about the cmsg_len type, I hadn't taken the time to
> look at the rest yet.
>
Sorry for the impatience :)
>
> I'm pushing a fix on glibc master.
>
Great, many thanks! This should make the GLib test suite pass again
(without counting the seven skipped tests).
--
Diego Nieto Cid, le mer. 01 janv. 2025 21:03:23 +, a ecrit:
> On Wed, Jan 01, 2025 at 08:07:04PM +, Diego Nieto Cid wrote:
> > On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > >
> > > > /* Structure used for storage of ancillary data object information.
> > > >
Diego Nieto Cid, le mer. 01 janv. 2025 20:07:04 +, a ecrit:
> On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > /* Structure used for storage of ancillary data object information.
> > > */
> > > struct cmsghdr
> > > {
> > > socklen_t cmsg_len;
On Wed, Jan 01, 2025 at 08:07:04PM +, Diego Nieto Cid wrote:
> On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > >
> > > /* Structure used for storage of ancillary data object information.
> > > */
> > > struct cmsghdr
> > > {
> > > socklen_t cmsg_len
On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> >
> > /* Structure used for storage of ancillary data object information. */
> > struct cmsghdr
> > {
> > socklen_t cmsg_len; /* Length of data in cmsg_data plus
> > length
> >
Diego Nieto Cid, le mar. 31 déc. 2024 20:48:08 +, a ecrit:
> On Tue, Dec 31, 2024 at 08:32:47PM +, Diego Nieto Cid wrote:
> >
> > Adding the following line to the program:
> >
> > printf("cmsghdr: %lu\n", sizeof (struct cmsghdr));
> >
> > shows 12 on Hurd and 16 on Linux. I think I'm
On Tue, Dec 31, 2024 at 08:32:47PM +, Diego Nieto Cid wrote:
>
> Adding the following line to the program:
>
> printf("cmsghdr: %lu\n", sizeof (struct cmsghdr));
>
> shows 12 on Hurd and 16 on Linux. I think I'm closer :)
The only difference in the structure definition is the cmsg_len f
On Tue, Dec 31, 2024 at 08:25:00PM +, Diego Nieto Cid wrote:
> On Tue, Dec 31, 2024 at 04:01:08PM +, Diego Nieto Cid wrote:
> >
> > Ok, I'll have a look in both OSes behaviour.
>
> There's something wrong with our CMSG_DATA macro. It produces the wrong
> output (or at least different fro
On Tue, Dec 31, 2024 at 04:01:08PM +, Diego Nieto Cid wrote:
>
> Ok, I'll have a look in both OSes behaviour.
There's something wrong with our CMSG_DATA macro. It produces the wrong
output (or at least different from Linux).
The attached program prints:
cmsg: 0x101040a90; data: 0x10104
Hi,
On Tue, Dec 31, 2024 at 02:52:53PM +0100, Samuel Thibault wrote:
>
> You should probably check precisely the difference between Linux and
> Hurd on these alignment questions at the various stages.
>
I placed a `g_message` call in `g_unix_credentials_message_deserialize` and
on Linux it does
On Tue, Dec 31, 2024 at 02:52:53PM +0100, Samuel Thibault wrote:
> Samuel Thibault, le mar. 31 déc. 2024 14:36:02 +0100, a ecrit:
> > > I'm not sure how to fix it. Should the expectations of GLib be updated
> > > to be aligned? Like below:
> > >
> > > - if (size != G_CREDENTIALS_NATIVE_SIZE)
> > >
Samuel Thibault, le mar. 31 déc. 2024 14:36:02 +0100, a ecrit:
> > I'm not sure how to fix it. Should the expectations of GLib be updated
> > to be aligned? Like below:
> >
> > - if (size != G_CREDENTIALS_NATIVE_SIZE)
> > + if (size != CMSG_ALIGN(G_CREDENTIALS_NATIVE_SIZE))
> >
> > Or should the
Diego Nieto Cid, le mar. 31 déc. 2024 02:47:35 +, a ecrit:
> On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
> >
> > Here are the results for `hurd-amd64`:
> >
> > $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> > -pthread cred_size.c -lgi
On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
>
> Here are the results for `hurd-amd64`:
>
> $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> -pthread cred_size.c -lgio-2.0 -lgobject-2.0 -lglib-2.0 \
> -o cred_size
>
> $ ./cred_s
On Sun, Dec 29, 2024 at 11:33:47PM +0100, Samuel Thibault wrote:
>
> See the error test, it's about G_CREDENTIALS_NATIVE_SIZE, see its
> definition:
>
> #define G_CREDENTIALS_NATIVE_SIZE (sizeof (struct cmsgcred))
>
> And the definition of struct cmsgcred in bits/soc
Hello,
Sergey Bugaev, le lun. 30 déc. 2024 16:44:24 +0300, a ecrit:
> This feels like an opportunity to remind everyone that the SCM_CREDS
> implementation, which is shipped as a Debian downstream patch, doesn't
> actually verify the credentials. I have posted a more detailed
> description [0] bac
1]
> > > https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gunixcredentialsmessage.c?ref_type=heads#L115
> > >
> > > It seems to be some structure size issue on amd64 (i386 tests don't fail)
> > > regarding
> > > SCM_CREDS implementation.
&
t; > It seems to be some structure size issue on amd64 (i386 tests don't fail)
> > regarding
> > SCM_CREDS implementation.
>
> See the error test, it's about G_CREDENTIALS_NATIVE_SIZE, see its
> definition:
>
> #define G_CREDENTIALS_NATIVE_SIZE (sizeof (str
alize
> (which
> can be seen here[1]).
> [1]
> https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gunixcredentialsmessage.c?ref_type=heads#L115
>
> It seems to be some structure size issue on amd64 (i386 tests don't fail)
> regarding
> SCM_CREDS imp
ction g_unix_credentials_message_deserialize (which
can be seen here[1]).
It seems to be some structure size issue on amd64 (i386 tests don't fail)
regarding
SCM_CREDS implementation. But I couldn't debug the test because they are run
from
complicated shell scripts :(
Two patches to the test runner needs to be a
Hello,
Diego Nieto Cid, le mer. 04 déc. 2024 09:57:08 -0300, a ecrit:
> Thanks for making sense of my gibberish :-)
> So, once the fix lands in hurd/glibc packages we can drop the debian
> patch and fix upstream (libzstd)
That's now uploaded indeed.
Samuel
Samuel Thibault, le mer. 04 déc. 2024 14:31:32 +0100, a ecrit:
> Diego Nieto Cid, le mer. 04 déc. 2024 10:28:45 -0300, a ecrit:
> > This is weird, just run the build, twice, and no test failed. It's
> > probably caused by some temporary state of the buildd.
> >
> &
Hi,
This is weird, just run the build, twice, and no test failed. It's
probably caused by some temporary state of the buildd.
Can we attempt a build again?
Thanks
Diego Nieto Cid, le mer. 04 déc. 2024 10:28:45 -0300, a ecrit:
> This is weird, just run the build, twice, and no test failed. It's
> probably caused by some temporary state of the buildd.
>
> Can we attempt a build again?
Sure, scheduled so.
Thanks,
Samuel
Hey Sergey,
Thanks for making sense of my gibberish :-)
So, once the fix lands in hurd/glibc packages we can drop the debian
patch and fix upstream (libzstd)
Sergey Bugaev, le mer. 04 déc. 2024 11:56:16 +0300, a ecrit:
> On Wed, Dec 4, 2024 at 11:26 AM Samuel Thibault
> wrote:
> > It's probably worth checking other _write methods in libstore/
>
> That, and also glibc should make more efforts to be resilient against
> servers returning bogus read/writ
On Wed, Dec 4, 2024 at 11:26 AM Samuel Thibault wrote:
> It's probably worth checking other _write methods in libstore/
That, and also glibc should make more efforts to be resilient against
servers returning bogus read/write amounts, whether by mistake like
here or maliciously. If we don't saniti
Sergey Bugaev, le mer. 04 déc. 2024 06:21:13 +0300, a ecrit:
> zero_write leaves *amount unset; its UB.
Indeed, good catch you two!
It's probably worth checking other _write methods in libstore/
Samuel
On Wed, Dec 4, 2024 at 12:11 AM Diego Nieto Cid wrote:
> 52<--47(pid1044)->io_write_request ("Hello World!\n" -1) = 0 15
On Wed, Dec 4, 2024 at 4:50 AM Diego Nieto Cid wrote:
> I traced it to the function `io_write` from `libhurduser.so.3` which
> is returning 1.
On Wed, Dec 4, 2024 at 6:09
Here is some stacktrace.
--->8>8
(gdb) frame
#0 _hurd_fd_write (fd=fd@entry=0x1012dde10,
buf=buf@entry=0x2dd0, nbytes=nbytes@entry=0x10103da78,
offset=offset@entry=-1)
at ./hurd/fd-write.c:39
39 *nbytes = wrote;
(gdb) bt
#0 _hurd_fd_write (fd=fd@entry=0x1012dde10
El mar, 3 dic 2024 a las 22:50, Diego Nieto Cid () escribió:
>
> Also, it's quite difficult without the source code. I've downloaded
> glibc-source and extracted the tar.xz. How do I instruct gdb to use
> those files?
>
GDB's directory command helped in this front. I'll continue debugging :-)
El mar, 3 dic 2024 a las 18:33, Samuel Thibault
() escribió:
>
> And nothing else after that? fclose() would need to be run inside gdb to
> make sure where exactly it returns an error. Possibly it's simply
> _IO_do_flush that doesn't work for /dev/zero, but this doesn't show up
> in the RPCs above.
Diego Nieto Cid, le mar. 03 déc. 2024 18:32:07 -0300, a ecrit:
> BTW, the /dev/zero holds the following translator entry:
>
> $ showtrans /dev/zero
> /bin/nullauth -- /hurd/storeio -Tzero
Yes, that's expected.
> I'm having a hard time finding the code handling the "-Tzero"
> parameter.
Diego Nieto Cid, le mar. 03 déc. 2024 18:11:17 -0300, a ecrit:
> El mar, 3 dic 2024 a las 17:15, Samuel Thibault
> () escribió:
> >
> > Oh, that's odd indeed. Perhaps run it through rpctrace to see what
> > happens behind.
> >
>
> I attached the rpctrace log. I'm not sure what to look for but the
BTW, the /dev/zero holds the following translator entry:
$ showtrans /dev/zero
/bin/nullauth -- /hurd/storeio -Tzero
I'm having a hard time finding the code handling the "-Tzero"
parameter. But, from a quick look at the arguments of storeio, it is
readonly by default. Maybe that has somet
El mar, 3 dic 2024 a las 17:15, Samuel Thibault
() escribió:
>
> Oh, that's odd indeed. Perhaps run it through rpctrace to see what
> happens behind.
>
I attached the rpctrace log. I'm not sure what to look for but the
following lines seem relevant:
7<--38(pid1044)->dir_lookup ("dev/zero" 655
Diego Nieto Cid, le mar. 03 déc. 2024 17:11:58 -0300, a ecrit:
> El mar, 3 dic 2024 a las 12:47, Samuel Thibault
> () escribió:
> >
> > Yes, the current behavior is really odd, I don't see why zstd would try
> > to remove /dev/zero...
> >
>
> I managed to craft a small reproducer by doing the foll
El mar, 3 dic 2024 a las 12:47, Samuel Thibault
() escribió:
>
> Yes, the current behavior is really odd, I don't see why zstd would try
> to remove /dev/zero...
>
I managed to craft a small reproducer by doing the following steps:
1. open /dev/zero
2. write something into it
3. close it
H
p : 0.04% ( 64.0 KiB => 24 B, /dev/zero)
> zstd: /dev/zero: Success
> zstd: Refusing to remove non-regular file /dev/zero
>
> The proper fix for this test, I presume, would be to make it work with
> /dev/zero and remove the special case from the test scri
ot;$UNAME" in
> > GNU) DEVDEVICE="/dev/random" ;;
> > *) DEVDEVICE="/dev/zero" ;;
>
> Possibly the -o option is using DEVDEVICE while it should be useing
> INTOVOID? (and that wasn't noticed on linux just because it's 666 there)
>
DEV
> > non-root?
>
> It's testing that a non regular file doesn't fail and rather continues
> silently. Not sure why the wouldn't want to error out in such cases
> :shrug:
>
> The device node is picked earlier in the test script [1]:
>
> INTOVOID=&qu
wouldn't want to error out in such cases
:shrug:
The device node is picked earlier in the test script [1]:
INTOVOID="/dev/null"
case "$UNAME" in
GNU) DEVDEVICE="/dev/random" ;;
*) DEVDEVICE="/dev/zero" ;;
esac
>
> An
Diego Nieto Cid, le mar. 03 déc. 2024 11:10:57 -0300, a ecrit:
> which produce the following piece of logs:
>
> $ cat tests/tmplog
> + '[' -z '' ']'
> + ../programs/zstd tmp -f -o /dev/random
> zstd: /dev/random: Permission denied
Eh? Why writing to random? What sense is this supp
Hello,
I was looking at the buildd failures of libzstd to try to fix it. It
compiles fine but one of the tests (so far...) fails to run
properly[1]:
test : should quietly not remove non-regular file
make[2]: *** [Makefile:352: test-zstd] Error 1
make[2]: Leaving directory '/<
On Fri, Nov 22, 2024 at 5:11 PM wrote:
> Sounds awfully familiar...so is this a compiler bug?
What, did you think if was *my* code that's broken? :D :D :D
> How should I go
> forward here?
Most importantly, please report this to GCC developers.
You could use the preprocessed source so they don
Sergey Bugaev writes:
> On Fri, Nov 22, 2024 at 4:28 PM wrote:
>> using the (amazing) command-line that glibc creates
>>
>> --8<---cut here---start->8---
>> $ x86_64-pc-gnu-gcc ../sysdeps/mach/hurd/x86_64/sigreturn.c -c
[..]
>
> You could now make use of this
On Fri, Nov 22, 2024 at 4:28 PM wrote:
> using the (amazing) command-line that glibc creates
>
> --8<---cut here---start->8---
> $ x86_64-pc-gnu-gcc ../sysdeps/mach/hurd/x86_64/sigreturn.c -c -std=gnu11
> -fgnu89-inline -g -O2 -Wall -Wwrite-strings -Wundef -fm
efs (__mach_task_self (), reply_port,
MACH_PORT_RIGHT_RECEIVE, -1);
asm ("nop"); asm ("nop"); asm ("nop");
THREAD_SETMEM (THREAD_SELF, reply_port, sc_reply_port);
asm ("nop"); asm ("nop"); asm ("nop"); a
c_reply_port);
in the source code. The other one doesn't do this, and seems to
clobber %edx without saving it.
> Note: on our 32bit Hurd which uses the same patch set for glibc, the
> test runs fine. For now I have disabled running check on
> findutils...but I'm afraid th
Hi!
The attached test-sig.c is a slightly modified version of
gnulib-tests/test-sigaction.c
(<https://git.savannah.gnu.org/cgit/gnulib.git/tree/tests/test-sigaction.c>)
as used by findutils.
When compiled statically on Debian/Hurd with Debian's glibc it succeeds
but when using Gui
open_issues/smp.mdwn: I copied a guide that Damien email to the Hurd
that explains how one might use his smp.c code to test the Hurd's
current SMP support.
---
open_issues/smp.mdwn | 59 +---
1 file changed, 56 insertions(+), 3 deletions(-)
diff --
Luca Dariz, le mer. 21 août 2024 18:36:16 +0200, a ecrit:
> * tests/test-machmsg.c: add two use cases used by glibc during signal
> handling
> * tests/include/testlib.h
> * tests/testlib.c: add new wait_thread_terminated() helper
Applied, thanks!
> ---
> tests/incl
* tests/test-machmsg.c: add two use cases used by glibc during signal
handling
* tests/include/testlib.h
* tests/testlib.c: add new wait_thread_terminated() helper
---
tests/include/testlib.h | 1 +
tests/test-machmsg.c| 80 +
tests/testlib.c
Applied, thanks!
Flavio Cruz, le mer. 03 juil. 2024 21:38:43 +0100, a ecrit:
> We need to expose the function declarations in mig_support.h.
>
> Also fix test setup to work well in cases the build directory is not
> inside the source directory.
> ---
> tests/bad/Makefile.a
We need to expose the function declarations in mig_support.h.
Also fix test setup to work well in cases the build directory is not
inside the source directory.
---
tests/bad/Makefile.am | 2 +-
tests/generate-only/Makefile.am | 2 +-
tests/good/Makefile.am| 2
of ursp) in one place.
Applied, thanks!
> This tests generating and handling exceptions, thread_get_state(),
> thread_set_state(), and newly added thread_set_self_state(). It does
> many of the same things that glibc does when handling a signal.
> ---
&
ptions, thread_get_state(),
thread_set_state(), and newly added thread_set_self_state(). It does
many of the same things that glibc does when handling a signal.
---
tests/test-thread-state.c | 215 ++
tests/user-qemu.mk| 3 +-
2 files changed, 217 insertions(+), 1 de
Samuel Thibault, le mar. 16 avril 2024 02:59:39 +0200, a ecrit:
> Sergey Bugaev, le lun. 15 avril 2024 12:01:49 +0300, a ecrit:
> > This tests generating and handling exceptions, thread_get_state(),
> > thread_set_state(), and newly added thread_set_self_state(). It does
> > many of the same thing
Sergey Bugaev, le lun. 15 avril 2024 12:01:49 +0300, a ecrit:
> This tests generating and handling exceptions, thread_get_state(),
> thread_set_state(), and newly added thread_set_self_state(). It does
> many of the same things that glibc does when handling a signal.
> ---
> Note that I only teste
This tests generating and handling exceptions, thread_get_state(),
thread_set_state(), and newly added thread_set_self_state(). It does
many of the same things that glibc does when handling a signal.
---
Note that I only tested this on i386 and AArch64, not on x86_64.
tests/test-thread-state.c
n enhanced to support nowadays' SMP standards like ACPI.
>
> -[[!tag open_issue_gnumach open_issue_xen]]
> +However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue
> +code isn't SMP-safe so build with --disable-linux-groups to test SMP and use
> +rumpdis
t of GNU Mach, the plan is to try it
-in this enviroment first.
+recently been enhanced to support nowadays' SMP standards like ACPI.
-[[!tag open_issue_gnumach open_issue_xen]]
+However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue
+code isn't SMP-safe so build
Hi,
This program requires master branch PLUS
a one line patch I just mailed in for gnumach.
Here is a simple test program to enable
a new task to run on slave_pset processor set
containing the rest of the processors in SMP kernel.
You can compile it as a sutil in hurd/sutils:
usage must be run
ex 3ea1bc02..dd2481b0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -408,10 +408,11 @@ AC_ARG_WITH([acpica],
>[AS_HELP_STRING([--without-acpica], [disable acpica])], ,
> [with_acpica=yes])
>
> AS_IF([test "x$with_acpica" != xno], [
> - AC_CH
],
[AS_HELP_STRING([--without-acpica], [disable acpica])], , [with_acpica=yes])
AS_IF([test "x$with_acpica" != xno], [
- AC_CHECK_LIB(acpica, acpi_init, [
+ AC_CHECK_HEADER([acpi/acpi_init.h], [
HAVE_LIBACPICA=yes
libacpica_LIBS="-lacpica -lpciaccess"
-
file mode 100644
> index 0000..a18f4912
> --- /dev/null
> +++ b/socket/tst-cmsg_cloexec.c
> @@ -0,0 +1,126 @@
> +/* Smoke test for MSG_CMSG_CLOEXEC.
> + Copyright (C) 2021-2023 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
> +
> + The GNU C L
/socket/tst-cmsg_cloexec.c b/socket/tst-cmsg_cloexec.c
new file mode 100644
index ..a18f4912
--- /dev/null
+++ b/socket/tst-cmsg_cloexec.c
@@ -0,0 +1,126 @@
+/* Smoke test for MSG_CMSG_CLOEXEC.
+ Copyright (C) 2021-2023 Free Software Foundation, Inc.
+ This file is part of the GNU C
On 18/04/23 12:37, Sergey Bugaev wrote:
> Hello,
>
> On Tue, Apr 18, 2023 at 3:13 PM Adhemerval Zanella Netto wrote:
>> On 17/04/23 10:39, Sergey Bugaev via Libc-alpha wrote:
>>> Signed-off-by: Sergey Bugaev
>>
>> Add some description of what the test is
Hello,
On Tue, Apr 18, 2023 at 3:13 PM Adhemerval Zanella Netto wrote:
> On 17/04/23 10:39, Sergey Bugaev via Libc-alpha wrote:
> > Signed-off-by: Sergey Bugaev
>
> Add some description of what the test is accomplishing here.
Do you mean in the commit message? Done.
Also change
On 17/04/23 10:39, Sergey Bugaev via Libc-alpha wrote:
> Signed-off-by: Sergey Bugaev
Add some description of what the test is accomplishing here.
Some small nits below, the patch LGTM.
> ---
>
> This is an attempt to write a test, roughly based on
> sysdeps/unix/sysv/linux/t
file mode 100644
index ..9351a052
--- /dev/null
+++ b/socket/tst-cmsg_cloexec.c
@@ -0,0 +1,124 @@
+/* Smoke test for MSG_CMSG_CLOEXEC.
+ Copyright (C) 2021-2023 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can
Signed-off-by: Sergey Bugaev
---
This is an attempt to write a test, roughly based on
sysdeps/unix/sysv/linux/tst-scm_rights.c
Please tell me if this needs any changes. For instance, I opted to do
my own error checking for sendmsg/recvmsg/socketpair, but I could've
alternatively added xse
Hi!
On 2011-04-13T06:49:31-0400, Joern Rennecke wrote:
> [...]
> This Makefile is supposed to give coverage of all the main configure targets
> and notable variants that enable different config files.
> [...]
> --- contrib/config-list.mk(revision 0)
> +++ contrib/config-list.mk(revision
Applied, thanks!
Flavio Cruz, le ven. 06 janv. 2023 00:24:38 -0500, a ecrit:
> mbchk is not part of grub2 and only available on grub-legacy.
> ---
> tests/Makefrag.am | 2 +-
> tests/configfrag.ac| 2 +-
> tests/{test-mbchk.in =>
mbchk is not part of grub2 and only available on grub-legacy.
---
tests/Makefrag.am | 2 +-
tests/configfrag.ac| 2 +-
tests/{test-mbchk.in => test-multiboot.in} | 8
3 files changed, 6 insertions(+), 6 deletions(-)
rename tests/{t
Hi,
Samuel Thibault skribis:
> It seems that replying on the web interface didn't work, so replying
> again here by mail.
Weird.
> Ludovic Courtès, le mer. 26 oct. 2022 19:20:07 +0200, a ecrit:
>> ludo@childhurd ~$ mkfifo fifo
>> ludo@childhurd ~$ ls -l fifo
>> prw-r--r-- 1 ludo users 0 Oct 21
Hello,
It seems that replying on the web interface didn't work, so replying
again here by mail.
Ludovic Courtès, le mer. 26 oct. 2022 19:20:07 +0200, a ecrit:
> ludo@childhurd ~$ mkfifo fifo
> ludo@childhurd ~$ ls -l fifo
> prw-r--r-- 1 ludo users 0 Oct 21 07:08 fifo
> ludo@childhurd ~$ df ./fifo
Just a note that this patch should not have been committed to the
libgo directory. As described in libgo/README.gcc, the libgo
directory is a mirror of a repository stored elsewhere. Changes
committed directly to the gcc repo will eventually be lost. Thanks.
I'll take care of handling this patc
Nick Clifton, le jeu. 07 janv. 2021 16:49:25 +, a ecrit:
> > > In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
> > > detection of shlibpath_overrides_runpath, thus avoiding unnecessary
> > > relink.
> > > This backports it.
>
> Approved and applied.
Thanks!
Samuel
Hi Samuel,
ping?
Oops - sorry.
In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
This backports it.
Approved and applied.
Cheers
Nick
Jeff Law, le mar. 05 janv. 2021 16:04:45 -0700, a ecrit:
> Thanks. Installed.
Thanks!
Samuel
On 12/23/20 6:12 PM, Samuel Thibault wrote:
> In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
> detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
> This backports it.
>
> ChangeLog:
>
> * libtool.m4: Match gnu* along other GNU systems.
>
Hello,
Jeff Law, le lun. 04 janv. 2021 13:29:53 -0700, a ecrit:
> On 12/23/20 6:12 PM, Samuel Thibault wrote:
> > In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
> > detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
> > This backports it.
> >
> > Cha
On 12/23/20 6:12 PM, Samuel Thibault wrote:
> In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
> detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
> This backports it.
>
> ChangeLog:
>
> * libtool.m4: Match gnu* along other GNU systems.
>
ping?
Samuel
Samuel Thibault, le mer. 23 déc. 2020 20:24:52 +0100, a ecrit:
> In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
> detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
> This backports it.
>
> ChangeLog:
>
> * libtool.m4: Match gnu
In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
This backports it.
ChangeLog:
* libtool.m4: Match gnu* along other GNU systems.
* libffi/configure: Re-generate.
* libgomp/conf
In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
This backports it.
ChangeLog:
* libtool.m4: Match gnu* along other GNU systems.
bfd/ChangeLog:
* configure: Re-generate.
binutils/Ch
* tests/Makeconf.am (AM_TESTS_ENVIRONMENT): Set CC to $(TARGET_CC).
---
Hi,
When testing a cross-MIG with gnumach headers in a sysroot, the native
GCC won't be able to find them (e.g. errors about no ).
Can this be changed to test with the target compiler?
Thanks.
David
tests/Makeco
On Thu, 2015-12-17 at 07:21 +0100, Justus Winter wrote:
> Hi :)
>
> Quoting Svante Signell (2015-12-16 20:54:24)
> > I'd like to derive a test case for partial file locking with libnetfs:
> > Setting
> > up ftpfs and reading e.g. cat ftp://ftp.gnu.org/README works
Hi :)
Quoting Svante Signell (2015-12-16 20:54:24)
> I'd like to derive a test case for partial file locking with libnetfs: Setting
> up ftpfs and reading e.g. cat ftp://ftp.gnu.org/README works fine. But open()
> on
> that file returns EBADF.
If you can cat it, then open work
Hi
Since there was not may people on IRC right now who could answer I send an email
instead.
I'd like to derive a test case for partial file locking with libnetfs: Setting
up ftpfs and reading e.g. cat ftp://ftp.gnu.org/README works fine. But open() on
that file returns EBADF.
Other transl
Svante Signell, le Thu 08 Oct 2015 17:17:16 +0200, a écrit :
> cp test dir
> cp: unwritable ‘dir/test’ (mode 0444, r--r--r--); try anyway? y
> cp: cannot create regular file ‘dir/test’: Permission denied
>
> fakeroot-tcp cp test dir
> cp: cannot create regular file ‘dir/test’:
Hi,
When looking for the EACCES problems with gpsd I found the following:
This small test reveals a bug in hurd (libdiskfs/dir-lookup.c,
trans/fakeroot.c, ...?):
touch test
chmod -w test
mkdir dir
ls -ld dir
drwxr-xr-x 2 srs srs 4096 Oct 8 17:06 dir
cp test dir/
ls -l dir
-r--r--r-- 1 srs
Hello,
I have eventually applied this version:
Svante Signell, le Wed 13 May 2015 09:35:28 +0200, a écrit :
> +error_t
> +netfs_set_translator (struct iouser *cred, struct node *np,
> + char *argz, size_t argzlen)
> +{
> + return file_set_translator (netfs_node_netnode (np)->fi
Svante Signell, le Wed 13 May 2015 10:31:42 +0200, a écrit :
> On Wed, 2015-05-13 at 10:04 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Wed 13 May 2015 09:57:27 +0200, a écrit :
> > > > + return file_set_translator (netfs_node_netnode (np)->file,
> > > > + FS_T
On Wed, 2015-05-13 at 10:04 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Wed 13 May 2015 09:57:27 +0200, a écrit :
> > > + return file_set_translator (netfs_node_netnode (np)->file,
> > > + FS_TRANS_EXCL|FS_TRANS_SET,
> > > + FS_TRANS_EXCL|FS_TRAN
Samuel Thibault, le Wed 13 May 2015 09:57:27 +0200, a écrit :
> > + return file_set_translator (netfs_node_netnode (np)->file,
> > + FS_TRANS_EXCL|FS_TRANS_SET,
> > + FS_TRANS_EXCL|FS_TRANS_SET, 0,
> > + argz, argzlen,
> > +
Svante Signell, le Wed 13 May 2015 09:35:28 +0200, a écrit :
> Q: Why does it work without fakeroot-hurd?
You mean on a bare filesystem?
They use libdiskfs, which implements diskfs_S_file_set_translator, which
calls diskfs_set_translator, which is implemented by filesystems.
And the filesystems
On Wed, 2015-05-13 at 00:52 +0200, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, le Tue 12 May 2015 22:09:33 +0200, a écrit :
> > netfs_attempt_chmod() returns an error of EOPNOTSUPP and hits the
> Err, no, see what I wrote earlier: “implement the
> netfs_set_translator stub by just calling
Hello,
Svante Signell, le Tue 12 May 2015 22:09:33 +0200, a écrit :
> netfs_attempt_chmod() returns an error of EOPNOTSUPP and hits the
> fallback case calling the stub in
> libnetfs/set-get-trans.c:netfs_set_translator() returning EOPNOTSUPP.
>
> Implementing netfs_S_file_set_translator() callin
1 - 100 of 236 matches
Mail list logo
