14 files changed, 242 insertions, 25 deletions
diff --git a/community/gsoc/2008/minutes-2008-04-25.mdwn b/community/gsoc/2008/minutes-2008-04-25.mdwn
index 4c2039d4..6b33de9e 100644
--- a/community/gsoc/2008/minutes-2008-04-25.mdwn
+++ b/community/gsoc/2008/minutes-2008-04-25.mdwn
@@ -9,12 +9,11 @@ is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
 - People agreed that some small projects should be done to during the bonding
-  period: ideas that floated around were fixing some of the build failures or
-  looking at the new debian installer.
-  http://unstable.buildd.net/buildd/hurd-i386_Failed.html
-  http://unstable.buildd.net/index-hurd-i386.html
+  period: ideas that floated around were fixing some of the build failures.
+  https://people.debian.org/~sthibault/hurd-i386/failed_packages.txt
+  https://people.debian.org/~sthibault/hurd-i386/out_of_date.txt
   For some context:
-  http://dept-info.labri.fr/~thibault/tmp/graph-radial.ps
+  https://www.debian.org/ports/hurd/hurd-devel-debian
   Don't pick something that looks too critical, it'll probably be too hard
 
 - Antrik was ok with not having a formal weekly report as long as the
diff --git a/community/gsoc/2012/virt/discussion.mdwn b/community/gsoc/2012/virt/discussion.mdwn
index e0085322..11c33e52 100644
--- a/community/gsoc/2012/virt/discussion.mdwn
+++ b/community/gsoc/2012/virt/discussion.mdwn
@@ -176,7 +176,7 @@ License|/fdl]]."]]"""]]
     <tschwinge> Exactly that is the abstraction level you need, yes.
     <nowhereman> I'm looking at http://savannah.gnu.org/git/?group=hurd
     <tschwinge> Yeah, that's a known shortcoming -- look here instead:
-      http://git.savannah.gnu.org/cgit/hurd
+      https://git.savannah.gnu.org/cgit/hurd
     <tschwinge> Here is some more up-to-date stuff on subhurds:
       http://www.gnu.org/software/hurd/hurd/subhurd.html
     <tschwinge> nowhereman: You know how to tell git to add a new remote to
diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn
index 4da3dde9..e5ef2920 100644
--- a/community/gsoc/2013/hacklu.mdwn
+++ b/community/gsoc/2013/hacklu.mdwn
@@ -1028,7 +1028,7 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
     <hacklu> is libpthread a part of glibc or hurd?
     <pinotree> glibc
     <NlightNFotis> hacklu: it is a different repository available here
-      http://git.savannah.gnu.org/cgit/hurd/libpthread.git/
+      https://git.savannah.gnu.org/cgit/hurd/libpthread.git/
     <hacklu> tschwinge: thanks for that, but I don't think I need help about
       the comiler error now, it just say missing some C file. I will look into
       the Makefile to verify.
@@ -1044,7 +1044,7 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
     <hacklu> tschwinge:BTW, I have found that, to continue the inferior from a
       breakpoint, doesn't need to call msg_sig_post_untraced. just call
       thread_abort and thread_resume is already ok.
-    <hacklu> I get the glibc from http://git.savannah.gnu.org/cgit/hurd. 
+    <hacklu> I get the glibc from https://git.savannah.gnu.org/cgit/hurd. 
     <tschwinge> hacklu: That sounds about right, because you want the inferior
       to continue normally, instead of explicitly sending a (Unix) signal to
       it.
diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn
index 8e672af1..756570d2 100644
--- a/community/gsoc/organization_application.mdwn
+++ b/community/gsoc/organization_application.mdwn
@@ -129,7 +129,7 @@ bug-hurd@gnu.org ( http://lists.gnu.org/mailman/listinfo/bug-hurd )
 
 * What is the main IRC channel for your organization?
 
-\#hurd on freenode.net
+\#hurd on libera.chat
 
 * Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2010 site.
 
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 0eab01c1..c68cfd66 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -98,7 +98,8 @@ All project ideas inlined:
 
 project_ideas:
 
-  "community/gsoc/project_ideas/virtualization
+  "community/gsoc/project_ideas/rust
+  community/gsoc/project_ideas/virtualization
   community/gsoc/project_ideas/secure_chroot
   community/gsoc/project_ideas/package_manager
   community/gsoc/project_ideas/driver_glue_code
diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn
index c0bdc5b2..236f1751 100644
--- a/community/gsoc/project_ideas/download_backends.mdwn
+++ b/community/gsoc/project_ideas/download_backends.mdwn
@@ -29,11 +29,11 @@ redirects etc.)
 
 A new interface providing all this additional information (either as an
 extension to the existing translators, or as distinct translators) is required
-to make such translators usable as backends for programs like apt-get for
+to make such translators usable as backends for programs like apt for
 example.
 
 The goal of this project is to design a suitable interface, implement it for at
-least one download protocol, and adapt apt-get (or some other program) to use
+least one download protocol, and adapt apt (or some other program) to use
 this as a backend.
 
 This task requires some design skills and some knowledge of internet protocols,
diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn
index db1816c9..9383f4ea 100644
--- a/community/gsoc/project_ideas/driver_glue_code.mdwn
+++ b/community/gsoc/project_ideas/driver_glue_code.mdwn
@@ -27,7 +27,7 @@ This is [[!GNU_Savannah_task 5488]].
 [[open issues/user-space device drivers]].
 [[open issues/device drivers and io systems]].
 
-The most promising approach for getting newer drivers seems to be the [[Rump_kernel]]:
+The most promising approach for getting newer drivers seems to be the [[rump kernel|hurd/rump]]:
 it already does the hard work of providing an environment
 where the foreign drivers can run,
 and offers the additional benefit of being externally maintained.
@@ -36,7 +36,10 @@ for running all drivers in separate userspace processes,
 which is more desirable than drivers running in the microkernel.
 
 Robert Millan worked on a port of the Rump kernel, which allowed to run a sound
-driver in userland. This work now needs to be extended.
+driver in userland. Damien Zammit implemented
+[[rumpdisk|hurd/rump/rumpdisk]] and
+[[rumpusbdisk|hurd/rump/rumpusbdisk]].
+This work now needs to be extended.
 
 [[Zheng Da|zhengda]] has already done considerable work on a similar approach, using [[DDE]]
 The basic framework for using DDE in the Hurd is present,
diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn
index a368a7a8..602c643e 100644
--- a/community/gsoc/project_ideas/file_locking.mdwn
+++ b/community/gsoc/project_ideas/file_locking.mdwn
@@ -15,7 +15,7 @@ License|/fdl]]."]]"""]]
 
 ---
 
-This is no longer valid as a Google Summer of Code project."""]]
+Svante Signell revived the patch and fixed it, it is now committed"""]]
 
 
 Over the years, [[UNIX]] has acquired a host of different file locking mechanisms.
diff --git a/community/gsoc/project_ideas/gdb.mdwn b/community/gsoc/project_ideas/gdb.mdwn
index e5c279b7..1cac960c 100644
--- a/community/gsoc/project_ideas/gdb.mdwn
+++ b/community/gsoc/project_ideas/gdb.mdwn
@@ -23,7 +23,7 @@ to be integrated first."""]]
 [[/GDB]] is available and working on GNU Hurd.  However, there are some bugs
 and there is missing functionality compared to a port targeting the Linux
 kernel ([[tag/Open_Issue_GDB]], [diff of
-testresults](http://git.savannah.gnu.org/cgit/hurd/web.git/tree/gdb/test.diff?h=toolchain/logs/master)).
+testresults](https://git.savannah.gnu.org/cgit/hurd/web.git/tree/gdb/test.diff?h=toolchain/logs/master)).
 For example, there is no port of [[open_issues/gdb/gdbserver]] available yet.
 Identifying (together with the mentors), and then addressing one or a few of
 these items is the goal of this project.
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
index 85695978..cfbec632 100644
--- a/community/gsoc/project_ideas/libcap/details.mdwn
+++ b/community/gsoc/project_ideas/libcap/details.mdwn
@@ -586,11 +586,11 @@ The replacing work could then be made a more gradual process.  Steps:
   iouser as mentioned in the details.
 
 * fsys_getroot.  Implement fsys_getroot_caps in libdiskfs, trans,
-  libtreefs, libtrivs, libnetfs.  Fix users of function in libdiskfs,
-  libfshelp, settrans, libtreefs, clookup.
+  libtrivs, libnetfs.  Fix users of function in libdiskfs,
+  libfshelp, settrans, clookup.
 
 * io_restrict_auth.  Implement io_restrict_auth_caps in libdiskfs,
-  libtreefs, libtrivfs, libnetfs, boot.  Fix users in utils(symlink,
+  libtrivfs, libnetfs, boot.  Fix users in utils(symlink,
   firmlink), libtrivs, term, clookup
 
 Among the problems might be that there are a lot of arguments that
diff --git a/community/gsoc/project_ideas/nfs.mdwn b/community/gsoc/project_ideas/nfs.mdwn
index d4980279..f8eb5319 100644
--- a/community/gsoc/project_ideas/nfs.mdwn
+++ b/community/gsoc/project_ideas/nfs.mdwn
@@ -16,15 +16,15 @@ very well: File locking doesn't work properly (at least in conjunction with a
 GNU/Linux server), and performance is extremely poor. Part of the problems
 could be owed to the fact that only NFSv2 is supported so far.
 
-(Note though that locking on the Hurd is problematic in general, not only in
-conjunction with NFS -- see the [[file_locking]] task.)
-
 This project encompasses implementing NFSv3 support, fixing bugs and
 performance problems -- the goal is to have good NFS support. The work done in
 a previous unfinished GSoC project can serve as a starting point.
 
 Both client and server parts need work, though the client is probably much more
-important for now, and shall be the major focus of this project.
+important for now, and shall be the major focus of this project.  One
+could probably use [[open_issues/libnfs]] for the client portion.  You
+should probably talk to Sergey, who has an in-development
+9P port to the Hurd.
 
 Some [discussion of NFS
 improvements](http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00035.html)
diff --git a/community/gsoc/project_ideas/rust.mdwn b/community/gsoc/project_ideas/rust.mdwn
new file mode 100644
index 00000000..f6be8132
--- /dev/null
+++ b/community/gsoc/project_ideas/rust.mdwn
@@ -0,0 +1,214 @@
+[[!meta copyright="Copyright © 2023 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="Porting Rust"]]
+
+[[!template id=highlight text="""/!\ Obsolete /!\
+
+---
+
+Vedant Tewari has been working on this as a Google Summer of Code 2023 project."""]]
+
+The goal of this project is to make the [Rust
+language](https://www.rust-lang.org/) available on GNU/Hurd.
+
+Presumably less work will be needed on the language's frontend itself, but
+rather on the supporting libraries.
+
+
+The Rust language is being used more and more widely, and notably in
+rather fundamental libraries such as librsvg or python-cryptography. It
+is thus more and more pressing for GNU/Hurd to have a compiler for Rust.
+
+The Rust compiler itself is quite portable, but its runtime library, libstd,
+needs to be ported to the GNU/Hurd system. This essentially consists in telling
+Rust how the standard C library functions can be called, i.e. the C ABI.
+
+There as an [initial attempt against rustc 1.30](https://people.debian.org/~sthibault/hurd-i386/rustc-1.30-patch) that was enough to get rustc
+to crossbuild, but it was missing most of what libstd needs. It is most probably
+very outdated nowadays, but that gives an idea.
+
+An example of the main part of the libstd port can be seen for the [VxWorks
+port](https://github.com/rust-lang/libc/blob/master/src/vxworks/mod.rs)
+
+The bulk of such a file can be mostly generated from the libc C
+headers thanks to the bindgen tool, it then needs to be cleaned up and
+integrated into the Rust build infrastructure, some preliminary work had
+already been investigated in that part.
+
+A good level of C programming will be welcome to understand the
+questions of ABI and the libc C functions being bound.
+
+Knowing the Rust language is not required: it can be learnt along the
+way, this can be a good occasion.
+
+Possible mentors: [[Samuel Thibault (youpi)|samuelthibault]] samuel.thibault@gnu.org
+
+For somebody who has already a very good level of C programming and good Rust
+programming skills, this can probably be a 175-hour project. Otherwise it will
+be a good occasion to learn, and can then be a 350-hour project.
+
+It is expected to be of medium difficulty: a fair part of the port is about
+mimicing other ports. Deciding how to mimic can be discussed with the community
+anyway. The other part is about expressing the C ABI. This requires to properly
+understand what that means, but once that is understood, it should be relatively
+straightforward to implement.
+
+You can contact the bug-hurd@gnu.org mailing list to discuss about this project.
+
+Bonding exercise: Building the Debian rustc package on Debian GNU/Linux.
+Building some Debian package (not rustc) on Debian GNU/Hurd.
+Have a look at the [initial attempt against rustc 1.30](https://people.debian.org/~sthibault/hurd-i386/rustc-1.30-patch) to get an idea how it looks like, how the ABI gets expressed in Rust.
+Then one builds the cross-compiler with
+
+    DEB_BUILD_OPTIONS=parallel=8 dpkg-buildpackage -B -ahurd-i386 -Ppkg.rustc.dlstage0,nocheck -nc
+
+[Rust language](https://www.rust-lang.org/)
+
+[How to build and run Rust](https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html)
+
+
+---
+
+One can check out the result with:
+
+    git clone https://github.com/sthibaul/getrandom.git
+    git clone https://github.com/sthibaul/nix.git -b r0.26-hack
+    git clone https://github.com/sthibaul/rust_libloading.git -b v0.7-hack
+    git clone https://github.com/sthibaul/rust_libloading.git -b hack rust_libloading-0.8.0
+    git clone https://github.com/sthibaul/socket2.git -b v0.4.x
+    git clone https://github.com/Vtewari2311/libc.git -b libc-hurd-latest-hack
+    git clone https://github.com/Vtewari2311/rust.git -b mod-hurd-latest-hack
+
+(yes, rust imposes checking out libloading several times...)
+
+---
+
+To build from GNU/Hurd, you will need existing `rustc`/`cargo`/`rustfmt`, you
+can e.g. fetch the tarball
+[from Samuel](https://people.debian.org/~sthibault/hurd-i386/rust-hurd.tar.xz).
+Then you can add the following to `rust/config.toml`
+
+    [build]
+    rustc = "/path/to/your/rust-hurd/usr/local/bin/rustc"
+    rustfmt = "/path/to/your/rust-hurd/usr/local/bin/rustfmt"
+    cargo = "/path/to/your/rust-hurd/usr/local/bin/cargo"
+
+And then run from `rust/`
+
+    ./x build
+    DESTDIR=/where/you/want ./x install
+    DESTDIR=/where/you/want ./x install cargo rustfmt
+
+Expect about 20GB disk usage and several hours duration. You also need quite
+some ram, 4GB may be needed.
+
+One can run the basic testsuites with
+
+    ./x test tests/ui
+    ./x test library/core
+    ./x test library/std
+
+One [can run tests remotely](https://rustc-dev-guide.rust-lang.org/tests/running.html#running-tests-on-a-remote-machine),
+to test with crossbuilding:
+
+    ./x build src/tools/remote-test-server --target i686-unknown-hurd-gnu
+
+One can run it on the target:
+
+    ./remote-test-server  -v --bind 0.0.0.0:12345
+
+and run the testsuite with
+
+    export TEST_DEVICE_ADDR="1.2.3.4:12345"
+    ./x test tests/ui --target i686-unknown-hurd-gnu
+
+Currently these tests are known to fail:
+
+tests/ui:
+
+    [ui] tests/ui/abi/homogenous-floats-target-feature-mixup.rs
+    [ui] tests/ui/associated-consts/issue-93775.rs
+    [ui] tests/ui/env-funky-keys.rs
+    [ui] tests/ui/issues/issue-74564-if-expr-stack-overflow.rs
+    [ui] tests/ui/macros/macros-nonfatal-errors.rs
+    [ui] tests/ui/modules/path-no-file-name.rs
+    [ui] tests/ui/parser/mod_file_with_path_attr.rs
+    [ui] tests/ui/process/no-stdio.rs#mir
+    [ui] tests/ui/process/no-stdio.rs#thir
+    [ui] tests/ui/process/println-with-broken-pipe.rs
+    [ui] tests/ui/sse2.rs
+    [ui] tests/ui/traits/object/print_vtable_sizes.rs
+
+notably because we have not enabled SSE2 by default, and we have errno values that are different from Linux etc.,
+
+library/std:
+
+    net::tcp::tests::double_bind
+    net::tcp::tests::test_read_timeout
+    net::tcp::tests::test_read_with_timeout
+    net::tcp::tests::timeouts
+    net::udp::tests::test_read_timeout
+    net::udp::tests::test_read_with_timeout
+    net::udp::tests::timeouts
+    os::unix::net::tests::basic
+    os::unix::net::tests::test_read_timeout
+    os::unix::net::tests::test_read_with_timeout
+    os::unix::net::tests::test_unix_datagram_connect_to_recv_addr
+
+because pfinet currently lets double-bind on IPv6 addresses, doesn't currently support `SO_SNDTIMEO` / `SO_RCVTIMEO`, and pflocal doesn't support getpeername.
+
+---
+
+To cross-build (e.g. from Linux), you need to set up a cross build toolchain
+; a simple way is to use the `build-many-glibcs.py` script as described on
+[[hurd/glibc]]. Note that to produce something that can be run even on current
+latest Debian, you should be using the `2.37/master` branch. You also need to
+comment the `#define ED` from `sysdeps/mach/hurd/bits/errno.h`.
+
+You also need to unpack a Hurd build of openssl ; a simple way is to take the
+debian packages from debian-ports:
+[libssl3](http://deb.debian.org/debian-ports/pool-hurd-i386/main/o/openssl/libssl3_3.0.10-1_hurd-i386.deb)
+and
+[libssl-dev](http://deb.debian.org/debian-ports/pool-hurd-i386/main/o/openssl/libssl-dev_3.0.10-1_hurd-i386.deb)
+and unpack them with:
+
+    dpkg-deb -x libssl3_3.0.10-1_hurd-i386.deb /where/you/want
+    dpkg-deb -x libssl-dev_3.0.10-1_hurd-i386.deb /where/you/want
+    mv /where/you/want/usr/include/i386-gnu/openssl/* /where/you/want/usr/include/openssl/
+    mv /where/you/want/usr/lib/i386-gnu/* /where/you/want/usr/lib/
+
+Then you can add the following to `rust/config.toml`
+
+    [llvm]
+    download-ci-llvm = false
+
+    [target.i686-unknown-hurd-gnu]
+    cc = "/path/to/your/build-glibc/install/compilers/i686-gnu/bin/i686-glibc-gnu-gcc"
+    cxx = "/path/to/your/build-glibc/install/compilers/i686-gnu/bin/i686-glibc-gnu-g++"
+    linker = "/path/to/your/build-glibc/install/compilers/i686-gnu/bin/i686-glibc-gnu-gcc"
+
+And then run from `rust/`
+
+    export I686_UNKNOWN_HURD_GNU_OPENSSL_DIR=/where/you/want/usr
+    ./x build --stage 0 compiler library
+    ./x build --host i686-unknown-hurd-gnu --target i686-unknown-hurd-gnu compiler library cargo rustfmt
+    DESTDIR=/where/you/want ./x install --host i686-unknown-hurd-gnu --target i686-unknown-hurd-gnu
+    DESTDIR=/where/you/want ./x install --host i686-unknown-hurd-gnu --target i686-unknown-hurd-gnu cargo rustfmt
+
+Expect about 25GB disk usage and several hours duration. You also need quite
+some ram, 4GB may be needed. Take care if you have many cores and threads, the
+parallel build of llvm can be quite demanding, you may want to reduce the number
+of available processors (e.g. disabling SMT by prefixing your commands with
+`hwloc-bind --no-smt all -- `), so you have more memory per core.
+
+Note that you will have a usable cross-compiler in
+`rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc` and a native Hurd compiler in
+`rust/build/i686-unknown-hurd-gnu/stage2/bin/rustc`
diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
index 28c95626..99befbf7 100644
--- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn
+++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
@@ -19,7 +19,7 @@ lwip as a complete replacement for pfinet.  However, lwip uses the netdde device
 drivers for wireless chips, which are old drivers from an old version of linux. To use
 lwip for a wifi connection on more modern hardware, one would also need modern
 device drivers to access the internet.  The promising approach to this is using
-a rump kernel.  This is essentially the New Driver Framework google summer of
+[[hurd/rump/rumpnet]].  This is essentially the [[New Driver Framework|community/gsoc/project_ideas/driver_glue_code]] google summer of
 code project idea.  Hopefully, one day soon the Hurd project will completely replace pfinet
 with lwip.
 
diff --git a/community/gsoc/project_ideas/xmlfs.mdwn b/community/gsoc/project_ideas/xmlfs.mdwn
index 5e5eaa13..41c0b018 100644
--- a/community/gsoc/project_ideas/xmlfs.mdwn
+++ b/community/gsoc/project_ideas/xmlfs.mdwn
@@ -15,7 +15,7 @@ different format.  This is a very powerful ability: it allows using standard
 tools on all kinds of data, and combining existing components in new ways, once
 you have the necessary translators.
 
-A typical example for such a translator would be xmlfs: a translator that
+A typical example for such a translator would be [[hurd/translator/xmlfs]]: a translator that
 presents the contents of an underlying XML file in the form of a directory
 tree, so it can be studied and edited with standard filesystem tools, or using
 a graphical file manager, or to easily extract data from an XML file in a