Zhaoming Luo, le sam. 03 mai 2025 21:28:08 +0800, a ecrit:
> Use 64bit mapped time values in maptime_read when the kernel and the
> mapped_time_value structure in header file time_value.h support it.
> Otherwise step back to use the 32bit time.
Applied, thanks!
Samuel
> ---
> configure.ac
Hello,
Zhaoming Luo, le sam. 03 mai 2025 12:49:56 +0800, a ecrit:
> Use 64bit mapped time values in maptime_read when possible. The 64bit
> time values in mapped time will be zero when the kernel does not support
> 64bit mapped time.
> + if (mtime->time_value.seconds == 0)
Please add
AC_CHECK_
Zhaoming Luo, le sam. 03 mai 2025 08:30:10 +0800, a ecrit:
> On Sat, May 03, 2025 at 02:21:31AM +0200, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> > > On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > > > Zhaoming Luo, le ven. 02 mai 20
On Sat, May 03, 2025 at 02:21:31AM +0200, Samuel Thibault wrote:
> Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> > On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > > Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> > > > Get the time with higher resolu
Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> > > Get the time with higher resolution from kernel using host_get_time64()
> > > when possible.
> >
> > It
On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> > Get the time with higher resolution from kernel using host_get_time64()
> > when possible.
>
> It seems there's a misunderstanding. I explained that the mapped time
> d
Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> Get the time with higher resolution from kernel using host_get_time64()
> when possible.
It seems there's a misunderstanding. I explained that the mapped time
does have 64bit precision fields, that's what I mean we want to use,
rather th
Zhaoming Luo, le ven. 02 mai 2025 18:52:49 +0800, a ecrit:
> I'm wondering if I should consider the case that host_get_time64() is not
> supported
Yes, please.
I wonder how many times I will have to repeat it: backward compatibility
is really important, otherwise people can't try to downgrade ker
Zhaoming Luo, le jeu. 01 mai 2025 18:13:46 +0800, a ecrit:
> We can have better resolution now so this comment can be removed.
Applied, thanks!
Samuel
> ---
> include/mach/time_value.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/mach/time_value.h b/include/
Hello again,
Apr 24, 2025, 19:05 by yelni...@tutamail.com:
> Hello Samuel,
>
> I haven't had much time to look into this in depth yet but I have adapted my
> initial example s.t. it doesn't need an external program for the main socket
> (please excuse my terrible C code and the formatting).
>
>
Zhaoming Luo, le mar. 29 avril 2025 17:21:05 +0800, a ecrit:
> On Tue, Apr 29, 2025 at 09:51:25AM +0200, Samuel Thibault wrote:
> >
> > What is more concerning is:
> >
> > piixide0:0:0: lost interrupt
> >
> > So the user-level interrupt mechanism should be checked.
> >
> > But overall it seems
"lspci -nn" shows the ids and names.
Then you can search the PCI device id in the rump ahci source.
Damien
Sent from Proton Mail Android
Original Message
On 29/4/25 7:21 pm, Zhaoming Luo wrote:
> On Tue, Apr 29, 2025 at 09:51:25AM +0200, Samuel Thibault wrote:
> >
> > Wh
On Tue, Apr 29, 2025 at 09:51:25AM +0200, Samuel Thibault wrote:
>
> What is more concerning is:
>
> piixide0:0:0: lost interrupt
>
> So the user-level interrupt mechanism should be checked.
>
> But overall it seems it only sees cd0, the CD drive, plugged on piixide,
> so not AHCI. Did you chec
Zhaoming Luo, le mar. 29 avril 2025 11:06:47 +0800, a ecrit:
> On Tue, Apr 29, 2025 at 02:19:30AM +, Damien Zammit wrote:
> > Hi, this is very interesting and probably indicating that we need to fix
> > race between previous servers starting up and next ones, as you mentioned.
I don't think i
On Tue, Apr 29, 2025 at 02:19:30AM +, Damien Zammit wrote:
> Hi, this is very interesting and probably indicating that we need to fix race
> between previous servers starting up and next ones, as you mentioned.
> What happens if you put a sleep(5) before rump_init() in rumpdisk, does ahci
> b
Hello Samuel,
I haven't had much time to look into this in depth yet but I have adapted my
initial example s.t. it doesn't need an external program for the main socket
(please excuse my terrible C code and the formatting).
The socket is first created nonblocking and once the first connection com
Ludovic Courtès, le lun. 21 avril 2025 16:59:03 +0200, a ecrit:
> Samuel Thibault writes:
> > dev_read starts with if (err) return err;. Various functions do not
> > define their own err variable. I don't know the original reason for
> > this, but this looks fishy to me, and local variables should
Samuel Thibault writes:
> dev_read starts with if (err) return err;. Various functions do not
> define their own err variable. I don't know the original reason for
> this, but this looks fishy to me, and local variables should probably
> always be used, patch welcome.
I wondered about that: acce
Ludovic Courtès, le lun. 21 avril 2025 00:59:00 +0200, a ecrit:
> Samuel Thibault writes:
>
> > Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit:
> >> What happens here is that reading from /dev/klog (opened with
> >> O_NONBLOCK) returns ED_WOULD_BLOCK. However Guile and its concur
Hey,
Samuel Thibault writes:
> Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit:
>> What happens here is that reading from /dev/klog (opened with
>> O_NONBLOCK) returns ED_WOULD_BLOCK. However Guile and its concurrency
>> framework (Fibers) don’t know about this error, hence the (
That's why I suggest use a simple main() and makefile. Then you link them
explicitly. Rump is linked statically I believe. It is supposed to support
dynamic linkage but I don't think I got it to work that way yet.
Damien
Sent from Proton Mail Android
Original Message
On 21
On Sun, Apr 20, 2025 at 10:49:41PM +, Damien Zammit wrote:
> Hi,
>
> Which rump libraries are you linking to? Its vital to link to the right ones.
> Part of the challenge is working out which ones.
>
It's indeed more challenging than I thought. I supposed I can see the
linked rump library us
Hello,
Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit:
> What happens here is that reading from /dev/klog (opened with
> O_NONBLOCK) returns ED_WOULD_BLOCK. However Guile and its concurrency
> framework (Fibers) don’t know about this error, hence the (non-fatal)
> backtrace, but t
Hello,
So it works as your additional test shows, but it is fragile.
Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
> b/sysdeps/mach/hurd/i386/sigreturn.c
> index ce8df8d02b..618cb74196 100644
> --- a/sysdeps/mach/hurd/i386/sigreturn.c
Hello,
yelninei--- via Bug reports for the GNU Hurd, le ven. 18 avril 2025 14:42:03
+0200, a ecrit:
> client = accept(fd, NULL, NULL);
> if (client < 0) return 1;
> fprintf(stderr, "Accepting connection\n");
> if ((fcntl(client, F_GETFL) & O_NONBLOCK) != 0)
> {
> fprintf
Hello
I fixed these and pushed it, thanks so much!
Samuel
Samuel Thibault, le ven. 11 avril 2025 02:27:04 +0200, a ecrit:
> Hello,
>
> Sorry it took me long to manage to fine time to look at this...
>
> Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> > diff --git a/sysdeps/mach/hur
Samuel Thibault, le jeu. 17 avril 2025 23:31:50 +0200, a ecrit:
> Zhaoming Luo, le lun. 10 mars 2025 16:44:09 +0800, a ecrit:
> > I haven't tested this patch again some stress tests as I don't know why
> > the `dpkg-buildpackage -B` on my qemu got stuck at:
> >
> > ```
> > ...
> > ../scripts/evalu
Hello,
Zhaoming Luo, le lun. 10 mars 2025 16:44:09 +0800, a ecrit:
> I haven't tested this patch again some stress tests as I don't know why
> the `dpkg-buildpackage -B` on my qemu got stuck at:
>
> ```
> ...
> ../scripts/evaluate-test.sh stdio-common/scanf14 $? false false >
> /home/1speaker/ap
Hello,
Sorry it took me long to manage to fine time to look at this...
Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
> b/sysdeps/mach/hurd/i386/sigreturn.c
> index ce8df8d02b..618cb74196 100644
> --- a/sysdeps/mach/hurd/i386/sigreturn
Zhaoming Luo, le jeu. 10 avril 2025 20:20:26 +0800, a ecrit:
> The option -M q35 is needed when trying rumpdisk in qemu
It would be useful to track down why, and fix the issue :)
Samuel
> ---
> hurd/rump/rumpdisk.mdwn | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/hurd/rump/
Applied, thanks!
Zhaoming Luo, le jeu. 10 avril 2025 08:55:49 +0800, a ecrit:
> ---
> hurd/running/debian/qemu_image.mdwn | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hurd/running/debian/qemu_image.mdwn
> b/hurd/running/debian/qemu_image.mdwn
> index 9984ac33..8409bc
Applied, thanks!
Etienne Brateau, le lun. 07 avril 2025 22:11:26 +0200, a ecrit:
> ---
> i386/i386/trap.c| 4 ++--
> i386/intel/pmap.c | 4 ++--
> i386/intel/read_fault.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/i386/i386/trap.c b/i386/i386/trap.c
Dear Samuel,
Thank you for your feedback.
I am in the process of polishing the GCC configuration files and I will send
them a patch for the riscv64-gnu backend shortly. It is indeed a trivial change
with no more than 100 lines.
For the Mach, I'm planning on getting a simple kprintf working an
Hello,
Hakan Candar, le sam. 05 avril 2025 13:40:01 +, a ecrit:
> I’ve been working on getting GNU Mach to compile on riscv64,
Nice :)
I don't remember if somebody did some work about this.
> Separately, I created a `riscv64-none-gnu` target for GCC and created the
> necessary backend confi
Zhaoming Luo, le jeu. 03 avril 2025 12:42:19 +0800, a ecrit:
> This is done.
Applied, thanks!
> ---
> contributing.mdwn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/contributing.mdwn b/contributing.mdwn
> index d79388ab..c9ce3c6a 100644
> --- a/contributing.mdwn
> +++ b/contributing.
Applied, thanks!
Zhaoming Luo, le mer. 02 avril 2025 17:23:54 +0800, a ecrit:
> ---
> hurd/io.defs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hurd/io.defs b/hurd/io.defs
> index 5bc399ed..4c63de36 100644
> --- a/hurd/io.defs
> +++ b/hurd/io.defs
> @@ -46,7 +46,7 @@
Applied, thanks!
Zhaoming Luo, le mer. 26 mars 2025 12:06:08 +0800, a ecrit:
> This is done.
> See:
> https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=6d91c78f0c240e3c7d81e19e85507e0aec580d6f
>
> ---
> contributing.mdwn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/contri
Applied, thanks!
Zhaoming Luo, le lun. 24 mars 2025 12:25:51 +0800, a ecrit:
> Integrate HPET so host_get_time, host_get_time64, and host_get_uptime64
> are more precise. The highest precision can be 10ns when this patch is
> applied.
>
> * i386/i386/apic.c: Implement the two high-precision clock
Applied, thanks!
Zhaoming Luo, le lun. 24 mars 2025 13:20:42 +0800, a ecrit:
> Check the availability of host_get_time64 and use it to replace
> host_get_time for CLOCK_REALTIME when it's available. Fall back to
> host_get_time if gnumach does not support host_get_time64 but the
> gnumach headers
Zhaoming Luo, le dim. 23 mars 2025 10:47:14 +0800, a ecrit:
> Check the availability of host_get_time64 and use it to replace
> host_get_time for CLOCK_REALTIME when it's available.
> case CLOCK_REALTIME:
>{
> - /* __host_get_time can only fail if passed an invalid host_t.
> +
Damien Zammit via Bug reports for the GNU Hurd, le dim. 23 mars 2025 10:20:37
+, a ecrit:
> You probably want to disable it entirely so it doesn't need to execute a
> branch condition every time it reads the timer, ie with #ifdef.
The if is precisely meant for the case where hpet is not avai
Hello,
Almost there!
Samuel
Zhaoming Luo, le dim. 23 mars 2025 18:13:55 +0800, a ecrit:
> +uint32_t
> +hpclock_get_counter_period_nsec(void)
> +{
> +if (hpet_addr != NULL)
> + return hpet_period_nsec;
> +else
> + return 0;
When hpet_addr is NULL, hpet_period_nsec will already be
Damien Zammit via Bug reports for the GNU Hurd, le dim. 23 mars 2025 08:22:23
+, a ecrit:
> I think we are assuming any machine with ACPI has HPET. This is true since
> ~2005.
Yes, but we currently still support the non-APIC case too.
Samuel
On Sun, Mar 23, 2025 at 10:20:37AM +, Damien Zammit wrote:
> You probably want to disable it entirely so it doesn't need to execute a
> branch condition every time it reads the timer, ie with #ifdef.
> This code path would be critical for timing.
Fair enough :/. Thanks :).
Zhaoming
>
>
> --
You probably want to disable it entirely so it doesn't need to execute a branch
condition every time it reads the timer, ie with #ifdef.
This code path would be critical for timing.
Damien
Sent from Proton Mail Android
Original Message
On 23/3/25 9:13 pm, Zhaoming Luo wrote:
On Sun, Mar 23, 2025 at 09:03:01AM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 23 mars 2025 13:29:47 +0800, a ecrit:
> > On Sun, Mar 23, 2025 at 12:48:52AM +0100, Samuel Thibault wrote:
> > > Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> > >
> > > > diff --git a/i386/i386
I think we are assuming any machine with ACPI has HPET. This is true since
~2005.
Damien
Sent from Proton Mail Android
Original Message
On 23/3/25 7:03 pm, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 23 mars 2025 13:29:47 +0800, a ecrit:
> > On Sun, Mar 23, 2025 at 12:
Zhaoming Luo, le dim. 23 mars 2025 13:29:47 +0800, a ecrit:
> On Sun, Mar 23, 2025 at 12:48:52AM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> >
> > > diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c
> > > index 30449c37..aa8451ac 100
On Sun, Mar 23, 2025 at 12:48:52AM +0100, Samuel Thibault wrote:
> Hello,
>
Thanks for the review
> Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
>
> > diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c
> > index 30449c37..aa8451ac 100644
> > --- a/i386/i386at/model_dep
Hello,
Zhaoming Luo, le dim. 23 mars 2025 09:50:33 +0800, a ecrit:
> Use the host_get_time64 to replace the deprecated host_get_time for
> CLOCK_REALTIME.
host_get_time64 is not always available, not with older gnumach. Please
use #if machinery like above in the monotonic case.
In general, pleas
Hello,
Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> The HPET counter is read once in every clock interrupt. When any of the
> functions used for getting time is used, the HPET counter is read again and
> the difference between these two read is multiplied by the HPET period
> and
Hi,
On Fri, Mar 14, 2025 at 12:44:02PM +, jbra...@dismail.de wrote:
> Apoligies for the click baity title...
That's the kinda mail that might've better been sent privately,
methinks.
Michael
Hello,
While at it, we'd better also fix sysdeps/mach/hurd/dup3.c the exact
same way (which will also fix dup2).
Thanks,
Samuel
Zhaoming Luo, le jeu. 06 mars 2025 06:39:04 +0800, a ecrit:
> Ignoring the return value of mach_port_mod_ref() causes the situation
> + if (err)
> +
On Mon, Mar 03, 2025 at 01:27:50PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le lun. 03 mars 2025 19:35:37 +0800, a ecrit:
> > Test 537 on Hurd opens 0x4 file discriptors and close them[0].
>
> The code is really odd.
>
> if(nitems > 0x7fff)
> nitems = 0x4;
>
> I would have
On Wed, Mar 05, 2025 at 01:12:04PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le mer. 05 mars 2025 20:07:56 +0800, a ecrit:
> > On Wed, Mar 05, 2025 at 12:38:39PM +0100, Samuel Thibault wrote:
> > > Hello,
> >
> > Thanks for the quick reply.
> > >
> > > Zhaoming Luo, le mer. 05 mars 2025 19:25
Zhaoming Luo, le mer. 05 mars 2025 20:07:56 +0800, a ecrit:
> On Wed, Mar 05, 2025 at 12:38:39PM +0100, Samuel Thibault wrote:
> > Hello,
>
> Thanks for the quick reply.
> >
> > Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > > - Run 'apt source glibc', use quilt to apply this pat
On Wed, Mar 05, 2025 at 12:38:39PM +0100, Samuel Thibault wrote:
> Hello,
Thanks for the quick reply.
>
> Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > - Run 'apt source glibc', use quilt to apply this patch and build
> > the libc package using `dpkg-buildpackage -B`. I got th
Hello,
Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> - Run 'apt source glibc', use quilt to apply this patch and build
> the libc package using `dpkg-buildpackage -B`. I got the same error as
> [0].
>
> [0]:
> https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=hurd-i38
Zhaoming Luo, le lun. 03 mars 2025 19:35:37 +0800, a ecrit:
> Test 537 on Hurd opens 0x4 file discriptors and close them[0].
The code is really odd.
if(nitems > 0x7fff)
nitems = 0x4;
I would have rather understood
if(nitems > 0x7fff)
nitems = 0x8000;
which will happ
Zhaoming Luo, le lun. 03 mars 2025 19:35:37 +0800, a ecrit:
> a dup() is executed[4]. The code line of [4] I think is where the issue
> is. We ignored return value of __mach_port_mod_refs(). In this case we
> indeed reached the limit of reference count[5],
Oops :)
This should indeed be fixed into
On Sat, Mar 01, 2025 at 12:18:05PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le sam. 01 mars 2025 19:06:52 +0800, a ecrit:
> > It checks for the total time of requesting a page under http
> > protocol[0][1]. More than 0 is needed.
> >
> > It's just too fast and our GNU Mach clock is not accura
Zhaoming Luo, le sam. 01 mars 2025 19:06:52 +0800, a ecrit:
> It checks for the total time of requesting a page under http
> protocol[0][1]. More than 0 is needed.
>
> It's just too fast and our GNU Mach clock is not accurate enough:
Ah :/
> Maybe adding the support of high accuracy clock in GNU
Zhaoming Luo, le ven. 28 févr. 2025 20:42:41 +0800, a ecrit:
> I have applied the code and make test.
[...]
> I think you can commit the code.
Ok, done so, thanks!
> I could only see two failed tests now. Test 537 is a stress test and
> it got stuck and outputing a lot of 'Deallocating a bogus po
On Thu, Feb 27, 2025 at 08:25:37PM +0100, Samuel Thibault wrote:
> Hello,
>
> Nice investigation!
>
> Zhaoming Luo, le jeu. 27 févr. 2025 10:37:36 +0800, a ecrit:
> > It means that pthread_hurd_cond_timedwait_np() successes but
> > current->signal is still 1. I assume current->signal will only be
Hello,
Nice investigation!
Zhaoming Luo, le jeu. 27 févr. 2025 10:37:36 +0800, a ecrit:
> It means that pthread_hurd_cond_timedwait_np() successes but
> current->signal is still 1. I assume current->signal will only be
> modified to 1 when pthread_hurd_cond_timedwait_np() returns EINTR. Maybe
> w
On Thu, Feb 27, 2025 at 09:07:53AM +0800, Zhaoming Luo wrote:
> On Thu, Feb 27, 2025 at 01:34:46AM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le jeu. 27 févr. 2025 08:23:16 +0800, a ecrit:
> > > On Tue, Feb 25, 2025 at 08:28:34PM +0100, Samuel Thibault wrote:
> > > > Zhaoming Luo, le mar. 25 f
On Thu, Feb 27, 2025 at 01:34:46AM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le jeu. 27 févr. 2025 08:23:16 +0800, a ecrit:
> > On Tue, Feb 25, 2025 at 08:28:34PM +0100, Samuel Thibault wrote:
> > > Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit:
> > > > The program './runtests.pl
Zhaoming Luo, le jeu. 27 févr. 2025 08:23:16 +0800, a ecrit:
> On Tue, Feb 25, 2025 at 08:28:34PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit:
> > > The program './runtests.pl -g 546' stopped at [0] several times before
> > > the test is really runn
On Tue, Feb 25, 2025 at 08:28:34PM +0100, Samuel Thibault wrote:
> Hello,
>
> Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit:
> > The program './runtests.pl -g 546' stopped at [0] several times before
> > the test is really running, so I think some preparations involved
> > io_select_
Hello,
Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit:
> The program './runtests.pl -g 546' stopped at [0] several times before
> the test is really running, so I think some preparations involved
> io_select_common. However, after the test is running, I set a breakpoint
> at [1](it's
Hello,
Zhaoming Luo, le sam. 22 févr. 2025 14:27:07 +0800, a ecrit:
> This is not completed, but I would to confirm whether I have
> understanded the code.
Yes, this is the idea.
> Then we use 'machdev_trivfs_init ()' to init it so ext2fs can use
> device_open('hd0s1'); the following stuff it is
Hi!
On Sat, 2025-02-22 at 15:33:47 +0100, Samuel Thibault wrote:
> Samuel Thibault, le sam. 22 févr. 2025 15:33:27 +0100, a ecrit:
> > Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> > > The pciutils package is failing to build in Debian on hurd-amd64:
> > >
> > >
> > > https:/
Samuel Thibault, le sam. 22 févr. 2025 15:33:27 +0100, a ecrit:
> Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> > The pciutils package is failing to build in Debian on hurd-amd64:
> >
> >
> > https://buildd.debian.org/status/fetch.php?pkg=pciutils&arch=hurd-amd64&ver=1%3A3.13.
Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> The pciutils package is failing to build in Debian on hurd-amd64:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=pciutils&arch=hurd-amd64&ver=1%3A3.13.0-1%2Bb1&stamp=1732538417&raw=0
>
> The error is the following:
>
> ,---
Zhaoming Luo, le sam. 22 févr. 2025 21:06:18 +0800, a ecrit:
> On Sat, Feb 22, 2025 at 02:01:58PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 févr. 2025 20:59:53 +0800, a ecrit:
> > > On Sat, Feb 22, 2025 at 01:07:40PM +0100, Samuel Thibault wrote:
> > > > Zhaoming Luo, le sam. 22 fé
2nd connection to 127.0.0.1 port 50381
> TYPE I
< 200 I modify TYPE as you wanted
> SIZE 546
< 500 Can't check for file existence
> RETR 546
< 550 the file doesn't exist
* RETR response: 550
* multi_done[DOING_MORE]: status: 78 prem: 0 done: 0
* Remembering we are in
Zhaoming Luo, le sam. 22 févr. 2025 20:59:53 +0800, a ecrit:
> On Sat, Feb 22, 2025 at 01:07:40PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 févr. 2025 20:03:12 +0800, a ecrit:
> > > On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote:
> > > > Zhaoming Luo, le sam. 22 fé
78 prem: 0 done: 0
* Remembering we are in dir "path/"
* Curl_multi_closed, fd=6 multi is 0x556b25f8
* Curl_multi_closed, fd=6 entry is (nil)
* Connection #0 to host 127.0.0.1 left intact
Advancing to URL 1
* STATE: INIT => SETUP handle 0x556b0f38; line 2393
* STATE: SETUP => CO
Zhaoming Luo, le sam. 22 févr. 2025 20:03:12 +0800, a ecrit:
> On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit:
> > > lib533.c:96 select() failed, with errno 1073741828 (Interrupted system
> > > call)
> >
> > This is
On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote:
> Hello,
>
> Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit:
> > lib533.c:96 select() failed, with errno 1073741828 (Interrupted system call)
>
> This is expected if the test handles a signal. Does it indeed set up a
>
Hello,
Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit:
> lib533.c:96 select() failed, with errno 1073741828 (Interrupted system call)
This is expected if the test handles a signal. Does it indeed set up a
signal handler and get a signal?
Samuel
Zhaoming Luo, le lun. 17 févr. 2025 12:21:53 +0800, a ecrit:
> On Sun, Feb 16, 2025 at 10:30:17AM +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Zhaoming Luo, le dim. 16 févr. 2025 15:59:41 +0800, a ecrit:
> > > In the test[0] of vim. I think the issue is that the sleep time is not
> > > long en
Zhaoming Luo, le lun. 17 févr. 2025 10:16:42 +0800, a ecrit:
> On Sun, Feb 16, 2025 at 10:39:42AM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le dim. 16 févr. 2025 16:22:01 +0800, a ecrit:
> > > In test_filechanged.vim, those three parts are the sources of fail:
> > >
> > > https://github.com/
Hello,
Zhaoming Luo, le lun. 17 févr. 2025 09:14:13 +0800, a ecrit:
> This is what I have done to try to open the storeio translator in
> ext2fs, like what's mentioned in the TODO list.
> ```
>error_t err;
>mach_port_t bootstrap;
>
> - /* Initialize the diskfs library, parse arguments, a
On Sun, Feb 16, 2025 at 10:30:17AM +0100, Samuel Thibault wrote:
> Hello,
>
> Zhaoming Luo, le dim. 16 févr. 2025 15:59:41 +0800, a ecrit:
> > In the test[0] of vim. I think the issue is that the sleep time is not
> > long enough. Sleep for 200ms is possible to pass the test, though the
> > possib
On Sun, Feb 16, 2025 at 10:39:42AM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 16 févr. 2025 16:22:01 +0800, a ecrit:
> > In test_filechanged.vim, those three parts are the sources of fail:
> >
> > https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.vim#L15-L18
> > https:
Zhaoming Luo, le dim. 16 févr. 2025 16:22:01 +0800, a ecrit:
> In test_filechanged.vim, those three parts are the sources of fail:
>
> https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.vim#L15-L18
> https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.vim#L57-L60
>
Hello,
Zhaoming Luo, le dim. 16 févr. 2025 15:59:41 +0800, a ecrit:
> In the test[0] of vim. I think the issue is that the sleep time is not
> long enough. Sleep for 200ms is possible to pass the test, though the
> possibility is not that high. I think sleep for 2 seconds might be a
> good option.
On 2025-02-11 14:37, Yuqian Yang wrote:
This patch still uses a PATH_MAX stuck on Hurd. But it at least
can unblock your other works.
PATH_MAX stub.
Thanks.
--
Yuqian Yang
Hello,
On 2025-02-08 09:05, Sam Hartman wrote:
* I work with the porter and review the patches.
Thanks.
I have put 2 patches in attachment. `hurd-fix.patch` is the
real patch for fixing problems on Hurd. You have to put this
to `debian/patches` manually and change the `series`.
`hurd-debian.p
Samuel Thibault, le lun. 10 févr. 2025 13:57:46 +0100, a ecrit:
> Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> > * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> > extern since they are used in another module (icmp.c) and shouldn't be
> > removed.
>
> >
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:38:26 -0500, a ecrit:
> ---
> server.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/server.c b/server.c
> index 8da231c..9d25573 100644
> --- a/server.c
> +++ b/server.c
> @@ -766,6 +766,14 @@ WriteExtractArg(FILE *file,
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:37:56 -0500, a ecrit:
> ---
> mach/mig_strncpy.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mach/mig_strncpy.c b/mach/mig_strncpy.c
> index b0c001d775..dbd0a08e56 100644
> --- a/mach/mig_strncpy.c
> ++
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:37:13 -0500, a ecrit:
> ---
> kern/ipc_mig.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/kern/ipc_mig.c b/kern/ipc_mig.c
> index 18ac88ef..b6543703 100644
> --- a/kern/ipc_mig.c
> +++
Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> extern since they are used in another module (icmp.c) and shouldn't be
> removed.
> diff --git a/pfinet/linux-src/net/ipv4/tcp_ipv4.c
> b/pfinet/linux-src/net
1029097-d...@bugs.debian.org
Cc: debian-h...@lists.debian.org
Subject:Re: Bug#1029097: PAM HURD patches
Date: Fri, 07 Feb 2025 18:05:05 -0700 (08.02.2025 02:05:05)
control: tags -1 wontfix
Hi.
I still have not received an answer to my questions.
Also, the patch as written would not be suf
Applied, thanks!
Zhaoming Luo, le sam. 08 févr. 2025 18:32:20 +0800, a ecrit:
> The term_getctty() should accept pty_class
>
> See
> https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg00061.html
>
> * term/users.c: The term_getctty() accepts pty_class
> ---
> term/users.c | 2 +-
> 1 file ch
Zhaoming Luo, le sam. 08 févr. 2025 12:51:04 +0800, a ecrit:
> On Sat, Feb 08, 2025 at 08:55:31AM +0800, Zhaoming Luo wrote:
> > On Fri, Feb 07, 2025 at 01:57:01PM +0100, Samuel Thibault wrote:
> > > Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit:
> > > > This is V2 of figuring out the
On 2025-02-07 23:51, Samuel Thibault wrote:
Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit:
I know this is due to the way of our kernel to handle file and memory.
Do we have a good way to fix this,
Not a trivial way. It'd need adding names to the kernel map entries,
and
setting t
On Sat, Feb 08, 2025 at 08:55:31AM +0800, Zhaoming Luo wrote:
> On Fri, Feb 07, 2025 at 01:57:01PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit:
> > > This is V2 of figuring out the issue. V1 is abandoned due to my mistake,
> > > but this time I can
1 - 100 of 4031 matches
Mail list logo
