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#1070396: exim4: FTBFS on hurd-i386

[Svante Signell]

Source: exim4
Version: 4.97-8
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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

Bug#1069094: mariadb: FTBFS on hurd-i386

[Svante Signell]

Source: mariadb
Version: 10.11.7-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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

Bug#1029097: pam: FTBFS on hurd-i386

[Svante Signell]

On Thu, 2024-04-11 at 14:02 -0300, Diego Nieto Cid wrote:
> Hello
> 
> > --- /dev/null
> > +++ pam-1.5.3/libpam/include/path_max.h
> > @@ -0,0 +1,7 @@
> > +/*
> > + * Define PATH_MAX if not available
> > + */
> > +
> > +#ifndef PAH_MAX
> 
> There's a typo here ^ 
> 
> > +#define PATH_MAX 4096
> > +#endif
> 
> Cheers

Thanks,

New patch attached.

Description: define PATH_MAX for compatibility when it's not already set
 Some platforms, such as the Hurd, don't set PATH_MAX.  Set a reasonable
 default value in this case.
Authors: Steve Langasek , Svante Signell 

Bug-Debian: http://bugs.debian.org/

Index: pam-1.5.3/libpam/include/path_max.h
===
--- /dev/null
+++ pam-1.5.3/libpam/include/path_max.h
@@ -0,0 +1,7 @@
+/*
+ * Define PATH_MAX if not available
+ */
+
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
Index: pam-1.5.3/tests/tst-dlopen.c
===
--- pam-1.5.3.orig/tests/tst-dlopen.c
+++ pam-1.5.3/tests/tst-dlopen.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 
+/* Hurd compatibility */
+#include "path_max.h"
+
 /* Simple program to see if dlopen() would succeed. */
 int main(int argc, char **argv)
 {
Index: pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
===
--- pam-1.5.3.orig/modules/pam_debug/tst-pam_debug-retval.c
+++ pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_debug"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
===
--- pam-1.5.3.orig/modules/pam_deny/tst-pam_deny-retval.c
+++ pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_deny"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
===
--- pam-1.5.3.orig/modules/pam_echo/tst-pam_echo-retval.c
+++ pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_echo"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
===
--- pam-1.5.3.orig/modules/pam_faildelay/tst-pam_faildelay-retval.c
+++ pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_faildelay"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
===
--- pam-1.5.3.orig/modules/pam_localuser/tst-pam_localuser-retval.c
+++ pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_localuser"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
===
--- pam-1.5.3.orig/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
+++ pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_mkhomedir"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
===
--- pam-1.5.3.orig/modules/pam_nologin/tst-pam_nologin-retval.c
+++ pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_nologin"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_permit/tst-pam_permit-retval.c
===
--- pam-1.5.3.orig/modules/pam_permit/tst-pam_permit-retval.c
+++ pam-1.5.3/modules/pam_permit/tst-pam_permit-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_permit"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_rootok/tst-pam_rooto

Re: Bug#1029097:pam: FTBFS on hurd-i386

[Svante Signell]

On Thu, 2024-04-11 at 14:02 -0300, Diego Nieto Cid wrote:
> Hello
> 
> > --- /dev/null
> > +++ pam-1.5.3/libpam/include/path_max.h
> > @@ -0,0 +1,7 @@
> > +/*
> > + * Define PATH_MAX if not available
> > + */
> > +
> > +#ifndef PAH_MAX
> 
> There's a typo here ^ 
> 
> > +#define PATH_MAX 4096
> > +#endif
> 
> Cheers

Thanks,

New patch attached.

Description: define PATH_MAX for compatibility when it's not already set
 Some platforms, such as the Hurd, don't set PATH_MAX.  Set a reasonable
 default value in this case.
Authors: Steve Langasek , Svante Signell 

Bug-Debian: http://bugs.debian.org/

Index: pam-1.5.3/libpam/include/path_max.h
===
--- /dev/null
+++ pam-1.5.3/libpam/include/path_max.h
@@ -0,0 +1,7 @@
+/*
+ * Define PATH_MAX if not available
+ */
+
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
Index: pam-1.5.3/tests/tst-dlopen.c
===
--- pam-1.5.3.orig/tests/tst-dlopen.c
+++ pam-1.5.3/tests/tst-dlopen.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 
+/* Hurd compatibility */
+#include "path_max.h"
+
 /* Simple program to see if dlopen() would succeed. */
 int main(int argc, char **argv)
 {
Index: pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
===
--- pam-1.5.3.orig/modules/pam_debug/tst-pam_debug-retval.c
+++ pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_debug"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
===
--- pam-1.5.3.orig/modules/pam_deny/tst-pam_deny-retval.c
+++ pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_deny"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
===
--- pam-1.5.3.orig/modules/pam_echo/tst-pam_echo-retval.c
+++ pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_echo"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
===
--- pam-1.5.3.orig/modules/pam_faildelay/tst-pam_faildelay-retval.c
+++ pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_faildelay"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
===
--- pam-1.5.3.orig/modules/pam_localuser/tst-pam_localuser-retval.c
+++ pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_localuser"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
===
--- pam-1.5.3.orig/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
+++ pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_mkhomedir"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
===
--- pam-1.5.3.orig/modules/pam_nologin/tst-pam_nologin-retval.c
+++ pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_nologin"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_permit/tst-pam_permit-retval.c
===
--- pam-1.5.3.orig/modules/pam_permit/tst-pam_permit-retval.c
+++ pam-1.5.3/modules/pam_permit/tst-pam_permit-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_permit"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_rootok/tst-pam_rooto

Fwd: Bug#1029097:pam: FTBFS on hurd-i386

[Svante Signell]

--- Begin Message ---

Index: pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
===
--- pam-1.5.3.orig/modules/pam_nologin/tst-pam_nologin-retval.c
+++ pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
@@ -182,9 +182,17 @@ main(void)
 			  pam_start_confdir(service_file, pw->pw_name,
 	, ".", ));
 		ASSERT_NE(NULL, pamh);
+#ifndef __GNU__ /* This assertion fails on GNU/Hurd */
 		ASSERT_EQ(PAM_SYSTEM_ERR, pam_authenticate(pamh, 0));
+#else
+		ASSERT_EQ(PAM_PERM_DENIED, pam_authenticate(pamh, 0));
+#endif
 		ASSERT_EQ(PAM_PERM_DENIED, pam_setcred(pamh, 0));
+#ifndef __GNU__ /* This assertion fails on GNU/Hurd */
 		ASSERT_EQ(PAM_SYSTEM_ERR, pam_acct_mgmt(pamh, 0));
+#else
+		ASSERT_EQ(PAM_PERM_DENIED, pam_acct_mgmt(pamh, 0));
+#endif
 		ASSERT_EQ(PAM_MODULE_UNKNOWN, pam_chauthtok(pamh, 0));
 		ASSERT_EQ(PAM_MODULE_UNKNOWN, pam_open_session(pamh, 0));
 		ASSERT_EQ(PAM_MODULE_UNKNOWN, pam_close_session(pamh, 0));
Description: define PATH_MAX for compatibility when it's not already set
 Some platforms, such as the Hurd, don't set PATH_MAX.  Set a reasonable
 default value in this case.
Authors: Steve Langasek , Svante Signell 

Bug-Debian: http://bugs.debian.org/

Index: pam-1.5.3/libpam/include/path_max.h
===
--- /dev/null
+++ pam-1.5.3/libpam/include/path_max.h
@@ -0,0 +1,7 @@
+/*
+ * Define PATH_MAX if not available
+ */
+
+#ifndef PAH_MAX
+#define PATH_MAX 4096
+#endif
Index: pam-1.5.3/tests/tst-dlopen.c
===
--- pam-1.5.3.orig/tests/tst-dlopen.c
+++ pam-1.5.3/tests/tst-dlopen.c
@@ -16,6 +16,9 @@
 #include 
 #include 
 
+/* Hurd compatibility */
+#include "path_max.h"
+
 /* Simple program to see if dlopen() would succeed. */
 int main(int argc, char **argv)
 {
Index: pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
===
--- pam-1.5.3.orig/modules/pam_debug/tst-pam_debug-retval.c
+++ pam-1.5.3/modules/pam_debug/tst-pam_debug-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_debug"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
===
--- pam-1.5.3.orig/modules/pam_deny/tst-pam_deny-retval.c
+++ pam-1.5.3/modules/pam_deny/tst-pam_deny-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_deny"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
===
--- pam-1.5.3.orig/modules/pam_echo/tst-pam_echo-retval.c
+++ pam-1.5.3/modules/pam_echo/tst-pam_echo-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_echo"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
===
--- pam-1.5.3.orig/modules/pam_faildelay/tst-pam_faildelay-retval.c
+++ pam-1.5.3/modules/pam_faildelay/tst-pam_faildelay-retval.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_faildelay"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
===
--- pam-1.5.3.orig/modules/pam_localuser/tst-pam_localuser-retval.c
+++ pam-1.5.3/modules/pam_localuser/tst-pam_localuser-retval.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_localuser"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
===
--- pam-1.5.3.orig/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
+++ pam-1.5.3/modules/pam_mkhomedir/tst-pam_mkhomedir-retval.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_mkhomedir"
 #define TEST_NAME "tst-" MODULE_NAME "-retval"
Index: pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
===
--- pam-1.5.3.orig/modules/pam_nologin/tst-pam_nologin-retval.c
+++ pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include "path_max.h"
 
 #define MODULE_NAME "pam_nolog

Re: Are you doing this too for GNU/Hurd?

[Svante Signell]

On Thu, 2024-02-22 at 17:43 +0100, Samuel Thibault wrote:
> Svante Signell, le jeu. 22 févr. 2024 17:36:15 +0100, a ecrit:
> > Changes:
> > ...
> >  gcc-13 (13.2.0-14) experimental; urgency=medium
> > * Pass -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 by
> > default
> >  on the 32bit architectures armel, armhf, hppa, m68k, mips,
> > mipsel,
> >  powerpc (-m32 only) and sh4.
> > ...
> 
> No, just like it's not planned for i386.

And why is it not planned for i386?

Are you doing this too for GNU/Hurd?

[Svante Signell]

>From the changelog:

Changes:
...
 gcc-13 (13.2.0-14) experimental; urgency=medium
* Pass -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 by default
 on the 32bit architectures armel, armhf, hppa, m68k, mips, mipsel,
 powerpc (-m32 only) and sh4.
...

Re: Announcing: a new Hurd distro, based on Alpine Linux

[Svante Signell]

Hi Sergey.

Sorry for top-posting. 

This is very interesting, especially now when the Debian (GNU/Linux,
GNU/Hurd) project is heading in the wrong direction. I'll take a closer
look on Alpine in due time. 

Thanks! 
On Sat, 2024-01-20 at 23:03 +0300, Sergey Bugaev wrote:
> Hello!
> 
> Those of you who made it to Joshua's belated New Year's party have
> heard me mumble my way through announcing this: I have been working
> on
> a new Hurd-based disto, based on the Alpine Linux distribution [0]!
> 
> [0] https://www.alpinelinux.org/about/
> 
> Now, before I go any further, I should say that this is not trying to
> displace Debian or anything like that. We all love Debian GNU/Hurd,
> and are thankful for Samuel's hard work that makes it possible. I am
> using Debian, and will continue to do so. (Especially given that this
> project might not succeed, after all.)
> 
> That being said, I have for a long time thought that the Hurd needed
> more _distro diversity_. The other existing distro is Guix on the
> Hurd, made by our Guix friends, which is great, and it seems to have
> generated some interest towards the Hurd in the Guix community, and
> some positive publicity for the Hurd too.
> 
> Historically, I know that there has been the Arch Hurd project [1]
> (just look at all the excitement it has generated! [2]), but it seems
> to have stalled. (By the way, if you're a fan of Arch who's
> interested
> in the Hurd, I encourage you to revive Arch Hurd, that'd be so cool!)
> There's been talks of Gentoo GNU/Hurd, but it doesn't look like
> they've made much progress. (Fun story: I have once almost convinced
> a
> friend of mine who was a Gentoo user to try and bootstrap a Hurd
> version of Gentoo on his own.)
> 
> [1] https://archhurd.org/
> [2] https://bbs.archlinux.org/viewtopic.php?pid=682472
> 
> Awesome as Debian is, there are issues with it. Firstly, the tooling
> (and the social processes) used around Debian packaging seems rather
> arcane and complicated for someone like myself who is not experienced
> in Debian packaging. This is not a criticism; I'm sure it works great
> for them! — but this also means that most of us in the already small
> Hurd community are essentially unable to contribute to it.
> 
> Secondly, Debian GNU/Hurd being the full "grown-up" Debian distro has
> — well, certainly a lot of upsides, and that's what makes it so
> appealing — but also, I imagine, some downsides, in that it cannot
> just be our little playground. For example, I imagine Debian cannot
> ship the latest & greatest glibc master with all of my fixes, because
> that might break Debian GNU/Linux, which has different expectations
> around stability and a lot more users. In fact, Debian still ships
> glibc 2.37, with some patches backported.
> 
> Now, on the other hand of the spectrum are Flávio's cross-hurd
> scripts, which bootstrap a minimal Hurd-based system. These are
> small,
> self-contained, and hackable. You can build the whole thing,
> including
> the cross toolchains required, in a few minutes, without much of a
> special setup required. Bumping glibc (or something) should be
> trivial. If you want to contribute, you fork the Git repo, apply your
> changes, and just open a PR. How cool is that?
> 
> So I think there is a place for some middle ground between the two: a
> full (although small, "embedded") distro, with a package manager and
> many available packages, that is at the same time easy to bootstrap,
> to hack on, experiment with, and contribute to. The hackability
> should
> hopefully ensure that this becomes a community project rather than a
> one man show, and has a healthy bus factor.
> 
> I chose Alpine Linux as the upstream distribution for the project,
> for
> various reasons; not least because I thought it would be a fun
> endeavour to try and port Alpine which is known for not being a GNU
> distro and in particular not using glibc (and it was!). Alpine
> certainly fills the bill of being small and extremely hackable. They,
> too, keep all of their package build definitions/scripts in a single
> Git repo (aports); updating a package or adding a patch only requires
> making an MR against the repo. The CI can then pick up the change,
> rebuild the package, and without minutes of the MR being merged have
> the new package available for download from the repo.
> 
> I have ported many Alpine packages to build with (i386, for now) GNU
> Mach, the Hurd, and glibc, replacing Linux and musl. If you want a
> specific number: as of yesterday, I have 299 installable packages;
> the
> number of source packages is of course several times less than that.
> Still, this includes things like curl, ncurses, nano, native binutils
> & gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools,
> ... and of course gnumach, hurd (with dependencies like libdaemon,
> parted, ...), and glibc. Importantly, all this cleanly bootstraps
> using the scripts/bootstrap.sh script that they provide; this is too
> somewhat 

Re: Please help test the PAM in experimental

[Svante Signell]

Hi,

you don't seem to address:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029097
why?

On Fri, 2024-01-19 at 11:40 -0700, Sam Hartman wrote:
> 
> There are a number of changes, and I'd just like a bit more
> confidence
> that it works as expected before uploading to unstable in about a
> week.
> 
> Changes include:
> 
> * Running pam_umask with usergroups support by default.
> 
> * libpam-modules now depends on libsystemd0 because utmp is not
>   y2038-clean and upstream has decided to depend on elogind for that.
> 
> * New PAM upstream and thus newly rebased patches.
> 
> So, it would be helpful especially if you would install libpam-
> modules
> and libpam0g from experimental.

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!
 

[Python-modules-team] Bug#1060093: lirc: Found Hurd bug in 0.10.2-0.{3, 4}

[Svante Signell]

found 1060093 0.10.2-0.3
found 1060093 0.10.2-0.4
thanks


___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#1060093: lirc: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2024-01-05 at 21:58 +0100, Samuel Thibault wrote:
> Hello,
> 
> Thanks for your patches.
> 
> Svante Signell, le ven. 05 janv. 2024 21:14:19 +0100, a ecrit:
> > --- a/debian/rules  2023-12-16 18:35:11.0 +0100
> > +++ b/debian/rules  2024-01-02 12:49:12.0 +0100
> > @@ -4,7 +4,14 @@
> >  include /usr/share/dpkg/pkg-info.mk
> >  
> >  export DEB_BUILD_MAINT_OPTIONS  = hardening=+all
> > -export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > B_HOST_MULTIARCH)
> > +
> > +ifeq ($(DEB_HOST_ARCH_OS), hurd)
> > +#FIXME: Replace gnu0 with either gnu or hurd in python3.11!
> > +#/usr/lib/python3.11/__pycache__/_sysconfigdata__gnu0_i386-
> > gnu.cpython-311.pyc
> > +   export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__gnu0_$(DEB_HOST_MULTIARC
> > H)
> > +else
> > +   export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > B_HOST_MULTIARCH)
> 
> Probably better just ask python itself:
> 
> export _PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__$(shell python3 -c
> 'import os; print(os.sys.platform)')_$(DEB_HOST_MULTIARCH)

Why does the os.sys.platform report gnu0? It should be gnu or
preferrably hurd??

> > @@ -33,7 +40,7 @@
> >  else
> > dh_auto_configure -- \
> >     SH_PATH=/bin/sh \
> > -   MODINFO=/sbin/modinfo \
> > +   MODINFO= \
> >     --disable-uinput --disable-devinput
> 
> We do want modinfo on the linux platform, please make this os-
> specific.

Note the else:
ifeq ($(DEB_HOST_ARCH_OS), linux)
dh_auto_configure -- \
SH_PATH=/bin/sh \
MODINFO=/sbin/modinfo \
--enable-uinput --enable-devinput
else
dh_auto_configure -- \
SH_PATH=/bin/sh \
MODINFO= \
--disable-uinput --disable-devinput
endif


___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#1056311: lirc: FTBFS on hurd-i386

[Svante Signell]

Source: lirc
Version: 0.10.1-7.2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1060093: lirc: Found Hurd bug in 0.10.2-0.{3,4}

[Svante Signell]

found 1060093 0.10.2-0.3
found 1060093 0.10.2-0.4
thanks

Bug#1060093: lirc: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2024-01-05 at 21:58 +0100, Samuel Thibault wrote:
> Hello,
> 
> Thanks for your patches.
> 
> Svante Signell, le ven. 05 janv. 2024 21:14:19 +0100, a ecrit:
> > --- a/debian/rules  2023-12-16 18:35:11.0 +0100
> > +++ b/debian/rules  2024-01-02 12:49:12.0 +0100
> > @@ -4,7 +4,14 @@
> >  include /usr/share/dpkg/pkg-info.mk
> >  
> >  export DEB_BUILD_MAINT_OPTIONS  = hardening=+all
> > -export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > B_HOST_MULTIARCH)
> > +
> > +ifeq ($(DEB_HOST_ARCH_OS), hurd)
> > +#FIXME: Replace gnu0 with either gnu or hurd in python3.11!
> > +#/usr/lib/python3.11/__pycache__/_sysconfigdata__gnu0_i386-
> > gnu.cpython-311.pyc
> > +   export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__gnu0_$(DEB_HOST_MULTIARC
> > H)
> > +else
> > +   export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > B_HOST_MULTIARCH)
> 
> Probably better just ask python itself:
> 
> export _PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__$(shell python3 -c
> 'import os; print(os.sys.platform)')_$(DEB_HOST_MULTIARCH)

Why does the os.sys.platform report gnu0? It should be gnu or
preferrably hurd??

> > @@ -33,7 +40,7 @@
> >  else
> > dh_auto_configure -- \
> >     SH_PATH=/bin/sh \
> > -   MODINFO=/sbin/modinfo \
> > +   MODINFO= \
> >     --disable-uinput --disable-devinput
> 
> We do want modinfo on the linux platform, please make this os-
> specific.

Note the else:
ifeq ($(DEB_HOST_ARCH_OS), linux)
dh_auto_configure -- \
SH_PATH=/bin/sh \
MODINFO=/sbin/modinfo \
--enable-uinput --enable-devinput
else
dh_auto_configure -- \
SH_PATH=/bin/sh \
MODINFO= \
--disable-uinput --disable-devinput
endif

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 

Bug#1060093: lirc: FTBFS on hurd-i386

[Svante Signell]

Source: lirc
Version: 0.10.2-0.2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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 

Bug#1056980: Lost mail!

[Svante Signell]

Hello,

How come I never saw this mail??
https://bugs.devuan.org/cgi/bugreport.cgi?bug=813#66

Strange, gmail hickup??

I'll comment inline when/if I find it, else I'd cut and paste from the bug
report.

Thanks!

Bug#1056980: Lost mail!

[Svante Signell]

Hello,

How come I never saw this mail??
https://bugs.devuan.org/cgi/bugreport.cgi?bug=813#66

Strange, gmail hickup??

I'll comment inline when/if I find it, else I'd cut and paste from the bug
report.

Thanks!

Bug#1056980: [devuan-dev] bug#813: Reopen 1056980

[Svante Signell]

Control: severity -1 serious
Control: tags -1 reopen

Hello again,

As long as you (or somebody else) don't give a solid reason for not
allowing configuration files to change, I'll continue this severity
ping-pong!

Thanks!
On Fri, 2023-12-08 at 20:40 +0100, Chris Hofstaedtler wrote:
> Control: severity -1 normal
> Control: tags -1 = wontfix
> 
> * Svante Signell  [231208 19:38]:
> > On Fri, 2023-12-08 at 16:15 +0100, Svante Signell wrote:
> > > reopen 1056980
> > > severity 1056980 serious
> > > tags 1056980 patch
> > > thanks
> > 
> > Sorry, forgot the patch!
> > 
> 
> > --- a/debian/netcat-traditional.postinst2023-11-27
> > 03:20:27.0 +0100
> > +++ b/debian/netcat-traditional.postinst2023-12-04
> > 15:11:31.0 +0100
> > @@ -4,8 +4,8 @@
> >  
> >  if [ "$1" = "configure" ]; then
> >  update-alternatives \
> > -    --install /bin/nc nc /bin/nc.traditional 10 \
> > -    --slave /bin/netcat netcat /bin/nc.traditional \
> > +    --install /usr/bin/nc nc /usr/bin/nc.traditional 10 \
> > +    --slave /usr/bin/netcat netcat /usr/bin/nc.traditional \
> >  --slave /usr/share/man/man1/nc.1.gz nc.1.gz \
> >  /usr/share/man/man1/nc.traditional.1.gz \
> >  --slave /usr/share/man/man1/netcat.1.gz netcat.1.gz \
> 
> This is absolutely wrong on Debian, and must not be uploaded to
> Debian.
> 
> If you want to keep it as a Devuan delta, go ahead.
> 
> Chris
> 

Bug#1056980: [devuan-dev] bug#813: Reopen 1056980

[Svante Signell]

On Fri, 2023-12-08 at 16:15 +0100, Svante Signell wrote:
> reopen 1056980
> severity 1056980 serious
> tags 1056980 patch
> thanks

Sorry, forgot the patch!

--- a/debian/netcat-traditional.postinst	2023-11-27 03:20:27.0 +0100
+++ b/debian/netcat-traditional.postinst	2023-12-04 15:11:31.0 +0100
@@ -4,8 +4,8 @@
 
 if [ "$1" = "configure" ]; then
 update-alternatives \
---install /bin/nc nc /bin/nc.traditional 10 \
---slave /bin/netcat netcat /bin/nc.traditional \
+--install /usr/bin/nc nc /usr/bin/nc.traditional 10 \
+--slave /usr/bin/netcat netcat /usr/bin/nc.traditional \
 --slave /usr/share/man/man1/nc.1.gz nc.1.gz \
 /usr/share/man/man1/nc.traditional.1.gz \
 --slave /usr/share/man/man1/netcat.1.gz netcat.1.gz \

Bug#1056980: [devuan-dev] bug#813: Reopen 1056980

[Svante Signell]

On Fri, 2023-12-08 at 16:15 +0100, Svante Signell wrote:
> reopen 1056980
> severity 1056980 serious
> tags 1056980 patch
> thanks

Sorry, forgot the patch!

--- a/debian/netcat-traditional.postinst	2023-11-27 03:20:27.0 +0100
+++ b/debian/netcat-traditional.postinst	2023-12-04 15:11:31.0 +0100
@@ -4,8 +4,8 @@
 
 if [ "$1" = "configure" ]; then
 update-alternatives \
---install /bin/nc nc /bin/nc.traditional 10 \
---slave /bin/netcat netcat /bin/nc.traditional \
+--install /usr/bin/nc nc /usr/bin/nc.traditional 10 \
+--slave /usr/bin/netcat netcat /usr/bin/nc.traditional \
 --slave /usr/share/man/man1/nc.1.gz nc.1.gz \
 /usr/share/man/man1/nc.traditional.1.gz \
 --slave /usr/share/man/man1/netcat.1.gz netcat.1.gz \

Bug#1056980: Reopen 1056980

[Svante Signell]

reopen 1056980  
severity 1056980 serious  
tags 1056980 patch  
thanks

Hello,

Reopening this bug due to a deliberate attempt to fool the users: Either you move binaries _and_ configuration files 
to /usr/bin or explicitely depend on usrmerge. And closing this bug as wontfix is not nice.

I've modified netcat-traditional.postinst on both usrmerged and non-usrmerged systems without problems. So your second comment b) in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056980#15
is definitely false:

From: Chris Hofstaedtler <[z...@debian.org](mailto:z...@debian.org)>  
...
No, changing the update-alternatives call is  
a) not necessary on /usr-merged systems,  
b) will break on these.

No the system did not break!

Yes, I have read [https://wiki.debian.org/UsrMerge](https://wiki.debian.org/UsrMerge)  

And found:  
! Please suspend further moves temporarily. The effects of moves cause more problems than anticipated 
people are working to understand and solve them. Exceptions: Continue to perform moves that fix RC bugs
(e.g. dh_installsystemd or systemd.pc issues) and DEP17P7 mitigations for udev rules.

And:
Do not update calls to update-alternatives:
- Even if you move e.g. /bin/more to /usr/bin/more, do not change the location used in the 
  update-alternatives invocation.
- If you add new alternatives, install them to /usr if possible. 

And:
P4: Even when changing all aliased paths from / to /usr, you must not change the paths passed to update-alternatives
invocations that already existed in bookworm. The current plan is to keep existing alternatives aliased as a legacy
forever and add new alternatives without aliasing. 

Who wrote this? The question is why?? All changes to packages moving files to /usr should also move _all_ 
corresponding configuration files to, or add an explicit dependency on usrmerge!

Thanks!

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

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]

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
> 

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

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

Bug#1057634: 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 ---

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#1056311: lirc: FTBFS on hurd-i386

[Svante Signell]

Source: lirc
Version: 0.10.1-7.2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1056145: e2fsprogs: FTBFS on hurd-i386

[Svante Signell]

Source: e2fsprogs
Version: 1.47.0-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#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-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1056049: consolekit2: Not buildable on hurd-i386

[Svante Signell]

Source: consolekit2
Version: 1.2.6-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1055936: synaptic: Non-installable on hurd-i386

[Svante Signell]

Source: synaptic
Version: 0.93.1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1055935: mate-polkit: Non-installable on hurd-i386

[Svante Signell]

Source: mate-polkit
Version: 1.26.1-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1055875: util-linux: FTBFS on hurd-i386

[Svante Signell]

Source: util-linux
Version: 2.39.2-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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)

Re: Some progress, Guix rumpdisk still crashes...

[Svante Signell]

On Wed, 2023-05-17 at 20:24 +0200, Janneke Nieuwenhuizen wrote:
> Hi!
> 
> With this newly patched glibc
> 
>     https://gitlab.com/janneke/guix/-/tree/wip-hurd12
> 
> rumpdisk still crashes, but the good news (I guess) is that it seems to
> get somewhat further, or at least it crashes differently.  Here are the
> last 24 (WTF, 1980 wants their screensize back!?) lines (I don't know
> how to get the full log from QEMU):

I use for hurdX (hurd-cross):
qemu-system-x86_64 -chardev stdio,id=char0,logfile=serial.log,signal=off -serial
chardev:char0 -m 2048 -enable-kvm -drive file=hurd-cross-serial.img
And added to /boot/grub/grub.cfg:
set serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1
set terminal_input serial
set terminal_output serial
set timeout=5

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Svante Signell]

On Sat, 2023-05-13 at 19:01 +, jbra...@dismail.de wrote:
> May 13, 2023 1:46 PM, "Sergey Bugaev"  wrote:
> 
> > On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de 
> > wrote:
> > 
> > > +Hurd developers are adding 64-bit support, and they plan to drop the
> > > +32-bit support, once the 64-bit support is deemed stable.
> > 
> > Is this really the plan? :(
> > 
> > Has this been discussed anywhere?
> 
> It is entirely possible that I made up the plan to drop 32-bit support.  
> I thought I had seem someone say that was the plan...

Why dropping 32-bit support? It does not make sense.

Thanks! 

Re: Prospectives (Was: hurd: Add expected abilist files for x86_64)

[Svante Signell]

On Wed, 2023-05-03 at 19:56 +0200, Samuel Thibault wrote:
> Samuel Thibault, le mer. 03 mai 2023 13:09:25 +0200, a ecrit:
> > Sergey Bugaev, le mer. 03 mai 2023 13:26:56 +0300, a ecrit:
> > > > To put another perspective: I have been doing that less funny part for a
> > > > long time already. I can't do everything alone.
> > > 
> > > I appreciate that! -- and I'm sure everyone else does. Are there any
> > > other tasks that are not fun to you that we could help you with?
> > 
> > E.g. fixing the remaining git and vim testsuite bugs.
> 
> And more generally fix the build of the top of 
> 
> https://people.debian.org/~sthibault/graph-total-top.txt
> 
> Some of these are mostly hopeless (java), others should really be fixed
> (perl, help2man, mesa, pam, util-linux, etc.). I'm currently hitting the
> pam issue to be able to bootstrap hurd-amd64, for instance.

Did you see the Debian pam Bug#1029097?

Re: [hurd,commited] hurd: Enable x86_64 build script

[Svante Signell]

On Tue, 2023-05-02 at 22:25 +0200, Samuel Thibault wrote:
> Thanks so much to all people involved in making the 64bit port a real
> thing now!

Congrats to all involved in creating the 64bit port. GNU/Hurd is definitely not
a dead project!

Thanks!

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

[Svante Signell]

On Tue, 2023-05-02 at 17:10 +0300, Sergey Bugaev wrote:
> On Mon, May 1, 2023 at 8:43 PM Samuel Thibault 
> wrote:
> > 
> > 
> > They will just *not* work with 64bit. The glue code is not ready at all,
> > and I think it's really not useful to spend time on that when we have
> > the rump drivers which should be working fine.
> 
> I was secretly hoping that the Linux drivers won't be fully abandoned
> with the rise of rump and lwip; but that Linux and non-Linux
> implementations will both stay as available alternatives. And that
> someone would upgrade the bundled Linux code (6.3 is out now...) --
> perhaps a future project for myself.

Please forget Linux code: drivers and pfinet. Rump and lwip is the future.
Additionally with pfinet and Linux drivers removed, Hurd code could be made
GPLv3+. That would be a _very_ large step ahead towards a pure GNU system.

Thanks!

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#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-h...@lists.debian.org
Usertags: hurd
Affects: gcc-snapshot
X-Debbugs-CC: debian-h...@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#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-h...@lists.debian.org
Usertags: hurd
Affects: gcc-snapshot
X-Debbugs-CC: debian-h...@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 ---

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

[Svante Signell via Gcc-patches]

Package: gcc-snapshot
Version: 1:20230315-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-snapshot
X-Debbugs-CC: debian-h...@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 ---

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #37, sr #110199 (project administration):

Hello,

Thank you for your reply. If I understand correctly all files under the BSD-3
licence have to contain a copy of the license text. Secondly for other
licences every file has to carry a copyright and license notice.

All of the above applies to files longer that 10 lines, according to the link
you gave above. What to do with such files?

I made an attempt to add a copyright file in every directory, listing all
files with their copyright and license information. This is what Debian does
for their packages. This solution does not seem to be accepted, right? Please
confirm and I'll make all changes according to your wishes. (Even if very
small files, > 10 lines, are cluttered with the license and copyright
information, making them harder to read). 

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #37, sr #110199 (project administration):

Hello,

Thank you for your reply. If I understand correctly all files under the BSD-3
licence have to contain a copy of the license text. Secondly for other
licences every file has to carry a copyright and license notice.

All of the above applies to files longer that 10 lines, according to the link
you gave above. What to do with such files?

I made an attempt to add a copyright file in every directory, listing all
files with their copyright and license information. This is what Debian does
for their packages. This solution does not seem to be accepted, right? Please
confirm and I'll make all changes according to your wishes. (Even if very
small files, > 10 lines, are cluttered with the license and copyright
information, making them harder to read). 

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #35, sr #110199 (project administration):

Hi again,

The file COPYING in patches/PAM/hurd_no_setfsuid.diff was added by me. The
text in that file is now changed to:
Copyright (C) 2018 Steve Langasek. Linux-PAM is free software licensed under
the 3-clause BSD license, see the file ../../licenses/BSD-3. Is that better?

Any other issues with licences and copyright?

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #35, sr #110199 (project administration):

Hi again,

The file COPYING in patches/PAM/hurd_no_setfsuid.diff was added by me. The
text in that file is now changed to:
Copyright (C) 2018 Steve Langasek. Linux-PAM is free software licensed under
the 3-clause BSD license, see the file ../../licenses/BSD-3. Is that better?

Any other issues with licences and copyright?

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #33, sr #110199 (project administration):

Hello, this issue seems to have a Closed status. Can somebody open it again?

Thanks!



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #33, sr #110199 (project administration):

Hello, this issue seems to have a Closed status. Can somebody open it again?

Thanks!



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #32, sr #110199 (project administration):

Long time no see!

Attached is an updated tarball of hurd-cross (hurdX): Hopefully the we are
getting closer to upload now.

(file #54322)

___

Additional Item Attachment:

File name: hurd-cross.tar.gz  Size:64 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #32, sr #110199 (project administration):

Long time no see!

Attached is an updated tarball of hurd-cross (hurdX): Hopefully the we are
getting closer to upload now.

(file #54322)

___

Additional Item Attachment:

File name: hurd-cross.tar.gz  Size:64 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

Re: [PATCH] Add libraries to Makefiles.

[Svante Signell]

On Wed, 2023-01-18 at 12:41 +0100, Samuel Thibault wrote:


> I'm not talking about libz.so, but about libstore.so. Is that
> libstore.so really a shared library that has libz in NEEDED? If so
> there is really no need to add -lz to linking storeio. Unless you
> actually send us the actual error message you get without an explicit
> -lz, we can't know why you'd have to add -lz.
> 

I compiled hurd-git natively, and no patches for zlib were needed. 

However cross-building errors out:
/cross-tools/bin/i686-pc-gnu-gcc -shared -Wl,-soname=libstore.so.0.3 -o
libstore.so.0.3 \
  -L. -L../libfshelp/ -L../libihash/ -L../libiohelp/ -L../libpager/
-L../libports/ -L../libshouldbeinlibc/ -Wl,-rpath-link=../libfshelp/ -
Wl,-rpath-link=../libihash/ -Wl,-rpath-link=../libiohelp/ -Wl,-rpath-
link=../libpager/ -Wl,-rpath-link=../libports/ -Wl,-rpath-
link=../libshouldbeinlibc/ -std=gnu99 -fgnu89-inline -Wall -g -O3 -fno-
strict-aliasing  -g -O2 -Wl,-verbose,-L/tools/lib \
  '-Wl,-(' create_pic.o derive_pic.o make_pic.o rdwr_pic.o
set_pic.o enc_pic.o encode_pic.o decode_pic.o clone_pic.o argp_pic.o
kids_pic.o flags_pic.o open_pic.o xinl_pic.o typed_pic.o map_pic.o
url_pic.o unknown_pic.o stripe_pic.o copy_pic.o device_pic.o file_pic.o
memobj_pic.o module_pic.o mvol_pic.o nbd_pic.o remap_pic.o task_pic.o
zero_pic.o gunzip_pic.o do-gunzip_pic.o util_pic.o
../libshouldbeinlibc/libshouldbeinlibc.so \
-ldl -lpthread  -lz \
  '-Wl,-)' 

libz.so needed by ../libstore/libstore.so
...
/cross-tools/lib/gcc/i686-pc-gnu/12.2.0/../../../../i686-pc-gnu/bin/ld:
warning: libz.so, needed by ../libstore/libstore.so, not found (try
using -rpath or -rpath-link)

Adding -Wl,-rpath-link,$TARGET_ROOT/lib to LDFLAGS fixes the problem.

Thanks!

Re: [PATCH] Fix some compiler warnings

[Svante Signell]

On Wed, 2023-01-18 at 12:27 +0100, Samuel Thibault wrote:
> Svante Signell, le mer. 18 janv. 2023 11:59:40 +0100, a ecrit:
> > On Wed, 2023-01-18 at 02:02 +0100, Samuel Thibault wrote:
> > > Hello,
> > > 
> > > 
> > > But conversely when we'll build it in 64bit, vm_page_size
> > > (actually uintptr_t) will be an unsigned long.
> > > 
> > > This needs to be fixed the *proper* way: either use the PRIuPTR
> > > macro, or cast the value into unsigned long.
> > 
> > Now cast to an unsigned long, new patch attached.
> 
> I only took the ext2fs.c part for an example, but it's the same for
> all other files.

I've changed to (unsigned long) everywhere.

(There is also debug code not triggered by normal build needing fixes).

Thanks!

Index: hurd-0.9.git20221224/ext2fs/ext2fs.c
===
--- hurd-0.9.git20221224.orig/ext2fs/ext2fs.c
+++ hurd-0.9.git20221224/ext2fs/ext2fs.c
@@ -233,7 +233,7 @@ main (int argc, char **argv)
 ext2_panic ("device too small for superblock (%Ld bytes)", store->size);
   if (store->log2_blocks_per_page < 0)
 ext2_panic ("device block size (%zu) greater than page size (%lu)",
-		store->block_size, vm_page_size);
+		store->block_size, (unsigned long)vm_page_size);
 
   /* Map the entire disk. */
   create_disk_pager ();
Index: hurd-0.9.git20221224/ext2fs/dir.c
===
--- hurd-0.9.git20221224.orig/ext2fs/dir.c
+++ hurd-0.9.git20221224/ext2fs/dir.c
@@ -417,7 +417,7 @@ dirscanblock (vm_address_t blockaddr, st
 	{
 	  ext2_warning ("bad directory entry: inode: %Ld offset: %lu",
 			dp->cache_id,
-			currentoff - blockaddr + idx * DIRBLKSIZ);
+			(unsigned long)(currentoff - blockaddr + idx * DIRBLKSIZ));
 	  return ENOENT;
 	}
 
Index: hurd-0.9.git20221224/libpager/data-request.c
===
--- hurd-0.9.git20221224.orig/libpager/data-request.c
+++ hurd-0.9.git20221224/libpager/data-request.c
@@ -49,7 +49,7 @@ _pager_S_memory_object_data_request (str
 }
   if (length != __vm_page_size)
 {
-  printf ("incg data request: bad length size %lu\n", length);
+  printf ("incg data request: bad length size %lu\n", (unsigned long)length);
   goto release_out;
 }
   if (offset % __vm_page_size)
Index: hurd-0.9.git20221224/libpager/data-return.c
===
--- hurd-0.9.git20221224.orig/libpager/data-return.c
+++ hurd-0.9.git20221224/libpager/data-return.c
@@ -60,7 +60,7 @@ _pager_do_write_request (struct pager *p
 }
   if (length % __vm_page_size)
 {
-  printf ("incg data return: bad length size %lu\n", length);
+  printf ("incg data return: bad length size %lu\n", (unsigned long)length);
   goto release_out;
 }
   if (offset % __vm_page_size)
Index: hurd-0.9.git20221224/libpager/data-unlock.c
===
--- hurd-0.9.git20221224.orig/libpager/data-unlock.c
+++ hurd-0.9.git20221224/libpager/data-unlock.c
@@ -58,7 +58,7 @@ _pager_S_memory_object_data_unlock (stru
 }
   if (length != __vm_page_size)
 {
-  printf ("incg data unlock: bad length size %lu\n", length);
+  printf ("incg data unlock: bad length size %lu\n", (unsigned long)length);
   goto out;
 }
 
Index: hurd-0.9.git20221224/ext2fs/pager.c
===
--- hurd-0.9.git20221224.orig/ext2fs/pager.c
+++ hurd-0.9.git20221224/ext2fs/pager.c
@@ -643,7 +643,7 @@ pager_unlock_page (struct user_pager_inf
 	ext2_warning ("This filesystem is out of space.");
   else if (err)
 	ext2_warning ("inode=%Ld, page=0x%lx: %s",
-		  node->cache_id, page, strerror (err));
+		  node->cache_id, (unsigned long)page, strerror (err));
 
   return err;
 }
@@ -906,7 +906,7 @@ disk_cache_init (void)
 {
   if (block_size != vm_page_size)
 ext2_panic ("Block size %u != vm_page_size %lu",
-		block_size, vm_page_size);
+		block_size, (unsigned long)vm_page_size);
 
   pthread_mutex_init (_cache_lock, NULL);
   pthread_cond_init (_cache_reassociation, NULL);
Index: hurd-0.9.git20221224/mach-defpager/main.c
===
--- hurd-0.9.git20221224.orig/mach-defpager/main.c
+++ hurd-0.9.git20221224/mach-defpager/main.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 /* XXX */
 

Re: [PATCH] Add libraries to Makefiles.

[Svante Signell]

On Wed, 2023-01-18 at 11:54 +0100, Samuel Thibault wrote:
> 
> Then you need to check that the linking of e.g. storeio does use the
> shared library and not the static library. For instance you can re-run
> the corresponding linking command and add -Wl,-verbose to check in the
> verbose output which precise libstore file it takes.


/cross-tools/bin/i686-pc-gnu-gcc -L. -L../libbpf/ -L../libcons/ -
L../libdiskfs/ -L../libfshelp/ -L../libftpconn/ -L../libhurdbugaddr/ -
L../libhurd-slab/ -L../libihash/ -L../libiohelp/ -L../libmachdev/ -
L../libnetfs/ -L../libpager/ -L../libpipe/ -L../libports/ -L../libps/ -
L../libshouldbeinlibc/ -L../libstore/ -L../libtrivfs/ -Wl,-rpath-
link=../libbpf/ -Wl,-rpath-link=../libcons/ -Wl,-rpath-
link=../libdiskfs/ -Wl,-rpath-link=../libfshelp/ -Wl,-rpath-
link=../libftpconn/ -Wl,-rpath-link=../libhurdbugaddr/ -Wl,-rpath-
link=../libhurd-slab/ -Wl,-rpath-link=../libihash/ -Wl,-rpath-
link=../libiohelp/ -Wl,-rpath-link=../libmachdev/ -Wl,-rpath-
link=../libnetfs/ -Wl,-rpath-link=../libpager/ -Wl,-rpath-
link=../libpipe/ -Wl,-rpath-link=../libports/ -Wl,-rpath-link=../libps/
-Wl,-rpath-link=../libshouldbeinlibc/ -Wl,-rpath-link=../libstore/ -
Wl,-rpath-link=../libtrivfs/ -std=gnu99 -fgnu89-inline -Wall -g -O3 -
fno-strict-aliasing  -g -O2  -Wl,-verbose,-L/tools/lib -lblkid -luuid -
lz -lncursesw -ltinfow -ldl  -uargp_program_bug_address -o storeio \
  dev.o storeio.o open.o pager.o io.o \
  '-Wl,-(' ../libhurdbugaddr/libhurdbugaddr.so
../libtrivfs/libtrivfs.so ../libpager/libpager.so
../libfshelp/libfshelp.so ../libiohelp/libiohelp.so
../libstore/libstore.so ../libports/libports.so ../libihash/libihash.so
../libshouldbeinlibc/libshouldbeinlibc.so \
-lpthread -lz \
  '-Wl,-)'
...

attempt to open /tools/lib/libz.so succeeded
/tools/lib/libz.so

Same stuff when linking other executables, e.g. pflocal, pfinet, etc

Re: [PATCH] Fix some compiler warnings

[Svante Signell]

On Wed, 2023-01-18 at 02:02 +0100, Samuel Thibault wrote:
> Hello,
> 
> 
> But conversely when we'll build it in 64bit, vm_page_size (actually
> uintptr_t) will be an unsigned long.
> 
> This needs to be fixed the *proper* way: either use the PRIuPTR
> macro, or cast the value into unsigned long.

Now cast to an unsigned long, new patch attached.

Thanks!
Index: hurd-0.9.git20221224/ext2fs/ext2fs.c
===
--- hurd-0.9.git20221224.orig/ext2fs/ext2fs.c
+++ hurd-0.9.git20221224/ext2fs/ext2fs.c
@@ -233,7 +233,7 @@ main (int argc, char **argv)
 ext2_panic ("device too small for superblock (%Ld bytes)", store->size);
   if (store->log2_blocks_per_page < 0)
 ext2_panic ("device block size (%zu) greater than page size (%lu)",
-		store->block_size, vm_page_size);
+		store->block_size, (unsigned long)vm_page_size);
 
   /* Map the entire disk. */
   create_disk_pager ();
Index: hurd-0.9.git20221224/ext2fs/dir.c
===
--- hurd-0.9.git20221224.orig/ext2fs/dir.c
+++ hurd-0.9.git20221224/ext2fs/dir.c
@@ -415,7 +415,7 @@ dirscanblock (vm_address_t blockaddr, st
 	  || EXT2_DIR_REC_LEN (entry->name_len) > le16toh (entry->rec_len)
 	  || memchr (entry->name, '\0', entry->name_len))
 	{
-	  ext2_warning ("bad directory entry: inode: %Ld offset: %lu",
+	  ext2_warning ("bad directory entry: inode: %Ld offset: %u",
 			dp->cache_id,
 			currentoff - blockaddr + idx * DIRBLKSIZ);
 	  return ENOENT;
Index: hurd-0.9.git20221224/libpager/data-request.c
===
--- hurd-0.9.git20221224.orig/libpager/data-request.c
+++ hurd-0.9.git20221224/libpager/data-request.c
@@ -49,7 +49,7 @@ _pager_S_memory_object_data_request (str
 }
   if (length != __vm_page_size)
 {
-  printf ("incg data request: bad length size %lu\n", length);
+  printf ("incg data request: bad length size %u\n", length);
   goto release_out;
 }
   if (offset % __vm_page_size)
Index: hurd-0.9.git20221224/libpager/data-return.c
===
--- hurd-0.9.git20221224.orig/libpager/data-return.c
+++ hurd-0.9.git20221224/libpager/data-return.c
@@ -60,7 +60,7 @@ _pager_do_write_request (struct pager *p
 }
   if (length % __vm_page_size)
 {
-  printf ("incg data return: bad length size %lu\n", length);
+  printf ("incg data return: bad length size %u\n", length);
   goto release_out;
 }
   if (offset % __vm_page_size)
Index: hurd-0.9.git20221224/libpager/data-unlock.c
===
--- hurd-0.9.git20221224.orig/libpager/data-unlock.c
+++ hurd-0.9.git20221224/libpager/data-unlock.c
@@ -58,7 +58,7 @@ _pager_S_memory_object_data_unlock (stru
 }
   if (length != __vm_page_size)
 {
-  printf ("incg data unlock: bad length size %lu\n", length);
+  printf ("incg data unlock: bad length size %u\n", length);
   goto out;
 }
 
Index: hurd-0.9.git20221224/ext2fs/pager.c
===
--- hurd-0.9.git20221224.orig/ext2fs/pager.c
+++ hurd-0.9.git20221224/ext2fs/pager.c
@@ -642,7 +642,7 @@ pager_unlock_page (struct user_pager_inf
   if (err == ENOSPC)
 	ext2_warning ("This filesystem is out of space.");
   else if (err)
-	ext2_warning ("inode=%Ld, page=0x%lx: %s",
+	ext2_warning ("inode=%Ld, page=0x%x: %s",
 		  node->cache_id, page, strerror (err));
 
   return err;
@@ -905,7 +905,7 @@ static void
 disk_cache_init (void)
 {
   if (block_size != vm_page_size)
-ext2_panic ("Block size %u != vm_page_size %lu",
+ext2_panic ("Block size %u != vm_page_size %u",
 		block_size, vm_page_size);
 
   pthread_mutex_init (_cache_lock, NULL);
Index: hurd-0.9.git20221224/mach-defpager/main.c
===
--- hurd-0.9.git20221224.orig/mach-defpager/main.c
+++ hurd-0.9.git20221224/mach-defpager/main.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 /* XXX */
 

Re: [PATCH] Add libraries to Makefiles.

[Svante Signell]

On Wed, 2023-01-18 at 11:10 +0100, Samuel Thibault wrote:
> 
> That's not enough information: I'm asking about your cross-toolchain.
> 
> Do you actually get e.g. libstore/libstore.so for instance?
> If so, run objdump -x on it and check that libz is indeed in NEEDED.
> That's what is supposed to save having to add -lz everywhere.


/tools/lib/libstore.so
/tools/lib/libstore.so.0.3
objdump -x  /tools/lib/libstore.so.0.3 | less
Dynamic Section:
  NEEDED   libblkid.so.1
  NEEDED   libuuid.so.1
  NEEDED   libz.so
  NEEDED   libncursesw.so.6
  NEEDED   libtinfow.so.6
  NEEDED   libshouldbeinlibc.so.0.3
  NEEDED   libpthread.so.0.3
  NEEDED   libc.so.0.3
  NEEDED   libmachuser.so.1
  NEEDED   libhurduser.so.0.3
  SONAME   libstore.so.0.3
...

Re: [PATCH] Add libraries to Makefiles.

[Svante Signell]

On Wed, 2023-01-18 at 01:54 +0100, Samuel Thibault wrote:
> Hello,
> 
> But none of these directories are actually using libz, so it doesn't
> make sense to make them use -lz.
> 
> Are you sure that your cross-toolchain supports linking shared
> libraries?

Here are the configure flags:
   CPPFLAGS="-I$TARGET_ROOT/include -fno-omit-frame-pointer" \
   LDFLAGS="-L$TARGET_ROOT/lib -lblkid -luuid -lz -lncursesw -ltinfow -
ldl" \
   ../$HURD_SRC/configure \
  --build="$HOST" \
  --host="$TARGET" \
  --prefix="$TARGET_ROOT" \
  --without-parted \
  --enable-static-progs=ext2fs,iso9660fs,pci-arbiter \
  --with-ncursesw-include-dir="$TARGET_ROOT/include/ncursesw" \
  --with-libgcrypt-prefix="$TARGET_ROOT" \
  --with-libcrypt \
  --with-libz \
  --without-rump \
  --without-acpica \
  --without-libdaemon \
  --without-libbz2 \
  --without-rump \
  --enable-ncursesw \
  --disable-profile

Bug#1029097: pam: FTBFS on hurd-i386

[Svante Signell]

On Tue, 2023-01-17 at 18:49 +, Sam Hartman wrote:
> > > > > > "Svante" == Svante Signell 
> > > > > > writes:
>     Svante> modules_pam_nologin_tst-pam_nologin-retval.c.diff
> disabling
>     Svante> two subtests failing on GNU/Hurd.  -
> 
> Why do these subtests fail?
> 
tst-pam_nologin-retval.c:185: Assertion failed: PAM_SYSTEM_ERR (0x4) ==
pam_authenticate(pamh, 0) (0x6)
tst-pam_nologin-retval.c:189: Assertion failed: PAM_SYSTEM_ERR (0x4) ==
pam_acct_mgmt(pamh, 0) (0x6)

>     Svante> 
>     Svante> debian_libpam-modules-bin.install.hurd-i386.patch
> creating
>     Svante> an install file for Hurd excluding two systemd-specific
>     Svante> files not needed.
> 
> Why is installing these files harmful?
> I'm reluctant to take  this patch unless it actually breaks something
> and there's no other way to do it.
> If I take this patch, then I'll have to remember to update the hurd
> install list every time something changes.

I did not say they are harmful. They just weren't built/available in
the build tree during the installation of libpam-modules-bin, so that
failed.

(I've tried to add stuff like (arch=!hurd-any) ... to the .install
file. It seems like that such attempts does not work, as they for e.g.
.symbol files.)

I found the two missing files here though: modules/pam_namespace/
pam_namespace_helper
pam_namespace.service

Dunno why they are not found under the debian/ directory.

Thanks!

[PATCH] Add libraries to Makefiles.

[Svante Signell]

Hi,

The attached patch adds libraries needed when cross-building Hurd. Most
of them arise when enabling zlib with --with-libz.

Applies nicely to hurd-0.9.git20221224 and latest git.

Thanks!

--- hurd/boot/Makefile	2022-11-30 11:14:21.08400 +0100
+++ hurd/boot/Makefile	2022-12-02 15:31:09.73600 +0100
@@ -28,6 +28,6 @@
 MIGSFLAGS=-imacros $(srcdir)/mig-mutate.h -DHURD_DEFAULT_PAYLOAD_TO_PORT=1
 io-MIGSFLAGS=-DREPLY_PORTS -DHURD_DEFAULT_PAYLOAD_TO_PORT=1
 HURDLIBS = store shouldbeinlibc ihash
-LDLIBS += -lpthread
+LDLIBS += -lpthread $(and $(HAVE_LIBZ),-lz)
 
 include ../Makeconf
--- hurd/storeio/Makefile	2022-11-30 11:14:21.18800 +0100
+++ hurd/storeio/Makefile	2022-11-30 12:27:44.26800 +0100
@@ -24,6 +24,6 @@
 
 OBJS = $(SRCS:.c=.o)
 HURDLIBS = trivfs pager fshelp iohelp store ports ihash shouldbeinlibc
-LDLIBS = -lpthread
+LDLIBS = -lpthread $(and $(HAVE_LIBZ),-lz)
 
 include ../Makeconf
--- hurd/sutils/Makefile	2022-11-30 11:14:21.19200 +0100
+++ hurd/sutils/Makefile	2022-12-02 15:51:54.06400 +0100
@@ -29,6 +29,7 @@
 
 OBJS = $(progs:=.o)
 HURDLIBS = store shouldbeinlibc
+LDLIBS += $(and $(HAVE_LIBZ),-lz)
 
 include ../Makeconf
 
--- hurd/tmpfs/Makefile	2022-11-30 11:14:21.19200 +0100
+++ hurd/tmpfs/Makefile	2022-11-30 12:18:05.20400 +0100
@@ -24,6 +24,6 @@
 OBJS = $(SRCS:.c=.o) default_pagerUser.o
 # XXX The shared libdiskfs requires libstore even though we don't use it here.
 HURDLIBS = diskfs pager iohelp fshelp store ports ihash shouldbeinlibc
-LDLIBS = -lpthread
+LDLIBS = -lpthread $(and $(HAVE_LIBZ),-lz)
 
 include ../Makeconf
--- hurd/utils/Makefile	2022-11-30 11:14:21.19600 +0100
+++ hurd/utils/Makefile	2022-12-02 15:40:57.58400 +0100
@@ -35,7 +35,7 @@
 
 OBJS = $(filter-out %.sh,$(SRCS:.c=.o))
 HURDLIBS = ps ihash store fshelp ports ftpconn shouldbeinlibc
-LDLIBS += -lpthread
+LDLIBS += -lpthread $(and $(HAVE_LIBZ),-lz)
 login-LDLIBS = -lutil $(and $(HAVE_LIBCRYPT),-lcrypt)
 addauth-LDLIBS = $(and $(HAVE_LIBCRYPT),-lcrypt)
 setauth-LDLIBS = $(and $(HAVE_LIBCRYPT),-lcrypt)
--- hurd-git/mach-defpager/Makefile	2022-12-03 16:44:52.84800 +0100
+++ hurd-git/mach-defpager/Makefile	2022-12-08 21:27:32.33600 +0100
@@ -30,7 +30,7 @@
 	   default_pager_replyUser.o
 
 HURDLIBS:= ihash shouldbeinlibc
-LDLIBS:= -lpthread
+LDLIBS:= -lpthread -lhurduser
 
 include ../Makeconf
 
--- hurd/trans/Makefile	2019-12-18 19:29:43.94000 +0100
+++ hurd/trans/Makefile	2019-12-22 00:37:06.65600 +0100
@@ -62,7 +62,7 @@
 ifeq ($(HAVE_LIBGCRYPT),yes)
  SRCS += random.c
  targets += random
- random-LDLIBS = -lgcrypt
+ random-LDLIBS = -lgcrypt -lgpg-error
  random: startup_notifyServer.o mach_debugUser.o ../libtrivfs/libtrivfs.a
 endif
 

[PATCH] Fix some compiler warnings

[Svante Signell]

Hi,

The attached patch fixes some format warnings as well as an implicit
declaration of ‘startup_essential_task’ in mach-defpager/main.c.

Applies nicely to hurd-0.9.git20221224 and latest git.

Thanks!
--- hurd-git/ext2fs/ext2fs.c	2022-12-08 15:05:29.80800 +0100
+++ hurd-git/ext2fs/ext2fs.c	2022-12-08 19:11:12.60400 +0100
@@ -232,7 +232,7 @@
   if (store->size < SBLOCK_OFFS + SBLOCK_SIZE)
 ext2_panic ("device too small for superblock (%Ld bytes)", store->size);
   if (store->log2_blocks_per_page < 0)
-ext2_panic ("device block size (%zu) greater than page size (%lu)",
+ext2_panic ("device block size (%zu) greater than page size (%u)",
 		store->block_size, vm_page_size);
 
   /* Map the entire disk. */
--- hurd-git/ext2fs/dir.c	2022-12-03 16:44:52.78000 +0100
+++ hurd-git/ext2fs/dir.c	2022-12-09 11:35:05.29600 +0100
@@ -415,7 +415,7 @@
 	  || EXT2_DIR_REC_LEN (entry->name_len) > le16toh (entry->rec_len)
 	  || memchr (entry->name, '\0', entry->name_len))
 	{
-	  ext2_warning ("bad directory entry: inode: %Ld offset: %lu",
+	  ext2_warning ("bad directory entry: inode: %Ld offset: %u",
 			dp->cache_id,
 			currentoff - blockaddr + idx * DIRBLKSIZ);
 	  return ENOENT;
--- hurd-git/libpager/data-request.c	2022-12-08 15:05:29.81200 +0100
+++ hurd-git/libpager/data-request.c	2022-12-09 11:23:20.41200 +0100
@@ -49,7 +49,7 @@
 }
   if (length != __vm_page_size)
 {
-  printf ("incg data request: bad length size %lu\n", length);
+  printf ("incg data request: bad length size %u\n", length);
   goto release_out;
 }
   if (offset % __vm_page_size)
--- hurd-git/libpager/data-return.c	2022-12-08 15:05:29.81200 +0100
+++ hurd-git/libpager/data-return.c	2022-12-09 11:24:56.80400 +0100
@@ -60,7 +60,7 @@
 }
   if (length % __vm_page_size)
 {
-  printf ("incg data return: bad length size %lu\n", length);
+  printf ("incg data return: bad length size %u\n", length);
   goto release_out;
 }
   if (offset % __vm_page_size)
--- hurd-git/libpager/data-unlock.c	2022-12-08 15:05:29.81200 +0100
+++ hurd-git/libpager/data-unlock.c	2022-12-09 11:26:07.95600 +0100
@@ -58,7 +58,7 @@
 }
   if (length != __vm_page_size)
 {
-  printf ("incg data unlock: bad length size %lu\n", length);
+  printf ("incg data unlock: bad length size %u\n", length);
   goto out;
 }
 
--- hurd-git/ext2fs/pager.c	2022-12-08 15:05:29.81200 +0100
+++ hurd-git/ext2fs/pager.c	2022-12-08 19:23:39.85600 +0100
@@ -642,7 +642,7 @@
   if (err == ENOSPC)
 	ext2_warning ("This filesystem is out of space.");
   else if (err)
-	ext2_warning ("inode=%Ld, page=0x%lx: %s",
+	ext2_warning ("inode=%Ld, page=0x%x: %s",
 		  node->cache_id, page, strerror (err));
 
   return err;
@@ -905,7 +905,7 @@
 disk_cache_init (void)
 {
   if (block_size != vm_page_size)
-ext2_panic ("Block size %u != vm_page_size %lu",
+ext2_panic ("Block size %u != vm_page_size %u",
 		block_size, vm_page_size);
 
   pthread_mutex_init (_cache_lock, NULL);
--- hurd-git/mach-defpager/main.c	2022-12-04 14:53:41.23200 +0100
+++ hurd-git/mach-defpager/main.c	2022-12-09 11:53:44.37200 +0100
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 /* XXX */
 

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#1029050: gcc-snapshot: FTBFS on hurd-i386 (and other archs?)

[Svante Signell]

Source: gcc-snapshot
Version: 20230108-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1029050: gcc-snapshot: FTBFS on hurd-i386 (and other archs?)

[Svante Signell]

Source: gcc-snapshot
Version: 20230108-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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!

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

[Svante Signell via Gcc-patches]

Source: gcc-snapshot
Version: 20230108-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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!

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

[Svante Signell via Gcc-bugs]

Source: gcc-snapshot
Version: 20230108-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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#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#1027840: gcc-11: FTBFS on hurd-i386

[Svante Signell]

Source: gcc-11
Version: 11.3.0-10
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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

gcc-11: FTBFS on hurd-i386

[Svante Signell via Gcc-patches]

Source: gcc-11
Version: 11.3.0-10
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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

gcc-11: FTBFS on hurd-i386

[Svante Signell via Gcc-bugs]

Source: gcc-11
Version: 11.3.0-10
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Svante Signell]

On Thu, 2022-12-15 at 12:17 +0100, Svante Signell wrote:
> 
> Hi,
> 
> The problem is probably that you need to add --enable-add-ons=libpthread to
> configure when building first version of cross-glibc. This is to obtain weak
> references when building libcstd++ of cross-gcc:
> 
> nm --dynamic /cross-tools/lib/libstdc++.so.6.0.30|grep pthread
> ...
> w __pthread_key_create
> w pthread_key_create
> w pthread_key_delete

I've been looking into this problem a little further: You need the attached
patch: libstdc++-hurd.diff, at least for gcc-11 and gcc-12 (and probably gcc-13
too)


Good luck!
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

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Svante Signell]

On Thu, 2022-12-15 at 01:24 -0600, Nathan Dehnel wrote:
> You could try seeing what they're doing here to cross-build
> https://github.com/flavioc/cross-hurd
> It worked last time I ran it (which was admittedly a while ago)

Hi,

The problem is probably that you need to add --enable-add-ons=libpthread to
configure when building first version of cross-glibc. This is to obtain weak
references when building libcstd++ of cross-gcc:

nm --dynamic /cross-tools/lib/libstdc++.so.6.0.30|grep pthread
...
w __pthread_key_create
w pthread_key_create
w pthread_key_delete
...

Then that build of cross-gcc will succeed in building the Hurd version of
libstdc++ etc.
nm --dynamic /tools/lib/libstdc++.so.6.0.30|grep pthread


The problem is due to that with recent versions of glibc libpthread is included
for Linux, but not for Hurd.

Note that don't issue autoreconf gcc (in my case 12.2.0) unless you have only
autoconf2.69 installed (or what is needed for your version of upstream gcc).

My scripts to cross-build Hurd on Debian/GNU Linux: hurd-cross (hurdX) will soon
be published on Savannah under the Hurd umbrella. Note the name difference:
hurd-cross vs cross-hurd. As of current these scripts include up-to-date
versions of all packages used, with git versions of mig, gnumach and hurd.

(The scripts of hurd-cross were based on the work by Flavio in 2019, thank you
Flavio. However they have diverged considerably since then, and are not easily
merged into his work at github)

Good luck!

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #30, sr #110199 (project administration):

Hi again.

Is this support issue still open? If so I plan to upload an updated tarball
RSN.

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #30, sr #110199 (project administration):

Hi again.

Is this support issue still open? If so I plan to upload an updated tarball
RSN.

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

Re: GNU Guix 1.4.0rc1 available for testing!

[Svante Signell]

On Thu, 2022-12-01 at 10:17 +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> The first release candidate of the upcoming 1.4.0 release is now
> available for testing:

What about hurd?

Re: GNU Guix 1.4.0rc1 available for testing!

[Svante Signell]

On Thu, 2022-12-01 at 10:17 +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> The first release candidate of the upcoming 1.4.0 release is now
> available for testing:

What about hurd?

Bug#970659: GNU/Hurd patch submitted upstream #1796917

[Svante Signell]

Hi,

The attached patch for the build problem on GNU/Hurd (same as the one from 2020)
was submitted upstream. Upstream bug number: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1796917

Thanks!

Index: nspr-4.28/nspr/pr/src/pthreads/ptsynch.c
===
--- nspr-4.28.orig/nspr/pr/src/pthreads/ptsynch.c
+++ nspr-4.28/nspr/pr/src/pthreads/ptsynch.c
@@ -50,7 +50,7 @@ void _PR_InitLocks(void)
 rv = _PT_PTHREAD_MUTEXATTR_INIT(&_pt_mattr);
 PR_ASSERT(0 == rv);
 
-#if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)) || \
+#if (defined(LINUX) && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2))) || \
 (defined(FREEBSD) && __FreeBSD_version > 700055)
 rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP);
 PR_ASSERT(0 == rv);

Bug#970659: nspr: FTBFS on hurd-i386 and tests fails to run.

[Svante Signell]

found 970659 2:4.35-1
found 970673 2:4.35-1
thanks

Hello again,
(bug reports first filed on 20+21 september 2020 against 4.28-1)

nspr still FTBFS on GNU/Hurd due to a one-line error in the file 
nspr/pr/src/pthreads/ptsynch.c, see #970659. Additionally tests in runtest.sh
are not run due to a bug in debian/rules, see #970673.

The first problem is solved by adding a condition on __GNU__ in the ptsynch.c
file. Secondly, the missing tests are run by replacing sh - with sh -s in
debian/rules for all tests.

Note that tests for gethost\|getproto\|nblayer\|socket\|vercheck are already
commented out in runtests.sh and not needed. Additionally sema tests needs to be
excluded for GNU/Hurd.

The patches debian/rules.patch and nspr_pr_src_pthreads_ptsynch.c.diff, somewhat
modified with respect to earlier patches, are attached for convenience.

Built and tests run successfully on both GNH/Hurd i386 and GNU/Linux amd64.

Thanks!
--- a/debian/rules	2022-10-17 23:15:00.0 +0200
+++ b/debian/rules	2022-10-17 23:19:20.0 +0200
@@ -84,7 +84,12 @@
 	# Skip socket because it freezes.
 	# Skip getproto because it fails on some buildds.
 	# Skip nblayer because it freezes on armel.
-	cd nspr/pr/tests && grep -v '^\(fdcach\|gethost\|getproto\|nblayer\|peek\|socket\|vercheck\)$$' ./runtests.sh | sh - $(CURDIR)/nspr/dist
+ifneq (hurd,$(shell dpkg-architecture -qDEB_HOST_ARCH_OS))
+	cd nspr/pr/tests && grep -v '^\(fdcach\|peek\)$$' ./runtests.sh | sh -s $(CURDIR)/nspr/dist
+else
+ 	# Skip semaphore tests: not implemented on GNU/Hurd.
+	cd nspr/pr/tests && grep -v '^\(sema\|semaerr\|semaping\)$$' ./runtests.sh | sh -s $(CURDIR)/nspr/dist
+endif
 	cd nspr/lib/tests && LD_LIBRARY_PATH=$(CURDIR)/nspr/dist/bin$(addprefix :,$(LD_LIBRARY_PATH)) ./base64t
 	cd nspr/lib/tests && LD_LIBRARY_PATH=$(CURDIR)/nspr/dist/bin$(addprefix :,$(LD_LIBRARY_PATH)) ./string
 endif
Index: nspr-4.35/nspr/pr/src/pthreads/ptsynch.c
===
--- nspr-4.35.orig/nspr/pr/src/pthreads/ptsynch.c
+++ nspr-4.35/nspr/pr/src/pthreads/ptsynch.c
@@ -50,7 +50,8 @@ void _PR_InitLocks(void)
 rv = _PT_PTHREAD_MUTEXATTR_INIT(&_pt_mattr);
 PR_ASSERT(0 == rv);
 
-#if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)) || \
+#if (defined(LINUX) && (__GLIBC__ > 2) || \
+(__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2))  && !defined(__GNU__) || \
 (defined(FREEBSD) && __FreeBSD_version > 700055)
 rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP);
 PR_ASSERT(0 == rv);

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-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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#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#1021357: gcc-12: FTBFS on hurd-i386

[Svante Signell]

Source: gcc-12
Version: 12_12.2.0-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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 

gcc-12: FTBFS on hurd-i386

[Svante Signell via Gcc-patches]

Source: gcc-12
Version: 12_12.2.0-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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 

gcc-12: FTBFS on hurd-i386

[Svante Signell via Gcc-bugs]

Source: gcc-12
Version: 12_12.2.0-5
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@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#1021260: libdumbnet: FTBFS on hurd-i386

[Svante Signell]

Source: libdumbnet
Version: 1.16.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@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#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Svante Signell]

Hi,

I would really appreciate if you quote your reply properly:
It was not Andreas Metzler who sent the below:

> On Tue, 2022-09-27 at 18:25 +0200, Andreas Metzler wrote:
> > On 2022-09-27 Zack Weinberg  wrote:
> > [...]

On Wed, 2022-09-28 at 11:55 +0100, Luca Boccassi wrote:

> > 
> > > This number is of usrmerged systems is so large that we cannot mark
> > > them as unsupported ("Please reinstall"). Whether this percentage
> > > is 25% or 90% does not matter.
> > 
> > You can easily revert any system having usrmerge installed with dpkg-
> > fsys-usrunmess. This should be known by all Debian users, by some
> > suitable channel.
> > 
> > And for example the latest init-system-helpers release should add
> > this to the package description (if not reverted). This applies to
> > other present and future packages having usrmerge as a dependency
> > too.
> 
> Please note that this will result in an unsupported system, as per CTTE
> decision. It is important to note this, for the record. So no, that
> will not be added anywhere, package description or otherwise, and in
> fact the last time it was "made known by all Debian users" it caused
> quite a lot of damage, and was forcefully reverted.

Please learn how to properly quote/reply to peoples postings :(

Thanks!

Re: Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Svante Signell]

Hi,

I would really appreciate if you quote your reply properly:
It was not Andreas Metzler who sent the below:

> On Tue, 2022-09-27 at 18:25 +0200, Andreas Metzler wrote:
> > On 2022-09-27 Zack Weinberg  wrote:
> > [...]

On Wed, 2022-09-28 at 11:55 +0100, Luca Boccassi wrote:

> > 
> > > This number is of usrmerged systems is so large that we cannot mark
> > > them as unsupported ("Please reinstall"). Whether this percentage
> > > is 25% or 90% does not matter.
> > 
> > You can easily revert any system having usrmerge installed with dpkg-
> > fsys-usrunmess. This should be known by all Debian users, by some
> > suitable channel.
> > 
> > And for example the latest init-system-helpers release should add
> > this to the package description (if not reverted). This applies to
> > other present and future packages having usrmerge as a dependency
> > too.
> 
> Please note that this will result in an unsupported system, as per CTTE
> decision. It is important to note this, for the record. So no, that
> will not be added anywhere, package description or otherwise, and in
> fact the last time it was "made known by all Debian users" it caused
> quite a lot of damage, and was forcefully reverted.

Please learn how to properly quote/reply to peoples postings :(

Thanks!

Re: doxygen: FTBFS on hurd-i386

[Svante Signell]

On Wed, 2022-09-28 at 17:50 +0200, Samuel Thibault wrote:
> Control: forwarded -1 https://github.com/doxygen/doxygen/pull/9514
> 
> Svante Signell, le mer. 28 sept. 2022 17:40:32 +0200, a ecrit:
> > Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue.
> 
> This issue was already forwarded upstream on
> https://github.com/doxygen/doxygen/pull/9514
> 
> they said it was actually imported from another project:
> https://github.com/gulrak/filesystem/pull/154
> 
> In the meanwhile we already have patched version 1.9.4-2+hurd.1
> available in unreleased.

Thanks, I did not know about this. Maybe you can create a version
1.9.4-3.hurd.1 version to avoid doxygen-latex not being held when
upgrading. (when upgrading/dist-upgrading it is very annoying to see
these messages).

Thanks again, your solution is much better than mine (though very
similar).

thanks!