Gather suggestions about how to set up a more friendly development environment on hurd vm

ucode :)), and how to set up clangd lsp with vim; this is quite easy to set up on GNU/Linux, but it's not the case on Hurd as some softwares are missing. For example, on my GNU/Linux I use coc[0] on vim and bear[1], but on Hurd, I cannot use coc as it requires nodejs, as it is 'not present in t

[PATCH 3/5] I put all "developer references" on hurd/documentation.

The pages hurd and hurd/documentation both have "documentation sections". That seems a little silly. I am added a link in hurd to "developer documentation" that links to hurd/documentation. * hurd: link to hurd/documentation. * hurd/documentation: combine the documentation from both hurd and hur

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

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

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

Hello >--- /dev/null >+++ pam-1.5.3/libpam/include/path_max.h >@@ -0,0 +1,7 @@ >+/* >+ * Define PATH_MAX if not available >+ */ >+ >+#ifndef PAH_MAX There's a typo here ^ >+#define PATH_MAX 4096 >+#endif Cheers

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

--- Begin Message --- Index: pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c === --- pam-1.5.3.orig/modules/pam_nologin/tst-pam_nologin-retval.c +++ pam-1.5.3/modules/pam_nologin/tst-pam_nologin-retval.c @@ -182,9 +182,17 @@ m

Re: [PATCH] templates: Start pci-arbiter before acpi on Hurd

On Sat, Jul 01, 2023 at 02:55:48PM +0200, Samuel Thibault wrote: > acpi actually needs to access PCI, while pci-arbiter will not be making > use of ACPI, so we need to start acpi first. > > Signed-off-by: Samuel Thibault Reviewed-by: Daniel Kiper Daniel

[PATCH] templates: Start pci-arbiter before acpi on Hurd

acpi actually needs to access PCI, while pci-arbiter will not be making use of ACPI, so we need to start acpi first. Signed-off-by: Samuel Thibault diff --git a/util/grub.d/10_hurd.in b/util/grub.d/10_hurd.in index b317a4b14..7d1e46391 100644 --- a/util/grub.d/10_hurd.in +++ b/util/grub.d/10_hur

Re: sigsp on Hurd/x86_64

Hello, On Fri, May 12, 2023 at 10:15 PM Bruno Haible wrote: > make no sense to me. After this statement, sigsp is > either 0x > or 0x0010. > > If aligning SP is intended, the line should read > > sigsp = (void *) ((uintptr_t) sigsp & -16UL); Indeed -- thank you

sigsp on Hurd/x86_64

Hi, In the file glibc/sysdeps/mach/hurd/x86/trampoline.c lines 199..204 #ifdef __x86_64__ /* Align SP at 16 bytes. Coupled with the fact that sigreturn_addr is 16-byte aligned within the stackframe struct, this ensures that it ends up on a 16-byte aligned address, as required by the

Rust on Hurd GSoC (Was: Prospectives)

Hello Vedant, So the assignment is now official, congrats and welcome! So now begins the bonding period. This is the time to get acquainted with the communication channels of the projects. You should subscribe to the bug-hurd mailing list, and it would be useful that you come to the #hurd channel

Bug#1022563: perl: FTBFS on hurd-i386: op/stat.t fails

Package: perl Version: 5.36.0-4 Severity: normal Hello, On hurd-i386, op/stat.t fails like this: not ok 36 - ls and -b agreeing on /dev (0 310) # Failed test 36 - ls and -b agreeing on /dev (0 310) at op/stat.t line 323 # got "0" # expected "310" # = before # total

[PATCH]: Fix static-pie on Hurd target

When linking with -static-pie, we need to use rcrt0.o (and grcrt0.o for -pg). Also, set static:crt0.o before pie:Scrt1.o, otherwise -static -pie fails to link with Scrt1.o due to missing _DYNAMIC symbol. Also, -static-pie needs crtbeginS.o (otherwise it contains a relocation in read-only .text).

Re: [PATCH] templates: Add support for acpi on Hurd

On Mon, Sep 26, 2022 at 09:51:32PM +0200, Samuel Thibault wrote: > This adds acpi as bootstrap module whenever it is available. This opens the > path for proper IRQ routing for fully-userland disk drivers. > > Signed-off-by: Samuel Thibault Reviewed-by: Daniel Kiper Daniel

Re: doxygen: FTBFS on hurd-i386

Control: forwarded -1 https://github.com/doxygen/doxygen/pull/9514 Svante Signell, le mer. 28 sept. 2022 17:40:32 +0200, a ecrit: > Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue. This issue was already forwarded upstream on https://github.com/doxygen/doxygen/pull/9514 they said it

Re: doxygen: FTBFS on hurd-i386

Svante Signell, le mer. 28 sept. 2022 18:09:58 +0200, a ecrit: > On Wed, 2022-09-28 at 17:50 +0200, Samuel Thibault wrote: > > Control: forwarded -1 https://github.com/doxygen/doxygen/pull/9514 > > > > Svante Signell, le mer. 28 sept. 2022 17:40:32 +0200, a ecrit: > > > Currently doxygen FTBFS on

Re: doxygen: FTBFS on hurd-i386

On Wed, 2022-09-28 at 17:50 +0200, Samuel Thibault wrote: > Control: forwarded -1 https://github.com/doxygen/doxygen/pull/9514 > > Svante Signell, le mer. 28 sept. 2022 17:40:32 +0200, a ecrit: > > Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue. > > This issue was already forwarded u

socat: FTBFS on hurd-i386

Source: socat Version: 1.7.4.3-3 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Cc: bug-hurd Hi, Currently socat FTBFS on GNU/Hurd due to differing values for O_RDONLY, O_WRONLY and O_RDWR compared to Linux systems. The attached patch, xioinitialize.c.patch, f

doxygen: FTBFS on hurd-i386

Source: doxygen Version: 1.9.4-3 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, Currently doxygen FTBFS on GNU/Hurd due to a PATH_MAX issue. The attached patch, filesystem_filesystem.hpp.diff, fixes the build problem by special-casing for Hurd. In fact the

[PATCH] templates: Add support for acpi on Hurd

This adds acpi as bootstrap module whenever it is available. This opens the path for proper IRQ routing for fully-userland disk drivers. Signed-off-by: Samuel Thibault diff --git a/util/grub.d/10_hurd.in b/util/grub.d/10_hurd.in index 4294bbe4c..a021d02c2 100644 --- a/util/grub.d/10_hurd.in +++

Re: rump on hurd fixed

Damien Zammit, le sam. 19 févr. 2022 07:32:32 +, a ecrit: > My understanding is that vm_allocate_contiguous() in gnumach now honours the > pmax variable > by providing a contiguous allocation of physical memory below pmax. Yes. > However, the virtual addresses of each page may not be consecu

rump on hurd fixed

Hi all, It seems that with the following two commits on gnumach and hurd: http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=6951d552749fe24d0c9514ac6efec2c09e567b8d http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=258b45cde4d48149e410012b06bf2071dbba21b4 rumpdisk is now worki

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

Hi, Jess     You are right, after I pushed this patch to the upstream repository and the maintainer merged it.     He gave me an reply saying the `stropts.h` now seemed meaningless since most major platforms do not support it, so does GNU Hurd. These lines will be completely removed in the

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

On 9 May 2021, at 14:56, hahawang wrote: > > Package: gftp > Severity: important > Version: 2.7.0b-1 > Tags: ftbfs,patch > User:hahawang > Usertags: hurd,hurd-i386 > X-Debbugs-CC:debian-h...@lists.debian.org,bug-hurd@gnu.org > > I decide to fix a broken package found at the recommended > page(h

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

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

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

Hello, hahawang, le dim. 09 mai 2021 21:56:58 +0800, a ecrit: > @@ -60,7 +60,7 @@ > >  #elif HAVE_GRANTPT > > -#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) || > defined(__linux__)) > +#if !(defined(__FreeBSD__) || defined(__NetBSD__) || defined(__APPLE__) || > defined(

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

I am sorry for the unindented patch file,  due to the thunderbird mail client(or may be I do not know how to use it correctly), so I decide to reply it with a correctly indented patch file. --- hahawang --- a/lib/pty.c +++ b/lib/pty.c @@ -60,7 +60,7 @@  #elif HAVE_GRANTPT -#if !(defined(__

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

Package: gftp Severity: important Version: 2.7.0b-1 Tags: ftbfs,patch User:hahawang Usertags: hurd,hurd-i386 X-Debbugs-CC:debian-h...@lists.debian.org,bug-hurd@gnu.org I decide to fix a broken package found at the recommended page(https://people.debian.org/~sthibault/out_of_date.txt)named `gftp`

Re: Fwd: [PATCH]libtorrent: FTBFS on hurd-i386: error: 'IPV6_TCLASS' was not declared in this scope.

haha wang, le ven. 30 avril 2021 16:49:24 +0900, a ecrit: >   It might be reasonable to define the `IPV6_TCLASS` with what the > linux does, Usually the Hurd rather follows the BSD values. (and the pfinet stack just follows that, even if that's the Linux code). >    Disabling the usage o

Fwd: [PATCH]libtorrent: FTBFS on hurd-i386: error: 'IPV6_TCLASS' was not declared in this scope.

`gpsd/netlib.c` in github (link:https://github.com/ukyg9e5r6k7gubiekd6/gpsd/blob/master/netlib.c).  It says, ``` /* work around the unfinished ipv6 implementation on hurd andOSX <10.6 */ #ifndef IPV6_TCLASS # if defined(__GNU__)    #  define IPV6_TCLASS

Re: [PATCH]libtorrent: FTBFS on hurd-i386: error: 'IPV6_TCLASS' was not declared in this scope.

On 29 Apr 2021, at 12:48, haha wang wrote: > > Package: libtorrent > Severity: important > Version: 0.13.8-2 > Tags: patch > User:hahw...@yandex.com > Usertags: hurd > X-Debbugs-CC: debian-h...@lists.debian.org > > > I decide to fix a broken package found at the recommended page > https://pe

[PATCH]libtorrent: FTBFS on hurd-i386: error: 'IPV6_TCLASS' was not declared in this scope.

Package: libtorrent Severity: important Version: 0.13.8-2 Tags: patch User:hahw...@yandex.com Usertags: hurd X-Debbugs-CC: debian-h...@lists.debian.org  I decide to fix a broken package found at the recommended page https://people.debian.org/~sthibault/out_of_date2.txt named `libtorrent`.       Aft

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

issues? You need to send them upstream. Mesa is also carrying a patch which is basically useless since it again fails to build on hurd due to other issues. -- t

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

Svante Signell, le mar. 27 avril 2021 01:04:30 +0200, a ecrit: > On Mon, 2021-04-26 at 23:43 +0200, Samuel Thibault wrote: > > For information, your patch got dropped because of #975658 > > Yes I know since a long time. Ok, I hadn't seen it. > And you did not care or anybody else either. Well,

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

On Mon, 2021-04-26 at 23:43 +0200, Samuel Thibault wrote: > Hello Svante, > > For information, your patch got dropped because of #975658 Yes I know since a long time. And you did not care or anybody else either. So why bother... Why spend time on worthless issues?

Re: posix_spawn[p] less secure on Hurd than on Linux

Hello, Bruno Haible, le jeu. 24 déc. 2020 02:54:28 +0100, a ecrit: > this misfeature was withdrawn from glibc in > > and > . > > But the test p

Re: posix_spawn[p] less secure on Hurd than on Linux

Thanks for reporting Bruno! Pointing out issues with GNU/Hurd's glibc is super helpful! -- Joshua Branson Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as

posix_spawn[p] less secure on Hurd than on Linux

Hi, In glibc versions < 2.15, posix_spawn and posix_spawnp did execute a script (with execution bits set) even if it did not start with a '#!' marker. Then, /bin/sh was used as an interpreter. You can imagine how easily a text file, which happens to set execution bits set because it was copied fr

Re: /proc/self/fd support on Hurd

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

Re: /proc/self/fd support on Hurd

Svante Signell, le mar. 11 févr. 2020 17:59:12 +0100, a ecrit: > Sorry, that was a Linux system. On hurd: > ls -l /proc/self/fd/ I don't have such a directory on a Hurd system. > total 0 Note that getting the list of fds is not supported, but if you ls /dev/fd/0 for instance

Re: /proc/self/fd support on Hurd

this functionality today? > > > > There are already symlinks there: > > Are you really looking at a hurd system? > > > ls -l /dev/pts/ > > total 0 > > crw--w 1 srs tty 136, 0 Feb 11 14:38 0 > > crw--w 1 srs tty 136, 1 Feb 11 17:39 1 > > c- 1 root root 5, 2 Dec 13 11:55 ptmx > > There is no ptmx support on GNU/Hurd yet. Sorry, that was a Linux system. On hurd: ls -l /proc/self/fd/ total 0 ls -l /dev/fd total 0

Re: /proc/self/fd support on Hurd

Svante Signell, le mar. 11 févr. 2020 17:42:18 +0100, a ecrit: > On Tue, 2020-02-11 at 06:16 -0800, Samuel Thibault wrote: > > Florian Weimer, le mar. 11 févr. 2020 15:06:43 +0100, a ecrit: > > > > Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit: > > > > > Florian Weimer, le mar. 11

Re: /proc/self/fd support on Hurd

On Tue, 2020-02-11 at 06:16 -0800, Samuel Thibault wrote: > Florian Weimer, le mar. 11 févr. 2020 15:06:43 +0100, a ecrit: > > > Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit: > > > > Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit: > > > > > Does Hurd support /proc/s

Re: /proc/self/fd support on Hurd

Florian Weimer, le mar. 11 févr. 2020 15:06:43 +0100, a ecrit: > > Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit: > >> Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit: > >> > Does Hurd support /proc/self/fd, in the sense that the POSIX functions > >> > in glibc (such

Re: /proc/self/fd support on Hurd

* Samuel Thibault: > Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit: >> Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit: >> > Does Hurd support /proc/self/fd, in the sense that the POSIX functions >> > in glibc (such as openat) can deal with such paths? >> >> Not yet

Re: /proc/self/fd support on Hurd

Samuel Thibault, le mar. 11 févr. 2020 05:47:30 -0800, a ecrit: > Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit: > > Does Hurd support /proc/self/fd, in the sense that the POSIX functions > > in glibc (such as openat) can deal with such paths? > > Not yet but that could be added qu

Re: /proc/self/fd support on Hurd

Hello, Florian Weimer, le mar. 11 févr. 2020 14:39:23 +0100, a ecrit: > Does Hurd support /proc/self/fd, in the sense that the POSIX functions > in glibc (such as openat) can deal with such paths? Not yet but that could be added quite easily with some magic translation. Samuel

/proc/self/fd support on Hurd

Does Hurd support /proc/self/fd, in the sense that the POSIX functions in glibc (such as openat) can deal with such paths? Thanks, Florian

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

Ping On Wed, 2017-12-27 at 23:36 +0100, Svante Signell wrote: > On Tue, 2017-12-26 at 09:40 +0100, Héctor Orón Martínez wrote: > > Hello Svante, > > > > On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell > > wrote: > > > Hello, > > > > > > These patches was submitted to Debian November 13 2017. No

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

On Tue, 2017-12-26 at 09:40 +0100, Héctor Orón Martínez wrote: > Hello Svante, > > On Sat, Dec 23, 2017 at 7:41 PM, Svante Signell > wrote: > > Hello, > > > > These patches was submitted to Debian November 13 2017. Nothing has > > happened so far, so maybe upstream would be interested to conside

Re: Bug#881569: [Fwd: gdb: FTBFS on hurd-i386]

age -- > From: Svante Signell > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Mon, 13 Nov 2017 04:31:34 +0100 > Subject: gdb: FTBFS on hurd-i386 > Source: gdb > Version: 8.0-1 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > User

[Fwd: gdb: FTBFS on hurd-i386]

Hello, These patches was submitted to Debian November 13 2017. Nothing has happened so far, so maybe upstream would be interested to consider the patches for next release. Thanks! --- Begin Message --- Source: gdb Version: 8.0-1 Severity: important Tags: patch User: debian-h...@lists.debian.org

Re: flock() LOCK_UN support on Hurd

Hello, Amos Jeffries, on jeu. 23 nov. 2017 04:51:24 +1300, wrote: > I am facing a small portability issue on Hurd. Specifically missing > definition of LOCK_UN for use as flock() parameter when compiling > <http://bazaar.launchpad.net/~squid/squid/4/view/head:/src/base/File.h> &

flock() LOCK_UN support on Hurd

I am facing a small portability issue on Hurd. Specifically missing definition of LOCK_UN for use as flock() parameter when compiling <http://bazaar.launchpad.net/~squid/squid/4/view/head:/src/base/File.h> There seems to be work from 2001/2002 and a GSoC from 2014 making patches, but th

Re: Bug#802593: gcl: FTBFS on hurd-i386

Greetings! One other datum -- commands run fine under rpctrace, but not without. Take care, Svante Signell writes: > On Thu, 2015-10-22 at 11:30 +0200, Svante Signell wrote: >> Hi, >> Cc: bug-hurd >> > >> Running your test program at >> https://lists.debian.org/debian-hurd/2013/07/msg00038.h

Re: Bug#802593: gcl: FTBFS on hurd-i386

Greetings! Are you still working on hurd? The problem appears to have shifted with recent hurd updates. GCL no longer builds. There is an untrappable segfault on running gcc via system() which I cannot isolate in gdb. Suggestions? Take care, Svante Signell writes: > On Thu, 2015-10-22

Re: Warning: glibc-2.22-6 is broken on Hurd

Svante Signell, on Tue 19 Apr 2016 11:46:18 +0200, wrote: > As seen on #hurd: > > starting /hurd/startup fails: > "Unexpected error: Invalid argument" The fixed 2.22-7 just got accepted, it'll land on mirrors within ~6-12h. Samuel

Warning: glibc-2.22-6 is broken on Hurd

As seen on #hurd: starting /hurd/startup fails: "Unexpected error: Invalid argument"

Re: Bug#753791: Java failures in packs on hurd-i386... [Bug#753791: simgrid: FTBFS on hurd-i386]

Hi! On Sun, 31 Aug 2014 18:41:41 +0200, Samuel Thibault wrote: > Matthias Klose, le Sun 31 Aug 2014 18:39:21 +0200, a écrit : > > Am 31.08.2014 um 03:10 schrieb Samuel Thibault: > > > guess that will just fix all our issues... I'll then commit that and > > > push upstream. > > > > is this nece

Re: Calculating correct values of mem_top, mem_range, stack_address, stack_direction and page_width for gcl on Hurd

Svante Signell, on Thu 05 Nov 2015 11:02:07 +0100, wrote: > Unfortunately some values are wrong for GNU/Hurd. In order to hardcode > them (to see if the application packages like maxima can run properly) > I need to know the correct/safe (maybe empirical) values. > > On Hurd:

Calculating correct values of mem_top, mem_range, stack_address, stack_direction and page_width for gcl on Hurd

o see if the application packages like maxima can run properly) I need to know the correct/safe (maybe empirical) values. On Hurd: page_width=12 stack_direction=-1 stack_address=0xfff mem_top=0x8000 mem_range=0x4000 Empirically, with a max memory of 1980 MiB, that gives mem_top=0x7bc

Re: Bug#802593: gcl: FTBFS on hurd-i386

On Fri, 2015-10-23 at 12:00 +0200, Svante Signell wrote: > On Thu, 2015-10-22 at 10:59 -0400, Camm Maguire wrote: > > Greetings, and thanks again for your work on this! > > > > Svante Signell writes: > > > > > maxima still FTBFS at the same place. > > > > > > Seems like there are errors when ru

Re: Bug#802593: gcl: FTBFS on hurd-i386

On Thu, 2015-10-22 at 10:59 -0400, Camm Maguire wrote: > Greetings, and thanks again for your work on this! > > Svante Signell writes: > > > Update: > > hol88 builds with one manual interrupt: > > >> Makefile:36: recipe for target 'latex_type_pp.ml' failed .. > > I think you might be using an

Re: Bug#802593: gcl: FTBFS on hurd-i386

Greetings, and thanks again for your work on this! Svante Signell writes: > On Thu, 2015-10-22 at 11:30 +0200, Svante Signell wrote: >> Hi, >> Cc: bug-hurd >> > >> Running your test program at >> https://lists.debian.org/debian-hurd/2013/07/msg00038.html >> on a recent kernel gives an even low

Re: Bug#802593: gcl: FTBFS on hurd-i386

xt >> upload. >> >> Do you work on Hurd? There are several FTBFS errors in gcl dependencies >> (maxima,hol88,axiom,acl2) which I have been unable to resolve and appear >> to point to bugs in system libraries (as did the old FTBFS for gcl in >> which calls to sy

Re: Bug#802593: gcl: FTBFS on hurd-i386

On Thu, 2015-10-22 at 11:30 +0200, Svante Signell wrote: > Hi, > Cc: bug-hurd > > Running your test program at > https://lists.debian.org/debian-hurd/2013/07/msg00038.html > on a recent kernel gives an even lower limit for memory fragmentation. > 0x7000 fails now, and I used 0x6b00 in th

Re: Bug#802593: gcl: FTBFS on hurd-i386

Hi, Cc: bug-hurd On Wed, 2015-10-21 at 10:57 -0400, Camm Maguire wrote: > Greetings, and thanks for your note! Patch will be included in next > upload. > > Do you work on Hurd? There are several FTBFS errors in gcl dependencies > (maxima,hol88,axiom,acl2) which I have been un

Re: Problem with natively built binaries on Hurd from Guix

Hi Manolis, I just remembered how I addressed it when I cross-built the Hurd with Nix: Given that libc.so is an ld script on GNU/Hurd, simply add libhurduser.so and libmachuser.so in there, next to libc.so.0.3 (see

Problem with natively built binaries on Hurd from Guix

Hello guys, I asked the same question yesterday in the irc, but I thought I should repost it to the mailing list so more people can see it. When I try to run the binaries, I get "error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory" li

Re: GNUstep TalkSoup running on HURD

Hi, Samuel Thibault wrote: Indeed! And sometimes it is nice to congrat people on the achievement, so let me say "well done!":) indeed. It is true that GNUstep hides a lot of portability issues, so once you get the core libraries to work, a decently written app is easy. But TalkSoup has its

Re: GNUstep TalkSoup running on HURD

Riccardo Mottola, le Sun 19 Apr 2015 12:43:31 +0200, a écrit : > sometimes it is nice to share success stories instead of just bugs! Indeed! And sometimes it is nice to congrat people on the achievement, so let me say "well done!" :) Samuel

GNUstep TalkSoup running on HURD

Hi, sometimes it is nice to share success stories instead of just bugs! Years ago on my blog I had a screenshot with GNUstep running on HURD on real harware with some apps, including our prototypal browser. I haven't been able in any way to get HURD running on real hardware again, ther

gcc testsuite on hurd-i386

testsuite seem to be due to libstdc++ not able to unwind over the signal trampoline on hurd-i386. Apparently gdb is not either. That'd be a very good thing to fix :) Samuel

Re: clamav failure on hurd-i386

Samuel Thibault, le Sun 24 Aug 2014 23:11:49 +0200, a écrit : > Samuel Thibault, le Sun 24 Aug 2014 22:06:42 +0200, a écrit : > > Samuel Thibault, le Sun 24 Aug 2014 21:29:57 +0200, a écrit : > > > On the technical side, what fails is the __ifsock_getsockaddr call. > > > Indeed, since the node is c

Re: clamav failure on hurd-i386

Samuel Thibault, le Sun 24 Aug 2014 22:06:42 +0200, a écrit : > Samuel Thibault, le Sun 24 Aug 2014 21:29:57 +0200, a écrit : > > On the technical side, what fails is the __ifsock_getsockaddr call. > > Indeed, since the node is created as , the ifsock translators > > tells glibc that it doesn't

Re: clamav failure on hurd-i386

Samuel Thibault, le Sun 24 Aug 2014 21:29:57 +0200, a écrit : > On the technical side, what fails is the __ifsock_getsockaddr call. > Indeed, since the node is created as , the ifsock translators > tells glibc that it doesn't have any right. The port to the translator > was gotten through a __f

Re: clamav failure on hurd-i386

Andreas Cadhalpun, le Sat 05 Jul 2014 19:54:03 +0200, a écrit : > This works fine for other architectures and also when testing in a > hurd virtual machine, so I assume there is a problem with the buildd. Mmm, does it really work in a virtual machine? It fails for me as a normal user. It does work

Re: Help on fixing pulseaudio test suite on hurd

Samuel Thibault, le Tue 19 Aug 2014 20:36:35 +0200, a écrit : > It creates thousands of threads, and it seems the stack addresses keep > going up, so we apparently have a problem of stack reuse here, so > something on the libpthread side, not the pulseaudio side. That's possibly related with the E

Re: Help on fixing pulseaudio test suite on hurd

Hello, Felipe Sateler, le Mon 18 Aug 2014 00:47:10 -0400, a écrit : > I am attempting to enable the pulseaudio test suite at package build > time. After clearing a few hurdles with upstream the package has > managed to build with tests everywhere except on the hurd[1]. So it's just once-test whic

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

Richard Braun, le Sat 28 Jun 2014 12:42:40 +0200, a écrit : > However, I'm not sure I understand why other users would rely on a > stream protocol for tokens. Right. I'd say we can keep with this for now. Samuel

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

Hi Richard, On 28.06.2014 10:48, Richard Braun wrote: Thanks for the report. There are actually two sides of the problem. First, I agree that there seems to be a bug, but let's take a closer look at the spec. The return value for recv() is defined as : "Upon successful completion, recv() shall

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

I'm inclined to say libc is not the right place to fix this. If the user says write/send 0, what that means should be up to the io server to decide--even if all the servers we have today are intending to implement the same POSIX semantics.

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

On Sat, Jun 28, 2014 at 12:42:40PM +0200, Richard Braun wrote: > I'll see if simply catching completely empty messages at socket_send is > a good enough solution. The solution seems to work, and I couldn't see anything against it, unlike the previous attempt. However I'd really like to put it into

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

> > This is because the client is calling: > > > > send(sockfd, "", 0, 0) > > > > > > > > Normally this doesn't trigger recv() in the server and thus can be > > > > used to test, whether the socket is working. > >

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

ot;, 0, 0) > > > > > > Normally this doesn't trigger recv() in the server and thus can be > > > used to test, whether the socket is working. > > > But on Hurd it actually sends an empty message, so that the real > > > message, which is sent later

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

he server and thus can be > > used to test, whether the socket is working. > > But on Hurd it actually sends an empty message, so that the real > > message, which is sent later, is not received. > > Hello, > > Thanks for the report. There are actually two sides of th

Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote: > This is because the client is calling: > send(sockfd, "", 0, 0) > > Normally this doesn't trigger recv() in the server and thus can be > used to test, whether the socket is working. > But o

since: FTBFS on hurd-i386

Source: since Version: Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, Currently since fails to build from source on GNU/Hurd due to failed tests. The problem is that dev_t is an unsigned integer, i.e. 4 bytes, on Hurd but since expects dev_t to be 8

Re: Fwd: System Calls on Hurd

Please always keep the mailing list in Cc, so you optimize the chance of getting a complete answer in a minimized time. Otherwise, you run the risk of either get a terse answer, or have to wait (possibly long) that I have time to provide a lengthier answer (or simply that I come back from vacation

System Calls on Hurd

So I was reading about system calls this week and I noticed that generally we write wrappers which handle the syscalls from programs. So if a system call is encountered, it calls this wrapper which then makes calls to the kernel to perform the task. So I presume that this wrapper is glibc in Hurd,

[PATCH 7/7] sysvinit: Fix getty path in /etc/inittab on Hurd.

/changelog @@ -62,6 +62,7 @@ sysvinit (2.88dsf-42) UNRELEASED; urgency=low have /dev/root and the device ids used here are specific to Linux. * killall5.c: Use sysconf(_SC_SYMLOOP_MAX) instead of MAXSYMLINKS. Fixes build on Hurd. + * sysvinit.postinst: Fix file name of gettys in /etc

[PATCH 2/7] initscripts: add -ocompatible to procfs mounts on Hurd

/changelog @@ -52,6 +52,7 @@ sysvinit (2.88dsf-42) UNRELEASED; urgency=low [ Justus Winter ] * mount-functions.sh: Hurd has a tmpfs translator now, remove workaround. + * mount-functions.sh: Add -ocompatible to procfs mounts on Hurd. -- Roger Leigh Sat, 04 May 2013 13:13:51 +0100 diff

Re: [PATCH 8/8] sysvinit: Fix getty path in /etc/inittab on Hurd.

Alle martedì 9 luglio 2013, Justus Winter ha scritto: > diff --git a/debian/sysvinit.postinst b/debian/sysvinit.postinst > index 1750412..061f53b 100755 > --- a/debian/sysvinit.postinst > +++ b/debian/sysvinit.postinst > @@ -85,6 +85,10 @@ then > if [ ! -f /etc/inittab ] > then > cp -p /usr/s

Re: [PATCH 8/8] sysvinit: Fix getty path in /etc/inittab on Hurd.

Ivan Shmakov, le Thu 11 Jul 2013 07:38:52 +, a écrit : > > Yes, it is fixed for new installations. However, the inittab as > > shipped with the package is only installed as /etc/inittab if this > > file is non-existant. As the inittab file was formerly not used on >

Re: [PATCH 5/8] initscripts: Disable rootcheck on Hurd

b/debian/changelog > @@ -58,6 +58,8 @@ sysvinit (2.88dsf-42) UNRELEASED; urgency=low >* debian/control: Depend on a recent hurd package on hurd-any. The > initscripts require some functionality that has been implemented > only recently. > + * checkroot.sh: Disable rootcheck on

Re: [PATCH 8/8] sysvinit: Fix getty path in /etc/inittab on Hurd.

e inittab as > shipped with the package is only installed as /etc/inittab if this > file is non-existant. As the inittab file was formerly not used on > Hurd systems, it is likely that users that are upgrading are not > aware of this issue, Do I understand it correct

Re: [PATCH 8/8] sysvinit: Fix getty path in /etc/inittab on Hurd.

; /etc/inittab file in the postinstall script. > > […] > > > + * sysvinit.postinst: Fix getty path in /etc/inittab on Hurd. > > Please note that the GNU Coding Standards recommend to use the > “file name” term here instead: > > --cut: https://www.gnu.org/prep/standards/standar

Re: [PATCH 8/8] sysvinit: Fix getty path in /etc/inittab on Hurd.

>>>>> Justus Winter <4win...@informatik.uni-hamburg.de> writes: > This is essentially the same as > 89f6476d8979174f395a1bf784486254464c349d but fixes the existing > /etc/inittab file in the postinstall script. […] > + * sysvinit.postinst: Fix g

[PATCH 8/8] sysvinit: Fix getty path in /etc/inittab on Hurd.

/etc/inittab on Hurd. -- Roger Leigh Sat, 04 May 2013 13:13:51 +0100 diff --git a/debian/sysvinit.postinst b/debian/sysvinit.postinst index 1750412..061f53b 100755 --- a/debian/sysvinit.postinst +++ b/debian/sysvinit.postinst @@ -85,6 +85,10 @@ then cp -p /usr/share/sysvinit/inittab

[PATCH 5/8] initscripts: Disable rootcheck on Hurd

package on hurd-any. The initscripts require some functionality that has been implemented only recently. + * checkroot.sh: Disable rootcheck on Hurd. The concept of device ids +simply does not apply to the Hurd system. -- Roger Leigh Sat, 04 May 2013 13:13:51 +0100 diff --git

[PATCH 7/8] sendsigs, killprocs: Disable on Hurd. killall5 kills essential processes.

(_SC_SYMLOOP_MAX) instead of MAXSYMLINKS. Fixes build on Hurd. + * sendsigs: Disable script on Hurd. killall5 kills essential processes. +Temporary workaround until +http://lists.gnu.org/archive/html/bug-hurd/2006-02/msg00081.html +is addressed. + * killprocs: Likewise. -- Roger Leigh

  1   2   3   >