Re: Incorrect link on a page

[Samuel Thibault]

Boyuan Yang, le ven. 20 sept. 2024 17:05:05 -0400, a ecrit:
> 在 2024-09-16一的 18:00 -0700，Mikhail Nitenko写道：
> > I was reading through this page
> > "https://www.debian.org/ports/hurd/hurd-cd"; and noticed an incorrect
> > link.
> > 
> > Specifically, in the section "Newer snapshots" it reads: "Some newer
> > snapshots are available on
> > https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/ for i386
> > and https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/ for
> > amd64"
> > 
> > I am pretty sure it should be "Some newer snapshots are available on
> > https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/ for i386
> > and https://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/ for
> > amd64" (changed the second link to point to appropriate architecture)
> 
> Thanks for the report. I have committed the fix at
> https://salsa.debian.org/webmaster-team/webwml/-/commit/38b1ccf880dcaca37d7f9783213ea20cb1dc68b8
>  ,
> and the fix shall be online within several hours.
> 
> (the original line committer and the Debian Hurd team are cc-ed.)

Thanks!

Samuel

Re: Bug#1081953: libgstreamer-plugins-base1.0-dev: gtk4 FTBFS on hurd-i386: fatal error: GLES3/gl3.h: No such file or directory

[Samuel Thibault]

Samuel Thibault, le lun. 16 sept. 2024 17:28:07 +0200, a ecrit:
> Simon McVittie, le lun. 16 sept. 2024 16:20:15 +0100, a ecrit:
> > https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=hurd-i386&ver=4.16.1%2Bds-2&stamp=1726438813&raw=0
> > > Get:209 http://deb.debian.org/debian-ports unreleased/main hurd-i386 
> > > libgstreamer-plugins-base1.0-dev hurd-i386 1.24.4-1+hurd.1 [539 kB]
> > ...
> > > In file included from ../../../modules/media/gtkgstsink.c:53:
> > > /usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:40:13: fatal error: 
> > > GLES3/gl3.h: No such file or directory
> > >40 | #   include 
> > 
> > On Linux, this header is part of libgles-dev, which is a dependency of
> > libgstreamer-plugins-base1.0-dev:
> > 
> > > libgles-dev: /usr/include/GLES3/gl3.h
> 
> It's most probably just because libglvnd is not built in its latest
> version, due to a SIGPIPE issue in 
> 
> 21/37 glvnd:glx / glxmakecurrent_mt   FAIL   0.13s
> 
> I have started a build with nocheck to avoid the issue for now, we'll
> see if that's enough.

Yes, that was it.

Samuel

Re: Bug#1081953: libgstreamer-plugins-base1.0-dev: gtk4 FTBFS on hurd-i386: fatal error: GLES3/gl3.h: No such file or directory

[Samuel Thibault]

Hello,

Simon McVittie, le lun. 16 sept. 2024 16:20:15 +0100, a ecrit:
> https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=hurd-i386&ver=4.16.1%2Bds-2&stamp=1726438813&raw=0
> > Get:209 http://deb.debian.org/debian-ports unreleased/main hurd-i386 
> > libgstreamer-plugins-base1.0-dev hurd-i386 1.24.4-1+hurd.1 [539 kB]
> ...
> > In file included from ../../../modules/media/gtkgstsink.c:53:
> > /usr/include/gstreamer-1.0/gst/gl/gstglfuncs.h:40:13: fatal error: 
> > GLES3/gl3.h: No such file or directory
> >40 | #   include 
> 
> On Linux, this header is part of libgles-dev, which is a dependency of
> libgstreamer-plugins-base1.0-dev:
> 
> > libgles-dev: /usr/include/GLES3/gl3.h

It's most probably just because libglvnd is not built in its latest
version, due to a SIGPIPE issue in 

21/37 glvnd:glx / glxmakecurrent_mt   FAIL   0.13s

I have started a build with nocheck to avoid the issue for now, we'll
see if that's enough.

Samuel

Re: init-d-script support for setpriv

[Samuel Thibault]

Hello,

Mark Hindley, le ven. 06 sept. 2024 14:27:41 +0100, a ecrit:
> I am working on a patch for init-d-script(5) to add an optional setpriv(1)
> wrapper. Obviously that is not available on non-linux and the patch 
> accommodates
> that.  However, I am concerned that non-linux users might find the warning too
> noisy. I would be grateful for your opinion and comments on the attached 
> patch.

That should be fine, thanks for caring!

> For background, I have use for this as part of the unit-translator[1] I am
> working on. I hope it might provide a general solution for the disappearing 
> LSB
> initscripts and cron fragments that we are all subject to in a 
> systemd-dominant
> Debian. The initial version of src:unit-translator with openrc and cron 
> support
> has passed through NEW. I am working on the LSB script backend which uses
> init-d-script.

Great, thanks!

Samuel

Re: Qemu N00b

[Samuel Thibault]

Hello,

Barry deFreese, le dim. 25 août 2024 21:01:32 -0400, a ecrit:
> However, I can't seem to resize the root partition.  Fdisk didn't
> work and I was able to use parted on the image and both the image and
> disk have 10gb but / is still 1Gb so I can't install hardly anything.

http://cdimage.debian.org/cdimage/ports/stable/hurd-i386/README.txt

has some doc to increase the disk image size.

Samuel

Re: 64bit support news

[Samuel Thibault]

Almudena Garcia, le dim. 25 août 2024 22:56:57 +0200, a ecrit:
> I've just found other problem: hurd-console doesn't works

that's why I had to disable it in the debian installer.

> Any solution?

Not that I know of.

Most probably just needs investigation and fixing.

Samuel

Re: 64bit support news

[Samuel Thibault]

Almudena Garcia, le dim. 25 août 2024 21:38:17 +0200, a ecrit:
> I'm testing the image in Qemu, but the installer doesn't boot: when I press
> "text install", the machine simply reboots.
> 
> Have you tested the installer?

Yes, like documented in the README.

Samuel

Re: 64bit support news

[Samuel Thibault]

Samuel Thibault, le dim. 25 août 2024 17:50:51 +0200, a ecrit:
> An amd64 installer cd image is available on
> 
> https://people.debian.org/~sthibault/hurd-amd64/installer/cdimage/daily/

I have also put it on
http://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/current/

where it won't be overwritten by newer daily images.

Samuel

Re: 64bit support news

[Samuel Thibault]

Hello,

An amd64 installer cd image is available on

https://people.debian.org/~sthibault/hurd-amd64/installer/cdimage/daily/

It seems to be working, provided that one has enough memory (2G seems
enough)

Samuel

Re: xattr records not actually working? (Was: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode)

[Samuel Thibault]

Johannes Schauer Marin Rodrigues, le dim. 25 août 2024 11:10:29 +0200, a ecrit:
>  - ran /usr/lib/hurd/setup-translators -k
>  - shut down the machine
>  - mounted the image again (with -t ext4)
>  - ran this: sudo getfattr --dump --match=- /mnt/hurd/*

Not all entries have a translator. Mostly only entries in /dev and
/servers

Samuel

Re: xattr records not actually working? (Was: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode)

[Samuel Thibault]

Samuel Thibault, le sam. 24 août 2024 19:25:54 +0200, a ecrit:
> Johannes Schauer Marin Rodrigues, le sam. 24 août 2024 18:29:52 +0200, a 
> ecrit:
> > Quoting Samuel Thibault (2024-07-19 01:35:45)
> > > Putting a more eye-catching title :)
> > 
> > Thank you, Samuel!
> > 
> > I am still unable to see extended attributes in the translators when 
> > checking
> > this call on Linux:
> > 
> > sudo getfattr --dump --match=- /mnt/hurd/*
> > 
> > Do others observe the same?
> 
> Indeed. Apparently the translators don't get updated on upgrade, so
> you'd have to force it:
> 
> /usr/lib/hurd/setup-translators -k

As discussed on irc: one needs to reboot with an upgraded hurd package
before using setup-translators to update the entries.

And on Linux, one needs to use the ext4fs module, not ext2fs (which
doesn't know about gnu.translators).

Samuel

Re: xattr records not actually working? (Was: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode)

[Samuel Thibault]

Johannes Schauer Marin Rodrigues, le sam. 24 août 2024 18:29:52 +0200, a ecrit:
> Quoting Samuel Thibault (2024-07-19 01:35:45)
> > Putting a more eye-catching title :)
> 
> Thank you, Samuel!
> 
> I am still unable to see extended attributes in the translators when checking
> this call on Linux:
> 
> sudo getfattr --dump --match=- /mnt/hurd/*
> 
> Do others observe the same?

Indeed. Apparently the translators don't get updated on upgrade, so
you'd have to force it:

/usr/lib/hurd/setup-translators -k

Samuel

Bug#1078001: findutils: Please disable 2038 on hurd-i386

[Samuel Thibault]

Package: findutils
Version: 4.10.0-2
Severity: important
Tags: patch

Hello,

With the hurd-amd64 port coming up, we do not plan to introduce a 64bit
time interface to hurd-i386, so could you please apply the attached
patch to disable requiring it until we completely replace hurd-i386 with
hurd-amd64?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.9.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages findutils depends on:
ii  libc62.39-6
ii  libselinux1  3.5-2+b3

findutils recommends no packages.

findutils suggests no packages.

-- no debconf information

-- 
Samuel
 > Subject: pb fvwm95-2 comment l'installer le compiler???
 > Merci d'avance
 je te conseille d'être un peu plus précis dans l'exposé de ton pb...
 -+- EJ in guide du linuxien pervers :"Les modéros sont sympas !" -+-
--- debian/rules.original   2024-08-05 20:08:00.0 +0200
+++ debian/rules2024-08-05 20:08:28.0 +0200
@@ -11,11 +11,15 @@
 export MAKEINFO
 endif
 
+ifeq ($(DEB_HOST_ARCH),hurd-i386)
+  Y2038 = --disable-year2038
+endif
+
 override_dh_auto_configure:
dh_auto_configure --verbose -- \
--localstatedir=/var/cache/locate \
-   --enable-d_type-optimisation
-
+   --enable-d_type-optimisation \
+   $(Y2038)
 
 override_dh_auto_clean:
[ ! -f Makefile ] || dh_auto_clean --verbose

Bug#1078000: coreutils: Please disable 2038 on hurd-i386

[Samuel Thibault]

Package: coreutils
Version: 9.4-3.1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

With the hurd-amd64 port coming up, we do not plan to introduce a 32bit
time interface to hurd-i386, so could you please apply the attached
patch to disable requiring it until we completely replace hurd-i386 with
hurd-amd64?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.9.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.3.2-2
ii  libattr1 1:2.5.2-1
ii  libc62.39-6
ii  libgmp10 2:6.3.0+dfsg-2+b1
ii  libselinux1  3.5-2+b3
ii  libssl3t64   3.2.2-1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

-- 
Samuel
 le y est un animal discret se logeant facilement dans un terminal
*** c has changed the topic on channel #ens-mim to ne pas jeter de cacahuetes 
aux ys, svp
 -+- #ens-mim - n'oubliez pas le guide -+-
--- debian/rules.original   2024-08-05 19:52:05.0 +0200
+++ debian/rules2024-08-05 19:52:40.0 +0200
@@ -13,13 +13,17 @@
   DEB_CFLAGS_MAINT_APPEND += -mieee
 endif
 
+ifeq ($(DEB_HOST_ARCH),hurd-i386)
+  Y2038 = --disable-year2038
+endif
+
 BIN_PROGS = cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir \
mknod mv pwd readlink rm rmdir vdir sleep stty sync touch true uname \
mktemp
 d=debian/coreutils
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-install-program=arch 
--with-openssl=auto-gpl-compat
+   dh_auto_configure -- --enable-install-program=arch 
--with-openssl=auto-gpl-compat $(Y2038)
 
 %:
dh $@ --with autoreconf

Re: 64bit support news

[Samuel Thibault]

Samuel Thibault, le sam. 03 août 2024 00:23:07 +0200, a ecrit:
> Samuel Thibault, le jeu. 01 août 2024 00:14:35 +0200, a ecrit:
> > I have noticed that the ibus package errs out in its testsuite. ibus is
> > a dependency for e.g. libsdl2 and thus a lot of packages, could somebody
> > take a look at its testsuite failures?
> 
> I also notice that jackd2 is failing for some time (on hurd-i386 too),
> we'll need it quite badly, any taker?

libgtop2 will quickly become a blocker, too.

Samuel

Re: 64bit support news

[Samuel Thibault]

bdefre...@verizon.net, le ven. 02 août 2024 22:36:12 +, a ecrit:
> If I can ever get my new key signed I'll try to get on some of this.

If you can provide a patch, I can very easily upload it :)

Samuel

Re: 64bit support news

[Samuel Thibault]

Samuel Thibault, le jeu. 01 août 2024 00:14:35 +0200, a ecrit:
> I have noticed that the ibus package errs out in its testsuite. ibus is
> a dependency for e.g. libsdl2 and thus a lot of packages, could somebody
> take a look at its testsuite failures?

I also notice that jackd2 is failing for some time (on hurd-i386 too),
we'll need it quite badly, any taker?

Samuel

Re: 64bit support news

[Samuel Thibault]

Samuel Thibault, le jeu. 01 août 2024 00:45:36 +0200, a ecrit:
> The main concern is that it looks like swapping doesn't work well with
> rumpdisk, perhaps something like rumpdisk or pci-arbiter not managing
> to wire themselves completely, and thus getting a hang if any part
> gets swapped out. This means I had to disable swap entirely to keep
> the box a bit more stable. But then when building packages that are a
> bit demanding in memory we end up with lack of memory and other stuck
> conditions (the buildd box has only 3G memory). Merely e.g. unpacking
> texlive-latex-extra can lock the box.

That can be seen in the accumulation of packages in "Building" state for
boralus in
https://buildd.debian.org/status/architecture.php?a=hurd-amd64&suite=sid

Samuel

Re: 64bit support news

[Samuel Thibault]

Samuel Thibault, le jeu. 01 août 2024 00:14:35 +0200, a ecrit:
> - packages that don't fail on hurd-i386, probably worth investigating as
> that'll probably reveal some bugs in the hurd-amd64 port.

(sometimes it's just that the package has 64bit-specific code that was
never fixed for the Hurd)

Samuel

Re: 64bit support news

[Samuel Thibault]

Almudena Garcia, le jeu. 01 août 2024 00:55:19 +0200, a ecrit:
> The main concern is that it looks like swapping doesn't work well with
> rumpdisk, perhaps something like rumpdisk or pci-arbiter not managing
> to wire themselves completely, and thus getting a hang if any part
> gets swapped out. This means I had to disable swap entirely to keep
> the box a bit more stable. But then when building packages that are a
> bit demanding in memory we end up with lack of memory and other stuck
> conditions (the buildd box has only 3G memory).
> 
> 
> This problem is not only in 64-bit. It seems to be a rumpdisk generalized
> problem, because in i386 and in smp I had the same issue.

Yes. It's just that on hurd-amd64 we don't have the choice :)

> I want to try to update rumpkernel sources, to add better hardware support in
> rumpdisk, and then we can test if the problem keeps in the new version.

I don't think a newer upstream version would change anything: freebsd
has been working fine for a long time.  Missing proper memory wiring
(e.g. perhaps the contiguous allocator) is a much more probable culprit.

Simplest would probably be to just *observe* what is happening, from the
kernel debugger, to check what rumpdisk is stuck on. Rather that making
all sorts of guesses that can take a much longer time to check.

Samuel

Re: 64bit support news

[Samuel Thibault]

Samuel Thibault, le jeu. 01 août 2024 00:14:35 +0200, a ecrit:
> We are then seeing build failures, see
> https://people.debian.org/~sthibault/hurd-amd64/failed.txt

Ah, I forgot to talk about the general stability of the port.

The main concern is that it looks like swapping doesn't work well with
rumpdisk, perhaps something like rumpdisk or pci-arbiter not managing
to wire themselves completely, and thus getting a hang if any part
gets swapped out. This means I had to disable swap entirely to keep
the box a bit more stable. But then when building packages that are a
bit demanding in memory we end up with lack of memory and other stuck
conditions (the buildd box has only 3G memory). Merely e.g. unpacking
texlive-latex-extra can lock the box. For some packages that we really
want, I built them by hand on a vm on a server that has a lot of memory.

Also, it looks like we are encountering deadlocks in ext2fs/libdiskfs
that we had not seen (most probably only by sheer luck) on i386.

All in all, I have to reboot the buildd box several times a day
(while the i386 buildds can compile packages for several weeks before
encountering hangs).

Samuel

64bit support news

[Samuel Thibault]

Hello,

It's high time to give some updates on the 64bit front.
Things seem to be going quite nicely, there is of course still some work
ahead :)

The shell replacement issue that I was having is mostly understood now
and fixed/worked around ; there are two issues, found by Luca:

- The clobber structure
https://sourceware.org/git/?p=glibc.git;a=blob;f=hurd/intr-msg.c;h=424c1fc700a7c56f346d72eddf2c3e717d8ba28f;hb=HEAD#l42
was not large enough: with the pointer-size alignment on message
filling, restoring error_t was not large enough.

- The save_data structure
https://sourceware.org/git/?p=glibc.git;a=blob;f=hurd/intr-msg.c;h=424c1fc700a7c56f346d72eddf2c3e717d8ba28f;hb=HEAD#l70
happens to get saved in the xmm0 register instead of the stack, and sse
registers are not currently saved/restored by the signal management.  In
Debian I added a volatile qualifier to work around the issue for now,
but saving/restoring sse registers needs to be implemented.

With that fixed/worked around, I was not seeing erroneous configure
executions etc. any more, so I was able to unleash the hurd-amd64 build
daemon, which has been busy building packages for a couple of weeks now,
we have ~2600 installed packages now, and as many in buildable state,
and yet more to come after that by dependency.

I was able to bootstrap rust, which was important to e.g. get
gstreamer1.0 built.  I have not managed to bootstrap ghc yet, it's
currently broken upstream in 9.4, and 9.0 also fails for me.

We are then seeing build failures, see
https://people.debian.org/~sthibault/hurd-amd64/failed.txt
There are various categories:

- packages that don't fail on hurd-i386, probably worth investigating as
that'll probably reveal some bugs in the hurd-amd64 port.

- packages that also fail on hurd-i386, no surprise here.  In some
cases (to unlock other packages by dependency), it can be useful to
investigate which older version was previously not failing on hurd-i386,
and I can build&upload that to the unreleased distribution. I have done
so for some packages already.

- packages that didn't fail on hurd-i386 when it was tried,
but that nowadays do fail on hurd-i386 too.  Unforunately,
notably we currently have a Debian switch to gcc-14, and
implicit-function-declaration-errors, which produces various new
failures to build due to the increased hardening on compiler warnings
(no bogus pointer casting allowed, no implicit function declaration).

- packages that not only fail on hurd-amd64 and hurd-i386, but also
amd64/i386 (quite often gcc-14 & implicit-func issues again). Probably
not worth spending time on this and let other people have a look.

I'm currently having a look at mariadb, which is essential for many
dependencies.

I have noticed that the ibus package errs out in its testsuite. ibus is
a dependency for e.g. libsdl2 and thus a lot of packages, could somebody
take a look at its testsuite failures?

Thanks for the collective work on this!
Samuel

Bug#1077591: gnumach FTBFS with stage1 profile

[Samuel Thibault]

Helmut Grohne, le mar. 30 juil. 2024 10:55:36 +0200, a ecrit:
> I looked into debian/rules and was a bit confused by the inconsistent
> indenting of make-level ifs.

Ouch, indeed, I completely messed up the if (stage1) when refactoring
this. I have now moved the if. I also fixed the -C build-up which was
now erroneous.

That actually points out something I was thinking about while using
build profiles to bootstrap hurd-amd64: we'd probably want to advertise
this:

https://salsa.debian.org/salsa-ci-team/pipeline#testing-build-profiles

Samuel

Bug#1077591: gnumach FTBFS with stage1 profile

[Samuel Thibault]

Hello,

Helmut Grohne, le mar. 30 juil. 2024 10:55:36 +0200, a ecrit:
> Can I defer this problem to you and then resume applying your glibc
> patch once I can actually verify it inside rebootstrap?

Sure!

> Related to that given that you are entitled to commit to Debian's glibc
> packaging, did you also commit your change there? The rebootstrap patch
> policy is that every upstream change must be accompanied with an
> "upstreaming effort reference" (e.g. bug report, upstream commit, ...)
> and the glibc packaging is an upstream to rebootstrap.

The proposed change is part of the changes above, #798955, which most
probably want to be solved altogether.

Samuel

xattr records not actually working? (Was: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode)

[Samuel Thibault]

Hello,

Putting a more eye-catching title :)

Samuel

Johannes Schauer Marin Rodrigues, le lun. 15 juil. 2024 11:38:37 +0200, a ecrit:
> Hi,
> 
> Quoting Johannes Schauer Marin Rodrigues (2024-05-21 11:50:25)
> > In any case, things go much further now. The next problem is some missing
> > DPKG_ROOT support in the hurd maintainer script. I opened a merge request
> > here:
> > 
> > https://salsa.debian.org/hurd-team/hurd/-/merge_requests/1
> 
> thank you for uploading a new version of the hurd package including these
> DPKG_ROOT changes! I just confirmed that these indeed do work as intended and
> it is now possible to create minimal hurd tarballs containing kernel and
> sysvinit using chrootless mode on linux like this:
> 
> mmdebstrap --variant=apt \
>   
> --include=passwd,debian-ports-archive-keyring,mmdebstrap,sysvinit-core,sysv-rc
>  \
>   --customize-hook='chroot "$1" mmdebstrap \
>   --mode=chrootless --arch=hurd-i386 \
>   
> --include=sysvinit-core,sysv-rc,debian-ports-archive-keyring,gnumach-image-1-486
>  \
>   --variant=apt \
>   unstable /tmp/chroot.tar \
>   "deb http://ftp.ports.debian.org/debian-ports/ unstable main" \
>   "deb http://ftp.ports.debian.org/debian-ports/ unreleased 
> main"' \
>   --customize-hook='copy-out /tmp/chroot.tar .'\
>   unstable /dev/null
> 
> We could turn these tarballs into an ext4 file system but that would not be
> very useful yet, because all the translators would be missing from it. I was
> told by Samuel Thibault that since recently, translators are stored in 
> extended
> attributes, namely in the gnu.translator xattr. So it should be possible to
> mimic what settrans does on Hurd on Linux using setxattr(2) or, in shell,
> setfattr(1). Namely, it should be possible to special-case the st() and md()
> functions in /usr/lib/hurd/setup-translators, such that the script can be run
> on Linux.
> 
> To make sure that my settrans replacement on Linux does the right thing, I
> wanted to investigate how the extended attribute values look like on Hurd. For
> that purpose, I downloaded
> https://cdimage.debian.org/cdimage/ports/stable/hurd-i386/debian-hurd-20230608.img
> and also gnumach.gz, exec.static and ext2fs.static from the same location and
> then ran the qemu vm like this:
> 
> qemu-system-i386 -nographic -net user,hostfwd=tcp:127.0.0.1:-:22 -net 
> nic,model=e1000 \
>   -m 1G -kernel gnumach -append 'root=device:hd0s2 console=com0' \
>   --initrd './ext2fs.static 
> --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} 
> --device-master-port=${device-port} --exec-server-task=${exec-task} -T typed 
> ${root} $(task-create) $(task-resume),./exec.static $(exec-task=task-create)' 
> \
>   -drive file=debian-hurd-20230608.img,format=raw
> 
> I put http://ftp.ports.debian.org/debian-ports/ unstable and unreleased main
> into the apt sources.list and upgraded everything to the latest versions. Then
> I turned the machine off, mounted the filesystem of the qemu vm and extracted
> /boot/gnumach-1.8-486-up.gz, /hurd/exec.static and /hurd/ext2fs.static. I
> gunzipped the gnumach kernel and then ran qemu again with the updated files.
> Just to be sure, I ran /usr/lib/hurd/setup-translators -K again and powered 
> off
> the machine. I then mounted the root filesystem and ran this:
> 
> sudo getfattr --dump --match=- /mnt/hurd/*
> 
> Unfortunately this came back empty. Should there not be extended attributes
> attached?
> 
> What could I be missing?
> 
> Thanks!
> 
> cheers, josch

Re: cdimage but no usb image?

[Samuel Thibault]

Hello,

romulasry, le lun. 15 juil. 2024 18:59:12 +, a ecrit:
> I see there is a cd image here: [1]https://people.debian.org/~sthibault/
> hurd-i386/installer/cdimage/daily/ but I don't see a usb image so I try to
> write it to a usb and it works until it tries to load netinstal in the
> installerl and it fails.

I have updated
https://darnassus.sceen.net/~hurd-web/faq/drivers/

USB is only recent support, it's not integrated in the d-i yet.

Samuel

Re: GNU/Hurd support for testing on CI systems

[Samuel Thibault]

Hello,

Guillem Jover, le jeu. 18 juil. 2024 00:04:29 +0200, a ecrit:
> I guess a partial list of places that would be nice to extend
> could be:
> 
>   Salsa: https://salsa.debian.org/salsa-ci-team/pipeline

We have a gitlab runner running on exodar. I'm wondering about the
capacity of the box, though.

Samuel

Re: dpkg 1.22.7 FTBFS and fcntl F_GETLK

[Samuel Thibault]

Guillem Jover, le mer. 17 juil. 2024 23:48:56 +0200, a ecrit:
> so there is no need to file a report about this.

Ok, thanks! :)

Samuel

Re: Maybe helping again?

[Samuel Thibault]

Barry deFreese, le jeu. 11 juil. 2024 22:06:41 -0400, a ecrit:
> Also, is the debian-hurd page up to date with what needs to be done?

It normally is, yes.

Samuel

Re: disabling the internal ide driver

[Samuel Thibault]

Hello,

Maite Gamper, le ven. 12 juil. 2024 00:18:15 +0200, a ecrit:
> Is it possible to disable the internal ide driver and use rumpdisk
> instead on the uniprocessor kernel?

It's the noide kernel parameter.

Samuel

Re: Maybe helping again?

[Samuel Thibault]

Hello,

Barry deFreese wrote:
>   I'm hoping I can try to get involved again

You're very welcome back, nice to see you again! ;)

Samuel

Re: Pseudo-Graphical install not working looking for cd for a netinstall

[Samuel Thibault]

Hello,

romulasry, le ven. 05 juil. 2024 23:51:25 +, a ecrit:
> I am using 
> [1]https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
> As of Fri July 5th
> Also non-graphical install is the same thing

This report is not precise enough to be able to do anything about it.

Samuel

Re: Graphical Interface for install doesn't load up

[Samuel Thibault]

Hello,

romulasry, le jeu. 04 juil. 2024 19:50:16 +, a ecrit:
> I don't know what package this is? Xorg?

Yes.

> The graphical interface doesn't load when I try to do an graphical install.

Better rather debug Xorg with an installed system.

Samuel

Re: Give-back request for globus-net-manager on hurd-i386

[Samuel Thibault]

Mattias Ellert, le mer. 26 juin 2024 14:35:00 +0200, a ecrit:
> Now, after a longer time than I had expected, the Python 3.12 rebuild
> has happened on all architectures except hurd-i386. This architecture
> was left out for some reason.

What did you notice precisely?

I have seen hurd-i386 package rebuilds with python 3.12.

Samuel

Re: Give-back request for globus-net-manager on hurd-i386

[Samuel Thibault]

Hello,

Mattias Ellert, le mer. 26 juin 2024 14:35:00 +0200, a ecrit:
> I'd like to request a give-back of the package on hurd-i386.

Ok, done so, thanks for the notice !

Samuel

Re: nice: cannot set niceness: Permission denied

[Samuel Thibault]

Hello,

Martin-Éric Racine, le lun. 17 juin 2024 10:59:28 +0300, a ecrit:
> One issue I have on Hurd (but not on Linux) is the following error:
> 
> $ sudo LC_ALL=C nice --20 chmod -R u+w /home/perkelix
> nice: cannot set niceness: Permission denied
> 
> Doesn't Hurd support the 'nice' command or what am I missing?

It does.

Running nice through rpctrace shows

task15(pid1373)->task_priority (15 1) = 0x5 ((os/kern) failure)

So that's where investigation is probably useful.

Samuel

Re: Hurd Manual Structure/tooling

[Samuel Thibault]

Hello,

Alexander Ziaee, le mar. 11 juin 2024 11:39:24 +, a ecrit:
> >> Currently, xf86-input-keyboard is used by Hurd as well as BSD, and I'd 
> >> like to make sure that my changes won't cause any regressions for you.
> 
> Here [0] is the merge request for the updated manual.

Thanks for this. I had a quick look at the content, I don't think
anything is hurd-specific actually so that'll be fine :)

Samuel

Re: Hurd Manual Structure/tooling

[Samuel Thibault]

Hello,

Alexander Ziaee, le jeu. 06 juin 2024 01:25:29 +, a ecrit:
> A. Would anyone be willing to share the sections of the Hurd manual? E.g (on 
> BSD). 1: user utilities, 2: syscalls, 3: libraries, 4: kernel interfaces, etc.

The sections are just like the GNU/Linux manual pages. "syscall" is thus
a somehow odd naming but from the application point of view that's fine.

> B. Are you guys using mandoc or groff or something else?

For the hurd documentation we use texinfo.

> Does your stack play nicely with mdoc(7) pages?

I don't know mdoc.

> I'm working on cleaning up manuals and especially apropos results across the 
> FreeBSD stack. Currently, xf86-input-keyboard is used by Hurd as well as us, 
> and I'd like to make sure that my changes won't cause any regressions for you.

Thanks for caring :)

Samuel

Bug#1072337: gst-plugins-good1.0: Missing build-dep for non-linux

[Samuel Thibault]

Source: gst-plugins-good1.0
Version: 1.24.4-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertag: hurd

Hello,

Some dependencies are missing for gst-plugins-good1.0 on non-linux:

https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0&arch=hurd-i386&ver=1.24.4-1&stamp=1717159633&raw=0
../ext/adaptivedemux2/meson.build:104:6: ERROR: Problem encountered: 
adaptivedemux2: Either libsoup2 or libsoup3 is needed

https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-good1.0&arch=hurd-i386&ver=1.24.4-1&stamp=1717233674&raw=0
../ext/qt6/meson.build:64:6: ERROR: Program 'qsb-qt6 qsb' not found or not 
executable

the attached patch fixes them, could you apply it?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.9.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/control.orig 2024-06-01 11:28:00.933813029 +0200
+++ debian/control  2024-06-01 11:30:01.364309857 +0200
@@ -27,6 +27,7 @@
libaa1-dev (>= 1.4p5),
libflac-dev (>= 1.1.4),
libdv4-dev | libdv-dev,
+   libsoup-3.0-dev [!linux-any],
libxdamage-dev,
libxext-dev,
libxfixes-dev,
@@ -51,7 +52,7 @@
qttools5-dev [amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x hurd-i386 powerpc ppc64 sparc64],
qt6-base-private-dev [amd64 arm64 armel armhf mips64el ppc64el 
riscv64 s390x hurd-i386 powerpc ppc64 sparc64],
qt6-declarative-dev [amd64 arm64 armel armhf mips64el ppc64el 
riscv64 s390x hurd-i386 powerpc ppc64 sparc64],
-   qt6-shader-baker [amd64 arm64 armel armhf mips64el ppc64el 
riscv64 s390x powerpc ppc64 sparc64],
+   qt6-shader-baker [amd64 arm64 armel armhf mips64el ppc64el 
riscv64 s390x hurd-i386 powerpc ppc64 sparc64],
qt6-tools-dev [amd64 arm64 armel armhf mips64el ppc64el riscv64 
s390x hurd-i386 powerpc ppc64 sparc64],
qt6-wayland-dev [amd64 arm64 armel armhf mips64el ppc64el 
riscv64 s390x powerpc ppc64 sparc64],
libqt5x11extras5-dev [amd64 arm64 armel armhf i386 mips64el 
ppc64el riscv64 s390x hurd-i386 powerpc ppc64 sparc64],

Bug#1072224: gst-plugins-base1.0: FTBFS on hurd-any

[Samuel Thibault]

Source: gst-plugins-base1.0
Version: 1.24.4-1
Severity: important
Tags: patch ftbfs
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

The attached patch fixes the build of gst-plugins-base1.0 on hurd-any,
could you apply it?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.9.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/rules.original   2024-05-30 17:12:55.0 +
+++ debian/rules2024-05-30 17:32:59.0 +
@@ -33,6 +33,7 @@
 
 ifeq ($(DEB_HOST_ARCH_OS),hurd)
 conf_flags += -Dcdparanoia=disabled
+conf_flags += -Ddrm=disabled
 endif
 
 ifneq ($(DEB_HOST_ARCH_OS),linux)
--- debian/libgstreamer-gl1.0-0.symbols.orig2024-05-30 17:31:05.0 
+
+++ debian/libgstreamer-gl1.0-0.symbols 2024-05-30 17:31:32.0 +
@@ -36,7 +36,7 @@
  (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf@Base 1.14.0
  (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf_direct@Base 1.16.0
  (arch=linux-any kfreebsd-any)gst_egl_image_from_dmabuf_direct_target@Base 
1.18.0
- gst_egl_image_from_dmabuf_direct_target_with_dma_drm@Base 1.23.1
+ (arch=linux-any 
kfreebsd-any)gst_egl_image_from_dmabuf_direct_target_with_dma_drm@Base 1.23.1
  gst_egl_image_from_texture@Base 1.14.0
  gst_egl_image_get_image@Base 1.14.0
  gst_egl_image_get_type@Base 1.14.0

Re: rustc_1.72.1+dfsg1-1+hurd.1_multi.changes ACCEPTED

[Samuel Thibault]

Samuel Thibault, le mer. 29 mai 2024 11:09:28 +0200, a ecrit:
> (will become available in the unreleased archive within 6h)

It's available. The buildds have started building the hundreds of
packages that were waiting.

Samuel

Re: rustc_1.72.1+dfsg1-1+hurd.1_multi.changes ACCEPTED

[Samuel Thibault]

Hello,

It was becoming more and more a concern (gstreamer build-depends on
rustc nowadays). At last, the rustc compiler becomes available :D

Thanks to Vedant's GSoC work last summer, and then waiting for Debian to
catch with upstream releases, eventually we have rustc!

(will become available in the unreleased archive within 6h)

Samuel

Re: migration: ntpdate to rdate

[Samuel Thibault]

Hello,

Martin-Éric Racine, le sam. 25 mai 2024 12:39:20 +0300, a ecrit:
> la 25. toukok. 2024 klo 10.17 Martin-Éric Racine
> (martin-eric.rac...@iki.fi) kirjoitti:
> > I cannot help but notice that the Hurd port still depends on 'ntpdate'
> > to sync its clock upon bootup. The key problem is that Debian has
> > migrated to 'src:ntpsec' which made 'bin:ntpdate' a transitional
> > package. However, 'rdate' seemingly has been ported to Hurd. Assuming
> > that it is verified to work, it could be usefull to migrate the Hurd
> > port to it.
> 
> As far as I can tell, on Hurd i386, using 'rdate' without any option
> does nothing. The command just sits there and wait.
> 
> $ sudo rdate -v pool.ntp.org
> 
> However, if I use the -n option for SNTP, it returns something:
> 
> $ sudo rdate -n -v pool.ntp.org
> Sat May 25 12:35:42 EEST 2024
> rdate: adjust local clock by -0.005979 seconds

According to the package description,

“By default, rdate uses the RFC 868 TCP protocol.”

so it apparently indeed needs to be told to use ntp, when targetting an
ntp server.

> Unless I'm mistaken, this means that Hurd should be able to use a
> wrapper script similar to 'ntpdate-debian' to achieve the same result
> as the old reference 'ntpdate' Hurd has forked.

Indeed.

> It should be fairly trivial to implement and submit to the 'rdate'
> maintainer for inclusion, at which point Hurd's old NTP fork could be
> put to rest.

Help welcome ;)

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Johannes Schauer Marin Rodrigues, le mar. 21 mai 2024 11:50:25 +0200, a ecrit:
> Where I should've looked is:
> 
> http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/p/pam/
> 
> Or I should've looked in the hurd-i386 Packages file instead of checking the
> pool directory. So what I did instead was to build pam with the patches from
> #1029097 on the exodar porter box resulting in this debdiff:
> 
> https://paste.debian.net/hidden/84c2d298/
> 
> Are the sources for pam that got uploaded to unreleased available somewhere?

It's in http://ftp.ports.debian.org/debian-ports/pool-hurd-i386/main/p/pam/

> I only see an empty (40 byte) Sources.gz in
> http://ftp.ports.debian.org/debian-ports/dists/unreleased/main/source/

Yes, that's a missing feature in the mini-dak setup of debian-ports.

> In any case, things go much further now. The next problem is some missing
> DPKG_ROOT support in the hurd maintainer script. I opened a merge request 
> here:
> 
> https://salsa.debian.org/hurd-team/hurd/-/merge_requests/1

Thanks!

> There were no forks and no merge requests on that repo yet so I hope I did
> everything correctly. :D

Congrats for the first MR :)

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Hello,

Johannes Schauer Marin Rodrigues, le mer. 10 avril 2024 12:15:33 +0200, a ecrit:
> It seems that new versions of login, passwd and util-linux require a more
> recent version of pam than was last buildable:
> 
> 
> The following packages have unmet dependencies:
>  login : PreDepends: libpam-runtime but it is not going to be installed
>  PreDepends: libpam-modules but it is not installable
>  passwd : Depends: libpam0g (>= 0.99.7.1) but it is not installable
>   Depends: libpam-modules but it is not installable
>  util-linux : PreDepends: libpam0g (>= 0.99.7.1) but it is not installable
> E: Unable to correct problems, you have held broken packages.

The available version (1.5.3-6+hurd.1) is largely enough for 0.99.7.1, I
don't think it's a question of "newer login, passwd and util-linux".

Note the subtle difference between "is not going to be installed" and
"is not installable". The latter means there is no available version at
all, while libpam-modules=1.5.3-6+hurd.1 is installable, from

deb http://ftp.ports.debian.org/debian-ports/ unreleased main

Samuel

Re: smp i386 kernels

[Samuel Thibault]

Maite Gamper, le dim. 19 mai 2024 16:41:41 +0200, a ecrit:
> But I've noticed that "gnumach-image-1.8-486-smp"
> seems to contain a uniprocessor kernel in sid,  the
> files seem to be identical.

Oops, there must have been some mistake in the build scripts, I'll have
a look.

> I've heard that mach doesn't really support smp, is that still
> correct?

Rumours are never to be taken seriously. Always refer to the reference.

https://darnassus.sceen.net/~hurd-web/faq/smp/

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Hello,

Johannes Schauer Marin Rodrigues, le mer. 10 avril 2024 10:09:02 +0200, a ecrit:
> So I tried the whole thing again and we got a new blocker:
> 
> https://buildd.debian.org/status/package.php?p=fakeroot

I'm not sure why it's a blocker? Is the previous fakeroot version not
enough?

> Do you see an easy way to fix fakeroot on hurd-i386

If it was easy it would be fixed already :)

> or should I just disable fakeroot mode?

Note that there is the fakeroot-hurd alternative which is actually much
more lightweight and much less hacky than fakeroot.

> Or maybe I should switch my tests from hurd-i386 to hurd-amd64?

You'll probably miss a lot of packages on hurd-amd64.

Samuel

smp and pae kernels

[Samuel Thibault]

Hello

In the latest gnumach upload, I have added smp and pae variants of the
kernel. pae should be relatively fine and allow to access more than 3G
memory. smp is completely experimental, and needs fixing here and there,
it seems like irq routing, notably, needs fixes, but at least people can
easily try.

Samuel

Re: ntpdate : Depends: ntpsec-ntpdate but it is not installable

[Samuel Thibault]

Hello,

Jose Luis Alarcon Sanchez, le dim. 24 mars 2024 13:31:22 +0100, a ecrit:
> What's the situation with the package ntpsec-ntpdate?. Is there a fix
> possible?. I volunteer, if i am able. Waiting for instructions to follow.

Fixing the build to at least support the step adjustment should be
relativement easy, yes. The slew adjustment would need adding some
kernel support for implementing adjtimex.

Samuel

Re: Hard Disk size limits on GNU Hurd

[Samuel Thibault]

Hello,

Tanguy LE CARROUR, le ven. 22 mars 2024 13:33:59 +0100, a ecrit:
> Quoting Samuel Thibault (2024-03-22 12:37:33)
> > Jose Luis Alarcon Sanchez, le ven. 22 mars 2024 12:31:04 +0100, a ecrit:
> > > Several years ago there was a limit in the size of the hard disks that 
> > > Hurd
> > > could manage. If i'm not wrong, i think it was 5 Gb. or so.
> > > 
> > > Is still this limit working right now?, or can i create a disk image (for
> > > kvm) with the size i decide (20 Gb. let's say)?.
> > 
> > Please read the faq ;)
> > 
> > https://darnassus.sceen.net/~hurd-web/faq/
> > https://darnassus.sceen.net/~hurd-web/faq/2_gib_partition_limit/
> 
> It was working fine until I ran short of disk space and increased it to
> 20Gb.

Did you really increase the filesystem size as well?

> Now, it randomly crashes with error messages like:
> 
> ```
> ext2fs: BUG: unexpected fault on disk image (10, 0x8ffc000) in
> [0xB8222000,0x18222000) eip 0x8052224 err 0xa
> ```
> 
> or:
> 
> ```
> ext2fs: disk-pager.c:109: fault_handler: Assertion ’err’ failed.
> ```

This looks to me like ENOSPC messages.

Saumel

Re: Hard Disk size limits on GNU Hurd

[Samuel Thibault]

Hello,

Jose Luis Alarcon Sanchez, le ven. 22 mars 2024 12:31:04 +0100, a ecrit:
> Several years ago there was a limit in the size of the hard disks that Hurd
> could manage. If i'm not wrong, i think it was 5 Gb. or so.
> 
> Is still this limit working right now?, or can i create a disk image (for
> kvm) with the size i decide (20 Gb. let's say)?.

Please read the faq ;)

https://darnassus.sceen.net/~hurd-web/faq/

https://darnassus.sceen.net/~hurd-web/faq/2_gib_partition_limit/

Samuel

Re: How connect Translator /hurd/ftpfs with a non anonimous ftp account with user and passwd

[Samuel Thibault]

Jose Luis Alarcon Sanchez, le dim. 17 mars 2024 20:13:13 +0100, a ecrit:
> On Sun, Mar 17, 2024 at 06:48:17PM +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Jose Luis Alarcon Sanchez, le dim. 17 mars 2024 18:34:29 +0100, a ecrit:
> > > The 'test' work exactly as the text say, and i did ls on the GNU FTP, but 
> > > i want to introduce here my
> > > question: Can this be done also with a ftp server that requires an user 
> > > name
> > > and password?. I have my account with user name and password and do well
> > > "traditional ftp". Can i get too have this Transparent FTP that the
> > > marvelous concept of the Translator allows?.
> >
> > See /hurd/ftpfs --help:
> >
> > SERVER can be a hostname, in which case anonymous ftp is used, or may
> > include a user and password like `USER:PASSWORD@HOST' (the `:PASSWORD'
> > part is optional).
> >
> > So in theory you can pass user+password. But that will then show up in
> > ls, so you don't actually want this. Something would need to be added to
> > hostmux and/or ftpfs to support this in a safe way.
> >
> 
> My sequence of commands:
> 
>  $ settrans -c ftp: /hurd/hostmux /hurd/ftpfs /
>  $ ls ftp://myuser:mypas...@servername.net/
> ls: cannot access 'ftp://myuser:mypas...@servername.net/': Translator died

This does work for me:

$ settrans -c ftp: /hurd/hostmux /hurd/ftpfs /
$ ls ftp://anonymous:anonym...@ftp.gnu.org/
CRYPTO.README  find.txt.gznon-gnu  tmp
MISSING-FILES  gnuold-gnu  tree.json.gz
MISSING-FILES.README   gnu+linux-distros  pub  video
README ls-lrRt.txt.gz savannah welcome.msg
before-2003-08-01.md5sums.asc  mirrorsthird-party

>  $ ftp servername.net
> 
> The part 'ftp://' is not needed. Can this be important?

calling ftp already tells you're using the ftp protocol. Above, "ftp://";
is merely to use the ftp:/ directory that you have set up.

Samuel

Re: How connect Translator /hurd/ftpfs with a non anonimous ftp account with user and passwd

[Samuel Thibault]

Alexandre Garreau-Capitanio, le dim. 17 mars 2024 19:29:56 +0100, a ecrit:
> On 17/03/2024 18:48, Samuel Thibault wrote:
> > SERVER can be a hostname, in which case anonymous ftp is used, or may
> > include a user and password like `USER:PASSWORD@HOST' (the `:PASSWORD'
> > part is optional).
> > 
> > So in theory you can pass user+password. But that will then show up in
> > ls, so you don't actually want this. Something would need to be added to
> > hostmux and/or ftpfs to support this in a safe way.
> 
> .authrc(.gpg) support?

If you are setting up an ftpfs mount for yourself, yes. But for
globally-visible mounts, you'd need to put somewhere an .authrc file for
the uid that you used to set the mount.

Samuel

Re: How connect Translator /hurd/ftpfs with a non anonimous ftp account with user and passwd

[Samuel Thibault]

Hello,

Jose Luis Alarcon Sanchez, le dim. 17 mars 2024 18:34:29 +0100, a ecrit:
> The 'test' work exactly as the text say, and i did ls on the GNU FTP, but i 
> want to introduce here my
> question: Can this be done also with a ftp server that requires an user name
> and password?. I have my account with user name and password and do well
> "traditional ftp". Can i get too have this Transparent FTP that the
> marvelous concept of the Translator allows?.

See /hurd/ftpfs --help:

SERVER can be a hostname, in which case anonymous ftp is used, or may
include a user and password like `USER:PASSWORD@HOST' (the `:PASSWORD'
part is optional).

So in theory you can pass user+password. But that will then show up in
ls, so you don't actually want this. Something would need to be added to
hostmux and/or ftpfs to support this in a safe way.

Samuel

Bug#1066932: gcc-14: Please enable m2 on hurd-any

[Samuel Thibault]

Source: gcc-14
Version: 14-20240303-1
Severity: normal
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

Now that upstream has fixed the m2 portability (available in the
20240303 snapshot), could you enable m2 on hurd-any, as the attached
patch does?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/rules.defs b/debian/rules.defs
index 928d4e56..44f3f3a0 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -1195,7 +1195,7 @@ ifneq ($(with_base_only),yes)
   endif
 endif
 m2_no_cpus = loong64 powerpc ppc64 sh4
-m2_no_systems = gnu
+m2_no_systems = 
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus)))
   with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif

Bug#1065456: python3.11: Please don't enable dtrace on hurd

[Samuel Thibault]

Package: python3.11
Version: 3.11.8-1
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

python3.11 currently fails to build on hurd-any because debian/rules
enables dtrace, which is not available on hurd-any.

Could you apply the attached patch that fixes this, on python3.11 as
well as on python3.12?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3.11 depends on:
ii  libpython3.11-stdlib  3.11.8-1
ii  media-types   10.1.0
ii  mime-support  3.66
ii  python3.11-minimal3.11.8-1

Versions of packages python3.11 recommends:
ii  ca-certificates  20240203

Versions of packages python3.11 suggests:
ii  binutils 2.42-3
pn  python3.11-doc   
ii  python3.11-venv  3.11.8-1

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/rules.orig   2024-03-03 10:23:40.0 +0100
+++ debian/rules2024-03-04 23:54:06.808627222 +0100
@@ -441,7 +441,6 @@
--with-computed-gotos \
--without-ensurepip \
--with-system-expat \
-   --with-dtrace \
--with-ssl-default-suites=openssl \
--with-wheel-pkg-dir=/usr/share/python-wheels/ \
--with-ssl-default-suites=openssl \
@@ -453,6 +452,10 @@
   common_configure_args += --with-system-ffi
 endif
 
+ifeq (,$(filter $(DEB_HOST_ARCH_OS), hurd))
+  common_configure_args += --with-dtrace
+endif
+
 ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
   common_configure_args += --host=$(DEB_HOST_GNU_TYPE) 
--build=$(DEB_BUILD_GNU_TYPE)
   common_configure_args += --with-build-python

time_t-related transition coming

[Samuel Thibault]

Hello,

Just to warn: the upload of the t64 packages is about to come into
Debian, that'll be a very big transition, so in the meanwhile the sid
distribution will be essentially uninstallable and non-upgradable.
Please bear with us while the world gets rebuilt ;)

Samuel

Bug#1063643: gcc-14: Fix disabling go and m2 according to OS

[Samuel Thibault]

Source: gcc-14
Version: 14-20240201-3
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

There was a typo in rules.defs concerning go_no_systems and
m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS,
while their content is gnu-system-like (kfreebsd-gnu, gnu), and
indeed all other foo_no_systems variables are compared against
DEB_TARGET_GNU_SYSTEM.

This was making the hurd-i386 build get stuck while building m2, the
attached patch fixes it.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/rules.defs b/debian/rules.defs
index 2810b233..1bb4b96e 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -989,7 +989,7 @@ endif
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_cpus)))
   with_go := disabled for arch $(DEB_TARGET_ARCH)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems)))
   with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes)
@@ -1189,7 +1189,7 @@ n2_no_systems = gnu
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus)))
   with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems)))
   with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)

Bug#1063642: gcc-13: Fix disabling go and m2 according to OS

[Samuel Thibault]

Package: gcc-13
Version: 13.2.0-13
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

There was a typo in rules.defs concerning go_no_systems and
m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS,
while their content is gnu-system-like (kfreebsd-gnu, gnu), and
indeed all other foo_no_systems variables are compared against
DEB_TARGET_GNU_SYSTEM.

This was making the hurd-i386 build get stuck while building m2, the
attached patch fixes it.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13 depends on:
ii  binutils 2.42-2
ii  gcc-13-base  13.2.0-13
ii  gcc-13-x86-64-linux-gnu  13.2.0-13

Versions of packages gcc-13 recommends:
ii  libc6-dev  2.37-15~deb13u1

Versions of packages gcc-13 suggests:
ii  gcc-13-doc   13.2.0-1
pn  gcc-13-locales   
ii  gcc-13-multilib  13.2.0-13

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/rules.defs b/debian/rules.defs
index 8638be92..4fa62c62 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -1019,41 +1019,41 @@ endif
 
 go_no_cpus := arc avr hppa loong64
 go_no_cpus += m68k # See PR 79281 / PR 83314
 go_no_systems := kfreebsd-gnu
 ifneq (,$(filter $(distrelease),precise))
   go_no_cpus  = armhf
   go_no_archs = armhf
 endif
 # Debian #969221
 go_no_cpus  += sh4
 go_no_archs += sh4
 
 ifneq ($(with_base_only),yes)
   ifneq ($(separate_lang),yes)
 with_go := yes
   endif
 endif
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(go_no_cpus)))
   with_go := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems)))
   with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_archs)))
   with_go := disabled for architecture $(DEB_TARGET_ARCH)
 endif
 ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes)
   with_go := disabled for cross compiler package
 endif
 ifeq ($(DEB_STAGE)-$(filter libgo, $(with_rtlibs)),rtlibs-)
   with_go := disabled for rtlibs stage
 endif
 with_go := $(call envfilt, go, , , $(with_go))
 
 # Build all packages needed for Go development
 ifneq (,$(findstring gcc, $(PKGSOURCE)))
   ifeq ($(with_go),yes)
 ifeq ($(with_dev),yes)
   with_godev := yes
 endif
 with_libgo := yes
@@ -1262,41 +1262,41 @@ endif
 with_objcxx := $(call envfilt, obj-c++, , c++ objc, $(with_objcxx))
 
 ifeq ($(with_objcxx),yes)
   enabled_languages += obj-c++
 endif
 
 # Modula-2 ---
 m2_no_cross := yes
 m2_no_cross := no
 
 ifneq ($(with_base_only),yes)
   ifneq ($(separate_lang),yes)
 with_m2 := yes
   endif
 endif
 m2_no_cpus = loong64 powerpc ppc64 sh4
 m2_no_systems = gnu kfreebsd-gnu
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus)))
 with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems)))
   with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)
   with_m2 := disabled for cross compiler package
 endif
 ifeq ($(DEB_STAGE)-$(filter libgm2, $(with_rtlibs)),rtlibs-)
   with_m2 := disabled for rtlibs stage
 endif
 ifneq (,$(filter $(distrelease),precise))
   with_m2 := disabled for $(distrelease) backport
 endif
 #with_m2 := disabled for GCC 13
 
 with_m2 := $(call envfilt, m2, , , $(with_m2))
 
 # Build all packages needed for Modula-2 development
 ifeq ($(with_m2),yes)
   ifeq ($(with_dev),yes)
 with_m2dev := yes
   endif

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 08:12:51 +0100, a ecrit:
> So this is missing entries for /etc/hurd/runsystem.sysv. The hurd.postinst 
> only
> sets up the entry for runsystem.gnu at priority 5. So I looked at the
> initscripts.postinst from sysvinit and that one also calls "uname" :D

Ah, ok, that's it indeed.

> > > If I do that I get:
> > > 
> > > /usr/libexec/runsystem.hurd: 117: Pipe call failed
> > 
> > You are probably also missing /servers/socket/1
> 
> No, I have that. Check here:
> 
> $ curl --silent https://people.debian.org/~josch/hurd.tar.xz | unxz | tar tv 
> | grep /servers/socket/
> drwxr-xr-x root/root 0 2024-02-07 17:12 ./servers/socket/
> -rw-r--r-- root/root 0 2024-02-07 17:12 ./servers/socket/1

Actually, checking runsystem.{hurd,sysv} again, it's the converse: they
configure /servers/socket/1 only if it doesn't exist at all. So images
creators are currently expected to either configure it completely, or
not create it at all.

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 10:04:51 +0100, a ecrit:
> On 2024-02-08 00:13, Samuel Thibault wrote:
> > Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 00:04:25 +0100,
> > a ecrit:
> > > I'm probably missing more customizations to make this work. Where
> > > else other
> > > than in debootstrap should I look? Maybe the Debian installer is doing
> > > something funny? Maybe there is a hurd-specific udeb that does some
> > > setup?
> > 
> > There shouldn't be much more left than the /servers/socket/1 piece.
> 
> Maybe I found the missing bit. In debootstrap, there is:
> 
> in_target /usr/lib/hurd/setup-translators -k

This cannot be done on Linux.

> settrans -a "$TARGET/dev" /hurd/firmlink /dev
> settrans -a "$TARGET/servers" /hurd/firmlink /servers
> settrans -a "$TARGET/proc" /hurd/firmlink /proc

This is only useful when running as chroot (think of it as the bind
mount that you'd do in Linux)

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Johannes Schauer Marin Rodrigues, le jeu. 08 févr. 2024 00:04:25 +0100, a ecrit:
> Quoting Samuel Thibault (2024-02-07 23:32:34)
> > > So I manually created the empty files /servers/exec, /servers/startup and
> > > /dev/console as it is done by debootstrap here:
> > > 
> > > https://sources.debian.org/src/debootstrap/1.0.134/functions/?hl=1304#L1304
> > 
> > That's needed, yes.
> 
> Could/should those be created by a postinst maintainer script of a package in
> the essential set? Maybe by the hurd package?

It used to be set by scripts but we can probably make the hurd postinst
create them, yes. But is the hurd postinst actually run in your case?

> > > /usr/libexec/runsystem.hurd: line 129: /usr/libexec/rc: No such file
> > 
> > Not sure how your system looks like exactly. One issue we have is that
> > the debian-kosher way to run things is not the same as the hurd upstream
> > way to run things. Normally what happens is:
> > 
> > startup/startup.c's `tries' array starts with LIBEXECDIR "/runsystem",
> > i.e. /usr/libexec/runsystem, which symlinks to /etc/hurd/runsystem,
> > which symlinks to /etc/alternatives/runsystem, which symlinks to
> > /etc/hurd/runsystem.sysv, which doesn't look at /usr/libexec/rc at all.
> > All of this is supposed to be shipped by the hurd package, either from
> > the tarball or as an alternative, not sure why (I guess) your alternative is
> > not being set?
> 
> The symlink chain is this one:
> 
> /usr/libexec/runsystem -> /etc/hurd/runsystem -> /alternatives/runsystem -> 
> /etc/hurd/runsystem.gnu
> 
> Should that last one be linking to /etc/hurd/runsystem.sysv?

Yes, I don't see why it's not doing that, isn't the alternative like
this?

  SelectionPath  Priority   Status

* 0/etc/hurd/runsystem.sysv   10auto mode
  1/etc/hurd/runsystem.gnu5 manual mode
  2/etc/hurd/runsystem.sysv   10manual mode

> If I do that I get:
> 
> /usr/libexec/runsystem.hurd: 117: Pipe call failed

You are probably also missing /servers/socket/1

> My final goal is to have debvm-run (which is just a wrapper around mmdebstrap)
> create a disk image that can be run with debvm-run (which is just a wrapper
> around qemu). I think it would be really cool if in Hurd-related bug reports
> one could just say "to reproduce this hurd problem locally, just run this".

Yes, clearly (though we have already been providing hurd qemu images for
a long time without that many people actually using the recommended
qemu-based way to start them...)

> I'm probably missing more customizations to make this work. Where else other
> than in debootstrap should I look? Maybe the Debian installer is doing
> something funny? Maybe there is a hurd-specific udeb that does some setup?

There shouldn't be much more left than the /servers/socket/1 piece.

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Hello,

Johannes Schauer Marin Rodrigues, le mer. 07 févr. 2024 18:07:21 +0100, a ecrit:
> if [ "$(uname -s)" = "Linux" ]; then
>   update-alternatives --install /usr/bin/pager pager /bin/more 50 \
>   --slave /usr/share/man/man1/pager.1.gz pager.1.gz \
>   /usr/share/man/man1/more.1.gz
> fi
> 
> And in unshare mode, uname -s prints "Linux" because I'm running this on 
> linux.
> Do you happen to know what this conditional is for on non-linux systems?

util-linux doesn't seem to ship /bin/more on non-linux.  Upstream indeed
added UL_REQUIRES_LINUX([more]) since the addition of using signalfd,
which is Linuxish.

> So I hacked around that by replacing /bin/uname with a shell script that 
> prints
> something that is not "Linux". And then it works! I'm now stuck elsewhere. 
> When
> putting everything into a disk image and attempting to boot it, I get the
> problem that was discussed here:
> 
> https://lists.debian.org/debian-hurd/2007/09/msg00073.html
> 
> So I manually created the empty files /servers/exec, /servers/startup and
> /dev/console as it is done by debootstrap here:
> 
> https://sources.debian.org/src/debootstrap/1.0.134/functions/?hl=1304#L1304

That's needed, yes.

> The next error I'm getting is:
> 
> /usr/libexec/console-run: /dev/console: Not a terminal

That one is just a warning.

> /usr/libexec/runsystem.hurd: line 129: /usr/libexec/rc: No such file

Not sure how your system looks like exactly. One issue we have is that
the debian-kosher way to run things is not the same as the hurd upstream
way to run things. Normally what happens is:

startup/startup.c's `tries' array starts with LIBEXECDIR "/runsystem",
i.e. /usr/libexec/runsystem, which symlinks to /etc/hurd/runsystem,
which symlinks to /etc/alternatives/runsystem, which symlinks to
/etc/hurd/runsystem.sysv, which doesn't look at /usr/libexec/rc at all.
All of this is supposed to be shipped by the hurd package, either from
the tarball or as an alternative, not sure why (I guess) your
alternative is not being set?

Samuel

Re: hurd-amd64 is missing from wanna-build graphs

[Samuel Thibault]

Amos Jeffries, le jeu. 01 févr. 2024 20:46:27 +1300, a ecrit:
> On 1/02/24 11:07, Samuel Thibault wrote:
> > marius, le mer. 31 janv. 2024 19:05:07 +, a ecrit:
> > > I noticed that hurd-amd64 is mssing from wanna-build graphs, is this 
> > > something that we want? If so i can propose a patch to the wb team
> > 
> > Since the hurd-amd64 buildd is not unleashed yet, it won't be useful
> > anyway :) better wait for the buildd to actually have started, rather
> > than getting bad press because nothing seems to be happening.
> 
> On that topic, how are things going with the buildd?
>  Is there a TODO list we can track and try to assist with?

This is just waiting for fixing the shell output pipe replacement
issue:

https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00062.html

Samuel

Re: hurd-amd64 is missing from wanna-build graphs

[Samuel Thibault]

Hello,

marius, le mer. 31 janv. 2024 19:05:07 +, a ecrit:
> I noticed that hurd-amd64 is mssing from wanna-build graphs, is this 
> something that we want? If so i can propose a patch to the wb team

Since the hurd-amd64 buildd is not unleashed yet, it won't be useful
anyway :) better wait for the buildd to actually have started, rather
than getting bad press because nothing seems to be happening.

Samuel

Re: Give-back request davix 0.8.5-1+b1 gnu-hurd

[Samuel Thibault]

Hello,

Mattias Ellert, le lun. 29 janv. 2024 08:53:44 +0100, a ecrit:
> The build of davix 0.8.5-1+b1 failed on hurd-i386 due to bug 1061610,
> which is a bug in debhelper 13.12. Could you retry the build with
> debhelper 13.13?
> 
> https://buildd.debian.org/status/package.php?p=davix
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061610

Done so, thanks for the notice!

Samuel

Re: dhcpcd: FTBFS on Hurd

[Samuel Thibault]

Joshua Branson, le mer. 17 janv. 2024 12:09:30 -0500, a ecrit:
> Also may I ask why Debian is switching to dhcpcd?  Just curious.

Because ISC is not maintaining its dhcp software any more.

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Hello,

Johannes Schauer Marin Rodrigues, le jeu. 11 janv. 2024 00:12:09 +0100, a ecrit:
> The util-linux problem is no surprise because less fails to install when
> investigating that issue I noticed the version of less is 487 which is the
> version from old-old-stable. Is that plausible?

It has been failing to build for a long time already and is still
waiting for somebody to contribute a fix, see
https://buildd.debian.org/status/logs.php?pkg=less&arch=hurd-i386

Samuel

Re: 64bit startup

[Samuel Thibault]

Luca, le sam. 06 janv. 2024 00:42:35 +0100, a ecrit:
> Il 05/01/24 19:12, Sergey Bugaev ha scritto:
> > /servers/crash-dump-core crashes on the memset () call in
> > hurd:exec/elfcore.c:fetch_thread_fpregset (); the (*fpregs) pointer is
> > NULL. The caller passes fpregs = ¬e.data.pr_fpreg, where note.data
> > is of type struct elf_lwpstatus, defined in hurd:include/sys/procfs.h,
> > whose pr_fpreg field is of type prfpregset_t, which is a typedef to
> > fpregset_t, which was an actual struct on i386, but is a pointer on
> > x86_64. This would've been easier to debug if I had debuginfo :)
> 
> I had this small patch applied that apparently is enough for me to have some
> kind of core dump, I'm not sure if it's a good solution:

You probably rather want to fix fetch_thread_fpregset, so as to properly
put the floating state into pr_fpreg.

This probably needs to actually copy over explicit fields, but that's
what we need anyway.

> diff --git a/exec/elfcore.c b/exec/elfcore.c
> index c6aa2bc8b..405fa8e0c 100644
> --- a/exec/elfcore.c
> +++ b/exec/elfcore.c
> @@ -544,6 +544,11 @@ dump_core (task_t task, file_t file, off_t corelimit,
>note.data.pr_info.si_code = sigcode;
>note.data.pr_info.si_errno = sigerror;
> 
> +#ifdef __x86_64__
> +  struct _libc_fpstate fpstate;
> +  memset(&fpstate, 0, sizeof(fpstate));
> +  note.data.pr_fpreg = &fpstate;
> +#endif
>fetch_thread_regset (threads[i], ¬e.data.pr_reg);
>fetch_thread_fpregset (threads[i], ¬e.data.pr_fpreg);
> 
> 
> HTH
> Luca

Re: 64bit startup

[Samuel Thibault]

Sergey Bugaev, le ven. 05 janv. 2024 21:12:48 +0300, a ecrit:
> Also I can't help but notice that the hurd package (i.e the translator
> binaries) is still not being built as PIE,

This is not actually specific to 64bit. This was set explicitly in 2016
in debian/rules, tests welcome to check whether building the package
without it works now.

Samuel

Re: 64bit startup

[Samuel Thibault]

Sergey Bugaev, le ven. 05 janv. 2024 21:12:48 +0300, a ecrit:
> I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo.

Yes, my repo is built from the rebootstrap scripts, which drop debug
etc. only for creating a booting system.

For proper packages, use the usual deb.debian.org debian-ports mirror.

Samuel

Re: 64bit startup

[Samuel Thibault]

Samuel Thibault, le jeu. 04 janv. 2024 08:57:51 +0100, a ecrit:
> Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit:
> > perhaps I need to try two of them in parallel and some I/O-heavy
> > workload in the background, as you're saying.
> 
> Yes, that's needed to raise the probability of the bug.
> 
> > Could it be that the two strings are actually different (something
> > being wrong with pipes perhaps)?
> 
> I tried
> 
> A=a ; time while /usr/bin/\[ "$A" = a ] ; do A="$(echo -n `echo a` )" ; done 
> ; echo $A
> 
> The output is empty. But yes, that could be some missing flush or such
> in pipes.

It happens with dash too.

Samuel

Re: 64bit startup

[Samuel Thibault]

Sergey Bugaev, le ven. 05 janv. 2024 12:06:13 +0300, a ecrit:
> > I use
> >
> > while true ; do apt install --reinstall wdiff ; done
> 
> That did it! I can now reliably reproduce this.
> 
> (I assume you don't mind my box constantly banging on your repo.)

It's people.debian.org, it's meant for this :)

You can probably also pass to apt an option to keep the donwloaded .deb

> > got acd :)
> 
> In the six times that I've reproduced it so far, I got "acd" in all cases. 
> Hmmm.

"interesting" :)

Samuel

Re: 64bit startup

[Samuel Thibault]

Hello,

Sergey Bugaev, le jeu. 04 janv. 2024 22:21:11 +0300, a ecrit:
> On Thu, Jan 4, 2024 at 10:57 AM Samuel Thibault  
> wrote:
> > Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit:
> > > perhaps I need to try two of them in parallel and some I/O-heavy
> > > workload in the background, as you're saying.
> >
> > Yes, that's needed to raise the probability of the bug.
> 
> I'm still unable to reproduce this, it's been running for 10+ hours at
> this point. That's two copies of it, and unrelated activity in the
> background.

Which kind of activity? I use 

while true ; do apt install --reinstall wdiff ; done

> > > Could it be that the two strings are actually different (something
> > > being wrong with pipes perhaps)?
> >
> > I tried
> >
> > A=a ; time while /usr/bin/\[ "$A" = a ] ; do A="$(echo -n `echo a` )" ; 
> > done ; echo $A
> >
> > The output is empty. But yes, that could be some missing flush or such
> > in pipes.
> 
> Try
> 
> A=abcd ; time while /usr/bin/\[ "$A" = abcd ] ; do A="$(echo -n `echo
> a``echo b`)$(echo -n `echo c``echo d`)" ; done ; echo $A
> 
> perhaps?

got acd :)

I'll be testing with dash over the next hours.

Samuel

Re: Bug#1059986: dpkg: Please add hurd-arm64 case

[Samuel Thibault]

Hello,

Guillem Jover, le jeu. 04 janv. 2024 20:23:02 +0100, a ecrit:
> but even though I've seen already some toolchain patches flying by,
> AFAIUI there's still no GNU Mach support, so I think I'd prefer to
> wait until that materializes,

Ok.

> as per the FAQ entry on new ports. I don't think this would block
> anything right now anyway, no?

I've hacked by chroot to add the arch to be able to build packages
already ;)

I was mostly anticipating this piece of the port which is needed for
proper set up of most of the rest :)

Samuel

Bug#1059986: dpkg: Please add hurd-arm64 case

[Samuel Thibault]

Package: dpkg
Version: 1.22.2
Severity: normal
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

aarch64-gnu support is coming too :)

Could you add a hurd-amd64 case in dpkg?

Thanks,
Samuel

-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.6.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.37-13
ii  liblzma5 5.4.5-0.1
ii  libmd0   1.1.0-1
ii  libselinux1  3.5-1+b1
ii  libzstd1 1.5.5+dfsg2-2
ii  tar  1.34+dfsg-1.3
ii  zlib1g   1:1.3.dfsg-3

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.7.6
pn  debsig-verify  

-- Configuration Files:
/etc/logrotate.d/dpkg changed [not included]

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: 64bit startup

[Samuel Thibault]

Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit:
> perhaps I need to try two of them in parallel and some I/O-heavy
> workload in the background, as you're saying.

Yes, that's needed to raise the probability of the bug.

> Could it be that the two strings are actually different (something
> being wrong with pipes perhaps)?

I tried

A=a ; time while /usr/bin/\[ "$A" = a ] ; do A="$(echo -n `echo a` )" ; done ; 
echo $A

The output is empty. But yes, that could be some missing flush or such
in pipes.

Samuel

Re: 64bit startup

[Samuel Thibault]

Luca, le mer. 03 janv. 2024 20:07:00 +0100, a ecrit:
> Il 03/01/24 09:17, Sergey Bugaev ha scritto:
> > How are you running it? Should I still be using a ramdisk image and
> > not rumpdisk?
> 
> Recently I've been installing hurd-amd64 on another disk of my hurd-i386 vm
> and booting from that. Basically I prepare the disk with debootstrap
> --foreign, then I reuse the i386 grub install to boot the 64 bit kernel with
> a custom entry, then run the --second stage, configure login, fstab and
> network and reboot. I can give you the exact commands and setup I'm using if
> you want (I need to reinstall it anyway due to latest changes),

It could be useful to merge information into the wiki page.

Samuel

Re: 64bit startup

[Samuel Thibault]

Sergey Bugaev, le mer. 03 janv. 2024 11:17:53 +0300, a ecrit:
> I guess this is where I ask (consistent with the subject line) about
> how I would run the x86_64 system (to reproduce & debug this).

You probably want to start with the pre-built images I have linked from
the wiki page.

> I've tried debootstrapping from
> https://people.debian.org/~sthibault/tmp/hurd-amd64 as the wiki page
> says; but that doesn't proceed beyond the rumpdisk. Rumpdisk just sits
> there, slowly spitting out logs;

Does it detect disks? What qemu parameters are you using?

I'm using a mere 

kvm -M q35 -drive file=disk-amd64.img -m 1

Samuel

Re: 64bit startup

[Samuel Thibault]

Hello,

I'm still stuck without being able to start packages building for
hurd-amd64 due to this unreliability.

Sergey Bugaev, le mar. 31 oct. 2023 10:09:17 +0300, a ecrit:
> On Mon, Oct 30, 2023 at 1:27 AM Samuel Thibault  
> wrote:
> > time while [  "$(echo -n `echo a` )" = a ] ; do : ; done
> >
> > by running two of them in parallel, along with an apt install loop in
> > parallel. It takes a few hours to reproduce (sometimes 1, sometimes
> > 3...)
> 
> This could be [0], considering [ is a Bash built-in and not /bin/[, so
> it's Bash that both compares strings and receives SIGCHLDs.
> 
> [0]: https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00105.html

I tried

time while /usr/bin/\[ "$(echo -n `echo a` )" = a ] ; do : ; done

with the same result.

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Hello,

Johannes Schauer Marin Rodrigues, le sam. 25 nov. 2023 00:17:35 +0100, a ecrit:
> Quoting Matthias Geiger (2023-11-24 23:56:11)
> > I see. I was merely wondering if there was an easy way to test hurd builds
> > locally without having to run a VM,
> 
> If you want to compile software, then ideally, no binaries of the host
> architecture (the architecture you are building for) are being run. So if you
> just want to build hurd software (and not run it) then all you need is "just" 
> a
> cross compiler for hurd (should be named gcc-i686-gnu) but I'm not aware of
> that being worked on right now?

Indeed. The rebootstrap scripts build one, though.

Samuel

Re: Patch series to avoid message resizing for x86_64 (v2)

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 17 déc. 2023 23:53:56 +0100, a ecrit:
> Flavio Cruz, le jeu. 14 déc. 2023 01:02:27 -0500, a ecrit:
> > Sending the updated patch series with the warnings fixed. The only
> > difference is in the glibc patch (added a cast when calling
> > clean_inlined_ports) and the MiG patch, which required a 3 line change
> > to add appropriate casts from mach_port_name_inlined_t* to mach_port_t*
> > in server.c.
> 
> Thanks for the update!
> 
> I confirm it now builds fine with -Werror, I have pushed the whole
> series.

I have uploaded the updated hurd-amd64 packages.
Since this is a completely incompatible change, people will probably
want to just re-generate their hurd-amd64 system if they already have
one. If you really don't want to re-generate, you can mount your
hurd-amd64 filesystem into another OS, and run:

cd path/to/hurd-amd64
for i in ~/hurd*_hurd-amd64.deb ~/libc*3.28*_hurd-amd64.deb ; do
  ar p $i data.tar.xz | tar xJh
done

tar's h option is very important, to avoid overwriting the lib, bin and
sbin symlinks.

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Wojciech (Voitek) Aniszewski, le jeu. 07 déc. 2023 14:23:35 +0100, a ecrit:
> wojciech@saiph:~$ showtrans /servers/shutdown
> /hurd/shutdown
> wojciech@saiph:~$ showtrans /servers/acpi
> /hurd/acpi
> wojciech@saiph:~$ showtrans ls /servers/acpi/tables
> APIC   BOOT  FACP  MCFG  SSDT  SSDT  SSDT  TCPA
> 'ASF!' ECDT  HPET  SLIC  SSDT  SSDT  SSDT
> 
> dunno what I'm looking at unfortunately,

To tell the real truth, I don't know what these tables are either.

> docs needed.

ACPI is documented, that's completely independent from the Hurd.

That being said, start from the start: the shutdown trigger is performed
by the shutdown translator, in shutdown/shutdown.c, which calls into the
acpi translator. Then it's a matter of following the function calls, put
mach_print() calls along the way, and check what is actually happening.

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Martin-Éric Racine, le jeu. 07 déc. 2023 11:31:44 +0200, a ecrit:
> On Thu, Dec 7, 2023 at 11:26 AM Samuel Thibault  wrote:
> >
> > Martin-Éric Racine, le jeu. 07 déc. 2023 08:16:34 +0200, a ecrit:
> > > On Thu, Dec 7, 2023 at 2:13 AM Samuel Thibault  
> > > wrote:
> > > > Martin-Éric Racine, le mar. 05 déc. 2023 10:48:57 +0200, a ecrit:
> > > > > On Mon, Dec 4, 2023 at 1:48 PM Samuel Thibault  
> > > > > wrote:
> > > > > > Martin-Éric Racine, le lun. 04 déc. 2023 12:16:59 +0200, a ecrit:
> > > > > > > ACPI support. I noticed during bootup that an ACPI server is 
> > > > > > > launched,
> > > > > > > but issuing "exec sudo poweroff" merely halts the system; it 
> > > > > > > doesn't
> > > > > > > send an ACPI poweroff at the end of the shutdown process.
> > > > > > >
> > > > > > > Is there any way to enable this or is ACPI poweroff merely not
> > > > > > > supported by Hurd?
> > > > > >
> > > > > > It *is* supported and works for me. There is nothing particular to 
> > > > > > do to
> > > > > > get it.
> > > > > >
> > > > > > Is the acpi translator perhaps dying at some point?
> > > > > >
> > > > > > Are you running hurd-i386 or hurd-amd64?
> > > > >
> > > > > As far as I can tell, pci-arbiter succesfully launches acpi on bootup
> > > > > and terminates it during shutdown.
> > > >
> > > > Just to make sure, does
> > > >
> > > > showtrans /servers/shutdown
> > > >
> > > > tell you /hurd/shutdown? and
> > > >
> > > > showtrans /servers/acpi
> > > >
> > > > tell you /hurd/acpi? and /servers/acpi/tables/ contains some tables?
> > >
> > > [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ showtrans /servers/shutdown
> > > /hurd/shutdown
> > > [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ showtrans /servers/acpi
> > > /hurd/acpi
> > > [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ ls /servers/acpi/tables/
> > > APIC  FACP  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT
> > > [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$
> >
> > Ok, then I don't any immediate idea, this needs investigation on your
> > system.
> 
> Possibly.  The thing is, given how Hurd remains a sketchily documented
> OS,

?? There are plenty of wiki pages, and the whole source code is just
there to be looked at. The shutdown translator is 160 lines long and
will tell you which RPC it's trying to do to shut down the machine. From
there you have everything.

Read the source, Luke.

This was said to people 20-30 years ago when the free software movement
deployed, this is just exactly the same now, for exactly the same
reasons.

> I wouldn't remotely know where to look or using what tools.

mach_print("foobar\n"); is a very powerful tool, for a start, to know
what is actually happening.

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Martin-Éric Racine, le jeu. 07 déc. 2023 08:16:34 +0200, a ecrit:
> On Thu, Dec 7, 2023 at 2:13 AM Samuel Thibault  wrote:
> > Martin-Éric Racine, le mar. 05 déc. 2023 10:48:57 +0200, a ecrit:
> > > On Mon, Dec 4, 2023 at 1:48 PM Samuel Thibault  
> > > wrote:
> > > > Martin-Éric Racine, le lun. 04 déc. 2023 12:16:59 +0200, a ecrit:
> > > > > ACPI support. I noticed during bootup that an ACPI server is launched,
> > > > > but issuing "exec sudo poweroff" merely halts the system; it doesn't
> > > > > send an ACPI poweroff at the end of the shutdown process.
> > > > >
> > > > > Is there any way to enable this or is ACPI poweroff merely not
> > > > > supported by Hurd?
> > > >
> > > > It *is* supported and works for me. There is nothing particular to do to
> > > > get it.
> > > >
> > > > Is the acpi translator perhaps dying at some point?
> > > >
> > > > Are you running hurd-i386 or hurd-amd64?
> > >
> > > As far as I can tell, pci-arbiter succesfully launches acpi on bootup
> > > and terminates it during shutdown.
> >
> > Just to make sure, does
> >
> > showtrans /servers/shutdown
> >
> > tell you /hurd/shutdown? and
> >
> > showtrans /servers/acpi
> >
> > tell you /hurd/acpi? and /servers/acpi/tables/ contains some tables?
> 
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ showtrans /servers/shutdown
> /hurd/shutdown
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ showtrans /servers/acpi
> /hurd/acpi
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$ ls /servers/acpi/tables/
> APIC  FACP  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT  SSDT
> [2023-12-07 08:14](HURD i386)perkelix@pxeth:~$

Ok, then I don't any immediate idea, this needs investigation on your
system.

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Martin-Éric Racine, le mar. 05 déc. 2023 10:48:57 +0200, a ecrit:
> On Mon, Dec 4, 2023 at 1:48 PM Samuel Thibault  wrote:
> > Martin-Éric Racine, le lun. 04 déc. 2023 12:16:59 +0200, a ecrit:
> > > ACPI support. I noticed during bootup that an ACPI server is launched,
> > > but issuing "exec sudo poweroff" merely halts the system; it doesn't
> > > send an ACPI poweroff at the end of the shutdown process.
> > >
> > > Is there any way to enable this or is ACPI poweroff merely not
> > > supported by Hurd?
> >
> > It *is* supported and works for me. There is nothing particular to do to
> > get it.
> >
> > Is the acpi translator perhaps dying at some point?
> >
> > Are you running hurd-i386 or hurd-amd64?
> 
> As far as I can tell, pci-arbiter succesfully launches acpi on bootup
> and terminates it during shutdown.

Just to make sure, does

showtrans /servers/shutdown

tell you /hurd/shutdown? and

showtrans /servers/acpi

tell you /hurd/acpi? and /servers/acpi/tables/ contains some tables?

Samuel

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

[Samuel Thibault]

Hello,

Thorsten Glaser, le mer. 06 déc. 2023 12:16:27 +0100, a ecrit:
> On Wed, 6 Dec 2023, Chris Hofstaedtler wrote:
> >I have zero knowledge about hurd, but it looks like[1] hwclock is built
> >with CMOS support on hurd.  So maybe it could work?
> 
> Maybe it just needs a different config?
> 
> >Given this I'd imagine nobody has ever used the hwclock initscripts
> >on hurd before, and maybe they shouldn't exist there? I'd hope hurd
> >wouldn't rely on userspace to do direct hardware access to set the
> >time.
> 
> AIUI Hurd is a microkernel so everything is done in userspace?

Yes, we'd rather set a translator on /dev/rtc, that does the ISA access
for everybody, instead of hwclock doing it (and possibly stepping on top
of another hwclock call). Contribution welcome ;)

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Martin-Éric Racine, le lun. 04 déc. 2023 14:30:55 +0200, a ecrit:
> On Mon, Dec 4, 2023 at 2:14 PM Samuel Thibault  wrote:
> >
> > Martin-Éric Racine, le lun. 04 déc. 2023 14:08:05 +0200, a ecrit:
> > > > Martin-Éric Racine, le lun. 04 déc. 2023 12:16:59 +0200, a ecrit:
> > > > > ACPI support. I noticed during bootup that an ACPI server is launched,
> > > > > but issuing "exec sudo poweroff" merely halts the system; it doesn't
> > > > > send an ACPI poweroff at the end of the shutdown process.
> > > > >
> > > > > Is there any way to enable this or is ACPI poweroff merely not
> > > > > supported by Hurd?
> > > >
> > > > It *is* supported and works for me. There is nothing particular to do to
> > > > get it.
> > >
> > > Interesting.
> > >
> > > > Is the acpi translator perhaps dying at some point?
> > >
> > > What keyword am I supposed to grep in syslog?
> >
> > syslog probably doesn't notice that. But that probably shows up on the
> > mach console.
> 
> Speaking of which: bug #1057397.

(inetutils-syslogd should be working fine)

Re: poweroff support on Hurd?

[Samuel Thibault]

Martin-Éric Racine, le lun. 04 déc. 2023 14:44:54 +0200, a ecrit:
> On Mon, Dec 4, 2023 at 2:40 PM Samuel Thibault  wrote:
> > Martin-Éric Racine, le lun. 04 déc. 2023 14:30:55 +0200, a ecrit:
> > > As for the console, it doesn't show much since it's too busy clearing
> > > the screen while changing the font
> >
> > You can disable the hurd console in /etc/defaults/hurd-console.
> 
> Which then prevents loading the correct keyboard map.

Alternatively, you can put the gnumach console on the com0 serial port.

> > > Speaking of the console, logging in via that doesn't set LANG or
> > > LANGUAGE, unless I missed something?
> >
> > It does set it according to your Debian configuration.
> 
> Nope. /etc/default/locale is correct, but 'locale' shows LANG and
> LANGUAGE unset, while everything else in LC_* has POSIX.

Ok, it does work through ssh but not on the Hurd console (and not via
inetutils-telnetd either). Contribution welcome to fix it.

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Martin-Éric Racine, le lun. 04 déc. 2023 14:30:55 +0200, a ecrit:
> As for the console, it doesn't show much since it's too busy clearing
> the screen while changing the font

You can disable the hurd console in /etc/defaults/hurd-console.

> Speaking of the console, logging in via that doesn't set LANG or
> LANGUAGE, unless I missed something?

It does set it according to your Debian configuration.

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Martin-Éric Racine, le lun. 04 déc. 2023 14:08:05 +0200, a ecrit:
> > Martin-Éric Racine, le lun. 04 déc. 2023 12:16:59 +0200, a ecrit:
> > > ACPI support. I noticed during bootup that an ACPI server is launched,
> > > but issuing "exec sudo poweroff" merely halts the system; it doesn't
> > > send an ACPI poweroff at the end of the shutdown process.
> > >
> > > Is there any way to enable this or is ACPI poweroff merely not
> > > supported by Hurd?
> >
> > It *is* supported and works for me. There is nothing particular to do to
> > get it.
> 
> Interesting.
> 
> > Is the acpi translator perhaps dying at some point?
> 
> What keyword am I supposed to grep in syslog?

syslog probably doesn't notice that. But that probably shows up on the
mach console.

Samuel

Re: poweroff support on Hurd?

[Samuel Thibault]

Hello,

Martin-Éric Racine, le lun. 04 déc. 2023 12:16:59 +0200, a ecrit:
> ACPI support. I noticed during bootup that an ACPI server is launched,
> but issuing "exec sudo poweroff" merely halts the system; it doesn't
> send an ACPI poweroff at the end of the shutdown process.
> 
> Is there any way to enable this or is ACPI poweroff merely not
> supported by Hurd?

It *is* supported and works for me. There is nothing particular to do to
get it.

Is the acpi translator perhaps dying at some point?

Are you running hurd-i386 or hurd-amd64?

Samuel

Re: keyboard configuration fails

[Samuel Thibault]

Hello,

Martin-Éric Racine, le jeu. 30 nov. 2023 12:23:47 +0200, a ecrit:
> Damn lists.debian's Reply-To... Please keep me in CC.

Ah, sorry, it's not the list's fault, but I told my mailer to avoid Cc
because most people are already subscribed to debian development lists.

> but the Hurd console does (which should work after a reboot).

(or just restarting the hurd-console service)

> This
> apparently fails, too, since debconf data for keyboard-configuration
> (correct for a default Finnish keyboard map) and what I get on the
> console (symbols where the US keyboard has them) don't match.

I just quickly tried within the installer, and things does work as far
as I can tell, for instance the key on the right of 'p' produces 'å'.

I tried to reconfigure keyboard-configuration to enable the Finnish
layout, and after hurd-console restart I did get the same.

Remember: in bug reports, always describe precisely what you did, what
you obtained, and what you expected. Otherwise we have a mail ping-pong
only to manage to find out what actually is going wrongly in your case,
thus a loss of time for everybody.

Samuel

Re: keyboard configuration fails

[Samuel Thibault]

Martin-Éric Racine, le mer. 29 nov. 2023 11:26:07 +0200, a ecrit:
> On Wed, Nov 29, 2023 at 11:22 AM Samuel Thibault  wrote:
> >
> > Martin-Éric Racine, le mer. 29 nov. 2023 01:55:23 +0200, a ecrit:
> > > On Tue, Nov 28, 2023 at 11:13 PM Samuel Thibault  
> > > wrote:
> > > > Martin-Éric Racine, le dim. 26 nov. 2023 16:19:58 +0200, a ecrit:
> > > > > The installer failed to configure the keyboard, which shows with
> > > > > incorrect symbols when typing in my user name at account creation.
> > > >
> > > > Which item did you choose in the boot menu?
> > > >
> > > > Which layout did you select?
> > >
> > > Text install.
> >
> > Text install is the pure gnumach console, which doesn't support keyboard
> > layouts.
> 
> Wait... the console doesn't support keyboard maps AT ALL?!

The Mach console, indeed (actually there is some support for it but it's
quite limited in terms of capacities, and thus we don't use it).

The Hurd console (pseudo-graphical) does support it, and uses the xkb
data.

Samuel

Re: keyboard configuration fails

[Samuel Thibault]

Martin-Éric Racine, le mer. 29 nov. 2023 01:55:23 +0200, a ecrit:
> On Tue, Nov 28, 2023 at 11:13 PM Samuel Thibault  wrote:
> > Martin-Éric Racine, le dim. 26 nov. 2023 16:19:58 +0200, a ecrit:
> > > The installer failed to configure the keyboard, which shows with
> > > incorrect symbols when typing in my user name at account creation.
> >
> > Which item did you choose in the boot menu?
> >
> > Which layout did you select?
> 
> Text install.

Text install is the pure gnumach console, which doesn't support keyboard
layouts.

Samuel

Re: keyboard configuration fails

[Samuel Thibault]

Hello,

Martin-Éric Racine, le dim. 26 nov. 2023 16:19:58 +0200, a ecrit:
> The installer failed to configure the keyboard, which shows with
> incorrect symbols when typing in my user name at account creation.

Which item did you choose in the boot menu?

Which layout did you select?

Samuel

Bug#1057004: gcc-13: hurd-amd64 support

[Samuel Thibault]

Package: gcc-13
Version: 13.2.0-7
Severity: important
Tags: patch
X-Debbugs-Cc: debian-hurd@lists.debian.org
User: debian-hurd@lists.debian.org
Usertags: hurd

Hello,

The attached patch adds support for hurd-amd64, could you apply it?

The part in hurd-amd64.diff comes from the upstream master commits,
which will thus be included in gcc 14.

The parts in hurd-multiarch.diff and hurd-multilib-multiarch.diff are
for long term, like gcc-multiarch.diff and gcc-multilib-multiarch.diff
for other archs.

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13 depends on:
ii  binutils   2.41-7
ii  cpp-13 13.2.0-7
ii  gcc-13-base13.2.0-7
ii  libc6  2.37-12+b1
ii  libcc1-0   13.2.0-7
ii  libgcc-13-dev  13.2.0-7
ii  libgcc-s1  13.2.0-7
ii  libgmp10   2:6.3.0+dfsg-2
ii  libisl23   0.26-3
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.1-1
ii  libstdc++6 13.2.0-7
ii  libzstd1   1.5.5+dfsg2-2
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages gcc-13 recommends:
ii  libc6-dev  2.37-12+b1

Versions of packages gcc-13 suggests:
ii  gcc-13-doc   13.2.0-1
pn  gcc-13-locales   
ii  gcc-13-multilib  13.2.0-7

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/patches/hurd-amd64.diff b/debian/patches/hurd-amd64.diff
new file mode 100644
index 000..e7288ea
--- /dev/null
+++ b/debian/patches/hurd-amd64.diff
@@ -0,0 +1,127 @@
+commit 5707e9db9c398d311defc80c5b7822c9a07ead60
+Author: Samuel Thibault 
+Date:   Sat May 6 13:50:36 2023 +0200
+
+hurd: Add multilib paths for gnu-x86_64
+
+We need the multilib paths in gcc to find e.g. glibc crt files on
+Debian.  This is essentially based on t-linux64 version.
+
+gcc/ChangeLog:
+
+* config/i386/t-gnu64: New file.
+* config.gcc [x86_64-*-gnu*]: Add i386/t-gnu64 to
+tmake_file.
+
+commit c768917402d4cba69a92c737e56e177f5b8ab0df
+Author: Samuel Thibault 
+Date:   Sat May 6 13:55:44 2023 +0200
+
+hurd: Ad default-pie and static-pie support
+
+This fixes the Hurd spec in the default-pie case, and adds static-pie
+support.
+
+gcc/ChangeLog:
+
+* config/i386/gnu.h: Use PIE_SPEC, add static-pie case.
+* config/i386/gnu64.h: Use PIE_SPEC, add static-pie case.
+
+diff --git a/src/gcc/config.gcc b/src/gcc/config.gcc
+index 3000379cafc..e62849c1230 100644
+--- a/src/gcc/config.gcc
 b/src/gcc/config.gcc
+@@ -5973,6 +5973,9 @@ case ${target} in
+   visium-*-*)
+   target_cpu_default2="TARGET_CPU_$with_cpu"
+   ;;
++  x86_64-*-gnu*)
++  tmake_file="$tmake_file i386/t-gnu64"
++  ;;
+ esac
+ 
+ t=
+diff --git a/src/gcc/config/i386/t-gnu64 b/src/gcc/config/i386/t-gnu64
+new file mode 100644
+index 000..23ee6823d65
+--- /dev/null
 b/src/gcc/config/i386/t-gnu64
+@@ -0,0 +1,38 @@
++# Copyright (C) 2002-2023 Free Software Foundation, Inc.
++#
++# This file is part of GCC.
++#
++# GCC is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 3, or (at your option)
++# any later version.
++#
++# GCC 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 GCC; see the file COPYING3.  If not see
++# <http://www.gnu.org/licenses/>.
++
++# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
++# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are sym

Re: Source for grub 2.06-13+hurd.2 ?

[Samuel Thibault]

Hello,

Martin-Éric Racine, le lun. 27 nov. 2023 09:35:19 +0200, a ecrit:
> The Hurd kernel in unstable wants a GRUB version higher than
> 2.06-13+hurd.2 yet neither unstable or experimental have that. Where
> can I find it?

It is available in snapshot:
http://snapshot.debian.org/package/grub2/
http://snapshot.debian.org/package/grub2/2.06-13%2Bhurd.2/
http://snapshot.debian.org/archive/debian-ports/20230701T202046Z/pool-hurd-i386/main/g/grub2/grub2_2.06-13%2Bhurd.2.dsc

Samuel

Re: proc leaking

[Samuel Thibault]

Hello,

Samuel Thibault, le mer. 01 nov. 2023 16:06:57 +0100, a ecrit:
> Samuel Thibault, le mer. 01 nov. 2023 15:35:00 +0100, a ecrit:
> > Samuel Thibault, le mer. 01 nov. 2023 13:14:17 +0100, a ecrit:
> > > Samuel Thibault, le mer. 01 nov. 2023 01:50:40 +0100, a ecrit:
> > > > Samuel Thibault, le mar. 31 oct. 2023 04:40:43 +0100, a ecrit:
> > > > > (it looks like there are memory leaks in proc, its vminfo keeps
> > > > > increasing).
> > > > 
> > > > It seems 64bit-specific: the program below makes proc leak memory, 100
> > > > vminfo lines at a time. Possibly __mach_msg_destroy doesn't actually
> > > > properly parse messages to be destroyed, so that in the error case the
> > > > server leaks non-inline data? Flavio, perhaps you have an idea?
> > > 
> > > I don't think we have the kernel-to-user equivalent for
> > > adjust_msg_type_size? So that we end up pushing twice too much data to
> > > userland for port arrays?
> > 
> > I found and fixed the allocation issue in the kernel.
> 
> It seems proc is still leaking, but on the heap this time. This is not
> 64bit-specific, the same simple reproducer triggers it:
> 
> while [  "$(echo -n `echo a` )" = a ] ; do : ; done
> 
> or more simply:
> 
> while true ; do echo $(echo -n $(echo a)) > /dev/null ; done

I found the issue, it's because of the quiescence support in libports,
which assumes that all threads will sooner or later go through a
quiescent state (because it finished processing a message). But that's
not true, proc doesn't set a thread timeout, and thus some threads can
stay indefinitely stuck in receiving messages. And thus the deferred
dereferencing used by ports_destroy_right never gets achieved.

I'll push a fix.

Samuel

Re: creating Hurd chroots on Linux using DPKG_ROOT chrootless mode

[Samuel Thibault]

Johannes Schauer Marin Rodrigues, le dim. 19 nov. 2023 11:57:07 +0100, a ecrit:
> The command above and the advice to extract ext2fs.static and exec.static
> should be put on some wiki page, I think.

It's the eternal problem with documentation: sometimes it doesn't even
exist, sometimes people don't find it. I have now added more keywords.

https://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#index8h1

Samuel