Bug#1070396: exim4: FTBFS on hurd-i386

[Svante Signell]

Source: exim4
Version: 4.97-8
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

exim4 FTBFS on hurd-i386, but built before. Latest successful build
was 4.94-19. Attached are two patches enabling a successful build:

- exim_monitor_em_hdr.h:
em_hdr.h includes macros.h but not exim.h, which defines PATH_MAX, but
that header file cannot cannot be included. Instead define PATH_MAX
directly in em_hdr.h to avoid the error occurring when macros.h is
included.

- src_tls-gnu.c.patch:
Define tls_{client,server}_creds_invalidate() for Hurd too by adding
#defined(__GNU__) to the condition. Functions gnutls_priority_deinit()
and gnutls_certificate_free_credentials() already defined in
libgnutls.so.30 (and libgnutls.a)

Thanks!


--- a/src/tls-gnu.c	2023-11-04 13:55:49.0 +0100
+++ b/src/tls-gnu.c	2024-05-04 17:02:04.0 +0200
@@ -1720,7 +1720,7 @@
 }
 
 
-#if defined(EXIM_HAVE_INOTIFY) || defined(EXIM_HAVE_KEVENT)
+#if defined(EXIM_HAVE_INOTIFY) || defined(EXIM_HAVE_KEVENT) || defined(__GNU__)
 /* Invalidate the creds cached, by dropping the current ones.
 Call when we notice one of the source files has changed. */
  
Index: exim4-4.97/exim_monitor/em_hdr.h
===
--- exim4-4.97.orig/exim_monitor/em_hdr.h
+++ exim4-4.97/exim_monitor/em_hdr.h
@@ -99,6 +99,10 @@ this interface so that this kind of klud
 typedef void * hctx;
 
 #include "local_scan.h"
+/* PATH_MAX is defined in exim.h but cannot be included here */
+#ifndef PATH_MAX
+#define PATH_MAX 1024
+#endif
 #include "macros.h"
 #include "structs.h"
 #include "blob.h"

Bug#1069094: mariadb: FTBFS on hurd-i386

[Svante Signell]

Source: mariadb
Version: 10.11.7-4
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

mariadb FTBFS on hurd-i386. Attached are three patches enabling a
successful build:

- debian_rules.patch: 
override_dh_installsystemd: Install mariadb.service on Linux only.
override_dh_missing: Change dh_missing from fail to list on non-linux. 

- storage_connect_ioapi.h.patch:
Add Hurd to define __USE_FILE_OFFSET64 et al.

- plugin_disks_information_schema_disks.cc.patch:
Define PATH_MAX if not defined.

Unfortunately the build succeeds only with DEB_BUILD_OPTIONS=nocheck
since debian/rules override_dh_auto_test errors out with:
2024-04-16 11:09:38 0 [Note] Plugin 'INNODB_SYS_VIRTUAL' is disabled.
ERROR: 1017  Can't find file: '(temporary)' (errno: 1073741826 "No such
file or directory")
2024-04-16 11:09:38 0 [ERROR] Aborting

Additionally the file debian/unstable-tests.hurd should be linked to
unstable-tests.hurd-i386 (or equivalent) since
dpkg-architecture -qDEB_BUILD_ARCH results in hurd-i386.

Thanks!

--- a/debian/rules	2024-04-15 16:46:16.0 +0200
+++ b/debian/rules	2024-04-15 16:45:59.0 +0200
@@ -205,7 +205,14 @@
 	mv -v $(TMP)/usr/lib/mysql/plugin/qa_auth_client.so $(TMP)/usr/lib/$(DEB_HOST_MULTIARCH)/libmariadb3/plugin/
 
 override_dh_installsystemd:
+ifneq (,$(filter linux,$(DEB_HOST_ARCH_OS)))
 	dh_installsystemd -pmariadb-server mariadb.service
+endif
+
+override_dh_missing:
+ifneq (,$(filter linux,$(DEB_HOST_ARCH_OS)))
+	dh_missing --list-missing
+endif
 
 override_dh_installinit-arch:
 	dh_installinit --name=mariadb
Index: mariadb-10.11.7/plugin/disks/information_schema_disks.cc
===
--- mariadb-10.11.7.orig/plugin/disks/information_schema_disks.cc
+++ mariadb-10.11.7/plugin/disks/information_schema_disks.cc
@@ -32,6 +32,9 @@
 #include 
 #endif
 #endif
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
 #include 
 #include 
 #include /* check_global_access() */
--- a/storage/connect/ioapi.h	2024-02-01 18:36:14.0 +0100
+++ b/storage/connect/ioapi.h	2024-04-14 17:29:57.0 +0200
@@ -21,9 +21,10 @@
 #ifndef _ZLIBIOAPI64_H
 #define _ZLIBIOAPI64_H
 
-#if defined(__linux__)
+#if defined(__linux__) || defined (__GNU__)
 
-  // Linux needs this to support file operation on files larger then 4+GB
+  // Linux and Hurd needs this to support file operation on files larger
+  // than 4+GB.
   // But might need better if/def to select just the platforms that needs them.
 
 #ifndef __USE_FILE_OFFSET64

Re: dhcpcd: FTBFS on Hurd

[Svante Signell]

On Wed, 2024-01-17 at 18:48 +0100, Samuel Thibault wrote:
> Joshua Branson, le mer. 17 janv. 2024 12:09:30 -0500, a ecrit:
> > Also may I ask why Debian is switching to dhcpcd?  Just curious.
> 
> Because ISC is not maintaining its dhcp software any more.

I'm working on porting dhcpcd. No working installation yet :(

Thanks!
 

Bug#1060093: lirc: FTBFS on hurd-i386

[Svante Signell]

Source: lirc
Version: 0.10.2-0.2
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

lirc FTBFS on hurd-i386. (Built in the past, last successful build
version was 0.10.1-5.2)

This is due to usage of __u32 (and __u16,__u64) in
include/media/lirc.h, which is not defined on GNU/Hurd. Additionally
inclusion of header files is ifdef-ed and config.h is included.

Moreover, MODINFO is not available on GNU/Hurd since Hurd does not use
modules at all. This change is reflected in the second patch for
debian/rules.

The two patches enabling a successful build on GNU/Hurd (and
GNU/Linux)are attached in next mail:
- include/media/lirc.h
- debian_rules.patch.

I'm sending this bug report to Debian instead of upstream since this
package has been NMU-ed several times, and the second patch is Debian-
specific.

Thanks!

Index: lirc-0.10.2/include/media/lirc.h
===
--- lirc-0.10.2.orig/include/media/lirc.h
+++ lirc-0.10.2/include/media/lirc.h
@@ -6,8 +6,27 @@
 #ifndef _LINUX_LIRC_H
 #define _LINUX_LIRC_H
 
+#include "config.h"
+
+#ifdef HAVE_STDINT_H
+#include 
+#endif
+
+#ifdef HAVE_LINUX_TYPES_H
 #include 
+#endif
+
+#ifdef HAVE_LINUX_IOCTL_H
 #include 
+#endif
+
+#ifdef HAVE_SYS_IOCTL_H
+#include 
+#endif
+
+#ifdef __GNU__
+#include 
+#endif
 
 #define PULSE_BIT   0x0100
 #define PULSE_MASK  0x00FF
@@ -93,55 +112,55 @@
 
 /*** IOCTL commands for lirc driver ***/
 
-#define LIRC_GET_FEATURES  _IOR('i', 0x, __u32)
+#define LIRC_GET_FEATURES  _IOR('i', 0x, uint32_t)
 
-#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
-#define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
-#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
+#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, uint32_t)
+#define LIRC_GET_REC_MODE  _IOR('i', 0x0002, uint32_t)
+#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, uint32_t)
 
-#define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
-#define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
+#define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, uint32_t)
+#define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, uint32_t)
 
 /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
-#define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
+#define LIRC_GET_LENGTH_IOR('i', 0x000f, uint32_t)
 
-#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, __u32)
-#define LIRC_SET_REC_MODE  _IOW('i', 0x0012, __u32)
+#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, uint32_t)
+#define LIRC_SET_REC_MODE  _IOW('i', 0x0012, uint32_t)
 /* Note: these can reset the according pulse_width */
-#define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, __u32)
-#define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, __u32)
-#define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, __u32)
-#define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, __u32)
+#define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, uint32_t)
+#define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, uint32_t)
+#define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, uint32_t)
+#define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, uint32_t)
 
 /*
  * when a timeout != 0 is set the driver will send a
  * LIRC_MODE2_TIMEOUT data packet, otherwise LIRC_MODE2_TIMEOUT is
  * never sent, timeout is disabled by default
  */
-#define LIRC_SET_REC_TIMEOUT   _IOW('i', 0x0018, __u32)
+#define LIRC_SET_REC_TIMEOUT   _IOW('i', 0x0018, uint32_t)
 
 /* 1 enables, 0 disables timeout reports in MODE2 */
-#define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, __u32)
+#define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, uint32_t)
 
 /*
  * if enabled from the next key press on the driver will send
  * LIRC_MODE2_FREQUENCY packets
  */
-#define LIRC_SET_MEASURE_CARRIER_MODE	_IOW('i', 0x001d, __u32)
+#define LIRC_SET_MEASURE_CARRIER_MODE	_IOW('i', 0x001d, uint32_t)
 
 /*
  * to set a range use LIRC_SET_REC_CARRIER_RANGE with the
  * lower bound first and later LIRC_SET_REC_CARRIER with the upper bound
  */
-#define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, __u32)
+#define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, uint32_t)
 
-#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
+#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, uint32_t)
 
 /*
  * Return the recording timeout, which is either set by
  * the ioctl LIRC_SET_REC_TIMEOUT or by the kernel after setting the protocols.
  */
-#define LIRC_GET_REC_TIMEOUT	   _IOR('i', 0x0024, __u32)
+#define LIRC_GET_REC_TIMEOUT	   _IOR('i', 0x0024, uint32_t)
 
 /**
  * struct 

Re: poweroff support on Hurd?

[Svante Signell]

On Thu, 2023-12-07 at 08:16 +0200, Martin-Éric Racine wrote:
> 
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ showtrans /servers/shutdown
> /hurd/shutdown
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ showtrans /servers/acpi
> /hurd/acpi
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ ls /servers/acpi/tables/
> APIC  FACP  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$

On one of my images:
ls /servers/acpi/tables/
APIC  FACP  HPET  WAET

Re: Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'

[Svante Signell]

And on a Devuan/Ceres box:
dpkg -S /usr/lib/udev/rules.d/hwclock.rules
initscripts: /usr/lib/udev/rules.d/hwclock.rules

dpkg -S /usr/lib/udev/rules.d/85-hwclock.rules
dpkg-query: no path found matching pattern /usr/lib/udev/rules.d/85-
hwclock.rules

On Wed, 2023-12-06 at 18:08 +0100, Svante Signell wrote:
> On Wed, 2023-12-06 at 16:52 +, Mark Hindley wrote:
> > Martin,
> > 
> > On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote:
> > > Please note that the start target refers to a non-existing
> > > /usr/lib/udev/rules.d/85-hwclock.rules.  The correct file is
> > > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a
> > > reference to rtc0 that probably needs fixing for Hurd as well.
> > 
> > Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd.
> 
> On a Hurd box:
> ls /usr/lib/udev/rules.d/85-hwclock.rules
> ls: cannot access '/usr/lib/udev/rules.d/85-hwclock.rules': No such file or
> directory
> ls /usr/lib/udev/rules.d/hwclock.rules
> /usr/lib/udev/rules.d/hwclock.rules
> 
> dpkg -S /usr/lib/udev/rules.d/hwclock.rules 
> initscripts: /usr/lib/udev/rules.d/hwclock.rules
> 
> On a Devuan/Daedalus box:
> ls /usr/lib/udev/rules.d/85-hwclock.rules
> /usr/lib/udev/rules.d/85-hwclock.rules
> ls /usr/lib/udev/rules.d/hwclock.rules
> ls: cannot access '/usr/lib/udev/rules.d/hwclock.rules': No such file or
> directory
> 
> dpkg -S /usr/lib/udev/rules.d/85-hwclock.rules 
> util-linux-extra: /usr/lib/udev/rules.d/85-hwclock.rules
> 

Re: Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'

[Svante Signell]

On Wed, 2023-12-06 at 16:52 +, Mark Hindley wrote:
> Martin,
> 
> On Wed, Dec 06, 2023 at 06:06:41PM +0200, Martin-Éric Racine wrote:
> > Please note that the start target refers to a non-existing
> > /usr/lib/udev/rules.d/85-hwclock.rules.  The correct file is
> > /usr/lib/udev/rules.d/hwclock.rules instead. That file contains a
> > reference to rtc0 that probably needs fixing for Hurd as well.
> 
> Hmmm, udev is linux only, so I imagine udev rules are cruft on Hurd.

On a Hurd box:
ls /usr/lib/udev/rules.d/85-hwclock.rules
ls: cannot access '/usr/lib/udev/rules.d/85-hwclock.rules': No such file or
directory
ls /usr/lib/udev/rules.d/hwclock.rules
/usr/lib/udev/rules.d/hwclock.rules

dpkg -S /usr/lib/udev/rules.d/hwclock.rules 
initscripts: /usr/lib/udev/rules.d/hwclock.rules

On a Devuan/Daedalus box:
ls /usr/lib/udev/rules.d/85-hwclock.rules
/usr/lib/udev/rules.d/85-hwclock.rules
ls /usr/lib/udev/rules.d/hwclock.rules
ls: cannot access '/usr/lib/udev/rules.d/hwclock.rules': No such file or
directory

dpkg -S /usr/lib/udev/rules.d/85-hwclock.rules 
util-linux-extra: /usr/lib/udev/rules.d/85-hwclock.rules

Fwd: Re: Bug#1057634: /sbin/hwclock: unrecognized option '--rtc=/dev/rtc0'

[Svante Signell]

--- Begin Message ---
On Wed, 2023-12-06 at 12:07 +, Mark Hindley wrote:
> Chris,
> 
> Thanks for your input.
> 
> On Wed, Dec 06, 2023 at 11:56:56AM +0100, Chris Hofstaedtler wrote:
> > * Mark Hindley  [231206 11:42]:
> > > Is hwclock actually useful on Hurd? I (naively) expected it to be linux
> > > only. But src:util-linux still ships it[1]. Or is the HCTOSYS_DEVICE used
> > > in the
> > > initscripts just wrong on Hurd?
> > 
> > I have zero knowledge about hurd, but it looks like[1] hwclock is built
> > with CMOS support on hurd.  So maybe it could work?
> > 
> > It certainly is built without the RTC support, so --rtc=... doesn't
> > work.
> 
> A superficial attempt on exodar.debian.net isn't particularly encouraging:
> 
> leepen@exodar:~$ /sbin/hwclock --test
> hwclock from util-linux 2.39.2
> System Time: 1701863851.810595
> No usable clock interface found.
> hwclock: Cannot access the Hardware Clock via any known method.
> 
> I suggest we wait for a response from the Hurd experts. But maybe
> util-linux-extra should be arch:linux-any?
> 

On a qemu Hurd image:

/sbin/hwclock --help | grep rtc
--directisa use the ISA bus instead of /dev/rtc0 access

/sbin/hwclock --directisa --show
2023-12-06 14:17:54.949951+01:00


--- End Message ---

Bug#1056311: lirc: FTBFS on hurd-i386

[Svante Signell]

Source: lirc
Version: 0.10.1-7.2
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

lirc FTBFS on hurd-i386. (Built in the past, last successful build version was
0.10.1-5.2)

This is due to usage of __u32 in the patch 0007-lirc-gpio-ir-0.10.patch, which
is not defined on GNU/Hurd. This patch was added to version 0.10.1-6 in 2019.  

Attached is that patch updated to use uint32_t which is defined. (In fact
uint32_t is used in an earlier statement in that patch.)

Moreover, MODINFO is not available on GNU/Hurd since Hurd does not use modules
at all. This change is reflected in the second patch for debian/rules.

The two patches enabling a successful build on GNU/Hurd are attached:
The updated patch 0007-lirc-gpio-ir-0.10.patch
and debian_rules.patch.

I'm sending this bug report to Debian instead of upstream since this package has
been NMU-ed twice, and the second patch is Debian-specific.

Thanks!









From: Debian Lirc Team 
Date: Thu, 12 May 2022 21:07:56 +0200
Subject: lirc-gpio-ir-0.10

Origin: https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir-0.10.patch
Bug-Debian: bugs.debian.org/931078
---
 lib/config_file.c|  2 +-
 lib/ir_remote.h  |  9 +++--
 lib/irrecord.c   | 41 +++--
 lib/lirc/ir_remote.h |  9 +++--
 tools/mode2.cpp  | 18 +++---
 5 files changed, 57 insertions(+), 22 deletions(-)

Index: lirc-0.10.1/lib/config_file.c
===
--- lirc-0.10.1.orig/lib/config_file.c
+++ lirc-0.10.1/lib/config_file.c
@@ -71,7 +71,7 @@ struct void_array {
 typedef void* (*array_guest_func)(void* item, void* arg);
 
 
-#define LINE_LEN 1024
+#define LINE_LEN 4096
 #define MAX_INCLUDES 10
 
 const char* whitespace = " \t";
Index: lirc-0.10.1/lib/ir_remote.h
===
--- lirc-0.10.1.orig/lib/ir_remote.h
+++ lirc-0.10.1/lib/ir_remote.h
@@ -110,12 +110,17 @@ static inline ir_code reverse(ir_code da
 
 static inline int is_pulse(lirc_t data)
 {
-	return data & PULSE_BIT ? 1 : 0;
+	return ((data & LIRC_MODE2_MASK)==LIRC_MODE2_PULSE) ? 1 : 0;
 }
 
 static inline int is_space(lirc_t data)
 {
-	return !is_pulse(data);
+	return ((data & LIRC_MODE2_MASK)==LIRC_MODE2_SPACE) ? 1 : 0;
+}
+
+static inline int is_timeout(lirc_t data)
+{
+	return ((data & LIRC_MODE2_MASK)==LIRC_MODE2_TIMEOUT) ? 1 : 0;
 }
 
 static inline int has_repeat(const struct ir_remote* remote)
Index: lirc-0.10.1/lib/irrecord.c
===
--- lirc-0.10.1.orig/lib/irrecord.c
+++ lirc-0.10.1/lib/irrecord.c
@@ -1398,9 +1398,16 @@ enum lengths_status get_lengths(struct l
 		state->retval = 0;
 		return STS_LEN_TIMEOUT;
 	}
+	if (is_timeout(state->data)) {
+		return STS_LEN_AGAIN;
+	}
 	state->count++;
 	if (state->mode == MODE_GET_GAP) {
-		state->sum += state->data & PULSE_MASK;
+		if (state->sum != 0 || is_pulse(state->data)) {
+			state->sum += state->data & PULSE_MASK;
+		}else{
+			return STS_LEN_AGAIN;
+		}
 		if (state->average == 0 && is_space(state->data)) {
 			if (state->data > 10) {
 state->sum = 0;
@@ -1472,6 +1479,10 @@ enum lengths_status get_lengths(struct l
 		state->keypresses = lastmaxcount;
 		return STS_LEN_AGAIN;
 	} else if (state->mode == MODE_HAVE_GAP) {
+		if (state->count==1 && is_space(state->data))  {
+			state->count = 0;
+			return STS_LEN_AGAIN;
+		}
 		if (state->count <= MAX_SIGNALS) {
 			signals[state->count - 1] = state->data & PULSE_MASK;
 		} else {
@@ -1510,7 +1521,7 @@ enum lengths_status get_lengths(struct l
 			/* such long pulses may appear with
 			 * crappy hardware (receiver? / remote?)
 			 */
-			else {
+			else if(is_pulse(state->data)) {
 remote->gap = 0;
 return STS_LEN_NO_GAP_FOUND;
 			}
@@ -1811,22 +1822,24 @@ ssize_t raw_read(void* buffer, size_t si
 
 static int raw_data_ok(struct button_state* btn_state)
 {
-	int r;
+	int r = 0;
 	int ref;
 
-	if (!is_space(btn_state->data)) {
+	if (is_pulse(btn_state->data)) {
 		r = 0;
-	} else if (is_const()) {
-		if (remote.gap > btn_state->sum) {
-			ref = (remote.gap - btn_state->sum);
-			ref *= (100 - remote.eps);
-			ref /= 100;
+	} else if (is_space(btn_state->data)) {
+		if (is_const()) {
+			if (remote.gap > btn_state->sum) {
+ref = (remote.gap - btn_state->sum);
+ref *= (100 - remote.eps);
+ref /= 100;
+			} else {
+ref = 0;
+			}
+			r = btn_state->data > ref;
 		} else {
-			ref = 0;
+			r = btn_state->data > (remote.gap * (100 - remote.eps)) / 100;
 		}
-		r = btn_state->data > ref;
-	} else {
-		r = btn_state->data > (remote.gap * (100 - remote.eps)) / 100;
 	}
 	return r;
 }
@@ -1970,7 +1983,7 @@ enum button_status record_buttons(struct
 btn_state->data = remote.gap;
 			}
 			if (btn_state->count == 0) {
-if (!is_space(btn_state->data)
+if (is_pulse(btn_state->data)
  

Bug#1056145: e2fsprogs: FTBFS on hurd-i386

[Svante Signell]

Source: e2fsprogs
Version: 1.47.0-2
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

e2fsprogs FTBFS on hurd-i386 due to usage of PATH_MAX which is not defined on
GNU/Hurd. (Built in the past, last successful build was 1.46.6-1)

A patch enabling a successful build on GNU/Hurd is attached:
misc_tune2fs.c.diff

I chose to submit this patch to Debian instead of upstream as recommended. The
upstream reports seemed to be a little dated:
https://sourceforge.net/projects/e2fsprogs/ However, that page has the latest
version available for download.

Regarding the patch it is a very simple ifdef solution to that specific file. As
can be found in other parts of the code similar definitions are made. Maybe a
common header file defining PATH_MAX would be a better solution. (or dynamically
allocating space for strings as is recommended for GNU/Hurd) 

Thanks!








--- a/misc/tune2fs.c	2023-02-07 04:31:53.0 +0100
+++ b/misc/tune2fs.c	2023-11-17 16:09:42.0 +0100
@@ -3159,6 +3159,9 @@
 int tune2fs_main(int argc, char **argv)
 #endif  /* BUILD_AS_LIB */
 {
+#ifndef MATH_MAX
+#define PATH_MAX 4096
+#endif
 	errcode_t retval;
 	ext2_filsys fs;
 	struct ext2_super_block *sb;

Bug#1056050: mate-power-manager: Non-installable on hurd-i386

[Svante Signell]

Source: mate-power-manager
Version: 1.26.1-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

mate-power-manager is not installable on hurd-i386 due to dependencies on
polkitd, pkexec, and systemd or elogind which are only available for GNU/Linux.

A patch enabling a successful installation is attached:
debian_control.patch

Thanks!







--- a/debian/control	2023-11-15 12:36:26.0 +0100
+++ b/debian/control	2023-11-15 12:26:19.0 +0100
@@ -26,7 +26,7 @@
libxrandr-dev,
mate-common (>= 1.24.0-1~),
pkg-config,
-   polkitd,
+   polkitd [linux-any],
xmlto,
yelp-tools,
 Standards-Version: 4.6.2
@@ -40,8 +40,8 @@
 Depends: default-dbus-session-bus | dbus-session-bus,
  mate-notification-daemon | notification-daemon,
  mate-power-manager-common (= ${source:Version}),
- polkitd, pkexec,
- systemd | elogind | consolekit,
+ polkitd [linux-any] , pkexec [linux-any],
+ systemd [linux-any] | elogind [linux-any] | consolekit,
  upower,
  ${misc:Depends},
  ${shlibs:Depends},

Bug#1056049: consolekit2: Not buildable on hurd-i386

[Svante Signell]

Source: consolekit2
Version: 1.2.6-2
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

consolekit is not buildable on hurd-i386 due to a dependency on libevdev-dev
which is only available for GNU/Linux.

A patch enabling a successful build on GNU/Hurd is attached:
debian_control.patch

Thanks!







--- a/debian/control	2023-11-07 18:27:10.0 +0100
+++ b/debian/control	2023-11-15 12:39:55.0 +0100
@@ -14,7 +14,7 @@
libselinux1-dev [linux-any],
libudev-dev [linux-any],
libacl1-dev [linux-any],
-   libevdev-dev,
+   libevdev-dev [linux-any],
libpam0g-dev,
xsltproc,
xmlto,

Bug#1055936: synaptic: Non-installable on hurd-i386

[Svante Signell]

Source: synaptic
Version: 0.93.1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

synaptic is not installable on hurd-i386 due to dependencies on polkitd, pkexec
and policykit-1 which are only available for GNU/Linux.

A patch enabling a successful installation is attached:
debian_control.patch

Thanks!






--- a/debian/control	2023-11-14 11:54:05.0 +0100
+++ b/debian/control	2023-11-14 11:56:06.0 +0100
@@ -12,7 +12,7 @@
 
 Package: synaptic
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, polkitd | policykit-1, pkexec | policykit-1
+Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, polkitd [linux-any] | policykit-1 [linux-any], pkexec [linux-any] | policykit-1 [linux-any]
 Recommends: libgtk3-perl, xdg-utils
 Suggests: dwww, deborphan, apt-xapian-index, tasksel, software-properties-gtk
 Description: Graphical package manager

Bug#1055935: mate-polkit: Non-installable on hurd-i386

[Svante Signell]

Source: mate-polkit
Version: 1.26.1-4
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

mate-polkit is not installable on hurd-i386 due to a dependency on polkitd,
which is only available for GNU/Linux.

A patch enabling a successful installation is attached:
debian_control.patch

Thanks!





--- a/debian/control	2023-04-25 15:12:24.0 +0200
+++ b/debian/control	2023-11-14 10:54:11.0 +0100
@@ -43,7 +43,7 @@
 Architecture: any
 Depends: accountsservice,
  mate-polkit-common (>= ${source:Version}),
- polkitd,
+ polkitd [linux-any],
  ${misc:Depends},
  ${shlibs:Depends},
 Provides: polkit-1-auth-agent,

Bug#1055875: util-linux: FTBFS on hurd-i386

[Svante Signell]

Source: util-linux
Version: 2.39.2-5
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

util-linux FTBFS on hurd-i386 (built in the past, last successful build was
2.39.1-4).

A patch enabling a successful build is attached:
libmount_src_hooks.c.diff where mnt_context_is_fake()
is defined only if USE_LIBMOUNT_MOUNTFD_SUPPORT is defined. And
USE_LIBMOUNT_MOUNTFD_SUPPORT is only defined on GNU/Linux systems.

Alternately #ifdef __linux__ instead of #ifdef USE_LIBMOUNT_MOUNTFD_SUPPORT
could be used as condition. Maybe that would be a better solution.

Configure reports:
configure: WARNING: non-linux system; not building libmount_mountfd_support,
among in total 47 warnings for not building on a non-linux system.

Thanks!




--- a/libmount/src/hooks.c	2023-08-17 09:56:12.0 +0200
+++ b/libmount/src/hooks.c	2023-11-11 19:29:01.0 +0100
@@ -315,11 +315,14 @@
 {
 	int rc = 0;
 
+#ifdef USE_LIBMOUNT_MOUNTFD_SUPPORT
 	if (mnt_context_is_fake(cxt))
 		DBG(CXT, ul_debugobj(cxt, " FAKE call"));
 	else
 		rc = hook->func(cxt, hook->hookset, hook->data);
-
+#else
+		rc = hook->func(cxt, hook->hookset, hook->data);
+#endif
 	hook->executed = 1;
 	if (!rc)
 		rc = call_depend_hooks(cxt, hook->hookset->name, hook->stage);
@@ -364,10 +367,14 @@
 
 		DBG(CXT, ul_debugobj(cxt, "calling %s [first]", hs->name));
 
+#ifdef USE_LIBMOUNT_MOUNTFD_SUPPORT
 		if (mnt_context_is_fake(cxt))
 			DBG(CXT, ul_debugobj(cxt, " FAKE call"));
 		else
 			rc = hs->firstcall(cxt, hs, NULL);
+#else
+			rc = hs->firstcall(cxt, hs, NULL);
+#endif
 		if (!rc)
 			rc = call_depend_hooks(cxt, hs->name, stage);
 		if (rc < 0)

Bug#1033007: Now gcc-13: [Fwd: [PATCH] gcc-12: Re-enable split-stack support for GNU/Hurd.]

[Svante Signell]

Package: gcc-snapshot
Version: 1:20230315-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
Affects: gcc-snapshot
X-Debbugs-CC: debian-hurd@lists.debian.org

Hello, seems like the patch gcc_config_gnu.h.diff, in debian gcc-12 named:
pr104290-followup.diff was lost (again).

How can this patch ever become upstreamed??

It seems like sending to gcc-patches is not enough. Create a regression bug?  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 is already reported as a
regression, it has to be updated to cover upstream releases of gcc-13 now.

For gcc-12 Debian has been carrying it as:
pr104290-followup.diff

Submitting this problem as new bug to Debian/gcc-13/gcc-snapshot!

Thanks!
--- Begin Message ---
Hello,

In line of porting the latest build of libgo/go with gcc-12 to GNU/Hurd, support
of split-stack was found to be removed.
 
After patching the files in libgo the build of gotools fails:
go1: error: '-fsplit-stack' currently only supported on GNU/Linux
go1: error: '-fsplit-stack' is not supported by this compiler configuration

The attached patch defines OPTION_GLIBC_P(opts) and OPTION_GLIBC that was lost
in config/gnu.h, needed to enable split-stack support for GNU/Hurd. 

This problem happened with the latest commit as discussed in the mail thread
starting with https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588973.html
.

The file first doing this check is: (first error: ..)
src/gcc/common/config/i386/i386-common.cc
in function:
static bool ix86_supports_split_stack (bool report,
struct gcc_options *opts ATTRIBUTE_UNUSED)

and secondly in:src/gcc/opts.cc: (second error: ...)
in function:
void
finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
location_t loc)

The checking logic is in function ix86_supports_split_stack():
#if defined(TARGET_THREAD_SPLIT_STACK_OFFSET) && defined(OPTION_GLIBC_P)
  if (!OPTION_GLIBC_P (opts))
#endif
{
  if (report)
error ("%<-fsplit-stack%> currently only supported on GNU/Linux");
  return false;
}

  bool ret = true;

In case of GNU/Hurd TARGET_THREAD_SPLIT_STACK_OFFSET is defined as well as
OPTION_GLIBC_P but OPTION_GLIBC_P(opts) is needed to. The attached patch to
src/gcc/config/gnu.h creates that definition. For GNU/Hurd, gnu.h is included in
the configure stage:
Configuring stage 1 in ./gcc
...
Using the following target machine macro files:
...
../../src/gcc/config/gnu.h

For a longer history about this bug see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

Additionally, I would propose the text in gcc/common/config/i386/i386-common.cc
to change from:
error ("%<-fsplit-stack%> currently only supported on GNU/Linux");
to:
error ("%<-fsplit-stack%> currently only supported on GLIBC-based systems");

Thanks!

--- a/src/gcc/config/gnu.h	2022-02-06 11:59:41.0 +0100
+++ b/src/gcc/config/gnu.h	2022-02-06 12:00:19.0 +0100
@@ -19,6 +19,9 @@
 along with GCC.  If not, see .
 */
 
+#define OPTION_GLIBC_P(opts)	(DEFAULT_LIBC == LIBC_GLIBC)
+#define OPTION_GLIBC		OPTION_GLIBC_P (_options)
+
 #undef GNU_USER_TARGET_OS_CPP_BUILTINS
 #define GNU_USER_TARGET_OS_CPP_BUILTINS()		\
 do {	\
--- End Message ---

Bug#1029050: gcc-snapshot: FTBFS on hurd-i386 (and other archs?)

[Svante Signell]

Source: gcc-snapshot
Version: 20230108-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

gcc-snapshot in sid FTBFS on hurd-i386 due to that some patches are not
applied when building gcc-snapshot. After the statement in rules.patch
ifeq ($(single_package),yes)
  debian_patches =
endif
previously defined patches are cleared, causing the build failure, see
below.

debian/ files causing the problem:

debian/rules.defs:
ifneq (,$(findstring gcc-snapshot, $(PKGSOURCE)))
  single_package = yes
  trunk_build = yes

debian/rules.patch:
ifeq ($(single_package),yes)
  debian_patches =
endif

Thanks!

Bug#1027840: gcc-11: FTBFS on hurd-i386

[Svante Signell]

Source: gcc-11
Version: 11.3.0-10
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

gcc-11-11.3.0-10 in sid FTBFS on hurd-i386 due to failing linkage of
pthread_once (same error already fixed in gcc-12 and gcc-13):
/<>/build/i686-gnu/libstdc++-v3/include/i686-gnu/bits/gthr-
default.h:700: undefined reference to `pthread_once'
and more.

The patch at hand is: libstdc++-hurd.diff, attached here for convenience.

Thanks!

This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.

The pthread_self() function can also always be used fine as it is on
GNU/Hurd.

libstdc++-v3/ChangeLog:

* config/os/gnu-linux/os_defines.h [!__linux__]
  (_GLIBCXX_NATIVE_THREAD_ID, _GLIBCXX_GTHREAD_USE_WEAK): Do not define.

--- a/libstdc++-v3/config/os/gnu-linux/os_defines.h
+++ b/libstdc++-v3/config/os/gnu-linux/os_defines.h
@@ -49,22 +49,24 @@
 // version dynamically in case it has changed since libstdc++ was configured.
 #define _GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC __GLIBC_PREREQ(2,23)
 
-#if __GLIBC_PREREQ(2, 27)
-// Since glibc 2.27 pthread_self() is usable without linking to libpthread.
-# define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
-#else
+#ifdef __linux__
+# if __GLIBC_PREREQ(2, 27)
+// Since glibc 2.27 Linux' pthread_self() is usable without linking to libpthread.
+#  define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
+# else
 // Before then it was in libc.so.6 but not libc.a, and always returns 0,
 // which breaks the invariant this_thread::get_id() != thread::id{}.
 // So only use it if we know the libpthread version is available.
 // Otherwise use (__gthread_t)1 as the ID of the main (and only) thread.
-# define _GLIBCXX_NATIVE_THREAD_ID \
-  (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
-#endif
+#  define _GLIBCXX_NATIVE_THREAD_ID \
+   (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
+# endif
 
-#if __GLIBC_PREREQ(2, 34)
-// Since glibc 2.34 all pthreads functions are usable without linking to
+# if __GLIBC_PREREQ(2, 34)
+// Since glibc 2.34 all Linux pthreads functions are usable without linking to
 // libpthread.
-# define _GLIBCXX_GTHREAD_USE_WEAK 0
+#  define _GLIBCXX_GTHREAD_USE_WEAK 0
+# endif
 #endif
 
 #endif

Bug#1021357: gcc-12: FTBFS on hurd-i386

[Svante Signell]

Source: gcc-12
Version: 12_12.2.0-5
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

gcc-12-12.2.0-4/5 in sid FTBFS on hurd-i386 due to failing linkage of
pthread_once (same error for gcc-11, gcc-12, gcc-snapshot):
/<>/build/i686-gnu/libstdc++-v3/include/i686-gnu/bits/gthr-
default.h:700: undefined reference to `pthread_once'

Patches have already submitted upstream by Samuel Thibault in August and
September, see
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600469.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601754.html

Unfortunately upstream is not very responsive. Therefore I have taken the time
to send these patches to Debian in the mean time.

Patches extracted and attached from that mail message are:
1.diff-6.diff. Note that 1.diff does not apply to gcc-12, it is related to the
git repo. This is reflected in attached debian_rules.patch by commenting out
1.diff.

Just a reflection: Matthias you are really doing a great job with the
gcc releases: Kudos!

Thanks!

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index ba5939d9003..dd288cce2ca 100644
--- a/src/libstdc++-v3/ChangeLog
+++ b/src/libstdc++-v3/ChangeLog
@@ -1,3 +1,11 @@
+2022-08-28  Samuel Thibault  
+
+   * config/os/gnu/os_defines.h: New file.
+   * config/os/gnu/ctype_base.h: New file.
+   * config/os/gnu/ctype_configure_char.cc: New file.
+   * config/os/gnu/ctype_inline.h: New file.
+   * configure.host: On gnu* host, use os/gnu instead of os/gnu-linux.
+
 2022-08-27  Patrick Palka  
diff --git a/src/libstdc++-v3/config/os/gnu/ctype_base.h b/src/libstdc++-v3/config/os/gnu/ctype_base.h
new file mode 100644
index 000..955146543db
--- /dev/null
+++ b/src/libstdc++-v3/config/os/gnu/ctype_base.h
@@ -0,0 +1,66 @@
+// Locale support -*- C++ -*-
+
+// Copyright (C) 1997-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/ctype_base.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{locale}
+ */
+
+//
+// ISO C++ 14882: 22.1  Locales
+//
+
+// Information as gleaned from /usr/include/ctype.h
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  /// @brief  Base class for ctype.
+  struct ctype_base
+  {
+// Non-standard typedefs.
+typedef const int* 		__to_type;
+
+// NB: Offsets into ctype::_M_table force a particular size
+// on the mask type. Because of this, we don't use an enum.
+typedef unsigned short 	mask;
+static const mask upper	= _ISupper;
+static const mask lower 	= _ISlower;
+static const mask alpha 	= _ISalpha;
+static const mask digit 	= _ISdigit;
+static const mask xdigit 	= _ISxdigit;
+static const mask space 	= _ISspace;
+static const mask print 	= _ISprint;
+static const mask graph 	= _ISalpha | _ISdigit | _ISpunct;
+static const mask cntrl 	= _IScntrl;
+static const mask punct 	= _ISpunct;
+static const mask alnum 	= _ISalpha | _ISdigit;
+#if __cplusplus >= 201103L
+static const mask blank	= _ISblank;
+#endif
+  };
+
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace
diff --git a/src/libstdc++-v3/config/os/gnu/ctype_configure_char.cc b/src/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
new file mode 100644
index 000..5a88fc11ab3
--- /dev/null
+++ b/src/libstdc++-v3/config/os/gnu/ctype_configure_char.cc
@@ -0,0 +1,196 @@
+// Locale support -*- C++ -*-
+
+// Copyright (C) 2011-2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but 

Bug#1021260: libdumbnet: FTBFS on hurd-i386

[Svante Signell]

Source: libdumbnet
Version: 1.16.1-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hi,

Currently libdumbnet FTBFS on GNU/Hurd due to some failing symbols for
libdumbnet1 in the Hurd build compared to Linux. I built in the past. Latest
successful build was: 1.14-2.

The attached patch, debian_libdumbnet1.symbols.patch, fixes the build problem.

Thanks!





--- a/debian/libdumbnet1.symbols	2022-05-04 19:18:23.0 +0200
+++ b/debian/libdumbnet1.symbols	2022-10-04 13:27:47.0 +0200
@@ -72,7 +72,7 @@
  ndisc_close@Base 1.16.1
  ndisc_delete@Base 1.16.1
  ndisc_get@Base 1.16.1
- ndisc_modify@Base 1.16.1
+ (arch=!hurd-any)ndisc_modify@Base 1.16.1
  ndisc_open@Base 1.16.1
  nsidc_loop@Base 1.16.1
  rand_add@Base 1.8
@@ -84,10 +84,10 @@
  rand_uint16@Base 1.8
  rand_uint32@Base 1.8
  rand_uint8@Base 1.8
- route6_add@Base 1.16.1
- route6_delete@Base 1.16.1
+ (arch=!hurd-any)route6_add@Base 1.16.1
+ (arch=!hurd-any)route6_delete@Base 1.16.1
  route_add@Base 1.8
- route_add_dev@Base 1.16.1
+ (arch=!hurd-any)route_add_dev@Base 1.16.1
  route_close@Base 1.8
  route_delete@Base 1.8
  route_get@Base 1.8

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

On Thu, 2022-01-27 at 20:23 +0100, Samuel Thibault wrote:
> Svante Signell, le jeu. 27 janv. 2022 12:08:47 +0100, a ecrit:
> > On Wed, 2022-01-26 at 17:54 +0100, Samuel Thibault wrote:
> > > So here the problem is that
> > > 
> > > test ! -d /home
> > > 
> > > says that /home is not a directory. Is there anything special about your
> > > /home path? Perhaps show the output of
> > > 
> > > stat /home
> > 
> >   File: /home
> >   Size: 4096Blocks: 8  IO Block: 8192   directory
> > Device: 1a0h/416d   Inode: 2   Links: 4
> > Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
> > Access: 2022-01-27 07:58:34.0 +0100
> > Modify: 2017-01-20 13:14:35.0 +0100
> > Change: 2017-01-20 13:14:35.0 +0100
> >  Birth: -
> > 
> > 
> > On all boxes the little script
> > #! /bin/sh
> > if test ! -d /home; then
> > echo "/home is not a directory"
> > else
> > echo "/home is a directory"
> > fi
> > returns : /home is a directory
> 
> One additional thing is that make install is run under fakeroot, so
> you'll have to also involve fakeroot in your tests.

The packages was built with dpkg-buildpackage -b 2>&1 | tee ../build.log where
fakeroot is automatically called.

But here is one result:
fakeroot stat /home
  File: /home
  Size: 4096Blocks: 8  IO Block: 8192   directory
Device: 1a1h/417d   Inode: 2   Links: 4
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2022-01-26 23:12:36.0 +0100
Modify: 2019-07-05 23:29:24.0 +0200
Change: 2019-07-05 23:29:24.0 +0200
 Birth: -

fakeroot ./test_for_directory.sh 
/home is a directory

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

On Wed, 2022-01-26 at 17:54 +0100, Samuel Thibault wrote:
> 
> So here the problem is that
> 
> test ! -d /home
> 
> says that /home is not a directory. Is there anything special about your
> /home path? Perhaps show the output of
> 
> stat /home

  File: /home
  Size: 4096Blocks: 8  IO Block: 8192   directory
Device: 1a0h/416d   Inode: 2   Links: 4
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2022-01-27 07:58:34.0 +0100
Modify: 2017-01-20 13:14:35.0 +0100
Change: 2017-01-20 13:14:35.0 +0100
 Birth: -

With similar results for the other two boxes.

cat /etc/fstab:
/dev/hd0s6  /home   ext2defaults0   2
/dev/hd0s2  /home   ext2defaults0   2
/dev/hd0s2  /home   ext2defaults0   2

/bin/sh is linked to dash. 
dash 0.5.11+git20210903+057cd650a4ed-3 

On all boxes the little script
#! /bin/sh
if test ! -d /home; then
echo "/home is not a directory"
else
echo "/home is a directory"
fi
returns : /home is a directory

and:

file /home
/home: directory

Thanks!

Re: Dropping gdc support?

[Svante Signell]

Unfortunate, I was just about to look into that problem.

On Sun, 2022-01-23 at 22:56 +0100, Samuel Thibault wrote:
> Samuel Thibault, le dim. 16 janv. 2022 21:19:17 +0100, a ecrit:
> > otherwise I'll soon ask to just drop the gdc support from
> > gcc-12
> 
> Apparently doko already did it.
> 
> Samuel
> 

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

On Tue, 2022-01-25 at 23:42 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 25 janv. 2022 23:40:17 +0100, a ecrit:
> > On Tue, 2022-01-25 at 22:16 +0100, Samuel Thibault wrote:
> > > > 
> > > > Thanks!
> > > > But on a third image I get:
> > > > mkdir: cannot create directory ‘/home’: File exists
> > > > 
> > > > Something is fishy...
> > > 
> > > As I already wrote, first make sure exactly *what* is producing
> > > this
> > > call. That way you'll see where the fish comes from.
> > 
> > I'd really appreciate to know the difference of an old image upgraded
> > to current and a new one??
> 
> No idea. As I've already written, I'm just using the
> debian-hurd-20210812.img image, upgraded to current archive.

I did add set -x to mkinstalldirs:

make[3]: Entering directory '/home/.../hurd-0.9.git20211230/build-
deb/libshouldbeinlibc'
+ errstatus=0
+ echo :/home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu
+ sed -ne s/^:\//#/;s/^://;s/\// /g;s/^#/\//;p
+ set fnord /home srs DEBs hurd hurd-0.9.git20211230 debian tmp lib
i386-gnu
+ shift
+ pathcomp=
+ pathcomp=/home
+ test ! -d /home
+ echo mkdir /home
mkdir /home
+ mkdir /home
mkdir: cannot create directory ‘/home’: File exists
+ lasterr=1
+ test ! -d /home
+ errstatus=1
+ pathcomp=/home/
...

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

On Tue, 2022-01-25 at 22:16 +0100, Samuel Thibault wrote:
> > 
> > Thanks!
> > But on a third image I get:
> > mkdir: cannot create directory ‘/home’: File exists
> > 
> > Something is fishy...
> 
> As I already wrote, first make sure exactly *what* is producing this
> call. That way you'll see where the fish comes from.

I'd really appreciate to know the difference of an old image upgraded
to current and a new one??

Thanks!

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

On Tue, 2022-01-25 at 19:43 +0100, Samuel Thibault wrote:
> 
> I can confirm again that building the package with a mere
> 
>  dpkg-buildpackage
> 
> works fine for me. This is as non-root user, I tried both on the /
> partition, and on a separate partition. I also tried upgrading the
> 20210812 image to the latest packages, it built successfully.
> I do get the /proc/5/stat error, so that doesn't seem to be the
> trigger.
> 
> So yes, it seems that the investigation has to happen on your
> systems.

Thanks!
But on a third image I get:
mkdir: cannot create directory ‘/home’: File exists

Something is fishy...

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

On Tue, 2022-01-25 at 17:06 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 25 janv. 2022 17:04:41 +0100, a ecrit:
> > On Tue, 2022-01-25 at 16:38 +0100, Samuel Thibault wrote:
> > > Svante Signell, le mar. 25 janv. 2022 16:15:46 +0100, a ecrit:
> > > > 
> > > > mkdir /home
> > > > mkdir: cannot create directory ‘/home’: File exists

> > > 
> > > Is this really unmodified source code? I don't see how there
> > > could be
> > > an
> > > 
> > > mkdir /home
> > > 
> > > triggered by the build rules you are patching:
> > 
> > Yes, unmodified sources. Found on two up-to-date images already.
> > Could
> > this be related to the /proc/5/stat bug?
> 
> I don't see how that could be.

Maybe not.

BTW: When you (or somebody else) have confirmed/not confirmed building
the latest hurd successfully on an up-to-date image (no chroot, no
buildd) we can continue this discussion. If not this discussion ends
here.

Thanks!

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

On Tue, 2022-01-25 at 16:38 +0100, Samuel Thibault wrote:
> Hello,
> 
> Svante Signell, le mar. 25 janv. 2022 16:15:46 +0100, a ecrit:
> > make[3]: Entering directory '/home/.../hurd-0.9.git20211230/build-
> > deb/
> > libshouldbeinlibc'
> > mkdir /home
> > mkdir: cannot create directory ‘/home’: File exists
> > mkdir /home/.../hurd-0.9.git20211230/debian/tmp/lib
> > mkdir /home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu
> 
> Is this really unmodified source code? I don't see how there could be
> an
> 
> mkdir /home
> 
> triggered by the build rules you are patching:

Yes, unmodified sources. Found on two up-to-date images already. Could
this be related to the /proc/5/stat bug?

Bug#1004348: hurd: FTBFS on hurd-i386 locally

[Svante Signell]

Source: hurd
Version: 0.9.git20211230-5
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hi,

Currently hurd FTBFS on GNU/Hurd due to a problem with the
Makeconf/mkinstalldirs scripts.

>From the build log:
make -C libshouldbeinlibc install
make[3]: Entering directory '/home/.../hurd-0.9.git20211230/build-deb/
libshouldbeinlibc'
mkdir /home
mkdir: cannot create directory ‘/home’: File exists
mkdir /home/.../hurd-0.9.git20211230/debian/tmp/lib
mkdir /home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu
../../Makeconf:307: recipe for target '/home/.../hurd-
0.9.git20211230/debian/tmp/lib/i386-gnu' failed
make[3]: *** [/home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu]
Error 1
make[3]: Leaving directory '/home/.../hurd-0.9.git20211230/build-
deb/libshouldbeinlibc'
../Makefile:280: recipe for target 'libshouldbeinlibc-install' failed
make[2]: *** [libshouldbeinlibc-install] Error 2

On the buildd the build succeeds:
make[3]: Entering directory '/<>/build-
deb/libshouldbeinlibc'
mkdir /<>/debian/tmp/lib
mkdir /<>/debian/tmp/lib/i386-gnu
mkdir /<>/debian/tmp/usr
mkdir /<>/debian/tmp/usr/include
where 
I: NOTICE: Log filtering will replace 'build/hurd-52h0Hx/hurd-
0.9.git20211230' with '<>'

Maybe building hurd in a chroot would also succeed. This has not been
attempted yet.

The attached patch, Makeconf.patch, has been used to successfully build
hurd on GNU/Hurd locally. Alternately one could modify mkinstalldirs
accordingly since MKINSTALLDIRS = $(top_srcdir)/mkinstalldirs, and
replacing mkdir with mkdir -p, as given in mkinstalldirs.patch.

With this patch hurd builds fine too. It might be the preferred
solution.

>From the build log:
make -C libshouldbeinlibc install
make[3]: Entering directory '/home/hurd-0.9.git20211230/build-
deb/libshouldbeinlibc'
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/lib
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/lib/i386-gnu
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/usr
mkdir -p /home/.../hurd-0.9.git20211230/debian/tmp/usr/include

Thanks!






--- a/Makeconf	2022-01-25 10:57:58.0 +0100
+++ b/Makeconf	2022-01-25 10:57:41.0 +0100
@@ -240,7 +240,7 @@
 all: $(install-targets)
 install: $(DESTDIR)$(installationdir) $(addprefix $(DESTDIR)$(installationdir)/,$(install-targets))
 $(DESTDIR)$(installationdir):
-	@$(MKINSTALLDIRS) $@
+	-@$(MKINSTALLDIRS) $@
 $(addprefix $(DESTDIR)$(installationdir)/,$(installable)): $(DESTDIR)$(installationdir)/%: %
 	$(INSTALL_PROGRAM) $(INSTALL-$<-ops) $< $@
 else
@@ -255,7 +255,7 @@
 install-headers: $(DESTDIR)$(includedir)/$(installhdrsubdir) $(addprefix $(DESTDIR)$(includedir)/$(installhdrsubdir)/,$(installhdrs))
 
 $(DESTDIR)$(includedir)/$(installhdrsubdir): $(DESTDIR)$(includedir)
-	@$(MKINSTALLDIRS) $@
+	-@$(MKINSTALLDIRS) $@
 
 # Arrange to have the headers installed locally anytime we build the library.
 # Not quite perfect, but at least it does end up getting done; and once done
@@ -304,7 +304,7 @@
 
 # Making installation directories
 $(addprefix $(DESTDIR),$(installationdirlist)): %:
-	@$(MKINSTALLDIRS) $@
+	-@$(MKINSTALLDIRS) $@
 
 # Building the target
 ifneq ($(makemode),misc)
--- a/mkinstalldirs	2021-12-30 15:16:15.0 +0100
+++ b/mkinstalldirs	2022-01-25 15:41:19.0 +0100
@@ -22,9 +22,9 @@
  esac
 
  if test ! -d "$pathcomp"; then
-echo "mkdir $pathcomp" 1>&2
+echo "mkdir -p $pathcomp" 1>&2
 
-mkdir "$pathcomp" || lasterr=$?
+mkdir -p "$pathcomp" || lasterr=$?
 
 if test ! -d "$pathcomp"; then
   	  errstatus=$lasterr

Re: Dropping gdc support?

[Svante Signell]

Unfortunately. I was jut going to look into that problem...

On Sun, 2022-01-23 at 22:56 +0100, Samuel Thibault wrote:
> Samuel Thibault, le dim. 16 janv. 2022 21:19:17 +0100, a ecrit:
> > otherwise I'll soon ask to just drop the gdc support from
> > gcc-12
> 
> Apparently doko already did it.
> 
> Samuel
> 

Bug#985645: hurd: Hurd creates buggy core files or gdb cannot read core files properly

[Svante Signell]

Source: hurd
Version: 1:0.9.git20201127-7
Severity: important
Tags: upstream
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

When hurd dumps a core file it cannot be read properly in gdb. This is
either due to a bug in the Hurd package itself or a bug in gdb. The
core dump code in Hurd seems to be located at:
exec/elfcore.s:dump_core().

I'm filing this bug to Hurd, but the problem might also be in gdb not
being able to read the core file. 

Example session:
host ftp.sunet.se
ftp.sunet.se is an alias for sunet.ftp.acc.umu.se.
sunet.ftp.acc.umu.se has address 194.71.11.173
sunet.ftp.acc.umu.se has address 194.71.11.165
socket.c:3175: REQUIRE(readable || writeable) failed, back trace
#0 0x1337666 in ??
#1 0x1337595 in ??
#2 0x137e3d5 in ??
#3 0x1372d1c in ??
#4 0x13e782f in ??
Aborted (core dumped)
...:~$ gdb -core ./core
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
;.
Find the GDB manual and other documentation resources online at:
;.

For help, type "help".
Type "apropos word" to search for commands related to "word".
[New process 14435]
[New process 1]
[New process 2]
[New process 3]
[New process 4]

warning: Unexpected size of section `.reg2/14435' in core file.
--Type  for more, q to quit, c to continue without paging--
Core was generated by `host ftp.sunet.se'.
Program terminated with signal SIGABRT, Aborted.

warning: Unexpected size of section `.reg2/14435' in core file.
#0  0x0141569c in ?? ()
[Current thread is 1 (process 14435)]
(gdb) quit

A bug report to the bind9-host package,1:9.16.13-1,  will be filed
separately. Probably this is also a Hurd bug and should be assigned to
Hurd, not bind9-host. Some more investigations are needed until then.

Thanks!

Re: go issues

[Svante Signell]

On Thu, 2021-02-04 at 10:44 +0100, Samuel Thibault wrote:
> Svante Signell, le jeu. 04 févr. 2021 10:39:32 +0100, a ecrit:

> > I just found out about the patched gcc-10 package. Then this patch
> > has to be applied also for gcc-11 and gcc-snapshot, right?
> 
> As I said, it was already commited upstream.
> 
> > Which versions from upstream in Debian already have the patch
> > applied?
> 
> None: Debian is getting frozen, I don't know if doko will upload new
> fixes, but that's not a problem anyway, this is now available from
> debian-ports.

gcc-11 is in experimental, so the code freeze should not affect it, or?
And the latest gcc-snapshot in sid is 20210204-1. Does that version
have the patch applied?

Re: go issues

[Svante Signell]

On Thu, 2021-02-04 at 10:35 +0100, Samuel Thibault wrote:
> Svante Signell, le jeu. 04 févr. 2021 10:30:57 +0100, a ecrit:
> > On Wed, 2021-02-03 at 18:52 +0100, Samuel Thibault wrote:
> > > It seems that the go issues that we were meeting (segfaults etc.)
> > > were due to the missing support for unwinding over signal
> > > handling
> > > with siginfo support. The fix is already committed upstream, I am
> > > uploading a fixed patch to debian-ports, and requeued the golang
> > > packages that seemed affected.
> > 
> > Do you mean the patch:
> > glibc (2.31-10~0) unreleased; urgency=medium
> > 
> >   * debian/patches/hurd-i386/unsubmitted-tiocflush.diff: Cope with
> > BSD 4.1-ish ioctl(..., TIOCFLUSH, NULL).
> 
> No, I mean where unwinding actually happens, in libgcc-s1,
> 
>   * patches/unwind_siginfo: libgcc unwinding over signal trampolines
> with SIGINFO.

I just found out about the patched gcc-10 package. Then this patch has
to be applied also for gcc-11 and gcc-snapshot, right? Which versions
from upstream in Debian already have the patch applied?

Thanks!

Re: go issues

[Svante Signell]

On Wed, 2021-02-03 at 18:52 +0100, Samuel Thibault wrote:
> Hello,
> 
> It seems that the go issues that we were meeting (segfaults etc.)
> were due to the missing support for unwinding over signal handling
> with siginfo support. The fix is already committed upstream, I am
> uploading a fixed patch to debian-ports, and requeued the golang
> packages that seemed affected.

Do you mean the patch:
glibc (2.31-10~0) unreleased; urgency=medium

  * debian/patches/hurd-i386/unsubmitted-tiocflush.diff: Cope with
BSD 4.1-ish ioctl(..., TIOCFLUSH, NULL).

That patch does not improve the go issues. I've re-run the go and libgo
tests from gcc-snapshot-20210108-1. The results are the same. For
example for libgo, see especially the SIGABRT failures:

=== libgo Summary ===

# of expected passes169
# of unexpected failures13

Looking at the errors more closely shows:
FAIL: cmd/go/internal/fsys: overlaid files can't be opened for write,
want nil
FAIL: html/template: SIGABRT: abort: failed to throw unwind exception
(reason=5)
FAIL: log/syslog: setsockopt: protocol not available
FAIL: net: setsockopt: protocol not available
FAIL: net/http: Segmentation fault (core dumped)
FAIL: net/http/cgi: error while loading shared libraries: libgo.so.19
FAIL: os/signal: Segmentation fault
FAIL: reflect: SIGABRT: abort: failed to throw unwind exception
(reason=5)
FAIL: runtime: SIGABRT: abort: failed to throw unwind exception
(reason=5)
FAIL: runtime/pprof: total 0 CPU profile samples collected: too few
samples
FAIL: sync/atomic: SIGABRT: abort: failed to throw unwind exception
(reason=5)
FAIL: text/template: SIGABRT: abort: failed to throw unwind exception
(reason=5)
FAIL: time: SIGABRT: abort: failed to throw unwind exception (reason=5)

Re: PHP 7.4 on Debian GNU/Hurd

[Svante Signell]

On Tue, 2020-12-01 at 12:51 +0100, Svante Signell wrote:
> On Tue, 2020-12-01 at 12:29 +0100, Richard Braun wrote:
> > Hello,
> > 
> > The php7.4 package and all that depend on it cannot be built
> > because
> > of
> > a dependency from php7.4 on systemd. Is there anything that can be
> > done
> > about it ?
> 
> See #951834 for patches. The only dependent package on systemd is  
> php-fhm: systemd | systemd-tmpfiles.
^^php-fpm:

Re: PHP 7.4 on Debian GNU/Hurd

[Svante Signell]

On Tue, 2020-12-01 at 12:29 +0100, Richard Braun wrote:
> Hello,
> 
> The php7.4 package and all that depend on it cannot be built because
> of
> a dependency from php7.4 on systemd. Is there anything that can be
> done
> about it ?

See #951834 for patches. The only dependent package on systemd is php-
fhm: systemd | systemd-tmpfiles.

Re: Expired ports archive key on current-hurd-i386 image

[Svante Signell]

On Wed, 2020-04-15 at 18:50 +0530, Pirate Praveen wrote:
> 
> On Tue, Apr 14, 2020 at 8:30 pm, Svante Signell 
>  wrote:
> > On Tue, 2020-04-14 at 23:34 +0530, Pirate Praveen wrote:
> > >  > Pirate Praveen, le mar. 14 avril 2020 21:48:17 +0530, a ecrit:
> > >  > Since I can't ssh into it yet, I can't share the logs. I have
> > >  > installed openssh-server on the vm but I can't ssh into vm
> > > from my
> > >  > host.
> > > 
> > >  I'm trying to ssh 10.0.2.15
> > 
> > That address is to access the host from the guest!

Sorry 10.0.2.2 is the gateway address the address to reach the host.
10.0.2.15 is the guest address. I saw that you got it right from your
follow-up mail.

Re: Expired ports archive key on current-hurd-i386 image

[Svante Signell]

On Tue, 2020-04-14 at 23:34 +0530, Pirate Praveen wrote:
> 
> > Pirate Praveen, le mar. 14 avril 2020 21:48:17 +0530, a ecrit:
> > Since I can't ssh into it yet, I can't share the logs. I have
> > installed openssh-server on the vm but I can't ssh into vm from my
> > host.
> 
> I'm trying to ssh 10.0.2.15

That address is to access the host from the guest!

How do you run your VM? A simple example to log in to your guest box
from the host a simple way to log in with ssh -p5556 localhost is to
add to the qemu-system-x86_64 command line :
-net nic,model=e1000 -net user,hostfwd=tcp::5556-:22

HTH!

Bug#951544: mate-session-manager: FTBFS on non-linux

[Svante Signell]

Source: mate-session-manager
Severity: important
Version: 1.24.0-1
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hello,

The latest version of mate-session-manager FTBFS on Hurd and kFreeBSD due to a
missing build dependency on libegl-dev. Looking at the build logs for linux*
architectures reveals that libegl-dev (and dependant libraries) are installed
for the builds, making them succeed without an explicit build-dependency. How
that is happening is unknown to this bug submitter.

The attached patch fixes the build for hurd-any and kfreebsd-any. Maybe that
dependency should also be added to the linux-any targets. In that case the build
dependency to add would be simply libegl-dev.

Thanks.
--- a/debian/control	2020-02-13 11:20:44.0 +0100
+++ b/debian/control	2020-02-17 22:59:52.0 +0100
@@ -25,6 +25,7 @@
libxrender-dev,
libxt-dev,
libxtst-dev,
+   libgles-dev [hurd-any kfreebsd-any],
mate-common (>= 1.18),
xmlto,
xsltproc,

Bug#951541: mate-panel: FTBFS on non-linux

[Svante Signell]

Source: mate-panel
Severity: important
Version: 1.24.0-1
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hello,

The latest version of mate-panel FTBFS on Hurd and kFreeBSD due to a build
dependency of libgtk-layer-shell-dev. That package is dependant on Wayland,
which is not yet available on hurd-any or kfreebsd-any.

The attached patch makes the build-dependency linux-any only.

Thanks.
--- a/debian/control	2020-02-13 13:07:28.0 +0100
+++ b/debian/control	2020-02-17 14:58:08.0 +0100
@@ -13,7 +13,7 @@
gir1.2-freedesktop,
gobject-introspection,
gtk-doc-tools,
-   libgtk-layer-shell-dev (>= 0.1.0-3~),
+   libgtk-layer-shell-dev (>= 0.1.0-3~) [linux-any],
intltool,
libatk1.0-dev,
libcairo2-dev,

Bug#951516: gvfs: gvfs-daemons fails to install on non-linux boxes

[Svante Signell]

Source: gvfs
Severity: important
Version: 1.42.2-1
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-hurd@lists.debian.org

Hello,

The latest version of gvfs fails to install on non-linux boxes due to the
dependency on lsof for gvfs-daemons, which is not available for these
architectures. Additionally, lsof is only needed for UDisks2VolumeMonitor, which
is built for linux-any only.

Attached are two patches, one for control and one for control.in. The first
patch is added for completeness, even if that file claims to be autogenerated.
The file being generated from control.in is created at debian/gvfs-
daemons/DEBIAN/control and debian/control by dh_gencontrol.

Thanks.
--- a/debian/control	2020-01-22 17:19:31.0 +0100
+++ b/debian/control	2020-02-17 14:32:20.0 +0100
@@ -140,7 +140,7 @@
 Section: libs
 Depends: gvfs-common (= ${source:Version}),
  gvfs-libs (= ${binary:Version}),
- lsof,
+ lsof [linux-any],
  udisks2 [linux-any],
  x11-utils,
  ${misc:Depends},
--- a/debian/control.in	2020-01-22 17:19:31.0 +0100
+++ b/debian/control.in	2020-02-17 14:36:01.0 +0100
@@ -136,7 +136,7 @@
 Section: libs
 Depends: gvfs-common (= ${source:Version}),
  gvfs-libs (= ${binary:Version}),
- lsof,
+ lsof [linux-any],
  udisks2 [linux-any],
  ${misc:Depends},
  ${shlibs:Depends}

Re: sigaltstack fix & golang

[Svante Signell]

On Wed, 2019-12-11 at 03:14 +0100, Samuel Thibault wrote:
> Hello,
> 
> I have tracked & found a bug in the sigaltstack implementation, that
> was posing problem to golang. I have uploaded a glibc package version
> 2.29-7~0+hurd.1 to unreleased, to be available within a few hours. I
> have given back the failing golang packages, so we get to see to which
> extent that fixed them.

I always suspected something was wrong with the sigaltstack code in trampoline.c
but could not pin it down. Too much assembly-like code for me to understand.
Hopefully you have found one of the major bugs for proper golang support in
Hurd.

Thanks!

Bug#942558: hurd: should return ENXIO instead of EIEIO in open()

[Svante Signell]

On Fri, 2019-10-18 at 23:37 +0800, Shengjing Zhu wrote:
> On Fri, Oct 18, 2019 at 2:38 PM Samuel Thibault  > wrote:
> > Hello,
> > 
> > Shengjing Zhu, le ven. 18 oct. 2019 13:26:58 +0800, a ecrit:
> > > When calling open(fifo_fd, O_WRONLY | O_NONBLOCK) on an fifo
> > > file, which has
> > > no reader, it should return ENXIO. But on Hurd, it returns EIEIO.
> > 
> > I guess you mean it does this consistently?
> > 
> 
> consistently on the qemu vm, with the image downloaded from
> cdimage.d.o.
> 
> I think it can be reproduced by following snippets,
> 
> ```
> #include 
> #include 
> #include 
> #include 
> 
> int main() {
>  char *s = "test";
>  mkfifo(s, S_IRUSR | S_IWUSR);
>  open(s, O_WRONLY | O_NONBLOCK);
>  perror(NULL);
>  return 0;
> }
> ```
> 
> On linux, it prints "No such device or address";
> On the hurd vm, it prints "Computer bought the farm".
> 
Confirmed:
./test_fifo
Computer bought the farm

And it does not seem to kill the translator:
ps -feM|grep fifo
 srs 11016   411  0:00.00 /hurd/fifo

Re: Emacs troubles after dist-upgrade

[Svante Signell]

On Mon, 2019-08-12 at 23:56 +0200, Samuel Thibault wrote:
> Samuel Thibault, le lun. 12 août 2019 23:50:22 +0200, a ecrit:
> > Svante Signell, le lun. 12 août 2019 23:08:10 +0200, a ecrit:
> > > On Mon, 2019-08-12 at 20:34 +0200, Samuel Thibault wrote:

> > > What about fixing the bugs to make emacs building (again)?

> This kind of remark just drops every bit of motivation from me.
> Was that really the effect you wanted to achieve?
> 
> I have litterally spent the week-end flushing out a fair part of my
> inbox. Such "what about?" remark is definitely not welcome, thanks.

We have been discussing the emacs problem for several years now. And I
don't know where the bugs/missing stuff is. I have tried debugging
emacs several times and failed. Even you who is a guru don't seem to
know how to find the bugs/missing stuff. Do you think the emacs people
can help us with this? I've had several contacts with them too but no
solution has been found so far...

Sorry for wasting your time reading this.
 

Re: Emacs troubles after dist-upgrade

[Svante Signell]

On Mon, 2019-08-12 at 20:34 +0200, Samuel Thibault wrote:
> 
> Since the arch:all packages shared with the linux ports come into
> play, one sometimes have to juggle a bit indeed. Usually the packages
> coming from unreleased are meant to fix things, so better rather try
> them as suggested above:
> 
> sudo apt-get install emacs-nox emacs-bin-common=1:25.2+1-
> 11+unreleased1 emacs-common=1:25.2+1-11+unreleased1

What about fixing the bugs to make emacs building (again)? Current
version in sid is: 1:26.1+1-3.3. ironforge has been building that
version for 19.5 days now.

Re: python3.8 ftbfs on the Hurd and KFreeBSD

[Svante Signell]

On Fri, 2019-08-02 at 02:33 +0200, Samuel Thibault wrote:
> Hello,
> 
> Matthias Klose, le lun. 08 juil. 2019 13:37:00 +0200, a ecrit:
> > The hurd-i386 and kfreebsd-* builds had some missing symbols, seen
> > in ...

> Here is a mach implementation for the native thread ids, and the
> patch to enable the symbol on hurd-any too.

I had prepared the following patch:

Index: python3.8-3.8.0~b2/Python/thread_pthread.h
===
--- python3.8-3.8.0~b2.orig/Python/thread_pthread.h
+++ python3.8-3.8.0~b2/Python/thread_pthread.h
@@ -22,6 +22,8 @@
 #   include   /* thread_self() */
 #elif defined(__NetBSD__)
 #   include  /* _lwp_self() */
+#elif defined(__GNU__) || defined(__FreeBSD_kernel__)
+#   include  /* pthread_self() */
 #endif
 
 /* The POSIX spec requires that use of pthread_attr_setstacksize
@@ -338,6 +340,9 @@ PyThread_get_thread_native_id(void)
 #elif defined(__NetBSD__)
 lwpid_t native_id;
 native_id = _lwp_self();
+#elif defined(__GNU__) || defined(__FreeBSD_kernel__)
+pthread_t native_id;
+native_id = pthread_self();
 #endif
 return (unsigned long) native_id;
 }

What's wrong with that patch compared to your (excluding the kFreeBSD
stuff)?

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Wed, 2019-06-26 at 12:14 -0300, elementar wrote:
> Where do I find kFreeBSD-amd64 isos, from testing or unstable?
> 
> Em sex, 12 de abr de 2019 17:49, Joerg Jaspert 
> escreveu:
> > Hi
> > 
> > back in August 2018 we discussed architecture inclusion into
> > unstable/experimental.
> > 
> > Today we had our regular FTPMaster meeting and discussed hurd and
> > both kfreebsd architecture and decided to remove them from unstable
> > and experimental 2 weeks from now.

You can find an old image you can upgrade from at:
https://people.debian.org/~jrtc27/debian-unofficial-kfreebsd-amd64-NETINST-1.iso

and then use (selected parts of) for sources.list for upgrades:
deb http://ftp.ports.debian.org/debian-ports sid main
deb http://ftp.ports.debian.org/debian-ports unreleased main
deb-src http://ftp.ports.debian.org/debian-ports unreleased main
deb http://ftp.ports.debian.org/debian-ports experimental main
deb-src http://ftp.se.debian.org/debian/ sid main contrib non-free

Re: hurd-i386 switched to debian-ports archive

[Svante Signell]

On Mon, 2019-04-22 at 19:53 +0200, Samuel Thibault wrote:
> Samuel Thibault, le lun. 22 avril 2019 19:37:35 +0200, a ecrit:
> > with the following sources.list entries:
> > 
> > deb http://ftp.ports.debian.org/debian-ports sid main
> > deb http://ftp.ports.debian.org/debian-ports experimental main
> 
> Note that the dbgsym packages are there too. The deb-src entries
> should not be changed, they will still be on the main archive.

And where are the sources for the Hurd-specific packages, e.g.
x86info except at 
http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/x/x86info/
?

(I don't have another example right now but you know what I mean...)

Thanks!

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Sun, 2019-04-14 at 11:33 +0200, Samuel Thibault wrote:
> Svante Signell, le dim. 14 avril 2019 10:52:19 +0200, a ecrit:
> > 
> > I cannot follow your reasoning here, e.g. at  
> > http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/glibc/
> > there are no source packages, only binary ones. How would I ever
> > get
> > hold of your source changes to build that version of glibc?
> 
> That version of glibc is in the "unreleased" distribution, not
> "unstable". See the main/binary-hurd-i386/Packages.gz files of the
> different distribs:
> 
> http://ftp.ports.debian.org/debian-ports/dists/

Yes, the glibc version is there, but where are the sources, i.e.
the *2.27.orig.tar.*, *2.27-8+hurd.1.debian.tar.* and *2.27-
8+hurd.1.dsc files?

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Sun, 2019-04-14 at 10:29 +0200, Samuel Thibault wrote:
> Svante Signell, le dim. 14 avril 2019 10:23:42 +0200, a ecrit:
> > One problem with debian-ports is that the sources, most interesting
> > the
> > *.debian.tar.* files. You cannot any longer add deb-src to the
> > sources.list and apt-get source ; dpkg-buildpackage ...
> > 
> > As I understand it the sources have to be added to where the binary
> > package are e.g. 
> > http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/gdb/
> >  and
> > the way to build from source is dget 
> > http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/gdb/gdb_7.12-6.1+pie.dsc
> > etc.
> 
> For unstable/experimental packages, one can simply use the main
> archive deb-src line, debian-ports only needs to host the binaries.

I cannot follow your reasoning here, e.g. at  
http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/glibc/
there are no source packages, only binary ones. How would I ever get
hold of your source changes to build that version of glibc?

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Sat, 2019-04-13 at 12:59 +0200, Aurelien Jarno wrote:
> On 2019-04-13 12:37, Samuel Thibault wrote:
> > Hello,
> > 
> > Before even thinking about uploading the hurd-i386 and kfreebsd
> > unstable/experimental packages to debian-ports, is there enough
> > disk space for this on it?  It seems my DD account is not enabled
> > on ftp.ports.debian.org so I can't check myself.
> 
> Disk space should be fine to import hurd-i386. There might be enough
> space to also import kfreebsd-*, but only for the short term. As the
> number of packages in unstable is increasing regularly, we will need
> to get more disk space soon, probably before the buster release.
> Unfortunately the disk space on the ganeti cluster where the
> porta.d.o VM is hosted is also getting low.
> 
> The CPU and RAM is however probably to low to add the 3 ports, unless
> wereduce the number of archive-install run per day (currently running
> every 6 hours).

One problem with debian-ports is that the sources, most interesting the
*.debian.tar.* files. You cannot any longer add deb-src to the
sources.list and apt-get source ; dpkg-buildpackage ...

As I understand it the sources have to be added to where the binary
package are e.g. 
http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/gdb/ and
the way to build from source is dget 
http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/g/gdb/gdb_7.12-6.1+pie.dsc
etc.

Is there space in ftp.ports.debian.org also for the source packages?

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Svante Signell]

On Sat, 2019-04-13 at 10:58 +0200, Samuel Thibault wrote:
> Joerg Jaspert, le sam. 13 avril 2019 10:24:53 +0200, a ecrit:
> > On 15371 March 1977, Samuel Thibault wrote:
> > 
> 
> Well, it's very odd that a team decision is suddenly made with a
> two-week effect without asking whether the schedule will be fine.
> 
> I guess I have to explicitly confirm here that yes, I know that the
> decision _whether_ to move is not sudden. Again, I'm talking about
> the schedule here. Asking a Debian team to do something time-
> consuming within a two-week timeframe in the middle of the full
> freeze, really...
> 
> I won't have the time to discuss with ftpmaster about it in the
> coming days anyway.

Samuel,

Please give up on Debian. They clearly have no interest in anything
non-linux or non-systemd, that is fully clear. Let's make a joint
effort to make a Guix release of Hurd (and kFreeBSD) happen. Or, if you
still want to continue using apt-style distributions, join Devuan.
Please, don't support the non-universal OS movement driven by Debian
people!

Thanks!

Re: [!!] Do not upgrade coreutils to 8.30-2

[Svante Signell]

On Wed, 2019-02-27 at 13:36 -0800, Samuel Thibault wrote:
> Hello,
> 
> In version 8.30-2, a fix was added to coreutils to make it use
> renameat2, but it happens that it wasn't supported in hurd's glibc,
> and thus the "mv" command would fail completely. I have pushed a fix
> to glibc, to be uploaded when Aurelien is finished with the things he
> wanted to fix.

Thanks! I've been struggling with that problem the whole day and
evening!

mkdir FOO; mv FOO BAR; mv: cannot move 'FOO' to a subdirectory of
itself, 'BAR'

Re: Bug#920618: initscripts: errors with /dev/shm on Hurd

[Svante Signell]

On Sat, 2019-02-02 at 06:41 +0100, Samuel Thibault wrote:
> Svante Signell, le sam. 02 févr. 2019 01:07:48 +0100, a ecrit:
> > 
> > I'm having a look :)
> 
> Thanks! :)

Seem to work fine, after removing the broken links /run/shm -> /dev/shm and
/dev/shm -> /run/shm. So maybe the Hurd now removed patch run.sh should check if
/run/shm exists, and if it does remove it. However, that depends on which script
runs first /lib/init/mount-functions.sh in initscripts or /etc/hurd/run run by
/hurd/init in Hurd.

I don't boot with a serial console so I might have missed som output, e.g. the
brightness issue.

Comment on glibc2.28: Re: [PATCH glibc] Add file record locking support

[Svante Signell]

On Thu, 2015-01-08 at 12:40 +0100, Svante Signell wrote:
> Hi, 
> 
> Attached is the patch adding support for file record locking in glibc,
> as implemented in Hurd by Neal Walfield and others. This patch should be
> applied after the corresponding hurd patch series in case glibc and hurd
> are not built simultaneously.

With the new version of glibc (2.28) the new file f-setlk.c (and f-setlk.h) is
introduced. This makes the file-record-locking patch for glibc very cumbersome.
Stuff already in fcntl.c now has to be redefined in that file, in order to add
the file record locking part.

Old patch:
fcntl.diff.old

New patch:
fcntl.diff.new

Please revert the patch introducing that file.
sysdeps/mach/hurd/Changelog
2018-12-01  Svante Signell 

* f_setlk.c: Add support for file-record-lock RPC fixing posix
  file locking using the flock64 version of struct
  flock. Replace the __flock() call with __file_record_lock()

* fcntl.c: Code moved to f_setlk.c. Don't include 

* fcntl.h: Removed: Patch not needed any longer.

2014-08-21  Svante Signell 

* f_setlk.c: Add support for file-record-lock RPC fixing posix
  file locking using the flock64 version of struct
  flock. Replace the __flock call with __file_record_lock

* fcntl.c: Add support for file-record-lock RPC fixing posix
  file locking using the flock64 version of struct flock.

* bits/fcntl.h: Since MIG cannot mix 32 bit and 64 bit
  integers define unique numbers for F_GETLK64, F_SETLK64 and
  F_SETLKW64 to prepare for a flock64 implementation of file
  record locking in hurd: fixed in glibc-2.28.

Index: glibc-2.28-1.1/sysdeps/mach/hurd/fcntl.c
===
--- glibc-2.28-1.1.orig/sysdeps/mach/hurd/fcntl.c
+++ glibc-2.28-1.1/sysdeps/mach/hurd/fcntl.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include   /* XXX for LOCK_* */
 #include "f_setlk.h"
 
 /* Perform file control operations on FD.  */
Index: glibc-2.28-1.1/sysdeps/mach/hurd/f_setlk.c
===
--- glibc-2.28-1.1.orig/sysdeps/mach/hurd/f_setlk.c
+++ glibc-2.28-1.1/sysdeps/mach/hurd/f_setlk.c
@@ -18,21 +18,29 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
-/* XXX
-   We need new RPCs to support POSIX.1 fcntl file locking!!
-   For the time being we support the whole-file case only,
-   with all kinds of WRONG WRONG WRONG semantics,
-   by using flock.  This is definitely the Wrong Thing,
-   but it might be better than nothing (?).  */
 int
 __f_setlk (int fd, int type, int whence, __off64_t start, __off64_t len, int 
wait)
 {
   int cmd = 0;
-
+  error_t err;
+  struct hurd_fd *d;
+  int result;
+  __pid_t pid = -1;
+  struct flock64 *fl64 = NULL;
+
+  fl64->l_type = type;
+  fl64->l_whence = whence;
+  fl64->l_start = start;
+  fl64->l_len = len;
+  fl64->l_pid = pid;
+  
   switch (type)
 {
 case F_RDLCK: cmd = LOCK_SH | __LOCK_ATOMIC; break;
@@ -78,5 +86,12 @@ __f_setlk (int fd, int type, int whence,
   return -1;
 }
 
-  return __flock (fd, cmd);
+  d = _hurd_fd_get (fd);
+
+  if (d == NULL)
+return __hurd_fail (EBADF);
+
+  err = HURD_FD_PORT_USE (d, __file_record_lock (port, cmd, fl64));
+  result = err ? __hurd_dfail (fd, err) : 0;
+  return result;
 }
sysdeps/mach/hurd/Changelog
2014-08-21  Svante Signell 

* fcntl.c: Add support for file-record-lock RPC fixing posix
  file locking using the flock64 version of struct flock.

* bits/fcntl.h: Since MIG cannot mix 32 bit and 64 bit
  integers define unique numbers for F_GETLK64, F_SETLK64 and
  F_SETLKW64 to prepare for a flock64 implementation of file
  record locking in hurd.

Index: glibc-2.25-1.1/sysdeps/mach/hurd/bits/fcntl.h
===
--- glibc-2.25-1.1.orig/sysdeps/mach/hurd/bits/fcntl.h
+++ glibc-2.25-1.1/sysdeps/mach/hurd/bits/fcntl.h
@@ -163,9 +163,18 @@
 # define F_GETOWN  5   /* Get owner (receiver of SIGIO).  */
 # define F_SETOWN  6   /* Set owner (receiver of SIGIO).  */
 #endif
+#ifdef __USE_FILE_OFFSET64
+# define   F_GETLK F_GETLK64
+# define   F_SETLK F_SETLK64
+# define   F_SETLKWF_SETLKW64
+#else
 #defineF_GETLK 7   /* Get record locking info.  */
 #defineF_SETLK 8   /* Set record locking info 
(non-blocking).  */
 #defineF_SETLKW9   /* Set record locking info (blocking).  
*/
+#endif
+#defineF_GETLK64   10  /* Get record locking info.  */
+#defineF_SETLK64   11  /* Set record locking info 
(non-blocking).  */
+#defineF_SETLKW64  12  /* Set record locking info (blocking).  
*/
 
 #ifdef __USE_XOPEN2K8
 

Re: Debian Buster release to partially drop non-systemd support

[Svante Signell]

On Fri, 2018-10-19 at 09:37 +0200, Philipp Kern wrote:
> On 2018-10-19 08:39, Narcis Garcia wrote:
> > El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit:
> > > For my packages I can state that I do not have a single machine
> > > which is not using systemd - and to be honest - I won't waste my
> > > time in writing/debugging initscripts.
> > 
> > Most of people want to use a GNU operating system.
> > You particularly seem to only need a Systemd operating system.
> 
> So what you want is https://www.gnu.org/software/shepherd/?

Yes please, is it packaged for Debian already? As Debian is/was the
Universal Operating System?

Re: Debian Buster release to partially drop non-systemd support

[Svante Signell]

On Mon, 2018-10-15 at 17:06 +0200, Samuel Thibault wrote:
> 
> It's a matter of people subscribing to the
> pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there,
> I
> don't see why anything heavier would be needed.

I thought alioth was no more, but maybe the mailing list remains?

Re: Re-evaluating architecture inclusion in unstable/experimental

[Svante Signell]

On Mon, 2018-09-03 at 01:07 +0200, Samuel Thibault wrote:
> 
> > So has the debian patch been submitted in #900240 upstream by you or Petter
> > Reinholdtsen yet? I don't believe so!
> 
> I don't think so either, it'd be marked forwarded. That doesn't mean you
> can't help with it.

Regardless who is submitting patches upstream, two problem remains:
1) The delay until upstream makes a new release.
2) The delay until the Debian Maintainer creates an updated package from that
release (if ever). Example: emacs26

And how many maintainers do cherry-pick patches accepted upstream, very few :( 

Re: Re-evaluating architecture inclusion in unstable/experimental

[Svante Signell]

On Sun, 2018-09-02 at 19:46 +0200, Samuel Thibault wrote:
> Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit:
> > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:
> > 
> > > 
> > > > The statistics and graphs available on the debian-ports page[1] may
> > > > provide some objective statistics or reflection on the actual
> > > > suitability of your architecture's continued inclusion.
> > > >  [1]: https://buildd.debian.org/stats/
> > > 
> > > Such statistics are really difficult to get any real conclusion from.
> > > Sometimes 10% packages are missing just for one tricky nonLinux-specific
> > > issue in one package.
> > 
> > Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
> > It does not even have to be tricky.
> 
> If it's not tricky, a NMU should be able to fix it easily.

I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this
issue and you both said it was not possible to NMU cmake, even if you are both
DD's. See bugs 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905140
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900240
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905138

I think that the power of a package maintainer is far too big, making it
possible to reject/ignore important and other bugs, especially with patches, for
non-released architectures (and effectively block NMUs).

I think the next step would be to bring the responsibilities and commitments of
a Package Maintainer to the TC, in addition to the full control of everything
related to that package. Maybe the recent salvaging of packages could be helpful
in the future regarding this problem.

Re: Re-evaluating architecture inclusion in unstable/experimental

[Svante Signell]

On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:

> 
> > The statistics and graphs available on the debian-ports page[1] may
> > provide some objective statistics or reflection on the actual
> > suitability of your architecture's continued inclusion.
> >  [1]: https://buildd.debian.org/stats/
> 
> Such statistics are really difficult to get any real conclusion from.
> Sometimes 10% packages are missing just for one tricky nonLinux-specific
> issue in one package.

Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
It does not even have to be tricky. For kfreebsd the patch(es) is attached
below!
Index: cmake-3.11.2/bootstrap
===
--- cmake-3.11.2.orig/bootstrap
+++ cmake-3.11.2/bootstrap
@@ -1352,7 +1352,7 @@ else
   libs="${libs} -ldl -lrt"
   ;;
 *BSD*)
-  libs="${libs} -lkvm"
+  libs="${libs} -lkvm -lfreebsd-glue"
   ;;
 *SunOS*)
   # Normally libuv uses '-D_XOPEN_SOURCE=500 -std=c90' on Solaris 5.10,
--- a/debian/control	2018-05-19 10:51:17.0 +0200
+++ b/debian_control	2018-07-29 17:38:11.272777000 +0200
@@ -15,6 +15,7 @@
librhash-dev,
libuv1-dev (>= 1.10),
procps [!hurd-any],
+   freebsd-glue [kfreebsd-any],
python3-sphinx,
qtbase5-dev ,
zlib1g-dev

Re: webrtc-audio-processing 0.3 is unbuildable on non-linux archs

[Svante Signell]

On Sun, 2016-07-03 at 13:00 -0300, Felipe Sateler wrote:
> Dear Hurd and BSD porters,
> 
> The latest upload of webrtc-audio-processing in unstable does not
> build on non-linux archs. This new version is required by pulseaudio
> 9, so it will not build as well.
> 
> My guess is that the build failures are only due to lack of
> appropriate checks in configure (ie, not any real incompatibility).
> If the porters could prepare such a patch, I'm more than happy to
> apply locally and forward upstream. I currently lack time to try to
> do this myself.

There is a patch for that package available already:
See #829570 from 04 Jul 2016.

Thanks!

Re: lwip is in

[Svante Signell]

On Mon, 2018-06-11 at 23:53 +0200, Samuel Thibault wrote:
> Svante Signell, le lun. 11 juin 2018 23:30:23 +0200, a ecrit:
> > 
> > Building from source fails with:
> > make[3]: *** No rule to make target 'lwip/priv/tcpip_priv.h',
> > needed by
> > 'lwip-util.o'.  Stop.
> > make[3]: Leaving directory '/home/srs/DEBs/hurd/hurd-
> > 0.9.git20180603-
> > 2.1/build-udeb/lwip'
> > 
> > Any ideas? That file does not exist :(
> 
> Use the latest version of liblwip-dev, -2

dpkg -l liblwip-dev
ii  liblwip-dev:hu 2.0.3-1  hurd-i386small implementation of
the TCP/...

find /usr/include/lwip/ -name 'tcpip*'
/usr/include/lwip/lwip/tcpip.h

No tcpip_priv.h :(

Re: lwip is in

[Svante Signell]

On Mon, 2018-06-11 at 23:22 +0200, Samuel Thibault wrote:
> Hello,
> 
> Since the lwip package got accepted, I reuploaded the hurd package
> with
> the additional dependency, which thus brings us a new translator,
> /hurd/lwip, which you can start playing with!

Building from source fails with:
make[3]: *** No rule to make target 'lwip/priv/tcpip_priv.h', needed by
'lwip-util.o'.  Stop.
make[3]: Leaving directory '/home/srs/DEBs/hurd/hurd-0.9.git20180603-
2.1/build-udeb/lwip'

Any ideas? That file does not exist :(

Re: heimdal: FTBFS on hurd-i386

[Svante Signell]

Sorry, sent to the wrong email address. Now you know about this bug report
anyway ;)

On Fri, 2018-05-25 at 21:25 +0200, Svante Signell wrote:
> Source: heimdal
> Version: 1.7.5.0+dfsg-1
> Severity: important
> Tags: patch
> User: debian-hurd@lists.debian.org
> Usertags: hurd
> 
> Hi,
> 
> Currently heimdal fails to build on GNU/Hurd due to usage of MAXHOSTNAMELEN
> where it is not defined. The attached patch solves this problem by using
> MaxHostNameLen instead. This patch could maybe be integrated with the already
> existing patch: 041_hurd_maxhostnamelen solving the same kind of issues.
> 
> 
> Thanks!

heimdal: FTBFS on hurd-i386

[Svante Signell]

Source: heimdal
Version: 1.7.5.0+dfsg-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hi,

Currently heimdal fails to build on GNU/Hurd due to usage of MAXHOSTNAMELEN
where it is not defined. The attached patch solves this problem by using
MaxHostNameLen instead. This patch could maybe be integrated with the already
existing patch: 041_hurd_maxhostnamelen solving the same kind of issues.


Thanks!
--- a/kdc/kx509.c.orig	2017-03-14 22:02:21.0 +0100
+++ b/kdc/kx509.c	2018-05-25 21:06:09.0 +0200
@@ -331,7 +331,7 @@
 krb5_boolean bret;
 krb5_principal principal = NULL;
 char *expected = NULL;
-char localhost[MAXHOSTNAMELEN];
+char localhost[MaxHostNameLen];
 
 ret = gethostname(localhost, sizeof(localhost) - 1);
 if (ret != 0) {

Re: Bug#891812: util-linux: FTBFS on hurd-i386: calls pty_init_slave unconditionally

[Svante Signell]

On Mon, 2018-05-21 at 22:45 +0200, Andreas Henriksson wrote:
> On Thu, Mar 01, 2018 at 01:55:22AM +0100, Samuel Thibault wrote:
> > Aaron M. Ucko, on mer. 28 févr. 2018 19:47:40 -0500, wrote:
> > >   login-utils/su-common.c:1427:3: warning: implicit declaration of
> > > function 'pty_init_slave'; did you mean 'initstate'? [-Wimplicit-function-
> > > declaration]
> > >   [...]
> > >   ./login-utils/su-common.c:1427: undefined reference to `pty_init_slave'
> > 
> > IIRC I got a fix commited upstream
> 
> Your fix should now be part of the latest upload (2.32-0.1),
> unfortunately there's another problem now.
> 
> Any chance you can test if by any chance the following upstream commit
> fixes the (libmount-related) build issue on hurd (or if additional
> upstream fixing is needed for hurd)?
> 
> https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=061d
> 1a51097c3c025ff46173f10aa135f9a610d4
> 
> (FYI, I've just committed making rfkill linux-any to git.)

Of course a build of util-linux on GNU/Hurd will fail :( Hurd does _not_ have
the sys/mount.h file, and functionality is elsewhere. Typical of Redhat people
to only think about Linux with systemd (and MS)

Request for kFreeBSD (and Hurd) porters

[Svante Signell]

Hi all,
Cc: debian-devel

The Debian GNU/kFreeBSD port recently obtained a buildd building
packages for the sid distribution, kamp. Thank you very much for your
effort making this happening jrtc27 :) The buildd is now soon up-to-
date building packages being outdated. As you know GNU/Hurd packages
are also built for sid, having two buildds: ironforge and mahler.

Now is the time to submit patches for failing packages. In the
beginning this will be low hanging fruit, like patches not applying for
glibc, a line missing one entry in the symbols file for mpfr4, etc.

GNU/kFreeBSD and GNU/Hurd share many common interests. Mainly most of
the build-related problems are due to non-portable software, i.e. Linux
only designs. Please help us out by submitting bugs with patches to
sub...@debian.org to make kFreeBSD a first class citizen too, in
addition to GNU/Hurd.

Thanks!

Re: Samuel: Do you have permission to _enable_ the gccgo patches again?

[Svante Signell]

On Tue, 2018-03-27 at 00:49 +0200, Samuel Thibault wrote:
> Svante Signell, on lun. 26 mars 2018 19:50:58 +0200, wrote
> 
> Well, a month is a long time indeed. I guess he needed to move forward,
> so he dropped; no big deal.

Yes it is a big deal. If somebody spends numerous (spare time, unpaid) hours
porting gccgo to Hurd and that work is thrown away then this _is_ a big deal.

> But we don't care about previous versions but the last version.

See below.

> My point is: no, it's not obvious to just commit and forget.  While it
> *is* obvious to just fix what's currently there.  If you don't see why
> that commit was a move forward concerning Debian, please do check its
> consequences and think about it.

??

> > As I wrote in that bug report, all needed patches are there. And as the bug
> > report says: gcc-8 (8-8-20180321-1 and earlier) was successfully built.
> 
> But that's not the latest version, as you said it, even.

??
Latest released Debian version of gcc-8 is 8-8-20180321-1, see
https://buildd.debian.org/status/package.php?p=gcc-8=sid

Re: Samuel: Do you have permission to _enable_ the gccgo patches again?

[Svante Signell]

On Mon, 2018-03-26 at 19:42 +0200, Samuel Thibault wrote:
> Svante Signell, on lun. 26 mars 2018 19:20:04 +0200, wrote:
> > 
> > What is really wrong is that Matthias Klose removed the Hurd patches.
> 
> Sure, but see what he wrote in the changlog: he found the patches
> "unmaintained", i.e. I guess he got an issue with it, and couldn't
> afford spending the time to fix it, and thus just dropped them. That's
> only normal for something that hasn't been upstreamed so far.

Me being AFK for a month gives him reason to claim the the patches are un-
maintined. Not nice :(

> > Adding them back is a piece of cake for you (or him), see #894080.
> 
> It's not: it means sorting out from your three mails what actually needs
> checking in, understanding what you mean by 
> “
> Finding the reverting commit and applying it
> gcc.git-b12c2c48c2c6aa1db9e6c50f6b26330d9caf.patch gcc+gccgo builds
> fine again.
> ”
> whether it's something that needs to be done on top of the patches,
> scratching one's head whether “I will report the build status when the
> latest version is built. (an eventually provide updated patches)” means
> one should wait for that to happen etc.

All this stuff is from earlier mails. Additionally the versions built with the
patches were reported.

> Then eventually try to build the whole thing, possibly realize it
> doesn't actually build, etc. etc. Not a piece of cake, really.

As I wrote in that bug report, all needed patches are there. And as the bug
report says: gcc-8 (8-8-20180321-1 and earlier) was successfully built.

Samuel: Do you have permission to _enable_ the gccgo patches again?

[Svante Signell]

Hi Samuel,

I just saw:
https://anonscm.debian.org/viewvc/gcccvs?view=revision=10084

This is really a large step BACK: Since you could issue that commit to _disable_
gccgo for Hurd, what about committing to _enable_ gccgo for Hurd instead. I just
filed a bug for gcc-8 to build gccgo again: https://bugs.debian.org/cgi-bin/bugr
eport.cgi?bug=894080

Thanks!

Re: [Freewx-maint] Bug#892237: wxpython4.0: FTBFS on hurd-i386: wx*FSW* undeclared

[Svante Signell]

On Tue, 2018-03-06 at 23:48 -0500, Scott Talbert wrote:
> On Tue, 6 Mar 2018, Aaron M. Ucko wrote:
> 
> >  ../../../../sip/cpp/sip_corecmodule.cpp:15517:51: error:
> > '::wxFSW_EVENT_ACCESS' has not been declared
> >  [...]
> >  ../../../../sip/cpp/sip_corecmodule.cpp:15529:55: error:
> > '::wxFSW_WARNING_OVERFLOW' has not been declared
> >  ../../../../sip/cpp/sip_corecmodule.cpp:17889:31: error: 'wxEVT_FSWATCHER'
> > was not declared in this scope
> > 
> > Could you please take a look?
> 
> Yep, it looks like this is because the wxwidgets3.0 build doesn't have 
> wxFileSystemWatcher support, which is because it couldn't find inotify. 
> It looks like inotify isn't available on Hurd?

Correct, inotify is a Linux only construct.

>From inotify(7):
CONFORMING TO
   The inotify API is Linux-specific.

Re: Future of kFreeBSD in Debian unstable

[Svante Signell]

On Fri, 2018-03-02 at 16:19 +, James Clarke wrote:
> On 2 Mar 2018, at 00:12, Svante Signell <svante.sign...@gmail.com>
> wrote:
> > Hi,
> > 
> 
> Hi Svante,
> Firstly thanks again for the VM offer. The main issue now is the lack
> of porters, as there needs to be at least one person willing to spend
> time checking on the buildds and, since this is a non-Linux
> architecture, maintaining the kernel-related packages. Given that
> it's amd64 and i386, there shouldn't really be many GCC/binutils
> toolchain issues to worry about which can plague less-popular ports,
> but there is then the issue of teaching language runtimes how to work
> on kFreeBSD.
> 
> As has been mentioned before, the sensible thing seems to be to move
> over to debian-ports as well.

Is this really necessary, I'm hosting a buildd for GNU/Hurd and don't
see any problems with that?

> Yes, mini-dak has a few annoyances which are a pain when they occur,
> but they're manageable, and probably a lot easier than having to
> have a DD sign all uploads (as would be the case if it stayed on ftp-
> master). Moreover, I've been working on patching dak to work for
> debian-ports, so hopefully we will be switching over to that in the
> not too distant future once it supports everything we need.

What would be gained by moving to debian-ports??

> As far as my time goes, I am willing to help setup and maintain
> buildd infrastructure for the port, but sadly I can't set aside time
> to be a porter, though that may well change in the summer once this
> academic year is over. If anyone who wants to see this port continue
> has time they can regularly devote to kFreeBSD porting, no matter how
> little, please let us know, as without you the port will likely
> suffer.

As far as the buildd goes, please let me know your wishes in a private
mail and I'll set up a VM for you, size, partitions, software for
me/you to install, etc

   I. I already havea few kfreebsd images, but they are not upgraded for
  some time. Regarding bug fixing, many bugs (except PATH_MAX ones)
  appearing for GNU/Hurd also appear for GNU/kFreeBSD. So, I think it
  is rally nice to have a sister architecture to Hurd pushing
  upstreams to really be writing portable code.

Thanks!

Re: Need help about choosing MSc thesis

[Svante Signell]

On Fri, 2017-12-01 at 16:57 +0330, behnam mohammad karimi wrote:
> Hi
> I want work on HURD for my MSc thesis. So I want some paper about HURD or
> kernel development, but I can't find any paper  
> Can u help me? Do u have any paper? (2015 or later)

Hi,

There is a rather recent Bachelors thesis from 2009, see
https://lists.gnu.org/archive/html/bug-hurd/2009-01/msg7.html
and an ongoing Masters thesis by Joan Lledó from 2017, see
https://lists.gnu.org/archive/html/bug-hurd/2017-10/msg00019.html
as a follow-up of his GSoC 2017 work, see
https://lists.gnu.org/archive/html/bug-hurd/2017-03/msg00035.html

HTH

Re: wget: FTBFS on hurd-i386

[Svante Signell]

Cc: debian-hurd

Another ping, almost two months later.


On Sun, 2017-08-27 at 10:30 +0200, Svante Signell wrote:
> found 858995 1.19.1-4
> thanks
> 
> ping again
> 
> The upstream patch has already been added to grep and findutils
> (#867120).
> 

Re: How to identify "running on a Hurd system"?

[Svante Signell]

On Thu, 2017-08-24 at 15:12 -0600, AlexLikeRock wrote:
> 
> On August 24, 2017 2:53:43 PM GMT-06:00, Christoph Biedl  @manchmal.in-ulm.de> wrote:
> > Samuel Thibault wrote...
> > 
> > > It's not vague :)
> > > 
> > > GNU/Hurd is *the* GNU system, no other system is supposed to make
> > > uname -s return "GNU".
> > 
> > That's fairly straight. So I'll blame you if the code should ever
> > break

> I agree, GNU/hurd its simple original "GNU"

GNU/hurd -> GNU/Hurd is the correct spelling. Please note :)

Re: How to identify "running on a Hurd system"?

[Svante Signell]

On Sat, 2017-08-19 at 17:59 +0200, Narcis Garcia wrote:
> El 19/08/17 a les 15:57, Samuel Thibault ha escrit:
> > 
> > It's not vague :)
> > 
> > GNU/Hurd is *the* GNU system, no other system is supposed to make
> > uname -s return "GNU".

> I believed that GNU was an operating system and Hurd a kernel.
> Why isn't it?

Well, GNU is the GNU os. The kernel consists of gnumach and Hurd
servers running on top of that kernel.

Take a look at
uname -a
GNU hurd-sid 0.9 GNU-Mach 1.8+git20170609-486-dbg/Hurd-0.9 i686-AT386
GNU
uname -s (kernel-name) This might be misleading
GNU
uname -r (kernel-release)
0.9
uname -v (kernel version)
GNU-Mach 1.8+git20170609-486-dbg/Hurd-0.9
uname -o (operating system)
GNU

On GNU/Linux you have:
uname -a
Linux z97-4790k 4.9.0-2-amd64 #1 SMP Debian 4.9.10-1 (2017-02-17)
x86_64 GNU/Linux
uname -s
Linux
uname -r
4.9.0-2-amd64
uname -v
#1 SMP Debian 4.9.10-1 (2017-02-17)
uname -o
GNU/Linux

Bug#870981: netdde: should netdde be removed from unstable?

[Svante Signell]

On Sun, 2017-08-06 at 09:50 -0400, Lucas Nussbaum wrote:
> Source: netdde
> User: debian...@lists.debian.org
> Usertags: qa-removals-post-stretch
> 
> Hi,
> 
> Following a discussion[1] on the debian-qa@ mailing list on packages that
> missed both jessie and stretch, I am proposing the removal of this package
> from
> unstable, because:
> 
>   it was in unstable at the time of the stretch freeze
> but wasn't part of stretch
> AND
>   it was in unstable at the time of the jessie freeze
> but it wasn't part of jessie
> AND
>   it is still not in testing
> AND
>   it was not uploaded since the beginning of 2017.
> 
> If you disagree and think that this package should remain in unstable, feel
> free to just close this bug.
> 
> If this bug is still open one month from now (on 2017-09-06), it will be
> turned
> into a removal request, using:
> 
>   reassign -1 ftp.debian.org
>   retitle -1 RM: netdde -- RoQA; missed both jessie and stretch
>   thanks
> 
> - Lucas, for the QA team.
> 
> [1] https://lists.debian.org/debian-qa/2017/07/msg00021.html
> 

The same applies as for bug #870985. It is currently used for hurd-i386 only,
but is essential for that architecture. Please close this bug too.

Re: Devuan GNU/Hurd

[Svante Signell]

On Tue, 2017-07-11 at 19:14 +0200, Samuel Thibault wrote:
> Narcis Garcia, on mar. 11 juil. 2017 18:52:04 +0200, wrote:
> > As Devuan GNU+Linux is a fork of Debian without systemd, I suppose
> > it can be an easier base to work that current Debian GNU/Hurd:
> > devuan.org
> 
> I'd say not so much. Most of the work required in Debian doesn't come
> so much from the presence of systemd.
> 
> And the mandatory-systemd issues should be forwarded upstream anyway,
> so the downstream doesn't really matter :)

I'll take the bait. Let's go for a Devuan GNU/Hurd :)
(Even if it is not infested by systemd, it's not available)

And in the not so far future we will hopefully use GuixSD and Shepherd
:)

Re: gputils: FTBFS on hurd-i386 (for review)

[Svante Signell]

On Tue, 2017-04-04 at 02:25 +0200, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2017-03-31 at 15:13:03 +0200, Svante Signell wrote:
> > Source: gputils
> > Version: 1.4.0-0.1
> > Severity: important
> > Tags: patch
> > User: debian-hurd@lists.debian.org
> > Usertags: hurd
> > gputils currently FTBFS on GNU/Hurd due to PATH_MAX not being defined. The
> > attached patch fixes this issue by allocating strings dynamically and remove
> > them when not needed any more.

Gullem,

Thank you for the review. Attached is an updated patch. Is it OK now? I still
have to check return values of snprintf and realloc and maybe also switch to
using alloca (not POSIX though).Index: gputils-1.4.0/gplink/gplink.c
===
--- gputils-1.4.0.orig/gplink/gplink.c
+++ gputils-1.4.0/gplink/gplink.c
@@ -321,17 +321,23 @@ gplink_open_coff(const char *name)
   gp_object_type *object;
   gp_archive_type *archive;
   FILE *coff;
-  char file_name[PATH_MAX + 1];
-
-  strncpy(file_name, name, sizeof(file_name));
+  char *file_name = NULL;
+  int len = 0;
 
+  file_name = strdup(name);
+  if (file_name == NULL) {
+perror(name);
+exit(1);
+  }
   coff = fopen(file_name, "rb");
   if ((coff == NULL) && (strchr(file_name, PATH_CHAR) == 0)) {
 /* If no "/" in name, try searching include pathes. */
 int i;
 
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s" COPY_CHAR "%s", state.paths[i], name);
+  len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s" COPY_CHAR "%s", state.paths[i], name);
   coff = fopen(file_name, "rb");
 
   if (coff != NULL) {
@@ -341,6 +347,8 @@ gplink_open_coff(const char *name)
   }
 
   if (coff == NULL) {
+if (file_name)
+  free(file_name);
 perror(name);
 exit(1);
   }
@@ -368,6 +376,8 @@ gplink_open_coff(const char *name)
   default:
 assert(0);
   }
+  if(file_name)
+free(file_name);
 }
 
 static void
Index: gputils-1.4.0/gplink/lst.c
===
--- gputils-1.4.0.orig/gplink/lst.c
+++ gputils-1.4.0/gplink/lst.c
@@ -35,9 +35,9 @@ static gp_section_type *line_section;
 static void
 open_src(const char *name, gp_symbol_type *symbol)
 {
-  char file_name[PATH_MAX + 1];
+  char *file_name = NULL;
   struct list_context *new = malloc(sizeof(*new));
-  int i;
+  int i, len;
 
   assert(name != NULL);
 
@@ -45,20 +45,28 @@ open_src(const char *name, gp_symbol_typ
   if (new->f == NULL) {
 /* Try searching include pathes */
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s" COPY_CHAR "%s", state.paths[i], name);
+  len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s" COPY_CHAR "%s", state.paths[i], name);
   new->f = fopen(file_name, "rb");
   if (new->f != NULL) {
 name = file_name;
 break;
   }
 }
+if(file_name)
+  free(file_name);
+
 if (new->f == NULL) {
   /* The path may belong to a build procedure other than this */
   const char *p = strrchr(name, PATH_CHAR);
 
   if (p != NULL) {
+file_name = NULL;
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s%s", state.paths[i], p);
+  len = snprintf(NULL, 0, "%s%s", state.paths[i], p) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s%s", state.paths[i], p);
   new->f = fopen(file_name, "rb");
   if (new->f != NULL) {
 name = file_name;
@@ -67,6 +75,8 @@ open_src(const char *name, gp_symbol_typ
 }
   }
 }
+if(file_name)
+  free(file_name);
   }
 
   if (new->f != NULL) {
Index: gputils-1.4.0/gpasm/scan.l
===
--- gputils-1.4.0.orig/gpasm/scan.l
+++ gputils-1.4.0/gpasm/scan.l
@@ -626,12 +626,13 @@ a'{STR_QCHAR}'   {
 static void
 search_paths(struct source_context *new, const char *name)
 {
-  char tryname[PATH_MAX + 1];
-  int i;
+  char *tryname = NULL;
+  int i, len;
 
   for (i = 0; i < state.path_num; i++) {
-snprintf(tryname, sizeof(tryname),
- "%s" COPY_CHAR "%s", state.paths[i], name);
+len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+tryname = realloc(tryname, len);
+snprintf(tryname, len, "%s" COPY_CHAR "%s", state.paths[i], name);
 new->f = fopen(tryname, "rt");
 
 if (new->f != NULL) {
@@ -639,6 +640,8 @@ search_paths(struct source_context *new,
   break;
 }
   }
+  if (tryname)
+free(tryname);
 }
 
 void

Re: gputils: FTBFS on hurd-i386 (for review)

[Svante Signell]

On Fri, 2017-03-31 at 18:07 +0100, James Clarke wrote:
> On Fri, Mar 31, 2017 at 03:13:03PM +0200, Svante Signell wrote:
> > Source: gputils
> > Version: 1.4.0-0.1
> > Severity: important
> > Tags: patch
> > User: debian-hurd@lists.debian.org
> > Usertags: hurd
...
> >  for (i = 0; i < state.numpaths; i++) {
> > -  snprintf(file_name, sizeof(file_name), "%s" COPY_CHAR "%s",
> > state.paths[i], name);
> > +  len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name);
> 
> This one seems to be missing a + 1.

Thanks James, OK now?
Index: gputils-1.4.0/gplink/gplink.c
===
--- gputils-1.4.0.orig/gplink/gplink.c
+++ gputils-1.4.0/gplink/gplink.c
@@ -321,9 +321,11 @@ gplink_open_coff(const char *name)
   gp_object_type *object;
   gp_archive_type *archive;
   FILE *coff;
-  char file_name[PATH_MAX + 1];
+  char *file_name = NULL;
+  int len = strlen(name) + 1;
 
-  strncpy(file_name, name, sizeof(file_name));
+  file_name = malloc(len);
+  strncpy(file_name, name, len);
 
   coff = fopen(file_name, "rb");
   if ((coff == NULL) && (strchr(file_name, PATH_CHAR) == 0)) {
@@ -331,7 +333,9 @@ gplink_open_coff(const char *name)
 int i;
 
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s" COPY_CHAR "%s", state.paths[i], name);
+  len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s" COPY_CHAR "%s", state.paths[i], name);
   coff = fopen(file_name, "rb");
 
   if (coff != NULL) {
@@ -341,6 +345,7 @@ gplink_open_coff(const char *name)
   }
 
   if (coff == NULL) {
+free(file_name);
 perror(name);
 exit(1);
   }
@@ -353,17 +358,21 @@ gplink_open_coff(const char *name)
 /* read the object */
 object = gp_read_coff(file_name);
 object_append(object, file_name);
+free(file_name);
 break;
   case archive_file:
 /* read the archive */
 archive = gp_archive_read(file_name);
 archive_append(archive, file_name);
+free(file_name);
 break;
   case sys_err_file:
 gp_error("Can't open file \"%s\".", file_name);
+free(file_name);
 break;
   case unknown_file:
 gp_error("\"%s\" is not a valid coff object or archive.", file_name);
+free(file_name);
 break;
   default:
 assert(0);
Index: gputils-1.4.0/gplink/lst.c
===
--- gputils-1.4.0.orig/gplink/lst.c
+++ gputils-1.4.0/gplink/lst.c
@@ -35,9 +35,9 @@ static gp_section_type *line_section;
 static void
 open_src(const char *name, gp_symbol_type *symbol)
 {
-  char file_name[PATH_MAX + 1];
+  char *file_name = NULL;
   struct list_context *new = malloc(sizeof(*new));
-  int i;
+  int i, len;
 
   assert(name != NULL);
 
@@ -45,10 +45,13 @@ open_src(const char *name, gp_symbol_typ
   if (new->f == NULL) {
 /* Try searching include pathes */
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s" COPY_CHAR "%s", state.paths[i], name);
+  len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s" COPY_CHAR "%s", state.paths[i], name);
   new->f = fopen(file_name, "rb");
   if (new->f != NULL) {
 name = file_name;
+free(file_name);
 break;
   }
 }
@@ -57,11 +60,15 @@ open_src(const char *name, gp_symbol_typ
   const char *p = strrchr(name, PATH_CHAR);
 
   if (p != NULL) {
+file_name = NULL;
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s%s", state.paths[i], p);
+  len = snprintf(NULL, 0, "%s%s", state.paths[i], p) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s%s", state.paths[i], p);
   new->f = fopen(file_name, "rb");
   if (new->f != NULL) {
 name = file_name;
+free(file_name);
 break;
   }
 }
Index: gputils-1.4.0/gpasm/scan.l
===
--- gputils-1.4.0.orig/gpasm/scan.l
+++ gputils-1.4.0/gpasm/scan.l
@@ -626,16 +626,18 @@ a'{STR_QCHAR}'   {
 static void
 search_paths(struct source_context *new, const char *name)
 {
-  char tryname[PATH_MAX + 1];
-  int i;
+  char *tryname = NULL;
+  int i, len;
 
   for (i = 0; i < state.path_num; i++) {
-snprintf(tryname, sizeof(tryname),
- "%s" COPY_CHAR "%s", state.paths[i], name);
+len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+tryname = realloc(tryname, len);
+snprintf(tryname, len, "%s" COPY_CHAR "%s", state.paths[i], name);
 new->f = fopen(tryname, "rt");
 
 if (new->f != NULL) {
   new->name = strdup(tryname);
+  free(tryname);
   break;
 }
   }

gputils: FTBFS on hurd-i386 (for review)

[Svante Signell]

Source: gputils
Version: 1.4.0-0.1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hi,

gputils currently FTBFS on GNU/Hurd due to PATH_MAX not being defined. The
attached patch fixes this issue by allocating strings dynamically and remove
them when not needed any more.

Thanks!Index: gputils-1.4.0/gplink/gplink.c
===
--- gputils-1.4.0.orig/gplink/gplink.c
+++ gputils-1.4.0/gplink/gplink.c
@@ -321,9 +321,11 @@ gplink_open_coff(const char *name)
   gp_object_type *object;
   gp_archive_type *archive;
   FILE *coff;
-  char file_name[PATH_MAX + 1];
+  char *file_name = NULL;
+  int len = strlen(name) + 1;
 
-  strncpy(file_name, name, sizeof(file_name));
+  file_name = malloc(len);
+  strncpy(file_name, name, len);
 
   coff = fopen(file_name, "rb");
   if ((coff == NULL) && (strchr(file_name, PATH_CHAR) == 0)) {
@@ -331,7 +333,9 @@ gplink_open_coff(const char *name)
 int i;
 
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s" COPY_CHAR "%s", state.paths[i], name);
+  len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name);
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s" COPY_CHAR "%s", state.paths[i], name);
   coff = fopen(file_name, "rb");
 
   if (coff != NULL) {
@@ -341,6 +345,7 @@ gplink_open_coff(const char *name)
   }
 
   if (coff == NULL) {
+free(file_name);
 perror(name);
 exit(1);
   }
@@ -353,17 +358,21 @@ gplink_open_coff(const char *name)
 /* read the object */
 object = gp_read_coff(file_name);
 object_append(object, file_name);
+free(file_name);
 break;
   case archive_file:
 /* read the archive */
 archive = gp_archive_read(file_name);
 archive_append(archive, file_name);
+free(file_name);
 break;
   case sys_err_file:
 gp_error("Can't open file \"%s\".", file_name);
+free(file_name);
 break;
   case unknown_file:
 gp_error("\"%s\" is not a valid coff object or archive.", file_name);
+free(file_name);
 break;
   default:
 assert(0);
Index: gputils-1.4.0/gplink/lst.c
===
--- gputils-1.4.0.orig/gplink/lst.c
+++ gputils-1.4.0/gplink/lst.c
@@ -35,9 +35,9 @@ static gp_section_type *line_section;
 static void
 open_src(const char *name, gp_symbol_type *symbol)
 {
-  char file_name[PATH_MAX + 1];
+  char *file_name = NULL;
   struct list_context *new = malloc(sizeof(*new));
-  int i;
+  int i, len;
 
   assert(name != NULL);
 
@@ -45,10 +45,13 @@ open_src(const char *name, gp_symbol_typ
   if (new->f == NULL) {
 /* Try searching include pathes */
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s" COPY_CHAR "%s", state.paths[i], name);
+  len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s" COPY_CHAR "%s", state.paths[i], name);
   new->f = fopen(file_name, "rb");
   if (new->f != NULL) {
 name = file_name;
+free(file_name);
 break;
   }
 }
@@ -57,11 +60,15 @@ open_src(const char *name, gp_symbol_typ
   const char *p = strrchr(name, PATH_CHAR);
 
   if (p != NULL) {
+file_name = NULL;
 for (i = 0; i < state.numpaths; i++) {
-  snprintf(file_name, sizeof(file_name), "%s%s", state.paths[i], p);
+  len = snprintf(NULL, 0, "%s%s", state.paths[i], p) + 1;
+  file_name = realloc(file_name, len);
+  snprintf(file_name, len, "%s%s", state.paths[i], p);
   new->f = fopen(file_name, "rb");
   if (new->f != NULL) {
 name = file_name;
+free(file_name);
 break;
   }
 }
Index: gputils-1.4.0/gpasm/scan.l
===
--- gputils-1.4.0.orig/gpasm/scan.l
+++ gputils-1.4.0/gpasm/scan.l
@@ -626,16 +626,18 @@ a'{STR_QCHAR}'   {
 static void
 search_paths(struct source_context *new, const char *name)
 {
-  char tryname[PATH_MAX + 1];
-  int i;
+  char *tryname = NULL;
+  int i, len;
 
   for (i = 0; i < state.path_num; i++) {
-snprintf(tryname, sizeof(tryname),
- "%s" COPY_CHAR "%s", state.paths[i], name);
+len = snprintf(NULL, 0, "%s" COPY_CHAR "%s", state.paths[i], name) + 1;
+tryname = realloc(tryname, len);
+snprintf(tryname, len, "%s" COPY_CHAR "%s", state.paths[i], name);
 new->f = fopen(tryname, "rt");
 
 if (new->f != NULL) {
   new->name = strdup(tryname);
+  free(tryname);
   break;
 }
   }

Re: kdiff3: FTBFS on hurd-i386 (for review)

[Svante Signell]

On Fri, 2014-09-26 at 07:44 +0200, Pino Toscano wrote:
> On 2014-09-25 14:05, Svante Signell wrote:
> > Hi Pino
> > 
> > On Thu, 2014-09-25 at 10:08 +0200, Pino Toscano wrote:
> > > On 2014-09-24 19:11, Philipp A. Hartmann wrote:
> > > > I would probably do it like this (untested):
> > > > 
> > > > const char *path =
> > > > QFile::encodeName(fi.absoluteFilePath()).constData();
> > > 
> > > QFile::encodeName returns a temporary QByteArray, and getting a
> > > pointer to its internal char* will cause it to be a dangling 
> > > pointer.
> > > 
> > >    const QByteArray path = QFile::encodeName(fi.absoluteFilePath());
> > > 
> > > and then use path.constData() whenever needed.
> > > 
> > > > std::vector s(sb.st_size + 1);
> > > 
> > > Please use QByteArray instead.
> > 
> > Ok now?
> 
> You've forgot the second part of what I said.

Hi again (2.5 years later). Attached is a patch using QByteArray. Hopefully it
is OK now? (I'm not fluent in C++)

Thanks!
Index: kdiff3-0.9.98/src-QT4/fileaccess.cpp
===
--- kdiff3-0.9.98.orig/src-QT4/fileaccess.cpp
+++ kdiff3-0.9.98/src-QT4/fileaccess.cpp
@@ -235,14 +235,22 @@ void FileAccess::setFile( const QFileInf
  d()->m_linkTarget = fi.readLink();
 #else
  // Unfortunately Qt4 readLink always returns an absolute path, even if the link is relative
- char s[PATH_MAX+1];
- int len = readlink(QFile::encodeName(fi.absoluteFilePath()).constData(), s, PATH_MAX);
- if ( len>0 )
+ const QByteArray path = QFile::encodeName(fi.absoluteFilePath());
+ struct stat sb;
+ bool resolved = false;
+
+ if ( lstat(path.constData(), ) != -1 )
  {
-s[len] = '\0';
-d()->m_linkTarget = QFile::decodeName(s);
+QByteArray s = QByteArray(path.constData(), sb.st_size + 1);
+ssize_t len = readlink(path.constData(), s.data(), s.size());
+s[len] = '\0';   
+if ( len > 0 && len <= sb.st_size )
+{
+   resolved = true;
+   d()->m_linkTarget = QFile::decodeName(s);
+}
  }
- else
+ if ( !resolved )
  {
 d()->m_linkTarget = fi.readLink();
  }

Re: open-isns porting question: sudden SIGLOST

[Svante Signell]

On Wed, 2016-07-27 at 23:38 +0200, Christian Seiler wrote:
> On 07/27/2016 07:25 PM, Svante Signell wrote:
> > 
> (FTR: <http://paste.debian.net/785673/>, code is more or less
> identical to the code in open-isns when it comes to sendmsg and
> recvmsg, but it works...)

Does the open-isns code use SCM_RIGHTS too? My test cases don't work
with both SCM_RIGHTS and SCM_CREDS used. (Haven't found SCM_RIGHTS in
the open-isns sources though)

Re: open-isns porting question: sudden SIGLOST

[Svante Signell]

(Adding bug-hurd to the Cc: list, not all developers follows the
debian-hurd list)

On Wed, 2016-07-27 at 18:15 +0200, Christian Seiler wrote:
> Oh, I should mention that every time you run isnsadm the server
> (isnsd) crashes with SIGLOST, so you need to restart it between
> tries.
> 
> Or you can run it in foreground on another shell under e.g. gdb or
> rpctrace. (--foreground)

I found that out, thanks!

> Any ideas where to set breakpoints in gdb?
> > isns_net_stream_xmit
> > isns_net_recvmsg
> > 
> > (stream_xmit for sending, recvmsg for receiving.)
> > 
> > Thanks for looking into this!

Using rpctrace I get the same output as you. It seems like the
SCM_CREDS support is failing somewhere. Or the implementation differs
from the kFreeBSD version.

And using gdb does not work, something in the latest gdb is buggy:
...
/build/gdb-N8gCcv/gdb-7.10/gdb/inline-frame.c:167: internal-error:
inline_frame_this_id: Assertion `frame_id_p (*this_id)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Re: open-isns porting question: sudden SIGLOST

[Svante Signell]

On Tue, 2016-07-26 at 23:21 +0200, Christian Seiler wrote:
> 
> > SCM_CREDS is supported and should work. Probably there is still
> > something missing or not working as the kFreeBSD version does.
> 
> Then, coming back to my original question: any pointers on how
> to debug that? Is there any documentation explaining what
> component in Hurd implements AF_LOCAL sockets and how it all
> works? Are there any tracing / debugging options one can apply
> here (apart from rpctrace, which doesn't appear to tell me
> much in this case)?
> 
> (Also, I'm unsure my problem is actually related to SCM_CREDS,
> that's just the only special thing that's done here, which is
> why I mentioned it.)
> 

This is what I get when running isnsadm with gdb:
(I also have an rpctrace available if you are interested)
Any ideas where to set breakpoints in gdb?

gdb /usr/sbin/isnsadm
(gdb) run --local --list nodes
Cannot access memory at address 0x17effec
Cannot access memory at address 0x17effe8
Cannot access memory at address 0x17effec
Cannot access memory at address 0x17effec
Cannot access memory at address 0x17effe8
Cannot access memory at address 0x17effec
Cannot access memory at address 0x17effe8
Cannot access memory at address 0x17effec
Cannot access memory at address 0x17effe8
/etc/iscsi/initiatorname.iscsi: No such file or directory
[New Thread 6216.3]
Cannot access memory at address 0x17effec
Cannot access memory at address 0x17effe8
Cannot access memory at address 0x17effec
Cannot access memory at address 0x17effe8
socket disconnect, retrying in 10 sec
socket disconnect, killing socket
Warning: Timed out while waiting for reply
Warning: GetNext call failed: Internal error
[Inferior 1 (bogus thread id 0) exited with code 01]

Re: open-isns porting question: sudden SIGLOST

[Svante Signell]

On Tue, 2016-07-26 at 18:12 +0200, Christian Seiler wrote:
> On 07/26/2016 04:15 PM, Richard Braun wrote:
> > On Sun, Jul 24, 2016 at 03:16:36PM +0200, Christian Seiler wrote:
> > > Peculiarities: the code uses SCM_CREDS and sendmsg/recvmsg over
> > > the
> > > local UNIX socket to check authorization. (Since there's no man
> > > page I
> > > could find about it, I assume that SCM_CREDS is implemented in
> > > the same
> > > way that kFreeBSD does it, at least if I look at the system
> > > header
> > > files.)
> > 
> > Please correct me if I'm wrong, but I'm almost certain we don't
> > support
> > SCM_CREDS yet.
> 
> Oh, I wasn't aware of that. Well, hmm, if that is true, what
> do I do then? It's not like there's an alternative I can use
> to achieve the same thing... (Or is there?)
> 
> FYI: the package in unstable now compiled [1], but it won't
> actually work properly.
> 
> Should I leave it at that? Or ask for removal from Hurd for
> now and instead of Arch: any use Arch: linux-any kfreebsd-any?
> Or leave it Arch: any but make the build explicitly fail
> again? I don't really have a preference.

SCM_CREDS is supported and should work. Probably there is still
something missing or not working as the kFreeBSD version does.

Re: Bug#829591: hurd: pseudoterminal hangs when I press ^O (flush)

[Svante Signell]

On Mon, 2016-07-11 at 23:04 +0300, Kalle Olavi Niemitalo wrote:
> 
> A Hurd developer advised me not to post the patches themselves
> because I don't intend to assign copyright to the FSF.  The
> diffstat (not counting the "prominent notices") is 18 insertions
> and 7 deletions, and the FSF considers "around 15 lines of code"
> the limit for a "tiny change".

If you look at the patch from an optimistic side: the number of new lines, it
would be only 11 LOC, i.e. 18-7=11 :)

Whatever its worth ...

Re: [PATCH] gnumach: debian/rules: Add custom keyword to custom built packages and uname -v

[Svante Signell]

On Wed, 2016-04-20 at 23:49 +0200, Samuel Thibault wrote:
> Svante Signell, on Wed 20 Apr 2016 23:40:31 +0200, wrote:
...
> > It would be much better to create custom versions of a given kernel,
> > like gnumach-1.6.custom or gnumach-1.6.custom1,
> > gnumach-1.6.custom2, etc
> Feel free to propose something which looks good :)

What about this?
From f8402f5752f3f9a432cfbabc05e17f6ecbd046b0 Mon Sep 17 00:00:00 2001
From: Svante Signell <s...@hurd-2014.my.own.domain>
Date: Thu, 21 Apr 2016 12:07:55 +0200
Subject: [PATCH 2/2] Add .custom- to custom built packages and gnumach
 kernels. Add - to .custom keyword in uname -v.

---
 debian/rules | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index 8138a98..c31106b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,11 +13,11 @@ MAJOR:= $(shell echo $(VERSION) | sed -e 's/\..*//g')
 DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 
 ifeq (,$(filter custom,$(DEB_BUILD_OPTIONS)))
-VERSION := $(NOGIT_VERSION)
 CUSTOM :=
+VERSION := $(NOGIT_VERSION)
 else
-VERSION := $(NOEPOCH_VERSION)
-CUSTOM := .custom
+CUSTOM := .custom-$(shell date +'%Y%m%d')
+VERSION := $(NOEPOCH_VERSION)$(CUSTOM)
 endif
 
 MACHINE := 486
-- 
2.6.4

Re: [PATCH] gnumach: debian/rules: Add custom keyword to custom built packages and uname -v

[Svante Signell]

On Wed, 2016-04-20 at 23:09 +0200, Samuel Thibault wrote:
> Hello,
> 
> Svante Signell, on Wed 20 Apr 2016 16:36:23 +0200, wrote:
> > 
> > shorten the gnumach-image package names containing the kernel a
> > little.
> Why doing this?  It prevents from installing various custom kernel
> versions.

I don't see the big issue with this: With the naming now you cannot make more
than one custom version of the 1.6 release. As it is now you cannot make several
versions of e.g. gnumach-1.6+git20160311-1-486 either until a new 1.6+git
version is out.

And the created package names are awful. It would be much better to create
custom versions of a given kernel, like gnumach-1.6.custom or
gnumach-1.6.custom1, gnumach-1.6.custom2, etc

However, I'll fix this, a new patch will follow subsequently.

[PATCH] gnumach: debian/rules: Add custom keyword to custom built packages and uname -v

[Svante Signell]

Hello,

As talked about on IRC, it would be nice to add the custom keyword to the kernel
version for custom built kernels. The attached patch fixes this and also add the
keyword to the built Debian packages as well as shorten the gnumach-image
package names containing the kernel a little.

Thanks!
--- a/debian/rules.orig	2016-03-11 23:03:06.0 +0100
+++ b/debian/rules	2016-04-20 16:07:25.0 +0200
@@ -14,7 +14,16 @@
 DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 
 ifneq (,$(filter custom,$(DEB_BUILD_OPTIONS)))
-VERSION := $(NOEPOCH_VERSION)
+VERSION := $(NOGIT_VERSION).custom
+SFX1=.custom-486
+SFX2=.custom-xen-486
+SFX3=.custom-486-dbg
+SFX4=.custom-xen-486-dbg
+else
+SFX1=-486
+SFX2=-xen-486
+SFX3=-486-dbg
+SFX4=-xen-486-dbg
 endif
 
 MACHINE := 486
@@ -81,7 +90,8 @@
 	dh_testdir
 	
 	-mkdir build
-	cd build && PACKAGE_VERSION_SUFFIX=-486 ../configure $(drivers) \
+	cd build && PACKAGE_VERSION_SUFFIX="$(SFX1)" ../configure \
+		$(drivers) \
 		CFLAGS="$(CFLAGS)" \
 		$(common_configure)
 
@@ -89,7 +99,7 @@
 	dh_testdir
 	
 	-mkdir build-xen
-	cd build-xen && PACKAGE_VERSION_SUFFIX=-xen-486 ../configure \
+	cd build-xen && PACKAGE_VERSION_SUFFIX="$(SFX2)" ../configure \
 		CFLAGS="$(CFLAGS)" \
 		$(common_configure) \
 		--enable-platform=xen
@@ -98,14 +108,16 @@
 	dh_testdir
 	
 	-mkdir build-dbg
-	cd build-dbg && PACKAGE_VERSION_SUFFIX=-486-dbg ../configure --enable-kdb $(drivers) \
-		$(common_configure) \
+	cd build-dbg && PACKAGE_VERSION_SUFFIX="$(SFX3)" ../configure \
+		--enable-kdb $(drivers) \
+		$(common_configure)
 
 build-xen-dbg/config.status: configure
 	dh_testdir
 	
 	-mkdir build-xen-dbg
-	cd build-xen-dbg && PACKAGE_VERSION_SUFFIX=-xen-486-dbg ../configure --enable-kdb \
+	cd build-xen-dbg && PACKAGE_VERSION_SUFFIX="$(SFX4)" ../configure \
+		--enable-kdb \
 		$(common_configure) \
 		--enable-platform=xen
 

Warning: glibc-2.22-6 is broken on Hurd

[Svante Signell]

As seen on #hurd:

starting /hurd/startup fails:
"Unexpected error: Invalid argument"

Re: php7.0: FTBFS on hurd-i386 (for review)

[Svante Signell]

Save for checking the return status of malloc() of course!

On Thu, 2016-03-31 at 10:11 +0200, Svante Signell wrote:
> Source: php7.0
> Version: 7.0.4-7
> Severity: important
> Tags: patch
> User: debian-hurd@lists.debian.org
> Usertags: hurd
> 
> Hello,
> 
> Currently php7.0 fails to build on GNU/Hurd due to PATH_MAX issues. The
> attached
> patch 0051-ext_date_lib_parse_tz.c.patch solves this by allocating the strings
> dynamically and free them when no longer needed.
> 
> 
> Thanks!

php7.0: FTBFS on hurd-i386 (for review)

[Svante Signell]

Source: php7.0
Version: 7.0.4-7
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

Currently php7.0 fails to build on GNU/Hurd due to PATH_MAX issues. The attached
patch 0051-ext_date_lib_parse_tz.c.patch solves this by allocating the strings
dynamically and free them when no longer needed.


Thanks!Index: php7.0-7.0.4/ext/date/lib/parse_tz.c
===
--- php7.0-7.0.4.orig/ext/date/lib/parse_tz.c
+++ php7.0-7.0.4/ext/date/lib/parse_tz.c
@@ -428,17 +428,23 @@ static char *parse_iso6709(char *p, doub
 static struct location_info **create_location_table(void)
 {
 struct location_info **li, *i;
-char zone_tab[PATH_MAX];
+char *zone_tab = NULL;
+int len;
 char line[512];
 FILE *fp;
 
-strncpy(zone_tab, ZONEINFO_PREFIX "/zone.tab", sizeof zone_tab);
+len = strlen(ZONEINFO_PREFIX) + 9 + 1;
+zone_tab = malloc(len);
+strncpy(zone_tab, ZONEINFO_PREFIX "/zone.tab", len);
 
 fp = fopen(zone_tab, "r");
 if (!fp) {
+free(zone_tab);
 return NULL;
 }
 
+free(zone_tab);
+
 li = calloc(LOCINFO_HASH_SIZE, sizeof *li);
 
 while (fgets(line, sizeof line, fp)) {
@@ -568,12 +574,14 @@ static void create_zone_index(timelib_tz
 
 	do {
 		struct dirent **ents;
-		char name[PATH_MAX], *top;
-		int count;
+		char *name = NULL, *top;
+		int count, len;
 
 		/* Pop the top stack entry, and iterate through its contents. */
 		top = dirstack[--dirstack_top];
-		snprintf(name, sizeof name, ZONEINFO_PREFIX "/%s", top);
+		len = strlen(ZONEINFO_PREFIX) + 1 + strlen(top) + 1;
+		name = malloc(len);
+		snprintf(name, len, ZONEINFO_PREFIX "/%s", top);
 
 		count = php_scandir(name, , index_filter, php_alphasort);
 
@@ -581,7 +589,9 @@ static void create_zone_index(timelib_tz
 			struct stat st;
 			const char *leaf = ents[count - 1]->d_name;
 
-			snprintf(name, sizeof name, ZONEINFO_PREFIX "/%s/%s", 
+			len = strlen(ZONEINFO_PREFIX) + 1 + strlen(top) + 1 + strlen(leaf) + 1;
+			name = realloc(name, len);
+			snprintf(name, len, ZONEINFO_PREFIX "/%s/%s",
  top, leaf);
 			
 			if (strlen(name) && stat(name, ) == 0) {
@@ -590,7 +600,9 @@ static void create_zone_index(timelib_tz
 
 if (root[0] == '/') root++;
 
-snprintf(name, sizeof name, "%s%s%s", root, 
+len = strlen(root) + 1 + strlen(leaf) + 1;
+name = realloc(name, len);
+snprintf(name, len, "%s%s%s", root,
 	 *root ? "/": "", leaf);
 
 if (S_ISDIR(st.st_mode)) {
@@ -616,6 +628,7 @@ static void create_zone_index(timelib_tz
 		}
 		
 		if (count != -1) free(ents);
+		free(name);
 		free(top);
 	} while (dirstack_top);
 
@@ -704,25 +717,31 @@ static const char *canonical_tzname(cons
  * length of the mapped data is placed in *length. */
 static char *map_tzfile(const char *timezone, size_t *length)
 {
-	char fname[PATH_MAX];
+	char *fname = NULL;
 	struct stat st;
 	char *p;
-	int fd;
-	
+	const char *c_tzname = canonical_tzname(timezone);
+	int fd, len;
+
 	if (timezone[0] == '\0' || strstr(timezone, "..") != NULL) {
 		return NULL;
 	}
 
-	snprintf(fname, sizeof fname, ZONEINFO_PREFIX "/%s", canonical_tzname(timezone));
-	
+	len = strlen(ZONEINFO_PREFIX) + 1 + strlen(c_tzname) + 1;
+	fname = malloc(len);
+	snprintf(fname, len, ZONEINFO_PREFIX "/%s", c_tzname);
+
 	fd = open(fname, O_RDONLY);
 	if (fd == -1) {
+		free(fname);
 		return NULL;
 	} else if (fstat(fd, ) != 0 || !is_valid_tzfile()) {
+		free(fname);
 		close(fd);
 		return NULL;
 	}
 
+	free(fname);
 	*length = st.st_size;
 	p = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
 	close(fd);
@@ -832,7 +851,9 @@ int timelib_timezone_id_is_valid(char *t
 
 #ifdef HAVE_SYSTEM_TZDATA
 	if (tzdb == timezonedb_system) {
-		char fname[PATH_MAX];
+		char *fname = NULL;
+		const char *c_tzname = canonical_tzname(timezone);
+		int len, res;
 		struct stat st;
 
 		if (timezone[0] == '\0' || strstr(timezone, "..") != NULL) {
@@ -846,9 +867,13 @@ int timelib_timezone_id_is_valid(char *t
 			}
 		}
 
-		snprintf(fname, sizeof fname, ZONEINFO_PREFIX "/%s", canonical_tzname(timezone));
-
-		return stat(fname, ) == 0 && is_valid_tzfile();
+		len = strlen(ZONEINFO_PREFIX) + 1 + strlen(c_tzname) + 1;
+		fname = malloc(len);
+		snprintf(fname, len, ZONEINFO_PREFIX "/%s", c_tzname);
+
+		res = (stat(fname, ) == 0) && is_valid_tzfile();
+		free(fname);
+		return res;
 	}
 #endif
 

Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support

[Svante Signell]

On Mon, 2016-03-14 at 14:23 +0100, Richard Braun wrote:
> On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote:
> > > Why, because it doesn't have a sleep statement?
> > 
> > I was referring to strict logic: it's not just because it happens to
> 
> Also, using sleep for synchronization is always wrong.

Dear Richard and Samuel, I know using sleep is considered bad! Please tell me
how the test code should be written to wait for the acknowledgement from the
receiver. That would be more productive than complaining :) 

Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support

[Svante Signell]

On Mon, 2016-03-14 at 12:20 +0100, Svante Signell wrote:
> On Mon, 2016-03-14 at 12:02 +0100, Samuel Thibault wrote:

> > > And with my old implementation it worked perfectly too.
> > 
> > Because it was synchronous, which was posing other problems.

Yet the problem is if the implementation should be synchronous or asynchronous.

> Have you checked that all dbus/glib tests pass? I have not :(

Why did you edit this comment out? This could supply a user case answer to the
above question. Strict logic or not.

Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support

[Svante Signell]

On Mon, 2016-03-14 at 12:02 +0100, Samuel Thibault wrote:
> Svante Signell, on Mon 14 Mar 2016 09:05:56 +0100, wrote:
> > On Mon, 2016-03-14 at 00:57 +0100, Samuel Thibault wrote:
> > > Svante Signell, on Sun 13 Mar 2016 14:19:35 +0100, wrote:
> > > > Running the code reveals that the current implementation in glibc is
> > > > buggy:
> > > > 
> > 
> > Well, the program works perfectly on kFreeBSD (Linux is different).
> 
> That doesn't mean that the program behaves correctly.

Why, because it doesn't have a sleep statement?

> > And with my old implementation it worked perfectly too.
> 
> Because it was synchronous, which was posing other problems.

Have you checked that all dbus/glib tests pass? I have not :(

Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support

[Svante Signell]

On Mon, 2016-03-14 at 00:57 +0100, Samuel Thibault wrote:
> Hello,
> 
> Svante Signell, on Sun 13 Mar 2016 14:19:35 +0100, wrote:
> > Running the code reveals that the current implementation in glibc is buggy:
> > 
> > ./scm_rights+creds_recv
> > Number of SCM_RIGHTS [<=3], SCM_CREDS [<=2]: [1,1] 
> > Input error: Using defaults: 
> > NRIGHTS = 1, NCREDS = 1
> > scm_rights+creds_send.c: msgh.msg_controllen = 112 (from control_un)
> > Receiving via datagram socket
> > recvmsg: (os/kern) invalid right
> 
> I've had a closer look, what happens here is that the
> mach_port_mod_refs() call on the rendezvous port fails because the port
> type of the rendezvous port is DEADNAME, i.e. the other end dropped the
> port.  Indeed, your sending program terminates as soon as it has sent
> its message.  You need to make it wait at least a bit for the receiver
> to get to receive the credentials.

Well, the program works perfectly on kFreeBSD (Linux is different). And with my
old implementation it worked perfectly too. Maybe the recvmsg/sendmsg code has
to be modified?

Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support

[Svante Signell]

On Sun, 2015-09-20 at 20:28 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Sun 20 Sep 2015 13:17:36 +0200, a écrit :
> > I'll have a stab at cleaning your patches.
> 
> I have pushed the result on the t/sendmsg-SCM_CREDS branch.  Note that I
> have refactored the t/sendmsg-SCM_RIGHTS branch, so make sure to update
> your SCM_RIGHTS patch from that branch.
> 
> I'll probably try to upload a glibc soon.

Working on a patch for a piece of software using SCM_CREDS code I tried the old
tests for SCM_RIGHTS and SCM_CREDS again with a recent glibc. 

Running the code reveals that the current implementation in glibc is buggy:

./scm_rights+creds_recv
Number of SCM_RIGHTS [<=3], SCM_CREDS [<=2]: [1,1] 
Input error: Using defaults: 
NRIGHTS = 1, NCREDS = 1
scm_rights+creds_send.c: msgh.msg_controllen = 112 (from control_un)
Receiving via datagram socket
recvmsg: (os/kern) invalid right

 ./scm_rights+creds_send
Number of SCM_RIGHTS [<=3], SCM_CREDS [<=2]: [1,1] 
Input error: Using defaults: 
NRIGHTS = 1, NCREDS = 1
scm_rights+creds_send.c: msgh.msg_controllen = 112 (from control_un)
Sent data = 12345

scm_rights+creds_send.c: Sending SCM_RIGHTS data
scm_rights+creds_send.c: cmhp[0]->cmsg_len = 16
scm_rights+creds_send.c: CMSG_SPACE (sizeof(int))[0] = 16
scm_rights+creds_send.c: fd[0]=3

scm_rights+creds_send.c: Sending SCM_CREDS data
scm_rights+creds_send.c: cmhp[1]->cmsg_len = 96
scm_rights+creds_send.c: CMSG_SPACE (sz)[1] = 96
Sent credentials: cmcred_pid=11071, cmcred_uid=1000, cmcred_euid=1000,
cmcred_gid=1000
scm_rights+creds_send.c: msgh.msg_controllen = 112
Sending via datagram socket
sendmsg() sent 4 bytes


Case 0,1 works, 0,2 does not. Neither does x,1 where x=1,2,3

Attached is the test code packaged into a small tar file.

test_SCM_RIGHTS+CREDS.tar.gz
Description: application/compressed-tar

Re: the tokyocabinet testsuite takes ages

[Svante Signell]

On Thu, 2016-02-11 at 17:40 +0100, Samuel Thibault wrote:
> Svante Signell, on Thu 11 Feb 2016 17:30:31 +0100, wrote:
> > tokyocabinet builds fine with your patch. Did you submit a bug report?
> 
> Nope, I'm still at work :)

Bug report with patch submitted: #814500

Re: the tokyocabinet testsuite takes ages

[Svante Signell]

On Wed, 2016-02-10 at 23:19 +0100, Samuel Thibault wrote:
> Hello,
> 
> The tokyocabinet testsuite currently takes ages to run, it didn't use to
> do that (e.g. on 28th january with version -5), it's really odd, there
> were only little source code change, and no gnumach, hurd or libc0.3
> change, can somebody have a look?

I've found the problem: The configure flag: --enable-uyeild was added to -6, to 
enable race-condition detection, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812796
Removing that option make the build succeed. Seems like there are many race
condition problems on GNU/Hurd, the test suite runs slower and slower for each
test. However, I haven't yet looked into what new code is enabled.