Re: libgtop2
At Wed, 11 May 2005 01:41:31 +0200, Manuel Menal [EMAIL PROTECTED] wrote: - I can't find a way to get statistics about CPU usage (user/sys/kernel times, etc.), i.e. what you get in /proc/stat with Linux. Check out libps, which is part of the Hurd. - I did not find a clean way to get the last running PID. That would mean getting a task id from Mach (since our scheduler is in Mach), and converting it to a proc_stat to get its pid, but I don't think Mach has interfaces for the first step. Right, I don't think Mach gives this info. But if you had a task id, there is a function to convert task ids into pids in the proc interface (just FYI). I don't actually see what you'd want to have this info for anyway. - There are no interfaces for IP accounting. It's usually done at the driver level, so you'd need to add an interface to Mach for that - that should be simple since the code that fills the /proc entry under Linux is already there. I don't know what IP accounting is. - We can't get the idle time along with the uptime like in /proc/uptime, but I'm not sure it matters anyway. Ok. libgtop2 interfaces are pretty Linux-specific, so there are a few things that don't apply to GNU/Hurd. I hope we'll have a working libgtop2 by the end of the week, but I can't say for sure. Sweet. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More packages
At Sat, 16 Apr 2005 08:18:30 -0400, Barry deFreese wrote: libgpg-error - Problem with mkerrcodes.awk. Submitted to alioth with no patch yet. I'm upstream maintainer of that, will look at it soon. It's a bit of a mess, unfortunately, but I already tried to make it so that it will work on the Hurd, so it must be a small thing. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More hurd packages
At Mon, 21 Mar 2005 14:55:13 +0100, Physicman [EMAIL PROTECTED] wrote: I also got libgpg-error-1.0 to build, but it required some ugly modification, because, apparently, gcc -E doesn't give the same kind of output on the Hurd as on GNU/Linux. That's evil. I wrote libgpg-error, so I know how evil it is what it is trying to do, but I thought I made sure it will work on the Hurd. I have definitely tried. I will check it out. I'm currently stucked with libcap-1.10 which seem to rely heavily on Linux. (I'd like to rebuild gnupg which build-depends on libcap-dev) libcap-dev is Linux specific. The build dependency on libcap-dev should be [!hurd-i386] or so... gnupg should work fine without cap support (it will probably not be able to mlock the memory it is using, though). Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
At Sat, 19 Mar 2005 13:35:57 +0100, Alfred M Szmidt wrote: Me, Gianluca and Stallman. When I say the GNU system then I mean a release of the actualy system, not the whole GNU project. And I think you misintepreted that to mean the whole GNU project. I thought, there rest of the people here help in anyway they can; by writing docs, building packages, testing, advocating, etc. They are working on Debian GNU/Hurd, not on the GNU system. I suggest that you keep discussion of your work on the GNU system on the mailing list for the GNU system, which does exist. You have never been directly involved in Debian GNU/Hurd, and you have never supported it, so I don't see any reason for you to give us a hard time here on our own mailing list. It is totally unsolicited and helps no one. In fact, I find it to be quite destructive. To everybody else: Please don't feed trolls. That goes for FHS discussions as well as discussions about what Debian GNU/Hurd supposedly never will do or not. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
At Thu, 17 Mar 2005 07:57:33 +0100, Alfred M Szmidt wrote: That might not be a bad thing anyway, but it would be more work and a change. The work needed would be minimal, and I doubt you would need any changes. There has always been a seperate archive where Debian GNU/Hurd has put hacks. I think you are underestimating the work involved. I have considered a Debian port outside of Debian a couple of years ago very carefully, for some reasons. And it is not an easy task, if you want to do it properly. There is a major difference between having a couple of extra packages on a server, and maintaining a full archive and keep it in sync. Also there are considerable extra costs, like keeping up a mirror network etc, which are all administrative but have to be done by someone. It's certainly not impossible, but I'd rather cut off my arm than do it. Or work on a new, less ambitious distribution than Debian. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
Hi, I am not even trying to comprehend where these rules come from, or what their sanity is. I am just going to accept whatever comes out of the Debian cabal as long as I can morally accept it. At 16 Mar 2005 11:04:39 -0800, Thomas Bushnell BSG wrote: 1. the architecture must be freely usable (i.e., without NDAs) Ok. 2. the architecture must be able to run a buildd 24/7 sustained (without crashing) Does this mean eternally, or only for one week? Who is going to verify this? If we use a slow machine with lots of memory, running for one week will be fine, if certain precautions are taken (enough disk space and ogi's ext2, or excluding certain packages that can't be built within 2 GB). If you use a fast machine, it won't work, because a fast machine hits the bugs and races faster. Mach just crashes at some point with zalloc failures. I have no information about this bug, and have no inclincation to collect it. 3. the architecture must have an actual, running, working buildd We had this before, it's possible. People are working on setting it up again. 4. the port must include basic unix functionality, e.g resolving DNS names and firewalling The firewalling requirement was specifically put in there for us, I suppose. AJ was quite upset when I told him we don't have it (years ago). The people asking for this seem to think that having a working firewall is some kind of proof of something, I don't know what. They may or may not realize that the Hurd does not make any kinds of security claims at this point (the code base is not audited, and we actually know about some glaring security problems, so a firewall is pretty down the list for me). In any case, I guess it would be possible to enable ipchains or iptables or whatever we have in our pfinet and export the Linux ioctl interface to configure it in pfinet. Some coding work, for sure, but nothing substantial, unless ipchains/iptables needs some kind of magic we don't have in our glued pfinet. Nobdoy is working on it, though (and don't look at me ;). 5. binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance) That was always a requirement. 6. binaries for the proposed architecture must have been built and signed by official Debian developers Ditto. This says nothing about the hardware and where it is located. I am reasonably sure that many Debian machines are located at environments which are not exclusively controlled by Debian maintainers, but by trusted third parties. 7. the architecture must have successfully compiled 50% of the archive's source (excluding architecture-specific packages) This assumes a definition of architecture-specific. I suspect it's going to be based on the Architecture: field of the packages, which would be wrong, as some packages may not be buildable yet but will be when we implemented a certain feature, or when it is ported. It doesn't help that Debian source packages suck in all the dependencies for every silly feature a package got. I suggest that this definition allows for the port maintainers to build their own architecture-specific exclusion list, and then base the numbers on that. But even then I suggest to just reject this rule. The software in Debian is heavily biased towards GNU/Linux. That said, last time I was doing the buildd stuff, I think we had something in the 30% range or so... 8. 5 developers who will use or work on the port must send in signed requests for its addition Trivial. We have many more than that (not all active all the time, but still). 9. the port must demonstrate that they have at least 50 users Well, we surely can find 50 people who say they are using Debian GNU/Hurd. These are not cast into stone, but we should expect something like this to become reality I think. I am expecting everything from the Debian cabal. Nothing will surprise me. ;) Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: heads up
At 16 Mar 2005 14:35:43 -0800, Thomas Bushnell BSG wrote: Does this mean eternally, or only for one week? Who is going to verify this? Verification isn't the point; if people can't be trusted not to lie, then everything is broken already. But what it means actually, is uncertain. I think it's a practical criterion, not a strict one. Right. But my point was not to subvert the rule. Stability is highly subjective. By most criteria, the Hurd is not stable enough for any real work, and won't be for a long time. It just lacks the critical mass of developers to sustain substantial stability. 4. the port must include basic unix functionality, e.g resolving DNS names and firewalling The firewalling requirement was specifically put in there for us, I suppose. AJ was quite upset when I told him we don't have it (years ago). The people asking for this seem to think that having a working firewall is some kind of proof of something, I don't know what. So, I've asked what features are implied here, and we can simply add that feature. I guess that's true. I will be looking forward to the patches. But in all honesty, the Hurd is not secure, and won't be even with a firewall. If a firewall gives people a false sense of security, that would not be good. 5. binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance) That was always a requirement. We've done it, but it's actually a change; there used to be procedures for porters to have private source for things. Yeah, I think I remember something like that. But it was very exceptional. It was also before there were procedures to speed up NMUs. But even then I suggest to just reject this rule. The software in Debian is heavily biased towards GNU/Linux. Most packages are not. Most packages are just ordinary libraries, gnome apps, etc. If you paint the broad picture, then that is true. But if you talk about numbers, the details matter. And there are numerous small packages which make no sense for us but are architecture any because nobdoy is going to list all the Linux architectures in the control file just to exclude the Hurd, and there are many build failures and unfulfilled build dependencies. It also merely requires that it build, *not* that it fully function. Let's not poke at that one, and just use it in our advantage. I am not saying that 50% can't be achieved. It probably can. But 50% for us is much harder than 50% for another Linux port, that's all I am saying. There should be some factor to take that into account. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RfC: Hurd console by default
At Fri, 11 Mar 2005 01:12:00 +0100, Alfred M Szmidt wrote: The point is that you actually want to break out of it if you are indeed in an infinite loop. This isn't really related to when console-client starts dieing, and you get into a infinite loop, but it would be nice when you actually wish to drop out into the Mach console by force. What do you think about making the console-client exist with a special exit code (say 0) when you hit C-A-BACKSPACE? Eventually this should be configurable of course, but having a break out key combo that returns with a different exit code to indicate to the wrapper if it should be restarted or not is a good idea indeed. You could of course also do something like /etc/init.d/console-client stop in the console client... Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RfC: Hurd console by default
At Wed, 09 Mar 2005 16:37:50 +, Neal H. Walfield wrote: Assuming you are only interested in avoiding resource consumption due to the high restart rate, you could just sleep for 5 seconds or so before restarting the console. Something like: while : do start_hurd_console sleep 5 done This is not the point. The point is that you actually want to break out of it if you are indeed in an infinite loop. Because if you are in such a loop, then it is a bug that prevents anybody from logging in, and it is preferable to fall back to rescue mode (root login prompt on Mach console) than to keep spinning. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RfC: Hurd console by default
At Wed, 9 Mar 2005 17:58:05 +0100, Michael Banck wrote: 1. It's sort of a hack. See http://people.debian.org/~mbanck/marcus_azeem_console_login.txt for some discussion on how this should be done properly. It also means running e.g. xdm will be painful/not possible as the Hurd console gets started /after/ /etc/rc2.d/ is being run. However, it's the only choice we have currently which does not involve some non-trivial coding. Why? What non-trivial coding are you talking about? Daemonizing the console client seems pretty trivial to me, and that's all that is really required. The loop can be in a shell script in /etc/rc2.d/..., even if it doesn't break out if it respawns too fast, in a first version. You must understand I am really confused here. I have seen several people involved in this, and they all hack on and struggle with runttys like mad, and I have never understood this. What is the problem in running the console-client as a normal daemon like any other daemon? Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Link Broken
Hi, this is probably ok, although I have reservations. Specifically, I am not sure anybody is really maintaining the Debian GNU/Hurd web page. I would feel much better about just referring to the Debian web page if I knew that somebody has an eye on it. Any volunteers on the Debian side to give http://www.debian.org/ports/hurd/ a lift? Thanks, Marcus At Mon, 28 Feb 2005 04:07:09 +0100, Alfred M Szmidt wrote: The GNU/Hurd Installation guide link in the page http://www.gnu.org/software/hurd/install.html is broken. Please fix it. Thank you, I have fixed this by removing the redundant information, users are now pointed to the Debian GNU/Hurd projects web page for further details on how to install Debian GNU/Hurd. --- install.html 09 Oct 2004 18:57:52 +0200 1.20 +++ install.html 28 Feb 2005 04:03:51 +0100 @@ -51,8 +51,6 @@ H3A NAME=contentsTable of Contents/A/H3 UL LIA HREF=#version NAME=TOCversionLatest version/A - LIA HREF=#install NAME=TOCinstallInstallation instructions/A - LIA HREF=#cdimage NAME=TOCcdimageCD ROM images/A /UL HR @@ -72,29 +70,9 @@ installation routine which is easy to us The Debian project has commited to provide such a binary distribution. A HREF=http://www.debian.org/ports/hurd/;Debian GNU/Hurd/A is currently under development and available in the sid/unstable branch -of the Debian archive. - -H3A HREF=#TOCinstall NAME=installInstallation instructions/A/H3 -P -A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-install-guide.html; -The GNU/Hurd installation guide/A written by Neal Walfield explains how -to install the Debian GNU/Hurd binary distribution of the Hurd. -Also available: -UL -LIformatted in A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-install-guide.pdf;PDF (105k characters)/A. -LIformatted as an A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-install-guide.info;Info document (24k characters)/A. -LIis the A HREF=http://web.walfield.org/papers/hurd-installation-guide/english/hurd-install-guide.texi;Texinfo source (25k characters)/A. -/UL - -H3A HREF=#TOCcdimage NAME=cdimageCD ROM images/A/H3 -P -The Debian GNU/Hurd binary distribution of the GNU/Hurd system can be -installed most conveniently from CD ROM. The complete Debian GNU/Hurd -snapshot fits on three CDs. Information on -A HREF=http://www.debian.org/ports/hurd/hurd-cd;where to find images -of the current CD ROM set/A are available from the -A HREF=http://www.debian.org/ports/hurd/;Debian GNU/Hurd/A web -pages. +of the Debian archive. Please see +the A HREF=http://www.debian.org/ports/hurd/;Debian GNU/Hurd/A +project web page installation instructions. P EMSome of these links are at other web sites not maintained by the ___ Web-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/web-hurd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tcpdump-3.8.3
At Thu, 10 Feb 2005 20:57:06 -0800, Barry deFreese wrote: +#if defined(__GNU__) +# define MAXHOSTNAMELEN 64 +#endif tcpdump. print-atalk.c uses MAXHOSTNAMELEN this way: char nambuf[MAXHOSTNAMELEN + 20]; ... getting lines from /etc/atalk.names into ... char line[256]; if (sscanf(line, %d.%d.%d %256s, i1, i2, i3, nambuf) == 4) If I read this correctly, this will happily overwrite anything after nambuf[64+20] if the lines in /etc/atalk.names happen to exceed %d.%d.%d + space + 84 characters. A simple buffer overrun. The %256s should instead maybe be something like %*s and then sizeof (nambuf) - 1, nambuf as arguments (is that portable?) and, in fact, it should use LINE_MAX instead of MAXHOSTNAMELEN + 20 (do we define LINE_MAX? If not, provide a default in tcpdump-stdinc.h of 2048). The uses of MAXHOSTNAMELEN in print-bgp.c and print-icmp.c seem to be properly protected by snprintf. I think using longer hostnames will just cause truncation (which could be considered a DoS attack if the log is important to you). Maybe just using a large MAXHOSTNAMELEN will be ok here (ie, a default definition as your patch adds). In fact, _I_'d also just use some LINE_MAX here and be done with it. I think they just want something that is large enough for all hostnames plus some things extra (the 100). In fact, to properly deal with _arbitrary_ host name lengths, I'd want the code to print the IP address first, then the hostname, truncated to some arbitrary limit, and then the rest of the line. This would make sure that a static buffer is sufficient, without risk of losing information. Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: console translator set without encoding
Hi, Ok, so I am not the quickest to respond... At Tue, 07 Sep 2004 12:39:06 +0200, Patrick Strasser [EMAIL PROTECTED] wrote: CC-ing bug-hurd Ognyan Kulev wrote: Patrick Strasser wrote: Unicode did not work until i set it to /hurd/console --encoding=UTF-8 via settrans /dev/vcs /hurd/console --encoding=UTF-8 I think this should be the default. The change will be in MAKEDEV. Will you submit bug for the hurd package? Then should Unicode be default for the console? I have not printed out a complete ASCII table on a UTF-8-console without Unicode fonts (anyone knowing a tool for this?), but at a first glance output seemed to be quite usefull without ISO8859-1 encoding. I'm not shure if this is a Debian issue. Why should Debian have a different default encoding? Is a UTF-8 console the default on Debian GNU/Linux? If not, why not? You may consider thinking about this. Also, setting the console to use UTF-8 encoding by default is _wrong_ if you don't also carefully set up (a) an UTF-8 font that is used by default and (b) ensure that a UTF-8 locale is used by default, and (c) ensure that all applications work within a UTF-8 locale by default, or well, at least a reasonable subset. I know that (a) is easy to do, (c) is probably still not complete, but definitely there was progress within the last years (although I think that there is still manual configuration required). (b) requires changing to the glibc package and/or locales package, and I think that maybe you must make the locales package mandatory or so - I don't really know what that entails. Also, note that UTF-8 is _not_ the encoding of choice for a lot of parts in the world. Irregardless of what you think about it - the western world doesn't need it (where ISO 8859-1 or 15 is enough), and as far as I know even some asian and/or russian regions are happier with their own funny regional multi-byte encodings for whatever reasons. I don't think it is our responsibility to push this. If Debian is ready to make the change, we (Debian GNU/Hurd) can follow. If not, we shouldn't lose any sweat over this. What is more important is to properly document the issues involved, and Marco committed some old text from me about this into the CVS tree to help with that. Now, the only remaining question is what upstream should do, in this case MAKEDEV. I don't really see a strong point here. This is a system configuration issue, and Debian is a system configurator, so it can do its job whatever the upstream MAKEDEV says, and the sysadmin can override that. If I were to build a GNU system, I would make UTF-8 the default, but then I would also make all sure all applications use that out of the box (actually, is emacs ready for that? I am unsure). Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: console translator set without encoding
At 21 Jan 2005 18:58:41 -0800, Thomas Bushnell BSG wrote: Marcus Brinkmann [EMAIL PROTECTED] writes: Irregardless of what you think about it - the western world doesn't need it (where ISO 8859-1 or 15 is enough). If only this were true. Obviously I was exaggerating. You are certainly right that it's not a Hurd-specific question, and Debian Hurd should probably just track what other people do, but we should make sure all our parts do the right thing with UTF-8, and then be ready to switch when Debian is. I think except for the input method we are completely up to par to an UTF-8 xterm using an 8x13 font on Debian GNU/Linux these days (and even 9x15 if you live with some limitations for extra-wide characters) - and all this in VGA text mode (== fast scrolling) and up to 512 different characters at the same time (if you can live with 8 colors - 256 otherwise). I have carried the VGA text mode to its most extreme, there is little room for improvement in this context (you _could_ do overstrike by handling the font slot allocation even more dynamically, but that's about it). For more, we need to go to graphics mode. For the input method, marco was working on an xkb driver for the console, which means we will support just about exactly the same input methods as X Free 86 (plus/minus the obvious tweaks). You can't get much more complete than that either. UTF-8 is an insanely complex standard, if you start to look down its depths. I am not sure if there is any complete implementation in the world (well, maybe some proprietary solutions for tens of thousands of dollar or so). But we provide the reasonably subset that GNU/Linux also supports. Beyond that you will quickly hit all sorts of limitations, including the fact that the unix console must be mono-spaced(!), while UTF-8 knows something like double-width characters which are twice as broad as normal characters (in mono-spaced fonts). Proper UTF-8 supports carries itself through all layers of the system, from string comparison at the glibc and filesystem level (when are two filenames distinct?) to input and display methods at the application level. It's huge. Heck, we even support _real_ bold and _real_ italic font types on the text console (unfortunately still not yet supported by emacs' font lock mode, although that should be a small hack). And we have a 6x3 cells big GNU Head (see console/motd.UTF-8)! Find that anywhere else in the world :) That said, I have only done little testing with the UTF-8 stuff. I think it is solid, but there may be some error conditions with iconv which mess things up. This will naturally manifest itself once the code gets used a lot. Have fun, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reboot complains about /dev/initctl
At Wed, 23 Jun 2004 21:17:31 +0300, Ognyan Kulev wrote: /* Cc: [EMAIL PROTECTED] */ Alfred M. Szmidt wrote: Recall that the ones in the Hurd don't do funky sysvinit magic. Infatc, reboot for us is essentially a call to reboot(). (Shame smiley here) I forgot about that (the funky sysvinit part). Anyway, we need resolution about the sysvinit package and hurd-i386. For the halt/reboot problem, one of the quickest solutions is to remove halt and reboot from Debian's hurd package[1], and -f to be always assumed for these commands in sysvinit package. [1] Well, this requires synchronization with hurd package maintainers, so the really quickest is sysvinit to not ship with halt and reboot. Well, it's true that synchronization may be required. However, before you can put an alternative into place, it must work. IE, the sysvinit port must be thoroughly tested and confirmed to do what it's supposed to do. This is just a general note, maybe it already does. I am not sure it is necessary or even desirable to use reboot/halt from sysvinit. I remember a time where users where discouraged from running halt/reboot directly specifically because they didn't run the scripts (even on GNU/Linux). The right way to shut down the system was shutdown (-r or -h and -t now or so). We will need our own initscripts package or whatever anyway, so if calling reboot/halt from those scripts is a problem, than in our version of the script we can adjust it wrt command line options (-f) etc. Thanks, Marcus
Re: Debian GNU/Hurd presence at LinuxTag
At Tue, 15 Jun 2004 05:27:36 +0200, ams wrote: I'll be around at LinuxTag, giving a presentation on Debian GNU/Hurd during Debian Day (Thursday). Would be nice to post this on hurd.gnu.org... Just to have _something_ new! Marcus, you there? I'd do this in a jiffy if I had commit access to the web page tree (which resides in the Hurd tree now-a-days). I am back from Wizards of OS 3 and can commit patches. Marcus
Re: Debian GNU/Hurd presence at LinuxTag
At Tue, 15 Jun 2004 10:35:15 +0200, Michael Banck wrote: On Tue, Jun 15, 2004 at 05:27:36AM +0200, Alfred M. Szmidt wrote: I'll be around at LinuxTag, giving a presentation on Debian GNU/Hurd during Debian Day (Thursday). Would be nice to post this on hurd.gnu.org... Just to have _something_ new! Wolfgang will deliver a general Hurd talk, which would fit even better on the web page. He will be speaking at 15:00 on Friday, June 25th (in german I guess) about Hurd: Was lange waehrt, wird unendlich gut?. We should mention both. Advocacy is good. In fact, we should have posted my Wizards of OS 3 Panel participation, too, but I flunked it, sorry. I want to be at Linuxtag, so, if I can overcome my inertia and actually be there, then I don't mind to be at the FSFe and Debian GNU/Hurd booth some of the time (I usually am anyway). There is one talk I want to attend, and that is Hong Feng's talk about a new project, Ming/OS. Maybe we should mention it, too. It is relevant to what we do (http://www.rons.net.cn/mingos/q2q.pdf) in the sense that it is a new OS design centered around the idea of freedom (Hong Feng is the head of FSF China, and a strong supporter of the freedom in free software, read more about him here: http://mm.gnu.org.in/pipermail/fsf-friends/2003-October/001222.html). Thanks, Marcus
Re: Bug#251561: Read error when configuring timezone
At Tue, 1 Jun 2004 14:19:14 +0200, Robert Millan wrote: See http://bugs.debian.org/251561 This is definitely a new one. Looks like glibc breakage to me. But if tzconfig works later on, it might be a more subtle problem. Definitely worth taking a closer look. On the rant issue, I don't think there is anything special about cross-hurd wrt to bug reports. The bug cropped up using crosshurd, probably because it is the first thing in a new hurd install that makes the bug pop up. In any case, reporting it as a bug to crosshurd sounds appropriate to me, if only to make it apparent that crosshurd doesn't work until this problem is fixed. Of course this doesn't look like a problem you can address in crosshurd, so the appropriate reaction for you as the maintainer is to reassign the bug to, well, the hurd package (as a general place holder for hurd specific bugs of unknown origin - we can reassign it to glibc if we think it is a glibc issue, etc). Thanks, Marcus
Re: Bug#251561: Read error when configuring timezone
At Wed, 2 Jun 2004 15:03:40 +0200, Robert Millan wrote: On Wed, Jun 02, 2004 at 01:12:20PM +0200, Marcus Brinkmann wrote: This is definitely a new one. Looks like glibc breakage to me. But if tzconfig works later on, it might be a more subtle problem. Definitely worth taking a closer look. On the rant issue, I don't think there is anything special about cross-hurd wrt to bug reports. The bug cropped up using crosshurd, probably because it is the first thing in a new hurd install that makes the bug pop up. In any case, reporting it as a bug to crosshurd sounds appropriate to me, if only to make it apparent that crosshurd doesn't work until this problem is fixed. Of course this doesn't look like a problem you can address in crosshurd, so the appropriate reaction for you as the maintainer is to reassign the bug to, well, the hurd package (as a general place holder for hurd specific bugs of unknown origin - we can reassign it to glibc if we think it is a glibc issue, etc). The BTS tracks bugs per-package. When bugs are known or at least suspected to be in a particular package, they're assigned in it. I don't find it suitable to use particular packages as general place-holders. In this situations we normaly use virtual BTS entries (e.g., general, wnpp, etc). If what we actualy need is a BTS entry for the system in general (e.g., gnu), this should be requested to the BTS admins (by using the BTS, of course). Using the general virtual package. I'd be fine with this (in general, I leave this to Jeff to decide if he wants to go for it). The point here is that we don't want to bother individual package maintainers with the bug reports they can't do nothing about, and provide them with a package to assign it to. So far the hurd package has been used for this purpose (not often, but a couple of times). That's what I said above. If a better solution is acceptable and preferred in Debian, then that's just as fine. Thanks, Marcus
Forward: Link update in Debian/Hurd website
Hi, can somebody take care of this? Thanks, Marcus ---BeginMessage--- Hi, just noticed that in the page : http://www.debian.org/ports/hurd/hurd-contact the URL of Kernel Cousin has changed and is now : http://www.kerneltraffic.org/debian-hurd/latest.html Cordially, Patrice Jaeck ---End Message---
Re: Debian GNU/Hurd sources.list
At Tue, 9 Mar 2004 05:31:38 +0100, Guillem Jover wrote: deb http://ftp.gnuab.org/debian unreleased main deb http://ftp.debian.org/debian unstable main Thanks a lot for doing this! I installed Debian GNU/Hurd recently, and used your packages, and it worked out ok. Marcus
Re: Debian GNU/Hurd K5 on bochs (network problem and gnumach recompilation)
At Sat, 6 Mar 2004 18:51:50 -0800, Obi wrote: I've seen previous email about running Hurd on Bochs: by then I already managed to install Hurd K5 on bochs 2.1.1 (discovered to use 2.1.1 thanks to this mailing list :)). Everything seems to works (slowly but) fine, a part from the network. The tun0 device is been created and my script configure it correctly, but the Hurd doesn't seem to see the card. I'm not so familiar with Hurd, but it seems that the kernel doesn't seem to recognized the ne2k: where can I find out the kernel messages? How can I tell if the card is or not recognized? And I'd like to recompile the gnumach kernel: make-kpkg spoiled me, so I found myself a bit lost in the process. Which kernel should I use? Where can I find instructions to recompile it? It worked fine for me, I am using the current debian package of gnumach. If you compile your own one, you must make sure that you enable the right network adapter at configure time (should be ne2k). You should use the gnumach-1-branch in CVS if you want to compile your own one. Instructions are in the various README's. It's probably best to just build the deb if you know how that works. BTW, I am using bochs 2.0.2, 2.1 didn't work for me (cp, perl were broken). Bochs is very slow, so slow that I didn't do extensive stability tests. I tried qemu a bit more, and found it to be quite unstable. Too unstable to compile anything within the emulated Hurd system. Thanks, Marcus
Re: Debian GNU/Hurd on qemu
At Sun, 29 Feb 2004 05:35:44 +0100, Marcus Brinkmann wrote: many people ask how to run Debian GNU/Hurd on bochs. Some people had success with this, while others had less luck. Here is what I did to make it work. Thanks to p2, weinholt, Jeroen and the other guys on IRC, who helped me out here and there. If you are adventurous, you might like to try qemu. http://fabrice.bellard.free.fr/qemu/ Everything works exactly as described for bochs (except you don't need to setup bochs, of course, but you need the hdimage etc). Then you run this: $ qemu -m 128 -boot a -fda ~/.bochs/guest.fd0 -hda ~/.bochs/guest.hd0 -n /home/marcus/gnu/bochs/start-tun Or if you installed grub on the hd image: $ qemu -m 128 -hda ~/.bochs/guest.hd0 -n /home/marcus/gnu/bochs/start-tun etc. qemu is a LOT faster than bochs, and this makes a huge difference (by orders of magnitude). However, its emulation is not as complete and exact as bochs. Plus, it seems to be less stable (in fact, it hangs quite often, and right now my mouse pointer is dead). So, it's definitely less mature and much more experimental. However, the speed advantage can be worth to wreck your X server ;) It's a no-brainer to try it out, there is no kernel patching or anything like that involved, so give it a try. Thanks, Marcus
Re: Debian GNU/Hurd on bochs
At Sun, 29 Feb 2004 08:14:05 +0100, 3. Making a filesystem (you need to be root to do that) #losetup /dev/loop0 /hurd/hurd.img -o 32256 (that magical offset value is bytes/sector times sectors/cylinder, and gives access to the partition we created, keeping the partition table safe) #mkfs.ext2 -o hurd /dev/loop0 quote/ Ah yeah, that looks very good. The only concern I'd have is the length of the filesystem. The partition might not actually expand to the very end of the loop0 device. So, I'd suggest that you first create the filesystem in parted, then set up the loop0 device, then run the e2os script and e2fsck. Unless you can somehow control how much of loop0 is actually seen by mkfs.ext2 etc. Thanks, Marcus
Debian GNU/Hurd on bochs
Hi guys, many people ask how to run Debian GNU/Hurd on bochs. Some people had success with this, while others had less luck. Here is what I did to make it work. Thanks to p2, weinholt, Jeroen and the other guys on IRC, who helped me out here and there. 1. Setup bochs. You need bochs 2.0.2. Bochs 2.1.x has problems with the newest coreutils (cp: memory exhausted bug and another bug, where perl fails with Your random is not that random no matter what you do). You can install bochs 2.0.2 on Debian GNU/Hurd by adding this to your /etc/apt/sources.list: deb http://snapshot.debian.net/archive pool bochs And running: # apt-get install bochs=2.0.2+20030829-1 bochs-wx=2.0.2+20030829-1 bochs-x=2.0.2+20030829-1 Then: $ zcat /usr/share/doc/bochs/examples/bochsrc.gz ~/.bochsrc Edit the file. I don't use wx but textconfig, and the x display lib. Peter warned me that wx used to be buggy (YMMV). Choose as much memory as you want/can spare. I use a floppy drive image in ~/.bochs/$GUEST.fd0, and a hard drive image in ~/.bochsrc/$GUEST.hd0. To get the actual hard drive image values (C/H/S), see below. Floppy is 1.44 MB. One thing you will want (if you are serious about this) is network access. So, install the tun (tun.ko on Linux 2.6) module, create the device (cd /dev; ./MAKEDEV tun), set the ownership so that your user has access to /dev/net/tun (no need to run bochs as root), and add to your bochsrc: ne2k: ioaddr=0x280, irq=9, mac=fe:fd:00:00:00:01, ethmod=tuntap, ethdev=tun0, script=/home/marcus/gnu/bochs/start-tun Of course, your script location will vary. My script looks like this: #!/bin/bash sudo /sbin/ifconfig $1 192.168.42.1 # If you use IP masquerading, for example: # sudo /usr/sbin/ipmasq Make that executable. The IP address is the one of your host then (of the virtual ethernet bridge). The other one will be configured in your guest OS (GRUB and the Hurd). This pretty much covers bochs. But we will need the images. 2. fd0 image First create floppy images. This has become quite simple. Create a directory boot/grub in which you copy all the grub files: $ mkdir -p boot/grub $ cp /usr/share/grub/i386-pc/* boot/grub Create a menu.lst file for grub and put it into boot/grub/menu.lst. Then make a tar file out of it: $ tar czf boot.tar.gz boot Then create the disk image with the Grub tool mkbimage: $ mkbimage -s ext2 -t 1.44 -f boot.gz That's it. Copy or link the file 1.44.image to ~/.bochs/guest.fd0 3. Optional: Grub and tftpboot This is a fancy setup I use to test new L4 kernels etc without changing my hd0 image. Instead using the Debian Grub in step 2, compile one with networking. I got mine from Peter, it supports the bochs network card (don't know how Peter built it). Then put in the following menu.lst: ifconfig --address=192.168.42.2 --server=192.168.42.1 default 0 timeout 0 title = default configfile (nd)/tftpboot/bochs/grub/menu.lst Install tftpd, create directory /tftpboot/bochs/grub/, change /etc/inetd.conf to use /tftpboot instead /boot, create the menu.lst file in /tftpboot/bochs/grub, in which you can then refer to kernel files in (nd)/tftpboot/ etc. GRUB will download the menu.lst and all kernel/module files via tftp. Very useful. To test a new kernel, just copy it into the above directory and press Reset in the bochs window. 4. hd0 image Now, you have a floppy image. Try it out if you want, by booting from floppy: boot: floppy in bochsrc. You need to do that, as the hd0 image will not be bootable, even when we created it. Which we will do now. $ bximage Select the size you want, and type flat. This tool will give you the C/H/S values for the hard drive geometry, which you have to enter into bochsrc. You also need it to create the disk label. Start $ /sbin/fdisk ~/.bochsrc/guest.hd0 Then select expert mode (x), and set the cylinder (c), heads (h), and sectors (s). A 512 MB hard drive has C/H/S of 1040/16/63. Then leave expert mode (r) and write the MS-DOS disk label (o). Supposedly you can do all this with parted, but I didn't see how you can set the drive geometry in parted (maybe it doesn't matter). Then you need to create a partition (p etc). I assume you make one primary partition in slot 1, which covers the whole disk. At this point, you may be able to boot from CD and make a CD based install in bochs. I didn't try that. But if you do thaat, you are now fine. In fact, in this case you don't even need to setup a partition or a disk label above. I will continue assuming you want to do a network install. Once you have that, you need to create a filesystem. That's quite a challenge actually, if you want to do it generically, as you don't know where the fs is in the image. I am sure there are many ways to do this, and probably many files to do that, too. I like it the hard and manual way, so this is what I did: Create the filesystem with parted (mkfs 1 ext2). This is however a Linux owned filesystem, but we need the Hurd
Re: locales lock locale-archive fail
At Mon, 16 Feb 2004 01:22:03 +0600, Dmitry V. Zhulanov wrote: ru_RU.UTF-8 ...cannot lock locale archive Maybe it tries to perform an unsupported set lock operation. Only whole file locking is supported, and many people tend to lock only the first byte. You have to check out the source code. Thanks, Marcus
Re: Hurd is no window manufacturer!
On Sat, Jan 10, 2004 at 06:39:18PM +0100, Jens Seidel wrote: On Sat, Jan 10, 2004 at 11:51:58AM -0500, [EMAIL PROTECTED] wrote: i live in buffalo ny and i the past 4 days my windows have been icing up on the bottom...i was under the impression this would not occur with a hurd windowany suggestions Please note that Debian/Hurd is a Unix-like operation system for your PC! There is no relation to windows and the hurd brand! It is, www.hurd.com. But this list is not related to it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Call for Papers: FOSDEM 2004: 2nd EMBEDDED SYSTEMS and OPERATING SYSTEMS track
2nd EMBEDDED SYSTEMS and OPERATING SYSTEMS track at FOSDEM 2004 === 21 - 22 February 2004, Brussels Call for papers --- The 2004 edition of FOSDEM (Free and Open Source Developers' European Meeting; http://www.fosdem.org) will take place in Brussels, Belgium on 21 and 22 February 2004. For the second time, a track on Embedded and Operating Systems will be organized. The first edition was quite succesful and attracted up to 100 attendants for certain topics. The program and papers of last year are available at http://www.embedded-kernel-track.org/2003/ The use of Free Software in the infrastructure of Embedded Systems is booming, e.g. by the use of Linux, uClinux, eCos, RedBoot, RTEMS and many other Free Software components. Operating System development has always been a very important topic in Free Software. As embedded and real-time systems typically have special OS requirements, we organise this Free Embedded and OS development track at FOSDEM. This track at FOSDEM provides a remarkable opportunity to present and discuss the ongoing work in these areas, and we invite developers to present their current projects. Technical topics of the conference include but are not limited to : * OS Development : kernel architecture and implementation (e.g. Linux, BSD, the Hurd, ...) * Embedded Development : tool chains and project cases (e.g. tool chain projects, packaging for cross compilation, portability, ...) * Real-time extensions, nanokernels and hardware virtualization software (e.g. RTAI, Adeos, KURT, L4, ...) * Hard real-time OS's (eCos, RTEMS, ...) * Embedded Java: open source implementations and the compatibility question (Classpath, Kaffe, Wonka, ..., Mauve, JCK, JCP, ...) * Open hardware and softcores (e.g opencores.org, OpenRISC, leonSparc, FPGA's, ...) * GUI's for embedded systems (Gtk, Qt, MicroWindows, ...) Authors are requested to submit their abstracts online to [EMAIL PROTECTED] before 18/12/2003. Notification of receipt will be sent within 48 hours. Authors wishing to submit a full paper (between 6 and 12 A4 pages), can do so in PS or PDF format. The Program Committee will evaluate the abstracts and consists of: * Herman Bruyninckx, Professor at K.U.Leuven, Belgium * Geert Uytterhoeven, Sony NSCE, Belgium * Karim Yaghmour, Opersys, Canada * Marcus Brinkman, University Bochum, Germany * Peter 'p2' De Schrijver, Mind, Belgium Peter Vandenabeele, acts as practical organiser for this track. All communication should be addressed to [EMAIL PROTECTED]
Re: [NEWS] Thomas Bushnell Leaves HURD
On Sat, Nov 22, 2003 at 11:58:33AM +0200, [EMAIL PROTECTED] wrote: On Fri, Nov 21, 2003 at 01:43:28PM +0200, Ognyan Kulev wrote: This is strictly an internal GNU struggle, and has no relevance at all on anything except how GNU is organized and what it means to be a GNU maintainer. In particular, Thomas did _not_ get dismissed from the HURD project [sic], nor is it true that Thomas leaves HURD [sic]. I'm glad that it's not that bad as it sounds when written and commented in the news :-) Well, the objective of the news is to publish something every day. If that means copying rumors that sound interesting from other news media, then that's ok, even if that means that your story is made of wrongness and irrelevance. In other words, ignorance has rarely stopped something from being published, nor does ignorance stop certain people from commenting. Sometimes its worse than it sounds, sometimes not at all. You have to apply your own scrutiny and judge the quality of the presented material (what sources are given? etc). In particular, nobody involved and who knew the facts had been even asked about it, and this is obvious from the content of these reports when you consider what is said, and more importantly, what is not said. The most important thing to learn from this is that the majority of things published in news media, be it online, print or TV, is not researched or investigated, but cut and pasted from press releases, press agencies, or simply other news media. That this has a devastating effect on the quality of the fourth power in state is apparent all around you (and you can think of the other consequences to society yourself). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: GNU-Hurd installation: extracting the base-system fails
On Thu, Nov 06, 2003 at 03:16:32PM +0100, Robert Millan wrote: - It's not clear to me if the so-called FSF policy allows hosting Debian CD images (remember our discussion in web-hurd). Previsouly, it was established that they only contain free software before they were put there. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: acl: FTBFS on GNU/Hurd
On Sat, Oct 11, 2003 at 05:49:08PM +, Robert Millan wrote: Fixed now. Someone should bang upstream with a large trout over this ;) This is a typical porting problem, but you should be trouted for not having this figured out before making the bug report ;) [...] -ifeq ($(PKG_PLATFORM),linux) +ifeq ($(PKG_LIBC),gnu) PCFLAGS = -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 endif [...] + +case `uname -s` in Linux|GNU|GNU/*) pkg_libc=gnu ;; esac +test -z $LIBC || pkg_libc=$LIBC +AC_SUBST(pkg_libc) This check is just dumb. It can be done slightly better with this check from the gettext package: /usr/share/aclocal/glibc21.m4 However, this is still suboptimal. Why not just use these: AC_GNU_SOURCE AC_SYS_LARGEFILE I will never understand why people make things so artificially complicated ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian Hurd package
Hi, we have always actively encouraged other people to help with this. Whenever someone asked me about making a new version of the Hurd package (last person to ask was Jeff), I said Pleeeaaase! with three pieces of sugar on it. On Fri, Oct 10, 2003 at 06:02:02PM +, Robert Millan wrote: In order to ensure the Hurd is properly maintained within Debian, I'm going to NMU the Debian Hurd package. I intend to do the following: - CVS update. - change Maintainer to debian-hurd@lists.debian.org. - add myself to Uploaders. Ok for me. - re-write debian/rules for easier maintainability (using CDBS). That's bullshit, but up to you, if you are committing to it. I guess Jeff will be happy about it, and I stopped caring. I doubt anybody else (who counts) will have an opinion. I'll wait a week or so to see if some of you is planning to fix these problems already, or has any comments. No reason to wait. Just do it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian Hurd package
On Fri, Oct 10, 2003 at 08:59:12PM +0200, Marco Gerards wrote: - Can you show the user a dialog when configuring the Hurd package so the user can choose if he wants to use the old or new console? No way. Dialog boxes at installation time are evil in general, but that's just one reason. The new console should just be the default when it can be. We don't need more testers of what works reasonably well already, but new features that allow it to work with X. - Add fatfs and make sure it uses read-only by default, etc. Just to make it easy for users to access their files on those partitions/floppies and I'd like more testers. :) Agreed. The read-only part is important. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: acl: FTBFS on GNU/Hurd
On Fri, Oct 10, 2003 at 09:16:19PM +, Robert Millan wrote: +#define __USE_LARGEFILE64 If the two underscores are not a hint enough for you, here it is in clear: You are not allowed to mess with __* symbols in glibc. There is an official interface, and it is _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE. Probably acl already can define that if it is needed, check the configure script and other places for that. There is nothing in the GNU/Hurd's large file support that is different from GNU/Linux's, because it's the same glibc (at least as far as the interfaces are concerned). +#define __USE_XOPEN_EXTENDED See above. There are two relevant symbols: _XOPEN_SOURCEIncludes POSIX and XPG things. Set to 500 if Single Unix conformance is wanted, to 600 for the upcoming sixth revision. _XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions. You can not just define away things blindly just to make it compile. First of all, you must use official interfaces. Second of all, you must investigate why it doesn't work without this hack on the GNU/Hurd already, because there shouldn't be any difference to GNU/Linux. Inspect where the problem lies, and fix the root of it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: attr: FTBFS on GNU/Hurd
On Fri, Oct 10, 2003 at 09:17:24PM +, Robert Millan wrote: +#define __USE_XOPEN_EXTENDED Same crap as for acl :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian Hurd package
On Fri, Oct 10, 2003 at 10:55:59PM +0200, Marco Gerards wrote: But what do you want for now? The current status is that people don't know about the new console and that X doesn't work with it. Do you want debian to wait until it works with X? I want people to write code. I am willing to work on the console to make it work with X, but I can't do that soon. I know. But pointing users with a large blinking sign to code that is in a half-working state is not a solution. Documenting bugs and missing features is not a solution. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Use of negated arches for dpkg dependencies
On Sun, Oct 05, 2003 at 11:58:02AM +, Robert Millan wrote: The general tendency is adding our dpkg arch to the list of _negated_ arches, e.g: [!hurd-i386 !freebsd-i386 !netbsd-i386]. This will get weird when we have 13 arches or so, and by the time we reach that we'd have to send a new patch every time we start another port. So I suggest that we carry that task where it belongs to. Instead of maintaining a list of non-linux arches, maintain a list of linux arches, e.g: [alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sh sparc] Sounds overkill adding 13 arches at this time, but at some point the negated list will outgrow the standard one, and then it'll look even worse. The right solution is of course to be able to specify patterns like *-linux-gnu. As for what is done today: As you rightly point out, today the list of GNU/Linux arches is 4 times as long as the number of non-GNU/Linux arches, so you will have a hard time convincing package maintainers or Debian policy that this change is desired. And given that both solutions are wrong, and the first one is the less ugly _today_, I don't see any reason for change. Again, the right solution is to fix this architecture mess once and for all by not using a simple matched string for both the cpu and the OS. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Use of negated arches for dpkg dependencies
On Sun, Oct 05, 2003 at 03:41:16PM +0200, Michael Banck wrote: Marcus, are you still interested in that? I can understand if your enthusiasm died away some time in the last 4 years... Not only did my enthusiasm die away about 3 years ago, I am also highly suspicious if implementing the right technical solution is in the best interest of Debian, which by now has to give a higher precedence to stability and compatibility. (This was already true 4 years ago, it is just even more true today). The solution that is going to be implemented will probably only provide a subset of all desirable features, chosen on the basis what still works without introducing too many new problems. I don't know enough about Debian's archive software to give advice on what that could possibly be, and I don't have time to get this knowledge. The only circumstances that could get me to tackle this issue again would be a new archive system for the GNU system, but even for that I wouldn't have much time these days. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Use of negated arches for dpkg dependencies
On Sun, Oct 05, 2003 at 05:14:24PM +, Robert Millan wrote: On Sun, Oct 05, 2003 at 01:12:12PM +0200, Marcus Brinkmann wrote: The right solution is of course to be able to specify patterns like *-linux-gnu. Yes, but this is a long-term solution. Well, 4+ years, a dpkg rewrite, and dozens of arches make up a long term for me. so you will have a hard time convincing package maintainers or Debian policy that this change is desired. I'd have a harder time sending a report for each package every time a new non-linux arch is added. Yes, you. But others would have a harder time if they wanted to add another GNU/Linux arch. Shifting around work from one person to another is not exactly a solution to the problem. And given that both solutions are wrong, and the first one is the less ugly _today_, I don't see any reason for change. The reason is that (as usual) we're coping with a work that doesn't belong to us. If a package depends on a linux-specific one, this is the package maintainer (or the Linux-based ports maintainers) who should take care about it. Well, that argument has some merit. If you want to change things, I guess the best, maybe the only way, is to get existence practice changed on a case-by-case basis and then get it solidified by a Debian policy change. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Re: live cd
On Thu, Oct 02, 2003 at 01:29:11AM +0200, Svante Signell wrote: On Thu, 2003-10-02 at 01:03, Svante Signell wrote: Hello, Excuse me for jumping in here. I'm one of the lurkers. I have been a supporter of GNU for many years and have followed the GNU development long before even Linux was born. I am still a fan of GNU idea an appreciate very much the (L)GPL compared to other free licences. What is sometimes very frustrating though is the stubbornness to add features to a specific tool, e.g. Grub in this case. Another more famous example is the CVS issue. If there had been some openness of the goals of CVS tools like Bitkeeper would not even exist (Larry McVoy go disappear somewhere). Other examples are Emacs vs Xemacs, gcc vs. egcs etc. I don't have a proposal for a solution, maybe I'm just frustrated. On my to do list is still to install Hurd on one of my computers to really get going with the real GNU thing, not just Linux. BTW: Is it true that the L4 will be distributed under a BSD licence, not (L)GPL? There is a very simple counter argument: All of these you mentioned are free software. You are not only allowed, but _encouraged_ to take them, rip them apart, add features, and republish them with your enhancements. If you succeed, you will certainly get attention. For example, egcs eventually was merged back into the official gcc, which organization was redone. So this is actually a pretty good example of how things can work out well. There is a high barrier for new features in GNU projects. And although it can be frustrating to experience that, you must understand why that is so. For one, GNU tools strive for technical excellence, and high portability. If you want to add something to coreutils, for example, it must not only be excellent code, but also (as far as feasible), run on dozens of architectures. I don't know the reason why CD support for GRUB was officially discouraged. Maybe there are technical reasons behind that, maybe just organizational. But if you add CD support to GRUB, and there are no good technical arguments against it, it can likely go into the Debian version of the package and be used by Debian GNU/Hurd. You could fork grub if you want to do even more work on it. Eventually, your work can be merged back into grub official, or pupa, or you will become the real grub and the other will vanish. However, if all you are saying is that other people are not working on the features you would like to have, I have no answer for you. Then the only thing you can try is to hire people, or try to convince them that it is worthwhile to work on that feature. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: please test libtool 1.5a
On Tue, Sep 23, 2003 at 01:26:29PM +, Robert Millan wrote: And next time, please keep non-Debian issues of debian-hurd. Well I just CCed both help-hurd and debian-hurd to get broader audience. Actually, it's of utmost importance to Debian GNU/Hurd. A broken libtool, once released, will cause endless pain and sorrow to anybody building binary packages for Debian GNU/Hurd. Been there, done that, it was not pretty. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: GNU K4 images available.
On Mon, Sep 15, 2003 at 12:57:12AM +1200, Philip Charles wrote: On Sun, 14 Sep 2003, Robert Millan wrote: On Sun, Sep 14, 2003 at 10:13:27PM +1200, Philip Charles wrote: Con. apt-cdrom does not work. It should work, but IIRC gnu mount failed to parse some sort of command options, see: #151407: hurd: mount can't parse dselect command It would be great to have it working, but I suspect that there are other priorities (which I would agree with). As I said in my mail, this is likely very easy to fix with argp, and I am willing to take a look at such a (tested) patch. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hazelnut - Pistachio
On Mon, Sep 01, 2003 at 01:49:51PM +0200, Jochen wrote: regarding to the discussion about the microkernel version, which is used for the L4 / Hurd in the Hurd advocacy thread I just found more information about hazelnut than pistachio at the GNU websites: Porting GNU Hurd to L4 http://www.gnu.org/software/hurd/l4-hurd.html shows as far as i can see only information about hazelnut and fiasco but nothing about pistachio. This page is not linked to by the main page. The only way you can find it is by following out of date links and google index. The link to the l4hurd project that is on the web page points to an obsolete source of information, too, though. Additional this website was last updated in December 2000. It's still in the CVS, but that doesn't mean it has any authority. As there is infomation about the project status, motivation for porting to L4, mailing lists, and so on, I would recommend to update this website to the actual status. I guess I better delete it. The Hurd advocacy thread discussed, how to improve the number of developers, how to get more interest by people and so on. Having actual websites about this project has to be highest priority -- in my opinion -- to get all those interest, discussed here. We suck at writing web pages. Feel free to write some. If we like them, we might even incorporate them on gnu.org. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: GNU/Hurd Section on the website
On Sat, Aug 30, 2003 at 08:01:30PM +0200, Alfred M. Szmidt wrote: Any volunteers that would like to work on the Debian GNU/Hurd pages? Me (I have access already). Please tell me what needs to be done. Marcus, care to enlighten everyone on what needs to be done there? Other then the obvious like removing obsolete content, fixing things that are wrong, etc. Well, Debian GNU/Hurd should document the Debian version of the GNU/Hurd. and answer all the questions a new user of Debian GNU/Hurd might have. I don't really have any detailed answer on that question. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd advocacy? Bootable (Knoppix-like) CD?
On Thu, Aug 21, 2003 at 11:42:13AM +1200, Philip Charles wrote: For a GNU live CD to work a hurdish ramdisk would have to be created and setup at the initial boot. If this could be done we could also use this to create a native GNU installer. At the moment the CDs have to use a Linux ramdisk and then reboot into GNU once the HDD has been setup. I can think of no way of rebooting into a ramdisk. A more interesting setup would be to mount the filesystem on CD and then layer a unionfs on top of it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Bootable (Knoppix-like) CD -- ramdisks
On Thu, Aug 21, 2003 at 05:21:23PM +1200, Philip Charles wrote: Can translators be stored on an iso filesystem? If not we are probably fscked from the start. Thomas put extensions for that into iso9660fs, but I have no idea how to create such an image in the first place. We might need to hack mkisofs. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Bootable (Knoppix-like) CD -- ramdisks
On Thu, Aug 21, 2003 at 04:42:34AM +0100, Greg Buchholz wrote: On Thu, 21 Aug 2003, Philip Charles wrote: For a GNU live CD to work a hurdish ramdisk would have to be created and setup at the initial boot. If this could be done we could also use this to create a native GNU installer. At the moment the CDs have to use a Linux ramdisk and then reboot into GNU once the HDD has been setup. I can think of no way of rebooting into a ramdisk. Can this ramdisk be a regular hurd translator? Or does it have to be a special beast because the full system isn't up and running? I'm guessing it must be the hard one (anyone care to venture a guess?), because it seems like a ram disk would be one of the easier translators to make. I'm sure this has probably been discussed before, so I'll google around to see what I can come up with. We already have tmpfs which runs on raw memory and doesn't need any filesystem. But tmpfs is buggy. You can also always use a store made up from fresh memory, but that store would then need to be initialized with a filesystem (I think you use -T copy zero:16M for a 16MB RAM store, or so). A more Hurdish approach would be to have a unionfs translator laid on top of a regular read only filesystem. There are prototypes of such unionfs filesystems implemented, but more work would be required. Maybe for version 2? Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd advocacy? Bootable (Knoppix-like) CD?
On Thu, Aug 21, 2003 at 02:15:24PM +0200, Niels M?ller wrote: Philip Charles [EMAIL PROTECTED] writes: For a GNU live CD to work a hurdish ramdisk would have to be created and setup at the initial boot. I think that's what the gzip store type is for; it's a store that is initialized by unpacking gzipped data in an underlying store. It should be possible to use it with the plain ext2 translator, although it might be inefficient compared to a specialized ramdisk fs. Hmm, we probably don't even need the gzip store, as GRUB can inflate the image for us. I'm a little confused about the Hurd boot procedure in general, but I guess it should work like this: GRUB loads the kernel, the ext2 root translator, any other servers (proc? ld.so?) which are needed for boot, only ld.so, which then starts exec, which it can read from ext2fs. From there, ext2fs starts init, which then starts the rest (auth, proc). and the gzipped ext2-image (which must contain enough free blocks so that new files can be written to it). The kernel wraps the loaded filesystem image into a memory object. Which is currently not supported :) Then the ext2 server must be started with arguments that tells it to use a supplied memory image as the underlying store. Theoretically possible. When the root filesystem is running, control is passed on to some boot script (/etc/runsystem?), which can install whatever additional symlinks and translators that aren't present already in the filesystem image, and start the rest of the system. I'm not sure what the missing pieces (if any?) are. The memory object store type? That exists, I think. Probably untested. The passing of the memory object between kernel and the root ext2 server? The creation of a memory object from a grub module? Right, those are missing. Probably not too hard. Another issue is that as we have no writable disks, the system must be reasonably stable without swap, or one has to fake some swap by by somwhow putting a swap file inside the ramdisk (ugly and wastes some more memory). Yeah. Well, I think that the above procedure is mostly useful for diskless booting. For the CD Rom, a unionfs seems to be the better approach to me, as it saves a lot of RAM. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd advocacy? Bootable (Knoppix-like) CD?
On Thu, Aug 21, 2003 at 02:40:46PM +0200, Niels M?ller wrote: Marcus Brinkmann [EMAIL PROTECTED] writes: Well, I think that the above procedure is mostly useful for diskless booting. For the CD Rom, a unionfs seems to be the better approach to me, as it saves a lot of RAM. Right, unionfs should be well suited for this. Then you need at least three filesystem processes: The cd-rom, a ramdisk (tmpfs or some ext2 on an image), and the unionfs. Which should be the root filesystem? The root filesystem would be the unionfs of course, with ext2fs using the CD Rom filesystem as the readonly fs, and tmpfs on top of that to store modifications. The boot filesystem would be ext2fs. It would later see that on its root node there is a translator setting and start up the translator. This translator would be unionfs. It would of course need to have the tmpfs translator configured. Maybe unionfs could be hacked to support such a translator internally (as making a read only fs writable seems to be a common operation, common enough to have special support in unionfs for that), or it could be configured to use /tmp-live, which would exist in the CD ROM filesystem and has tmpfs on it. Does it work to install active and/or passive translators, in particular unionfs, on / ? It should work. It probably doesn't, but that's how it should be setup and made work. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Newbie docs
On Thu, Aug 21, 2003 at 02:28:06PM +0100, Mark Wilkinson wrote: 'Hi, I've just heard about Hurd from ..., and I'm interested in helping out. I'm grateful to everyone who works on Open Source software, because it's free. I've attached my CV in Word format so you guys can get a feel for where I may be useful. I've also been looking at Amazon to try and work out what books to buy, any help would be appreciated on this point. Thx Arthur Newbie' ...and gets a response that corrects him on all the contentious points above, instead of a warm welcome and a little advice on reading material. I really don't want anyone to take this as criticism, just a suggestion for helping people feel part of things before we draw them into our culture. I agree except that I'd say correct him _and_ give him a warm welcome and advice. The reason I say correct him is that all of these things, the Open Source movement, the use of proprietary formats and support for software patents (which Amazon does in a most desisable form) are hurting us very much up to the point of threatening the base of our (desired economic) existence. And I am not exaggerating here. I definitely and very much agree that there is no need nor reason for not doing that in a respectful and curteous manner. Although sometimes newbies are treated roughly on our mailing list and in particular on IRC, I hope that this will stay the exception. It doesn't hurt however to get reminded of the importance of this, like with your mail. One thing I want to add. I was interviewed by a researcher who tried to find out how free software development works, and why it works. She analyzed the various operating system group's activities (Linux, BSD, the Hurd), and she did ask me specifically why we had hardly any flame wars on our mailing list. I believe and hope that this is not just because people who disagree with us remain silent, but also because we generally are respectful in our communication. And I don't want to be proved wrong on that ;) So, everyone, please, we have a good reputation, which is well worth fighting for! Think twice before raising political issues, and if you feel you can't take the seconds it takes to calm down and write in a particularly friendly or neutral manner, don't reply at all, but let someone else do it. One could thing to do is to every second time not to write do nots but do's. Like: Please use a portable document format like PS or plain ASCII instead don't use Word, and Please use the term Free Software to encourage thinking about the freedom of the software instead don't say Open Source. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: distribution question
On Thu, Aug 21, 2003 at 12:05:19PM -0400, Matthew Grant wrote: Hi folks, Would it be a waste of time and bandwith if me and my server offered cvs (daily or weekly) tarball snapsots of hurd,gnumach,mig and gnu's unofficiall oskit? Just curious if this would help the community in any way. Something that would be a good idea is to compile prominent GNU packages from CVS once in a while, so errors (in particular errors specific to the Hurd) are caught early. This however requires a certain amount of human work. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Wed, Aug 20, 2003 at 10:11:17AM +0200, Farid Hajji wrote: The Hurd provides the same security protection that other POSIX systems, including Linux, BSD, etc... If AROS runs as a user-level application in the Hurd, it will be as secure as other user-level applications. If it runs as a task (or set of tasks) directly on top of the microkernel (Mach, L4, ...), it will be even more isolated from other tasks, including Hurd tasks. There are a couple of issues though you have to be aware of if you want to do that. First of all, Mach is open to all sorts of DoS attacks. L4 isn't, because all global effects are wrapped in system calls which require privileges (ie, only the root task can call them). So the root task becomes the aribter on such privileged operations. Of course we will have a generic rootserver that allwos you to do that. The only other thing that you then must be aware of is the DoS attack of bombarding other (server) threads with messages (which they will reject of course). There is a feature in L4 (redirector) that can be used to prevent that, but it causes an overhead on every IPC from that thread you use it for. Still you might have to use a global redirector task in the system that controls which task is allowed to send messages to which other tasks (or subsystem, if that's a feature you want to have), for ultimate security. This thread is not off-topic, but on the wrong list :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Tue, Aug 19, 2003 at 09:55:40PM +0200, Marco Gerards wrote: How about NUMA? AFAIK it matter a lot for NUMA systems which page a task gets. And will we support NUMA? (I'm sorry if this is a bit off-topic). Even in NUMA you have classes of homogenous memory, and within a single class all pages are the same. How to handle several classes of such memory is an interesting problem, and would certainly have to be handled by privileged system code to prevent DoS attacks or unfair treatment. But it is orthogonal to the problems of how to manage sharing the memory resources within a uniform memory. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Tue, Aug 19, 2003 at 10:06:15AM +0100, Dave wrote: OK, I think I can comment here, as I'm someone that's used Linux for years and has periodically looked into Hurd. Here are major concerns from this end: [snip] I only have one thing to add, and that's that the Hurd needs a lawsuit from SCO. ;) Actually, this is an interesting point, as the FSF has long warned that the copyright situation of Linux is so that it is difficult to defend the Linux source code in court. This is why the FSF is so careful about requiering copyright assignments and proper changelogs in the GNU project. Chance is that no company would ever dare to claim that GNU code was taken from them without a license unless it is really true, and in that case it can be tracked down to the person who did that. This is also true for the GNU Hurd. SCO has realized that this is not true for Linux, and thus saw a chance to take advantage of it. I think that SCO has correctly identified one of the main weaknesses of Linux, and it should be a warning to any high profile free software project. Note also that the problem here is not the GPL, it is the lack of code maintenance (proper history records) and copyright assignments. The GPL has been defended successfully in the past (and that this has not happened in a court, but outside of it, is a further prove that it is a strong license). It has even been defended for the Linux source code, but in such cases the origin of the Linux source code was not disputed, only the consequences for a mix of Linux code and proprietary code. I would still not want to be sued by SCO. It's a big hassle, and even the threat of such a suit can be an effective tool to get a better deal in negotiations. You have to choose your fights carefully. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Improving the (web) content (was: Re: Hurd advocacy?
. If all the document titles listed above existed and could be kept within a rough length of say, between one and eight A4 pages, then that becomes material that could be used in lectures, which in turn could significantly raise the Hurds profile. Something like the above could potentially create new issues, who 'controls' development? Who settles disputes when there are two conflicting opinions on a matter that can only have one outcome? But to me open source is about settling things through open reasoned discussion, and I'm sure that as long as these things are thought about prior to acting on any of these suggestions, it can all be worked out. It's up to us to draw people in and invite them to gain experience while working on a complex real world project. It offers the opportunity for people to broaden their knowledge and skills, and see something real grow from the work that they've put in. These are just opinions, I feel like a fraud for typing so much when I haven't even got the Hurd installed on my PC yet, but if we could get our foot in the door of universities/technical colleges then there's the potential for an entire generation of software engineers/programmers to at least be aware of the Hurd even if only 1% of that number actually get involved. Feel free to shoot me down in flames/tell me to stop prolonging this time consuming thread. Thanks, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
ReRe: Improving the (web) content
On Tue, Aug 19, 2003 at 03:47:42PM +0100, Mark Wilkinson wrote: I'd be happy to review and make suggestions on anything that was provided to me. That's great! Hopefully we get some volunteers that I can assign to you as your slaves then :) As the lists proverbial idiot, That's just not true. Of course if you haven't even installed the Hurd so far, you don't have much experience in the Hurd. But the accuracy of identifying the main questions a new user shows not only that you have not lost touch of the beginners problems (being a beginner yourself), and second that you can identify and express these problems and have ideas how to solve them. And, you are motivated, as you wrote it down and sent it to the list. anything that I get, understand and appreciate will qualify as the sort of idiots guide that we're looking for. I'm happy to recieve documentation in HTML, OpenOffice, MS Office, PDF or plain text formats and will do my best to provide suitably constructive criticism. One part of our culture is to reject proprietary products like MS, and, while I am at it, another part is to call free software Free Software and not Open Source (as you did in your other mail). This leads me to the idea of another document, that explains some of the things of our culture, why they are the way they are, so people coming from elsewhere (university, business) have a better understanding on what's going on (ie, things like how we are organized, which tools we use for interaction, etc). I don't feel ready to be writing documentation for Hurd yet though, I'd kind of like to get it installed and to some extent working before I begin documenting things myself. Be sure that I'll be adding any problems I get during install to an Installation FAQ though Writing down the problems that you are experiencing yourself is certainly one of the best ways to get started. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Tue, Aug 19, 2003 at 09:38:54PM +0200, PUYDT Julien wrote: Le lun 18/08/2003 à 15:57, Marcus Brinkmann a écrit : L4 does not have any device drivers. Some people are working on a new device driver infrastructure for GNU Hurd/L4, and drivers for that infrastructure. It's a huge task, but it is also an interesting challenge. Device drivers will be in user space and thus can be multi-threaded. This allows to keep state about a device active in the thread, and can greatly simplify a driver. 1. Who works on that infrastructure? You should talk to Peter 'p2' De Schrijver [EMAIL PROTECTED] if you are interested in helping. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Mon, Aug 18, 2003 at 12:37:05AM +0200, Patrick Strasser wrote: How do maintainers react on patches for the Hurd? I there any direction noticalbe? Do poeple know about the Hurd and it's idiosyncrasies? Most often they are accepted without hassle. Usually this is because the Hurd is pretty POSIX compatible, and the bugs fix problems with the source code to make it run on more POSIX systems. Sometimes we have issues, because the Hurd makes some drastic decisions. For example, we don't define a global PATH_MAX, and some maintainers believe that this is ridiculous :) But for every maintainer like this there is also a maintainer who is very happy to see the patch, or even does some non-trivial amount of work to help us to get there. - Is a lack of documentation the real hard thing for new developers to overcome? In deed. And I like to read documentation in pdf. Others like it in info. You can convert texinfo manuals into pdf, though. Regarding stability: I expect to see people hop on the train when the Hurd is more stable. Features are not the problem. But noone wants to use a system that has lots of features that work only 95% ot the time (Although most people do... ;- ) I agree a lot. This is why I was working bugs and crashes for a very long time before I even considered working on Hurd projects like translators or design issues. I got a lot of bugs fixed, even if that required nagging Roland more often than I could provide a fix myself. More people who actually try things and learn how to use gdb to figure out why it crashes are always helpful. Regarding Chicken Egg: A lot has been said about the chicken-egg-problem. Nothing will happen while there are always the same number of chicken and eggs. Other things have to be done to increase the number of active developers and tester, this will not happen by itself. What about a Hurd advocacy task force that activley tries to attract new people? Mmh. Some advocacy is good, but it can also be counterproductive. If the advocacy makes promises that the active developers can not fulfill, people will get a bad impression. So I would rather see advocacy done by people who are also, at least in a minimal way, active, for example in helping with installation problems, bug finding etc. Another thing that somtimes puzzles me: What is the role of RMS in the Hurd? I sometimes read posts about features or releases anounced by RMS, which noone on the lists has ever heard of. Lot's of people keep an eye of what RMS says. RMS is our spiritual guide. He never wrote a line of code for the Hurd, but he has given input on the design in many stages of the Hurd. The FSF has employed people to work on the Hurd in the past, and I think it could happen again. The post about the release was taken out of context and wildly exaggerated. I think that RMS maybe was on the edge of giving up on the Hurd, but we were able to demonstrate that the Hurd is somewhat working as a prototype and is worth working on and supporting. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Sun, Aug 17, 2003 at 05:27:32PM +0100, Mark Wilkinson wrote: If the decision has been made to go to L4, IMHO work should have halted on Mach. People have halted on Mach long before L4 even entered the picture. Forgive my ignorance, but why is L4 3-5 years away? L4 was released a month ago or so. But it is not a drop in replacement for Mach. If the decision has been made to move to a kernel structure that doesn't exist yet, that strikes me as an *interesting* decision. The L4 kernel is truly minimal. The Hurd depends on a couple of features in Mach that simply don't exist in L4. The three core issues: * Device drivers * Virtual memory management * A capability based IPC system L4 does not have any device drivers. Some people are working on a new device driver infrastructure for GNU Hurd/L4, and drivers for that infrastructure. It's a huge task, but it is also an interesting challenge. Device drivers will be in user space and thus can be multi-threaded. This allows to keep state about a device active in the thread, and can greatly simplify a driver. L4 does not have any Virtual memory management, just some primitives to recursively map pages into other address spaces. The physical memory is provided directly to the user space. So we have to implement a VM system. Neal has some great and ambitious ideas about doing VM management locally in every task, instead of a global server. This is a dramatic departure from traditional OS design (even from Mach and the Hurd as it is now), and thus needs to be fleshed out from scratch (there are some academic papers on it, but I don't know of a production system doing it this way). L4 provides a minimal IPC system, that allows direct thread-to-thread message sending. But it only gives a single protection primitive. So it is not usable for a user space multi server system as the Hurd, where untrusted communication is happen on a frequent basis. This is why a more featureful capability system is needed. Instead doing it in a central global server (like the port system in Mach is centralized), we want, again, do it locally in each task. This seems to be a new design to me, and I have worked on the protocols and data srtuctures for that in the last weeks. I am currently working on an implementation, which is needed very early in any porting effort to L4. So you see, it is not about L4, but about glueing Hurd to L4. Mach did a lot of things for us that L4 is not doing, and we take the chance to try to more consequently implement the Hurd's fundamental design ideas. Freedom to the users! Freedom to map your physical memory as you want it, freedom to use the IPC policy you want, and the freedom to have functional device drivers without getting them approved by a kernel master geek ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Mon, Aug 18, 2003 at 05:38:33PM +0200, Farid Hajji wrote: Marcus Brinkmann wrote: So you see, it is not about L4, but about glueing Hurd to L4. Mach did a lot of things for us that L4 is not doing, and we take the chance to try to more consequently implement the Hurd's fundamental design ideas. Freedom to the users! Freedom to map your physical memory as you want it, freedom to use the IPC policy you want, and the freedom to have functional device drivers without getting them approved by a kernel master geek ;) L4 also provides for user-space scheduling, besides the standard in-kernel scheduler. Putting the scheduling policy out of the kernel opens up new interesting possibilities, like, perhaps real-time threads and better support for SMP systems as well. Yeah, but it is not at all obvious to me how to do this, and happily, the Hurd itself doesn't need real time. We will use some of the scheduling interfaces in the device driver, in particular preemption control for interrupt handlers. As about SMP support, we certainly want to do that, but it will not be possible to do it at a local level like memory. Neal gave the heuristic argument to me at Oslo. He said, to paraphrase him, that all memory pages are equal (ie it doesn't matter which page you get), but all time slices are not. In particular, it does indeed matter if you get the next, let's say, one million time slices, or if you get only one and then have to wait a bit until everybody else got a chance to run, and that one million times. Also, time is consumed and then useless to anybody else, while access to memory can be revoked temporarily without too much problems (there is still the issue of caching etc, but it's controllable). The choice of the processor to run on is also not free for the user, because that would open the system to DoS attacks. For example, let's say you run an important task on processor A. Then N users tasks can cooperate in that they all choose to run on processor A. So although the scheduling parameters in L4 are interesting, and will make it possible to provide exciting user level features like real time, it is still entirely open how this could be done the Hurd way. ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Mon, Aug 18, 2003 at 10:01:40AM -0700, deFreese, Barry wrote: Speaking of SMP. If (when?) we shoot for SMP support would we shoot for processor affinity or leave it up to the scheduler like in Linux? Rapidly getting off topic, but as a general rule of thumb we want all the great features that you'd expect from a modern OS. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: MD5 passwords
On Sat, Aug 16, 2003 at 12:41:09PM +0200, Alfred M. Szmidt wrote: Probobly cause we don't have PAM support yet, and Debian GNU/Linux uses that to enable/disable MD5 passwords for chpasswd. PAM has been ported to the GNU/Hurd a long time ago. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Sat, Aug 16, 2003 at 03:07:27AM -0400, Mark L. Kahnt wrote: - I'll leave you to assess whether what you get now constitutes works Right Now. I wouldn't use it for a production system yet, or even as the system on which I did development work, but testing code being targeted to or ported to it, it seems to be getting by. That is a fair assessment. I know that I wouldn't use it on a headless server, as I honestly don't know if it is reliable enough to be able to log in via telnet whenever desired. I know that while ssh is *somewhat* on the system, it isn't secure because the key used isn't built with random numbers drawn from entropy. You could set up egd to provide secure random on the system via a fifo. A similar consideration, as I mentioned in the 1 June email, and later in discussions via email with Kent West was Kent's encounter with mounting partitions. I understand that there is a mount script, but it reportedly hangs the system. The write-ups from various Hurd sites, however, imply that to the user, the common system usage should seem like a common POSIX interface (the parts dealing with command line utilities.) Mounting and unmounting is not part of POSIX. It is past being a research project, but it isn't quite what I understand to be ready for a beta release candidate of a distribution. From the perspective of a codebase to work on and a vision being reached to, it exists. From a user-ready distribution perspective, not this week. Definitely not. Beside the fact that large scale fixes and redesigns are not happening timely enough (or don't happen at all), I believe it is not possible to work out the tiny quirks and buglets like those in mount with a small core team of developers. Beside actually finding these problems, fixing them is very time consuming. This is something that can so easily done by contributors even if they are not core developers (and the bug finding can be done by users), and even if they don't want to make a long term committment. Savannah at sv.gnu.org/projects/hurd has a bug database and a patch database. There have been 7 bugs files, some by me as a reminder. This is ridiculous. Someone (hi bdd) is working on gathering bug reports from the mailing list and put them into the database. There have been filed 32 patches, a third by me, and then the rest by a small handful of people who are already long term contributors. Only 15 patches (including most I filed) are not yet applied, 17 have been applied. It could be 18 if there had been a patch for mount. How hard is it for someone like you who can C and knows Unix to fix mount and submit a patch, or at least submit a bug report? Probably as hard as it is for me. Maybe 5 minutes more to figure out some of the specific Hurd aspects. If nobody except the core people are willing to put up this effort, then why should the core people do it? Apparently it is not at all urgent, and time is better spent elsewhere (ie, on the hard problems, which are also there). A volunteer based free software project of this scale can not be successful with only core developers and end users waiting in the line. There needs to be a solid middle ground. This didn't exist at all before 1998. It got somewhat better, and now we have a middle which is quite productive, at least more productive than any of the core developers with regards to short term fixes etc. ;) This fits with the entry before it on the list - its stable. It's conceptual design is stable, but the binaries aren't necessarily resulting in a system that runs with the level of stability comparable to the BSDs or Linux in comparable breadths of configurations. With some attention to core aspects, both of those could change - essentially focussing on getting a kernel, a core set of translators and servers, and the appropriate aspects of the GNU software suite to provide a functional system that can host its own development and administration (most of which I understand now exists,) a viable base for assembling a distribution, or at least a reliably operational, installable o/s on which the distribution can be ported as necessary. Well, that's the idea. The problem is that of the people who did the outstanding work of implementing the Hurd as it is today (mainly Thomas, Roland and Miles), only one (Roland) is somewhat active at all still, while Thomas only jumps in with a crazy idea or two from time to time. People like me and Neal (and some other folks who have jumped in since then) are targetting the big rewrite of the Hurd. But we are new in the OS writing business, and have to learn a lot of things, and solve problems for which cookbooks do not exist. So while we are trying to do that, who is fixing mount? Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy? (Hazelnut Announcement)
On Sat, Aug 16, 2003 at 06:10:35PM +0100, Ciaran O'Riordan wrote: Should I ask DWN for a correction? It's not important. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Fri, Aug 15, 2003 at 06:06:25PM -0400, Shawn Boyette wrote: This is exactly the conclusion I reached a few days ago when I read about L4 through Debian Weekly News. I keep wanting to play with the HURD, but it keeps on not existing. Well, if you only want to play, there are enough toys out there that are more existing than the Hurd. The current existing Debian GNU/Hurd should nevertheless be enough to play with the Hurd. As a proof of concept, it works quite nicely. This is almost farsical, announcing a switch to a new kernel architecture (which, I might add, is already deprecated by its developers -- Pistachio is the current branch of L4Ka, not Hazelnut) before the previous new kernel architecture (OSKit) migration is even completed. We never considered Hazelnut to be a platform for the Hurd, it is way too limited for that. Not sure where you got it from that Hazelnut is a target. Our is Pistachio. The OSKit integration into GNU Mach is not related to the Hurd at all. It is just a different set of drivers in GNU Mach. Not many people are interested in hacking on that, and this is for good reason. Although it would make the device glue code in GNU Mach more sane, it wouldn't change much from the user experience in the Hurd (in other words: it would still be slow and unstable). The main features you would get with GNU Mach v2 are a couple of drivers (like, a random device, and better serial port support for PPP). Is this a project to produce a kernel for a GNU OS, or is it some sort of never-ending, ivory tower, trans-academic wankfest for kernel geeks? The Hurd is not interesting at all from the perspective of producing yet another unix core. There is BSD, there is Linux, and between the two of them there is absolutely no niche for yet another monolithical kernel intended to be used in production systems. So what the Hurd is about is indeed its user-space design. However, just as the Hurd on GNU Mach as a proof of concept is a good success, it is, as a production system, a fantastic failure. There are several fundamental flaws that absolutely must be addressed to hopefully make the Hurd competitive in performance, stability, security and features. When looking at the options, L4 seemed to be the logical conclusion, because it furthers the fundamental design concepts of the Hurd and implements them more consequently than Mach did. Going to L4 will, unlike OSKit, require a complete redesign of the Hurd. Much of this redesign has already been done on the conceptual level, and we are slowly working towards the actual implementation. There are a couple of interesting issues to solve on the way. All this is going on without a guarantee that the final result will work better than the Hurd works now. Although we have the feature-component of it under control, nobody can predict if the performance and stability will improve and become competitive, or if it turns out that it won't. Nobdoy can tell because nobody attempted to implement a system like the Hurd before at this scale. The Hurd is one of the few innovative free software projects. While most other projects are more of the same in that they reimplement well known and proven concepts, the Hurd is walking on new grounds, with all the problems that this implies. And it is lacking some very experienced developers with lots of spare time and motivation. We won't attract such developers with GNU Mach, though, I can tell you that. Now, about the ivory tower comment. Actually, most people on the earth have stopped believing in a microkernel approach a long time ago. I think that the history of operating systems has as much to contribute to the history of the Hurd as other factors. However, if history is any judge, there is a good chance that the hype curve will bend the other way some time in the future. Hopefully we will then be able to profit from that. But that requires us to find answers to questions so we can offer them to interested parties at that time. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Fri, Aug 15, 2003 at 09:04:07PM -0500, asubedi wrote: = Original Message From Marco Gerards [EMAIL PROTECTED] = The kernel is developed by the L4KA project. Does it matter that it is written in C++ or isn't GPLed? (Ofcourse what matters is that it is free software). I had noticed that some of the L4 kernels were licensed commercially while I was browsing L4 website sometime ago. The concern of the choice of language being that I had read in some paper that g++ is not really fine tuned as compared to gcc (plus other GNU philosophies; sorry true GNU fanatic :). Pistachio is Free Software, although not under copyleft, but more like the revised BSD license. The documentation is unfortunately not freely licensed. It's written in a subset of C++, and the L4 people know exactly what features they can use without running into problems and which should be avoided. The external interface of L4, the ABI, is of course language independent and specified down to the assembler and bit level. There are convenience interfaces for various languages, too. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Advocacy?
On Fri, Aug 15, 2003 at 12:27:49PM -0700, Barry deFreese wrote: Not to be argumentative but then why does www.gnu.org say the following: *it exists* The Hurd is real software that works Right Now. It is not a research project or a proposal. You don't have to wait at all before you can start using and developing it. Wouldn't that imply to the user that it is usable, not necessarily alpha/beta? I'm not tryint to troll, start a flame, or downplay the Hurd. In fact, I would like to see the Hurd prosper as an alternative OS but I think it suffers from image problems. It all depends on your definition of various words, of course. But the point of this item on the web page is to make clear that the Hurd is not vapour ware in the sense that it's all talk and no code. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: HURD kernel change
On Fri, Aug 08, 2003 at 04:04:36PM -0400, [EMAIL PROTECTED] wrote: Is there really a plan to stablize GNUmach 2.0? Well, let's look at it this way. How long will it take to port the Hurd to L4? Probably a long time, with the current pace. However, there are several people working on it, and of course it would be good to have more. But note that helping with the port to L4 means that you have to become an expert on an issue and be able to work independently of others (also because not everything about the design is finished yet). Getting GNU Mach 2.0 to work reasonably well is probably not a lot of work (compared to the L4 port), if you are determined and know what you do. The set of problems is reasonably defined (mostly oskit integration in GNU Mach), and so it is a much smaller problem. Also there are people who at least theoretically could tell you what's the way to go (ie, what the design criteria are, and if a change is correct). However, nobody of the core developers is working on this, so you'd still have to work on your own. It's something that has the potential to give reasonable results in a short time frame. At least on the hardware I'm using now there are just too many hard to reproduce or just plain wacky bugs to try to fix them without being able to ask if others experience the problems too. Uhm, if you see bugs, then you can fix bugs! The problem is if you can't reproduce a bug :) If anyone is still interested in this, I'd like to get an idea of how stable 2.0 (1.9) is for you. Mine has never stayed up more than a couple of hours (at most and it was idle at that). It just seems to randomly reset and then the machine boots again. This is under remote debugging, without debugging it crashes during init server startup and resets. That's of course not so good. If it is not possible to stabilize it, it might be a dead end. In the end, you decide how you spend your time. If GNU Mach 2 can be made to work better than GNU Mach 1, certainly that would be a usability boost (I am thinking of random device, Wagi's serial device drivers, etc). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: [EMAIL PROTECTED]: Hurd CD images have disappeared.]
On Sat, Aug 09, 2003 at 01:37:43AM +1200, Philip Charles wrote: On Fri, 8 Aug 2003, Josip Rodin wrote: - Forwarded message from Apurva Mehta [EMAIL PROTECTED] - From: Apurva Mehta [EMAIL PROTECTED] Hi, I can't find Hurd-K4 cd images anywhere. Where have they gone? It seems that ftp.gnu.org has had a disaster (cracked?) and that the archive has not been rebuilt. It's under way though, and the files are still there. With known good md5sums, it will be easy to recover them. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: default CPU target for ix86 based ports
On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote: IIRC the Hurd can be built for i586 only, so it could be used as the default target CPU as well. We only require a coprocessor, but anything i586 doesn't make much sense at all at this stage. So no problem on our side. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: default CPU target for ix86 based ports
On Thu, Aug 07, 2003 at 01:13:18AM +0200, Matthias Klose wrote: Marcus Brinkmann writes: On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote: IIRC the Hurd can be built for i586 only, so it could be used as the default target CPU as well. We only require a coprocessor, but anything i586 doesn't make much sense at all at this stage. So no problem on our side. so make -mcpu=i586 -mtune=i686 the default? anything else as the default? I think that would be fine. I am not really savvy of what other options could be useful. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: MD5 passwords
On Wed, Aug 06, 2003 at 12:05:01AM +0200, Marco Gerards wrote: Why does Debian GNU/Hurd use DES encrypted passwords instead of MD5 encrypted passwords? I think that this is the default on Debian GNU/Linux as well, for legacy reasons. I have tested MD5 passwords on the Hurd (I've copied a /etc/shadow entry from my GNU/Linux installation to my /etc/shadow on Debian GNU/Hurd and logged in). This works. libshouldbeinlibc wasn't written to support this(I assume because of the crypt prototype there), but it supports it because of the way glibc works. I am not sure how you would set it up so that passwd etc store passwords in the MD5 format, though. I wonder if no-one knew it works (some people claimed it didn't works and because of that I had a look) or if it wasn't enabled because I'm stupid and don't understand debian. I think that nobody ever thought about it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a simple dmesg
On Fri, Aug 01, 2003 at 03:44:17PM +0100, Bob Ham wrote: dmesgd sits on /dev/klog and stores up its output. it also listens to an AF_UNIX socket, /tmp/dmesg-socket. dmesg clients connect to this and read the stored up klog output that the server sends them. How is that any better than syslogd? Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a simple dmesg
On Sun, Aug 03, 2003 at 02:36:52PM +0100, Bob Ham wrote: On Sun, 2003-08-03 at 09:17, Marcus Brinkmann wrote: On Fri, Aug 01, 2003 at 03:44:17PM +0100, Bob Ham wrote: dmesgd sits on /dev/klog and stores up its output. it also listens to an AF_UNIX socket, /tmp/dmesg-socket. dmesg clients connect to this and read the stored up klog output that the server sends them. How is that any better than syslogd? I don't know that it is. Think of it as a tiny syslogd just for klog messages if you want :) Ok. I just want to point out that syslog already is set up by default to read from /dev/klog on the Hurd (we don't have sysklogd), and that it has network facilities. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a simple dmesg
On Fri, Aug 01, 2003 at 05:32:26PM +, Robert Millan wrote: No, it's not hurdish, yes, it works around bugs, but does have these wicked features: It Works (tm) and It Exists (tm) :) Nice! could you add it into GNU sysutils? (at least temporarily) Definitely not. I can elaborate later why (in short: our klog is flushed by reading, and reserved for syslog, second, it works around bugs that must be fixed). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: K4
On Thu, Jul 24, 2003 at 03:24:37PM +, Robert Millan wrote: If it just was rejected because it was an horrid kludge but still it works fine, then we should apply it in Debian since this bug is breaking all packages that need semaphores to build or work at all. You could also remove pthreads from the Debian Hurd package. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: K4
On Thu, Jul 24, 2003 at 11:00:32AM -0700, Jeff Bailey wrote: As far as I know, NPTL doesn't have a hard requirement for Linux. The constructs that it doesn need (futexs, kernel threads, etc.) appear to be possible to support cleanly on L4. A futex will hardly be possible in L4, it will have to be replaced by the conventional wait queue for local locks and wait queues in the physical memory server (or some other server) for shared locks. However, this is still possible with NPTL. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: eth0: Via Rhine
On Tue, Jul 22, 2003 at 11:35:36AM +0200, Jochen wrote: $ MIG=/usr/bin/i386-gnu-mig CC=/usr/bin/i386-gnu-gcc ./configure add --build i386-linux --host i386-gnu here. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Package list
On Sat, Jul 19, 2003 at 07:07:20PM +0200, Jochen wrote: I thought of something like this from the debian web site http://packages.debian.org/unstable/ So, everyone can easily check, which packages are available (already ported) for the hurd system and which versions are up. So you can see, which packages can be installed and which ones need to be ported. Maybe try buildd.debian.org, and in particular the quinn-diff pages. quinn-diff used to be a bit buggy, don't know if that is fixed. My autobuiler turtle (on savannah.gnu.org) can do accurate web pages reporting on source and binary version. Maybe check it out, if you want (it's sorta discontinued and a bit slow, though). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian GNU/Hurd crossinstaller: crosshurd
On Fri, Jul 18, 2003 at 09:46:23PM +0200, Marco Gerards wrote: Jeff Bailey [EMAIL PROTECTED] writes: Another problem right now is the translator vs. tarring up /dev stuff. What are you going to do about this? With Marco's patch floating around, wouldn't it make sense to talk to the Debian tar maintainer (Bdale) while he's around? Or are we going to take a different road? Different path. It turns out that the only reason they don't use MAKEDEV is because it was slow. We don't have that issue so will just use MAKEDEV. I lost track of the thread for Marco's tar patch. I don't remember if we ever decided it was an attribute or a file type. (FYI:) It = passive translator I was trying to explain the star maintainer that passive translators are a filetype and not an attribute of a file. But he isn't convinced of this yet... That is because he is probably correct. Remember that you can set a passive translator on any node, an empty file, a file with content, or a directory, or whatever. On the other hand, it is not possible to set a translator to a symlink (I don't think you can stack passive translators, can you?) So, it might very well be that the right behaviour for tar would be to tar up the underlying file and its translator setting (as an attribute to the file). So far we only have ocnsidered empty nodes carrying passive translators. What matter more to me is having this patch (or a reworked version) in GNU tar. This cannot be done in a POSIX compatible way without doing a _LOT_ of GNU tar work. Jeff, what would be the best way to get this in GNU tar? (Or at least to get some comments about this?). For GNU tar, having a patch that just saves the translator setting (not the underlying file) would be a good first thing to have. However, saving the underlying file should also be consdered as an option, because some translators might require it in the future. POSIX compatibility is not a requirement for GNU tra today (as GNU tar is already not POSIX compatible). What would be more interesting is translator support in Linux ext2fs (to the extend of being able to read and write passive translator settings), so you could unpack such a tar file under GNU/Linux on a Hurd partition. Thanks, Marcus
Re: Debian GNU/Hurd crossinstaller: crosshurd
On Thu, Jul 17, 2003 at 06:34:31PM +, Robert Millan wrote: On Thu, Jul 17, 2003 at 04:22:57AM -0700, Jeff Bailey wrote: I will do up a new Hurd package by the end of debcamp/debconf which has some libdiskfs fixes and such. Some brave soul could take on 44039. It looks about medium difficulty. If you provide a fix for that, please send it to the bug address, not upstream. I will take care of getting it in upstream. AFAIK, the bug that breaks coreutils is #190581, which is not exactly the same as #44039. To quote myself: Glibc maintainers: bug #44039 is not exactly the same as #190581, so i'm not merging. i'd say that #44039 is a multibug that contains a patch which fixes #190581, but doesn't fix all the bugs in #44039 Have you tried to find out why nice(-1) doesn't work? If it is anything but what is described in the last two mails on 44039, then I would like to know about it. Otherwise, 44039 is what has to be addressed, and 190581 will just be fixed as well then. Thanks, Marcus
Re: mouse device
On Wed, Jul 09, 2003 at 08:17:13AM +0200, Johannes Rohr wrote: Marcus Brinkmann [EMAIL PROTECTED] writes: On Sat, Jul 05, 2003 at 12:43:50AM +0200, Robert Millan wrote: btw, you upstream CVS people could please commit the mouse/kbd patch from the debian hurd_*.diff.gz? No, it's just a horrid hack. Then, why is it there at all? X doesn't really need it. It works fine with its own drivers. I don't think so. It used to be quite sluggish to use X's drivers. Can you confirm that performance is the same, and that all types supported by the mouse device are supported by X's drivers? PS/2? Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: mouse device
On Sat, Jul 05, 2003 at 12:43:50AM +0200, Robert Millan wrote: btw, you upstream CVS people could please commit the mouse/kbd patch from the debian hurd_*.diff.gz? No, it's just a horrid hack. Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: compiler/linker isssues
On Mon, Jun 30, 2003 at 12:29:48PM +0200, Robert Millan wrote: I've been busy lately, and couldn't dedicate much time for fixing this. Do you want me to provide a build tree of libgcrypt for GNU? The first thing to provide would be a proper log that shows the problem. The config files and all the usual information included of course. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: why was um-pppd removed?
On Wed, Jun 25, 2003 at 10:27:42PM +0200, Gergely Nagy wrote: Great. Last time I checked, it was around ~4800 bps, which is just a wee-bit better than not working at all. Far from that. It means that the package works fine, and only the serial driver needs fixing. In this case, you'll just have to reintroduce um-pppd and have fun. If that would be easier for Debian, I would agree. However, removing and adding packages are expensive for Debian, as they require manual work. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: compiler/linker isssues
On Wed, May 28, 2003 at 04:39:42PM +0200, Robert Millan wrote: On Tue, May 27, 2003 at 05:22:31PM +0200, Marcus Brinkmann wrote: A complete build log. If possible, the whole build three somewhere, that allows me to look at the actual object files. Then you need to repeat the gcc/link command that fails with -v, so we see the whole command. The version of gcc/g++/... (which Debian package) you are using is also important. see http://people.debian.org/~rmh/gtkgl2/ Ok. Yeah, this is what I meant with something being wrong with the X libraries. On my system, libGLU is linked against libstdc++: ulysses:~# objdump -p /usr/X11R6/lib/libGLU.so.1 |grep NEEDED NEEDED libstdc++-libc6.2-2.so.3 NEEDED libm.so.6 NEEDED libc.so.6 And if that dependency is there, usually things will work fine if you link against libGLU even if you do not link against its dependencies. So, even though the whole thing smells like rotten fish, as long as we do the same as GNU/Linux and have the NEEDED entry in libGLU, things should work just fine. However, this is still bogus, because the requirement is that you have to link with each library that is required, and in the right order, and you are not formally allowed to leave out a dependency of another library on the link line. This is particularly important if you want to link statically. If you link statically, the sharedl ibs dependency information is absent, and the linking will fail. This is the reason why projects with many library dependencies invented the -config scripts, so programs know what to link against: ulysses:~# pkg-config --libs gtk+ -L/usr/X11R6/lib -lgtk -lgdk -lXi -lXext -lX11 -lm -lglib Try this out, you can build programs against -lgtk without adding all libraries above, but not if you do it statically, and it is not formally correct. You are expected to list them all. Now, to libGLU. I don't remember if libGLU was a C++ library that had a C interface, or the other way round. In any way, they are doing somethig pretty strange. Formally, your bug reports have been correct, because you are required to list all dependencies. However, it might be the simplest thing to just make sure that libGLU has the inter-library dependency to libstdc++ and that this will make things work automagically for all situations in that it works on GNU/Linux, and leave these people with their errors. I think this only leaves us with libgcrypt. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Must NOT link with pthread
On Tue, May 27, 2003 at 10:59:50AM +0200, Robert Millan wrote: my apologises, Marcus. i'll follow your suggestion next time. It never hurts to ask if you see something unusual. Any unexplained difference between GNU/Linux and GNU/Hurd is by definition unusual :). it seems we do actualy have a system bug, maybe in ld or in our dynamic linker (GNU/Linux uses a different one, right?). whereever it is, this bug is reproduced in the following places (i've hit all them): We certainly have bugs. However, we are using the very same linker. So if indeed something is errorneous with the linker, then we have a problem. However, libsdc++ and problems with weak symbols rather indicate a compiler problem, than a linker problem. Of course it is not possible to guess what happens. xfree86: see http://people.debian.org/~rmh/xfree86/glxinfo-makefile.diff (applied) xft2: bug #185536 gtkgl2: bug #186760 libgcrypt: bug #187309 [...] (and more i forgot and are already fixed) I think that 185536 (xft2) might be a genuine bug (although I can not check without the X sources), while the others probably are not. g++ should always add libstdc++ automatically for C++ programs. Marcus, i'm unable to debug this. please could you have it a look and try to find out the problem? I will follow up. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Micro$oft to licence UNIX from SCO
On Wed, May 21, 2003 at 04:24:29PM +0200, Robert Millan wrote: On Tue, May 20, 2003 at 12:23:56PM +0100, Ashish Gokhale wrote: Hi All, There is a recent news that Microsoft is trying to licence Unix technology from SCO. http://news.com.com/2100-1016-1007528.html?part=dtxtag=ntop In flow of current discussion regarding TCPA/palladium and open source in genral, how much impact does this will have on GNU/Linux GNU/HURD community ? I'm particularly interested by this kind of political discussions, but this is realy off-topic here. debian-hurd is for porting and development of the Debian GNU/Hurd distribution. maybe move to help-hurd? Is that like help-god! ? ;) Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: x-window-system
On Tue, May 20, 2003 at 11:15:13AM +0200, Johannes Rohr wrote: But it is still lacking stability. I have experienced several freezes of the console server. (I could still telnet to my box.) Another annoyance is that, once you have run 'console -d vga -d pc_kbd -d generic_speaker /dev/vcs', you cannot exit console without rebooting. Just killing the program freezes the screen. I assure that this is not behaviour I see when using it. So there are two possibilities. Either you found a bug or two in the console code. Then I would appreciate more information on these. Or you have other problems in your system. Then more information is needed as well. I don't use the Hurd frequently these days, but I had never the console freeze. So what are you doing that I didn't? If you could telnet to your box, what was the state of the processes? What did gdb attached to the processes involved tell you? I don't know what killing the program means. If you mean kill then yes, this will leave your screen in a desolate state until we catch SIGTERM with marcos patch. However, if you press CTRL+ALT+Backspace, the console client should terminate itself and correctly clean up behind itself. Unless we need Marcos patch to get the right thread killing the console. It did work for me in the past, though. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Micro$oft to licence UNIX from SCO
On Tue, May 20, 2003 at 12:23:56PM +0100, Ashish Gokhale wrote: Hi All, There is a recent news that Microsoft is trying to licence Unix technology from SCO. http://news.com.com/2100-1016-1007528.html?part=dtxtag=ntop In flow of current discussion regarding TCPA/palladium and open source in genral, how much impact does this will have on GNU/Linux GNU/HURD community ? If anything than SCO's lawsuit proves that RMS has always been right with insisting on copyright assignments and being careful about copyright history of the source code you write. The sloppiness of Linux and other Open Source developers in not caring about copyright issues properly now backfires to them. The FSF did repeatedly educate everyone on what is required, but their advise has been largely ignored in certain circles. The copyright of the Hurd and other GNU sources is fully accounted for, though. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Bug #103204/dpkg-shlibdeps and /X11R6/lib
On Tue, May 20, 2003 at 02:06:15AM +0200, Michael Banck wrote: Anyway, I've heard the next glibc version (2.3.2) will fix this problem, so it's not much to worry about at the moment. It won't fix it. It just sweeps it under the carpet. This is a decision that Jeff made for Debian GNU/Hurd (as opposed to something we want to become the official fix for this issue as far as the GNU/Hurd is concerned). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Bug #103204/dpkg-shlibdeps and /X11R6/lib
On Tue, May 20, 2003 at 02:38:09AM +0200, Marcus Brinkmann wrote: On Tue, May 20, 2003 at 02:06:15AM +0200, Michael Banck wrote: Anyway, I've heard the next glibc version (2.3.2) will fix this problem, so it's not much to worry about at the moment. It won't fix it. It just sweeps it under the carpet. This is a decision that Jeff made for Debian GNU/Hurd (as opposed to something we want to become the official fix for this issue as far as the GNU/Hurd is concerned). Oh, and I think it will only work if you use a real /usr instead of a symlink. The changed glibc makes that a possible configuration. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Bug #103204/dpkg-shlibdeps and /X11R6/lib
On Tue, May 20, 2003 at 03:05:32AM +0200, Michael Banck wrote: On Tue, May 20, 2003 at 02:40:45AM +0200, Marcus Brinkmann wrote: Oh, and I think it will only work if you use a real /usr instead of a symlink. The changed glibc makes that a possible configuration. True. But the dpkg-dev rewrite in python works OK, and as doogie said he wants to fix it himself... Let's say there are more serious issues than dpkg-shlibdep[0], priority-wise. Does that sound alright? This is not a matter of priority but of policy. But I don't argue. For Debian GNU/Hurd, Jeff made a reasonable decision, and I support him. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Hurd Installation (panic)
On Thu, May 08, 2003 at 12:39:39PM +0200, M. Gerards wrote: Isn't 0.3 official? Isn't this a good reason to release? IMHO there should be released because it looks to many people the hurd isn't developed anymore. And having grub corrected is a good thing to have. Noone uses 0.2 anymore. How about that: We make a release and write your name on it. :P Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: How to debug translators?
On Wed, May 07, 2003 at 02:31:04PM +0200, Johannes Rohr wrote: That's nice. BTW: I've downloaded the CVS source tarball from alpha.gnu.org. I see that the mouse translator is missing. Has it been removed on purpose? The mouse translator is not part of the official source code. It's in the Debian package only. Besides that, reading through the changelogs I get the impression that no active development has taken place for over half a year or so (since the upload of hurd-20021118-1 to Debian). Is my assumptiom correct (no flame intended, I'm just curious.) That's basically correct, as far as the official Hurd source is concerned. (Although I wonder what inactive development is :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Again, seeking advocate
On Fri, Apr 04, 2003 at 01:49:09AM -0500, B. Douglas Hilton wrote: Most of you probably don't remember, but I gave a good try to hack SMP support for OSKit/Mach over the last couple years. Although I can't remember every piece of hardware of you, I remember you pretty well :) I still have full serial remote debugging capabilities via my Netwinder which I cross-compiled gdb for Hurd. I think that I'm Debian material, and I would be honored if a Hurd developer sponsored me. I have not yet applied for New Maintaier because I lack a sponsor. The easiest thing to do is to mail me a link to the website where I need to advocate you. Then you will enter the normal new maintainer process. I was at DebConf2 in Toronto last year, and spent about $1000USD to go there just to get my key signed. I'm a patient dude, but I want to get in before I die please. :-) Frankly, it totally escapes me what is required to become a Debian maintainer, but usually it happens within a couple of years, as far as I know (sometimes even months!). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian-Gentoo collaboration on GNU/Hurd ports
On Thu, Mar 27, 2003 at 04:53:57PM -0800, Jeff Bailey wrote: On Fri, Mar 28, 2003 at 12:18:35AM +0100, Marcus Brinkmann wrote: we could get a list for that an generic porting discussion. where should i ask for a new list of the Hurd project? I am happy to have such a list for discussing that topic. I just don't know if the savannah interface for mailing lists in that regard is fully automatic. Jeff, do you know how this is done? The savannah interface works lovely. If you have troubles, /msg me. (I don't think I'm a project admin for the Hurd) I thought that it was different for older GNU projects that moved into savannah. Might be obsolete factoid on my side. Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian-Gentoo collaboration on GNU/Hurd ports
On Thu, Mar 27, 2003 at 01:33:31PM +0100, Robert Millan wrote: fine! i still like having a separate list of api-porting-related bugs in debian BTS, but as Marcus said Savannah is the canonical place. I hope you aer talking about bugs in the Hurd and GNU Mach (and MiG, and whatever other components we come up with). - the Glibc savannah site [1] doesn't have an entry for bugs. what do the libc people here (Roland? :)) think about creating one? This depends. If it is a genuine bug in the latest CVS (and are prepared to deal with any responses from the hackers), you can try libc-alpha. Otherwise you should use the Debian BTS. - again, what about using a tag to identify apt-porting-related bugs in savannah? tags for bug reports will be created when I (or some other hacker) feel the need for it. How and which tags are created follows an undocumented pattern that only exists in my head (and even there only vaguely). So just start filing reports, and then we can see. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian-Gentoo collaboration on GNU/Hurd ports
On Thu, Mar 27, 2003 at 11:46:25PM +0100, Robert Millan wrote: tags for bug reports will be created when I (or some other hacker) feel the need for it. How and which tags are created follows an undocumented pattern that only exists in my head (and even there only vaguely). I just meant putting an agreed string in the bug description heard, like [porting] or the like. Well, you can do that, but the bug tracking system in savannah supports rich set of features for classifying bug reports. Any information that helps in grouping reports is of course welcome. Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: Debian-Gentoo collaboration on GNU/Hurd ports
On Thu, Mar 27, 2003 at 11:55:32PM +0100, Robert Millan wrote: we could get a list for that an generic porting discussion. where should i ask for a new list of the Hurd project? I am happy to have such a list for discussing that topic. I just don't know if the savannah interface for mailing lists in that regard is fully automatic. Jeff, do you know how this is done? The problem is that Debian bugs should never really go upstream. Debian's glibc is heavily modified to deal with the fact that we have ports that upstream doesn't actively care about (sh and hppa). Some of those changes involve some fairly invasive hacks. Certainly in the case of glibc, you risk facing the Wrath Of Drepper (sort of like the Wrath of Kahn, except that drepper always wins *g*) I see.. then maybe it's not a good idea to share porting-related libc bugs with Gentoo. Well, otoh, the Hurd port of glibc is not modified in the Debian version IIRC (at least not the Hurd specific parts of it). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
