From cb5fffd0ae36d1d7c3ff480deacfbd5e434f233a Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 1 Apr 2009 02:19:34 +0200 Subject: Create Union Mount GSoC task, but don't include in list --- community/gsoc/project_ideas/unionmount.mdwn | 60 ++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 community/gsoc/project_ideas/unionmount.mdwn diff --git a/community/gsoc/project_ideas/unionmount.mdwn b/community/gsoc/project_ideas/unionmount.mdwn new file mode 100644 index 00000000..89b53123 --- /dev/null +++ b/community/gsoc/project_ideas/unionmount.mdwn @@ -0,0 +1,60 @@ +[[meta copyright="Copyright © 2009 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="Union Mounts"]] + +When setting a translator on Hurd -- similar to mounting a file system on UNIX +-- the new node(s) exported by the translator are obscuring the original node +where the translator is set, and any nodes below it in the directory tree. The +translator itself can access the underlying node (which is a very nice feature, +as it allows translators presenting the contents of the node in a different +format); but it's no longer accessible from the "outside". + +Plan9 has a feature where a file system can be mounted in union mode: the new +file system doesn't obscure the mount point in this case, but instead the +contents are combined. (This feature has also been under discussion in Linux +for a couple of years now, under the label "VFS-based union mounts".) + +This kind of union mounts is generally useful, as it's sometimes more +convenient than unioning existing filesystem locations with unionfs -- it's not +necessary to mount a file system that is to be unioned at some external +location first: just union-mount it directly at the target location. + +But union mounts also allow creating passive translator hierarchies: If there +is a passive translator on a parent node, and further passive translators on +child nodes, the union mount allows the child nodes with the further translator +settings still to be visible after the parent translator has started. + +This could be useful for device nodes for example: let's say we have an +ethernet multiplexer at /dev/veth. Now the virtual subnodes could all be +directly under /dev, i.e. /dev/veth0, /dev/veth1 etc., and explicitely refer to +the main /dev/veth node in the translator command line. It would be more +elegant however to store the virtual nodes direcly below the main multiplexer +node -- /dev/veth/0, /dev/veth/1 etc. + +There are two possible approaches how union mounts could be implemented in the +Hurd. The first one is to let the various translators handle union mounts +internally, i.e. let them present the underlying nodes to the clients in +addition to the actual nodes they export themselfs. This probably can be +implemented as some kind of extension to the existing netfs and diskfs +libraries. + +The other possible apporach is less efficient and probably more tricky, but +probably also more generic: create a special unionmount translator, which +serves as a kind of proxy: setting the union-mounted translator on some +internal node; and at the actual mount location, presenting a union of the +nodes exported by this translator, and the nodes from the underlying file +system. + +The goal of this project is implementing union mounts using either of the +approaches described above. (Though it might be useful initially to prototype +both for comparision.) The ethernet multiplexer shall serve as an example use +case -- any changes necessary to allow using it with the union mount +functionality are also to be considered part of the task. -- cgit v1.2.3 From d0f0c0d22f5a3359c50ffe3c1f0ddf6b29a38f53 Mon Sep 17 00:00:00 2001 From: "http://tamathecool.blogspot.com/" Date: Thu, 2 Apr 2009 11:58:42 +0000 Subject: --- hurd/running/gnu/universal_package_manager.mdwn | 1 + 1 file changed, 1 insertion(+) diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index 440f1122..5a160409 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -151,3 +151,4 @@ To join the project just list your name below. 5. Nidhin Raghavan 6. Ajish.B 7. Ambili.B + 8. Abhradip Mukherjee -- cgit v1.2.3 From 7fc9ccdc82999e02ebe587b7775bb7abd1f00440 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 4 Apr 2009 19:08:51 +0200 Subject: Application time -> evaluation time. --- community/gsoc.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index 0986f528..ed1f7a52 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -23,8 +23,8 @@ always open to introducing newcomers to the world of the GNU Hurd outside of any Google Summer of whatever project. Just pick a task from the list pointed to below on this page and get in touch with us! -Application for GSoC projects is possible [on Google's -site](http://code.google.com/soc/) until April 3rd. +The GSoC 2009 student application time has come to an end -- we are now +evaluating your applications. # History -- cgit v1.2.3 From 8c376bc34df3fa1895ba4e975c5fa6fdf08c990d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 4 Apr 2009 20:48:15 +0200 Subject: Update description for flubber. --- public_hurd_boxen.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index bc902384..fd54a2c6 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -1,4 +1,4 @@ -[[meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, +[[meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, Inc."]] [[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable @@ -13,7 +13,7 @@ Here are some Hurd boxes that users have made available to the public: [[table class="table_style_1" data=""" "Host Name","Operator","Access","Distro","Machine Specs","Comments" -"flubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2250","Debian","PII 550 MHz; 384 MiB","used for the wiki, and a bit short on disk space, so please don't use for general work" +"flubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2250","Debian","Celeron; 2.2 GHz; 333 MiB","domU on zenhost" "clubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2251","Debian","PIII 1 GHz; 384 MiB" "gnubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2254","Debian","PII 733 MHz; 384 MiB" "goober.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2255","Debian","?" -- cgit v1.2.3 From 3da49ff8575e64c659282bf5f7bd1f39b204a334 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 4 Apr 2009 20:48:42 +0200 Subject: hurd.nipl.net has been unreachable for many months. --- public_hurd_boxen.mdwn | 3 --- 1 file changed, 3 deletions(-) diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index fd54a2c6..4b9290fe 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -17,7 +17,6 @@ Here are some Hurd boxes that users have made available to the public: "clubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2251","Debian","PIII 1 GHz; 384 MiB" "gnubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2254","Debian","PII 733 MHz; 384 MiB" "goober.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2255","Debian","?" -"hurd.nipl.net","[[AlastairPoole]]","ssh; port 24","GNU","AMD Sempron 2800 MHz","not sure if this machine is still alive" """]] To request an account on the `*.bddebian.com` machines either contact @@ -25,8 +24,6 @@ To request an account on the `*.bddebian.com` machines either contact or send email to . Also use these contact addresses for requesting support with respect to software installations, etc. -For the `hurd.nipl.net` host, please see . - For a list of people using the Hurd in production systems, please see [[Hurd/WhoRunsGNU]]. -- cgit v1.2.3 From c703b8b98e427c143d9c7b162653dc7d24e49d15 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 17:44:36 +0200 Subject: Update copyright year and formatting. --- microkernel/mach/gnumach/ports/xen.mdwn | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index b3d8a3e4..b9e2fac7 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2007, 2008, 2009 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 @@ -16,7 +17,7 @@ is included in the section entitled You can either get binaries at or build them yourself. -- Copy `gnumach-xen-pae` and `hurd-modules` to your dom0 /boot. If you still have a non-PAE hypervisor, use gnumach-xen-nonpae instead. +- Copy `gnumach-xen-pae` and `hurd-modules` to your dom0 /boot. If you still have a non-PAE hypervisor, use `gnumach-xen-nonpae` instead. - Copy `hurd` into `/etc/xen`, edit it for fixing access to your hurd / and swap ## GNU/Hurd system -- cgit v1.2.3 From 714738c3aa0d5625cc7dccf0e8c3f1414b8930c6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 18:39:14 +0200 Subject: unsorted/PortingIssues -> hurd/porting/guidelines --- community/gsoc/project_ideas/maxpath.mdwn | 2 +- hurd/faq/old-stuff.mdwn | 2 +- hurd/porting/guidelines.mdwn | 281 +++++++++++++++++++++++++ hurd/running/debian/GnuDebianRelationship.mdwn | 4 +- hurd/running/distrib.mdwn | 2 +- unsorted/PortingIssues.mdwn | 270 ------------------------ 6 files changed, 286 insertions(+), 275 deletions(-) create mode 100644 hurd/porting/guidelines.mdwn delete mode 100644 unsorted/PortingIssues.mdwn diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn index 992b91ee..d78297d5 100644 --- a/community/gsoc/project_ideas/maxpath.mdwn +++ b/community/gsoc/project_ideas/maxpath.mdwn @@ -33,7 +33,7 @@ by `char *foo`, and using dynamic memory allocation, i.e. e.g. a loop that tries geometrically growing sizes. Sometimes this is tricky, but more often not very hard. Sometimes it is even trivial because the GNU system has proper replacements. See the corresponding section of the -[[Porting_issues_page|unsorted/PortingIssues]] for more details. With a bit of +[[porting_guidelines_page|hurd/porting/guidelines]] for more details. With a bit of practice, it should be easily possible to fix several programs per day. The goal of this project is to fix the PATH_MAX and related problems in a diff --git a/hurd/faq/old-stuff.mdwn b/hurd/faq/old-stuff.mdwn index 1bcc09a0..e4132d50 100644 --- a/hurd/faq/old-stuff.mdwn +++ b/hurd/faq/old-stuff.mdwn @@ -28,7 +28,7 @@ If you still have problems, do not hesitate to make use of the [[mailing_lists]] * These are different versions of the Mach microkernel that supports the Hurd that runs on top of it. For more info, see [[Mach]] * **_What software is available for GNU?_** - * Most packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in . Programs which need pthreads, including [GNOME](http://www.gnome.org), [KDE](http://www.kde.org), [Mozilla](http://www.mozilla.org), [OpenOffice](http://www.openoffice.org), [SDL](http://www.libsdl.org), etc. are being worked on currently using Neal Walfields libpthreads. See the [[Distrib/PortingIssues]] document for some common build problems and their solutions. + * Most packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in . Programs which need pthreads, including [GNOME](http://www.gnome.org), [KDE](http://www.kde.org), [Mozilla](http://www.mozilla.org), [OpenOffice](http://www.openoffice.org), [SDL](http://www.libsdl.org), etc. are being worked on currently using Neal Walfields libpthreads. See the [[porting/guidelines]] document for some common build problems and their solutions. * If you can't fetch a package with "apt-get install ", try building it from source: "apt-get source && cd <package\_dir> && debian/rules binary". * As of January 2007, 50% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome. diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn new file mode 100644 index 00000000..ee27c9be --- /dev/null +++ b/hurd/porting/guidelines.mdwn @@ -0,0 +1,281 @@ +[[meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 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]]."]]"""]] + +## Table of Contents + +%TOC% + +## Overview + +This is a recompilation of common porting problems and their solutions. Information is gathered from the following sources: + +* [Debian GNU/Hurd port guidelines](http://www.debian.org/ports/hurd/hurd-devel-debian) + +* [James Morrison's GNU/Hurd pages](http://hurd.dyndns.org/) + +as well as other misc. sources. + +First of all, see [[BtsFiling]] if you need instructions on manipulating [Debian](http://www.debian.org/) source packages and submitting patches to their [Bug Tracking System](http://bugs.debian.org/). + +## System API limitations + +Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. + +We maintain a separate Wiki page for information on these bugs, see [[Distrib/SystemAPILimits]] + +If you think you can fix any of them and send a patch to the debian BTS, that'd be much appreciated. You may ask in for details or questions on the bug. + +## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) + +If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. + +The following macros have been found in this offending situation (add more if you find them): `PIPE_BUF` + +An example with `sysconf`: (when you find a `sysconf` offending macro, put a better example) + + #ifndef XXX + #define XXX sysconf(_SC_XXX) + #endif + /* offending code using XXX follows */ + +An example with `fpathconf`: + + #ifdef PIPE_BUF + read(fd, buff, PIPE_BUF - 1); + #else + read(fd, buff, fpathconf(fd, _PC_PIPE_BUF) - 1); + #endif + /* note we can't #define PIPE_BUF, because it depends + on the "fd" variable */ + +## Bad File Descriptor + +If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the `open()` invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use `O_RDONLY`, `O_WRONLY` or `O_RDWR`. This bug was observed in the `fortunes` and `mtools` packages for example. + +## `PATH_MAX` / `MAX_PATH` / `MAXPATHLEN` + +Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Alioth patch](http://alioth.debian.org/tracker/download.php/30628/410472/303735/1575/cpulimit-path-max-fix.patch). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. + +## `ARG_MAX` + +Same rationale as `PATH_MAX`. There is no limit on the number of arguments. + +## `IOV_MAX` + +Same rationale as `PATH_MAX`. There is no limit on the number of iovec items. + +## `MAXHOSTNAMELEN` + +Same as `PATH_MAX`. When you find a `gethostname()` function, which acts on a static buffer, you can replace it with Neal's [xgethostname function](http://ftp.walfield.org/pub/people/neal/xgethostname/) which returns the hostname as a dynamic buffer. For example: + +Buggy code: + + char localhost[MAXHOSTNAMELEN]; + ... + gethostname(localhost, sizeof(localhost)); + +Fixed code: + + #include "xgethostname.h" + ... + char *localhost; + ... + localhost = xgethostname(); + if (! localhost) + { + perror ("xgethostname"); + return ERROR; + } + ... + /* use LOCALHOST. */ + free (localhost); + +## `NOFILE` + +Replace with `getrlimit(RLIMIT_NOFILE,...)` + +## GNU specific `#define` + +If you need to include specific code for GNU/Hurd using `#if` ... `#endif`, then you can use the `__GNU__` symbol to do so. But think (at least) thrice! before doing so. In most situations, this is completely unnecessary and will create more problems than it may solve. Better ask on the mailing list how to do it right if you can't think of a better solution. + +## `sys_errlist[]` vs. `strerror()` + +If a program has only support for `sys_errlist[]` you will have to do some work to make it compile on GNU, which has dropped support for it and does only provide `strerror()`. Steinar Hamre writes about `strerror()`: + +`strerror()` should be used because: + +* It is the modern, POSIX way. +* It is localized. +* It handles invalid signals/numbers out of range. (better errorhandling and not a buffer-overflow-candidate/security risk) + +`strerror()` should always be used if it is available. Unfortunaly there are still some old non-POSIX systems that do not have `strerror()`, only `sys_errlist[]`. + +Today, only supporting `strerror()` is far better than only supporting `sys_errlist[]`. The best (from a portability viewpoint), however is supporting both. For configure.in, you will need: + + AC_CHECK_FUNCS(strerror) + +To `config.h.in`, you need to add: + + #undef HAVE_STRERROR + +Then something like: + + #ifndef HAVE_STRERROR + static char * + private_strerror (errnum) + int errnum; + { + extern char *sys_errlist[]; + extern int sys_nerr; + + if (errnum > 0 && errnum <= sys_nerr) + return sys_errlist[errnum]; + + return "Unknown system error"; + } + #define strerror private_strerror + #endif /* HAVE_STRERROR */ + +You can for example look in the latest coreutils (the above is a simplified version of what I found there.) Patches should of course be sent to upstream maintainers, this is very useful even for systems with a working `sys_errlist[]`. + +Of course, if you don't care about broken systems (like MS-DOG) not supporting `strerror()` you can just replace `sys_errlist[]` directly (upstream might not accept your patch, but debian should have no problem) + +## C++, `error_t` and `E*` + +On the Hurd, `error_t` is an enumeration of the `E*` constants. However, C++ +does not like `E*` integer macros being directly assigned to that enumeration. In short, replace + + error_t err = EINTR; + +by + + error_t err = error_t(EINTR); + +## Filenames ending in a slash \`/' + +Those are evil if they don't exist and you want to name a directory this way. For example, `mkdir foobar/` will not work on GNU. This is POSIX compatible. POSIX says that the path of a directory may have slashes appended to it. But the directory does not exist yet, so the path does not refer to a directory, and hence trailing slashes are not guaranteed to work. Just drop the slashes, and you're fine. + +## Missing `termio.h` + +Change it to use `termios.h` (check for it properly with autoconf `HAVE_TERMIOS_H` or the `__GLIBC__` macro) + +Also, change calls to `ioctl(fd, TCGETS, ...)` and `ioctl(fd, TCSETS, ...)` with `tcgetattr(fd, ...)` and `tcsetattr(fd, ...)`. + +## `AC_HEADER_TERMIO` + +The autoconf check for `AC_HEADER_TERMIO` tryes to check for termios, but it's only really checking for termio in `termios.h`. It is better to use `AC_CHECK_HEADERS(termio.h termios.h)` + +## missing `_IOT` + +This comes from ioctls. Fixing this is easy if the structure members can be expressed by using the _IOT() macro, else it's simply impossible... See `bits/termios.h` for an instance: + +`#define _IOT_termios /* Hurd ioctl type field. */ \ + _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)` + +because `struct termios` holds 4 members of type `tcflag_ts`, then `NCCS` +members of type `cc_tsi` and finaly 2 members of type `speed_ts`. + +As you can see, this limits the number of kinds of members to 3, and in +addition to that (see the bitfield described in `ioctls.h`), the third +kind of member is limited to 3 members. However, since at the API +compatibility layer you are generally allowed to reorder fields in +structures, you can usually manage to fit into these limits. + +Note: if a field member is a pointer, then the ioctl can't be expressed +this way, and that makes sense, since the server you're talking to +doesn't have direct access to your memory. Ways other than ioctls must +then be found. + +## `SA_SIGINFO` + +Not implemented, packages may be fixed for working around this: use void sighandler(int num) prototype and sa_handler field. + +## `SOL_IP` + +Not implemented yet. + +## `HZ` + +Linuxish and doesn't even make sense since the value may vary according to the running kernel. Should use `sysconf(_SC_CLK_TCK)` or `CLK_TCK` instead. + +## `SIOCDEVPRIVATE` + +Oh, we should probably provide it. + +## `MAP_NORESERVE` + +Not POSIX, but we could implement it. + +## `O_DIRECT` + +Long story to implement. + +## `PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP` + +We could easily provide it; + +## `PTHREAD_STACK_MIN` + +We should actually provide it. + +## `linux/types.h` or `asm/types.h` + +These are not POSIX, `sys/types.h` and `stdint.h` should be used instead. + +## `iopl` + +Not supported. Try to replace with `ioperm(0, 65536, 1)` (conditionned with `__GNU__` as that will not work in Linux). + +## `semget`, `sem_open` + +Not implemented, will always fail. Use `sem_init()` instead if possible. + +## `net/if_arp.h`, `net/ethernet.h`, etc. + +Not implemented, not POSIX. Try to disable the feature in the package. + +## broken libc6 dependency + +Some packages use an erroneous dependency on `libc6-dev`. This is incorrect because `libc6` is specific to GNU/Linux. The corresponding package for GNU is `libc0.3-dev` but other OSes will have different ones. You can locate the problem in the `debian/control` file of the source tree. Typical solutions include detecting the OS using `dpkg-architecture` and hardcoding the soname, or better, use a logical OR. eg: `libc6-dev | libc0.3-dev | libc-dev`. The `libc-dev` is a virtual package that works for any soname but you have to put it only as the last option. + +---- + +## ChangeLog + +-- [[Main/TWikiGuest]] - 13 Jan 2005 + +Fix xgethostname example. - Neal + +-- [[Main/RobertMillan]] - 22 Jul 2002 + +Formatting and minor grammatical fixes. + +-- [[Main/JoachimNilsson]] - 09 Sep 2002 + +Added more examples and misc semantical fixes. + +-- [[Main/RobertMillan]] - 05 Oct 2002 + +Added `xgethostname` example. + +-- [[Main/RobertMillan]] - 15 Nov 2002 + +Added broken libc6 dependency + +-- [[Main/RobertMillan]] - 21 Nov 2002 + +Text formatting. + +-- Ognyan Kulev - 12 Mar 2003 + +Added `ioctl` entry. + +-- [[Main/RobertMillan]] - 19 Mar 2003 diff --git a/hurd/running/debian/GnuDebianRelationship.mdwn b/hurd/running/debian/GnuDebianRelationship.mdwn index ede808c8..94fd6265 100644 --- a/hurd/running/debian/GnuDebianRelationship.mdwn +++ b/hurd/running/debian/GnuDebianRelationship.mdwn @@ -2,11 +2,11 @@ I have hesitated in starting this page due to the sensitive nature of this relat This is a work in progress. Please email me directly if you have comments or suggestions. -* Debian Advantages of Hurd [[Distrib/PortingIssues]] Efforts +* Debian Advantages of Hurd [[porting/guidelines]] Efforts * One of the first ports to non-Linux system along with \*BSD and win32. * Official GNU system distribution. -* Debian Disadvantages of Hurd [[Distrib/PortingIssues]] Efforts +* Debian Disadvantages of Hurd [porting/guidelines]] Efforts * Perceived zealous GNU and FSF promotion. * Hurd Port Advantages of Debian diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 935c0c2d..607b50af 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -68,7 +68,7 @@ about getting applications to work (if possible).
-
[[PortingIssues]] FAQ
+
[[porting/guidelines]] FAQ
What does it take to move a piece of Debian packaged software to the GNU/Hurd port?
diff --git a/unsorted/PortingIssues.mdwn b/unsorted/PortingIssues.mdwn deleted file mode 100644 index 03980ef3..00000000 --- a/unsorted/PortingIssues.mdwn +++ /dev/null @@ -1,270 +0,0 @@ -## Table of Contents - -%TOC% - -## Overview - -This is a recompilation of common porting problems and their solutions. Information is gathered from the following sources: - -* [Debian GNU/Hurd port guidelines](http://www.debian.org/ports/hurd/hurd-devel-debian) - -* [James Morrison's GNU/Hurd pages](http://hurd.dyndns.org/) - -as well as other misc. sources. - -First of all, see [[BtsFiling]] if you need instructions on manipulating [Debian](http://www.debian.org/) source packages and submitting patches to their [Bug Tracking System](http://bugs.debian.org/). - -## System API limitations - -Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. - -We maintain a separate Wiki page for information on these bugs, see [[Distrib/SystemAPILimits]] - -If you think you can fix any of them and send a patch to the debian BTS, that'd be much appreciated. You may ask in for details or questions on the bug. - -## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) - -If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. - -The following macros have been found in this offending situation (add more if you find them): `PIPE_BUF` - -An example with `sysconf`: (when you find a `sysconf` offending macro, put a better example) - - #ifndef XXX - #define XXX sysconf(_SC_XXX) - #endif - /* offending code using XXX follows */ - -An example with `fpathconf`: - - #ifdef PIPE_BUF - read(fd, buff, PIPE_BUF - 1); - #else - read(fd, buff, fpathconf(fd, _PC_PIPE_BUF) - 1); - #endif - /* note we can't #define PIPE_BUF, because it depends - on the "fd" variable */ - -## Bad File Descriptor - -If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the `open()` invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use `O_RDONLY`, `O_WRONLY` or `O_RDWR`. This bug was observed in the `fortunes` and `mtools` packages for example. - -## `PATH_MAX` / `MAX_PATH` / `MAXPATHLEN` - -Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Alioth patch](http://alioth.debian.org/tracker/download.php/30628/410472/303735/1575/cpulimit-path-max-fix.patch). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. - -## `ARG_MAX` - -Same rationale as `PATH_MAX`. There is no limit on the number of arguments. - -## `IOV_MAX` - -Same rationale as `PATH_MAX`. There is no limit on the number of iovec items. - -## `MAXHOSTNAMELEN` - -Same as `PATH_MAX`. When you find a `gethostname()` function, which acts on a static buffer, you can replace it with Neal's [xgethostname function](http://ftp.walfield.org/pub/people/neal/xgethostname/) which returns the hostname as a dynamic buffer. For example: - -Buggy code: - - char localhost[MAXHOSTNAMELEN]; - ... - gethostname(localhost, sizeof(localhost)); - -Fixed code: - - #include "xgethostname.h" - ... - char *localhost; - ... - localhost = xgethostname(); - if (! localhost) - { - perror ("xgethostname"); - return ERROR; - } - ... - /* use LOCALHOST. */ - free (localhost); - -## `NOFILE` - -Replace with `getrlimit(RLIMIT_NOFILE,...)` - -## GNU specific `#define` - -If you need to include specific code for GNU/Hurd using `#if` ... `#endif`, then you can use the `__GNU__` symbol to do so. But think (at least) thrice! before doing so. In most situations, this is completely unnecessary and will create more problems than it may solve. Better ask on the mailing list how to do it right if you can't think of a better solution. - -## `sys_errlist[]` vs. `strerror()` - -If a program has only support for `sys_errlist[]` you will have to do some work to make it compile on GNU, which has dropped support for it and does only provide `strerror()`. Steinar Hamre writes about `strerror()`: - -`strerror()` should be used because: - -* It is the modern, POSIX way. -* It is localized. -* It handles invalid signals/numbers out of range. (better errorhandling and not a buffer-overflow-candidate/security risk) - -`strerror()` should always be used if it is available. Unfortunaly there are still some old non-POSIX systems that do not have `strerror()`, only `sys_errlist[]`. - -Today, only supporting `strerror()` is far better than only supporting `sys_errlist[]`. The best (from a portability viewpoint), however is supporting both. For configure.in, you will need: - - AC_CHECK_FUNCS(strerror) - -To `config.h.in`, you need to add: - - #undef HAVE_STRERROR - -Then something like: - - #ifndef HAVE_STRERROR - static char * - private_strerror (errnum) - int errnum; - { - extern char *sys_errlist[]; - extern int sys_nerr; - - if (errnum > 0 && errnum <= sys_nerr) - return sys_errlist[errnum]; - - return "Unknown system error"; - } - #define strerror private_strerror - #endif /* HAVE_STRERROR */ - -You can for example look in the latest coreutils (the above is a simplified version of what I found there.) Patches should of course be sent to upstream maintainers, this is very useful even for systems with a working `sys_errlist[]`. - -Of course, if you don't care about broken systems (like MS-DOG) not supporting `strerror()` you can just replace `sys_errlist[]` directly (upstream might not accept your patch, but debian should have no problem) - -## C++, `error_t` and `E*` - -On the Hurd, `error_t` is an enumeration of the `E*` constants. However, C++ -does not like `E*` integer macros being directly assigned to that enumeration. In short, replace - - error_t err = EINTR; - -by - - error_t err = error_t(EINTR); - -## Filenames ending in a slash \`/' - -Those are evil if they don't exist and you want to name a directory this way. For example, `mkdir foobar/` will not work on GNU. This is POSIX compatible. POSIX says that the path of a directory may have slashes appended to it. But the directory does not exist yet, so the path does not refer to a directory, and hence trailing slashes are not guaranteed to work. Just drop the slashes, and you're fine. - -## Missing `termio.h` - -Change it to use `termios.h` (check for it properly with autoconf `HAVE_TERMIOS_H` or the `__GLIBC__` macro) - -Also, change calls to `ioctl(fd, TCGETS, ...)` and `ioctl(fd, TCSETS, ...)` with `tcgetattr(fd, ...)` and `tcsetattr(fd, ...)`. - -## `AC_HEADER_TERMIO` - -The autoconf check for `AC_HEADER_TERMIO` tryes to check for termios, but it's only really checking for termio in `termios.h`. It is better to use `AC_CHECK_HEADERS(termio.h termios.h)` - -## missing `_IOT` - -This comes from ioctls. Fixing this is easy if the structure members can be expressed by using the _IOT() macro, else it's simply impossible... See `bits/termios.h` for an instance: - -`#define _IOT_termios /* Hurd ioctl type field. */ \ - _IOT (_IOTS (tcflag_t), 4, _IOTS (cc_t), NCCS, _IOTS (speed_t), 2)` - -because `struct termios` holds 4 members of type `tcflag_ts`, then `NCCS` -members of type `cc_tsi` and finaly 2 members of type `speed_ts`. - -As you can see, this limits the number of kinds of members to 3, and in -addition to that (see the bitfield described in `ioctls.h`), the third -kind of member is limited to 3 members. However, since at the API -compatibility layer you are generally allowed to reorder fields in -structures, you can usually manage to fit into these limits. - -Note: if a field member is a pointer, then the ioctl can't be expressed -this way, and that makes sense, since the server you're talking to -doesn't have direct access to your memory. Ways other than ioctls must -then be found. - -## `SA_SIGINFO` - -Not implemented, packages may be fixed for working around this: use void sighandler(int num) prototype and sa_handler field. - -## `SOL_IP` - -Not implemented yet. - -## `HZ` - -Linuxish and doesn't even make sense since the value may vary according to the running kernel. Should use `sysconf(_SC_CLK_TCK)` or `CLK_TCK` instead. - -## `SIOCDEVPRIVATE` - -Oh, we should probably provide it. - -## `MAP_NORESERVE` - -Not POSIX, but we could implement it. - -## `O_DIRECT` - -Long story to implement. - -## `PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP` - -We could easily provide it; - -## `PTHREAD_STACK_MIN` - -We should actually provide it. - -## `linux/types.h` or `asm/types.h` - -These are not POSIX, `sys/types.h` and `stdint.h` should be used instead. - -## `iopl` - -Not supported. Try to replace with `ioperm(0, 65536, 1)` (conditionned with `__GNU__` as that will not work in Linux). - -## `semget`, `sem_open` - -Not implemented, will always fail. Use `sem_init()` instead if possible. - -## `net/if_arp.h`, `net/ethernet.h`, etc. - -Not implemented, not POSIX. Try to disable the feature in the package. - -## broken libc6 dependency - -Some packages use an erroneous dependency on `libc6-dev`. This is incorrect because `libc6` is specific to GNU/Linux. The corresponding package for GNU is `libc0.3-dev` but other OSes will have different ones. You can locate the problem in the `debian/control` file of the source tree. Typical solutions include detecting the OS using `dpkg-architecture` and hardcoding the soname, or better, use a logical OR. eg: `libc6-dev | libc0.3-dev | libc-dev`. The `libc-dev` is a virtual package that works for any soname but you have to put it only as the last option. - ----- - -## ChangeLog - --- [[Main/TWikiGuest]] - 13 Jan 2005 - -Fix xgethostname example. - Neal - --- [[Main/RobertMillan]] - 22 Jul 2002 - -Formatting and minor grammatical fixes. - --- [[Main/JoachimNilsson]] - 09 Sep 2002 - -Added more examples and misc semantical fixes. - --- [[Main/RobertMillan]] - 05 Oct 2002 - -Added `xgethostname` example. - --- [[Main/RobertMillan]] - 15 Nov 2002 - -Added broken libc6 dependency - --- [[Main/RobertMillan]] - 21 Nov 2002 - -Text formatting. - --- Ognyan Kulev - 12 Mar 2003 - -Added `ioctl` entry. - --- [[Main/RobertMillan]] - 19 Mar 2003 -- cgit v1.2.3 From e016e16505f5b97959dba8edc05411ce17bd7b67 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 18:44:10 +0200 Subject: unsorted/SystemAPILimits -> hurd/porting/system_api_limitations --- hurd/porting/guidelines.mdwn | 2 +- hurd/porting/system_api_limitations.mdwn | 41 ++++++++++++++++++++++++++++++++ hurd/running/distrib.mdwn | 2 +- unsorted/SystemAPILimits.mdwn | 30 ----------------------- 4 files changed, 43 insertions(+), 32 deletions(-) create mode 100644 hurd/porting/system_api_limitations.mdwn delete mode 100644 unsorted/SystemAPILimits.mdwn diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index ee27c9be..f37a17e2 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -29,7 +29,7 @@ First of all, see [[BtsFiling]] if you need instructions on manipulating [Debian Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. -We maintain a separate Wiki page for information on these bugs, see [[Distrib/SystemAPILimits]] +We maintain a separate Wiki page for information on these bugs, see [[System_API_Limitations]] If you think you can fix any of them and send a patch to the debian BTS, that'd be much appreciated. You may ask in for details or questions on the bug. diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn new file mode 100644 index 00000000..d536f764 --- /dev/null +++ b/hurd/porting/system_api_limitations.mdwn @@ -0,0 +1,41 @@ +[[meta copyright="Copyright © 2003, 2004, 2005, 2009 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]]."]]"""]] + +## API Limitations of the GNU system + +---- + +Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. + +Taken from the bug lists in debian BTS. If you find more of them (and it is clear in the bug log that it is a bug), please add them to the list below. See: + +* ([source](http://packages.qa.debian.org/h/hurd.html) and [binary](http://packages.debian.org/hurd) debs not synchronized) +* ([binary](http://packages.debian.org/hurd-dev)) +* ([source](http://packages.qa.debian.org/g/glibc.html) & [binary](http://packages.debian.org/libc0.3) debs) +* ([binary](http://packages.debian.org/libc0.3-dev)) + +---- + +These are the known system API limits that have porting implications. + +**_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** + +**_[\#184565](http://bugs.debian.org/184565): libc0.3: missing shm\* functions (from ``)_**
**breaks:** cdrtools
**error:** warning: shm\* is not implemented and will always fail + +**_[\#190581](http://bugs.debian.org/190581): nice() doesn't work_**
**breaks:** coreutils
**error:** `nice()` doesn't take effect on some situations + +**_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**
**breaks:** fam, gail
**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) + +**_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**
**breaks:** gnome-session (and others) from running
**error:** misc lock-related errors + +-- [[Main/RobertMillan]] - 01 May 2003 + +Text formatting.
-- [[Main/OgnyanKulev]] - 02 May 2003 diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 607b50af..77736a45 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -95,7 +95,7 @@ about getting applications to work (if possible). * GNU [Coding Standards](http://www.gnu.org/prep/standards.html) * [[TestSuites]] - Posix, Perl, results feedback, etc. * [[Documentation]] -* [[SystemAPILimits]] +* [[System_API_Limitations]] * [[CodeAnnouncements]] - Recent coding projects related to the Hurd
diff --git a/unsorted/SystemAPILimits.mdwn b/unsorted/SystemAPILimits.mdwn deleted file mode 100644 index 8930ef9c..00000000 --- a/unsorted/SystemAPILimits.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -## API Limitations of the GNU system - ----- - -Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. - -Taken from the bug lists in debian BTS. If you find more of them (and it is clear in the bug log that it is a bug), please add them to the list below. See: - -* ([source](http://packages.qa.debian.org/h/hurd.html) and [binary](http://packages.debian.org/hurd) debs not synchronized) -* ([binary](http://packages.debian.org/hurd-dev)) -* ([source](http://packages.qa.debian.org/g/glibc.html) & [binary](http://packages.debian.org/libc0.3) debs) -* ([binary](http://packages.debian.org/libc0.3-dev)) - ----- - -These are the known system API limits that have porting implications. - -**_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** - -**_[\#184565](http://bugs.debian.org/184565): libc0.3: missing shm\* functions (from ``)_**
**breaks:** cdrtools
**error:** warning: shm\* is not implemented and will always fail - -**_[\#190581](http://bugs.debian.org/190581): nice() doesn't work_**
**breaks:** coreutils
**error:** `nice()` doesn't take effect on some situations - -**_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**
**breaks:** fam, gail
**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) - -**_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**
**breaks:** gnome-session (and others) from running
**error:** misc lock-related errors - --- [[Main/RobertMillan]] - 01 May 2003 - -Text formatting.
-- [[Main/OgnyanKulev]] - 02 May 2003 -- cgit v1.2.3 From 2276f5afa71d11d3016ae2ade7b8e383c03eef68 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 18:50:28 +0200 Subject: hurd/porting: New page. --- hurd.mdwn | 1 + hurd/porting.mdwn | 14 ++++++++++++++ hurd/running/debian/porting.mdwn | 5 ++++- 3 files changed, 19 insertions(+), 1 deletion(-) create mode 100644 hurd/porting.mdwn diff --git a/hurd.mdwn b/hurd.mdwn index ee40d6da..4bf28827 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -92,6 +92,7 @@ in the *unstable* branch of the Debian archive. * [[libhello_example]] -- Hurd library example * [[libnetfs]] -- short introductory material * [[IO_Path]] +* [[Porting]] * [[Debugging]] * [Hurd Sourcecode Reference](http://www.htu.tugraz.at/~past/hurd/global/): Searchable and browsable index of the code. * [[Networking]] diff --git a/hurd/porting.mdwn b/hurd/porting.mdwn new file mode 100644 index 00000000..d1900f0b --- /dev/null +++ b/hurd/porting.mdwn @@ -0,0 +1,14 @@ +[[meta copyright="Copyright © 2009 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]]."]]"""]] + + * [[Guidelines]] + * [[System_API_Limitations]] + + * Debian: [[running/debian/Porting]] diff --git a/hurd/running/debian/porting.mdwn b/hurd/running/debian/porting.mdwn index eb46c4c3..3ad25e01 100644 --- a/hurd/running/debian/porting.mdwn +++ b/hurd/running/debian/porting.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2007, 2008, 2009 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 @@ -30,6 +31,8 @@ that need someone to work on them. When you have a patch to submit, please adhere to the [[patch_submission]] guidelines. +There is also further information available about [[hurd/porting]]. + [[inline pages="hurd/running/debian/porting/* and !*/discussion" show=0 -- cgit v1.2.3 From 5fb5cd59948b112aaaaa24c406bc1fe7f31a0382 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 19:01:48 +0200 Subject: Remove superseded page. --- hurd/running/debian/BtsFiling.mdwn | 52 -------------------------------------- hurd/running/distrib.mdwn | 2 +- 2 files changed, 1 insertion(+), 53 deletions(-) delete mode 100644 hurd/running/debian/BtsFiling.mdwn diff --git a/hurd/running/debian/BtsFiling.mdwn b/hurd/running/debian/BtsFiling.mdwn deleted file mode 100644 index 90f451a8..00000000 --- a/hurd/running/debian/BtsFiling.mdwn +++ /dev/null @@ -1,52 +0,0 @@ -When you encounter any GNU/Hurd related bugs in a Debian package you can fix, please use the Debian BTS (Bug Tracking System) to report them. - -Managing Debian packages and using the BTS is quite simple. If you're new to Debian, here's a short guide: - -* first of all, check [http://bugs.debian.org/<package>](http://bugs.debian.org) to ensure the problem is not in the BTS already. This is possible for packages and bug numbers. [[TWiki/InterWikis]] is a shorthand way of linking to bugs and packages from this site. i.e. [[DebianBug]]:hurd [[DebianPackage]]:oskit -* you can fetch package sources with: - - apt-get source - -note: this should unpack already - -* and unpack with: - - dpkg-source -x x-y_z.dsc - -* then get all dependencies: - - apt-get -y build-dep - -note: if some dependencies are missing, it most probably means you have to port them first. follow this instructions recursively until done - - :) - -* Debian packages have a makefile in debian/rules, with (at least) the following targets:
-
build
-
Yup, to build
-
binary
-
Generates deb files in ../
-
clean
-
Full clean
-
- -* when you have a patch, send it to the BTS using the reportbug utility (or manually as explained in . The following parameters should be used: - - Severity: important (when the package is unbuildable or uninstallable, lower otherwise.) - Tags: sid, patch - -* be nice to the maintainers. most are friendly and cooperative, and a few could annoy you for months before applying. Be patient. - -Read for extensive documentation on the BTS. - --- [[Main/RobertMillan]] - 10 Jun 2002 - ----- - -Wikification & small changes. - --- [[Main/JoachimNilsson]] - 24 Jun 2002 - -Updates with the new [[TWiki/InterWikis]] rules. - --- [[Main/GrantBow]] - 15 Jan 2003 diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 77736a45..bbf0a380 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -79,7 +79,7 @@ about getting applications to work (if possible).
Debain Infrastructure
-
Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[BtsFiling]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd &amp; turtle efforts.
+
Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[debian/patch_submission]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd &amp; turtle efforts.
-- cgit v1.2.3 From 661c83c479f13d8e7c1e5d52946a7cce19b0a67f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 19:11:59 +0200 Subject: Rework introduction and remove changelog. --- hurd/porting/guidelines.mdwn | 60 ++++++-------------------------------------- 1 file changed, 8 insertions(+), 52 deletions(-) diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index f37a17e2..b96df856 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -9,29 +9,19 @@ 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]]."]]"""]] -## Table of Contents +This is a compilation of common porting problems and their solutions. -%TOC% -## Overview +Additionally to this page, also see the section *General Porting Issues* of +, as well as further Debian-specific [[running/debian/porting]] +information. -This is a recompilation of common porting problems and their solutions. Information is gathered from the following sources: +There is a separate page about [[System_API_Limitations]]. -* [Debian GNU/Hurd port guidelines](http://www.debian.org/ports/hurd/hurd-devel-debian) +You may ask on the [[mailing_lists/bug-hurd]] mailing list for details or +questions about fixing bugs. -* [James Morrison's GNU/Hurd pages](http://hurd.dyndns.org/) - -as well as other misc. sources. - -First of all, see [[BtsFiling]] if you need instructions on manipulating [Debian](http://www.debian.org/) source packages and submitting patches to their [Bug Tracking System](http://bugs.debian.org/). - -## System API limitations - -Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. - -We maintain a separate Wiki page for information on these bugs, see [[System_API_Limitations]] - -If you think you can fix any of them and send a patch to the debian BTS, that'd be much appreciated. You may ask in for details or questions on the bug. ## Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) @@ -245,37 +235,3 @@ Not implemented, not POSIX. Try to disable the feature in the package. ## broken libc6 dependency Some packages use an erroneous dependency on `libc6-dev`. This is incorrect because `libc6` is specific to GNU/Linux. The corresponding package for GNU is `libc0.3-dev` but other OSes will have different ones. You can locate the problem in the `debian/control` file of the source tree. Typical solutions include detecting the OS using `dpkg-architecture` and hardcoding the soname, or better, use a logical OR. eg: `libc6-dev | libc0.3-dev | libc-dev`. The `libc-dev` is a virtual package that works for any soname but you have to put it only as the last option. - ----- - -## ChangeLog - --- [[Main/TWikiGuest]] - 13 Jan 2005 - -Fix xgethostname example. - Neal - --- [[Main/RobertMillan]] - 22 Jul 2002 - -Formatting and minor grammatical fixes. - --- [[Main/JoachimNilsson]] - 09 Sep 2002 - -Added more examples and misc semantical fixes. - --- [[Main/RobertMillan]] - 05 Oct 2002 - -Added `xgethostname` example. - --- [[Main/RobertMillan]] - 15 Nov 2002 - -Added broken libc6 dependency - --- [[Main/RobertMillan]] - 21 Nov 2002 - -Text formatting. - --- Ognyan Kulev - 12 Mar 2003 - -Added `ioctl` entry. - --- [[Main/RobertMillan]] - 19 Mar 2003 -- cgit v1.2.3 From 6e2b09121895bb07d88b86ba1374d68d0cde9df1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 5 Apr 2009 19:15:39 +0200 Subject: Rework introduction and remove changelog. --- hurd/porting/system_api_limitations.mdwn | 24 +++++++----------------- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index d536f764..83a54654 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -9,20 +9,14 @@ 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]]."]]"""]] -## API Limitations of the GNU system +Sometimes building or running a program will fail due to bugs in the system API +implementation (in [[glibc]] and the [[Hurd]]). Make sure you check this list +and know them before porting, otherwise you'll end up debugging something just +to find out its an already known bug. ----- - -Sometimes building or running a program will fail due to bugs in the system API implementation (in Glibc and the Hurd). Make sure you check this list and know them before porting, otherwise you'll end up debugging something just to find out its an already known bug. - -Taken from the bug lists in debian BTS. If you find more of them (and it is clear in the bug log that it is a bug), please add them to the list below. See: - -* ([source](http://packages.qa.debian.org/h/hurd.html) and [binary](http://packages.debian.org/hurd) debs not synchronized) -* ([binary](http://packages.debian.org/hurd-dev)) -* ([source](http://packages.qa.debian.org/g/glibc.html) & [binary](http://packages.debian.org/libc0.3) debs) -* ([binary](http://packages.debian.org/libc0.3-dev)) - ----- +Taken from the bug lists in [[running/Debian]] BTS. If you find more of them +(and it is clear in the bug log that it is a bug), please add them to the list +below. These are the known system API limits that have porting implications. @@ -35,7 +29,3 @@ These are the known system API limits that have porting implications. **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**
**breaks:** fam, gail
**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) **_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**
**breaks:** gnome-session (and others) from running
**error:** misc lock-related errors - --- [[Main/RobertMillan]] - 01 May 2003 - -Text formatting.
-- [[Main/OgnyanKulev]] - 02 May 2003 -- cgit v1.2.3 From 1b7d5c4900176a17af278f082b3dc6dbf888a94a Mon Sep 17 00:00:00 2001 From: "http://arnebab.livejournal.com/" Date: Tue, 14 Apr 2009 08:29:01 +0000 Subject: added contact link to hurd disk image with translator-intro. --- hurd/running/qemu.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index f13ef5c8..8a3dce61 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -15,7 +15,7 @@ volunteers and may not have been tested extensively. * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) with a short intro on translators. Just start it with 'qemu *disk_image.img*'. - It should work without any of the configuration below. -[[community/weblogs/ArneBab]] + It should work without any of the configuration below. when you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] -- cgit v1.2.3 From 8ad7193b826bd2c477bce8382eafd68d137162dc Mon Sep 17 00:00:00 2001 From: Mahesh Date: Tue, 14 Apr 2009 16:28:48 +0000 Subject: --- hurd/hurd_hacking_guide.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hurd/hurd_hacking_guide.mdwn b/hurd/hurd_hacking_guide.mdwn index 2ef08f8a..6ee5b2f2 100644 --- a/hurd/hurd_hacking_guide.mdwn +++ b/hurd/hurd_hacking_guide.mdwn @@ -13,6 +13,8 @@ introduction to GNU Hurd and GNU Mach programming, an overview of some of the Hurd's features. It also contains a tutorial on writing your own [[translator]]. +Before using the code in the example (trivfs) please do read the Changelog. A lot of changes might have taken place. + * [HTML version](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) for browsing online, * [PostScript version](http://www.gnu.org/software/hurd/hacking-guide/hhg.ps) -- cgit v1.2.3 From b4d53b226e3d0f417ea446e5ca04281243e38740 Mon Sep 17 00:00:00 2001 From: zhengda Date: Wed, 15 Apr 2009 17:40:38 +0000 Subject: --- user/zhengda/howto.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/user/zhengda/howto.mdwn b/user/zhengda/howto.mdwn index 3f0d0d13..99d487cb 100644 --- a/user/zhengda/howto.mdwn +++ b/user/zhengda/howto.mdwn @@ -18,7 +18,7 @@ This document briefly introduces how to set up the virtual network and connect t Step 1: Get the Hurd and compile it. - cvs -z3 -d:ext:username@cvs.savannah.gnu.org:/sources/hurd co -r zhengda-soc2008-virt-branch + cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r zhengda-soc2008-virt-branch hurd Step 2: apply the [patch](http://www.assembla.com/spaces/VNetHurd/documents/b0eLzUxHmr3ymXab7jnrAJ/download/A%20patch%20of%20gnumach) on the GNU Mach. -- cgit v1.2.3 From 8f91458f89e13fe5659ac2d5043ad063104d50e4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 18 Apr 2009 20:51:13 +0200 Subject: rules/source_repositories: Change for CVS to Git conversion. Also add further thoughts (rules, hints, suggestions, whatever). --- rules/source_repositories.mdwn | 114 ++++++++++++++++++++++++----------------- 1 file changed, 66 insertions(+), 48 deletions(-) diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 2ecc6fe6..7ef19a8b 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2007, 2008, 2009 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 @@ -8,54 +9,65 @@ 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]]."]]"""]] -CVS repositories on Savannah, see . +Git repositories on Savannah, see (search +for *hurd*). # Branches -Members of the Hurd Savannah group, -, are allowed to -create branches without formal permission... +[Members of the Hurd Savannah +group](http://savannah.gnu.org/project/memberlist.php?group=hurd) are allowed +to create branches without formal permission: -* named *SAVANNAH_LOGIN-WHATEVER-branch* for general-purpose branches, or - -* named *BASE_BRANCH-WHATEVER-branch* for topic-branches basing on + * named *BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]* for private general-purpose or + topic branches, respectively, or + * named *BASE_BRANCH-TOPIC* for public topic branches basing on *BASE_BRANCH*. -*WHATEVER* shall be a suitable tag. +*TOPIC* shall be a suitable tag describing the branch's main concern. These +tags can be applied recursively (*TOPIC-SUBTOPIC-SUBSUBTOPIC*). -Examples: +*private* vs. *public* does, of course, in this scenario not mean visibility, +but instead authority: *private* branches are those that the user +*SAVANNAH_LOGIN* has authority over, whereas public branches are open for +every committer to install changes on. The private branches are those that +you would typically host on your own machine and publish through your own web +server, but we offer that you can instead do this from the centralized Savannah +repository, as a number of people don't have an always-accessible web server +running on their own machines. -* GNU Mach +Examples: - * *gnumach-1-branch-Xen-branch* - * *gnumach-1-branch-gdb-branch* + * GNU Mach -* GNU Hurd + * *master* -- the mainline branch + * *master-oskit* -- port to OSKit; branched off of *master* at some point + * *master-gdb_stubs* -- add support for GDB stubs; branched off of + *master* at some point - * *miles-orphaned-changes* - * *hammy-libchannel-branch* - * *mmenal-soc2006-nfs-branch* + * libpthread -Also, create helper tags for merging mainline changes into your branches. + * *master* -- the mainline branch + * *master-viengoos* -- port to Viengoos; branched off of *master* at some + point + * *master-viengoos-on-bare-metal* -- port to Viengoos running on bare + metal; branched off of *master-viengoos* at some point -Examples: - -* GNU Mach +## Merging - * *gnumach-1-branch-Xen-branch*: *gnumach-1-branch-Xen-branch-merge_helper* - * *gnumach-1-branch-gdb-branch*: *gnumach-1-branch-gdb-branch-merge_helper* +Merging between Git branches is trivial, at least as long as no conflicts +arise. -* GNU Hurd +Due to this, you are encouraged to freely make use of separate branches for +different working topics, as this really faciliates concentrating on one +specific working topic. - * *hammy-libchannel-branch*: *hammy-libchannel-branch-base* - * *mmenal-soc2006-nfs-branch*: *mmenal-soc2006-nfs-branch-base* +You are encouraged to regularely merge from the respective mainline branches +(*BASE_BRANCH*; should be *master* in most cases) into your working branches, +and ensure that your modifications are still fine in the context of new +mainline changes. -## Merging - -Merging between CVS branches is not trivial. Unless you really know what -you're doing, please talk to [[Thomas_Schwinge|tschwinge]] or -[[Samuel_Thibault|samuelthibault]], to avoid cluttering the repositories -unintendedly. +Merging from working branches into the mainline branches will usually be done +by one of the project administrators, unless negotiated otherwise. # Tags @@ -63,24 +75,18 @@ Equivalent rules apply. # Behavior -## ... on your branches +## Behavior on branches -Most branches are to be eventually be merged back into the mainline branch. To -faciliate (and also to help other contributors) we'd like you to write a short -summary log in a top-level (or wherever else appropriate) `ChangeLog.WHATEVER` -file. +Usually, branches are to be eventually merged back into their respective +mainline branches. To faciliate (and also to help other contributors) we'd +like you to write a short summary log in a top-level (or wherever else +appropriate) `ChangeLog.*TOPIC*` file. Examples: -* GNU Mach - - * *gnumach-1-branch-Xen-branch*: `ChangeLog.Xen` - * *gnumach-1-branch-gdb-branch-merge_helper*: `ChangeLog.gdb` - -* GNU Hurd + * GNU Mach - * *hammy-libchannel-branch-base*: `channelio/ChangeLog`, `libchannel/ChangeLog` - * *mmenal-soc2006-nfs-branch-base*: `nfs/ChangeLog` + * *master-gdb_stubs*: `ChangeLog.gdb` This need not be a full-fledged [GNU-style *ChangeLog* file](http://www.gnu.org/prep/standards/html_node/Change-Logs.html). E.g., @@ -88,12 +94,24 @@ don't waste time writing *ChangeLog* entries for debugging stuff that will be removed again before merging back into mainline. But please do write something. Short notes. -## ... in general +### Behavior on *private* branches + +Even though you are said to be the owner of branches tagged with your +*SAVANNAH_LOGIN*, it is generally nevertheless good to not do history-rewriting +stuff and the like (`git rebase` and friends), as others may in turn be basing +their work on your private branches. + +We could establish a branch-tagging policy for branches that others should +expect their history possibly to be rewritten. This may be useful for branches +that are only meant for aggregating the changes of (several) development +branches, like *master-proposed_for_general_testing*. + +## Behavior in general Try to not introduce spurious, unneeded changes, e.g., whitespace changes. -Adhere to the already-used coding conventions. These are usually the [GNU -Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff +Adhere to the coding conventions that are already used. These are usually the +[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff written by ourselves, including new files, of course. GNU Mach code is largely based on external code. Don't GNU-ify it, as this -- cgit v1.2.3 From 22312957d01b0d380a55e9756d5a81982e41eb4d Mon Sep 17 00:00:00 2001 From: zhengda Date: Sat, 18 Apr 2009 22:30:15 +0000 Subject: --- user/zhengda/howto.mdwn | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/user/zhengda/howto.mdwn b/user/zhengda/howto.mdwn index 99d487cb..a04c2662 100644 --- a/user/zhengda/howto.mdwn +++ b/user/zhengda/howto.mdwn @@ -42,31 +42,26 @@ The network device file is used to help other translators open the device. Step 5: create the virtual network device with eth-multiplexer. -eth-multiplexer is responsible to create the virtual network device and dispatch the packet to the right clients that connect to the virtual device. It also connects the virtual network and the external network. +eth-multiplexer is responsible to create the virtual network device and dispatch the packet to the right clients that connect to the virtual device. It also connects the virtual network and the external network. Eth-multiplexer of the current version is a netfs translator and can create virtual devices and the device files dynamically, according to the request from the client. - # settrans -acfg /root/multiplexer /root/hurd/eth-multiplexer/eth-multiplexer -v 2 -i /dev/eth0 + # ettrans -acfg /root/multiplexer /root/hurd/eth-multiplexer/eth-multiplexer -i /dev/eth0 -Step 6: create the network device files for the virtual network device with devnode. +Step 6: setup the filter translator eth-filter on the network device. This step is optional. - # settrans -acfg /dev/veth0 /root/hurd/devnode/devnode -d veth0 -M /root/multiplexer - # settrans -acfg /dev/veth1 /root/hurd/devnode/devnode -d veth1 -M /root/multiplexer +eth-filter is used by the user to force the traffic policy on the network device. -Step 7: setup the filter translator eth-filter on the network device. This step is optional. -eth-filter is used to set up the traffic policy on the network device. + # settrans -acfg /dev/fveth0 /root/hurd/eth-filter/eth-filter -i /root/multiplexer/veth0 -S 192.168.8.0/24 -R 192.168.8.0/24 + # settrans -acfg /dev/fveth1 /root/hurd/eth-filter/eth-filter -i /root/multiplexer/veth1 -S 192.168.8.0/24 -R 192.168.8.0/24 - # settrans -acfg /dev/fveth0 /root/hurd/eth-filter/eth-filter -i /dev/veth0 -S 192.168.8.0/24 -R 192.168.8.0/24 - # settrans -acfg /dev/fveth1 /root/hurd/eth-filter/eth-filter -i /dev/veth1 -S 192.168.8.0/24 -R 192.168.8.0/24 - -Step 8: setup the pfinet server on the virtual network device. +Step 7: setup the pfinet server on the virtual network device. # settrans -afgc /root/socket0/2 /root/hurd/pfinet/pfinet -i /dev/fveth0 -a 192.168.8.10 -g 192.168.8.1 -m 255.255.255.0 # settrans -afgc /root/socket1/2 /root/hurd/pfinet/pfinet -i /dev/fveth1 -a 192.168.8.11 -g 192.168.8.1 -m 255.255.255.0 - # settrans -afgc /root/socket2/2 /root/hurd/pfinet/pfinet -i /dev/fveth1 -a 192.168.8.12 -g 192.168.8.1 -m 255.255.255.0 #### 1.3 Run the command with the customized pfinet server. -Step 9: Set environment variables to use the customized pfinet server. +Step 8: Set environment variables to use the customized pfinet server. The environment variable of SOCK_SERV_DIR is used to override all socket servers and SOCK_SERV_%d to override a specific socket server. %d after SOCK_SERV_ is the domain of the protocol that the socket server supports. The environment variable SOCK_SERV_%d has the higher priority than SOCK_SERV_DIR. @@ -83,13 +78,13 @@ A SHELL script is provided to run all translators I mentioned automatically: htt ### 2. Connect the subhurd with the main hurd. -In the main hurd, we still need to do Step 1-9. +In the main hurd, we still need to do Step 1-8. We run subhurd, # /root/hurd/boot/boot -m eth0=/dev/fveth0 -m eth1=/dev/fveth1 servers.boot /dev/hd1s1 In the subhurd, we do Step 1, 4, 8. Step 4: # settrans -acfg /dev/veth0 /root/hurd/devnode/devnode -d veth0 -Step 8: # settrans -afgc /servers/socket/2 /root/hurd/pfinet/pfinet -i /dev/veth0 -a 192.168.8.20 -g 192.168.8.1 -m 255.255.255.0 +Step 7: # settrans -afgc /servers/socket/2 /root/hurd/pfinet/pfinet -i /dev/veth0 -a 192.168.8.20 -g 192.168.8.1 -m 255.255.255.0 Now we can communicate from the subhurd with any pfinet server of the main Hurd that runs in the virtual network. -- cgit v1.2.3 From e89e28fd48b5c42cdbfaca296cade0f6549f1adb Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 19 Apr 2009 09:45:43 +0200 Subject: Repair typo. --- user/zhengda/howto.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/user/zhengda/howto.mdwn b/user/zhengda/howto.mdwn index a04c2662..ed13acc2 100644 --- a/user/zhengda/howto.mdwn +++ b/user/zhengda/howto.mdwn @@ -1,4 +1,4 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2008, 2009 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 @@ -44,7 +44,7 @@ Step 5: create the virtual network device with eth-multiplexer. eth-multiplexer is responsible to create the virtual network device and dispatch the packet to the right clients that connect to the virtual device. It also connects the virtual network and the external network. Eth-multiplexer of the current version is a netfs translator and can create virtual devices and the device files dynamically, according to the request from the client. - # ettrans -acfg /root/multiplexer /root/hurd/eth-multiplexer/eth-multiplexer -i /dev/eth0 + # settrans -acfg /root/multiplexer /root/hurd/eth-multiplexer/eth-multiplexer -i /dev/eth0 Step 6: setup the filter translator eth-filter on the network device. This step is optional. -- cgit v1.2.3 From 466e2728e21f9a519c2df5b3bb6f0efa28b1154d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 19 Apr 2009 09:51:29 +0200 Subject: rules/source_repositories: Move a snippet of text to rules/savannah_group. --- rules/savannah_group.mdwn | 5 +++++ rules/source_repositories.mdwn | 5 ++--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/rules/savannah_group.mdwn b/rules/savannah_group.mdwn index 14139719..935a5c87 100644 --- a/rules/savannah_group.mdwn +++ b/rules/savannah_group.mdwn @@ -22,3 +22,8 @@ for sending your contributions, for asking questions, and so on. Have a look at the page for [[contributing]]. Also be sure to have a look at the [[contributing/questionnaire]]. + +## List of members + +The list of members can be seen at +. diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 7ef19a8b..b84c2145 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -14,9 +14,8 @@ for *hurd*). # Branches -[Members of the Hurd Savannah -group](http://savannah.gnu.org/project/memberlist.php?group=hurd) are allowed -to create branches without formal permission: +Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create +branches without formal permission: * named *BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]* for private general-purpose or topic branches, respectively, or -- cgit v1.2.3 From b9c9db8acc47f417ca912d4ec3b3d624cd75493a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 19 Apr 2009 09:54:47 +0200 Subject: rules/savannah_group: Add stanza about copyright assignments. --- rules/savannah_group.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/rules/savannah_group.mdwn b/rules/savannah_group.mdwn index 935a5c87..ab84e75d 100644 --- a/rules/savannah_group.mdwn +++ b/rules/savannah_group.mdwn @@ -27,3 +27,13 @@ the [[contributing/questionnaire]]. The list of members can be seen at . + + +## Copyright assignment + + +If you have pieces of code or documentation to contribute, then, in order to +install them into our [[source_repositories]], you have to assign the copyright +of your changes to the [Free Software Foundation](http://www.fsf.org/). + +Please [[contact_us]] to request the needed forms. -- cgit v1.2.3 From 6ab6fabb1af5a4b325454acd1f656452ba22ff43 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 19 Apr 2009 10:04:14 +0200 Subject: rules/source_repositories: Add a note about copyright assignment. Suggested by Olaf Buddenhagen. --- rules/source_repositories.mdwn | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index b84c2145..ad488ebf 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -66,7 +66,10 @@ and ensure that your modifications are still fine in the context of new mainline changes. Merging from working branches into the mainline branches will usually be done -by one of the project administrators, unless negotiated otherwise. +by one of the project administrators, unless negotiated otherwise. For this to +happen, the copyright of your changes has to be assigned to the Free Software +Foundation; read about the +[[copyright_assignment_process|savannah_group#copyright_assignment]]. # Tags -- cgit v1.2.3 From 814e148d4425b3f020fca5e7d5ff17a0f4e6b16c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 21 Apr 2009 13:11:01 +0200 Subject: Link to the fatfs file truncating bug. --- hurd/running/qemu.mdwn | 3 +++ hurd/translator/fatfs.mdwn | 6 ++++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 8a3dce61..d5f27311 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -78,6 +78,9 @@ The Hurd [[`fatfs`_translator|translator/fatfs]] currently is read-only, but for testing executables (etc.) that is enough. And it is much easier than loop-mounting the file systems images. (Also you don't need `root' rights.) +However, note that there is a bug in [[translator/fatfs]]: [[GNU_Savannah_bug +25961]]. + # Networking in QEMU diff --git a/hurd/translator/fatfs.mdwn b/hurd/translator/fatfs.mdwn index b534b97e..fd537896 100644 --- a/hurd/translator/fatfs.mdwn +++ b/hurd/translator/fatfs.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2007, 2008, 2009 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 @@ -8,4 +9,5 @@ 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]]."]]"""]] -The current `fatfs` translator is read-only. +The current `fatfs` translator is read-only, and it has a severe bug: +[[GNU_Savannah_bug 25961]]. -- cgit v1.2.3 From 3289f087e3f980e810e55d2f40d16d4e099e4734 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 21 Apr 2009 23:25:49 +0200 Subject: The instability problem is not due to pfinet, and is being worked around. --- public_hurd_boxen.mdwn | 9 --------- 1 file changed, 9 deletions(-) diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index 4b9290fe..29c2eb36 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -27,15 +27,6 @@ addresses for requesting support with respect to software installations, etc. For a list of people using the Hurd in production systems, please see [[Hurd/WhoRunsGNU]]. ---- - -/!\ SSH access to the machines is very instable at the moment. This is -probably due to problems with the [[hurd/translator/pfinet]] server. - - * - ---- - To be able to use just `ssh [machine]`, you should append your public SSH key to `~/.ssh/authorized_keys` on the remote machine. -- cgit v1.2.3 From e1cb0bb2352e724db3fb814a733bf199f02dcb1b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 21 Apr 2009 23:33:39 +0200 Subject: Remove completely outdated WhoRunsGNU page. --- community.mdwn | 2 -- index.mdwn | 7 +++---- public_hurd_boxen.mdwn | 3 --- unsorted/SeenHurd.mdwn | 3 --- unsorted/WhoRunsGNU.mdwn | 31 ------------------------------- 5 files changed, 3 insertions(+), 43 deletions(-) delete mode 100644 unsorted/WhoRunsGNU.mdwn diff --git a/community.mdwn b/community.mdwn index 73812494..5d58ae5a 100644 --- a/community.mdwn +++ b/community.mdwn @@ -22,8 +22,6 @@ Further ways of getting in contact or getting information: [[GSoC]] -- Participation in the Google Summer of Code -[[Hurd/WhoRunsGNU]] - [[Hurd/HurdDevelopers]] -- Who's who? [Hurd User's Guide](http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html). diff --git a/index.mdwn b/index.mdwn index 8754baab..3e35c368 100644 --- a/index.mdwn +++ b/index.mdwn @@ -1,5 +1,5 @@ -[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2009 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 @@ -76,8 +76,7 @@ Find more information about it at the There are [[various_possibilities|hurd/running]] of running a GNU/Hurd system. And these web pages are a living proof of the usability of the Hurd, as they -are rendered on a Debian GNU/Hurd system. More people using GNU Hurd in -production can be found on [[Hurd/WhoRunsGNU]]. +are rendered on a Debian GNU/Hurd system. ## Current Status diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index 29c2eb36..b4ea6169 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -24,9 +24,6 @@ To request an account on the `*.bddebian.com` machines either contact or send email to . Also use these contact addresses for requesting support with respect to software installations, etc. -For a list of people using the Hurd in production systems, please see -[[Hurd/WhoRunsGNU]]. - To be able to use just `ssh [machine]`, you should append your public SSH key to `~/.ssh/authorized_keys` on the remote machine. diff --git a/unsorted/SeenHurd.mdwn b/unsorted/SeenHurd.mdwn index be9e1aba..8e883d5f 100644 --- a/unsorted/SeenHurd.mdwn +++ b/unsorted/SeenHurd.mdwn @@ -12,9 +12,6 @@
[[IRC]]
-
[[WhoRunsGNU]]
-
-
[[HurdDevelopers]]
Who's who?
[[PersonalHurdPages]]
diff --git a/unsorted/WhoRunsGNU.mdwn b/unsorted/WhoRunsGNU.mdwn deleted file mode 100644 index ad1685b7..00000000 --- a/unsorted/WhoRunsGNU.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -## Who runs GNU in production? - -On an official [GNU Project](http://www.gnu.org/gnu/thegnuproject.html) page I found a quote, attributed to Rabbi Hillel: - -> If I am not for myself, who will be for me? -> ->
-> -> If I am only for myself, what am I? -> ->
-> -> If not now, when? - -There are many now using test installations of Debian GNU/Hurd for testing and development. This page is set aside to list those sites using full GNU systems (GNU/Hurd) for non-testing and non-development purposes. - -## I run GNU! - -
-
Budi Rahardjo
-
http://hurd.indocisc.com, contact at budi@research.indociscNOSPAM.com
-
[[Main/JamesAMorrison]]
-
http://hurd.dyndns.org - -seems to be offline -- [[Community/weblogs/ArneBab]] - 2008-09-02
-
- -### Testing and developer installations - -Installations for testing purposes are listed as [[public_hurd_boxen]]. - -These also contain the wiki server. -- cgit v1.2.3 From 3558b47e3c836c8f1878323b82cd49c7c3104bf4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 22 Apr 2009 21:25:25 +0200 Subject: EuroSys 2009 is over. --- community/meetings.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/community/meetings.mdwn b/community/meetings.mdwn index ca99393a..1b994e13 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -14,10 +14,10 @@ is included in the section entitled # Upcoming * [[Self-organised]] - * [[EuroSys_2009]] # Past + * [[EuroSys_2009]] * [[FOSDEM_2008]] * [[Weekend_at_stesie's|stesie_2007-10-12]] * [[FOSDEM_2007]] -- cgit v1.2.3 From 2cbe2f1ab6b85423cd09879a8f01aae92cdf965d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 22 Apr 2009 21:27:24 +0200 Subject: Linuxhotel was suggested by Neal. --- community/meetings/self-organised.mdwn | 3 +++ 1 file changed, 3 insertions(+) diff --git a/community/meetings/self-organised.mdwn b/community/meetings/self-organised.mdwn index ece96696..7a19960b 100644 --- a/community/meetings/self-organised.mdwn +++ b/community/meetings/self-organised.mdwn @@ -36,6 +36,9 @@ Please add any suggestions here, and add to your name above if that time is good This likely has the benefit of being relatively close to most people + might be a suitable venue at very +reasonable pricing. + ## Somewhere in Italy This likely has the benefit of better weather. ;-) -- cgit v1.2.3 From 64e101c86b1cabd96613abc85f98d67c4182ae42 Mon Sep 17 00:00:00 2001 From: "Neal H. Walfield" Date: Wed, 29 Apr 2009 02:38:35 +0200 Subject: Update build instructions. --- microkernel/viengoos/building.mdwn | 136 ++++++++++++++++----------------- microkernel/viengoos/grub2-config.diff | 47 ++++++++++++ 2 files changed, 113 insertions(+), 70 deletions(-) create mode 100644 microkernel/viengoos/grub2-config.diff diff --git a/microkernel/viengoos/building.mdwn b/microkernel/viengoos/building.mdwn index 000a582c..a70f93df 100644 --- a/microkernel/viengoos/building.mdwn +++ b/microkernel/viengoos/building.mdwn @@ -1,4 +1,4 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2008, 2009 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 @@ -8,97 +8,93 @@ 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]]."]]"""]] -## Viengoos build +Check out Viengoos and switch to the viengoos-on-bare-metal branch +(all development is currently done on this branch and it will +eventually be merged into the master branch): -####Checkout viengoos-master: + $ git clone git://git.savannah.gnu.org/hurd/viengoos.git + $ cd viengoos + $ git checkout -b viengoos-on-bare-metal origin/viengoos-on-bare-metal - git clone git://git.savannah.gnu.org/hurd/viengoos.git +Generate the autoconf environment (note that --force is not specified +as we have our own version of config.guess and config.sub): -Configure: + $ autoreconf -i - autoreconf -i - mkdir test build +Configure a build directory: -Make check on test (fails to complete as on July 7, 2008): + $ mkdir build + $ cd build + $ ../configure --host=x86_64-pc-viengoos-gnu --with-newlib - cd test - ../configure --enable-l4-abi=x2 --host=i686-pc-viengoos-gnu --enable-tests - make check +Now, build Viengoos. Running make the first time will automatically +fetch binutils and gcc from the Internet and build a cross compiler. +Running make again will build the Viengoos proper. Again, the build +process with fetch several tarballs including Newlib, the Boehm GC and +Sqlite. -Build the compiler: + $ make + ... + The cross compiler is now set-up. Re-run `make' and proceed as usual. + make[2]: Leaving directory `.../viengoos/build' + make[1]: Leaving directory `.../viengoos/build' + $ make - cd ../build - ../configure --enable-l4-abi=x2 --host=i686-pc-viengoos-gnu --with-newlib +# Booting Using QEMU -Build cross-compiler: +To boot Viengoos, use Grub 2. You cannot use Grub Legacy: Viengoos is +an ELF64 executable, which Grub Legacy does not support. - make +First, check out Grub 2 from svn: -Build Viengoos proper: + $ svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 + $ cd grub2 - make +Before building Grub 2, you should apply the following patch, which +makes it easy to tell Grub to load a specific grub.cfg at start up +([http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00099.html](details)). -Install the built executables: + $ wget http://www.gnu.org/software/hurd/microkernel/viengoos/grub2-config.diff -O /dev/stdout | patch -p0 - cd .. - mkdir install - install -s build/laden/laden install - install -s build/viengoos/viengoos install - install -s build/hieronymus/hieronymus install +Next, build Grub 2: -## BUILD L4 + $ ./autogen.sh + $ mkdir build + $ cd build + $ ../configure --prefix=`pwd`/../install + $ make && make install -Get Pistachio using hg: +Create the boot disk: - hg clone http://hg.l4ka.org/l4ka-pistachio + $ cd ../install + $ bin/grub-mkrescue boot.img --configfile=grub.cfg --image-type=floppy --modules='help reboot serial multiboot pc configfile normal boot fat' -Build: +Now, create /viengoos and link viengoos and hieronymus into that +directory: - cd kernel + $ mkdir /viengoos + $ cd /viengoos + $ ln -s ~/viengoos/build/viengoos/viengoos.stripped viengoos + $ ln -s ~/viengoos/build/hieronymus/hieronymus.stripped hieronymus - make BUILDDIR=/absolute/path/to/build - cd build +Also, create a grub.cfg file in /viengoos/grub.cfg: -Check Makeconf.local: + set timeout=1 + set default=0 + set root=hd0,1 + + menuentry "Viengoos" { + multiboot /viengoos -D 3 -o serial + module /hieronymus + } - make menuconfig - Kernel->Enable experimental features->Pager ExchangeRegisters - - make +NB: If you edit grub.cfg and a backup file called grub.cfg~ is +created, qemu will use grub.cfg~ instead of grub.cfg! Thus, after +editing grub.cfg, be sure to delete any grub.cfg~ file! -## Build sigma0 +Finally, boot! - cd user + $ qemu-system-x86_64 -serial stdio -fda ~/grub2/install/boot.img -hda fat:/viengoos -boot a - autoheader - autoconf - ./configure - make - -## Test! - -Install all executables to /usr/local/hurd. Create a menu.lst - - title The GNU Hurd on L4 - root (hd0,0) - kernel /laden -D - module /x86-kernel - module /sigma0 - module /viengoos -D 3 -o serial - module /hieronymus -D 3 - -Get specific grub version: - - wget ftp://alpha.gnu.org/gnu/grub/grub-0.97-i386-pc.ext2fs - -Use the following to boot: - - qemu -serial stdio -hdb fat:/usr/local/hurd -fda grub-0.97-i386-pc.ext2fs -boot a - -At grub prompt: - - grub> root (hd0,0) - - grub> configfile /menu.lst - -It will boot to a kernel debugger prompt. +By default, Hieronymus is configured to load ruth, a test suite. Ruth +can take a long time to complete. diff --git a/microkernel/viengoos/grub2-config.diff b/microkernel/viengoos/grub2-config.diff new file mode 100644 index 00000000..e4b1ef40 --- /dev/null +++ b/microkernel/viengoos/grub2-config.diff @@ -0,0 +1,47 @@ +2009-01-17 Neal H. Walfield + + * util/i386/pc/grub-mkrescue.in: Add new option --configfile. If + not the set and not the empty string, load it from the generated + config file on boot. + +Index: util/i386/pc/grub-mkrescue.in +=================================================================== +--- util/i386/pc/grub-mkrescue.in (revision 2148) ++++ util/i386/pc/grub-mkrescue.in (working copy) +@@ -49,6 +49,7 @@ + --image-type=TYPE select floppy or cdrom (default) + --emulation=TYPE select El Torito boot emulation type floppy + or none (default) (cdrom only) ++ --configfile=FILE config file to load (default: none) + + grub-mkimage generates a bootable rescue image of the specified type. + +@@ -93,6 +94,9 @@ + echo "Unknown emulation type \`$emulation'" 1>&2 + exit 1 ;; + esac ;; ++ --configfile=*) ++ configfile=`echo "$option" | sed 's/--configfile=//'` ++ ;; + -*) + echo "Unrecognized option \`$option'" 1>&2 + usage +@@ -121,9 +125,15 @@ + ${aux_dir}/boot/grub/ + + modules="biosdisk `cat ${input_dir}/partmap.lst` ${modules}" +-for i in ${modules} ; do +- echo "insmod $i" +-done > ${aux_dir}/boot/grub/grub.cfg ++{ ++ for i in ${modules} ; do ++ echo "insmod $i" ++ done ++ if test x$configfile != x ++ then ++ echo "configfile $configfile" ++ fi ++} > ${aux_dir}/boot/grub/grub.cfg + + for d in ${overlay}; do + echo "Overlaying $d" -- cgit v1.2.3 From 6ccb3e0f305bc869c907477b97c95bcbc938bc32 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 29 Apr 2009 10:17:48 +0200 Subject: Reformatting. --- rules/source_repositories.mdwn | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index ad488ebf..044cf6ce 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -17,17 +17,17 @@ for *hurd*). Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create branches without formal permission: - * named *BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]* for private general-purpose or + * named `BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]` for private general-purpose or topic branches, respectively, or - * named *BASE_BRANCH-TOPIC* for public topic branches basing on - *BASE_BRANCH*. + * named `BASE_BRANCH-TOPIC` for public topic branches basing on + `BASE_BRANCH`. -*TOPIC* shall be a suitable tag describing the branch's main concern. These -tags can be applied recursively (*TOPIC-SUBTOPIC-SUBSUBTOPIC*). +`TOPIC` shall be a suitable tag describing the branch's main concern. These +tags can be applied recursively (`TOPIC-SUBTOPIC-SUBSUBTOPIC`). *private* vs. *public* does, of course, in this scenario not mean visibility, but instead authority: *private* branches are those that the user -*SAVANNAH_LOGIN* has authority over, whereas public branches are open for +`SAVANNAH_LOGIN` has authority over, whereas public branches are open for every committer to install changes on. The private branches are those that you would typically host on your own machine and publish through your own web server, but we offer that you can instead do this from the centralized Savannah @@ -38,18 +38,18 @@ Examples: * GNU Mach - * *master* -- the mainline branch - * *master-oskit* -- port to OSKit; branched off of *master* at some point - * *master-gdb_stubs* -- add support for GDB stubs; branched off of - *master* at some point + * `master` -- the mainline branch + * `master-oskit` -- port to OSKit; branched off of `master` at some point + * `master-gdb_stubs` -- add support for GDB stubs; branched off of + `master` at some point * libpthread - * *master* -- the mainline branch - * *master-viengoos* -- port to Viengoos; branched off of *master* at some + * `master` -- the mainline branch + * `master-viengoos` -- port to Viengoos; branched off of `master` at some point - * *master-viengoos-on-bare-metal* -- port to Viengoos running on bare - metal; branched off of *master-viengoos* at some point + * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare + metal; branched off of `master-viengoos` at some point ## Merging @@ -61,7 +61,7 @@ different working topics, as this really faciliates concentrating on one specific working topic. You are encouraged to regularely merge from the respective mainline branches -(*BASE_BRANCH*; should be *master* in most cases) into your working branches, +(`BASE_BRANCH`; should be `master` in most cases) into your working branches, and ensure that your modifications are still fine in the context of new mainline changes. @@ -82,31 +82,31 @@ Equivalent rules apply. Usually, branches are to be eventually merged back into their respective mainline branches. To faciliate (and also to help other contributors) we'd like you to write a short summary log in a top-level (or wherever else -appropriate) `ChangeLog.*TOPIC*` file. +appropriate) `ChangeLog.TOPIC` file. Examples: * GNU Mach - * *master-gdb_stubs*: `ChangeLog.gdb` + * `master-gdb_stubs`: `ChangeLog.gdb` -This need not be a full-fledged [GNU-style *ChangeLog* +This need not be a full-fledged [GNU-style `ChangeLog` file](http://www.gnu.org/prep/standards/html_node/Change-Logs.html). E.g., -don't waste time writing *ChangeLog* entries for debugging stuff that will be +don't waste time writing `ChangeLog` entries for debugging stuff that will be removed again before merging back into mainline. But please do write something. Short notes. ### Behavior on *private* branches Even though you are said to be the owner of branches tagged with your -*SAVANNAH_LOGIN*, it is generally nevertheless good to not do history-rewriting +`SAVANNAH_LOGIN`, it is generally nevertheless good to not do history-rewriting stuff and the like (`git rebase` and friends), as others may in turn be basing their work on your private branches. We could establish a branch-tagging policy for branches that others should expect their history possibly to be rewritten. This may be useful for branches that are only meant for aggregating the changes of (several) development -branches, like *master-proposed_for_general_testing*. +branches, like `master-proposed_for_general_testing`. ## Behavior in general -- cgit v1.2.3 From 64bc4f0483bc668f5ec0fd85cd39cef80a04131c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 29 Apr 2009 10:18:48 +0200 Subject: rules/source_repositories: Move a section. --- rules/source_repositories.mdwn | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 044cf6ce..ed09b8c6 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -77,6 +77,15 @@ Equivalent rules apply. # Behavior +Try to not introduce spurious, unneeded changes, e.g., whitespace changes. + +Adhere to the coding conventions that are already used. These are usually the +[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff +written by ourselves, including new files, of course. + +GNU Mach code is largely based on external code. Don't GNU-ify it, as this +would make merging external patches unnecessarily difficult. + ## Behavior on branches Usually, branches are to be eventually merged back into their respective @@ -107,14 +116,3 @@ We could establish a branch-tagging policy for branches that others should expect their history possibly to be rewritten. This may be useful for branches that are only meant for aggregating the changes of (several) development branches, like `master-proposed_for_general_testing`. - -## Behavior in general - -Try to not introduce spurious, unneeded changes, e.g., whitespace changes. - -Adhere to the coding conventions that are already used. These are usually the -[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff -written by ourselves, including new files, of course. - -GNU Mach code is largely based on external code. Don't GNU-ify it, as this -would make merging external patches unnecessarily difficult. -- cgit v1.2.3 From e100a2b696891c93f96b99aabf4f067716427690 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 29 Apr 2009 10:33:50 +0200 Subject: Correct hyperlink. --- microkernel/viengoos/building.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/microkernel/viengoos/building.mdwn b/microkernel/viengoos/building.mdwn index a70f93df..d70ea47d 100644 --- a/microkernel/viengoos/building.mdwn +++ b/microkernel/viengoos/building.mdwn @@ -52,7 +52,7 @@ First, check out Grub 2 from svn: Before building Grub 2, you should apply the following patch, which makes it easy to tell Grub to load a specific grub.cfg at start up -([http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00099.html](details)). +([details](http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00099.html)). $ wget http://www.gnu.org/software/hurd/microkernel/viengoos/grub2-config.diff -O /dev/stdout | patch -p0 -- cgit v1.2.3