Hello
Apr 22, 2025, 22:17 by l...@gnu.org:
>
> Can be reproduced with just this:
>
> guile -c '(open "." O_DIRECTORY)'
>
> I think ‘flags_to_mode’ in Guile returns “r” on Linux, which is fine
> because O_RDONLY is set. But on the Hurd, O_RDONLY is not set:
>
> --8<---------------cut here---------------start------------->8---
> ludo@childhurd ~$ guile -c '(pk %host-type (fcntl (open-fdes "." O_DIRECTORY)
> F_GETFL))'
>
> ;;; ("i586-pc-gnu" 0)
> --8<---------------cut here---------------end--------------->8---
>
> vs.:
>
> --8<---------------cut here---------------start------------->8---
> $ guile -c '(pk %host-type (fcntl (open-fdes "." O_DIRECTORY) F_GETFL))'
>
> ;;; ("x86_64-unknown-linux-gnu" 98304)
> --8<---------------cut here---------------end--------------->8---
>
> Long story short, O_RDONLY = 0 on Linux but it’s non-zero on the Hurd,
> so to placate ‘scm_i_fdes_is_valid’, we need to show it that the
> directory is opened with O_RDONLY:
>
>
> Tested on both systems and it seems to work.
>
> Let me know how it goes for you!
>
Thank you, this fixes the issue for me and I did not notice a difference on
Linux.
>> Finding this was a lot of trial and error (bisecting did now work
>> because of the python cross compilation failure) but sshd not showing
>> up is caught by the childhurd system test. Encountering a record ABI
>> mismatch requiring a recompile of the entire guix tree slowed this
>> down as well.
>>
>
> For the API mismatch, you could probably rebuild just the small subset
> of modules affected by this (for example, those that refer to
> <guix-configuration> if that’s what’s involved).
>
Yeah, but I was not in the mood to figure out which modules would need to be
rebuilt and just threw away all of them, but will keep this in mind. For this
my brute force method was sufficient but it would have been a lot faster with
some more tricks.
> Thanks for finding and debugging this!
>
I guess I am finding all the weird Hurd bugs lately.
>
> Ludo’.
>
