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

[Jeffrey Walton]

On Wed, May 29, 2024 at 5:09 AM Samuel Thibault  wrote:
>
> 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)

Good work, congrats!

Re: Remove me from this list please

[Jeffrey Walton]

On Thu, Mar 28, 2024 at 8:49 PM Sergio Casero Verdial
 wrote:
>
> I have been receiving emails for 2 years, it's okay, I don't want to continue 
> receiving emails, ALL the emails in my inbox are from Hurd and I'm fed up, I 
> move all the emails to spam and nothing, please get rid of this, I can't take 
> it anymore and I can't see my email without coming across 357 emails about 
> gnu hurd.
>

 ?

Re: dhcpcd: FTBFS on Hurd

[Jeffrey Walton]

On Wed, Jan 17, 2024 at 12:33 PM Joshua Branson  wrote:
> [...]
> Also what is FTBFS?

Failure to Build from Source.

Jeff

Re: 64bit startup

[Jeffrey Walton]

On Tue, Oct 24, 2023 at 9:56 PM Jessica Clarke  wrote:
>
> On 25 Oct 2023, at 02:40, Jeffrey Walton  wrote:
> >
> > On Tue, Oct 24, 2023 at 9:33 PM Jessica Clarke  wrote:
> >>
> >> On 25 Oct 2023, at 02:26, Jeffrey Walton  wrote:
> >>>
> >>> On Tue, Oct 24, 2023 at 6:21 PM Samuel Thibault  
> >>> wrote:
> >>>>
> >>>> Some update on the 64bit port:
> >>>>
> >>>> - The debian-ports archive now has enough packages to bootstrap a
> >>>> chroot.
> >>>> - A 64bit debian buildd is getting set up, not much work is left there.
> >>>> - The hurd-amd64 wanna-build infrastructure is to be set up in the
> >>>> coming days.
> >>>
> >>> Congrats
> >>>
> >>>> *but*
> >>>>
> >>>> Building packages is not very stable. I have been trying to build
> >>>> gcc-13 for a couple of weeks, without success so far. There are various
> >>>> failures, most often odd errors in the libtool script, which are a sign
> >>>> that the system itself is not behaving correctly. A way to reproduce
> >>>> the issue is to just repeatedly build a package that is using libtool,
> >>>> sooner or later that will fail very oddly.
> >>>
> >>> lol... <https://harmful.cat-v.org/software/GCC> and
> >>
> >> Yeah can we not spread this kind of vile rhetoric here? Regardless of
> >> how much truth is in that, and whether it holds today, that kind of
> >> language isn’t something we should be celebrating and encouraging
> >> others to read. Let’s keep things more civil and on topic.
> >
> > My apologies for offending your delicate sensibilities.
>
> 1. I did not say I was offended. I said it was vile rhetoric. It does
>not personally offend me, but that does not mean I want to see it
>being circulated on these kinds of mailing lists.

Your overreaction. It looks like the stuff I would expect to see on
social media, like one of those binary confused persons crying someone
is perpetrating a hate crime because the wrong pronoun (subject?) was
used.

> 2. Even if it did, so what? Per the Debian Mailing Lists’ Code of
>Conduct, a superset of Debian’s. Off-topic and unwelcoming content is
>against those. Even if it wasn’t explicitly written down as a rule,
>though, the decent response to “don’t send unwelcoming content” isn’t
>“I’m sorry you’re so sensitive” but “sorry, I won’t do it again”. So
>kindly act decently or don’t contribute.

Exactly. So what?

Some folks have witty humor and appreciate the nostalgia. Others don't.

If you don't like my posts, then plonk me.

Jeff

Re: 64bit startup

[Jeffrey Walton]

On Tue, Oct 24, 2023 at 9:33 PM Jessica Clarke  wrote:
>
> On 25 Oct 2023, at 02:26, Jeffrey Walton  wrote:
> >
> > On Tue, Oct 24, 2023 at 6:21 PM Samuel Thibault  
> > wrote:
> >>
> >> Some update on the 64bit port:
> >>
> >> - The debian-ports archive now has enough packages to bootstrap a
> >> chroot.
> >> - A 64bit debian buildd is getting set up, not much work is left there.
> >> - The hurd-amd64 wanna-build infrastructure is to be set up in the
> >> coming days.
> >
> > Congrats
> >
> >> *but*
> >>
> >> Building packages is not very stable. I have been trying to build
> >> gcc-13 for a couple of weeks, without success so far. There are various
> >> failures, most often odd errors in the libtool script, which are a sign
> >> that the system itself is not behaving correctly. A way to reproduce
> >> the issue is to just repeatedly build a package that is using libtool,
> >> sooner or later that will fail very oddly.
> >
> > lol... <https://harmful.cat-v.org/software/GCC> and
>
> Yeah can we not spread this kind of vile rhetoric here? Regardless of
> how much truth is in that, and whether it holds today, that kind of
> language isn’t something we should be celebrating and encouraging
> others to read. Let’s keep things more civil and on topic.

My apologies for offending your delicate sensibilities.

Jeff

Re: 64bit startup

[Jeffrey Walton]

On Tue, Oct 24, 2023 at 6:21 PM Samuel Thibault  wrote:
>
> Some update on the 64bit port:
>
> - The debian-ports archive now has enough packages to bootstrap a
> chroot.
> - A 64bit debian buildd is getting set up, not much work is left there.
> - The hurd-amd64 wanna-build infrastructure is to be set up in the
> coming days.

Congrats

> *but*
>
> Building packages is not very stable. I have been trying to build
> gcc-13 for a couple of weeks, without success so far. There are various
> failures, most often odd errors in the libtool script, which are a sign
> that the system itself is not behaving correctly. A way to reproduce
> the issue is to just repeatedly build a package that is using libtool,
> sooner or later that will fail very oddly.

lol...  and
.

Jeff

Re: unbreaking LibreOffices tests on at least release architectures

[Jeffrey Walton]

On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard  wrote:
>
> Am 22.07.23 um 14:02 schrieb Andreas Schwab:
> > On Jun 18 2023, Rene Engelhard wrote:
> >
> >> For riscv64 I already pointed that out in the thread starting at
> >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the
> >> other architectures there is the mail now. riscv64 is different because
> >> the failures are even more big than any other down below and it's actually
> >> a new architecture anyway.
> > Libreoffice is actually basically working on riscv64.
>
> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile
> says, though)

Be careful of -Os. I test one of my C++ libraries with it in the
library's test suite. Based on unexplained crashes with -Os, I believe
GCC produces bad code with -Os on occasion.

I do not recommend using -Os in production based on my experience.

Jeff

Re: [syzbot] [hfs?] WARNING in hfs_write_inode

[Jeffrey Walton]

On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox  wrote:
>
> On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > Then we should delete the HFS/HFS+ filesystems.  They're orphaned in
> > > MAINTAINERS and if distros are going to do such a damnfool thing,
> > > then we must stop them.
> >
> > Both HFS and HFS+ work perfectly fine. And if distributions or users are so
> > sensitive about security, it's up to them to blacklist individual features
> > in the kernel.
> >
> > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years
> > and I don't think it's justified to introduce such a hard compatibility
> > breakage just because some people are worried about theoretical evil
> > maid attacks.
> >
> > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac
> > and I don't think it's okay to break all these systems running Linux.
>
> If they're so popular, then it should be no trouble to find somebody
> to volunteer to maintain those filesystems.  Except they've been
> marked as orphaned since 2011 and effectively were orphaned several
> years before that (the last contribution I see from Roman Zippel is
> in 2008, and his last contribution to hfs was in 2006).

One data point may help.. I've been running Linux on an old PowerMac
and an old Intel MacBook since about 2014 or 2015 or so. I have needed
the HFS/HFS+ filesystem support for about 9 years now (including that
"blessed" support for the Apple Boot partition).

There's never been a problem with Linux and the Apple filesystems.
Maybe it speaks to the maturity/stability of the code that already
exists. The code does not need a lot of attention nowadays.

Maybe the orphaned status is the wrong metric to use to determine
removal. Maybe a better metric would be installation base. I.e., how
many users use the filesystem.

Jeff

Re: unbreaking LibreOffices tests on at least release architectures

[Jeffrey Walton]

On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard  wrote:
>
> Am 20.06.23 um 00:03 schrieb Jeffrey Walton:
> >
> > You can usually uncover them by building the package with CFLAGS=" ...
> > -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
> > ". The UBsan sanitizer operates on real data. There are no false
> > positives.
>
> I'd personally assume this isn't UB since upstream builds with UBsan for
> testing (admittedly not on mipsel, though). But once can investigate here...

Yeah, there's a caveat: you have to have complete self tests. If the
project lacks complete self tests, then you may not uncover the bug.

You can run the program in production with a sanitizer build. It may
uncover cases that were lacking in the test cases.

And it's unfortunate some arches lack Asan and UBsan support. They are
such powerful tools. Sometimes you can tease-out the UB on a different
arch. Sometimes you can't.

Jeff

Re: unbreaking LibreOffices tests on at least release architectures

[Jeffrey Walton]

On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard  wrote:
>
> Hi,
>
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
> > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
> >> ...
> >> I won't be of much help here unfortunately, except
> >> maybe testing patches, but then again there's porterboxes
> >> ...
> > You are the only one who could realistically debug many of these.
> >
> > E.g. on armel it says:
> >Fatal exception: Signal 6
> >Stack:
> >/<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4]
> >/<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534]
> >
> > /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0]
> >/lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c]
> >/lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360]
> >Aborted (core dumped)
> >
> > Fixing something like this would involve generating a backtrace,
> > and then you are likely the only person in Debian who could tell
> > what is actually going on there.
>
> Not really.
>
> > There are likely also build or debug tricks you know that a porter would
> > not know.
>
> True, I can help with those if needed.
>
> (As I already pointed out for zelenka, though it's basically setting
> some variables in rules)
>
> > Debugging something like this is only feasible with reasonable effort if
> > a porter who knows the port with its caveats debugs it together with a
> > package maintainer who knows the internals of the package.
>
> I didn't say I was not helping, I said I am of no help if it comes to
> actually fix it if it involves architecture knowledge.
>
> [...]
>
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep fixing them
> if I report them.
> > The pragmatic option would be to run only a smoketest for build success
> > on architectures not tested by upstream.
>
> And have Format->Character in Impress crash with Bus error like on
> mipsel? That doesn't sound too good for basic quality.
>
> There is a "smoketest" but it does just basic start. open, close stuff.
> Not even basic usage.

Related, bus errors are usually due to unaligned data accesses.
Programmers casting from one type to another when when they shouldn't,
like:

typedef unsigned char byte;
...
byte buffer[32];

readBuffer(buffer);
double d = *(double *)buffer;

That is undefined behavior because a byte buffer is a byte buffer, and
it is not a double. That can result in a bus error on some platforms.
You may get lucky and the byte buffer may be aligned for double. Or it
may not be.

In contrast, this would be Ok because the byte buffer is really a double object:

typedef unsigned char byte;
...
double d;
byte* buffer = (bytes*)

readBuffer(buffer);
double dd = *(double *)buffer;

You can usually uncover them by building the package with CFLAGS=" ...
-fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
". The UBsan sanitizer operates on real data. There are no false
positives.

You don't need to be a porter to build and run with sanitizers.
However, you do need an arch-specific machine. Or possibly a Debian
chroot.

Jeff

Re: dhcpcd5: FTBFS on Hurd-i386

[Jeffrey Walton]

On Fri, Jul 29, 2022 at 2:09 AM Martin-Éric Racine
 wrote:
>
> On Thu, Jul 28, 2022 at 10:38 PM Samuel Thibault  wrote:
> >
> > Martin-Éric Racine, le jeu. 28 juil. 2022 21:30:42 +0300, a ecrit:
> > > Actually, where it barfs is here:
> > >
> > > #if !defined(__linux__) && !defined(__QNX__) && !defined(__sun)
> > > #include 
> > > #else
> > > #include "endian.h"
> > > #endif
> > >
> > > What is the equivalent define for Hurd?
> >
> > It's just the same on the Hurd as on Linux, since that's just coming
> > from glibc.
>
> Yet it FTBFS on Hurd at that precise point. That suggets we need to
> patch that spot. Not knowing Hurd, I have no idea what the correct
> fragment would be.

If you want the Mach kernel, use __MACH__.  If you want GNU Hurd, use
__GNU__ or __gnu_hurd__.

The Pre-defined Operating System Macros list at Sourceforge is usually
reliable. Also see
https://sourceforge.net/p/predef/wiki/OperatingSystems/ .

Jeff

Re: The following signatures were invalid: EXPKEYSIG 5A88D659DCB811BB Debian Ports Archive Automatic Signing Key (2021)

[Jeffrey Walton]

On Thu, Feb 10, 2022 at 11:09 AM Philipp Klaus Krause  wrote:
>
> I just downloaded debian-hurd-20210812.img, and started it in kvm.
> apt-get update then failed:
> ...
> Get:3 http://snapshot.debian.org/archive/debian/20210812T10Z sid
> InRelease [165 kB]
> Err:1 http://snapshot.debian.org/archive/debian-ports/20210812T10Z
> sid InRelease
>The following signatures were invalid: EXPKEYSIG 5A88D659DCB811BB
> Debian Ports Archive Automatic Signing Key (2021)
> 

You might consider filing a bug against Debian or Apt. There's no such
thing as an expired signature.

For those who desire a key to have attributes, either (1) the key was
valid at the time and applied the signature or (2) the key was not
valid.
 A valid signature does not transition to invalid after the signature
has been applied.

The only way to invalidate signatures is to revoke the key. There's no
reason to revoke the key here.

This is just more Debian key mismanagement. They have a chronic problem.

Jeff

Re: HURD install errata

[Jeffrey Walton]

Hi Everyone,

An FYI on applying HURD updates. I think this broke in November or
December or so. I was putting it off thinking it may fix itself.

> I needed to reinstall HURD today. Something got sideways and the
> machine would not update properly. Something about a libc version from
> -unreleased and a kernel version.

I'm actually hitting the problem again after a fresh install during
the updates after the install. It looks like something is sideways.
The error is:


Preparing to unpack .../libc0.3_2.33-2~3_hurd-i386.deb ...
dpkg: error processing archive
/var/cache/apt/archives/libc0.3_2.33-2~3_hurd-i386.deb (--unpack):
 new libc0.3:hurd-i386 package pre-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libc0.3_2.33-2~3_hurd-i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 locales : Depends: libc-bin (> 2.33) but 2.31-13+hurd.2 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages
(or specify a solution).


Running apt --fix-broken install says the kernel must be upgraded, but
there's no kernel available to upgrade to. See attached.

Jeff

On Mon, Jan 3, 2022 at 10:08 PM Jeffrey Walton  wrote:
>
> Hi Samuel,
>
> I needed to reinstall HURD today. Something got sideways and the
> machine would not update properly. Something about a libc version from
> -unreleased and a kernel version.
>
> There were two errata items when installing from the ISO named
> debian-hurd-2021-i386-DVD-1.iso. I installed it into a VirtualBox VM
> in case it matters.
>
> The first item was a failure by /hurd/random to read
> /var/lib/random-seed. The second item was a Debian archive warning
> about a missing security repository.
>
> I attached the images because they are small.
>
> Jeff

Re: Failed self test on Hurd

[Jeffrey Walton]

On Sat, Oct 9, 2021 at 10:41 AM Peter  wrote:
>  ...
> Also it might be useful to know the output of "uname -s" is on Hurd, as the 
> makefile branches on the value.

jwalton@hurd-x86:~$ uname -s
GNU
jwalton@hurd-x86:~$ uname -o
GNU
jwalton@hurd-x86:~$ uname -a
GNU hurd-x86 0.9 GNU-Mach 1.8+git20210404-486/Hurd-0.9 i686-AT386 GNU

Re: Troubles with updating Debian Hurd

[Jeffrey Walton]

On Thu, Oct 7, 2021 at 5:34 PM Samuel Thibault  wrote:
>
> Hello,
>
> Answering separately since they are completely separate issues.
>
> Sergey Bugaev, le jeu. 30 sept. 2021 15:35:41 +0300, a ecrit:
> >- Filesize:77531148 [weak]
> >- 
> > SHA512:c8108d738ef08afa9556ec395e0b8097e54f66347cce924303b6294dcfa32a4a3853b29597902372562542c7b73ca364be44234d3c0b709e992ad19fa6b566a2
> >- SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
> >- SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
> >- MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
> >   Hashes of received file:
> >- 
> > SHA512:9fae8af5d37a72f3410c9c0c70d75c4677b9ee8933bd3a05c8cb20e59430f7b56fb060b6d0cba41a20ac0e7d878cd447a6936b740ffc3536b74afe0fd31d90bb
> >- SHA256:06de0c824e0ff3e683a5698ebd63892c34f264eff7d311a7e3a225dd894f8457
> >- SHA1:4b881bd3628a18f0917b55349563fe6a95f25887 [weak]
> >- MD5Sum:65d941cde7d7279bbecfe22c67ff40fa [weak]
> >- Filesize:77531148 [weak]
>
> > I'm primarily concerned about the hashsum check failures. In all of the
> > cases, filesize, md5, sha1, and sha256 seem to match, but sha512 differs
> > between expected and received. I can't really imagine how this could be
> > possible unless sha512 was just computed incorrectly either remotely or
> > locally.
>
> That's odd indeed. Which gnumach kernel were you using? I noticed an FPU
> context switch bug in gnumach, possibly that was affecting only the
> sha512 implementation. It is fixed in version 2:1.8+git20210923-1.

GnuPG released a new version today. The release notes said something
about problems with Let's Encrypt. Maybe it affects packaging, too.

The changes are not listed in NEWS at the moment,
https://dev.gnupg.org/source/gnupg/browse/master/NEWS. But here's the
email: https://lists.gnupg.org/pipermail/gnupg-users/2021-October/065473.html.

Jeff

Re: Netsurf build failure: 'PATH_MAX' undeclared (patch)

[Jeffrey Walton]

On Sat, May 29, 2021 at 2:33 PM João Pedro Malhado  wrote:
>
> "With a little help from my friends", I came up with a patch for the Netsurf
> build. The size of the filepaths are now allocated dynamically using 
> asprintf()
> type of functions and realpath().
> ...
> I don't know if upstream would accept such a patch as they need to worry about
> platforms like RISC OS and AmigaOS, and I don't know if this would work there.
> It might be ok for Debian though. If there are no objections/corrections I 
> could
> try upstream first.

You may be able to use Gnulib for the cross-platform support of
asprintf and realpath. Gnulib will handle the implementation details
for you. Gnulib also does a good job of listing problem platforms.

Also see https://www.gnu.org/software/gnulib/manual/html_node/asprintf.html
and https://www.gnu.org/software/gnulib/manual/html_node/realpath.html.

Jeff

Re: problem with hurd image

[Jeffrey Walton]

On Sun, May 9, 2021 at 5:16 AM Samuel Thibault  wrote:
>
> Marcin Laszewski, le dim. 09 mai 2021 07:34:21 +0100, a ecrit:
> > Have you a etherner driver compiled in the kernel (mach) ?
>
> There is no need for that, netdde already has all the network drivers
> that you'll want. And yes it's automatically set up by the debian
> installer. The fact that /dev/eth0 has apparently disappeared (please
> tell us exactly what this means: does /dev/eth0 not show up with ls) is
> only a sign of a filesystem problem, not a network driver problem.

In the past, I experienced a hang at boot when bringing up the network
under Virtual Box. I used the default card provided by VB instead of
selecting a card for which Hurd had a driver.

After a dirty reboot (Machine -> Reset), I would lose /dev devices,
like /dev/urandom.

I assumed it was due to ext2 and lack of journaling. But I never did
track down the actual problem.

The fix (for me) was to reinstall Hurd using a network card for which
Hurd had a driver.

Jeff

Re: Netsurf build failure: 'PATH_MAX' undeclared

[Jeffrey Walton]

On Tue, Apr 27, 2021 at 5:12 PM  wrote:
>
> On 2021-04-27 20:40, Jeffrey Walton wrote:
> > On Tue, Apr 27, 2021 at 4:35 AM William ML Leslie wrote:
> >>
> >> On Tue, 27 Apr 2021, 6:13 am Samuel Thibault wrote:
> >>>
> >>> It's not because something is economical that one should want to do
> >>> it.
> >>>
> >>> You don't even seem to realize that defining PATH_MAX *does* pose
> >>> problem, notably with the actual semantic of realpath(), due to the
> >>> semantic that posix attaches to it.
> >>>
> >>
> >> Economical would be to avoid the rich bug farm that is arbitrary but
> >> unenforced limits.  PATH_MAX is an open invitation for buffer
> >> overflows on any modern system.
> >
> > It is what it is. Folks are going to use PATH_MAX.
>
> ... therefore nobody should fix bugs?

What bug?

If you get fed a path larger than 4096 you are likely under attack. I
don't blame Posix or Linux for putting a sane upper limit on it.

> That is bad logic. There are plenty of historic code symbols which are
> known to be buggy, removed from various OS due to that, or never were
> portable at all. A bad idea existing does not mean it MUST be fully
> supported everywhere.
>
> PATH_MAX is a false value even on systems where it is "supported". It
> often really means the max length of the *filename* section of path and
> people use it for full-path or other bad assumptions based on the symbol
> name.

4096 is large enough for every system I've worked on since the late 1990s.

The only problem I encountered was in the early 2000s on a Windows
system. MAX_PATH is 255 on the system, and I needed about 280
characters.

I'd love to hear about your use case where you encountered a need for
a path or component larger than 4K.

Jeff

Re: Netsurf build failure: 'PATH_MAX' undeclared

[Jeffrey Walton]

On Tue, Apr 27, 2021 at 4:35 AM William ML Leslie
 wrote:
>
> On Tue, 27 Apr 2021, 6:13 am Samuel Thibault,  wrote:
>>
>> It's not because something is economical that one should want to do it.
>>
>> You don't even seem to realize that defining PATH_MAX *does* pose
>> problem, notably with the actual semantic of realpath(), due to the
>> semantic that posix attaches to it.
>>
>
> Economical would be to avoid the rich bug farm that is arbitrary but 
> unenforced limits.  PATH_MAX is an open invitation for buffer overflows on 
> any modern system.

It is what it is. Folks are going to use PATH_MAX.

You can thank Drepper and the Glibc folks for many of the buffer
overflow problems in GNU software.

Jeff

Re: Netsurf build failure: 'PATH_MAX' undeclared

[Jeffrey Walton]

On Mon, Apr 26, 2021 at 3:12 PM Samuel Thibault  wrote:
>
> Jeffrey Walton, le lun. 26 avril 2021 15:08:28 -0400, a ecrit:
> > On Mon, Apr 26, 2021 at 2:58 PM Samuel Thibault  
> > wrote:
> > >
> > > Jeffrey Walton, le lun. 26 avril 2021 14:48:32 -0400, a ecrit:
> > > > On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado  
> > > > wrote:
> > > > >
> > > > > On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
> > > > > > João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
> > > > > > > > src/time.c:25:10: fatal error: mach/clock.h: No such file or 
> > > > > > > > directory
> > > > > > >
> > > > > > > https://buildd.debian.org/status/package.php?p=netsurf
> > > > > > >
> > > > > > > Is this something easy to fix and patch?
> > > > > >
> > > > > > Yes, see 
> > > > > > https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
> > > > > >
> > > > > > > would there be other packages in the repository affected by the 
> > > > > > > same
> > > > > > > problem?
> > > > > >
> > > > > > Various packages wrongly think that mach == apple. The fix is 
> > > > > > usually
> > > > > > very simple.
> > > > >
> > > > > Thank you Samuel for the useful pointers.
> > > > >
> > > > > I made some simple changes to the time.c file and the build went on, 
> > > > > only to
> > > > > fail at some later stage. The error that I'm getting is:
> > > > >
> > > > > frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url':
> > > > > frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use 
> > > > > in this
> > > > > function)
> > > > > 252 | char buf[PATH_MAX];
> > > > >
> > > > > Now, the only C I know is what I can guess from other programming 
> > > > > languages I'm
> > > > > familiar with, but this seems simple and not very hurd specific. 
> > > > > However the
> > > > > build does not seem to have any problems on other platforms, so I 
> > > > > don't know.
> > > > > Anyone has an idea on how to best approach this?
> > > >
> > > > Ensure you are including  in the source file. That's usually
> > > > the place PATH_MAX is defined.
> > >
> > > Please always read the porting guideline page, it discusses such things.
> > >
> > > > You can search for symbols on the Posix website at 
> > > > https://pubs.opengroup.org:
> > > >
> > > >   https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
> > >
> > > Yes, but PATH_MAX is not mandatory, and it is indeed not defined on
> >
> > > GNU/Hurd. Please read the mentioned page.
> >
> > Instead of asking the world to do something special, perhaps Hurd
> > should do what people expect?
>
> People should *not* expect PATH_MAX to be defined.
>
> Using PATH_MAX is most often a sign of laziness, that possibly entails
> bugs or even security holes.

Or expediency. Nearly all operating systems provide PATH_MAX.

> > Doing what the world expects is economical.
>
> Yes. And we should also burn all the petrol we have on earth since it's
> economical.

https://www.google.com/search?q=logical+fallacy+faulty+analogy

Jeff

Re: Netsurf build failure: 'PATH_MAX' undeclared

[Jeffrey Walton]

On Mon, Apr 26, 2021 at 2:58 PM Samuel Thibault  wrote:
>
> Jeffrey Walton, le lun. 26 avril 2021 14:48:32 -0400, a ecrit:
> > On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado  
> > wrote:
> > >
> > > On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
> > > > João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
> > > > > > src/time.c:25:10: fatal error: mach/clock.h: No such file or 
> > > > > > directory
> > > > >
> > > > > https://buildd.debian.org/status/package.php?p=netsurf
> > > > >
> > > > > Is this something easy to fix and patch?
> > > >
> > > > Yes, see 
> > > > https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
> > > >
> > > > > would there be other packages in the repository affected by the same
> > > > > problem?
> > > >
> > > > Various packages wrongly think that mach == apple. The fix is usually
> > > > very simple.
> > >
> > > Thank you Samuel for the useful pointers.
> > >
> > > I made some simple changes to the time.c file and the build went on, only 
> > > to
> > > fail at some later stage. The error that I'm getting is:
> > >
> > > frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url':
> > > frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in 
> > > this
> > > function)
> > > 252 | char buf[PATH_MAX];
> > >
> > > Now, the only C I know is what I can guess from other programming 
> > > languages I'm
> > > familiar with, but this seems simple and not very hurd specific. However 
> > > the
> > > build does not seem to have any problems on other platforms, so I don't 
> > > know.
> > > Anyone has an idea on how to best approach this?
> >
> > Ensure you are including  in the source file. That's usually
> > the place PATH_MAX is defined.
>
> Please always read the porting guideline page, it discusses such things.
>
> > You can search for symbols on the Posix website at 
> > https://pubs.opengroup.org:
> >
> >   https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
>
> Yes, but PATH_MAX is not mandatory, and it is indeed not defined on

> GNU/Hurd. Please read the mentioned page.

Instead of asking the world to do something special, perhaps Hurd
should do what people expect?

Doing what the world expects is economical. Instead of wasting
hundreds of developers' time (say 1000 developers, 15 minutes each),
Hurd can fix it in once (15 minutes). 15 minutes (Hurd) is much more
cost effective than asking each developer to figure out what Hurd is
doing special (15000 minutes, 250 man hours).

Jeff

Re: Netsurf build failure: 'PATH_MAX' undeclared

[Jeffrey Walton]

On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado  wrote:
>
> On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
> > João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
> > > > src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
> > >
> > > https://buildd.debian.org/status/package.php?p=netsurf
> > >
> > > Is this something easy to fix and patch?
> >
> > Yes, see 
> > https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
> >
> > > would there be other packages in the repository affected by the same
> > > problem?
> >
> > Various packages wrongly think that mach == apple. The fix is usually
> > very simple.
>
> Thank you Samuel for the useful pointers.
>
> I made some simple changes to the time.c file and the build went on, only to
> fail at some later stage. The error that I'm getting is:
>
> frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url':
> frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
> function)
> 252 | char buf[PATH_MAX];
>
> Now, the only C I know is what I can guess from other programming languages 
> I'm
> familiar with, but this seems simple and not very hurd specific. However the
> build does not seem to have any problems on other platforms, so I don't know.
> Anyone has an idea on how to best approach this?

Ensure you are including  in the source file. That's usually
the place PATH_MAX is defined.

You can search for symbols on the Posix website at https://pubs.opengroup.org:

  https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org

Jeff

Re: sem_open is coming!

[Jeffrey Walton]

On Wed, Dec 16, 2020 at 6:02 PM Samuel Thibault  wrote:
>
> More and more packages were depending on a working sem_open() function
> (scipy, pandas, matplotlib, etc.) so I "implemented" it (basically
> copied over the nptl implementation), it will be in libc0.3 2.31-6 which
> is getting built.

Forgive my ignorance... I thought semaphores were counted signals
implemented by the OS so they can be used across processes.

I don't believe libc should be in the business of sharing data across processes.

In fact, regarding userland sharing, a GNU_SHARED data section in an
elf binary will cause it to fail an audit or produce a finding.
Processes should not be sharing data like that because a corruption in
one process affects another process.

Jeff

Re: git broken on hurd

[Jeffrey Walton]

On Tue, Apr 21, 2020 at 3:56 PM Pirate Praveen  wrote:
>
> On Tue, Apr 21, 2020 at 3:51 pm, Jeffrey Walton 
> wrote:
> > On Tue, Apr 21, 2020 at 3:46 PM Samuel Thibault
> >  wrote:
> >>
> >>  Hello,
> >>
> >>  Pirate Praveen, le mer. 22 avril 2020 01:10:16 +0530, a ecrit:
> >>  > Someone working on it already? I can see it was working till
> >> 2.25.1
> >>  > http://snapshot.debian.org/package/git/1%3A2.25.1-1/
> >>
> >>  There has been a test failing since about 1:2.12.2+next.20170330-1
> >>  I don't think anybody has had a look at it.
> >>  >From times to times, I make a build without checks, so git gets
> >>  installable again (last time with 1:2.25.1-1), but I don't do it
> >>  systematically.
> >
> > Git bumped to 2.26.2 recently. 2.26 may have cleared the test failure.
> > The Git folks are pretty good at staying on top of self test failures.
> >
>
> buildd log still shows the failure.
> https://buildd.debian.org/status/fetch.php?pkg=git=hurd-i386=1%3A2.26.2-1=1587409938=0

https://marc.info/?l=git=158750316126553

Jeff

Re: git broken on hurd

[Jeffrey Walton]

On Tue, Apr 21, 2020 at 3:46 PM Samuel Thibault  wrote:
>
> Hello,
>
> Pirate Praveen, le mer. 22 avril 2020 01:10:16 +0530, a ecrit:
> > Someone working on it already? I can see it was working till 2.25.1
> > http://snapshot.debian.org/package/git/1%3A2.25.1-1/
>
> There has been a test failing since about 1:2.12.2+next.20170330-1
> I don't think anybody has had a look at it.
> >From times to times, I make a build without checks, so git gets
> installable again (last time with 1:2.25.1-1), but I don't do it
> systematically.

Git bumped to 2.26.2 recently. 2.26 may have cleared the test failure.
The Git folks are pretty good at staying on top of self test failures.

Jeff

Re: Apt warnings after dist-upgrade

[Jeffrey Walton]

On Sat, Apr 18, 2020 at 4:53 PM Samuel Thibault  wrote:
>
> Jeffrey Walton, le sam. 18 avril 2020 16:45:44 -0400, a ecrit:
> > W: Skipping acquire of configured file 'main/source/Sources' as
> > repository 'http://deb.debian.org/debian-ports sid InRelease' does not
> > seem to provide it (sources.list entry misspelt?)
>
> debian-ports doesn't currently provides sources indeed.
>
> > W: Target Packages (main/binary-hurd-i386/Packages) is configured
> > multiple times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
>
> So you seem to have duplicated lines as mentioned.

My bad... I did not change my sources.list. Something else changed them.

Jeff

Apt warnings after dist-upgrade

[Jeffrey Walton]

Hi Everyone,

I ran a dist-upgrade earlier today. An update now produces several warnings:

W: Skipping acquire of configured file 'main/source/Sources' as
repository 'http://deb.debian.org/debian-ports sid InRelease' does not
seem to provide it (sources.list entry misspelt?)
W: Target Packages (main/binary-hurd-i386/Packages) is configured
multiple times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
W: Target Packages (main/binary-all/Packages) is configured multiple
times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
W: Target Translations (main/i18n/Translation-en_US) is configured
multiple times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
W: Target Translations (main/i18n/Translation-en) is configured
multiple times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
W: Target Packages (main/binary-hurd-i386/Packages) is configured
multiple times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
W: Target Packages (main/binary-all/Packages) is configured multiple
times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
W: Target Translations (main/i18n/Translation-en_US) is configured
multiple times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13
W: Target Translations (main/i18n/Translation-en) is configured
multiple times in /etc/apt/sources.list:8 and /etc/apt/sources.list:13

Jeff

Just lost git on apt-get update

[Jeffrey Walton]

Hi Everyone,

I just fired up the VM and performed a update/upgrade. It looks like
the latest changes whacked Git (see below). I'm having trouble
re-installing it:

$ sudo apt-get install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 git : Depends: git-man (< 1:2.25.1-.) but 1:2.26.0~rc2-1 is to be installed
E: Unable to correct problems, you have held broken packages.

And here was the result of the update/upgrade:

$ cat /var/log/apt/history.log
Start-Date: 2020-03-18  13:29:39
Commandline: apt-get -y dist-upgrade
Requested-By: jwalton (1000)
Upgrade: xfce4-power-manager:hurd-i386 (1.6.5-2, 1.6.6-1),
vim-common:hurd-i386 (2:8.2.0378-1, 2:8.2.0397-1), hurd-dev:hurd-i386
(1:0.9.git20191228-1, 1:0.9.git20200314-1), git-man:hurd-i386
(1:2.25.1-1, 1:2.26.0~rc2-1), libxkbfile1:hurd-i386 (1:1.0.9-2,
1:1.1.0-1), at-spi2-core:hurd-i386 (2.36.0-1, 2.36.0-2),
liblognorm5:hurd-i386 (2.0.5-1, 2.0.5-1.1),
xfce4-power-manager-plugins:hurd-i386 (1.6.5-2, 1.6.6-1),
gimp-data:hurd-i386 (2.10.14-2, 2.10.14-3), runit-helper:hurd-i386
(2.8.14, 2.8.15), libgphoto2-l10n:hurd-i386 (2.5.23-2, 2.5.24-1),
xdg-utils:hurd-i386 (1.1.3-1, 1.1.3-2), hurd:hurd-i386
(1:0.9.git20191228-1, 1:0.9.git20200314-1), libatspi2.0-0:hurd-i386
(2.36.0-1, 2.36.0-2), libjbig2dec0:hurd-i386 (0.17-1, 0.18-1),
tar:hurd-i386 (1.30+dfsg-6, 1.30+dfsg-7), vim-runtime:hurd-i386
(2:8.2.0378-1, 2:8.2.0397-1), gir1.2-atspi-2.0:hurd-i386 (2.36.0-1,
2.36.0-2), python3-gi:hurd-i386 (3.34.0-6, 3.36.0-1),
logrotate:hurd-i386 (3.15.1-2, 3.16.0-2), hurd-libs0.3:hurd-i386
(1:0.9.git20191228-1, 1:0.9.git20200314-1), libglib2.0-0:hurd-i386
(2.64.0-2, 2.64.1-1), xfce4-power-manager-data:hurd-i386 (1.6.5-2,
1.6.6-1)
Remove: git:hurd-i386 (1:2.25.1-1)
End-Date: 2020-03-18  13:30:00

Start-Date: 2020-03-18  13:30:02
Commandline: apt-get -y autoremove
Requested-By: jwalton (1000)
Remove: git-man:hurd-i386 (1:2.26.0~rc2-1), liberror-perl:hurd-i386 (0.17029-1)
End-Date: 2020-03-18  13:30:02

Re: hurd_0.9.git20200314-1_source-all.changes ACCEPTED into unstable

[Jeffrey Walton]

Hi Everyone,

Just a quick note after testing several software packages on the JAN
2020 version of HURD.

The distro is doing great. It appears to be much more stable then the
previous version I was using for testing.

I even performed several ungraceful shutdowns and the box remained
stable. In the past, the network would hang, and the ungraceful
restart would cause /dev/urandom to go missing.

Jeff

On Sat, Mar 14, 2020 at 1:21 PM Debian FTP Masters
 wrote:
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sat, 14 Mar 2020 15:35:28 +
> Source: hurd
> Binary: hurd hurd-dbgsym hurd-dev hurd-dev-dbgsym hurd-doc hurd-libs0.3 
> hurd-libs0.3-dbgsym
> Built-For-Profiles: noudeb noprof
> Architecture: source all
> Version: 1:0.9.git20200314-1
> Distribution: unstable
> Urgency: medium
> Maintainer: GNU Hurd Maintainers 
> Changed-By: Samuel Thibault 
> Description:
>  hurd   - GNU Hurd
>  hurd-dev   - GNU Hurd (development files)
>  hurd-doc   - GNU Hurd manual
>  hurd-libs0.3 - GNU Hurd (libraries)
> Changes:
>  hurd (1:0.9.git20200314-1) unstable; urgency=medium
>  .
>* New upstream snapshot
>* rules [stage1 stage2 stage3] (CONFIGURE_ARGS): Add --without-libcrypt.
>* rules: Fix staged build.
>* patches/getty-noclear: Discard --noclear passed by inittab.
>* hurd-udeb.install: Add acpi and shutdown translators, to fix d-i shutting
>  down box.
> ...

GDB no longer works as expected

[Jeffrey Walton]

Hi Everyone,

GDB no longer works. GDB worked in the past, but I don't recall how long ago.

Fatal Python Error: _PyHashRandomization_Init: failed to get
random numbers to initialize Python

I can't give the GDB version because `gdb --version` fails, too.

Uname identifies as:

GNU hurd-x86 0.9 GNU-Mach 1.8+git20190109-486/Hurd-0.9 i686-AT386 GNU

Jeff

tolower trick in net.c

[Jeffrey Walton]

Hi Everyone,

I was looking at
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/xen/net.c. The
tolower trick of setting the 5th bit is not portable. C does not
guarantee the trick.

for (number = 0, c = *cp | 0x20; ... )

As far as I know the only guarantees are:

* letters A-Z and a-z exist and that they fit within a byte
* digits 0-9 are sequential

It may be a good idea to just call tolower on *cp.

Jeff

Emacs troubles after dist-upgrade

[Jeffrey Walton]

I was able to install emacs-nox after initial install.

After a apt-get update && apt-get dist-upgrade:

$ sudo emacs /etc/fstab
sudo: emacs: command not found

And:

$ sudo apt-get install emacs-nox
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 emacs-nox : Depends: emacs-bin-common (= 1:25.2+1-11+unreleased1) but
it is not going to be installed
 Depends: emacs-common (= 1:25.2+1-11+unreleased1) but
1:26.1+1-3.2 is to be installed
E: Unable to correct problems, you have held broken packages.

Re: Broken random number generator

[Jeffrey Walton]

On Mon, Aug 12, 2019 at 4:35 AM Samuel Thibault  wrote:
>
> Jeffrey Walton, le lun. 12 août 2019 04:30:09 -0400, a ecrit:
> > I'm trying to setup a machine to investigate this failure of Crypto++
> > (https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B=hurd-i386=5.6.4-9=1565561714=0):
> >
> > Testing operating system provided nonblocking random number generator...
> > FAILED:  10 generated bytes compressed to 98749 bytes by DEFLATE
>
> We haven't implemented real collection of hardware entropy, both
> /dev/random and /dev/urandom use a pseudo-random generator, so I'm not
> surprised that it can be compressed a bit.
>
> > Some Python package complained it failed to get random numbers.
> >
> > And GnuTLS failed to initialize due to the random number generator.
>
> Do you have both /dev/random and /dev/urandom? You may have to re-run
> dpkg-reconfigure hurd
> to fix them.

/dev/urandom is completely missing on my test rig.

Jeff

Re: Networking is still broke

[Jeffrey Walton]

On Mon, Aug 12, 2019 at 3:27 AM Samuel Thibault  wrote:
>
> Jeffrey Walton, le lun. 12 août 2019 02:53:44 -0400, a ecrit:
> > Networking on a fresh Debian HURD install is still broken. The machine
> > hangs at getting a DHCP address.
> >
> > The only work-around I have found is to disable the network adapter in
> > the vm's settings. With the network adapter removed the vm will boot.
>
> Which kind of VM are you using?

Virtual Box on Linux. Ubuntu 18.04 LTS (fully patched).

Jeff

Re: Networking is still broke

[Jeffrey Walton]

On Mon, Aug 12, 2019 at 3:31 AM Narcis Garcia  wrote:
>
> Which NIC model do you "plug" to the Hurd machine?

I tried the three Intel NICs and virtio.

Jeff

Networking is still broke

[Jeffrey Walton]

Networking on a fresh Debian HURD install is still broken. The machine
hangs at getting a DHCP address.

The only work-around I have found is to disable the network adapter in
the vm's settings. With the network adapter removed the vm will boot.

A server without a network connection is not very useful.

Installer drive names

[Jeffrey Walton]

I installed HURD from the latest DVD ISO at .

I might be missing something, but it looks like the graphical
installer got the names of the hard drive a dvd drive backwards.
/dev/hd2 is the size of the dvd in the dvd drive; and /dev/sd0 is the
size of the hard drive I created for the virtual machine.

Also see https://postimg.cc/yk88gLMw.

Jeff

Re: Debian GNU/Hurd 2019 released!

[Jeffrey Walton]

On Sat, Jul 13, 2019 at 2:48 PM Richard Braun  wrote:
>
> On Sat, Jul 13, 2019 at 08:37:54PM +0200, Arne Babenhauserheide wrote:
> > >   1. The installer uses ext2.
> > …
> > > Regarding (1), ext2 seems a bit unusual in 2019, but it may be a
> > > design decision. It may be worth noting ext4 is a journaled file
> > > system and ext2 is not.
> >
> > The reason for ext2 is that this is not just an ordinary ext2, but one
> > which supports setting passive Hurd translators on nodes (started on
> > access to the filesystem node).
>
> The real reason is history. Noone did work to get ext4 in, but ext2
> on the other hand was there from the start. How can people imagine
> this is a design decision at all ?

Well, I can't speak for others, but for me, ext2 is there. Ext4 has
been available for over 10 years. There has to be a good reason for
selecting ext2 over ext4 a decade after the fact.

Also, the Hurd docs don't state no one has done the work. Confer,
https://www.gnu.org/software/hurd/hurd/translator/ext2fs.html . I
would not advertise that either :)

Finally, there are no open issues for the ext4 migration. Confer,
https://www.gnu.org/software/hurd/tag/open_issue_hurd.html .

Jeff

Re: Debian GNU/Hurd 2019 released!

[Jeffrey Walton]

On Sat, Jul 6, 2019 at 7:57 PM Samuel Thibault  wrote:
>
> It is with huge pleasure that the Debian GNU/Hurd team announces the
> release of Debian GNU/Hurd 2019.  This is a snapshot of Debian "sid" at
> the time of the stable Debian "stretch" release (July 2019), so it is
> mostly based on the same sources.  It is not an official Debian release,
> but it is an official Debian GNU/Hurd port release.
>
> The installation ISO images can be downloaded from cdimage
> (https://cdimage.debian.org/cdimage/ports/10.0/hurd-i386/)
> in the usual three Debian flavors: NETINST, CD, or DVD. Besides the
> friendly Debian installer, a pre-installed disk image is also available,
> making it even easier to try Debian GNU/Hurd. The easiest way to run it
> is inside a VM such as qemu
> (https://www.debian.org/ports/hurd/hurd-install)
>
> Debian GNU/Hurd is currently available for the i386 architecture with
> about 80% of the Debian archive, and more to come!

Congrats.

A couple feedback items from an install

  1. The installer uses ext2.
  2. /hurd/random: failed to read random seed file
  3. Xcfe desktop has some gaps

Regarding (1), ext2 seems a bit unusual in 2019, but it may be a
design decision. It may be worth noting ext4 is a journaled file
system and ext2 is not.

Regarding (2), will this affect my SSH machine keys? Will I be in weak
key territory?

Regarding (3), Hurd still hangs around when attempting to get a DHCP
address. This problem was present in the last version of Hurd. I
installed the new version of Hurd in hopes of clearing the problem.

Also see (1) https://postimg.cc/xqPyzQRY and (3)
https://postimg.cc/yksJ0SNr. (Sorry about the spam).

Jeff

GCC and UBsan for Hurd?

[Jeffrey Walton]

Hi Everyone,

I'm trying to build a debug configuration with UBsan:

$ g++ -DDEBUG -g2 -O1 -fsanitize=undefined TestPrograms/test_cxx.cxx
/usr/bin/ld: cannot find -lubsan

Apt-cache is returning a lot of hits for UBsan, but they seem to be
for cross-compiles.

What package do I use for Hurd?

Thanks in advance.

-

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Hurd buster/sid
Release:unstable
Codename:   sid

$ apt-cache search ubsan
lib32ubsan0-amd64-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib32ubsan0-s390x-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib64ubsan0-i386-cross - UBSan -- undefined behaviour sanitizer (64bit)
libubsan0-amd64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-arm64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-armel-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-armhf-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-i386-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-ppc64el-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-s390x-cross - UBSan -- undefined behaviour sanitizer (runtime)
libx32ubsan0-amd64-cross - UBSan -- undefined behaviour sanitizer (x32)
libx32ubsan0-i386-cross - UBSan -- undefined behaviour sanitizer (x32)
lib32ubsan0-ppc64-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib32ubsan0-sparc64-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib32ubsan0-x32-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib64ubsan0-powerpc-cross - UBSan -- undefined behaviour sanitizer (64bit)
lib64ubsan0-x32-cross - UBSan -- undefined behaviour sanitizer (64bit)
libubsan0-powerpc-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-ppc64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-sparc64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan0-x32-cross - UBSan -- undefined behaviour sanitizer (runtime)
lib32ubsan1-amd64-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib32ubsan1-s390x-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib64ubsan1-i386-cross - UBSan -- undefined behaviour sanitizer (64bit)
libubsan1-amd64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-arm64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-armel-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-armhf-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-i386-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-ppc64el-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-s390x-cross - UBSan -- undefined behaviour sanitizer (runtime)
libx32ubsan1-amd64-cross - UBSan -- undefined behaviour sanitizer (x32)
libx32ubsan1-i386-cross - UBSan -- undefined behaviour sanitizer (x32)
lib32ubsan1-ppc64-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib32ubsan1-sparc64-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib32ubsan1-x32-cross - UBSan -- undefined behaviour sanitizer (32bit)
lib64ubsan1-powerpc-cross - UBSan -- undefined behaviour sanitizer (64bit)
lib64ubsan1-x32-cross - UBSan -- undefined behaviour sanitizer (64bit)
libubsan1-powerpc-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-ppc64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-sparc64-cross - UBSan -- undefined behaviour sanitizer (runtime)
libubsan1-x32-cross - UBSan -- undefined behaviour sanitizer (runtime)

Re: Debian HURD is not booting after install in Virtual Box VM

[Jeffrey Walton]

On Sat, Feb 2, 2019 at 10:24 PM Amos Jeffries  wrote:
>
> On 3/02/19 11:27 am, Samuel Thibault wrote:
> >
> > Jeffrey Walton, le sam. 02 févr. 2019 14:19:24 -0500, a ecrit:
> >> I'm trying to install HURD into a Virtual Box VM on Windows.
> >
> > I don't think anybody tried that setup.
> >
>
> This was the setup I was working with some years ago. The same issue
> occured on first install of the Debian's (then) latest image download link.
>
> VirtualBox requires the VM to be 32-bit with the same extensions pack
> installed as if a standard Linux Debian VM was to be used. Without these
> a pile of confusing device issues occur.

Thanks.

I found I could work around it by inserting a CD if one was not
present (or ejecting one if present). I guess it has something to do
with udev being able to move the computer to a new state that allows
it to boot.

No logs to provide at the moment, though. There's no dmesg, and trying
to read /dev/klog crashes:

$ dmesg
-bash: dmesg: command not found
$ cat /dev/klog
cat: /dev/klog: Computer bought the farm

Does anyone know how to view system logs on this OS?

Jeff

Debian HURD is not booting after install in Virtual Box VM

[Jeffrey Walton]

Hi Everyone,

I'm trying to install HURD into a Virtual Box VM on Windows. I've run
through the process three times with the following HURD options:

* Desktop Environment (GNOME), SSH Server, System Utilities
* Desktop Environment (MATE), SSH Server, System Utilities
* SSH Server, System Utilities (no desktop environment )

Each of the installs complete successfully, including fetching latest
packages from a mirror. However the first boot after install hangs
just after the ISC code/DHCP code attempts to do its thing. Looking at
my DHCP server I don't see the hostname registered with an address, so
I'm guessing that's about where the problem lies.

There's nothing special about Virtual Box on this machine. It has
about 45 VMs, including Debian 6 through 8 in both 32-bit and 64-bit
flavors. None of the VMs have a problem.

The HURD ISO was downloaded from
https://cdimage.debian.org/cdimage/ports/current-hurd-i386/iso-dvd/ .
It is named debian-hurd-2017-i386-DVD-1.iso and dated 2017-06-13. The
installer updated the installation during install and I have no idea
of what was pulled in.

It would be helpful if someone would look at the issue.

Thanks in advance.