Re: Debian GNU/(k)NetBSD and sparc32 hardware?
Hi, BERTRAND Joël [EMAIL PROTECTED] writes: Maybe, but NetBSD kernel does not correctly work on sun4m/SMP, like Linux. Today, no one OS can be used on sun4m/SMP workstations, and I think that it will be easier to fix linux 2.6 sparc32 kernel than work on debian/xBSD sparc32 port. I had reports stating the contrary, as far as HyperSPARC SMP is concerned (which seems like the less-likely-to-work configuration): http://article.gmane.org/gmane.os.netbsd.ports.sparc/6945 http://article.gmane.org/gmane.os.netbsd.ports.sparc/6943 OTOH, there were mixed reports related to SMP with other processors: http://article.gmane.org/gmane.os.netbsd.ports.sparc/6931 http://article.gmane.org/gmane.os.netbsd.ports.sparc/6914 Thanks, Ludovic.
Re: Debian GNU/(k)NetBSD and sparc32 hardware?
Hi, Ulrich Teichert [EMAIL PROTECTED] writes: That's not quite true. Dave Miller is still collecting patches, Mark Fortescue, Krzysztof Helt and others are producing them. See the respective posts on [EMAIL PROTECTED] It's just that there is no real maintainer for the port. [...] Call me a chicken, but I still think it will be less work to just fix the issues in the kernel and use the existing stuff instead. That's the whole issue. I am under the impression (perhaps wrongfully) that Linux development is moving at a high pace, not considering support of legacy hardware as a high priority. For instance, the first 2.6 releases introduced significant regressions wrt. SPARC32 support compared to 2.4. Only now is 2.6 starting to catch up with 2.4, thanks to the work of a few people. Conversely, it seems that NetBSD values continued support more, judging from the mailing list archives of various ports (including, e.g., the still active VAX port!). It's probably following a much more conservative development approach, less biased towards newer hardware. I agree that a new debian architecture would be more fun, but splitting up the remaining debian sparc32 developers between NetBSD and Linux does not sound too healthy for me. Agreed. In the short term, it does seem easier to try and fix Linux' SPARC32 support. However, I'm wondering whether that would be a good long-term investment. Now, similar issues may also arise with other architectures, too. Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/(k)NetBSD and sparc32 hardware?
Hi, Ulrich Teichert [EMAIL PROTECTED] writes: What we've seen here is classic bitrot, IMHO. Of course, the main Linux development platform is x86 and quite a lot kernel developers only work on one platform. This has introduced bugs for all other ports (and will continue to do so), which I can understand. Just look at the amount of patches between 2.6.21 and 2.6.22. Sure, a huge amount of work is being done in between versions, but that new stable releases introduce such significant regressions strikes me as a questionable release policy. Of course, developing an OS kernel is a hard task, especially when so many architectures have to be supported, but still. Anyway, I just discovered the Linux Test Project: http://ltp.sourceforge.net/ I guess we, users of those non economically valuable architectures, should commit to run LTP every once in a while on latest kernels and report any problems. That might be an improvement given that kernel developers do not seem to run it. I'm not following NetBSD so closely, so please correct me when something I write isn't true, but I am under the impression that NetBSD has not got that much devoted kernel hackers as Linux. As a result, the process of bitrotting is slower with NetBSD. But NetBSD has a totally different approach to ports as Linux, just because the motives behind NetBSD are different. And maybe these reasons will suite [EMAIL PROTECTED] better, I don't know. Disclaimer: I'm not familiar with NetBSD either, I've never used it actually. I just quickly browsed the web site and mailing list archives, which gave me the impression that when they claim that platform X is supported, it is indeed supported. Nevertheless, you might be right in that bitrotting is just slower on NetBSD than on Linux, it's hard to tell. Thanks, Ludovic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tomcat6
Hello, Anton Andreev antonandr...@fmi.uni-sofia.bg writes: Is tomcat available on Debian / kfreeBSD? Apparently yes: http://packages.debian.org/sid/tomcat6 . BTW, the proper name is Debian GNU/kFreeBSD. Thanks, Ludo'. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: kFreeBSD progress report week 8
Hi, Luca Favatella slacky...@gmail.com writes: [...] on the deb package, there is a different script for GNU/kFreeBSD and GNU/Linux, but the GNU/kFreeBSD version needs ifconfig and route. I considered porting and switching to BusyBox udhcpc. (I haven't studied the question in depth, so pardon me if this remark is off.) Did you consider using GNU Inetutils as a (hopefully) portable network tool set for all the GNU/* variants? Thanks, Ludo'. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: kFreeBSD progress report week 8
Luca Favatella slacky...@gmail.com writes: It seems it is not enough. It has only ifconfig http://packages.debian.org/sid/kfreebsd-i386/inetutils-tools/filelist Hmm, actually it has more than this, but it seems to lack `route', for instance: http://git.savannah.gnu.org/cgit/inetutils.git/tree/ Thanks, Ludo'. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ZFS on kFreeBSD
Hello, Petr Salinger petr.salin...@seznam.cz writes: Fou our specifics, take a look at our SVN repository http://svn.debian.org/wsvn/glibc-bsd/trunk/, namely freebsd-libs, freebsd-util. Start with target get-orig-source in debian/rules. Out of curiosity, is there any plan to get the kFreeBSD port into upstream (E)Glibc? Thanks, Ludo’. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Detecting kfreebsd kernel while compiling
Hi, Cyril Brulebois k...@debian.org writes: There's __FreeBSD__ for plain FreeBSD, and __FreeBSD_kernel__ for GNU/kFreeBSD (which doesn't define the former, so that people can distinguish). And ‘__GLIBC__’, which is what most applications really want to know. Thanks, Ludo’. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Detecting kfreebsd kernel while compiling [hurd]
Hi, Joachim Wiedorn ad_deb...@joonet.de writes: But I don't now how can I specify a GNU/Hurd (with mach-Kernel) system (hurd-i386), which is still an unofficial port of Debian. I have only tried 'defined (__hurd__)' which does not work. I think if I say 'defined (__GNU__)' this is always the same an ALL Debian systems because Debian alsways use GNU-OS. ‘__GNU__’ is only defined on GNU/Hurd, whereas ‘__GLIBC__’ is defined on all GNU variants. Thanks, Ludo’. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: porting userland ppp to kfreebsd
Hi, The Anarcat anar...@koumbit.org writes: +#if defined(__linux__) || defined(__GNU__) || defined(__GLIBC__) Only the last one makes sense: ‘__linux__’ is for the Linux kernel and ‘__GNU__’ is for GNU (aka. GNU/Hurd). Thanks, Ludo’. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ociisdg6@gnu.org
