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

; > There's a typo here ^ > > > +#define PATH_MAX 4096 > > +#endif > > Cheers Thanks, New patch attached. Description: define PATH_MAX for compatibility when it's not already set Some platforms, such as the Hurd, don't set PATH_MAX. Set a reasonable defaul

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

uthors: Steve Langasek , Svante Signell Bug-Debian: http://bugs.debian.org/ Index: pam-1.5.3/libpam/include/path_max.h === --- /dev/null +++ pam-1.5.3/libpam/include/path_max.h @@ -0,0 +1,7 @@ +/* + * Define PATH_MAX if

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

On Thu, 2024-02-22 at 17:43 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 22 févr. 2024 17:36:15 +0100, a ecrit: > > Changes: > > ... > >  gcc-13 (13.2.0-14) experimental; urgency=medium > > * Pass -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 by > &

Are you doing this too for GNU/Hurd?

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

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

Hi Sergey. Sorry for top-posting.  This is very interesting, especially now when the Debian (GNU/Linux, GNU/Hurd) project is heading in the wrong direction. I'll take a closer look on Alpine in due time. Thanks! On Sat, 2024-01-20 at 23:03 +0300, Sergey Bugaev wrote: > Hello! > > Those of

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

On Wed, 2023-05-17 at 20:24 +0200, Janneke Nieuwenhuizen wrote: > Hi! > > With this newly patched glibc > >     https://gitlab.com/janneke/guix/-/tree/wip-hurd12 > > rumpdisk still crashes, but the good news (I guess) is that it seems to > get somewhat further, or at least it crashes

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

On Sat, 2023-05-13 at 19:01 +, jbra...@dismail.de wrote: > May 13, 2023 1:46 PM, "Sergey Bugaev" wrote: > > > On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de  > > wrote: > > > > > +Hurd developers are adding 64-bit support, and they plan to drop the > > > +32-bit support, once the 64-bit

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

On Wed, 2023-05-03 at 19:56 +0200, Samuel Thibault wrote: > Samuel Thibault, le mer. 03 mai 2023 13:09:25 +0200, a ecrit: > > Sergey Bugaev, le mer. 03 mai 2023 13:26:56 +0300, a ecrit: > > > > To put another perspective: I have been doing that less funny part for a > > > > long time already. I

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

On Tue, 2023-05-02 at 22:25 +0200, Samuel Thibault wrote: > Thanks so much to all people involved in making the 64bit port a real > thing now! Congrats to all involved in creating the 64bit port. GNU/Hurd is definitely not a dead project! Thanks!

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

On Tue, 2023-05-02 at 17:10 +0300, Sergey Bugaev wrote: > On Mon, May 1, 2023 at 8:43 PM Samuel Thibault > wrote: > > > > > > They will just *not* work with 64bit. The glue code is not ready at all, > > and I think it's really not useful to spend time on that when we have > > the rump drivers

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

Follow-up Comment #37, sr #110199 (project administration): Hello, Thank you for your reply. If I understand correctly all files under the BSD-3 licence have to contain a copy of the license text. Secondly for other licences every file has to carry a copyright and license notice. All of the

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

Follow-up Comment #35, sr #110199 (project administration): Hi again, The file COPYING in patches/PAM/hurd_no_setfsuid.diff was added by me. The text in that file is now changed to: Copyright (C) 2018 Steve Langasek. Linux-PAM is free software licensed under the 3-clause BSD license, see the

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

Follow-up Comment #33, sr #110199 (project administration): Hello, this issue seems to have a Closed status. Can somebody open it again? Thanks! ___ Reply to this item at:

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

Follow-up Comment #32, sr #110199 (project administration): Long time no see! Attached is an updated tarball of hurd-cross (hurdX): Hopefully the we are getting closer to upload now. (file #54322) ___ Additional Item Attachment: File

Re: [PATCH] Add libraries to Makefiles.

On Wed, 2023-01-18 at 12:41 +0100, Samuel Thibault wrote: > I'm not talking about libz.so, but about libstore.so. Is that > libstore.so really a shared library that has libz in NEEDED? If so > there is really no need to add -lz to linking storeio. Unless you > actually send us the actual error

Re: [PATCH] Fix some compiler warnings

On Wed, 2023-01-18 at 12:27 +0100, Samuel Thibault wrote: > Svante Signell, le mer. 18 janv. 2023 11:59:40 +0100, a ecrit: > > On Wed, 2023-01-18 at 02:02 +0100, Samuel Thibault wrote: > > > Hello, > > > > > > > > > But conversely when we'll bu

Re: [PATCH] Add libraries to Makefiles.

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

Re: [PATCH] Fix some compiler warnings

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

Re: [PATCH] Add libraries to Makefiles.

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

Re: [PATCH] Add libraries to Makefiles.

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

[PATCH] Add libraries to Makefiles.

Hi, The attached patch adds libraries needed when cross-building Hurd. Most of them arise when enabling zlib with --with-libz. Applies nicely to hurd-0.9.git20221224 and latest git. Thanks! --- hurd/boot/Makefile 2022-11-30 11:14:21.08400 +0100 +++ hurd/boot/Makefile 2022-12-02

[PATCH] Fix some compiler warnings

Hi, The attached patch fixes some format warnings as well as an implicit declaration of ‘startup_essential_task’ in mach-defpager/main.c. Applies nicely to hurd-0.9.git20221224 and latest git. Thanks! --- hurd-git/ext2fs/ext2fs.c 2022-12-08 15:05:29.80800 +0100 +++ hurd-git/ext2fs/ext2fs.c

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

Follow-up Comment #30, sr #110199 (project administration): Hi again. Is this support issue still open? If so I plan to upload an updated tarball RSN. Thanks! ___ Reply to this item at:

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

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, 

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] Uncouple netfs_make_protid (netfs_make_peropen()) function calls in Hurd.

in libdiskfs. If/when making such changes all functions and function calls would have to be modified simultaneously. Thanks! From a36202019dcc92d5b8058002ba427de3923c6a1c Mon Sep 17 00:00:00 2001 From: Svante Signell Date: Thu, 20 Jan 2022 16:11:44 +0100 Subject: [PATCH] Uncouple nested function calls

Re: Dropping gdc support?

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

Re: Dropping gdc support?

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

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

On Tue, 2021-11-30 at 22:22 +, jbra...@dismail.de wrote: > November 29, 2021 12:41 PM, "Svante Signell" > wrote: > > > Hello, > > > > I've been working lately with on how to port valgrind to GNU/Hurd, > > and found out that this is not a tr

Re: Need help with assembly code

On Mon, 2021-11-29 at 22:19 +0100, Samuel Thibault wrote: > Hello, > > Svante Signell, le lun. 29 nov. 2021 18:40:48 +0100, a ecrit: > > I've been working lately with on how to port valgrind to GNU/Hurd, and found > > out that this is not a trivial task. > > It is ind

Need help with assembly code

Hello, I've been working lately with on how to port valgrind to GNU/Hurd, and found out that this is not a trivial task. Seems like one have to make a suitable mix of linux and darwin code (and to some extent freebsd/solaris code). Being a novice on assembly programming I need some help on

RFC: Comments on patches for libdrm are welcomed

Hello, After the patches sent to the libdrm package in #909436 was removed with version 2.4.103-2 due to bug #975658 causing problems with an "Invalid read after the end of block in xf86drm.c" a year ago nothing happened. I've now taken up the patches again, and try to solve the issues of the

Re: Regarding copyright assignment to FSF

On Fri, 2021-08-13 at 18:23 +0200, Samuel Thibault wrote: > The GPLv2-only code is essentially the pfinet stack from Linux, for > which we don't have any assignment anyway. But again, this is getting > replaced by lwip. Hello. How to make lwip by default enabled instead of pfinet? Thanks :)

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

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__) ||

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?

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

Follow-up Comment #29, sr #110199 (project administration): Hello, Thanks for the heads up. A new tarball will be uploaded soon. Thanks! ___ Reply to this item at:

Re: WEXITED/WCONTINUED

On Sun, 2020-12-27 at 01:13 +0100, Samuel Thibault wrote: > Hello, > > For information, I am currently landing patches to implemented > waitid's > WEXITED/WCONTINUED/etc. Linux has in /usr/include/x86_64-linux-gnu/bits/waitflags.h: # define WEXITED4 /* Report dead child. */ #

Re: WEXITED/WCONTINUED

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

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

On Fri, 2020-12-18 at 14:02 +0100, Samuel Thibault wrote: > Svante Signell, le ven. 18 déc. 2020 13:22:12 +0100, a ecrit: > > > > It is a crash: Without gdb: > > host ftp.sunet.se > > ftp.sunet.se is an alias for sunet.ftp.acc.umu.se. > > sunet.ftp.acc

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

On Fri, 2020-12-18 at 12:12 +0100, Samuel Thibault wrote: > Svante Signell, le ven. 18 déc. 2020 11:58:53 +0100, a ecrit: > > On Thu, 2020-12-17 at 17:11 +0100, Samuel Thibault wrote: > > > BTW: Any ideas about the second crash written about in my previous > > mail that yo

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

On Thu, 2020-12-17 at 17:11 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 17 déc. 2020 15:54:28 +0100, a ecrit: > > # define CLOCK_REALTIME_COARSE 5 > > > > The problem with that option is that it is not yet supported, > > resulting in EINVAL and a c

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

Hello, Testing the command host results in time.c:118: Invalid argument timer.c:634: fatal error: RUNTIME_CHECK(isc_time_now(()) == 0) failed Aborted (core dumped) Looking into the problem reveals that bind9 is built with the wrong option clk_id for clock_gettime(): CLOCK_REALTIME_COARSE is

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

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

Re: Boot issue with e1000 netdde driver

On Sun, 2020-11-29 at 20:31 +0100, Samuel Thibault wrote: > Svante Signell, le dim. 29 nov. 2020 18:01:51 +0100, a ecrit: > > On Sun, 2020-11-29 at 14:37 +0100, Samuel Thibault wrote: > > > Richard Braun, le dim. 29 nov. 2020 14:09:56 +0100, a ecrit: > > > > Actuall

Re: Boot issue with e1000 netdde driver

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

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

Hi, After installing and running sbuild+sbuild-createchroot it failed and a lot of passive translators? are still running at /tmp/*, e.g. \rm -rf /tmp/* rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/fd': Device or resource busy rm: cannot remove '/tmp/tmp.6hFFgM37Tt/dev/vcs': Device or resource

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

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

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

On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit: > > Got it. Can some of the drivers be tested with software rendering, > > like swrast? > > software rendering does not use drm/dri. That's alread

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

On Tue, 2020-11-17 at 15:32 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 15:31:03 +0100, a ecrit: > > > > > dri cannot work. You changes in libdrm only introduced some > > > > > stub interface. Actual drm implementation is needed to

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

On Tue, 2020-11-17 at 15:22 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 15:22:02 +0100, a ecrit: > > On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote: > > > Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit: > > > > > >

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

On Tue, 2020-11-17 at 14:57 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 14:53:56 +0100, a ecrit: > > > > Which of these (and xorg* packages) are needed? > > > > > > Needed for what? > > > > For testing if some of the dri/drv

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

On Tue, 2020-11-17 at 14:22 +0100, Samuel Thibault wrote: > Svante Signell, le mar. 17 nov. 2020 11:41:52 +0100, a ecrit: > > I managed to build more packages from mesa based on that libdrm is > > now available. Is there any way to test these packages with qemu? > >

Testing direct rendering/more video cards with qemu?

Hello, I managed to build more packages from mesa based on that libdrm is now available. Is there any way to test these packages with qemu? qemu-system-x86_64 --help shows -vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none] select video card type (or is it only possible with

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

Follow-up Comment #25, sr #110199 (project administration): Hi Ineiev, Any results from your discussions with Samuel? ___ Reply to this item at:

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

Follow-up Comment #23, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

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

Follow-up Comment #22, sr #110199 (project administration): Hi again. I don't really understand what you mean by "confirm your commitment to maintain these notices in the long run". If a patch for example does not change the copyright and license information does not have to change at all. Or do

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

Follow-up Comment #20, sr #110199 (project administration): Hi again. I have now added Copyright and License information to all files where it is needed. Hopefully I have not missed any. Please let me know if I did or if there is still something missing or in need of correction. Thanks! (file

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

Follow-up Comment #18, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

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

Follow-up Comment #17, sr #110199 (project administration): Thanks for reopening #110199. I don't really understand your comment #16. Do you mean that I should add copyright and license information to all files in the patches directory? Or the ones larger than 10 lines? If that is what you mean

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

Follow-up Comment #15, sr #110199 (project administration): Please, I did submit a new tarball after sending that message. And commented on your feedback. Please reopen this issue. Thanks! ___ Reply to this item at:

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

Follow-up Comment #13, sr #110199 (project administration): ping? ___ Reply to this item at: ___ Message sent via Savannah

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

Follow-up Comment #12, sr #110199 (project administration): You are right, coreutils/coreutils-8.23-noman-1.patch does not have a license. Looking more closely at applied patches I found out that it is not needed. Just remove it from the tarball. Regrading the patches for glibc README.patches

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

Follow-up Comment #10, sr #110199 (project administration): Hi again, As explained in patches/README.patches most patches are smaller than 10 lines, and therefore does not need to have Copyright information. They are denoted SHORT in that file. The longer patches do have Copyright information:

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

Follow-up Comment #8, sr #110199 (project administration): ping! ___ Reply to this item at: ___ Message sent via Savannah

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

Follow-up Comment #7, sr #110199 (project administration): Hi again. This time I've tried to comply with all your requests of Copyright and License info. Please le me know if something is still missing. Attaching an updated tarball: hurd-cross.tar.gz. Thanks! (file #48777)

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

Follow-up Comment #6, sr #110199 (project administration): Hi Inieiev, I'll make one more effort to to comply to your requirements. If you reject the next tarball, I'll publish the project elsewhere, gitlab or github (god forgive) :( ___

Re: git-bisect results on gnumach

On Sat, 2020-04-04 at 11:27 +0200, Samuel Thibault wrote: > Svante Signell, le sam. 04 avril 2020 09:59:26 +0200, a ecrit: > > Just a follow-up: I did cherry-pick > > 572095c645ecc63285d0955fbee2f5d644ad8f88 > > on top of > > 0b3504b6db86c531e8b53b8e9aa9030db6e7235

Re: git-bisect results on gnumach

On Sat, 2020-04-04 at 09:20 +0200, Svante Signell wrote: > On Fri, 2020-04-03 at 23:45 +0200, Samuel Thibault wrote: > > Thanks! I pushed a fix. > > I tried the latest gnumach and something is still not OK: > Loading GNU Mach > Loading the Hurd ... > KVM: entry failed, h

Re: git-bisect results on gnumach

On Fri, 2020-04-03 at 23:45 +0200, Samuel Thibault wrote: > Thanks! I pushed a fix. I tried the latest gnumach and something is still not OK: Loading GNU Mach Loading the Hurd ... KVM: entry failed, hardware error 0x8021 Is bisecting not possible any longer, unless cherry picking the latest

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

Follow-up Comment #4, sr #110199 (project administration): [comment #3 comment #3:] > > [comment #2 comment #2:] > > Regarding patches in the patches directory, it does not make sense to add copyright notices. > > Why not? I have now added Copyright info to the patches directory, see

Re: git-bisect results on gnumach

On Fri, 2020-04-03 at 16:11 +0200, Svante Signell wrote: > Hello, > > After having problems to boot the cross-built Hurd from the latest > hurd/gnumach/mig git repos bisecting gnumach with git-bisect the > following bad commit was found (breaking --enable-pae accord

git-bisect results on gnumach

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

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

Follow-up Comment #2, sr #110199 (project administration): Hello, Regarding patches in the patches directory, it does not make sense to add copyright notices. Therefore I have created the README.patches file under patches. It is a lot of work to create a README.patches for every sub-directory.

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

URL: Summary: Cross-building of GNU/Hurd and additional packages Project: Savannah Administration Submitted by: gnu_srs Submitted on: Tue 18 Feb 2020 10:09:24 AM UTC Category:

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

there too. I can of course add a link to your work in README.commands as well as add that link to README.md too. Alternately, do you want me to add your name to the files having an origin of your work, like: Copyright (C) 2016 Flavio Cruz, 2019, 2020 Svante Signell Written by Flavio Cruz and Svante

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

Hello, I've created the hurd-cross (hurdX) package and submitted it as task #15548, see https://savannah.nongnu.org/task/?15548. I was asked by ine...@gnu.org if I could join "The Hurd group" with it. The project is described in the task, and I also have uploaded a tarball. The tarball is created

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. > No

Re: /proc/self/fd support on Hurd

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

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

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

On Mon, 2019-10-28 at 01:40 +0100, Samuel Thibault wrote: > There was an issue with rlock-tweak.c, revealed by the tdb testsuite: > > Index: hurd-debian/libfshelp/rlock-tweak.c > === > --- hurd-debian.orig/libfshelp/rlock-tweak.c >

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

On Sun, 2019-10-27 at 21:06 +0100, Samuel Thibault wrote: > Svante Signell, le jeu. 12 sept. 2019 10:23:55 +0200, a ecrit: > > @@ -358,6 +357,18 @@ routine file_reparent ( > > skip; /* Was: file_get_children. */ > > skip; /* Was: file_get_source. */ > >

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

file: hurd-i386/tg-WRLCK-upgrade.diff Additionally the two upstream commits are reversed by: revert-git-lockf-0.diff revert-git-fcntl64.diff If you are working with git these commits are more easily mage there. Thanks! sysdeps/mach/hurd/Changelog 2019-01-12 Svante Signell * Update copyright

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

Attached is the second part of the patches for file record locking: libnetfs_file_record_lock.patch pflocal_fs.c.patch hurd_add_RPC.patch Thanks! hurd/ChangeLog 2019-02-01 Svante Signell * Update copyright years. 2018-01-05 Svante Signell * Update copyright years. * fs.defs: Add new

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

Signell * file-lock.c: Make flock work regardless of the mode in which the file was opened. 2019-02-12 Svante Signell * file-lock.c: Comment out "Make flock work without R or W mode" 2019-02-01 Svante Signell * Update copyright years. * file-record-lock.c(diskfs_S_file_r

Re: Need help with mach_printf()

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

Re: Need help with mach_printf()

On Fri, 2019-03-08 at 11:42 +0100, Svante Signell wrote: > On Fri, 2019-03-08 at 11:39 +0100, Svante Signell wrote: > > On Fri, 2019-03-08 at 11:28 +0100, Samuel Thibault wrote: > > > Use mach_print for a start, to avoid any potential problem with vsnprintf > > > etc.

Re: Need help with mach_printf()

On Fri, 2019-03-08 at 11:39 +0100, Svante Signell wrote: > On Fri, 2019-03-08 at 11:28 +0100, Samuel Thibault wrote: > > Use mach_print for a start, to avoid any potential problem with vsnprintf > > etc. > > > > Svante Signell, le ven. 08 mars 2019 11:16:32 +0100, a e

Re: Need help with mach_printf()

On Fri, 2019-03-08 at 11:28 +0100, Samuel Thibault wrote: > Use mach_print for a start, to avoid any potential problem with vsnprintf etc. > > Svante Signell, le ven. 08 mars 2019 11:16:32 +0100, a ecrit: > > (cd libs; ln -s libtrivfs.so.0.3 libtrivfs.so.0) > > export L

Need help with mach_printf()

Hi, As written on bug-hurd IRC. Attached is the relevant code. Thanks! /* Copyright (C) 1994, 2002, 2015-2019 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the

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

On Fri, 2019-03-01 at 07:04 -0800, Samuel Thibault wrote: > Svante Signell, le lun. 25 févr. 2019 10:25:01 +0100, a ecrit: > > Unfortunately, the situation has not improved with it :( > > > > The SIGILL failures are now SIGABRT and SIGSEGV as they became with the

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

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

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

On Sat, 2019-02-02 at 14:34 +0100, Samuel Thibault wrote: > Hello, > So can you confirm my guesswork above? If, so, then only keep the first > line (the second line doesn't make sense in my guesswork), and mention > that while fcntl requires WR access for exclusive lock, flock doesn't. I've now

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

On Sat, 2019-02-02 at 14:34 +0100, Samuel Thibault wrote: > Hello, > > Thanks for the fixes! YW! > Svante Signell, le sam. 02 févr. 2019 11:52:56 +0100, a ecrit: > > On Sun, 2018-12-30 at 21:21 +0100, Samuel Thibault wrote: > > > Svante Signell, le sam. 22 déc. 2

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

the series file: #hurd-i386/git-fcntl64.diff #hurd-i386/git-lockf-0.diff #hurd-i386/tg-WRLCK-upgrade.diff Thanks! sysdeps/mach/hurd/Changelog 2019-01-12 Svante Signell * Update copyright years. 2018-12-21 Svante Signell * hurd-i386/fcntl.diff: Add the required new arguments when calling

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

Attached is the second part of the patches for file record locking: libnetfs_file_record_lock.patch pflocal_fs.c.patch hurd_add_RPC.patch Thanks! hurd/ChangeLog 2019-02-01 Svante Signell * Update copyright years. 2018-01-05 Svante Signell * Update copyright years. * fs.defs: Add new

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

entries. Thanks! libdiskfs/ChangeLog 2019-02-01 Svante Signell * Update copyright years. * file-record-lock.c(diskfs_S_file_record_lock): Don't set rendezvous to MACH_PORT_NULL. 2018-12-07 Svante Signell * Update copyright years. * dir-lookup.c(diskfs_S_dir_lookup): Call

Re: GNUstep - check for reuse address

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

Re: GNUstep - check for reuse address

On Fri, 2016-01-08 at 21:59 +0100, Svante Signell wrote: > On Fri, 2016-01-08 at 16:43 +0100, Samuel Thibault wrote: > > Pino Toscano, on Fri 08 Jan 2016 16:40:08 +0100, wrote: > > > In data venerdì 8 gennaio 2016 13:34:46, Samuel Thibault ha > > > scritto: > >

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

On Mon, 2019-01-28 at 22:43 +0100, Samuel Thibault wrote: > Svante Signell, le lun. 28 janv. 2019 21:50:50 +0100, a ecrit: > > Thread 4 hit Breakpoint 2, __GI___sigaltstack (argss=0x3005c84, oss=0x0) at > > ../sysdeps/mach/hurd/sigaltstack.c:55 > > 55 in ../sysdeps/ma

  1   2   3   4   5   6   7   8   >