Re: Progress report: Multilingual sysinstall for -current
At Wed, 6 Dec 2000 18:18:50 -0600, Michael C . Wu [EMAIL PROTECTED] wrote: Do you have Alpha boot floppies? Does kons25/big5con/korean compile on Alpha? Would this fit on our ever growing mfsroot.flp and kern.flp? I don't have alpha machine and my knowledge about Alpha architecture is very limited. But kons25 currently can't be compiled on Alpha machine, and is disabled if ARCH==alpha (perhaps release/localization/kon2 should be release/localization/i386/kon2). I recall seeing the release engineers struggling with fitting the kernel. I have committed to move *.ko modules to mfsroot.flp (and I think it's easily extended to the third floppy or CD-ROM) last month. This is not enabled on Alpha currently, but I think it can be also used on alpha architecture. I've not put it to alpha floppy only because I dont have alpha testbed. If you copy release/i386/drivers.conf to release/alpha and edit it to fit the alpha architecture, drivers will be moved to mfsroot.flp easily. It would be hard to make OpenBOOT and SRM do what we do in kons25. (Doable, but someone has to do it.) I also know that Alpha SRM+vidcontrol+sc0 can only have one video mode, 80x25. Can Mr. Yokota clarify this for me? Does vidcontrol on Alpha support loadable font option? Russian support uses only this function and does not use graphics console. Other European languages can be supported in this way. hosokawa -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Progress report: Multilingual sysinstall for -current
Hi! I've ported Multilingual sysinstall to -current. I put the latest source and binaries (Japanese/Englush only) is at http://people.freebsd.org/~hosokawa/boot-ja/5.0-CURRENT/release-20001206-1/ (please note that non-English docuemnt files are based on 4.2-RELEASE) Currently, this implementation supports Japanese, Korean, Traditional Chinese, and Russian. The status of translation work is: Japanese: finished Korean: finished Traditional Chinese:about to finish Russian:only *.hlp files have been translated This code has some minor problems, but it works. I think it's better to change the development of this project to open style. I would like to import this code to -current CVS repositry soon if there's no objections. FYI: for 4.2-RELEASE, http://people.freebsd.org/~hosokawa/boot-ja/4.2-RELEASE/release-20001205-1/ contains source, and binaries for all supported languages. -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Progress report: Multilingual sysinstall for -current
At Wed, 06 Dec 2000 20:25:30 +0900, Kazutaka YOKOTA [EMAIL PROTECTED] wrote: As we wait for libh development, I do not think we should exert efforts to try for another solution. This tends to allow for slack in further development of better products. A good example would be a proposal by Alfred Pernstein to slightly modify RELENG_4 SMP for the duration of SMPNG development. The proposal was not well accepted due to the reason I stated above. We really should concentrate on libh as a complete and _clean_ solution. Sure, libh is a better solution. But, don't you think it's still good to have something working until it will become available. Multilingual sysinstall project started when FreeBSD is 2.0.5, and maintained in PAO-like style, but it's very larger patch than PAO (especially, it replaces almost all messages in release/sysinstall/menus.c) and it makes that "keeping current" work very difficult. Almost all code of this project is written when FreeBSD is 2.x, and it's in "maintainance-only" phase for years. If it's on -current tree, our work can be easier, and many developpers other than us also can do this work. If this makes us the spare time, perhaps we can help libh work. I don't think sysinstall is better solution, but it's available now. I'll glad to cvs delete this code entirely, if we can use better solution. In addition, the purpose of putting localized sysinstall in -CURRENT is rather dubious. -CURRENT/HEAD is a developers' branch, people who use this branch should be able to read English and the system error messages. If they cannot install the system with English sysinstall, I would have doubts on their programming and testing ability. People who run -CURRENT should be able to read and write English to understand the code comments, report bugs, and post to the lists in English. I think you are missing the point here. As you point out, the -current is for developers; it's for development and for testing. I don't think Tatsumi wants -current users to use I18N sysinstall to install -current, but, rather wants them to have a look at the code and test it. My main target is RELENG_4 and I hope this won't live until 5.x-RELEASE. It's in -current for only testing purpose. I would have no objections to L10N'ized sysinstall being maintained in the same way that PAO is maintained. The boot floppies and iso images can be put up somewhere for download, and maintained in RELENG_4. Why should it be in RELENG_4? If it's maintained in -current and regularly MFCed to RELENG_4, it is exposed to wide audience of -current developers and -stable users. That will attract more comments and bug reports, and will also minimize the delay between regular releases of FreeBSD and I18N/L10N sysinstall for them; the delay normally associated with L10N sysinstall (and PAO) after regular FreeBSD releases. And the delay has been prolonged sometimes because only a few developper was busy :-). Normally, I would welcome any I18N/L10N efforts in FreeBSD. However, the FreeBSD Project's official position paraphrased is "If you don't know what to do with -CURRENT, don't install it." See my comments above. Combined with the point that we should not divert efforts from libh, I hold the opinion that we should not import this. I don't think importing multilingual sysinstall will detract effort from libh. You see, even if it is maintained separately from the -current, it has its own maintainers and developers. I expect they are the same people who will maintain and develop I18N sysinstall when it is imported to the -current. They may or may not be libh developers at the same time. But, I don't think I18N sysinstall is suddenly needing a large army of developers and will steal them from the libh developer base. Yes. Programmers are needed when some change in source tree break this code and we can find it easier if it's in -current tree. Otherwise, only translators are needed for maintainance of *.TXT, *.hlp, and catalog files. Finally, still many thanks and applause to Tatsumi and others for this work. The same from me to them too. Thank you ! hosokawa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Driver Floppy implementation (Re: make release breakage - dokern.sh patch 2)
At Fri, 03 Nov 2000 12:05:46 +0900, Makoto MATSUSHITA [EMAIL PROTECTED] wrote: BTW, I've not received your email; are you busy working? Last night, I tested "make release" on my machine, and failed twice because of unloaded vn driver (this causes last trouble). It successfly finished this morning. I'm Sorry. I wanted to test it on my machine with Celeron 300MHz. hosokawa Maybe it's current.jp.freebsd.org's problem I don't think so. It's a mismatch that all object files are created under /usr/src/modules but make install assumes that these are under (maybe) /usr/obj. Maybe it's a fault of some Makefiles (sorry I dunno who change the policy of module compilation directories, did you?). I've done "cd /usr/src/modules; make clean" under -current buildtree to remove them. You say that I should always run "make clean" under all source code directory since somebody causes a mistake to use /usr/src for object? Maybe it's O.K., but before I'm doing, the committer who breaks the policy should be blamed :-) I understood the situation. I'll look into the Makefile's under src/sys. -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Driver Floppy implementation (Re: make release breakage - dokern.sh patch 2)
My driver-floppy patch broke "make release" on current.jp.freebsd.org (ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i3865.0-CURRENT-20001101-JPSNAP.log). Of course "make boot.flp" works very well on my enviroment. I'm debugging this problem, but it'll take hours and hours because testing "make release" takes about 8 hours on my machine. Anyway, I'll fix this bug as soon as possible. -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Driver Floppy implementation (Re: make release breakage - dokern.sh patch 2)
At Thu, 02 Nov 2000 10:34:03 +0900, Tatsumi Hosokawa [EMAIL PROTECTED] wrote: My driver-floppy patch broke "make release" on current.jp.freebsd.org (ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i3865.0-CURRENT-20001101-JPSNAP.log). Of course "make boot.flp" works very well on my enviroment. I'm debugging this problem, but it'll take hours and hours because testing "make release" takes about 8 hours on my machine. Anyway, I'll fix this bug as soon as possible. Hmm. Binaries on current.freebsd.org seems to be successfuly compiled. I'm not guilty :-). % gzip kern-20001028.flp kern-20001101.flp (got from current.freebsd.org) % ls -l kern-20001* -rw-r--r-- 1 hosokawa hosokawa 1330551 11/ 2 13:53 kern-20001028.flp.gz -rw-r--r-- 1 hosokawa hosokawa 1245853 11/ 2 13:50 kern-20001101.flp.gz Maybe it's current.jp.freebsd.org's problem and I'll talk with the administrator of this host. -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Driver Floppy implementation (Re: make release breakage - dokern.sh patch 2)
Hi! In "make release breakage" discussion, I said that I'll write a patch to load kernel module from sysinstall to get more free space in the first floppy. This is my implementation. I'll commit this patch to -current if there's no objection. I moved PCI/PCCARD/USB if_xx.ko driver to mfsroot.flp, and I've got 100KB of free blocks in the first floppy. If we move more drivers to mfsroot.flp or coming drivers.flp, we can get not only free blocks in the first floppy, but also more installation devices. I've put the patche and the binary images of *.flp at, http://people.freebsd.org/~hosokawa/driver-floppy/ I've tested these floppies on my machine with Intel PRO/100+ fxp network card. Sysinstall loads if_fxp.ko from mfsroot.flp, and listed it as network installation media (Alt-F2 shows debug messages). -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release breakage - dokern.sh patch 2
At Wed, 25 Oct 2000 04:48:14 +0900, Motomichi Matsuzaki [EMAIL PROTECTED] wrote: I vote for 'remove NFS away'. How about mergeing ifconfig kldload function into sysinstall, and move /boot/kernel/if_xxx.ko into mfsroot.gz mfs image. hosokawa -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release breakage - dokern.sh patch 2
At Wed, 25 Oct 2000 19:37:42 +0900,
Tatsumi Hosokawa [EMAIL PROTECTED] wrote:
How about mergeing ifconfig kldload function into sysinstall, and move
/boot/kernel/if_xxx.ko into mfsroot.gz mfs image.
or simply add,
main()
{
+ for ( i in /kernel/*.ko ) {
+ kdload(i);
+ }
How about it? If it's acceptable, I'll try to write this patch this
weekend.
--
Tatsumi Hosokawa
[EMAIL PROTECTED]
http://www.sm.rim.or.jp/~hosokawa/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make release breakage - dokern.sh patch 2
At Wed, 25 Oct 2000 21:23:01 +0900, [EMAIL PROTECTED] wrote: From: "David O'Brien" [EMAIL PROTECTED] Date: Tue, 24 Oct 2000 13:15:26 -0700 Before removing NFS, I'd remove the new `ncv', `nsp', and `stg' drivers. Please do not remove them. Many people are waiting for them to switch from 3.x with PAO3 or even with 2.x with PAO to more recent FreeBSD. If sysinstall with kldload works, we don't have to remove no driver and no protocols from boot.flp. I'll work on it this weekend. -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
At Sat, 14 Oct 2000 13:57:07 -0700 (PDT), Matthew Jacob [EMAIL PROTECTED] wrote: I had asked for a 3rd floppy earlier that we could put f/w images and other drivers on. Now that we have a mostly loadable system, it strikes me that this would be an excellent time to trim down the GENERIC to the common denominator per-platform and then have compressed driver images available on a 3rd floppy if people need them. It's a nice idea, but this means that boot.flp can exceed 2.88MB limit. As far as I know, the maximum size of boot image of El-Torito bootable CD-ROM is 2.88MB. When I install from CD-ROM, I have to enable ATAPI or SCSI drivers first, and then load Network dirvers and so on. When I install from the net, I have to enable Ethernet, PLIP or PPP drivers first, and then load ATAPI or SCSI drivers and so on. Currently, sysinstall supports two types of install media: local media and remote media. Boot.flp should be capable of loading drivers from the install media. Local media installation: Disk1-1: kernel, atapi + scsi drivers Disk2: sysinstall and utilities Disk3: driver disk Remote media installation: Disk1-2: kernel, network drivers Disk2: sysinstall and utilities Disk3: driver disk I think that disk 2 and 3 can be shared by them. Sysinstall have to ask user about installation media first, and then get compressed *.ko modules from the installation media. P.S.: Japanese/Korean boot.flp for 4.1.1 will be available in a few days (test version is available at http://people.freebsd.org/~hosokawa/boot-ja/), and I believe that it can be ported to -current easily, but it needs pty support in the Disk1 currently -- --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DHCP client problem?
At Fri, 21 Jul 2000 17:22:15 -0700 (PDT), Nick Sayer [EMAIL PROTECTED] wrote: Something changed very recently in the dhcp client stuff that seems to have broke my -current machine's ability to be a dhcp client. The symptom is that I see ifconfig: netmask 255.255.255.224: bad value come out of the script invocation, and the ip address does not get set. My -current machine (cvsupped only a few hours ago) has the same problem. If I echo out the parameters and type in THE EXACT SAME command line myself, it works just fine. I suspect some sort of bizarre quoting conspiracy. :-) Maybe here? (in http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/isc-dhcp/client/scripts/freebsd.diff?r1=1.11r2=1.12) - if [ x$old_ip_address = x ] || [ x$old_ip_address != x$new_ip_address ] || \ - [ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then -ifconfig $interface inet $new_ip_address $new_netmask_arg \ - $new_broadcast_arg $medium + if [ "x$old_ip_address" = "x" ] || [ "x$old_ip_address" != "x$new_ip_address" ] || \ + [ "x$reason" = "xBOUND" ] || [ "x$reason" = "xREBOOT" ]; then +ifconfig "$interface" inet "$new_ip_address" "$new_netmask_arg" \ + "$new_broadcast_arg" "$medium" --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccardd and modules
At Mon, 12 Jun 2000 07:53:02 -0700 (PDT), Pete Carah [EMAIL PROTECTED] wrote: I notice that though ifconfig does a kld as appropriate, pccardd doesn't at least as of a week ago. Still looks like it isn't in the source. 1. Is this in the works from one of the normal maintainers? If not I might take a look at fixing it up over the next week or so. Currently I'm not working on this. (I'm now working on multilingual support for -current sysinstall) ...Hmm? Does sysinstall have to have the same function :-) ??? -- --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[20000307-SNAP] /etc/make.conf USA_RESIDENT and international crypto distribution
Hi.
I'm testing 2307-SNAP and I found that USA_RESIDENT is set to YES
even if I installed from CD-ROMs with crypto distribution compiled
from international crypto sources.
How about adding something like following patch to sysinstall?
(this patch has not tested yet)
Index: dist.c
===
RCS file: /home/ncvs/src/release/sysinstall/dist.c,v
retrieving revision 1.174
diff -u -r1.174 dist.c
--- dist.c 2000/03/08 14:54:19 1.174
+++ dist.c 2000/03/11 20:49:57
@@ -393,14 +393,22 @@
"DES-based passwords on other Unix systems. There will also be
some\n"
"differences in the type of RSA code you use.\n\n"
"Please do NOT choose Yes at this point if you are outside the\n"
- "United States and Canada and are installing from a U.S. FTP
server.\n"
+ "United States and Canada and are installing from a U.S. FTP
+server\n"
+ "or CDROM with international crypto distribution.\n"
"Instead, install everything but the crypto bits from the U.S.
site\n"
"and then switch to an international FTP server to install crypto
on\n"
"a second pass with the Custom Installation option.")) {
if (!dmenuOpenSimple(MenuCRYPTODistributions, FALSE))
i = DITEM_FAILURE;
- else
- USAResident = TRUE;
+ else {
+ if (!msgYesNo("Are you living in the United States or Canada?\n"
+ "(If you are not living in other countries and \n"
+ " installing from international CDROM, please\n"
+ " choose \"NO\")"))
+ USAResident = TRUE;
+ else
+ USAResident = FALSE;
+ }
}
else
USAResident = FALSE;
--
---
Tatsumi Hosokawa
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: VMWare 2.0R broken - linux ioctl(13, 1260, *) not implemented
At Sun, 5 Mar 2000 01:32:39 -0500 (EST),
Andrew Atrens [EMAIL PROTECTED] wrote:
A missing (not implemented) linux ioctl is breaking VMWare 2.0 -
linux: 'ioctl' fd=13, cmd=1260 ('^R',96) not implemented
After rummaging around in the 2.3 kernel, I found the following in
`linux/include/linux/fs.h':
Hmm? I'm using Win98 (Japanese), Win2K (Japanese), and
FreeBSD-current on vmware 2.0 with linux emulator of yesterday's
-current without any problems. Am I wrong?
---
Tatsumi Hosokawa
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
