[PATCH] Resurrect x86-linux build.
This avoids using system headers, which may result in kern/strings.c: In function 'strchr': kern/strings.c:188:32: error: 'NULL' undeclared (first use in this function) In file included from util/atoi.c:77: ./util/atoi.h:65:29: error: unknown type name 'u_char' device/net_io.c: In function 'bpf_do_filter': device/net_io.c:1636:34: error: 'u_int' undeclared (first use in this function); did you mean 'int'? In file included from device/subrs.c:36: ./device/if_ether.h:43:9: error: unknown type name 'u_char' 43 | u_char ether_dhost[6]; ./linux/dev/include/linux/fs.h:304:5: error: unknown type name 'loff_t' 304 | loff_t f_pos; This is a follow-up to commit d5e5dd3401ea0d0475aa830c2171be5b8a72f4fa Update configure.ac so that we don't need glibc when running ./configure. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index e31a875d..ad38249b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -43,7 +43,7 @@ AM_LDFLAGS = GCC_INSTALL = $(shell LANG=C $(CC) -print-search-dirs | sed -n -e 's/install: \(.*\)/\1/p') AM_CPPFLAGS += \ - -imacros config.h -I $(GCC_INSTALL)/include + -nostdinc -imacros config.h -I $(GCC_INSTALL)/include AM_CPPFLAGS += \ -I$(systype) \ -- 2.41.0
Re: Announcing: a new Hurd distro, based on Alpine Linux
On Sun, Jan 21, 2024 at 10:14 PM wrote:
> I'd be happy to buy a sourcehut account for it for a year.
>
> I'd also be happy to create a website for it and host it for a year.
> We should make this email (perhaps reword it) as the website's first
> blog post.
>
> Software with which we can build a static site (that runs on the hurd):
>
> ikiwiki
> Emacs org-mode (I vote this one)
> guile's Haunt (I am having a hard time installing this on Debian
> GNU/Hurd).
Yay :)
FWIW, I love how the Guile website looks, but that clearly has more to
do with the styling than with the choice of a backend framework.
As for {Git,packages} repos, I just learned that Gitea 1.20 has
built-in support for Alpine package registries [0][1], which is pretty
neat. If we could work out how to hook this up to a CI pipeline that
would build and publish packages (and that shouldn't be hard), this
would be perfect for us.
[0]: https://docs.gitea.com/next/usage/packages/packages/alpine (this
page says 1.20 is unreleased for some reason, but 1.20 has been
released back in July, and 1.21.4 is the current release)
[1]: https://github.com/go-gitea/gitea/pull/23714
So, what do you think, would you (or anyone else reading this) be able
to host a Gitea instance for this project? Hosting it on a Hurd system
would be cool, but not a requirement — we can do one thing at a time.
Any more naming ideas?
Sergey
[PATCH hurd] Update rpctrace to use the new ABI for inlined port names
---
utils/rpctrace.c | 83 +++-
1 file changed, 53 insertions(+), 30 deletions(-)
diff --git a/utils/rpctrace.c b/utils/rpctrace.c
index f7046a0..c8635a3 100644
--- a/utils/rpctrace.c
+++ b/utils/rpctrace.c
@@ -801,6 +801,18 @@ rewrite_right (mach_port_t *right, mach_msg_type_name_t
*type,
return 0;
}
+static mach_port_name_t *
+get_port_ref (void *data, const boolean_t is_inline, const int i) {
+ if (is_inline)
+{
+ mach_port_name_inlined_t *const inlined_port_names = data;
+ return _port_names[i].name;
+} else {
+ mach_port_t *const portnames = data;
+ return [i];
+}
+}
+
static void
print_contents (mach_msg_header_t *inp,
void *msg_buf_ptr, struct req_info *req)
@@ -818,6 +830,7 @@ print_contents (mach_msg_header_t *inp,
mach_msg_type_number_t nelt; /* Number of data items. */
mach_msg_type_size_t eltsize; /* Bytes per item. */
mach_msg_type_name_t name; /* MACH_MSG_TYPE_* code */
+ boolean_t is_inline = type->msgt_inline;
if (!type->msgt_longform)
{
@@ -834,7 +847,7 @@ print_contents (mach_msg_header_t *inp,
data = msg_buf_ptr = lt + 1;
}
- if (!type->msgt_inline)
+ if (!is_inline)
{
/* This datum is out-of-line, meaning the message actually
contains a pointer to a vm_allocate'd region of data. */
@@ -857,35 +870,39 @@ print_contents (mach_msg_header_t *inp,
if (MACH_MSG_TYPE_PORT_ANY_RIGHT (name))
{
/* These are port rights. Translate them into wrappers. */
- mach_port_t *const portnames = data;
mach_msg_type_number_t i;
mach_msg_type_name_t newtypes[nelt ? : 1];
int poly;
assert_backtrace (inp->msgh_bits & MACH_MSGH_BITS_COMPLEX);
- assert_backtrace (eltsize == sizeof (mach_port_t));
+
+ if (is_inline)
+ assert_backtrace (eltsize == sizeof (mach_port_name_inlined_t));
+ else
+ assert_backtrace (eltsize == sizeof (mach_port_t));
poly = 0;
for (i = 0; i < nelt; ++i)
{
char *str;
+ mach_port_name_t *port_name = get_port_ref (data, is_inline, i);
newtypes[i] = name;
- str = rewrite_right ([i], [i], req);
+ str = rewrite_right (port_name, [i], req);
putc ((i == 0 && nelt > 1) ? '{' : ' ', ostream);
- if (portnames[i] == MACH_PORT_NULL)
+ if (*port_name == MACH_PORT_NULL)
fprintf (ostream, "(null)");
- else if (portnames[i] == MACH_PORT_DEAD)
+ else if (*port_name == MACH_PORT_DEAD)
fprintf (ostream, "(dead)");
else
{
if (str != 0)
fprintf (ostream, "%s", str);
else
- fprintf (ostream, "%3u", (unsigned int) portnames[i]);
+ fprintf (ostream, "%3u", (unsigned int) *port_name);
}
if (i > 0 && newtypes[i] != newtypes[0])
poly = 1;
@@ -900,39 +917,45 @@ print_contents (mach_msg_header_t *inp,
/* Some of the new rights are MAKE_SEND_ONCE.
Turn them all into MOVE_SEND_ONCE. */
for (i = 0; i < nelt; ++i)
- if (newtypes[i] == MACH_MSG_TYPE_MAKE_SEND_ONCE)
+ {
+ mach_port_name_t *port_name = get_port_ref (data,
is_inline, i);
+ if (newtypes[i] == MACH_MSG_TYPE_MAKE_SEND_ONCE)
{
err = mach_port_insert_right (mach_task_self (),
- portnames[i],
- portnames[i],
- newtypes[i]);
+ *port_name,
+ *port_name,
+ newtypes[i]);
assert_perror_backtrace (err);
}
- else
- assert_backtrace (newtypes[i] ==
MACH_MSG_TYPE_MOVE_SEND_ONCE);
+ else
+ assert_backtrace (newtypes[i] ==
MACH_MSG_TYPE_MOVE_SEND_ONCE);
+ }
}
else
{
for (i = 0; i < nelt; ++i)
- switch (newtypes[i])
+ {
+ mach_port_name_t *port_name = get_port_ref (data,
is_inline, i);
+ switch (newtypes[i])
{
- case MACH_MSG_TYPE_COPY_SEND:
- err = mach_port_mod_refs (mach_task_self (),
- portnames[i],
- MACH_PORT_RIGHT_SEND, +1);
-
[PATCH hurd 5/6] ftpfs: use correct function signature for interrupt_check
---
ftpfs/ftpfs.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/ftpfs/ftpfs.c b/ftpfs/ftpfs.c
index 794439b..9310a56 100644
--- a/ftpfs/ftpfs.c
+++ b/ftpfs/ftpfs.c
@@ -51,8 +51,13 @@ struct ftpfs *ftpfs;
/* Parameters describing the server we're connecting to. */
struct ftp_conn_params *ftpfs_ftp_params = 0;
+static int
+ftp_hooks_interrupt_check (struct ftp_conn *) {
+ return ports_self_interrupted ();
+}
+
/* customization hooks. */
-struct ftp_conn_hooks ftpfs_ftp_hooks = { interrupt_check:
ports_self_interrupted };
+struct ftp_conn_hooks ftpfs_ftp_hooks = { interrupt_check:
ftp_hooks_interrupt_check };
/* The (user-specified) name of the SERVER:FILESYSTEM we're connected too. */
char *ftpfs_remote_fs;
--
2.39.2
[PATCH hurd 6/6] hurdio: use correct function signature for hurdio_mdmstate
---
term/hurdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/term/hurdio.c b/term/hurdio.c
index c6e14a4..a3e2a0a 100644
--- a/term/hurdio.c
+++ b/term/hurdio.c
@@ -613,8 +613,8 @@ hurdio_mdmctl (int how, int bits)
}
-static int
-hurdio_mdmstate (void)
+static error_t
+hurdio_mdmstate (int *state)
{
int oldbits;
--
2.39.2
[PATCH hurd 2/6] procfs: remove unused rootdir_symlink_make_node
Not needed since b2c97e251bb470e6f967c716081675a96dbde59c
---
procfs/rootdir.c | 8
1 file changed, 8 deletions(-)
diff --git a/procfs/rootdir.c b/procfs/rootdir.c
index 7742edd..206a541 100644
--- a/procfs/rootdir.c
+++ b/procfs/rootdir.c
@@ -706,14 +706,6 @@ rootdir_file_make_node (void *dir_hook, const void
*entry_hook)
return procfs_make_node (entry_hook, dir_hook);
}
-static struct node *
-rootdir_symlink_make_node (void *dir_hook, const void *entry_hook)
-{
- struct node *np = procfs_make_node (entry_hook, dir_hook);
- if (np)
-procfs_node_chtype (np, S_IFLNK);
- return np;
-}
/* Translator linkage. */
--
2.39.2
[PATCH hurd 3/6] Fix warnings in fstests
---
fstests/fstests.c | 1 -
fstests/timertest.c | 10 --
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/fstests/fstests.c b/fstests/fstests.c
index b776503..ca60203 100644
--- a/fstests/fstests.c
+++ b/fstests/fstests.c
@@ -94,7 +94,6 @@ main (void)
#endif
printf ("All done.\n");
- malloc (0);
return 0;
}
diff --git a/fstests/timertest.c b/fstests/timertest.c
index 2d60256..6eca98e 100644
--- a/fstests/timertest.c
+++ b/fstests/timertest.c
@@ -32,14 +32,20 @@ alarm_handler (int signo)
int
main(int argc, char *argv[])
{
+ struct sigaction alarm_sigaction = { 0 };
+ sigset_t empty_sigset;
struct itimerval real_timer;
+ sigemptyset (_sigset);
+
real_timer.it_interval.tv_usec = 0;
real_timer.it_interval.tv_sec = 1;
real_timer.it_value.tv_usec = 0;
real_timer.it_value.tv_sec = 1;
- signal (SIGALRM, alarm_handler);
+ alarm_sigaction.sa_handler = _handler;
+ alarm_sigaction.sa_flags = SA_RESTART;
+ sigaction (SIGALRM, _sigaction, NULL);
if (setitimer (ITIMER_REAL, _timer, 0) < 0)
error (1, errno, "Setting timer");
@@ -56,7 +62,7 @@ main(int argc, char *argv[])
{
puts ("Saw EOF. Pausing (no input)...");
fflush (stdout);
- sigpause (0);
+ sigsuspend (_sigset);
}
else
printf ("Saw %.3o\n", c);
--
2.39.2
[PATCH hurd 4/6] x86_64: do not define mach_cpu_subtypes since we don't use it
---
proc/cpu-types.c | 2 ++
proc/host.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/proc/cpu-types.c b/proc/cpu-types.c
index 3d89d5a..7a814f6 100644
--- a/proc/cpu-types.c
+++ b/proc/cpu-types.c
@@ -38,6 +38,7 @@ const char *const mach_cpu_types[] =
#endif
};
+#ifndef __x86_64__
const char *const mach_cpu_subtypes[][32] =
{
[CPU_TYPE_VAX] =
@@ -167,3 +168,4 @@ const char *const mach_cpu_subtypes[][32] =
[CPU_SUBTYPE_ALPHA_21064] = "ALPHA_21064",
},
};
+#endif /* !__x86_64__ */
diff --git a/proc/host.c b/proc/host.c
index 823bda5..c2b53c3 100644
--- a/proc/host.c
+++ b/proc/host.c
@@ -340,7 +340,9 @@ void
initialize_version_info (void)
{
extern const char *const mach_cpu_types[];
+#ifndef __x86_64__
extern const char *const mach_cpu_subtypes[][32];
+#endif
kernel_version_t kv;
char *p;
struct host_basic_info info;
--
2.39.2
[PATCH hurd 1/6] Restructure argument setup in hashbang
We do a few things here:
- Move search_path to the scope where it is used to make dependencies
more clear.
- Have a separate variable to store the file name we eventually need to
free and move the free logic to happen in a single place.
Both of this allows us to still free the name even if a fault is generated and
also avoids a compiler warning as we try to assign a 'const char*'
file_name_exec to a 'char *', making it more clear to what exactly we
need to free. I also believe 'error' in line 245 was not initialized in
case 'file_name_exec' is used and this fixes that too.
---
exec/hashexec.c | 91 +++--
1 file changed, 43 insertions(+), 48 deletions(-)
diff --git a/exec/hashexec.c b/exec/hashexec.c
index a107291..0953679 100644
--- a/exec/hashexec.c
+++ b/exec/hashexec.c
@@ -221,14 +221,14 @@ check_hashbang (struct execdata *e,
if (! e->error)
{
- int free_file_name = 0; /* True if we should free FILE_NAME. */
+ char * volatile file_name_to_free = NULL; /* Will free this if set. */
jmp_buf args_faulted;
void fault_handler (int signo)
{ longjmp (args_faulted, 1); }
error_t setup_args (struct hurd_signal_preemptor *preemptor)
{
size_t namelen;
- char * volatile file_name = NULL;
+ const char * volatile file_name = NULL;
if (setjmp (args_faulted))
file_name = NULL;
@@ -242,44 +242,42 @@ check_hashbang (struct execdata *e,
named by ARGV[0] in the `PATH' environment variable
might find it. */
- error_t error;
- char *name;
- int free_name = 0; /* True if we should free NAME. */
- file_t name_file;
- mach_port_t fileid, filefsid;
- ino_t fileno;
-
- /* Search $PATH for NAME, opening a port NAME_FILE on it.
-This is encapsulated in a function so we can catch faults
-reading the user's environment. */
- error_t search_path (struct hurd_signal_preemptor *preemptor)
+ if (file_name_exec && file_name_exec[0] != '\0')
+ file_name = file_name_exec;
+ else
{
- error_t err;
- char *path = envz_get (envp, envplen, "PATH"), *pfxed_name;
-
- if (! path)
+ error_t error;
+ file_t name_file;
+ mach_port_t fileid, filefsid;
+ ino_t fileno;
+ char *name;
+ /* Search $PATH for NAME, opening a port NAME_FILE on it.
+This is encapsulated in a function so we can catch faults
+reading the user's environment. */
+ error_t search_path (struct hurd_signal_preemptor *preemptor)
{
- const size_t len = confstr (_CS_PATH, NULL, 0);
- path = alloca (len);
- confstr (_CS_PATH, path, len);
- }
+ error_t err;
+ char *path = envz_get (envp, envplen, "PATH"),
*pfxed_name;
- err = hurd_file_name_path_lookup (user_port, user_fd, 0,
- name, path, O_EXEC, 0,
- _file, _name);
- if (!err && pfxed_name)
- {
- name = pfxed_name;
- free_name = 1;
- }
+ if (! path)
+ {
+ const size_t len = confstr (_CS_PATH, NULL, 0);
+ path = alloca (len);
+ confstr (_CS_PATH, path, len);
+ }
- return err;
- }
+ err = hurd_file_name_path_lookup (user_port, user_fd, 0,
+ name, path, O_EXEC, 0,
+ _file,
_name);
+ if (!err && pfxed_name)
+ {
+ name = pfxed_name;
+ file_name_to_free = pfxed_name;
+ }
+
+ return err;
+ }
- if (file_name_exec && file_name_exec[0] != '\0')
- name = file_name_exec;
- else
- {
/* Try to locate the file. */
error = io_identity (file, , , );
if (error)
@@ -320,15 +318,10 @@ check_hashbang (struct execdata *e,
}
mach_port_deallocate (mach_task_self (), fileid);
- }
- if (!error)
- {
- file_name = name;
- free_file_name = free_name;
+ if (!error)
+
Re: Announcing: a new Hurd distro, based on Alpine Linux
January 20, 2024 at 3:03 PM, "Sergey Bugaev" wrote: > > Hello! > > Those of you who made it to Joshua's belated New Year's party have > heard me mumble my way through announcing this: I have been working on > a new Hurd-based disto, based on the Alpine Linux distribution [0]! > > [0] https://www.alpinelinux.org/about/ > > Now, before I go any further, I should say that this is not trying to > displace Debian or anything like that. We all love Debian GNU/Hurd, > and are thankful for Samuel's hard work that makes it possible. I am > using Debian, and will continue to do so. (Especially given that this > project might not succeed, after all.) > > That being said, I have for a long time thought that the Hurd needed > more _distro diversity_. The other existing distro is Guix on the > Hurd, made by our Guix friends, which is great, and it seems to have > generated some interest towards the Hurd in the Guix community, and > some positive publicity for the Hurd too. > > Historically, I know that there has been the Arch Hurd project [1] > (just look at all the excitement it has generated! [2]), but it seems > to have stalled. (By the way, if you're a fan of Arch who's interested > in the Hurd, I encourage you to revive Arch Hurd, that'd be so cool!) > There's been talks of Gentoo GNU/Hurd, but it doesn't look like > they've made much progress. (Fun story: I have once almost convinced a > friend of mine who was a Gentoo user to try and bootstrap a Hurd > version of Gentoo on his own.) > > [1] https://archhurd.org/ > [2] https://bbs.archlinux.org/viewtopic.php?pid=682472 > > Awesome as Debian is, there are issues with it. Firstly, the tooling > (and the social processes) used around Debian packaging seems rather > arcane and complicated for someone like myself who is not experienced > in Debian packaging. This is not a criticism; I'm sure it works great > for them! — but this also means that most of us in the already small > Hurd community are essentially unable to contribute to it. > > Secondly, Debian GNU/Hurd being the full "grown-up" Debian distro has > — well, certainly a lot of upsides, and that's what makes it so > appealing — but also, I imagine, some downsides, in that it cannot > just be our little playground. For example, I imagine Debian cannot > ship the latest & greatest glibc master with all of my fixes, because > that might break Debian GNU/Linux, which has different expectations > around stability and a lot more users. In fact, Debian still ships > glibc 2.37, with some patches backported. > > Now, on the other hand of the spectrum are Flávio's cross-hurd > scripts, which bootstrap a minimal Hurd-based system. These are small, > self-contained, and hackable. You can build the whole thing, including > the cross toolchains required, in a few minutes, without much of a > special setup required. Bumping glibc (or something) should be > trivial. If you want to contribute, you fork the Git repo, apply your > changes, and just open a PR. How cool is that? > > So I think there is a place for some middle ground between the two: a > full (although small, "embedded") distro, with a package manager and > many available packages, that is at the same time easy to bootstrap, > to hack on, experiment with, and contribute to. The hackability should > hopefully ensure that this becomes a community project rather than a > one man show, and has a healthy bus factor. > > I chose Alpine Linux as the upstream distribution for the project, for > various reasons; not least because I thought it would be a fun > endeavour to try and port Alpine which is known for not being a GNU > distro and in particular not using glibc (and it was!). Alpine > certainly fills the bill of being small and extremely hackable. They, > too, keep all of their package build definitions/scripts in a single > Git repo (aports); updating a package or adding a patch only requires > making an MR against the repo. The CI can then pick up the change, > rebuild the package, and without minutes of the MR being merged have > the new package available for download from the repo. > > I have ported many Alpine packages to build with (i386, for now) GNU > Mach, the Hurd, and glibc, replacing Linux and musl. If you want a > specific number: as of yesterday, I have 299 installable packages; the > number of source packages is of course several times less than that. > Still, this includes things like curl, ncurses, nano, native binutils > & gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools, > ... and of course gnumach, hurd (with dependencies like libdaemon, > parted, ...), and glibc. Importantly, all this cleanly bootstraps > using the scripts/bootstrap.sh script that they provide; this is too > somewhat like Flávio's scripts, but it uses the real full Alpine > package definitions for e.g. GCC (patched by me for glibc / Hurd > support). > > Above the kernel and libc, things remain much as they were in upstream > Alpine: the
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 you who made it to Joshua's belated New Year's party have > heard me mumble my way through announcing this: I have been working > on > a new Hurd-based disto, based on the Alpine Linux distribution [0]! > > [0] https://www.alpinelinux.org/about/ > > Now, before I go any further, I should say that this is not trying to > displace Debian or anything like that. We all love Debian GNU/Hurd, > and are thankful for Samuel's hard work that makes it possible. I am > using Debian, and will continue to do so. (Especially given that this > project might not succeed, after all.) > > That being said, I have for a long time thought that the Hurd needed > more _distro diversity_. The other existing distro is Guix on the > Hurd, made by our Guix friends, which is great, and it seems to have > generated some interest towards the Hurd in the Guix community, and > some positive publicity for the Hurd too. > > Historically, I know that there has been the Arch Hurd project [1] > (just look at all the excitement it has generated! [2]), but it seems > to have stalled. (By the way, if you're a fan of Arch who's > interested > in the Hurd, I encourage you to revive Arch Hurd, that'd be so cool!) > There's been talks of Gentoo GNU/Hurd, but it doesn't look like > they've made much progress. (Fun story: I have once almost convinced > a > friend of mine who was a Gentoo user to try and bootstrap a Hurd > version of Gentoo on his own.) > > [1] https://archhurd.org/ > [2] https://bbs.archlinux.org/viewtopic.php?pid=682472 > > Awesome as Debian is, there are issues with it. Firstly, the tooling > (and the social processes) used around Debian packaging seems rather > arcane and complicated for someone like myself who is not experienced > in Debian packaging. This is not a criticism; I'm sure it works great > for them! — but this also means that most of us in the already small > Hurd community are essentially unable to contribute to it. > > Secondly, Debian GNU/Hurd being the full "grown-up" Debian distro has > — well, certainly a lot of upsides, and that's what makes it so > appealing — but also, I imagine, some downsides, in that it cannot > just be our little playground. For example, I imagine Debian cannot > ship the latest & greatest glibc master with all of my fixes, because > that might break Debian GNU/Linux, which has different expectations > around stability and a lot more users. In fact, Debian still ships > glibc 2.37, with some patches backported. > > Now, on the other hand of the spectrum are Flávio's cross-hurd > scripts, which bootstrap a minimal Hurd-based system. These are > small, > self-contained, and hackable. You can build the whole thing, > including > the cross toolchains required, in a few minutes, without much of a > special setup required. Bumping glibc (or something) should be > trivial. If you want to contribute, you fork the Git repo, apply your > changes, and just open a PR. How cool is that? > > So I think there is a place for some middle ground between the two: a > full (although small, "embedded") distro, with a package manager and > many available packages, that is at the same time easy to bootstrap, > to hack on, experiment with, and contribute to. The hackability > should > hopefully ensure that this becomes a community project rather than a > one man show, and has a healthy bus factor. > > I chose Alpine Linux as the upstream distribution for the project, > for > various reasons; not least because I thought it would be a fun > endeavour to try and port Alpine which is known for not being a GNU > distro and in particular not using glibc (and it was!). Alpine > certainly fills the bill of being small and extremely hackable. They, > too, keep all of their package build definitions/scripts in a single > Git repo (aports); updating a package or adding a patch only requires > making an MR against the repo. The CI can then pick up the change, > rebuild the package, and without minutes of the MR being merged have > the new package available for download from the repo. > > I have ported many Alpine packages to build with (i386, for now) GNU > Mach, the Hurd, and glibc, replacing Linux and musl. If you want a > specific number: as of yesterday, I have 299 installable packages; > the > number of source packages is of course several times less than that. > Still, this includes things like curl, ncurses, nano, native binutils > & gcc & mig, libffi, openrc, openssl, util-linux, busybox, apk-tools, > ... and of course gnumach, hurd (with dependencies like libdaemon, > parted, ...), and glibc. Importantly, all this cleanly bootstraps > using the scripts/bootstrap.sh script that they provide; this is too > somewhat
