summaryrefslogtreecommitdiff
path: root/community
diff options
context:
space:
mode:
Diffstat (limited to 'community')
-rw-r--r--community/gsoc/2012/virt/discussion.mdwn2
-rw-r--r--community/gsoc/2013/hacklu.mdwn4
-rw-r--r--community/gsoc/project_ideas.mdwn3
-rw-r--r--community/gsoc/project_ideas/driver_glue_code.mdwn2
-rw-r--r--community/gsoc/project_ideas/file_locking.mdwn2
-rw-r--r--community/gsoc/project_ideas/gdb.mdwn2
-rw-r--r--community/gsoc/project_ideas/rust.mdwn214
-rw-r--r--community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn2
-rw-r--r--community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn3
-rw-r--r--community/weblogs/ArneBab/what_we_need.mdwn4
10 files changed, 226 insertions, 12 deletions
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/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/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn
index db1816c9..3d0a9192 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.
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/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/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn
index b0e57bfb..5ead2362 100644
--- a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn
+++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn
@@ -57,7 +57,7 @@ For this years GSoC I want to turn the currently rudimentary Python Bindings of
* *August 8.*
More translators and integrating into the build system.
* *August 15.*
- Suggested Pencils down. The translator API is easy to use, there are many example translators and there is a full featured settrans command in Python using the easier controlling API which shows how to control the Hurd directly from Python. The code is pushed to <https://github.com/ArneBab/PyHurd> and a git repo at <http://git.savannah.gnu.org/cgit/hurd> and integrated into the build system with a switch to enable building PyHurd.
+ Suggested Pencils down. The translator API is easy to use, there are many example translators and there is a full featured settrans command in Python using the easier controlling API which shows how to control the Hurd directly from Python. The code is pushed to <https://github.com/ArneBab/PyHurd> and a git repo at <https://git.savannah.gnu.org/cgit/hurd> and integrated into the build system with a switch to enable building PyHurd.
* *August 22.*
Firm pencils down.
diff --git a/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn
index 200dd5a9..af7cbab6 100644
--- a/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn
+++ b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn
@@ -6,7 +6,7 @@ For that I want to use:
* An up to date debian image (no longer online, but I have a copy here).
* My [Hurd Intro](http://bitbucket.org/ArneBab/hurd_intro),
-* Translators from [hurd-extras](http://www.nongnu.org/hurdextras/) and the [incubator](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), and naturally
+* Translators from [hurd-extras](http://www.nongnu.org/hurdextras/) and the [incubator](https://git.savannah.gnu.org/cgit/hurd/incubator.git/), and naturally
* a lot of apt update; apt upgrade and apt dist-upgrade :) (all worked flawlessly).
## Working
@@ -14,7 +14,6 @@ For that I want to use:
### Generally
# ssh with public key
- apt install random-egd
ssh-keygen
# build tools
diff --git a/community/weblogs/ArneBab/what_we_need.mdwn b/community/weblogs/ArneBab/what_we_need.mdwn
index 4773d5c0..f6008d53 100644
--- a/community/weblogs/ArneBab/what_we_need.mdwn
+++ b/community/weblogs/ArneBab/what_we_need.mdwn
@@ -32,8 +32,8 @@ why not become a Hurd hacker and add your touch? :)
You can reach us in the [[mailing_lists]] and in [[irc]].
-The sourcecode is in our [[source_repositories]] (git). When you want to check sources relevant for you, [DDE](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=dde) might be a good place to start for wireless and sound. USB on the other hand might need work in [gnumach](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/) ([[hacking_info|microkernel/mach/gnumach]]).
+The sourcecode is in our [[source_repositories]] (git). When you want to check sources relevant for you, [DDE](https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=dde) might be a good place to start for wireless and sound. USB on the other hand might need work in [gnumach](https://git.savannah.gnu.org/cgit/hurd/gnumach.git/) ([[hacking_info|microkernel/mach/gnumach]]).
-Besides: “The great next stuff” is in the [incubator git repo](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), including (among others) [clisp](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=clisp) (translators in lisp) and [nsmux](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=nsmux) (dynamically setting translators on files for one command by accessing `file,,translator`).
+Besides: “The great next stuff” is in the [incubator git repo](https://git.savannah.gnu.org/cgit/hurd/incubator.git/), including (among others) [clisp](https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=clisp) (translators in lisp) and [nsmux](https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=nsmux) (dynamically setting translators on files for one command by accessing `file,,translator`).
Happy hacking!