Yes, sure, anything will do.
I essentially mean that "we" shouldn't be me.
For a start, just testing that the whole thing just builds in the
various situations would be a *VAST* improvement, considering the amount
of time I spend on just that.
Then there was recently some work on building simple
As a little suggestion, using my very little knowledge about it, we can set a
mirror in a GitLab server, which incorporates this functionality natively. We
can deploy a GitLab local server if we don't want to depends of gitlab.com, and
set a couple of tests in it.
As this way, we can use a test
Can some people eventually set up some CI somehow somewhere?
(AFAIK savannah doesn't support such a thing, so it wouldn't go there,
so anybody can feel free to set it up wherever it sees easiest).
If people wonder why I don't make releases that often, the reason is
very simple: each time I try to
And now I'm getting a -Werror in glibc due to this:
Flavio Cruz, le ven. 24 nov. 2023 16:30:40 -0500, a ecrit:
> diff --git a/utils.c b/utils.c
> index ec0f2d1..0d69cb2 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -317,6 +317,9 @@ WriteFieldDeclPrim(FILE *file, const argument_t *arg,
> if (it-
Hello,
Flavio Cruz, le ven. 24 nov. 2023 16:30:38 -0500, a ecrit:
> @@ -215,11 +237,11 @@ _hurd_intr_rpc_mach_msg (mach_msg_header_t *msg,
> data = (char *) ty + sizeof (mach_msg_type_t);
> }
>
> + /* Calculate length of data in bytes. */
> co
Applied, thanks!
Joan Lledó, le sam. 02 déc. 2023 11:14:01 +0100, a ecrit:
> From: Joan Lledó
>
> The translator received a null `netif_list` during initialization, this
> caused a few bugs.
>
> When started without parameters, the translator didn't add any new
> interface to `netif_list`, and
Hello,
As reported on IRC: building mig with --host=i686-unknown-linux-gnu
doesn't seem to be producing a 32bit-target mig any more: building
gnumach with it ends up with:
84 | _Static_assert(sizeof(ipc_port_t) == 8 * 1, "expected
ipc_port_t to be size 8 * 1");
Samuel
From: Joan Lledó
The translator received a null `netif_list` during initialization, this
caused a few bugs.
When started without parameters, the translator didn't add any new
interface to `netif_list`, and that broke any subsequent fsysopts over
the translator, as the stack was being initialized
Hi,
This patch fixes a few bugs. The translator was assuming one interface was
already allocated in `netif_list` when calling `init_ifs` during startup, and
used it to configure the loopback interface [1]. That was possibly true in the
past but after upgrading liblwip I found `netif_list` is
