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

[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 #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/

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

[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 */
 

[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: 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!

socat: FTBFS on hurd-i386

[Svante Signell]

Source: socat
Version: 1.7.4.3-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Cc: bug-hurd

Hi,

Currently socat FTBFS on GNU/Hurd due to differing values for O_RDONLY,
O_WRONLY and O_RDWR compared to Linux systems.

The attached patch, xioinitialize.c.patch, fixes the build problem.
Unfortunately, since util-linux build-depends on socat, that package
cannot be built.

A problem is that socat depends on netstat or ip to function properly,
and is used in the tests, not being available for GNU/Hurd. So building
the package w/o tests is recommended. (No patch is attached to disable
tests in this posting).

Additionally ifconfig is needed for the tests, but probably inetutils-
ifconfig can be used as a replacement. That package just need to add a
link of /usr/bin/inetutils-ifconfig to /sbin/ifconfig.

Thanks!





--- a/xioinitialize.c	2019-04-04 10:59:55.0 +0200
+++ b/xioinitialize.c	2022-09-02 19:20:22.0 +0200
@@ -27,10 +27,15 @@
assert(sizeof(uint32_t)==4);
 
/* assertions regarding O_ flags - important for XIO_READABLE() etc. */
+#ifdef __GNU__
+   assert(O_RDONLY==1);
+   assert(O_WRONLY==2);
+   assert(O_RDWR==3);
+#else
assert(O_RDONLY==0);
assert(O_WRONLY==1);
assert(O_RDWR==2);
-
+#endif
assert(SHUT_RD==0);
assert(SHUT_WR==1);
assert(SHUT_RDWR==2);

doxygen: FTBFS on hurd-i386

[Svante Signell]

Source: doxygen
Version: 1.9.4-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue.

The attached patch, filesystem_filesystem.hpp.diff, fixes the build
problem by special-casing for Hurd. In fact the patch could be applied
to all glibc-based systems and upstreamed. 

However, it is not very C++-ish, maybe some better solution could be
used. Cc-ing bug-hurd for comments, WDYT?

Thanks!




Index: doxygen-1.9.4/filesystem/filesystem.hpp
===
--- doxygen-1.9.4.orig/filesystem/filesystem.hpp
+++ doxygen-1.9.4/filesystem/filesystem.hpp
@@ -56,6 +56,8 @@
 #define GHC_OS_MACOS
 #elif defined(__linux__)
 #define GHC_OS_LINUX
+#elif defined(__GNU__)
+#define GHC_OS_GNU
 #if defined(__ANDROID__)
 #define GHC_OS_ANDROID
 #endif
@@ -4081,6 +4083,13 @@ GHC_INLINE path current_path(std::error_
 return path();
 }
 return path(std::wstring(buffer.get()), path::native_format);
+#elif defined(GHC_OS_GNU)
+char* buffer = ::getcwd (NULL, 0);
+if (buffer == nullptr) {
+ec = detail::make_system_error();
+return path();
+}
+return path(buffer);
 #else
 size_t pathlen = static_cast(std::max(int(::pathconf(".", _PC_PATH_MAX)), int(PATH_MAX)));
 std::unique_ptr buffer(new char[pathlen + 1]);

[PATCH] Uncouple netfs_make_protid (netfs_make_peropen()) function calls in Hurd.

[Svante Signell]

Hello,

Attached are two patches, hopefully useful in decoupling the nested function
calls in libnetfs: netfs_make_protid (netfs_make_peropen()). Hopefully, the
patches is useful to enhance error tracking. Due to indentation differences they
are larger than they would be if not.

GIT/hurd:
This patch applies to the upstream GIT repo:
0001-Uncouple-nested-function-calls-netfs_make_protid-net.patch

Debian/hurd:
This patch is for Debian:
0043-Uncouple-nested-function-calls-netfs_make_protid-net.patch
It is modified to account for the changes to libnetfs/file-exec.c in
0041-libnetfs-libtrivs-Shield-S_file_exec_paths-from-canc.patch
not yet committed upstream.

The attached patches could be broken down to a series of patches, one for each
C-file. However, the function interface for netfs_make_peropen() and
netfs_make_protid() is preferably the same as the corresponding functions in
libdiskfs. If/when making such changes all functions and function calls would
have to be modified simultaneously.

Thanks!

From a36202019dcc92d5b8058002ba427de3923c6a1c Mon Sep 17 00:00:00 2001
From: Svante Signell 
Date: Thu, 20 Jan 2022 16:11:44 +0100
Subject: [PATCH] Uncouple nested function calls
 netfs_make_protid(netfs_make_peropen()) in order to enhance error tracking.

---
 libnetfs/dir-lookup.c| 80 +++-
 libnetfs/dir-mkfile.c| 36 ++
 libnetfs/file-exec.c | 63 +--
 libnetfs/file-reparent.c | 25 +
 libnetfs/fsys-getroot.c  | 18 +++--
 libnetfs/make-peropen.c  | 11 +-
 trans/fakeroot.c | 14 +--
 7 files changed, 155 insertions(+), 92 deletions(-)

diff --git a/libnetfs/dir-lookup.c b/libnetfs/dir-lookup.c
index 87874dc5..00e3a08f 100644
--- a/libnetfs/dir-lookup.c
+++ b/libnetfs/dir-lookup.c
@@ -48,6 +48,7 @@ netfs_S_dir_lookup (struct protid *dircred,
   char *relpath;
   error_t err;
   struct protid *newpi = NULL;
+  struct peropen *newpo = NULL;
   struct iouser *user;
 
   if (!dircred)
@@ -223,13 +224,18 @@ netfs_S_dir_lookup (struct protid *dircred,
 	  err = iohelp_create_empty_iouser ();
 	  if (! err)
 	{
-	  newpi = netfs_make_protid (netfs_make_peropen (dnp, 0,
-			 dircred->po),
-	 user);
-	  if (! newpi)
-	{
-		  err = errno;
-		  iohelp_free_iouser (user);
+	  newpo = netfs_make_peropen (dnp, 0, dircred->po);
+	  if (! newpo)
+		  err = errno;
+	  if (! err)
+		{
+		  newpi = netfs_make_protid (newpo, user);
+		  if (! newpi)
+		{
+		  err = errno;
+		  netfs_release_peropen (newpo);
+		  iohelp_free_iouser (user);
+		}
 		}
 	}
 
@@ -427,36 +433,42 @@ netfs_S_dir_lookup (struct protid *dircred,
   if (err)
 goto out;
 
-  newpi = netfs_make_protid (netfs_make_peropen (np, flags, dircred->po),
-			 user);
-  if (! newpi)
+  newpo = netfs_make_peropen (np, flags, dircred->po);
+  if (! newpo)
+err = errno;
+  if (! err)
 {
-  iohelp_free_iouser (user);
-  err = errno;
-  goto out;
-}
+  newpi = netfs_make_protid (newpo, user);
+  if (! newpi)
+	{
+	  err = errno;
+	  netfs_release_peropen (newpo);
+	  iohelp_free_iouser (user);
+	  goto out;
+	}
 
-  mach_port_t rendezvous = MACH_PORT_NULL;
-  struct flock64 lock =
-{
-l_start: 0,
-l_len: 0,
-l_whence: SEEK_SET
-};
+  mach_port_t rendezvous = MACH_PORT_NULL;
+  struct flock64 lock =
+	{
+	l_start: 0,
+	l_len: 0,
+	l_whence: SEEK_SET
+	};
 
-  if (flags & O_EXLOCK)
-{
-  lock.l_type = F_WRLCK;
-  err = fshelp_rlock_tweak (>userlock, >lock,
->po->lock_status, flags, 0, 0,
-F_SETLK64, , rendezvous);
-}
-  else if (flags & O_SHLOCK)
-{
-  lock.l_type = F_RDLCK;
-  err = fshelp_rlock_tweak (>userlock, >lock,
->po->lock_status, flags, 0, 0,
-F_SETLK64, , rendezvous);
+  if (flags & O_EXLOCK)
+	{
+	  lock.l_type = F_WRLCK;
+	  err = fshelp_rlock_tweak (>userlock, >lock,
+>po->lock_status, flags, 0, 0,
+F_SETLK64, , rendezvous);
+	}
+  else if (flags & O_SHLOCK)
+	{
+	  lock.l_type = F_RDLCK;
+	  err = fshelp_rlock_tweak (>userlock, >lock,
+>po->lock_status, flags, 0, 0,
+F_SETLK64, , rendezvous);
+	}
 }
 
   if (! err)
diff --git a/libnetfs/dir-mkfile.c b/libnetfs/dir-mkfile.c
index 6cd79174..62715fa6 100644
--- a/libnetfs/dir-mkfile.c
+++ b/libnetfs/dir-mkfile.c
@@ -1,4 +1,4 @@
-/* 
+/*
Copyright (C) 1995,96,97,2001 Free Software Foundation, Inc.
Written by Michael I. Bushnell, p/BSG.
 
@@ -23,13 +23,14 @@
 #include "fs_S.h"
 
 error_t
-netfs_S_dir_mkfile (struct protid *diruser, int flags, mode_t mode, 
+netfs_S_dir_mkfile (struct protid *diruser, int flags, mode_t mode,
 		mach_port_t *newfile, mach_msg_type_name_t *newfiletype)
 {
   error_t err;
   struct node *np;
   struct iouser *user;
   struct pr

Re: Dropping gdc support?

[Svante Signell]

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

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

Re: Dropping gdc support?

[Svante Signell]

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

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

Porting Valgrind to GNU/Hurd: Re: Need help with assembly code

[Svante Signell]

On Tue, 2021-11-30 at 22:22 +, jbra...@dismail.de wrote:
> November 29, 2021 12:41 PM, "Svante Signell"
>  wrote:
> 
> > Hello,
> > 
> > I've been working lately with on how to port valgrind to GNU/Hurd,
> > and found out that this is not a trivial task. Seems like one have
> > to make a suitable mix of linux and darwin code (and to some extent
> > freebsd/solaris code). Being a novice on assembly programming I
> > need some help on modifying the Darwin code for syscall-x86-
> > darwin.S to GNU. The following code snippet fails to
> > compile with gcc/gas:
> > 
> 
> Best of luck!

Hi Joshua,

Thank you for your encouragement. Even though that I did get "a lot of
help and encouragement from Samuel" I decided to give it up. I'll reply
later on with a combined patch of what I did so far. The patch touches
around 80+ modified and new files of valgrind-3.18.1 for GNU/Hurd.

Note: Valgrind does build but is not usable due to e.g.:

- assembly code I don't have knowledge or control of.
- How to combine Hurd RPCs with the existing code.
- How to combine gnumach code with the existing code (especially
kernel_traps) (this stuff I could probably solve myself). Darwin port
of Valgrind has some code that could be used for GNU/Hurd.
Unfortunately the RPC stuff is not implemented yet. Other means are
used with the help of mach_msg and mach_msg_trap. Unfortunately, that
would not help until the Hurd RPCs are supported.

Anybody willing to continue this effort is very welcome :)

Or if somebody is interested in being a mentor for the port I would be
seriously considering carrying on.

Thanks!

Re: Need help with assembly code

[Svante Signell]

On Mon, 2021-11-29 at 22:19 +0100, Samuel Thibault wrote:
> Hello,
> 
> Svante Signell, le lun. 29 nov. 2021 18:40:48 +0100, a ecrit:
> > I've been working lately with on how to port valgrind to GNU/Hurd, and found
> > out that this is not a trivial task.
> 
> It is indeed very far from a trivial task. I'd rather recommend to port
> gcc's lsan support, it will be most probably much easier to port.

Maybe it is. I might look into that later on. Thanks for the tip.

> > Seems like one have to make a suitable mix of linux and darwin code
> > (and to some extent freebsd/solaris code).
> 
> Also it'd need a fair amount of code to reimplement the basic posixish
> needs of valgrind in terms of the Hurd RPCs.

Do you mean that Darwin does not use RPCs? Seems like valgrind has some 
RPC-code 
for Darwin already. In fact there is a directory containing mach code:
coregrind/m_mach/ but most *.defs code is absent. Basically only mach_msg and
mach_msg_trap are defined (and nothing about Hurd RPCs of course).

> > 
> > movl$$__NR___pthread_sigmask, %eax
> > int $$0x80  /* should be sysenter? */
> > jc  L_$0_7  /* __pthread_sigmask failed */

> Mach doesn't use int 0x80 but an lcall. See for instance
> glibc/sysdeps/mach/i386/syscall.S

Can't 0x80 just be replaced by lcall? Probably not. Looking at the x86-specific
assembly code for all architectures 0x80 seems to be used everywhere.

Additionally: My question was about the macro definition with an option
argument:
/* DO_SYSCALL MACH|MDEP|UNIX */
#define MACH 1
#define MDEP 2
#define UNIX 3

.macro DO_SYSCALL 

.endm

.globl ML_(do_syscall_for_client_unix_WRK)
ML_(do_syscall_for_client_unix_WRK):
DO_SYSCALL UNIX

.globl ML_(do_syscall_for_client_mach_WRK)
ML_(do_syscall_for_client_mach_WRK):
DO_SYSCALL MACH

.globl ML_(do_syscall_for_client_mdep_WRK)
ML_(do_syscall_for_client_mdep_WRK):
DO_SYSCALL MDEP

Need help with assembly code

[Svante Signell]

Hello,

I've been working lately with on how to port valgrind to GNU/Hurd, and found out
that this is not a trivial task. Seems like one have to make a suitable mix of
linux and darwin code (and to some extent freebsd/solaris code). Being a novice
on assembly programming I need some help on modifying the Darwin code for 
syscall-x86-darwin.S to GNU. The following code snippet fails to compile with
gcc/gas:

#define VKI_SIG_SETMASK 3
/* DO_SYSCALL MACH|MDEP|UNIX */
#define MACH 1
#define MDEP 2
#define UNIX 3

.macro DO_SYSCALL
/* establish stack frame */
push%ebp
mov %esp, %ebp
subl$$8, %esp   /* 16-byte align stack */

L_$0_1: /* Even though we can't take a signal until the
   __pthread_sigmask completes, start the range early.
   If eip is in the range [1,2), the syscall hasn't been started yet */

/* Set the signal mask which should be current during the syscall. */
/* Set up for __pthread_sigmask(SIG_SETMASK, sysmask, postmask) */
pushl   20(%ebp)
pushl   16(%ebp)
pushl   $$VKI_SIG_SETMASK
pushl   $$0xcafebabe/* totally fake return address */
movl$$__NR___pthread_sigmask, %eax
int $$0x80  /* should be sysenter? */
jc  L_$0_7  /* __pthread_sigmask failed */
addl$$16,%esp

L_$0_2:
.if $0 == UNIX
int $$0x80  /* UNIX (GrP fixme should be sysenter?) */
.elseif $0 == MACH
int $$0x81
.elseif $0 == MDEP
int $$0x82
.else
error$0 x
.endif

L_ $0_3: ...

.endm (.endmacro gives: Error: unexpected end of file in macro `do_syscall'
 definition)

.globl ML_(do_syscall_for_client_unix_WRK)
ML_(do_syscall_for_client_unix_WRK):
DO_SYSCALL UNIX
(additional code for DO_SYSCALL MACH/MDEP)

.data
#define FOO(scclass,labelno) L_##scclass##_##labelno
#define MK_L_SCCLASS_N(scclass,labelno) FOO(scclass,labelno)

.globl ML_(blksys_setup_UNIX)
.globl ML_(blksys_restart_UNIX)
.globl ML_(blksys_complete_UNIX)
.globl ML_(blksys_committed_UNIX)
.globl ML_(blksys_finished_UNIX)
ML_(blksys_setup_UNIX): .long MK_L_SCCLASS_N(UNIX,1)
ML_(blksys_restart_UNIX):   .long MK_L_SCCLASS_N(UNIX,2)
ML_(blksys_complete_UNIX):  .long MK_L_SCCLASS_N(UNIX,3)
ML_(blksys_committed_UNIX): .long MK_L_SCCLASS_N(UNIX,4)
ML_(blksys_finished_UNIX):  .long MK_L_SCCLASS_N(UNIX,5)

(additional code for MACH/MDEP)

Compiling results in: 
m_syswrap/syscall-x86-gnu.S:196: Error: too many positional arguments (3 times)

How to change the macro definition to accept aruments?
Is the code OK also for GNU/Hurd?

Thanks!

RFC: Comments on patches for libdrm are welcomed

[Svante Signell]

Hello,

After the patches sent to the libdrm package in #909436 was removed with version
2.4.103-2 due to bug #975658 causing problems with an "Invalid read after the
end of block in xf86drm.c" a year ago nothing happened. I've now taken up the
patches again, and try to solve the issues of the hurd port of libdrm. Attached
are the latest effort to fix this, hurd-port.diff and path_max.diff. Comments on
the patches are really appreciated. If OK, I'll resend them to  #909436 and
upstream so Hurd can be properly supported.

One alternative to the path_max.diff patch is to simply do:
#ifndef PATH_MAX
#define PATH_MAX 4096
#endif
in xf86drm.c. This is a patch that upstream would accept more easily than the
proposed one, but is not very Hurdish.

WDYT?

Thanks!
Index: libdrm-2.4.107/include/drm/drm.h
===
--- libdrm-2.4.107.orig/include/drm/drm.h
+++ libdrm-2.4.107/include/drm/drm.h
@@ -42,6 +42,22 @@
 #include 
 typedef unsigned int drm_handle_t;
 
+#elif defined(__GNU__)
+
+#include 
+#include 
+#include 
+typedef __int8_t   __s8;
+typedef __uint8_t  __u8;
+typedef __int16_t  __s16;
+typedef __uint16_t __u16;
+typedef __int32_t  __s32;
+typedef __uint32_t __u32;
+typedef __int64_t  __s64;
+typedef __uint64_t __u64;
+typedef size_t   __kernel_size_t;
+typedef unsigned int drm_handle_t;
+
 #else /* One of the BSDs */
 
 #include 
Index: libdrm-2.4.107/xf86drm.h
===
--- libdrm-2.4.107.orig/xf86drm.h
+++ libdrm-2.4.107/xf86drm.h
@@ -58,8 +58,14 @@ extern "C" {
 
 #else /* One of the *BSDs */
 
+#if defined(__GNU__)
+#include 
+#include 
+#define DRM_IOCTL_NR(n) _IOC_COMMAND(n)
+#else
 #include 
 #define DRM_IOCTL_NR(n) ((n) & 0xff)
+#endif
 #define DRM_IOC_VOIDIOC_VOID
 #define DRM_IOC_READIOC_OUT
 #define DRM_IOC_WRITE   IOC_IN
Index: libdrm-2.4.107/xf86drm.c
===
--- libdrm-2.4.107.orig/xf86drm.c
+++ libdrm-2.4.107/xf86drm.c
@@ -3359,7 +3359,8 @@ static char *drmGetMinorNameForFD(int fd
 return strdup(name);
 #else
 struct stat sbuf;
-char buf[PATH_MAX + 1];
+char *buf = NULL;
+int len = 0;
 const char *dev_name = drmGetDeviceName(type);
 unsigned int maj, min;
 int n;
@@ -3376,11 +3377,19 @@ static char *drmGetMinorNameForFD(int fd
 if (!dev_name)
 return NULL;
 
-n = snprintf(buf, sizeof(buf), dev_name, DRM_DIR_NAME, min);
-if (n == -1 || n >= sizeof(buf))
+len = snprintf(NULL, 0, dev_name, DRM_DIR_NAME, min);
+if (len < 0)
 return NULL;
+buf = (char *) malloc(len + 1);
+if(buf == NULL )
+return NULL;
+n = snprintf(buf, len + 1, dev_name, DRM_DIR_NAME, min);
+if (n == -1 || n > len) {
+free(buf);
+return NULL;
+}
 
-return strdup(buf);
+return buf;
 #endif
 }
 
@@ -3946,7 +3955,9 @@ static drmDevicePtr drmDeviceAlloc(unsig
 ptr += max_node_length;
 }
 
-memcpy(device->nodes[type], node, max_node_length);
+/* This fixes debian bug #975658 and upstream bug #1679430 */
+memcpy(device->nodes[type], node, max_node_length <= strlen(node)+1 ? max_node_length : strlen(node)+1);
+
 
 *ptrp = ptr;
 
@@ -4326,17 +4337,31 @@ process_device(drmDevicePtr *device, con
bool fetch_deviceinfo, uint32_t flags)
 {
 struct stat sbuf;
-char node[PATH_MAX + 1];
+char *node = NULL;
 int node_type, subsystem_type;
+int len = 0, n, ret = 0;
 unsigned int maj, min;
 
 node_type = drmGetNodeType(d_name);
 if (node_type < 0)
 return -1;
 
-snprintf(node, PATH_MAX, "%s/%s", DRM_DIR_NAME, d_name);
-if (stat(node, ))
+len = snprintf(NULL, 0, "%s/%s", DRM_DIR_NAME, d_name);
+if (len < 0)
+return -1;
+node = (char *) malloc(len + 1);
+if(node == NULL )
+return NULL;
+n = snprintf(node, len + 1, "%s/%s", DRM_DIR_NAME, d_name);
+if (n == -1 || n > len) {
+free(node);
+return -1;
+}
+
+if (stat(node, )) {
+free(node);
 return -1;
+}
 
 maj = major(sbuf.st_rdev);
 min = minor(sbuf.st_rdev);
@@ -4351,18 +4376,27 @@ process_device(drmDevicePtr *device, con
 switch (subsystem_type) {
 case DRM_BUS_PCI:
 case DRM_BUS_VIRTIO:
-return drmProcessPciDevice(device, node, node_type, maj, min,
+ret = drmProcessPciDevice(device, node, node_type, maj, min,
fetch_deviceinfo, flags);
+	free(node);
+	return ret;
 case DRM_BUS_USB:
-return drmProcessUsbDevice(device, node, node_type, maj, min,
+ret = drmProcessUsbDevice(device, node, node_type, maj, min,
fetch_deviceinfo, flags);
+	free(node);
+	return ret;
 case DRM_BUS_PLATFORM:
-return drmProcessPlatformDevice(device, node, node_type, maj, min,
+

Re: Regarding copyright assignment to FSF

[Svante Signell]

On Fri, 2021-08-13 at 18:23 +0200, Samuel Thibault wrote:

> The GPLv2-only code is essentially the pfinet stack from Linux, for
> which we don't have any assignment anyway. But again, this is getting
> replaced by lwip.

Hello. 

How to make lwip by default enabled instead of pfinet?

Thanks :)

Re: gftp: FTBFS on hurd-i386: fatal error: stropts.h: No such file or directory

[Svante Signell]

On Sun, 2021-05-09 at 21:56 +0800, hahawang wrote:
> Package: gftp
> Severity: important
> Version: 2.7.0b-1
> Tags: ftbfs,patch
> User:hahawang
> Usertags: hurd,hurd-i386
> X-Debbugs-CC:debian-h...@lists.debian.org,bug-hurd@gnu.org
> 
> +#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) 
> > > defined(__linux__) || defined(__gnu_hurd__))

Normally defined(__GNU__) is the most common way to indicate GNU/Hurd.

Re: Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Svante Signell]

On Mon, 2021-04-26 at 23:43 +0200, Samuel Thibault wrote:
> Hello Svante,
> 
> For information, your patch got dropped because of #975658

Yes I know since a long time. And you did not care or anybody else
either. So why bother... Why spend time on worthless issues?

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

[Svante Signell]

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

Hello,

Thanks for the heads up. A new tarball will be uploaded soon.

Thanks!

___

Reply to this item at:

  

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

Re: WEXITED/WCONTINUED

[Svante Signell]

On Sun, 2020-12-27 at 01:13 +0100, Samuel Thibault wrote:
> Hello,
> 
> For information, I am currently landing patches to implemented
> waitid's
> WEXITED/WCONTINUED/etc.

Linux has in /usr/include/x86_64-linux-gnu/bits/waitflags.h:
# define WEXITED4   /* Report dead child.  */
# define WCONTINUED 8   /* Report continued child.  */

Why did you choose in proc/wait.c:
+#ifndef WCONTINUED
+#define WCONTINUED 4
+#endif
+
+#ifndef WEXITED
+#define WEXITED 16
+#endif

Any specific reason?

Thanks!

Re: WEXITED/WCONTINUED

[Svante Signell]

On Sun, 2020-12-27 at 02:24 +, jbra...@dismail.de wrote:
> That's pretty cool!  I wonder what applications will benefit from
> that. I would imagine quite a few.
> 
> December 26, 2020 7:13 PM, "Samuel Thibault"  > wrote:
> 
> > Hello,
> > 
> > For information, I am currently landing patches to implemented
> > waitid's
> > WEXITED/WCONTINUED/etc.

The workaround for WCONTINUED can now be removed in gccgo. (I did look
into how WCONTINUED should be implemented, bud did not succeed. The
solution by Samuel was a little to complicated for me, adding a new
argument to send_signal() and even adding a new RPC.)

Thanks!

Re: Please comment out constants in header files for features not being supported yet. And remove stubs??

[Svante Signell]

On Fri, 2020-12-18 at 14:02 +0100, Samuel Thibault wrote:
> Svante Signell, le ven. 18 déc. 2020 13:22:12 +0100, a ecrit:
> > 
> > It is a crash: Without gdb:
> > host ftp.sunet.se
> > ftp.sunet.se is an alias for sunet.ftp.acc.umu.se.
> > sunet.ftp.acc.umu.se has address 194.71.11.173
> > sunet.ftp.acc.umu.se has address 194.71.11.165
> > socket.c:3173: REQUIRE(readable || writeable) failed, back trace
> > #0 0x132a806 in ??
> > #1 0x132a735 in ??
> > #2 0x13640d5 in ??
> > #3 0x13c33ff in ??
> > Aborted
> 
> Yes, so enable cores with "ulimit -c unlimited", then open it with
> gdb.

And as usual gdb on a core file is useless:
gdb -core ./core
[New process 799]
[New process 1]
[New process 2]
[New process 3]
[New process 4]

warning: Unexpected size of section `.reg2/799' in core file.
Core was generated by `host ftp.sunet.se'.
Program terminated with signal SIGABRT, Aborted.

warning: Unexpected size of section `.reg2/799' in core file.
#0  0x013f05ac in ?? ()
(gdb) where
#0  0x013f05ac in ?? ()
(gdb) bt
#0  0x013f05ac in ?? ()
(gdb) quit

Re: Please comment out constants in header files for features not being supported yet. And remove stubs??

[Svante Signell]

On Fri, 2020-12-18 at 12:12 +0100, Samuel Thibault wrote:
> Svante Signell, le ven. 18 déc. 2020 11:58:53 +0100, a ecrit:
> > On Thu, 2020-12-17 at 17:11 +0100, Samuel Thibault wrote:
> 
> > BTW: Any ideas about the second crash written about in my previous
> > mail that you edited away?
> 
> What second crash? I only see one gdb session. There is first a
> SIGTRAP, which is used by gdb for its own debugging purpose, then a
> SIGABRT. The second signal is very probably just a consequence of bad
> interaction between the program and gdb on the SIGTRAP. Thus why
> rather working on a core file.

It is a crash: Without gdb:
host ftp.sunet.se
ftp.sunet.se is an alias for sunet.ftp.acc.umu.se.
sunet.ftp.acc.umu.se has address 194.71.11.173
sunet.ftp.acc.umu.se has address 194.71.11.165
socket.c:3173: REQUIRE(readable || writeable) failed, back trace
#0 0x132a806 in ??
#1 0x132a735 in ??
#2 0x13640d5 in ??
#3 0x13c33ff in ??
Aborted

Re: Please comment out constants in header files for features not being supported yet. And remove stubs??

[Svante Signell]

On Thu, 2020-12-17 at 17:11 +0100, Samuel Thibault wrote:
> Svante Signell, le jeu. 17 déc. 2020 15:54:28 +0100, a ecrit:
> > # define CLOCK_REALTIME_COARSE  5
> > 
> > The problem with that option is that it is not yet supported,
> > resulting in EINVAL and a crash message on the console:
> > /hurd/crash: host  crashed ...
> 
> We could comment this out indeed.
> 
> But the program assuming that "it's defined so it works" is
> completely bogus on Linux as well: one may run an application built
> against a recent libc, on an old Linux kernel...

You are right, but how common is this combination? According to the
manpage of clock_gettime(): CLOCK_REALTIME_COARSE (since Linux 2.6.32;
Linux-specific) And that kernel was released on December 2, 2009.

> > Maybe even the stubs, like: posix_fadvise, acct, getrandom,
> > msg{ctl,get,rcv,snd}, sem{ctl,op,get}, vhangup,
> > pthread_getcpuclockid,
> > etc from gnu/stubs.h should be hidden too?
> 
> ./configure knows that they are stubs, and thus correctly detects
> them as not being available.

Got it! Then we should concentrate on finding stuff defined in header
files, but not yet implemented in Hurd.

BTW: Any ideas about the second crash written about in my previous mail
that you edited away?

Thanks! 

Please comment out constants in header files for features not being supported yet. And remove stubs??

[Svante Signell]

Hello,

Testing the command host  results in 
time.c:118: Invalid argument
timer.c:634: fatal error: RUNTIME_CHECK(isc_time_now(()) == 0)
failed
Aborted (core dumped)

Looking into the problem reveals that bind9 is built with the wrong
option clk_id for clock_gettime(): CLOCK_REALTIME_COARSE is used
instead of CLOCK_REALTIME. This is shown in the source code for
lib/isc/unix/stdtime.c and lib/isc/unix/time.c:
#if defined(CLOCK_REALTIME_COARSE)
#define CLOCKSOURCE CLOCK_REALTIME_COARSE
#elif defined(CLOCK_REALTIME_FAST)
#define CLOCKSOURCE CLOCK_REALTIME_FAST
#else /* if defined(CLOCK_REALTIME_COARSE) */
#define CLOCKSOURCE CLOCK_REALTIME
#endif /* if defined(CLOCK_REALTIME_COARSE) */

Searching for CLOCK_REALTIME_COARSE in the header files reveals:
/usr/include/i386-gnu/bits/time.h:
/* Identifier for system-wide realtime clock, updated only on
ticks.  */
# define CLOCK_REALTIME_COARSE  5

The problem with that option is that it is not yet supported, resulting
in EINVAL and a crash message on the console: /hurd/crash: host
 crashed ...

Recompiling bind9 commenting out the definition of
CLOCK_REALTIME_COARSE in time.h makes the crash go away.
host  works fine :)

However, another crash happens (still to be further investigated): host
ftp.sunet.se run in gdb shows:
[New Thread 29158.13]
[New Thread 29158.14]
[New Thread 29158.15]
[New Thread 29158.16]
ftp.sunet.se is an alias for sunet.ftp.acc.umu.se.
sunet.ftp.acc.umu.se has address 194.71.11.173
sunet.ftp.acc.umu.se has address 194.71.11.165

Thread 4 received signal SIGTRAP, Trace/breakpoint trap.
0x013f05ac in mach_msg_trap () at ./build-tree/hurd-i386-
libc/mach/mach_msg_trap.S:2
2   ./build-tree/hurd-i386-libc/mach/mach_msg_trap.S: No such file
or directory.
(gdb) c
Continuing.
socket.c:3173: REQUIRE(readable || writeable) failed, back trace
#0 0x132a806 in ??
#1 0x132a735 in ??
#2 0x13640d5 in ??
#3 0x13c33ff in ??

Thread 4 received signal SIGABRT, Aborted.
0x013f05ac in mach_msg_trap () at ./build-tree/hurd-i386-
libc/mach/mach_msg_trap.S:2
2   in ./build-tree/hurd-i386-libc/mach/mach_msg_trap.S
(gdb) where
#0  0x013f05ac in mach_msg_trap () at ./build-tree/hurd-i386-
libc/mach/mach_msg_trap.S:2
#1  0x013f0d99 in __GI___mach_msg (msg=0x4808b18, option=2,
send_size=0, rcv_size=24, 
rcv_name=171, timeout=0, notify=0) at msg.c:123
#2  0x0143f179 in __GI___sigwait (set=0x4808bd4, sig=0x4808bd8)
at ../sysdeps/mach/hurd/sigwait.c:113
#3  0x01329c52 in isc_app_ctxrun (ctx=) at app.c:312
#4  0x01329eff in isc_app_run () at app.c:365

So the problem now is now at sigwait.c:113:
/* Select any of pending signals from SET or wait for any to
arrive.  */
int
__sigwait (const sigset_t *set, int *sig)
...
  if (!setjmp (buf))
...
  /* Wait. */
  __mach_msg (, MACH_RCV_MSG, 0, sizeof (msg), wait,
  MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
  abort ();


Note: Rebuilding bind9 required some fixes:
1) Build clisp-2.49.20180218+really2.49.92-3 without tests. (or find
the failing test(s), and fix). Provides: clisp-fasl-loader-20100806
2) Build xindy-2.5.1.20160104-8 with the built clisp.
3) Rebuild bind9 with the newly installed versions of clisp and xindy.

There are other packages falsely believing that some features are
available when they are not. It would be good to hide from the
appropriate header files.

Maybe even the stubs, like: posix_fadvise, acct, getrandom,
msg{ctl,get,rcv,snd}, sem{ctl,op,get}, vhangup, pthread_getcpuclockid,
etc from gnu/stubs.h should be hidden too?

Please build gcc-9 + gcc-10 w/o tests.

[Svante Signell]

Hello,

Unfortunately gcc-9 (and gcc-10, gcc-snapshot) fails when tests are enabled, due
to "make -C build/gotools/ check" fails with one test hanging forever (and all 5
tests fails when killing the hanged process). A fix for that problem is still
needed. Note that "make -C build/i686-gnu/libgo check" and "make -C build check-
go" runs without hanging.

Additionally gcc-10 build-depends on gnat-9, so a failing build of gcc-9
disables a build of gcc-10. Please build the latest versions w/o tests.

Patches for build of libgo for gcc-snapshot are on it's way. Note that gotools
tests fails here too, while the other two runs to completion.

Thanks!

Re: Boot issue with e1000 netdde driver

[Svante Signell]

On Sun, 2020-11-29 at 20:31 +0100, Samuel Thibault wrote:
> Svante Signell, le dim. 29 nov. 2020 18:01:51 +0100, a ecrit:
> > On Sun, 2020-11-29 at 14:37 +0100, Samuel Thibault wrote:
> > > Richard Braun, le dim. 29 nov. 2020 14:09:56 +0100, a ecrit:
> > > > Actually, with the e1000 driver, very often, network is not
> > > > functional at boot time and I have to manually kill netdde and
> > > > trigger some activity
> > > Oh?
> > > 
> > > I'm surprised, I never experience this on my box.
> > 
> > I do see it too. Network is functional after a loong time and/or
> > after a reboot.
> 
> Has it always been so?

No, since the last 1-2 weeks or so.

Re: Boot issue with e1000 netdde driver

[Svante Signell]

On Sun, 2020-11-29 at 14:37 +0100, Samuel Thibault wrote:
> Richard Braun, le dim. 29 nov. 2020 14:09:56 +0100, a ecrit:
> > 
> > Actually, with the e1000 driver, very often, network is not
> > functional at boot time and I have to manually kill netdde and
> > trigger some activity
> Oh?
> 
> I'm surprised, I never experience this on my box.

I do see it too. Network is functional after a loong time and/or after
a rebbot. And this: see attached. I rump default already?

Thanks!

Installing sbuild failed, a lot of passive translators? still running.

[Svante Signell]

Hi,

After installing and running sbuild+sbuild-createchroot it failed and a
lot of passive translators? are still running at /tmp/*, e.g.

\rm -rf /tmp/*
rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/fd': Device or resource busy
rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/vcs': Device or resource
busy
rm: cannot remove '/tmp/tmp.6hFFgM37Tt/servers/bus/pci': Device or
resource busy
rm: cannot remove '/tmp/tmp.6hFFgM37Tt/servers/acpi': Device or
resource busy

How to get rid of them??

And how to add the unreleased repo?

sbuild-createchroot --make-sbuild-
tarball=/home/srs/DEBs/chroot/unstable-hurd-i386.tar.gz --
keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-
repository="deb http://deb.debian.org/debian-ports unreleased main"
unstable `mktemp -d` http://deb.debian.org/debian-ports

does not work!

Thanks!

Re: Testing direct rendering/more video cards with qemu?

[Svante Signell]

On Tue, 2020-11-17 at 22:51 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 22:47:04 +0100, a ecrit:
> > On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote:
> > > Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit:
> > > > Got it. Can some of the drivers be tested with software
> > > > rendering,
> > > > like swrast?
> > > 
> > > software rendering does not use drm/dri. That's already what we
> > > are using (and have been using for years) for -vga std or cirrus.
> > 
> > So having more mesa packages building is worthless?
> 
> I don't mean it's worthless, I mean it already used to be building
> and working fine. Now that it builds fine again, I have little doubt
> that software rendering works fine.

My question is merely if there is any idea of submitting my patches for
mesa, enabling builds of more mesa and other packages. (even if
software rendering is the only solution for now.)

Thanks!

Re: Testing direct rendering/more video cards with qemu?

[Svante Signell]

On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit:

> > Got it. Can some of the drivers be tested with software rendering,
> > like swrast?
> 
> software rendering does not use drm/dri. That's already what we are
> using (and have been using for years) for -vga std or cirrus.

So having more mesa packages building is worthless? You are very
encouraging.

Thanks!

Re: Testing direct rendering/more video cards with qemu?

[Svante Signell]

On Tue, 2020-11-17 at 15:32 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 15:31:03 +0100, a ecrit:

> > > > > dri cannot work. You changes in libdrm only introduced some
> > > > > stub interface. Actual drm implementation is needed to get
> > > > > any kind of direct rendering working
> > > > 
> > > > The changes to libdrm are similar to the kFreeBSD solution. So
> > > > you mean that dri won't work there either?
> > > 
> > > kFreeBSD does have some drm infrastructure.
> > 
> > Ok. What is needed for Hurd to have drm infrastructure, kernel
> > support? 
> There were some discussions about it on the list some years ago. Yes,
> some kernel support probably, and coordination between user processes
> using it. Not a simple hack anyway.

Got it. Can some of the drivers be tested with software rendering, like
swrast?

Thanks!

Re: Testing direct rendering/more video cards with qemu?

[Svante Signell]

On Tue, 2020-11-17 at 15:22 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 15:22:02 +0100, a ecrit:
> > On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote:
> > > Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit:
> > > > > > Which of these (and xorg* packages) are needed?
> > > > > 
> > > > > Needed for what?
> > > > 
> > > > For testing if some of the dri/drv drivers work on Hurd: e.g.
> > > > r200,
> > > > r300 etc.
> > > 
> > > dri cannot work. You changes in libdrm only introduced some stub
> > > interface. Actual drm implementation is needed to get any kind of
> > > direct rendering working
> > 
> > The changes to libdrm are similar to the kFreeBSD solution. So you
> > mean
> > that dri won't work there either?
> 
> kFreeBSD does have some drm infrastructure.

Ok. What is needed for Hurd to have drm infrastructure, kernel
support? 

Another question: libgbm1 now builds, and many packages build-depends
on libgbm-dev (and maybe other packages not yet available): mpv,
directfdb, virglrender, ukvm, kmscube, etc. Are they also unusable
if/when built?

Is there any idea to work on mesa/drm for Hurd at all??

Thanks!

Re: Testing direct rendering/more video cards with qemu?

[Svante Signell]

On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit:
> > > > Which of these (and xorg* packages) are needed?
> > > 
> > > Needed for what?
> > 
> > For testing if some of the dri/drv drivers work on Hurd: e.g. r200,
> > r300 etc.
> 
> dri cannot work. You changes in libdrm only introduced some stub
> interface. Actual drm implementation is needed to get any kind of
> direct rendering working

The changes to libdrm are similar to the kFreeBSD solution. So you mean
that dri won't work there either?

Thanks!

Re: Testing direct rendering/more video cards with qemu?

[Svante Signell]

On Tue, 2020-11-17 at 14:22 +0100, Samuel Thibault wrote:
> Svante Signell, le mar. 17 nov. 2020 11:41:52 +0100, a ecrit:
> > I managed to build more packages from mesa based on that libdrm is
> > now available. Is there any way to test these packages with qemu?
> 
> Which packages? Those mentioned below in your mail? They don't depend
> that much on the emulated hardware, and rather on the software being
> used.

Testing xorg with the other drivers than default? 

> > qemu-system-x86_64 --help shows
> > -vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none]
> > select video card type
> 
> Yes, that's basically all. Apart from the virtual devices meant for
> virtualization, qemu doesn't propose many virtual cards.

Not emulating any of the radeon/nvidia/etc graphics cards then. So Hurd
has to run on real hardware? That can maybe be possible when rumpdisk
is working properly!?

> > Which of these (and xorg* packages) are needed?
> 
> Needed for what?

For testing if some of the dri/drv drivers work on Hurd: e.g. r200,
r300 etc.

> > I had to make a dirty patch for non-linux of libva:va/va_trace.c
> > since gettid() or syscall(__NR_ttid) is not available on GNU/Hurd
> > (or GNU/kFreeBSD. Any ideas on how to make a workaround?
> > pthread_self() does not seem to work: See
> > http://clanguagestuff.blogspot.com/2013/08/gettid-vs-pthreadself.html
> 
> "work" wholy depends what it is used for. gettid is a very linuxish
> thing. What I read from va/va_trace.c looks like it could be very
> fine with using pthread_self().
> 
> (In general, relying on gettid() to provide non-reusable thread ids
> is nonsense: tids do wrap around as well).

So you mean that all calls to gettid() can be replaced with
pthread_self() for non-linux systems?

Thanks!

Testing direct rendering/more video cards with qemu?

[Svante Signell]

Hello,

I managed to build more packages from mesa based on that libdrm is now
available. Is there any way to test these packages with qemu?

qemu-system-x86_64 --help shows
-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none]
select video card type

(or is it only possible with real hardware?)

Which of these (and xorg* packages) are needed?
(dbgsym packages excluded)
libegl1-mesa_20.2.2-1.1_hurd-i386.deb
libegl1-mesa-dev_20.2.2-1.1_hurd-i386.deb
libegl-mesa0_20.2.2-1.1_hurd-i386.deb
libgbm1_20.2.2-1.1_hurd-i386.deb
libgbm-dev_20.2.2-1.1_hurd-i386.deb
libgl1-mesa-dev_20.2.2-1.1_hurd-i386.deb
libgl1-mesa-dri_20.2.2-1.1_hurd-i386.deb
libgl1-mesa-glx_20.2.2-1.1_hurd-i386.deb
libglapi-mesa_20.2.2-1.1_hurd-i386.deb
libgles2-mesa_20.2.2-1.1_hurd-i386.deb
libgles2-mesa-dev_20.2.2-1.1_hurd-i386.deb
libglx-mesa0_20.2.2-1.1_hurd-i386.deb
libosmesa6_20.2.2-1.1_hurd-i386.deb
libosmesa6-dev_20.2.2-1.1_hurd-i386.deb
mesa-common-dev_20.2.2-1.1_hurd-i386.deb
mesa-va-drivers_20.2.2-1.1_hurd-i386.deb
mesa-vdpau-drivers_20.2.2-1.1_hurd-i386.deb

I had to make a dirty patch for non-linux of libva:va/va_trace.c since
gettid() or syscall(__NR_ttid) is not available on GNU/Hurd (or
GNU/kFreeBSD. Any ideas on how to make a workaround? pthread_self()
does not seem to work: See
http://clanguagestuff.blogspot.com/2013/08/gettid-vs-pthreadself.html

Thanks!

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

[Svante Signell]

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

Hi Ineiev,

Any results from your discussions with Samuel?

___

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 #23, sr #110199 (project administration):

ping?

___

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 #22, sr #110199 (project administration):

Hi again.

I don't really understand what you mean by "confirm your commitment to
maintain these notices in the long run". If a patch for example does not
change the copyright and license information does not have to change at all.
Or do you mean the files I created? 

Of course I will maintain them long term. The idea is to maintain the
cross-hurd repository with git and update the involved packages consisting of
the environment regularly. For example glibc-2.30 is used in the tarball, but
2.31 is already released and will be upgraded to when the git repo is up and
running.
 
For your information, I have ported Ada, Go, etc to GNU/Hurd and contribute
regularly when additional patches are needed. Additionally, I have assigned
copyright to FSF for my contributions to Mig, GnuMach, Hurd, glibc gcc, and
gdb (if I remember correctly) and contribute to these packages regularly too.
Maybe Samuel Thibault  can help me to confirm my
commitment to GNU software.

Can you please be specific which files I missed and where the wrong things
are.

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 #20, sr #110199 (project administration):

Hi again. I have now added Copyright and License information to all files
where it is needed. Hopefully I have not missed any. Please let me know if I
did or if there is still something missing or in need of correction.

Thanks!

(file #49032)
___

Additional Item Attachment:

File name: hurd-cross.tar.gz  Size:80 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 #18, sr #110199 (project administration):

ping?


___

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 #17, sr #110199 (project administration):

Thanks for reopening #110199.

I don't really understand your comment #16. Do you mean that I should add
copyright and license information to all files in the patches directory? Or
the ones larger than 10 lines? If that is what you mean I'll do it.

(As a side note, Debian don't add these notices to their patches. Instead they
have a file called debian/copyright stating copyright and license for all
files in the source and debian directories of the package. In my opinion this
is more handy than to add that info to each file in the patches directory.
Maybe create a separate copyright file in the patches directory?)

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 #15, sr #110199 (project administration):

Please, I did submit a new tarball after sending that message. And commented
on your feedback. Please reopen this issue.

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 #13, sr #110199 (project administration):

ping?

___

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 #12, sr #110199 (project administration):

You are right,

coreutils/coreutils-8.23-noman-1.patch does not have a license. Looking more
closely at applied patches I found out that it is not needed. Just remove it
from the tarball.

Regrading the patches for glibc README.patches states:
All patches below are Copyright FSF.
git-ONSTACK.diff: GPLv2.1+ Patch by Samuel Thibault.
tg-mach-hurd-link.diff: GPLv2.1+ Patch by Samuel Thibault.
tg-hurdsig-fixes.diff: GPLv2.1+ Patch by Jeremy Koenig.
tg-hurdsig-global-dispositions.diff: GPLv2.1+ Patch by Jeremy Koenig.
tg-hurdsig-SA_SIGINFO.diff: GPLv2.1+ Patch by Jeremy Koenig.
tg-hurdsig-fixes-2.diff: GPLv2.1+ Patch by Jeremy Koenig.
tg-sigstate_thread_reference.diff: GPLv2.1+ Patch by Richard Braun.
glibc.git-0b262ca4c64cd9042576ddb9969607c0ea1187d7.patch: GPLv2.1+ Patch by
me.

Is that not enough? Or do you want me to add Copyright and License information
to that patch (or all the above patches?)

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 #10, sr #110199 (project administration):

Hi again,

As explained in patches/README.patches most patches are smaller than 10 lines,
and therefore does not need to have Copyright information. They are denoted
SHORT in that file.

The longer patches do have Copyright information:
coreutils/coreutils-8.23-noman-1.patch
gcc/fixinc_glimits.h.diff
glibc/local-remove-manual.diff
glibc/tg-hurdsig-SA_SIGINFO.diff

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 #8, sr #110199 (project administration):

ping!

___

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 #7, sr #110199 (project administration):

Hi again.

This time I've tried to comply with all your requests of Copyright and License
info. Please le me know if something is still missing.
Attaching an updated tarball: hurd-cross.tar.gz.

Thanks!

(file #48777)
___

Additional Item Attachment:

File name: hurd-cross.tar.gz  Size:75 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 #6, sr #110199 (project administration):

Hi Inieiev,

I'll make one more effort to to comply to your requirements. If you reject the
next tarball, I'll publish the project elsewhere, gitlab or github (god
forgive) :(



___

Reply to this item at:

  

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

Re: git-bisect results on gnumach

[Svante Signell]

On Sat, 2020-04-04 at 11:27 +0200, Samuel Thibault wrote:
> Svante Signell, le sam. 04 avril 2020 09:59:26 +0200, a ecrit:

> > Just a follow-up: I did cherry-pick
> > 572095c645ecc63285d0955fbee2f5d644ad8f88
> > on top of
> > 0b3504b6db86c531e8b53b8e9aa9030db6e72357
> > and the error remains.
> 
> Could you try the attached patch on top of that?

Yes, Hurd boots fine adding that patch. And applying it to the latest
git version of gnumach works fine too!

Thanks!

Re: git-bisect results on gnumach

[Svante Signell]

On Sat, 2020-04-04 at 09:20 +0200, Svante Signell wrote:
> On Fri, 2020-04-03 at 23:45 +0200, Samuel Thibault wrote:
> > Thanks! I pushed a fix.
> 
> I tried the latest gnumach and something is still not OK:
> Loading GNU Mach
> Loading the Hurd ...
> KVM: entry failed, hardware error 0x8021
> 
> Is bisecting not possible any longer, unless cherry picking the
> latest
> commit? There are plenty of commits between
> d8029bb8eebeb43cb1879a618eda70a8f53042cc
> and
> 0b3504b6db86c531e8b53b8e9aa9030db6e72357

Just a follow-up: I did cherry-pick
572095c645ecc63285d0955fbee2f5d644ad8f88
on top of
0b3504b6db86c531e8b53b8e9aa9030db6e72357
and the error remains.

Re: git-bisect results on gnumach

[Svante Signell]

On Fri, 2020-04-03 at 23:45 +0200, Samuel Thibault wrote:
> Thanks! I pushed a fix.

I tried the latest gnumach and something is still not OK:
Loading GNU Mach
Loading the Hurd ...
KVM: entry failed, hardware error 0x8021

Is bisecting not possible any longer, unless cherry picking the latest
commit? There are plenty of commits between
d8029bb8eebeb43cb1879a618eda70a8f53042cc
and
0b3504b6db86c531e8b53b8e9aa9030db6e72357

Thanks!

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

[Svante Signell]

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

[comment #3 comment #3:]
> 
> [comment #2 comment #2:]
> > Regarding patches in the patches directory, it does not make sense to add
copyright notices.
> 
> Why not?

I have now added Copyright info to the patches directory, see
hurd-cross/patches/README.patches. I hope this is good so I can upload the
project to Savannah. I'm attaching an updated tarball: hurd-cross.tar.gz.

Thanks!

(file #48748)
___

Additional Item Attachment:

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




___

Reply to this item at:

  

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

Re: git-bisect results on gnumach

[Svante Signell]

On Fri, 2020-04-03 at 16:11 +0200, Svante Signell wrote:
> Hello,
> 
> After having problems to boot the cross-built Hurd from the latest
> hurd/gnumach/mig git repos bisecting gnumach with git-bisect the
> following bad commit was found (breaking --enable-pae according to
> Samuel):
> 
> 0b3504b6db86c531e8b53b8e9aa9030db6e72357 is the first bad commit
> commit 0b3504b6db86c531e8b53b8e9aa9030db6e72357
> Author: Samuel Thibault 
> Date:   Sun Mar 18 20:31:22 2012 +0100
> 
> pmap.h: Add 64bit variant
> 
> * i386/intel/pmap.h (L4SHIFT, L4MASK, lin2l4num): New macros
> (PDPNUM, PDPMASK, set_pmap): Add 64bit variant. Make PAE use the
> 64bit mask
> too.
> (pmap): Add l4base, user_l4base, user_pdpbase fields.
> * i386/intel/pmap.c (pmap_bootstrap): Clear the whole PDP. Enable
> write
> bit in PDP. Set user pagetable to NULL. Initialize l4base.
> (pmap_clear_bootstrap_pagetable): Add 4th-level support.
> (pmap_ceate): Clear the whole PDP. Enable write bit in PDP.
> Initialize
> l4base, user_pdpbase, user_l4base.
> (pmap_destroy): Clear l4base, user_pdpbase, user_l4base.
> * i386/i386at/model_dep.c (i386at_init): Load l4base on 64bits.
> 
>  i386/i386at/model_dep.c |  10 ++--
>  i386/intel/pmap.c   | 120
> ++--
>  i386/intel/pmap.h   |  41 -
>  3 files changed, 153 insertions(+), 18 deletions(-)

Some more info:
The problem showed up in kvm as a hardware error when running the built
image with qemu:
qemu-system-x86_64 -chardev \
stdio,id=char0,logfile=serial.log,signal=off -serial chardev:char0 \
-- enable-kvm -m 2048 hurd-cross.img

Serial console output:
Loading GNU Mach
Loading the Hurd ...
KVM: entry failed, hardware error 0x8021

If you're running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an
invalid
state for Intel VT. For example, the guest maybe running in big real
mode
which is not supported on less recent Intel processors.

EAX=80010011 EBX=f5af ECX=f5af EDX=078bfbfd
ESI=35af4000 EDI=f67fe020 EBP=c11ea214 ESP=c11ea1ec
EIP=c1000317 EFL=0086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 4000  00c09300 DPL=0 DS   [-WA]
CS =0008 4000  00c09b00 DPL=0 CS32 [-RA]
SS =0010 4000  00c09300 DPL=0 DS   [-WA]
DS =0010 4000  00c09300 DPL=0 DS   [-WA]
FS =   00c0
GS =   00c0
LDT=   8200 DPL=0 LDT
TR =   8b00 DPL=0 TSS32-busy
GDT= 0190 001f
IDT=  
CR0=80010011 CR2= CR3=35aef000 CR4=0020
DR0= DR1= DR2=
DR3= 
DR6=0ff0 DR7=0400
EFER=
Code=0f 20 e0 83 c8 20 0f 22 e0 0f 20 c0 0d 00 00 01 80 0f 22 c0 <0f>
20 c0 25 ff ff ff 9f 0f 22 c0 80 e6 20 75 79 eb 00 e8 42 69 00 00 e8 bd
69 00 00 e8 88

git-bisect results on gnumach

[Svante Signell]

Hello,

After having problems to boot the cross-built Hurd from the latest
hurd/gnumach/mig git repos bisecting gnumach with git-bisect the
following bad commit was found (breaking --enable-pae according to
Samuel):

0b3504b6db86c531e8b53b8e9aa9030db6e72357 is the first bad commit
commit 0b3504b6db86c531e8b53b8e9aa9030db6e72357
Author: Samuel Thibault 
Date:   Sun Mar 18 20:31:22 2012 +0100

pmap.h: Add 64bit variant

* i386/intel/pmap.h (L4SHIFT, L4MASK, lin2l4num): New macros
(PDPNUM, PDPMASK, set_pmap): Add 64bit variant. Make PAE use the
64bit mask
too.
(pmap): Add l4base, user_l4base, user_pdpbase fields.
* i386/intel/pmap.c (pmap_bootstrap): Clear the whole PDP. Enable
write
bit in PDP. Set user pagetable to NULL. Initialize l4base.
(pmap_clear_bootstrap_pagetable): Add 4th-level support.
(pmap_ceate): Clear the whole PDP. Enable write bit in PDP.
Initialize
l4base, user_pdpbase, user_l4base.
(pmap_destroy): Clear l4base, user_pdpbase, user_l4base.
* i386/i386at/model_dep.c (i386at_init): Load l4base on 64bits.

 i386/i386at/model_dep.c |  10 ++--
 i386/intel/pmap.c   | 120
++--
 i386/intel/pmap.h   |  41 -
 3 files changed, 153 insertions(+), 18 deletions(-)

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

[Svante Signell]

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

Hello,

Regarding patches in the patches directory, it does not make sense to add
copyright notices. Therefore I have created the README.patches file under
patches. It is a lot of work to create a README.patches for every
sub-directory.

Do you want me to add a copyright notice in every READ.* file?

___

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]

URL:
  

 Summary: Cross-building of GNU/Hurd and additional packages
 Project: Savannah Administration
Submitted by: gnu_srs
Submitted on: Tue 18 Feb 2020 10:09:24 AM UTC
Category: Source code repositories - developer access
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: svante.sign...@gmail.com
Operating System: GNU/Linux
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

hurd-cross is a project for cross-building GNU/Hurd and other packages using
e.g. an GNU/Linux host. It contains mainly of a number of bash scripts, for
download, bootstrap and compile dependant packages for GNU/Hurd, as well as
other packages to build and run on the built image. The scripts downloads and
patches source packages, bootstraps the dependant packages for building Hurd,
compiles and installs the cross-built packages and finally creates an image of
GNU/Hurd to be run e.g. in a Virtual Machine (VM). In an extension the number
of built packages can be cross-built to create other packages not yet
available natively on GNU/Hurd.



___

File Attachments:


---
Date: Tue 18 Feb 2020 10:09:24 AM UTC  Name: hurd-cross.tar.gz  Size: 74KiB  
By: gnu_srs



___

Reply to this item at:

  

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

Re: Adding the hurd-cross package to "The Hurd group"?

[Svante Signell]

Hi Flavio,

I did try to email you 25 September 2019 to your google email address but did
not get any reply. The current project hurd-cross is a major rewrite of your
cross-hurd at github.

I did keep your README.md and updated the build procedure in README.commands.
The name change from cross-hurd to hurd-cross was made to avoid naming conflicts
with the Debian package crosshurd, which is an installer for the Debian system.

Your work was a good starting point for me, that is very appreciated, thank you.
I linked to your github account in files/README.files and mention ../README.md
there too. I can of course add a link to your work in README.commands as well as
add that link to README.md too.

Alternately, do you want me to add your name to the files having an origin of
your work, like:
Copyright (C) 2016 Flavio Cruz, 2019, 2020 Svante Signell

Written by Flavio Cruz  and Svante Signell <
svante.sign...@gmail.com>

However, doing a recursive diff of the directories there is not much in common
any longer, except in the files/ directory.

As you might find out executing the scripts to build and run the hurd-cross
image there are still some FIXMEs to solve. (But it boots and runs, tested with
qemu). There is also a need to extend the cross-builds to enable networking on
the built image, as well as doing further extensions, see the TODO file. Any
help with these things is happily received.

Looking at your github account you mention a rewrite of mig. Is that project
also stalled, no updates since 2016? A rewrite of mig would be a major
contribution to the GNU/Hurd OS. 

Thank you for inspiring me,
Svante Signell

On Fri, 2020-02-14 at 00:40 -0800, Flávio Cruz wrote:
> Hi Svante
> 
> Your hurd-cross project seems to be based on something I did a few years back
> (https://github.com/flavioc/cross-hurd). I'm glad you want to continue to
> improve it but please reference the original author.
> 
> Thanks
> 
> On Thu, Feb 13, 2020 at 8:36 AM Samuel Thibault 
> wrote:
> > Hello,
> > 
> > Svante Signell, le jeu. 13 févr. 2020 17:10:30 +0100, a ecrit:
> > > I've created the hurd-cross (hurdX) package and submitted it as task
> > #15548, see
> > > https://savannah.nongnu.org/task/?15548. I was asked by ine...@gnu.org if
> > I
> > > could join "The Hurd group" with it. The project is described in the task,
> > and I
> > > also have uploaded a tarball. The tarball is created by git archive. If
> > admitted
> > > to join the group with that package
> > 
> > Sure, you're welcome!
> > 
> > > I would like to create a git repository at
> > > http://git.savannah.gnu.org/cgit/hurd/ or elsewhere. What is the
> > > procedure to create an upstream git repo?
> > 
> > I don't know, Thomas, do you know?
> > 
> > Samuel
> > 
> 
> 

Adding the hurd-cross package to "The Hurd group"?

[Svante Signell]

Hello,

I've created the hurd-cross (hurdX) package and submitted it as task #15548, see
https://savannah.nongnu.org/task/?15548. I was asked by ine...@gnu.org if I
could join "The Hurd group" with it. The project is described in the task, and I
also have uploaded a tarball. The tarball is created by git archive. If admitted
to join the group with that package I would like to create a git repository at
http://git.savannah.gnu.org/cgit/hurd/ or elsewhere. What is the procedure to
create an upstream git repo?

Thanks!

Re: /proc/self/fd support on Hurd

[Svante Signell]

On Tue, 2020-02-11 at 09:03 -0800, Samuel Thibault wrote:
> Svante Signell, le mar. 11 févr. 2020 17:59:12 +0100, a ecrit:
> > Sorry, that was a Linux system. On hurd:
> > ls -l /proc/self/fd/
> 
> I don't have such a directory on a Hurd system.

Yes you are correct.

> Note that getting the list of fds is not supported, but if you ls
> /dev/fd/0 for instance, it will work.

Yes /1 and /2 too.

Re: /proc/self/fd support on Hurd

[Svante Signell]

On Tue, 2020-02-11 at 08:46 -0800, Samuel Thibault wrote:
> Svante Signell, le mar. 11 févr. 2020 17:42:18 +0100, a ecrit:
> > On Tue, 2020-02-11 at 06:16 -0800, Samuel Thibault wrote:
> > > Florian Weimer, le mar. 11 févr. 2020 15:06:43 +0100, a ecrit:
> > > > > Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit:
> > > > > > Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit:
> > > > > > > Does Hurd support /proc/self/fd, in the sense that the POSIX
> > > > > > > functions
> > > > > > > in glibc (such as openat) can deal with such paths?
> > > > > > 
> > > > > > Not yet but that could be added quite easily with some magic
> > > > > > translation.
> > > > > 
> > > > > Ah, actually it's already supported in /dev/fd (but we can add a
> > > > > symlink
> > > > > in /proc/self for compatibility).
> > > > 
> > > > Does this mean if we generate paths starting with /dev/fd/, we already
> > > > have this functionality today?
> > 
> > There are already symlinks there:
> 
> Are you really looking at a hurd system?
> 
> > ls -l /dev/pts/
> > total 0
> > crw--w 1 srs  tty  136, 0 Feb 11 14:38 0
> > crw--w 1 srs  tty  136, 1 Feb 11 17:39 1
> > c- 1 root root   5, 2 Dec 13 11:55 ptmx
> 
> There is no ptmx support on GNU/Hurd yet.

Sorry, that was a Linux system. On hurd:
ls -l /proc/self/fd/
total 0
ls -l /dev/fd
total 0

Re: /proc/self/fd support on Hurd

[Svante Signell]

On Tue, 2020-02-11 at 06:16 -0800, Samuel Thibault wrote:
> Florian Weimer, le mar. 11 févr. 2020 15:06:43 +0100, a ecrit:
> > > Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit:
> > > > Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit:
> > > > > Does Hurd support /proc/self/fd, in the sense that the POSIX functions
> > > > > in glibc (such as openat) can deal with such paths?
> > > > 
> > > > Not yet but that could be added quite easily with some magic
> > > > translation.
> > > 
> > > Ah, actually it's already supported in /dev/fd (but we can add a symlink
> > > in /proc/self for compatibility).
> > 
> > Does this mean if we generate paths starting with /dev/fd/, we already
> > have this functionality today?

There are already symlinks there:

ls -l /proc/self/fd/
total 0
lrwx-- 1 srs srs 64 Feb 11 14:48 0 -> /dev/pts/1
lrwx-- 1 srs srs 64 Feb 11 14:48 1 -> /dev/pts/1
lrwx-- 1 srs srs 64 Feb 11 14:48 2 -> /dev/pts/1
lr-x-- 1 srs srs 64 Feb 11 14:48 3 -> /proc/2872/fd

ls -l /dev/fd/
total 0
lrwx-- 1 srs srs 64 Feb 11 17:38 0 -> /dev/pts/1
lrwx-- 1 srs srs 64 Feb 11 17:38 1 -> /dev/pts/1
lrwx-- 1 srs srs 64 Feb 11 17:38 2 -> /dev/pts/1
lr-x-- 1 srs srs 64 Feb 11 17:38 3 -> /proc/2982/fd

ls -l /dev/pts/
total 0
crw--w 1 srs  tty  136, 0 Feb 11 14:38 0
crw--w 1 srs  tty  136, 1 Feb 11 17:39 1
c- 1 root root   5, 2 Dec 13 11:55 ptmx

Re: [PATCH] 1(3) hurd+glibc: Support for file record locking

[Svante Signell]

On Mon, 2019-10-28 at 01:40 +0100, Samuel Thibault wrote:
> There was an issue with rlock-tweak.c, revealed by the tdb testsuite:
> 
> Index: hurd-debian/libfshelp/rlock-tweak.c
> ===
> --- hurd-debian.orig/libfshelp/rlock-tweak.c
> +++ hurd-debian/libfshelp/rlock-tweak.c
> 
> + else if (l->start < start && start <= l->start + l->len
> +  && (len == 0 || start + len > l->start + l->len))
> /* Our start falls within the locked region or exactly one byte after
> it and our end falls beyond it.  We know that we cannot consume the
> entire region.  */
> 
> Apart from that it seemed to work just fine. I'll let the glibc
> testsuite run this night to be sure before committing.

Nice catch. I never tried running the tdb testsuite explicitly during
the years, only when trying to build tdb itself. How did the glibc
testsuite run go?

Thanks!

Re: [PATCH] 2(3) hurd+glibc: Support for file record locking

[Svante Signell]

On Sun, 2019-10-27 at 21:06 +0100, Samuel Thibault wrote:
> Svante Signell, le jeu. 12 sept. 2019 10:23:55 +0200, a ecrit:
> > @@ -358,6 +357,18 @@ routine file_reparent (
> >  skip;  /* Was: file_get_children.  */
> >  skip;  /* Was: file_get_source.  */
> >  
> > +
> > +/* Do fcntl type locking on FILE. CMD is from the set F_GETLK64,
> > + F_SETLK64, F_SETLKW64. FLOCK64 is passed by the user and is as
> > + defined by . RENDEZVOUS is MACH_PORT_NULL for per opened
> > + file locking and !MACH_PORT_NULL for per process file locking */
> > +routine file_record_lock (
> > +   file: file_t;
> > +   RPT
> > +   cmd: int;
> > +   inout flock64: flock_t;
> > +   rendezvous: mach_port_send_t);
> > +
> >  /* Overlay a task with a file.  Necessary initialization,
> > including authentication changes associated with set[ug]id
> > execution must be handled by the filesystem.  Filesystems normally
> > implement this by
> 
> I'm only realizing this, now that I see that rebooting with the
> patches applied on hurd fails completely: never insert an RPC between
> existing ones! That renumbers everything, we do not want that at any
> rate. I'll fix that along committing.

Thank you Samuel for finding time to review the patches. Regarding the
placement of file_record_lock in fs.defs I have not changed it. That
place was selected by Neal in 2001. Of course a lot has happened since
then. Sorry for not realising that it should be placed in time order,
but I never had a failing boot due to this error. Maybe it did not hit
me since I built and installed the patched hurd+glibc packages
simultaneously?

Thanks!

[PATCH] 3(3) hurd+glibc: Support for file record locking

[Svante Signell]

Attached is the third part of the patches for file record locking:
libfshelp-tests_rlock.patch
fcntl.diff

The patch fcntl.diff against glibc-2.29-1 should be applied after
(or at the same time as) the patched hurd debs.

Note that the following glibc patch have been commented out from the
series file:
hurd-i386/tg-WRLCK-upgrade.diff

Additionally the two upstream commits are reversed by:
revert-git-lockf-0.diff
revert-git-fcntl64.diff

If you are working with git these commits are more easily mage there.

Thanks!
sysdeps/mach/hurd/Changelog
2019-01-12  Svante Signell 

	* Update copyright years.

2018-12-21  Svante Signell 

	* hurd-i386/fcntl.diff: Add the required new arguments when
	  calling the updated RPC file_record_lock.

2018-12-04  Svante Signell 

	* debian/patches/series: Comment out debian 2.28-1 patches:
	  hurd-i386/git-fcntl64.diff
	  hurd-i386/git-lockf-0.diff
	  hurd-i386/tg-WRLCK-upgrade.diff

	* fcntl.c: Add support weak, hidden and strong references as
	  in Debian 2.28-1 patch as in hurd-i386/git-fcntl64.diff.

	* fcntl64.c: New file, defined in fcntl.c as an alias. 

	* hurd-i386/fcntl.diff: Refresh.

2014-08-21  Svante Signell 

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

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

Index: glibc-2.28-4.1/sysdeps/mach/hurd/bits/fcntl.h
===
--- glibc-2.28-4.1.orig/sysdeps/mach/hurd/bits/fcntl.h
+++ glibc-2.28-4.1/sysdeps/mach/hurd/bits/fcntl.h
@@ -1,5 +1,5 @@
 /* O_*, F_*, FD_* bit values for GNU.
-   Copyright (C) 1993-2018 Free Software Foundation, Inc.
+   Copyright (C) 1993-2019 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -163,9 +163,18 @@
 # define F_GETOWN	5	/* Get owner (receiver of SIGIO).  */
 # define F_SETOWN	6	/* Set owner (receiver of SIGIO).  */
 #endif
+#ifdef __USE_FILE_OFFSET64
+# define	F_GETLK		F_GETLK64
+# define	F_SETLK		F_SETLK64
+# define	F_SETLKW	F_SETLKW64
+#else
 #define	F_GETLK		7	/* Get record locking info.  */
 #define	F_SETLK		8	/* Set record locking info (non-blocking).  */
 #define	F_SETLKW	9	/* Set record locking info (blocking).  */
+#endif
+#define	F_GETLK64	10	/* Get record locking info.  */
+#define	F_SETLK64	11	/* Set record locking info (non-blocking).  */
+#define	F_SETLKW64	12	/* Set record locking info (blocking).  */
 
 #ifdef __USE_XOPEN2K8
 # define F_DUPFD_CLOEXEC 1030	/* Duplicate, set FD_CLOEXEC on new one.  */
Index: glibc-2.28-4.1/sysdeps/mach/hurd/fcntl.c
===
--- glibc-2.28-4.1.orig/sysdeps/mach/hurd/fcntl.c
+++ glibc-2.28-4.1/sysdeps/mach/hurd/fcntl.c
@@ -1,4 +1,4 @@
-/* Copyright (C) 1992-2018 Free Software Foundation, Inc.
+/* Copyright (C) 1992-2019 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 		/* XXX for LOCK_* */
 
 /* Perform file control operations on FD.  */
 int
@@ -128,31 +127,27 @@ __libc_fcntl (int fd, int cmd, ...)
 case F_SETLK:
 case F_SETLKW:
   {
-	/* XXX
-	   We need new RPCs to support POSIX.1 fcntl file locking!!
-	   For the time being we support the whole-file case only,
-	   with all kinds of WRONG WRONG WRONG semantics,
-	   by using flock.  This is definitely the Wrong Thing,
-	   but it might be better than nothing (?).  */
 	struct flock *fl = va_arg (ap, struct flock *);
-	va_end (ap);
+	mach_port_t rendezvous = MACH_PORT_NULL;
+
 	switch (cmd)
 	  {
 	  case F_GETLK:
-	errno = ENOSYS;
-	return -1;
+	cmd = F_GETLK64;
+	break;
 	  case F_SETLK:
-	cmd = LOCK_NB;
+	cmd = F_SETLK64;
 	break;
-	  default:
-	cmd = 0;
+	  case F_SETLKW:
+	cmd = F_SETLKW64;
 	break;
 	  }
 	switch (fl->l_type)
 	  {
-	  case F_RDLCK: cmd |= LOCK_SH; break;
-	  case F_WRLCK: cmd |= LOCK_EX; break;
-	  case F_UNLCK: cmd |= LOCK_UN; break;
+	  case F_RDLCK:
+	  case F_WRLCK:
+	  case F_UNLCK:
+	break;
 	  default:
 	errno = EINVAL;
 	return -1;
@@ -160,24 +155,73 @@ __libc_fcntl (int fd, int cmd, ...)
 	switch (fl->l_whence)
 	  {
 	  case SEEK_SET:
-	if (fl->l_start == 0 && fl->l_len == 0) /* Whole file request.  */
-	  break;
-	/* It seems to be common for applications to lock the first
-	   byte of the file when they are really doing whole-file locking.
-	   So, since it's so wrong already, might as well do that too.  */
-	if (fl->l_start == 0 && fl->l_len == 1)
-	  break;
-	/* FALLTHROUGH */
 	  case SEEK_C

[PATCH] 2(3) hurd+glibc: Support for file record locking

[Svante Signell]

Attached is the second part of the patches for file record locking:
libnetfs_file_record_lock.patch
pflocal_fs.c.patch
hurd_add_RPC.patch

Thanks!
hurd/ChangeLog

2019-02-01  Svante Signell 

	* Update copyright years.

2018-01-05  Svante Signell 

	* Update copyright years.
	* fs.defs: Add new argument rendezvous: mach_port_send_t to RPC file_record_lock.

2017-01-05  Svante Signell 

	* Update copyright years and headers.

2016-05-23  Svante Signell 

	* fs.defs: Added description.
	* hurd_types.defs: Make struct flock_t seven integers long since
	  l_start and l_len are 64bit.
	* hurd_types.h: typedef flock_t as flock64.

2001-04-10  Neal H Walfield  

	* fs.defs: New RPC file_record_lock.
	* hurd_types.defs: Import .

Index: hurd-0.9.git20190331-8.2/hurd/fs.defs
===
--- hurd-0.9.git20190331-8.2.orig/hurd/fs.defs
+++ hurd-0.9.git20190331-8.2/hurd/fs.defs
@@ -1,23 +1,22 @@
 /* Definitions for the filesystem interface.
-   Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2010
+
+   Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2010, 2014-2019
Free Software Foundation, Inc.
 
-This file is part of the GNU Hurd.
+   This file is part of the GNU Hurd.
 
-The GNU Hurd 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 2, or (at your option)
-any later version.
-
-The GNU Hurd 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.
-
-You should have received a copy of the GNU General Public License
-along with the GNU Hurd; see the file COPYING.  If not, write to
-the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+   The GNU Hurd 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 2, or (at your option)
+   any later version.
+
+   The GNU Hurd 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.
 
+   You should have received a copy of the GNU General Public License
+   along with the GNU Hurd.  If not, see <http://www.gnu.org/licenses/>.  */
 
 /* All these objects also implement the generic IO facilities. */
 
@@ -358,6 +357,18 @@ routine file_reparent (
 skip;	/* Was: file_get_children.  */
 skip;	/* Was: file_get_source.  */
 
+
+/* Do fcntl type locking on FILE. CMD is from the set F_GETLK64,
+ F_SETLK64, F_SETLKW64. FLOCK64 is passed by the user and is as
+ defined by . RENDEZVOUS is MACH_PORT_NULL for per opened
+ file locking and !MACH_PORT_NULL for per process file locking */
+routine file_record_lock (
+   file: file_t;
+   RPT
+   cmd: int;
+   inout flock64: flock_t;
+   rendezvous: mach_port_send_t);
+
 /* Overlay a task with a file.  Necessary initialization, including
authentication changes associated with set[ug]id execution must be
handled by the filesystem.  Filesystems normally implement this by
Index: hurd-0.9.git20190331-8.2/hurd/hurd_types.defs
===
--- hurd-0.9.git20190331-8.2.orig/hurd/hurd_types.defs
+++ hurd-0.9.git20190331-8.2/hurd/hurd_types.defs
@@ -1,22 +1,22 @@
 /* MiG type declarations for Hurd interfaces		-*- C -*-
-   Copyright (C) 1993,94,95,96,98,2001,02,17 Free Software Foundation, Inc.
 
-This file is part of the GNU Hurd.
+   Copyright (C) 1993-1996, 1998, 2001, 2002, 2014-2019
+   Free Software Foundation, Inc.
 
-The GNU Hurd 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 2, or (at your option)
-any later version.
-
-The GNU Hurd 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.
-
-You should have received a copy of the GNU General Public License
-along with the GNU Hurd; see the file COPYING.  If not, write to
-the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+   This file is part of the GNU Hurd.
 
+   The GNU Hurd 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 2, or (at your option)
+   any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied wa

[PATCH] 1(3) hurd+glibc: Support for file record locking

[Svante Signell]

Hello,

Attached is the first part of the patches for file record locking:
libfshelp_rlock.patch
libdiskfs_file_record_lock.patch
libtrivfs_file_record_lock.patch

The second part is following in a subsequent email:
libnetfs_file_record_lock.patch
pflocal_fs.c.patch
hurd_add_RPC.patch

The third part is following in a subsequent email:
libfshelp-tests_rlock.patch
revert-git-lockf-0.diff
revert-git-fcntl64.diff
fcntl.diff

The hurd patches are made against Debian version 0.9.git20190331-8 and
the glibc patch against 2.29-1. The patches should preferably be
applied in the same order as above. 

All patches contains preliminary changelog entries.

In order to enable upstream commits the code in libtrivfs_file_record_lock.patch
has been stubbed out for now. More (free)time is needed to make e.g. locking of
/dev/null working properly.


Thanks!
libdiskfs/ChangeLog

2019-03-04  Svante Signell 

	* file-lock.c: Make flock work regardless of the
  mode in which the file was opened.

2019-02-12  Svante Signell 

	* file-lock.c: Comment out "Make flock work without R or W mode"

2019-02-01  Svante Signell 

	* Update copyright years.
	* file-record-lock.c(diskfs_S_file_record_lock):
	  Don't set rendezvous to MACH_PORT_NULL.

2018-12-07  Svante Signell 

	* Update copyright years.
	* dir-lookup.c(diskfs_S_dir_lookup): Call fshelp_rlock_tweak()
  with new last argument rendezvous = MACH_PORT_NULL.
	* file-lock.c(diskfs_S_file_lock): Likewise.
	* file-record-lock.c(diskfs_S_file_record_lock): Likewise.
	(diskfs_S_file_record_lock): Add new argument mach_port_t rendezvous.

2017-01-05  Svante Signell 

	* Update copyright years and headers.

2016-05-23  Svante Signell 

	* define temporary CPP_FLAGS until glibc is updated
	* file-lock-stat.c: Port from cthreads to libpthread.
	* file-lock.c: Likewise.
	* file-record-lock: Likewise.

2001-04-11  Neal H Walfield  

	* Makefile (FSSRCS): Add file-record-lock.c.
	* diskfs.h (struct peropen): Change the type of lock_status
	from an int to a struct rlock_peropen.
	(struct node): Change the type of userbox from a struct lock_box
	to a struct rlock_box.
	* dir-lookup.c (diskfs_S_dir_lookup): Use fshelp_rlock_tweak
	as fshelp_acquire_lock is now depreciated.
	* file-lock-stat.c (diskfs_S_file_lock_stat): Total rewrite
	around the new record locking functions.
	* file-lock.c (diskfs_S_file_lock): Total rewrite around the
	new record locking functions.
	* file-record-lock.c: New file.  Implement
	diskfs_S_file_record_lock.
	* node-make.c (diskfs_make_node):  Initialize userbox with
	fshelp_rlock_init.
	* peropen-make.c (diskfs_make_peropen): Initialize lock_status
	using fshelp_rlock_po_init.
	* peropen-rele.c (diskfs_release_peropen): Release lock_status
	using fshelp_rlock_drop_peropen.
	
Index: hurd-0.9.git20190331-8.2/libdiskfs/Makefile
===
--- hurd-0.9.git20190331-8.2.orig/libdiskfs/Makefile
+++ hurd-0.9.git20190331-8.2/libdiskfs/Makefile
@@ -1,4 +1,4 @@
-#   Copyright (C) 1994,95,96,97,98,99,2000,01,2006,2012
+#   Copyright (C) 1994,95,96,97,98,99,2000,01,2006,2012,2016-2019
 # Free Software Foundation, Inc.
 #
 #   This program is free software; you can redistribute it and/or
@@ -12,8 +12,7 @@
 #   General Public License for more details.
 #
 #   You should have received a copy of the GNU General Public License
-#   along with this program; if not, write to the Free Software
-#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+#   along with the GNU Hurd.  If not, see <http://www.gnu.org/licenses/>.
 
 dir := libdiskfs
 makemode := library
@@ -26,7 +25,8 @@ FSSRCS= dir-chg.c dir-link.c dir-lookup.
 	file-get-trans.c file-get-transcntl.c file-getcontrol.c \
 	file-getfh.c file-getlinknode.c file-lock-stat.c \
 	file-lock.c file-set-size.c file-set-trans.c file-statfs.c \
-	file-sync.c file-syncfs.c file-utimes.c file-reparent.c
+	file-sync.c file-syncfs.c file-utimes.c file-record-lock.c \
+	file-reparent.c
 IOSRCS= io-async-icky.c io-async.c io-duplicate.c io-get-conch.c io-revoke.c \
 	io-map-cntl.c io-map.c io-modes-get.c io-modes-off.c \
 	io-modes-on.c io-modes-set.c io-owner-mod.c io-owner-get.c \
@@ -72,4 +72,10 @@ ifsock-MIGSFLAGS = -imacros $(srcdir)/fs
 exec_startup-MIGSFLAGS = -imacros $(srcdir)/fsmutations.h
 MIGCOMSFLAGS = -prefix diskfs_
 
+# Define the 64 bit versions of the second argument to fcntl()
+# Can safely be removed when glibc is updated
+EXTRA_CPP_FLAGS= -DF_GETLK64=10 -DF_SETLK64=11 -DF_SETLKW64=12
+dir-lookup-CPPFLAGS += $(EXTRA_CPP_FLAGS)
+file-lock-CPPFLAGS += $(EXTRA_CPP_FLAGS)
+
 include ../Makeconf
Index: hurd-0.9.git20190331-8.2/libdiskfs/diskfs.h
===
--- hurd-0.9.git20190331-8.2.orig/libdiskfs/diskfs.h
+++ hurd-0.9.git20190331-8.2/libdiskfs/diskfs.h
@@ -1,7 +1,7 @@
 /* Definitions for fileserver helper functions
 
-   Copyright (C) 1994, 1995, 1996, 1997, 1998, 

Re: Need help with mach_printf()

[Svante Signell]

On Fri, 2019-03-08 at 11:45 +0100, Samuel Thibault wrote:
> Perhaps you rather have to use 
> 
> settrans -cap /dev/null /usr/bin/env
> LD_LIBRARY_PATH=/home/srs/hurd.debs/0.9.git20190303-1.3/libfshelp-tests/libs
> /hurd/null

Using the /usr/bin/env trick seems to work. Maybe the example by Thomas I
mentioned could be complemented with this case?

Thanks!

Re: Need help with mach_printf()

[Svante Signell]

On Fri, 2019-03-08 at 11:42 +0100, Svante Signell wrote:
> On Fri, 2019-03-08 at 11:39 +0100, Svante Signell wrote:
> > On Fri, 2019-03-08 at 11:28 +0100, Samuel Thibault wrote:
> > > Use mach_print for a start, to avoid any potential problem with vsnprintf
> > > etc.
> > > 
> > > Svante Signell, le ven. 08 mars 2019 11:16:32 +0100, a ecrit:
> > > > (cd libs; ln -s libtrivfs.so.0.3 libtrivfs.so.0)
> > > > export LD_LIBRARY_PATH=./libs
> > > > ldd /hurd/null
> > > > libtrivfs.so.0.3 => ./libs/libtrivfs.so.0.3 (0x01029000)
> > > 
> > > If it's /dev/null that you want to debug, it's for the start of /dev/null
> > > that
> > > you
> > > need to set LD_LIBRARY_PATH. And do not set the variable then sudo to
> > > start /dev/null, sudo clears the environment.
> > 
> > So I need to do as root?
> > LD_LIBRARY_PATH=/home/srs/hurd.debs/0.9.git20190303-1.3/libfshelp-tests/libs
> >  
> > \
> > settrans -cap /dev/null /hurd/null
> 
> Does not work :(

There is an example written by Thomas at:
https://www.gnu.org/software/hurd/hurd/debugging/translator.html
I think it has to be improved, or another example like my problem to be added!

Re: Need help with mach_printf()

[Svante Signell]

On Fri, 2019-03-08 at 11:39 +0100, Svante Signell wrote:
> On Fri, 2019-03-08 at 11:28 +0100, Samuel Thibault wrote:
> > Use mach_print for a start, to avoid any potential problem with vsnprintf
> > etc.
> > 
> > Svante Signell, le ven. 08 mars 2019 11:16:32 +0100, a ecrit:
> > > (cd libs; ln -s libtrivfs.so.0.3 libtrivfs.so.0)
> > > export LD_LIBRARY_PATH=./libs
> > > ldd /hurd/null
> > > libtrivfs.so.0.3 => ./libs/libtrivfs.so.0.3 (0x01029000)
> > 
> > If it's /dev/null that you want to debug, it's for the start of /dev/null
> > that
> > you
> > need to set LD_LIBRARY_PATH. And do not set the variable then sudo to
> > start /dev/null, sudo clears the environment.
> 
> So I need to do as root?
> LD_LIBRARY_PATH=/home/srs/hurd.debs/0.9.git20190303-1.3/libfshelp-tests/libs \
> settrans -cap /dev/null /hurd/null

Does not work :(

Re: Need help with mach_printf()

[Svante Signell]

On Fri, 2019-03-08 at 11:28 +0100, Samuel Thibault wrote:
> Use mach_print for a start, to avoid any potential problem with vsnprintf etc.
> 
> Svante Signell, le ven. 08 mars 2019 11:16:32 +0100, a ecrit:
> > (cd libs; ln -s libtrivfs.so.0.3 libtrivfs.so.0)
> > export LD_LIBRARY_PATH=./libs
> > ldd /hurd/null
> > libtrivfs.so.0.3 => ./libs/libtrivfs.so.0.3 (0x01029000)
> 
> If it's /dev/null that you want to debug, it's for the start of /dev/null that
> you
> need to set LD_LIBRARY_PATH. And do not set the variable then sudo to
> start /dev/null, sudo clears the environment.

So I need to do as root?
LD_LIBRARY_PATH=/home/srs/hurd.debs/0.9.git20190303-1.3/libfshelp-tests/libs \
settrans -cap /dev/null /hurd/null

Need help with mach_printf()

[Svante Signell]

Hi,

As written on bug-hurd IRC. Attached is the relevant code.

Thanks!
/*
   Copyright (C) 1994, 2002, 2015-2019 Free Software Foundation, Inc.

   This program 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 2, or (at
   your option) any later version.

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

   You should have received a copy of the GNU General Public License
   along with the GNU Hurd.  If not, see .
*/

#include "priv.h"
#include "trivfs_fs_S.h"

#include 
#include 
#include "mach-printf.h"

kern_return_t
trivfs_S_file_lock (struct trivfs_protid *cred,
		mach_port_t reply, mach_msg_type_name_t reply_type,
		int flags)
{
  error_t err = 0;
  struct flock64 lock;
  struct trivfs_peropen *po = cred->po;
  struct trivfs_node *tp = cred->po->tp;
  int openmodes = cred->po->openmodes;
  mach_port_t rendezvous = MACH_PORT_NULL;

  if (!cred)
return EOPNOTSUPP;

  mach_printf("libtrivfs/file-lock.c(trivfs_S_file_lock)\n");
  lock.l_whence = SEEK_SET;
  lock.l_start = 0;
  lock.l_len = 0;

  if (flags & LOCK_UN)
lock.l_type = F_UNLCK;
  else if (flags & LOCK_SH)
lock.l_type = F_RDLCK;
  else if (flags & LOCK_EX)
lock.l_type = F_WRLCK;
  else
return EINVAL;

  if (!po)
{
  mach_printf("libtrivfs/file-lock.c(trivfs_S_file_lock): !po\n");
  po = trivfs_make_peropen (cred, flags);
  if (!po)
	return ENOMEM;
  cred->po = po;
}

  if (!tp)
{
  mach_printf("libtrivfs/file-lock.c(trivfs_S_file_lock): !tp\n");
  tp = trivfs_make_node();
  if (!tp)
	return ENOMEM;
  cred->po->tp = tp;
}

  /*
XXX: Fix for flock(2) calling fcntl(2)
From flock(2): A shared or exclusive lock can be placed on a file
regardless of the mode in which the file was opened.
  */
  if (cred->po->openmodes & (O_RDONLY|O_WRONLY|O_EXEC)) openmodes |= O_RDONLY|O_WRONLY;

  pthread_mutex_lock (>lock);
  err = fshelp_rlock_tweak (>credlock, >lock,
			>po->lock_status, openmodes,
			0, 0, flags & LOCK_NB ? F_SETLK64 : F_SETLKW64,
			, rendezvous);
  pthread_mutex_unlock (>lock);

  return err;
}
#include 
#include 

void mach_print(const char *);

#ifndef EXTERNAL_MACH_PRINT
asm (".global mach_print;"
 " mach_print:;"
 " mov $0xffe2, %eax;"
 " lcall $0x7, $0x0;"
 " ret;");
#endif /* EXTERNAL_MACH_PRINT */

#define BUFFER_SIZE 1024
static void
mach_printf(const char *format, ...)
{
  va_list ap;
  char buf[BUFFER_SIZE];

  va_start(ap, format);
  vsnprintf(buf, sizeof(buf), format, ap);
  mach_print(buf);
  va_end(ap);
}

emacs libtrivfs/file-lock.c
#include "mach_printf.h"
Add mach_printf statements.
mach_printf("libdiskfs/file-lock.c(trivfs_S_file_lock)\n");

make -C build-deb/libtrivfs
find build-deb -name 'libtrivfs.so*'
build-deb/libtrivfs/libtrivfs.so.0.3
build-deb/libtrivfs/libtrivfs.so
build-deb/lib/libtrivfs.so.0.3
srs@hurd-2014:~/hurd.debs/0.9.git20190303-1.2/libfshelp-tests$
mkdir libs
scp -p -P 5577 
10.0.2.2:~/DEBs/hurd/hurd-0.9.git20190303-1.3/build-deb/libtrivfs/libtrivfs.so.0.3
 libs
(cd libs; ln -s libtrivfs.so.0.3 libtrivfs.so.0)
export LD_LIBRARY_PATH=./libs
ldd /hurd/null
libtrivfs.so.0.3 => ./libs/libtrivfs.so.0.3 (0x01029000)
./test-flock /dev/null
...
Installed version of libtrivfs.so is used not the one in libs. 
No output on console :(

Re: [Bug hurd/24110] SS_DISABLE never set in stack_t value returned by sigaltstack

[Svante Signell]

On Fri, 2019-03-01 at 07:04 -0800, Samuel Thibault wrote:
> Svante Signell, le lun. 25 févr. 2019 10:25:01 +0100, a ecrit:
> > Unfortunately, the situation has not improved with it :(
> > 
> > The SIGILL failures are now SIGABRT and SIGSEGV as they became with the
> > SS_DISABLE patch.
> 
> It however seems that the failures are different?
> (possibly with much more understandable backtraces)

No they are not from a global tests perspective. That requires further
investigations. I suspect the problems arise earlier in the backtrace chain. One
suspicion is the *context functions. Can they be called more than once without
problems? Unfortunately I don't know anything (have forgotten everything) about
assembly code...

Just a thought!

Re: [Bug hurd/24110] SS_DISABLE never set in stack_t value returned by sigaltstack

[Svante Signell]

On Thu, 2019-02-21 at 20:56 +0100, Samuel Thibault wrote:
> Hello,
> 
> Mmmm, while having a look at glibc-2.29, I realized one patch was
> missing, to enable thread-specific signal delivery.  It looks like
> fixing this gets to go to better work.  I'll run the glibc testsuite
> and probably upload a new glibc soon, and probably try to re-trigger
> all golang package builds :)

I've now built glibc 2.28-8, with the missing patch,
libpthread_sigs.diff, compiled and run the go tests on gcc-9-9-
20190223-1. Unfortunately, the situation has not improved with it :(

The SIGILL failures are now SIGABRT and SIGSEGV as they became with the
SS_DISABLE patch.

However, nice to see that gccgo for Hurd now is fully upstream :)

Re: [PATCH] 1(3) hurd+glibc: Support for file record locking

[Svante Signell]

On Sat, 2019-02-02 at 14:34 +0100, Samuel Thibault wrote:
> Hello,

> So can you confirm my guesswork above? If, so, then only keep the first
> line (the second line doesn't make sense in my guesswork), and mention
> that while fcntl requires WR access for exclusive lock, flock doesn't.

I've now run the tests for flock:
./test-flock
./test-flock: Usage: ./test-flock file [flags] [operation] [sleep_time]
   file   : file name/device name
   flags  : r (O_RDONLY) | w [O_WRONLY] | rw (O_RDWR)
   operation  : s [LOCK_SH], x (LOCK_EX), u (LOCK_UN),
sn (LOCK_SH | LOCK_UN), xn (LOCK_EX | LOCK_UN)
   sleep_time : st [10]

GNU/Linux and GNU/Hurd: (all OK)
Terminal 1 and Terminal 2:
./test-flock foo r x
./test-flock foo w x
./test-flock foo r xn
./test-flock foo w xn

Without both statements below the tests would not work for all cases above, at
least according to my understanding. Note that these statements are made only
for the *_S_file_lock.c files, i.e. the flock case.

if ((openstat & O_RDONLY) && !(openstat & O_WRONLY)) openstat |= O_WRONLY;
if (!(openstat & O_RDONLY) && (openstat & O_WRONLY)) openstat |= O_RDONLY;

I will add comments in the code when we agree of the above issue and re-submit
the libdiskfs and libnetfs patches.

I've found some locking error in the libtrivfs implementation. BBL on that.
(and will supply updated patches for libtrivfs and libfshelp-tests)

Re: [PATCH] 1(3) hurd+glibc: Support for file record locking

[Svante Signell]

On Sat, 2019-02-02 at 14:34 +0100, Samuel Thibault wrote:
> Hello,
> 
> Thanks for the fixes!

YW!

> Svante Signell, le sam. 02 févr. 2019 11:52:56 +0100, a ecrit:
> > On Sun, 2018-12-30 at 21:21 +0100, Samuel Thibault wrote:
> > > Svante Signell, le sam. 22 déc. 2018 13:07:37 +0100, a ecrit:
> > > >  diskfs_S_file_lock (struct protid *cred, int flags)
> > > >  {
> > > ...
> > > > +  /* XXX: Fix for flock(2) calling fcntl(2) */
> > > > +  if ((openstat & O_RDONLY) && !(openstat & O_WRONLY)) openstat |=
> > > > O_WRONLY;
> > > > +  if (!(openstat & O_RDONLY) && (openstat & O_WRONLY)) openstat |=
> > > > O_RDONLY;
> > > 
> > > I don't understand this: in which application case is this needed?
> > 
> > I added this when running tests for flock(2) and comparing the behaviour
> > with Linux, see the test file libfshelp-tests/test-flock.c.
> 
> Do you mean: in the case of a file opened without WR open mode, taking
> an exclusive lock would fail otherwise?
> (really, that's the bit of information I was looking for, having to
> guess it is errorprone...)

Yes, I think that was the problem. I have to re-run the tests to be sure, it was
some time ago since I made those changes.

> Continuing on guesswork, I guess you noticed that Linux allows to take
> an exclusive lock with flock even without WR open mode?
> 
> If that's so, then indeed the fcntl lock doesn't allow it (as mentioned
> in POSIX:
> 
>   A request for an exclusive lock shall fail if the file descriptor was
>   not opened with write access.
> 
> But we only want to fix that case, and not just blindly set open modes
> without an explained rationale.

OK!

> So can you confirm my guesswork above? If, so, then only keep the first
> line (the second line doesn't make sense in my guesswork), and mention
> that while fcntl requires WR access for exclusive lock, flock doesn't.

Ok, I'll run the tests again, make those changes and reupload.

[PATCH] 3(3) hurd+glibc: Support for file record locking

[Svante Signell]

Attached is the third part of the patches for file record locking:
libfshelp-tests_rlock.patch
fcntl.diff

The patch fcntl.diff against glibc-2.28-5 should be applied after
(or at the same time as) the patched hurd debs.

Note that the following glibc patches have been commented out from the
series file:
#hurd-i386/git-fcntl64.diff
#hurd-i386/git-lockf-0.diff
#hurd-i386/tg-WRLCK-upgrade.diff

Thanks!
sysdeps/mach/hurd/Changelog
2019-01-12  Svante Signell 

	* Update copyright years.

2018-12-21  Svante Signell 

	* hurd-i386/fcntl.diff: Add the required new arguments when
	  calling the updated RPC file_record_lock.

2018-12-04  Svante Signell 

	* debian/patches/series: Comment out debian 2.28-1 patches:
	  hurd-i386/git-fcntl64.diff
	  hurd-i386/git-lockf-0.diff
	  hurd-i386/tg-WRLCK-upgrade.diff

	* fcntl.c: Add support weak, hidden and strong references as
	  in Debian 2.28-1 patch as in hurd-i386/git-fcntl64.diff.

	* fcntl64.c: New file, defined in fcntl.c as an alias. 

	* hurd-i386/fcntl.diff: Refresh.

2014-08-21  Svante Signell 

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

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

Index: glibc-2.28-4.1/sysdeps/mach/hurd/bits/fcntl.h
===
--- glibc-2.28-4.1.orig/sysdeps/mach/hurd/bits/fcntl.h
+++ glibc-2.28-4.1/sysdeps/mach/hurd/bits/fcntl.h
@@ -1,5 +1,5 @@
 /* O_*, F_*, FD_* bit values for GNU.
-   Copyright (C) 1993-2018 Free Software Foundation, Inc.
+   Copyright (C) 1993-2019 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -163,9 +163,18 @@
 # define F_GETOWN	5	/* Get owner (receiver of SIGIO).  */
 # define F_SETOWN	6	/* Set owner (receiver of SIGIO).  */
 #endif
+#ifdef __USE_FILE_OFFSET64
+# define	F_GETLK		F_GETLK64
+# define	F_SETLK		F_SETLK64
+# define	F_SETLKW	F_SETLKW64
+#else
 #define	F_GETLK		7	/* Get record locking info.  */
 #define	F_SETLK		8	/* Set record locking info (non-blocking).  */
 #define	F_SETLKW	9	/* Set record locking info (blocking).  */
+#endif
+#define	F_GETLK64	10	/* Get record locking info.  */
+#define	F_SETLK64	11	/* Set record locking info (non-blocking).  */
+#define	F_SETLKW64	12	/* Set record locking info (blocking).  */
 
 #ifdef __USE_XOPEN2K8
 # define F_DUPFD_CLOEXEC 1030	/* Duplicate, set FD_CLOEXEC on new one.  */
Index: glibc-2.28-4.1/sysdeps/mach/hurd/fcntl.c
===
--- glibc-2.28-4.1.orig/sysdeps/mach/hurd/fcntl.c
+++ glibc-2.28-4.1/sysdeps/mach/hurd/fcntl.c
@@ -1,4 +1,4 @@
-/* Copyright (C) 1992-2018 Free Software Foundation, Inc.
+/* Copyright (C) 1992-2019 Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
The GNU C Library is free software; you can redistribute it and/or
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 		/* XXX for LOCK_* */
 
 /* Perform file control operations on FD.  */
 int
@@ -128,31 +127,27 @@ __libc_fcntl (int fd, int cmd, ...)
 case F_SETLK:
 case F_SETLKW:
   {
-	/* XXX
-	   We need new RPCs to support POSIX.1 fcntl file locking!!
-	   For the time being we support the whole-file case only,
-	   with all kinds of WRONG WRONG WRONG semantics,
-	   by using flock.  This is definitely the Wrong Thing,
-	   but it might be better than nothing (?).  */
 	struct flock *fl = va_arg (ap, struct flock *);
-	va_end (ap);
+	mach_port_t rendezvous = MACH_PORT_NULL;
+
 	switch (cmd)
 	  {
 	  case F_GETLK:
-	errno = ENOSYS;
-	return -1;
+	cmd = F_GETLK64;
+	break;
 	  case F_SETLK:
-	cmd = LOCK_NB;
+	cmd = F_SETLK64;
 	break;
-	  default:
-	cmd = 0;
+	  case F_SETLKW:
+	cmd = F_SETLKW64;
 	break;
 	  }
 	switch (fl->l_type)
 	  {
-	  case F_RDLCK: cmd |= LOCK_SH; break;
-	  case F_WRLCK: cmd |= LOCK_EX; break;
-	  case F_UNLCK: cmd |= LOCK_UN; break;
+	  case F_RDLCK:
+	  case F_WRLCK:
+	  case F_UNLCK:
+	break;
 	  default:
 	errno = EINVAL;
 	return -1;
@@ -160,24 +155,73 @@ __libc_fcntl (int fd, int cmd, ...)
 	switch (fl->l_whence)
 	  {
 	  case SEEK_SET:
-	if (fl->l_start == 0 && fl->l_len == 0) /* Whole file request.  */
-	  break;
-	/* It seems to be common for applications to lock the first
-	   byte of the file when they are really doing whole-file locking.
-	   So, since it's so wrong already, might as well do that too.  */
-	if (fl->l_start == 0 && fl->l_len == 1)
-	  break;
-	/* FALLTHROUGH */
 	  case SEEK_CUR:
 	  case SEEK_END:
-	errno = ENOTSUP;
+	break;
+	  default:
+	errno = EINVAL;
 	return

[PATCH] 2(3) hurd+glibc: Support for file record locking

[Svante Signell]

Attached is the second part of the patches for file record locking:
libnetfs_file_record_lock.patch
pflocal_fs.c.patch
hurd_add_RPC.patch

Thanks!
hurd/ChangeLog

2019-02-01  Svante Signell 

	* Update copyright years.

2018-01-05  Svante Signell 

	* Update copyright years.
	* fs.defs: Add new argument rendezvous: mach_port_send_t to RPC file_record_lock.

2017-01-05  Svante Signell 

	* Update copyright years and headers.

2016-05-23  Svante Signell 

	* fs.defs: Added description.
	* hurd_types.defs: Make struct flock_t seven integers long since
	  l_start and l_len are 64bit.
	* hurd_types.h: typedef flock_t as flock64.

2001-04-10  Neal H Walfield  

	* fs.defs: New RPC file_record_lock.
	* hurd_types.defs: Import .

Index: hurd-0.9.git20181030-4.1/hurd/fs.defs
===
--- hurd-0.9.git20181030-4.1.orig/hurd/fs.defs
+++ hurd-0.9.git20181030-4.1/hurd/fs.defs
@@ -1,23 +1,22 @@
 /* Definitions for the filesystem interface.
-   Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2010
+
+   Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2010, 2014-2019
Free Software Foundation, Inc.
 
-This file is part of the GNU Hurd.
+   This file is part of the GNU Hurd.
 
-The GNU Hurd 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 2, or (at your option)
-any later version.
-
-The GNU Hurd 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.
-
-You should have received a copy of the GNU General Public License
-along with the GNU Hurd; see the file COPYING.  If not, write to
-the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+   The GNU Hurd 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 2, or (at your option)
+   any later version.
+
+   The GNU Hurd 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.
 
+   You should have received a copy of the GNU General Public License
+   along with the GNU Hurd.  If not, see <http://www.gnu.org/licenses/>.  */
 
 /* All these objects also implement the generic IO facilities. */
 
@@ -358,6 +357,18 @@ routine file_reparent (
 skip;	/* Was: file_get_children.  */
 skip;	/* Was: file_get_source.  */
 
+
+/* Do fcntl type locking on FILE. CMD is from the set F_GETLK64,
+ F_SETLK64, F_SETLKW64. FLOCK64 is passed by the user and is as
+ defined by . RENDEZVOUS is MACH_PORT_NULL for per opened
+ file locking and !MACH_PORT_NULL for per process file locking */
+routine file_record_lock (
+   file: file_t;
+   RPT
+   cmd: int;
+   inout flock64: flock_t;
+   rendezvous: mach_port_send_t);
+
 /* Overlay a task with a file.  Necessary initialization, including
authentication changes associated with set[ug]id execution must be
handled by the filesystem.  Filesystems normally implement this by
Index: hurd-0.9.git20181030-4.1/hurd/hurd_types.defs
===
--- hurd-0.9.git20181030-4.1.orig/hurd/hurd_types.defs
+++ hurd-0.9.git20181030-4.1/hurd/hurd_types.defs
@@ -1,22 +1,22 @@
 /* MiG type declarations for Hurd interfaces		-*- C -*-
-   Copyright (C) 1993,94,95,96,98,2001,02,17 Free Software Foundation, Inc.
 
-This file is part of the GNU Hurd.
+   Copyright (C) 1993-1996, 1998, 2001, 2002, 2014-2019
+   Free Software Foundation, Inc.
 
-The GNU Hurd 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 2, or (at your option)
-any later version.
-
-The GNU Hurd 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.
-
-You should have received a copy of the GNU General Public License
-along with the GNU Hurd; see the file COPYING.  If not, write to
-the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+   This file is part of the GNU Hurd.
 
+   The GNU Hurd 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 2, or (at your option)
+   any later version.
+
+   The GNU Hurd is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied wa

[PATCH] 1(3) hurd+glibc: Support for file record locking

[Svante Signell]

Hello,

Attached is the first part of the patches for file record locking:
libfshelp_rlock.patch
libdiskfs_file_record_lock.patch
libtrivfs_file_record_lock.patch

The second part is following in a subsequent email:
libnetfs_file_record_lock.patch
pflocal_fs.c.patch
hurd_add_RPC.patch

The third part is following in a subsequent email:
libfshelp-tests_rlock.patch
fcntl.diff

The hurd patches are made against Debian version 0.9.git20181030-4 and
the glibc patch against 2.28-5. The patches should preferably be
applied in the same order as above. 

All patches contains preliminary changelog entries.

Thanks!
libdiskfs/ChangeLog

2019-02-01  Svante Signell 

	* Update copyright years.
	* file-record-lock.c(diskfs_S_file_record_lock):
	  Don't set rendezvous to MACH_PORT_NULL.

2018-12-07  Svante Signell 

	* Update copyright years.
	* dir-lookup.c(diskfs_S_dir_lookup): Call fshelp_rlock_tweak()
  with new last argument rendezvous = MACH_PORT_NULL.
	* file-lock.c(diskfs_S_file_lock): Likewise.
	* file-record-lock.c(diskfs_S_file_record_lock): Likewise.
	(diskfs_S_file_record_lock): Add new argument mach_port_t rendezvous.

2017-01-05  Svante Signell 

	* Update copyright years and headers.

2016-05-23  Svante Signell 

	* define temporary CPP_FLAGS until glibc is updated
	* file-lock-stat.c: Port from cthreads to libpthread.
	* file-lock.c: Likewise.
	* file-record-lock: Likewise.

2001-04-11  Neal H Walfield  

	* Makefile (FSSRCS): Add file-record-lock.c.
	* diskfs.h (struct peropen): Change the type of lock_status
	from an int to a struct rlock_peropen.
	(struct node): Change the type of userbox from a struct lock_box
	to a struct rlock_box.
	* dir-lookup.c (diskfs_S_dir_lookup): Use fshelp_rlock_tweak
	as fshelp_acquire_lock is now depreciated.
	* file-lock-stat.c (diskfs_S_file_lock_stat): Total rewrite
	around the new record locking functions.
	* file-lock.c (diskfs_S_file_lock): Total rewrite around the
	new record locking functions.
	* file-record-lock.c: New file.  Implement
	diskfs_S_file_record_lock.
	* node-make.c (diskfs_make_node):  Initialize userbox with
	fshelp_rlock_init.
	* peropen-make.c (diskfs_make_peropen): Initialize lock_status
	using fshelp_rlock_po_init.
	* peropen-rele.c (diskfs_release_peropen): Release lock_status
	using fshelp_rlock_drop_peropen.
	
Index: hurd-0.9.git20181030-4.1/libdiskfs/Makefile
===
--- hurd-0.9.git20181030-4.1.orig/libdiskfs/Makefile
+++ hurd-0.9.git20181030-4.1/libdiskfs/Makefile
@@ -1,4 +1,4 @@
-#   Copyright (C) 1994,95,96,97,98,99,2000,01,2006,2012
+#   Copyright (C) 1994,95,96,97,98,99,2000,01,2006,2012,2016-2019
 # Free Software Foundation, Inc.
 #
 #   This program is free software; you can redistribute it and/or
@@ -12,8 +12,7 @@
 #   General Public License for more details.
 #
 #   You should have received a copy of the GNU General Public License
-#   along with this program; if not, write to the Free Software
-#   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+#   along with the GNU Hurd.  If not, see <http://www.gnu.org/licenses/>.
 
 dir := libdiskfs
 makemode := library
@@ -26,7 +25,8 @@ FSSRCS= dir-chg.c dir-link.c dir-lookup.
 	file-get-trans.c file-get-transcntl.c file-getcontrol.c \
 	file-getfh.c file-getlinknode.c file-lock-stat.c \
 	file-lock.c file-set-size.c file-set-trans.c file-statfs.c \
-	file-sync.c file-syncfs.c file-utimes.c file-reparent.c
+	file-sync.c file-syncfs.c file-utimes.c file-record-lock.c \
+	file-reparent.c
 IOSRCS= io-async-icky.c io-async.c io-duplicate.c io-get-conch.c io-revoke.c \
 	io-map-cntl.c io-map.c io-modes-get.c io-modes-off.c \
 	io-modes-on.c io-modes-set.c io-owner-mod.c io-owner-get.c \
@@ -72,4 +72,10 @@ ifsock-MIGSFLAGS = -imacros $(srcdir)/fs
 exec_startup-MIGSFLAGS = -imacros $(srcdir)/fsmutations.h
 MIGCOMSFLAGS = -prefix diskfs_
 
+# Define the 64 bit versions of the second argument to fcntl()
+# Can safely be removed when glibc is updated
+EXTRA_CPP_FLAGS= -DF_GETLK64=10 -DF_SETLK64=11 -DF_SETLKW64=12
+dir-lookup-CPPFLAGS += $(EXTRA_CPP_FLAGS)
+file-lock-CPPFLAGS += $(EXTRA_CPP_FLAGS)
+
 include ../Makeconf
Index: hurd-0.9.git20181030-4.1/libdiskfs/diskfs.h
===
--- hurd-0.9.git20181030-4.1.orig/libdiskfs/diskfs.h
+++ hurd-0.9.git20181030-4.1/libdiskfs/diskfs.h
@@ -1,7 +1,7 @@
 /* Definitions for fileserver helper functions
 
-   Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002, 2007, 2008,
-   2009, 2013 Free Software Foundation, Inc.
+   Copyright (C) 1994-1999, 2001, 2002, 2007-2009, 2013-2019
+   Free Software Foundation, Inc.
 
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
@@ -14,8 +14,7 @@
General Public License for more details.
 
You should have received a copy of the GNU General Public License
-   along with this p

Re: GNUstep - check for reuse address

[Svante Signell]

On Sat, 2016-01-09 at 00:37 +0100, Samuel Thibault wrote:
> Svante Signell, on Fri 08 Jan 2016 21:59:56 +0100, wrote:
> > > Yes. And SO_REUSEADDR won't help there :)
> > 
> > Samuel, this is exactly what the SO_REUSEADDR in pflocal should do:
> 
> Except no Unix makes it do that.

Well, it works for GNU/Linux.

> > Unlink the old socket and create a new one with the same name. (I
> > wonder how GNU/Linux is implementing this?)
> 
> It doesn't.

How is it implemented then? I need to find a good testcase for this.

Re: GNUstep - check for reuse address

[Svante Signell]

On Fri, 2016-01-08 at 21:59 +0100, Svante Signell wrote:
> On Fri, 2016-01-08 at 16:43 +0100, Samuel Thibault wrote:
> > Pino Toscano, on Fri 08 Jan 2016 16:40:08 +0100, wrote:
> > > In data venerdì 8 gennaio 2016 13:34:46, Samuel Thibault ha
> > > scritto:
> > > > Svante Signell, on Fri 08 Jan 2016 13:27:49 +0100, wrote:
> > > > > > Depends on how the test is made. SO_REUSEADDR is defined in
> > > > > > bits/socket.h but is not functional (yet).
> > > > > 
> > > > > To clarify; For pflocal. For pfinet it should work.
> > > > 
> > > > Ok.  It seems to be accepted for local sockets on Linux, but it
> > > > doesn't do anything.  I don't see what it would be supposed to mean
> > > > anyway, so gnustep should really not be using that for local sockets.
> > > 
> > > IIRC it should unlink the existing socket path before trying to
> > > bind the unix socket to the specified path -- otherwise you'd get
> > > EADDRINUSE.
> > 
> > Yes. And SO_REUSEADDR won't help there :)
> 
> Samuel, this is exactly what the SO_REUSEADDR in pflocal should do:
> Unlink the old socket and create a new one with the same name. (I
> wonder how GNU/Linux is implementing this?)

This problem is coming up again in the gccgo tests, making some of them fail.
What's wrong with implementing it also for pflocal?

Re: [Bug hurd/24110] SS_DISABLE never set in stack_t value returned by sigaltstack

[Svante Signell]

On Mon, 2019-01-28 at 22:43 +0100, Samuel Thibault wrote:
> Svante Signell, le lun. 28 janv. 2019 21:50:50 +0100, a ecrit:
> > Thread 4 hit Breakpoint 2, __GI___sigaltstack (argss=0x3005c84, oss=0x0) at
> > ../sysdeps/mach/hurd/sigaltstack.c:55
> > 55  in ../sysdeps/mach/hurd/sigaltstack.c
> > (gdb) p *argss
> > $9 = {ss_sp = 0x9501c, ss_size = 45028, ss_flags = 0}
> 
> Uh, so that is really so? Maybe check a backtrace here, to see where
> these odd values come from.

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /part1/DEBs/gcc-9/gcc-9-9-20190120-1.1/build/i686-
gnu/libgo/gotest3957/test/a.out 

Thread 4 hit Hardware watchpoint 3: * (void **) 0x25139ac

Old value = 
New value = (void *) 0x0
0x022a03a1 in __GI__hurd_thread_sigstate (thread=) at
hurdsig.c:96
96  hurdsig.c: No such file or directory.
(gdb) c
Continuing.
[New Thread 4569.24]

Thread 4 hit Breakpoint 2, __GI___sigaltstack (argss=0x0, oss=0x3005cb4) at
../sysdeps/mach/hurd/sigaltstack.c:55
55  ../sysdeps/mach/hurd/sigaltstack.c: No such file or directory.
(gdb) c
Continuing.

Thread 4 hit Hardware watchpoint 3: * (void **) 0x25139ac

Old value = (void *) 0x0
New value = (void *) 0x9501c
0x022d18b8 in __GI___sigaltstack (argss=0x3005c84, oss=0x0) at
../sysdeps/mach/hurd/sigaltstack.c:51
51  in ../sysdeps/mach/hurd/sigaltstack.c
(gdb) p *argss
$11 = {ss_sp = 0x9501c, ss_size = 45028, ss_flags = 0}

(gdb) thread apply all bt full

Thread 5 (Thread 4569.24):
#0  0x022842ac in mach_msg_trap ()
at /part2/DEBs/glibc.test/glibc-2.28/build-tree/hurd-i386-
libc/mach/mach_msg_trap.S:2
No locals.
#1  0x02284a56 in __GI___mach_msg (msg=0x3804f00, option=3, send_size=32,
rcv_size=4096, rcv_name=137, timeout=0, 
notify=0) at msg.c:111
ret = 
#2  0x02285058 in __mach_msg_server_timeout (demux=0x22999f0 ,
max_size=4096, rcv_name=137, option=0, 
timeout=0) at msgserver.c:150
request = 0x3804f00
reply = 0x3805f10
mr = 0
__PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
tmp = 
#3  0x02285144 in __mach_msg_server (demux=0x22999f0 ,
max_size=4096, rcv_name=137) at msgserver.c:195
No locals.
#4  0x02299ade in _hurd_msgport_receive () at msgportdemux.c:67
No locals.
#5  0x024b094f in entry_point (self=, start_routine=, arg=)
at pt-create.c:62
No locals.
#6  0x in ?? ()
No symbol table info available.

Thread 4 (Thread 4569.23):
#0  0x022d18b8 in __GI___sigaltstack (argss=0x3005c84, oss=0x0) at
../sysdeps/mach/hurd/sigaltstack.c:51
s = 0x2513808
ss = {ss_sp = 0x9501c, ss_size = 45028, ss_flags = 0}
old = {ss_sp = 0x0, ss_size = 0, ss_flags = }
#1  0x01520893 in runtime.signalstack (p=0x9501c "", n=45028) at
../../../src/libgo/runtime/runtime_c.c:118
st = {ss_sp = 0x9501c, ss_size = 45028, ss_flags = 0}
#2  0x01995fad in runtime.minitSignalStack () at
../../../src/libgo/go/runtime/signal_unix.go:693
_g_ = 0x2124040 
st = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}
_g_ = 
st = 
#3  runtime.minitSignals () at ../../../src/libgo/go/runtime/signal_unix.go:676
No locals.
#4  runtime.minit () at ../../../src/libgo/go/runtime/os_gccgo.go:28
No locals.
#5  0x0152016e in runtime_mstart (arg=0x2124540 ) at
../../../src/libgo/runtime/proc.c:556
mp = 0x2124540 
gp = 0x2124040 
#6  0x0803b57d in main (argc=, argv=) at
../../../src/libgo/runtime/go-main.c:59
No locals.
#7  0x022ba39d in __libc_start_main (main=0x803b4a0 , argc=1,
argv=0x3005da4, init=0x804a8d0 <__libc_csu_init>, 
fini=0x804a930 <__libc_csu_fini>, rtld_fini=0x10920 <_dl_fini>,
stack_end=0x3005d9c) at ../csu/libc-start.c:339
result = 
#8  0x0803b5b1 in _start ()
No symbol table info available.