Re: [Cooker] kernel-2.4.2.6.4tmb
Quoting Svetoslav Slavtchev: Quoting John O'Toole [EMAIL PROTECTED]: on this same vein, I have a VisionPlus 1020 DVB card, are there any plans to have this working? currently, if I even have the card plugged into the PCI slot, cooker will hang at Determining module dependancies... and only a hard reset will dislodge it..it seems to be happening when the bttv.o module is referenced...this card is also called the twinhan 1020 (www.twinhan.com). It's also possible I'm missing something in configuration of this card? cheers all, John it seems currently there are no drivers: http://www.linuxtv.org/mailinglists/linux-dvb/2002/07-2002/msg00207.html but it shouldn't load bttv and it shouldn't lock up :( Actually, it looks like the card has a bt878 chip and in theory it should be supported by the bttv driver: From linux-2.4.21/Documentation/video4linux/bttv/Cards: Twinhan --- DST Card/DST-IP (bt878, twinhan asic) VP-1020 Sold as: KWorld DVBS Satellite TV-Card Powercolor DSTV Satellite Tuner Card Prolink Pixelview DTV2000 Provideo PV-911 Digital Satellite TV Tuner Card With Common Interface ? DST-CI Card (DVB Satellite) VP-1030 DCT Card (DVB cable)
Re: [Cooker] Updated 18mdk update kernel...
On the topic of the update kernel and the kernel that Danny maintains, also applies to the modified update kernel from Thomas. Would you guys consider giving your kernels different names, just so that we don't have to ask confused users Which version of 2.4.21.0.18 are you using? The security update one, Thomas' one or Danny's? Thomas, at some point you used TmB for your kernel, was there something you didn't like about that? Danny, could you do something similar? Btw. I love your kernel versions, I think you are both doing an incredible job with the kernel. Thank you both. I just don't want other users to get confused. Best, Narfi.
Re: [Cooker] Updated 18mdk update kernel...
Thomas Backlund wrote: The reason my _updated_ update kernel kept the version was to keep it name compatible with the original update kernel so that 3rd party modules and RPMS wont complain ( nVidia, Ati, ...) Ah! That's a good reason. I agree with Danny that hackkernel is a bad, bad name! The kernels that you guys provide are as solid as they get :-) Thanks for your hard work, Narfi.
Re: [Cooker] Asus A7N8X USB
Stefan van der Eijk wrote: Has anybody had any luck getting USB to work on a A7N8X? Yes. IIRC, I had problems using the lower 2 ports, but the upper 2 work without any problems. I have not modified /etc/lilo.conf and /etc/modules.conf from what I got from a clean installation of 9.1. Bios settings (as I remember them to be!) USB Controllers: V1.1+V2.0 APIC: disabled /etc/lilo.conf: append=devfs=mount acpi=off ide1=ata66 quiet /etc/modules.conf: alias eth0 3c90x alias sound-slot-0 i810_audio probeall usb-interface usb-ohci ehci-hcd alias ieee1394-controller ohci1394 lsusb -vv shows Bus 001, Bus 002 and Bus 003. Buses 1 and 2 seem to be USB 1.1 and bus 3 seems to be USB 2.0. The only thing that bothers me is that Thomas Backlund's patch for Firewire on the A7N8X deluxe did not make it into the standard kernel :-( Narfi.
Re: [Cooker] Asus A7N8X USB
Narfi wrote: I have not modified /etc/lilo.conf and /etc/modules.conf from what I got from a clean installation of 9.1. ... /etc/lilo.conf: append=devfs=mount acpi=off ide1=ata66 quiet Sorry, about the incorrect statement. I added the ide1=ata66 clause into /etc/lilo.conf. It boosted hdparm from 22 MB/s to 40 MB/s. Narfi.
Re: [Cooker] Fwd: mpeg2enc timing results [narfi@cs.wisc.edu]
Giuseppe wrote: w9ya wrote: Austin wrote: [for me, thanks Austin!] The best times of the 4 were: athlon-xp:12.16 i586: 13.24 i586, no mmx: 57.65 Honestly I never found yet a package that will increase performance of even 10% just changing the compiler flags Guiseppe, I completely agree with this statement. My trivial experiment shows 2 things: 1) It pays off bigtime to allow mjpegtools to use the MMX instruction set. 2) We only get a minimal benefit from compiling for athlon instead of i586. When the discussion of mjpegtools started, some people wanted local recompilations but these numbers to not support that idea. They do, however, strongly support the idea of building and distributing mjpegtools with and without the MMX instructions. [The former is in order to get the performance benefit, the latter in order to follow the Mandrake architecture policy] If you can help Austin in any way to set that up, we would all be very grateful. So far, Austin has only received vague instructions and ridicule despite his best attempts at asking polite and constructive questions. Narfi.
[Cooker] openoffice, Japanese and kinput2
i, I've been trying to find something on the lock-ups that occur in openoffice.org in a Japanese environment when using kinput2. This happens on a current cooker [as well as on 9.0, actually]. The problems occurs as follows: Start openoffice.org and select a font capable of displaying Japanese. Hit shift-space in order to activate the input method editor and type something in, say, hiragana without the quotes. Then hit ctrl-w twice to bring up the candidate selection window, press the right arrow key once to choose a candidate and hit enter twice to confirm that candidate. That should be enough to cause problems with OOo, namely possible lockups, some keys don't seem not to work, others don't work as expected, etc. Anyway, what I seem to have found as a solution is to append the following to /usr/X11R6/lib/X11/app-defaults/Kinput2 *SeparateConversion.input: false *selectionShell.input: false *auxShell.input: false Japanese speakers can find this in: http://openoffice-docj.sourceforge.jp/document/faq/us_linux.html and suse seems to have been aware of this for quite a while: http://lists.suse.com/archive/m17n/2002-May/0055.html Now, my question to Pablo and those that use kinput2 regularly is whether this is an acceptable solution. It means that the kinput2 candidate selection window never receives the keyboard focus, so that the arrow keys don't work anymore when selecting candidates. Instead, one has to use ctrl-w to cycle forward or to use the mouse. Unless anyone objects vociferously, I recommend adding this to the app-defaults/Kinput2 file in order to make ooffice usable again with kinput2. Narfi.
Re: [Cooker] kernel headers problems (again)
On Monday 28 October 2002 13:07, Warly wrote: David Walser [EMAIL PROTECTED] writes: --- Austin Acton [EMAIL PROTECTED] wrote: Okay, I've come across this problem two more times since my first two emails went unnoticed. There are some problems with the current headers Do not hesitate cc the package maintainer if he does not answer in a sensible delay. Ok, let's try again: As far as we have been able to see in this thread, the #include statements in /usr/include/kernel/videodev.h and /usr/include/kernel/videodev2.h are royally screwed up: a) Why does kernel/videodev.h include kernel/fs.h? It breaks, among other things, mjpegtools. b) Why are all the include statements missing from kernel/videodev2.h? Narfi. Below: The #include-s are compared to stock 2.4.18 and 2.4.19. [1001] grep include /usr/include/linux/videodev.h #include linux/types.h #include linux/version.h #include linux/fs.h # include linux/videodev2.h #include linux/poll.h #include linux/devfs_fs_kernel.h [1002] grep include /usr/include/linux/videodev2.h Compare this to 2.4.18 and 2.4.19 where linux/fs.h is not included: [1005] grep include linux-2.4.19/include/linux/videodev.h #include linux/types.h #include linux/version.h # include linux/videodev2.h #include linux/poll.h #include linux/devfs_fs_kernel.h [1006] grep include src/linux-2.4.18/include/linux/videodev.h #include linux/types.h #include linux/version.h #include linux/poll.h #include linux/devfs_fs_kernel.h Compare videodev2.h to ftp://ftp.thedirks.org/pub/v4l2/kernel2.4/videodevX/videodevX-20020330.tgz: [1045] grep include src/videodevX/videodev.h #include linux/types.h #include linux/version.h #include linux/poll.h #include linux/devfs_fs_kernel.h
Re: [Cooker] kernel headers problems (again)
On Sunday 27 October 2002 09:48, Austin Acton wrote: On Sun, 2002-10-27 at 06:42, Guillaume Rousse wrote: There was a fix proposal some times ago, consisting of modifying the glibc headers with an additional #ifdef __KERNEL__ around the redondants definitions. See the thread FYI: Getting mjpegtools built with avifile (divx/lav2divxt) for =Mandrake 8.2 for more details. Now the cooker is unfrozen, maybe it could be done. Sounds good. This sounds like a good, permanent solution, but it involves changing most/all of the kernel headers and it's not what's needed to solve this problem. The question in front of us is much simpler: Why were these 2 kernel headers changed: linux/videodev2.h, linux/videodev.h? Once we know that, we can hopefuly change them back into the way everybody else has them. After that has been done, we can debate the #ifdef __KERNEL__ issue because that would again be doing something that isn't done in stock 2.4.19 and I'm sure the developers will hesitate making such a change. Can somebody find the patch to these 2 files in mandrake's cvs? I would imagine that finding it and being able to contact that developer directly might help getting some reponse on this issue. I looked and I couldn't find it. Vacations or no vacations, this bug report has received absolutely no response from any employee despite the fact that there have been 4 threads about it on cooker, starting on June 3rd. My hat's off to Austin for his persistence. Narfi.
Re: [Cooker] HP 9100i CDRW on MSI k7t266 pro2 mobo -- lockup
On Monday 21 October 2002 12:49, you wrote: On Tue, 1 Oct 2002, H. Narfi Stefansson wrote: Hi, I'm now running 9.0, but I can't get it to work while my CD writer is connected to my motherboard Must admit I had a very similar problem, with the same drive, but with SuSE 8.0. I put it down to a dodgy drive, it had stopped writing some weeks earlier. Maybe there was a bad batch, maybe we should swap seriel numbers and sue! Sorry, I can't join you for that because I know the CD writer is working just fine. I ended up putting it into my USB 2.0 case enclosure and I can use it that way without any problems. Perhaps the bios is buggy, perhaps the bios and mdk don't communicate well enough, I don't know where the fault is. But I cannot connect that cdrw to my motherboard or to my PCI controller card because that always results in lockups. I tried apic, no apic, dma, no dma, master, slave, with and without scsi emulation, on the mobo, on the controller card and most of the possible combinations of these... Narfi.
[Cooker] linux/videodev.h in 9.0
Hi, does anybody on this list why /usr/include/linux/videodev.h was changed in 9.0? I've looked in the changelog and couldn't find anything. Neither stock 2.4.18 nor the stock 2.4.19 version of linux/videodev.h include linux/fs.h, whereas Mandrake's version of linux/videodev.h does. Why is this bad? Well, mjpegtools won't compile without some hacking, that's one thing. I'm just wondering why this was done and whether it's going to stay this way in 9.1. I couldn't find anything in the changelog for kernel-headers. Best, Narfi. 2.4.18: grep include linux/include/linux/videodev.h #include linux/types.h #include linux/version.h #include linux/poll.h #include linux/devfs_fs_kernel.h 2.4.19: grep include linux-2.4.19/include/linux/videodev.h #include linux/types.h #include linux/version.h # include linux/videodev2.h #include linux/poll.h #include linux/devfs_fs_kernel.h Mandrake 9.0: grep include /usr/include/linux/videodev.h #include linux/types.h #include linux/version.h #include linux/fs.h # include linux/videodev2.h #include linux/poll.h #include linux/devfs_fs_kernel.h
[Cooker] emacs crashes under ja_JP
I start in the en_US locale narfi/home/narfi[1000] locale LANG=en_US LC_CTYPE=en_US LC_NUMERIC=en_US LC_TIME=en_US LC_COLLATE=en_US LC_MONETARY=en_US LC_MESSAGES=en_US LC_PAPER=en_US LC_NAME=en_US LC_ADDRESS=en_US LC_TELEPHONE=en_US LC_MEASUREMENT=en_US LC_IDENTIFICATION=en_US LC_ALL= Then I switch locales narfi/home/narfi[1001] export LC_ALL=ja_JP narfi/home/narfi[1002] emacs Fatal error (11).Segmentation fault (core dumped) I put an strace up at http://www.cs.wisc.edu/~narfi/emacs_trace.txt This is on a standard 9.0 install. It happens regardless of whether I load my ~/.emacs file or not. emacs -nw runs without problems. Needless to say, this also happens even if I set all the XIM variables and ENC as well, I just posted the simplest way I found to crash emacs. narfi/home/narfi[1004] rpm -qa | grep -i emacs emacs-X11-21.2-12mdk emacs-21.2-12mdk Narfi. ps. Of course I don't know whether the source of the problems here is emacs or XFree86. I do know that I tested this in 2 of the RCs, RC1 and RC2 IIRC and I had no problems.
Re: [Cooker] HP 9100i CDRW on MSI k7t266 pro2 mobo -- lockup
On Tue, 1 Oct 2002, H. Narfi Stefansson wrote: Hi, I'm now running 9.0, but I can't get it to work while my CD writer is connected to my motherboard [Most likely, I also had this problem with 8.2, but my hardware setup was different there, so it's not the best to compare] I was unable to install with the drive connected to the motherboard, so I disconnected, installed without it and have since tried to reconnect the drive and boot. All those attempts have resulted in lockups. I tried all combinations of apic/noapic in the bios and as a boot parameter to linux as well as with and without supermount. The net result: supermount has no effect on this freeze. Booting with/without noapic in lilo has no effect either. With APIC off in the bios, I can't even boot, but with APIC on in the bios, I can start and log into the console, but logging into KDE freezes the computer. The last message in the logs before the freeze is (unsurprisingly): Oct 1 17:45:56 localhost kernel: Uniform CD-ROM driver Revision: 3.12 I put the output of dmesg up on the web: http://www.cs.wisc.edu/~narfi/dmesg.txt and http://www.cs.wisc.edu/~narfi/dmesg_noapic.txt for the 2 cases where supermount was enabled, apic enabled in bios and lilo was run with or without the noapic parameter. Please let me know if you need any more info Narfi. One important thing to add: I've read in the MSI forums that in the case of 8.2, this bug only surfaced with BIOS version 3.3. I am using version 3.4 and would very much like to assist with making Mdk work out of the box with the newer versions of the bios. Narfi.
[Cooker] harddrake2 bug(?), controller card listed as raid?!?
I just installed an old SIIG controller card in an empty PCI slot on my machine. Its an ATA controller card, has 2 connectors. After I had booted from the rescue CD and updated my /etc/fstab and /etc/lilo.conf and rebooted, I ran harddrake2. When I clicked on the Configure button for the new item in the list of detected hardware, I got the following message on the console: Wed Oct 2 21:40:41 2002 Gtk-LOG **: file gtkstatusbar.c: line 233 (gtk_statusbar_pop): assertion `context_id 0' failed. at /usr/lib/libDrakX/harddrake/ui.pm line 223. and that was the only response I received. Additionally, the new controller card seems to be detected as a raid card: md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. [from dmesg] harddrake2 says: (E)IDE/ATA controllers VT82C586 IDE [apollo] HPT366: Module: hptraid HPT366: Module: hptraid Where the highpoint controller is presumably repeated once for each connector on the card. Narfi. harddrake-ui-1.1.9-53mdk 2.4.19-16mdk ps. Can somebody explain to my why my devices shift when I insert the card: /dev/hda -- /dev/hde /dev/hdc -- /dev/hdg and the card gets /dev/hda, hdb, hdc and hdd? I would've liked my primary and secondary controllers to keep their designations as hda, hdb, hdc and hdd.
Re: [Cooker] HP 9100i CDRW on MSI k7t266 pro2 mobo -- lockup
On Wednesday 02 October 2002 10:26 am, Stéphane Teletchéa wrote: Le Mercredi 2 Octobre 2002 17:18, vous avez écrit : On Tue, 1 Oct 2002, H. Narfi Stefansson wrote: Hi, I'm now running 9.0, but I can't get it to work while my CD writer is connected to my motherboard I was unable to install with the drive connected to the motherboard, so I disconnected, installed without it and have since tried to reconnect the drive and boot. All those attempts have resulted in lockups. Try to use hdparm and define a /etc/sysconfig/hardiskhdX (where X is the letter for your cd). In this config, uncomment dma=1 and move it to DMA=0. Reboot and see if it copes your problem. This was sound advice but did not work. I've tried to connect the cdrw to the motherboard or to a controller card and tried to access it without dma, alas no success. Any access to the device with hdparm resulted in a lockup when the drive was on the motherboard. When I connected it to a controller card, I could remove the dma assignment [I used hdparm -d0 /dev/hda; hdparm -k1 /dev/hda;], but I still had lockups on subsequent reboots. Yes, on a later reboot, I verified that the drive had stored the dma=0 assignment. I don't mean for these to sound like support questions -- I just happen to think that a failure to install and hard lockups on a new release are worth investigating -- I hope you agree, Narfi. ps. I couldn't install 8.2 with the CDwriter on my motherboard, but I didn't investigate that any further since it worked on my controller card. However, I'm a little more patient now, and the drive won't work on either of them...
[Cooker] HP 9100i CDRW on MSI k7t266 pro2 mobo -- lockup
Hi, I'm now running 9.0, but I can't get it to work while my CD writer is connected to my motherboard [Most likely, I also had this problem with 8.2, but my hardware setup was different there, so it's not the best to compare] I was unable to install with the drive connected to the motherboard, so I disconnected, installed without it and have since tried to reconnect the drive and boot. All those attempts have resulted in lockups. I tried all combinations of apic/noapic in the bios and as a boot parameter to linux as well as with and without supermount. The net result: supermount has no effect on this freeze. Booting with/without noapic in lilo has no effect either. With APIC off in the bios, I can't even boot, but with APIC on in the bios, I can start and log into the console, but logging into KDE freezes the computer. The last message in the logs before the freeze is (unsurprisingly): Oct 1 17:45:56 localhost kernel: Uniform CD-ROM driver Revision: 3.12 I put the output of dmesg up on the web: http://www.cs.wisc.edu/~narfi/dmesg.txt and http://www.cs.wisc.edu/~narfi/dmesg_noapic.txt for the 2 cases where supermount was enabled, apic enabled in bios and lilo was run with or without the noapic parameter. Please let me know if you need any more info Narfi.
Re: [Cooker] Installer failed to install bootloader
On Sunday 22 September 2002 15:16, Todd Lyons wrote: -L- wrote on Sat, Sep 21, 2002 at 10:31:05PM -0500 : 2 out of 5 times that i have installed mandrake9.0RC3 the installer fails to install the bootloader because it requests for it on CD1,When you put cd1 it will not find it on there and keep requesting. So you have to restart the install or boot off a floppy. I believe the bootloader is on CD3. No, the lilo rpm is on CD1, the code that instantiates it is on the ramdisk that got loaded from CD1. If it asks for CD1, that means that something didn't get installed earlier in the install process, but at this point, it's really too late to go back to CD's (that's why lots of things are copied to a temporary cache directory during the install) Blue skies... Todd Guillaume, isn't the same thing going on there as I reported? My message: http://marc.theaimsgroup.com/?l=mandrake-cookerm=103241096406420w=2 GC's reply: http://marc.theaimsgroup.com/?l=mandrake-cookerm=103243775726447w=2 My bug report has hopefully been solved already. Narfi.
[Cooker] installer got stuck in a loop
RC3: Just before installing the bootloader, the installer got stuck in a loop, it kept asking for installation cd 1, I put it in, it ejected it and asked for it again. We argued like this for a while, I tried to put all 3 of the CDs in several times and I ended up having to hit cancel. Things went downhill from there, and I ended up having to reboot. The short story is that I received messages about: 1) mkinitrd failed 2) isa ??? failed in drakx 3) no loopback found or something similar to that. That's when I had no option but to reboot. I copied the logs from /root/drakx/, they are accessible at: http://www.cs.wisc.edu/~narfi/9.0RC3failure/ddebug.log.gz http://www.cs.wisc.edu/~narfi/9.0RC3failure/install.log.gz http://www.cs.wisc.edu/~narfi/9.0RC3failure/report.bug.gz and will stay there until 9.0 is released Something similar happened to me in one setup of RC2, but I tried to reproduce it, but couldn't and I lost the /root/drakx/* files from the failed installation. Narfi.
kinput2 doesn't work in OOo (Was Re: [Cooker] OpenOffice.org regression with kinput2)
On Sunday 08 September 2002 05:30, Laurent Montel wrote: Le Sunday 08 September 2002 12:24, Gwenole Beauchesne a écrit : Hi, I just tried to create a couple of new users and type in some simple Japanese with OpenOffice.org and soon I had trouble with keyboard focus and I seemed neither able to start nor stop kinput2. The procedure was as follows: create a new user, log into kde, use localedrake or kde-control center to switch to Japanese. Log out and in again. Start ooffice from the command line. Once OOo is up, hit shift-space to start kinput2. I typed in arigato and hit ctrl-w to get the candidate selection window. I selected my candidate, hit enter and after that I had trouble editing in OOo. The neither delete key not the backspace key seemed to work. I hit ctrl-\ to suspend kinput2, but the small 'edit' window from kinput2 stayed open even though I was typing in English text. I just finished doing a fresh install of RC2, plus adding all the updates I could find at ibiblio and this problem still persists. [Which tells us that the reason was not simply that I had damaged my setup of RC1]. Of course, I have no idea where this problem originates, but I had no problems with using kinput2 together with this version same of OOo 3-4 days ago. Perhaps it was the XFree86 update? Narfi.
Re: [Cooker] usb storage: desktop icon not removed/still
On Friday 06 September 2002 10:53, Frederic Crozat wrote: On Fri, 06 Sep 2002 16:46:55 +0100, Alastair Scott wrote: --=-uv4Dj+q907OgonNFRe5O Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-09-06 at 14:25, H. Narfi Stefansson wrote: I thought the whole idea was that this should be automated now. Does the= =20 'automated' part only apply to the mounting and not to the unmounting? In other words, is this a feature or is this a bug? It looks like a bug, and I reported it during the 'great mail server outage' but it appears that that post never got through. So ... I have a Sony Clie PEG-425T and used to mount its memory stick 'by hand' from the command line as /dev/sda1.=20 With the automated facility, under Gnome I see a 'removable' icon on the desktop (with the rather inappropriate appearance of a hard disk!) but: i. the icon appears to be stuck there forever and never goes away, even when the Clie is taken out of the cradle and the PC rebooted without it; Indeed.. Because it is using supermount.. No problem here.. ii. the 'Unmount Volume' command has no effect. In supermount mode, Unmount Volume doesn't do anything since you are not root.. I'll try to hide it (no garantee) iii. the entry in /etc/fstab looks like none /mnt/removable supermount dev=3D/dev/sda1,fs=3Dauto,--,iocharset=3Diso8859-15,codepage=3D850,uma sk=3D= 0 0 0 This looks OK, but doesn't explain the unmounting not happening: I have to issue umount -a /dev/sda1 from the command line to actually do it. There is no unmounting because usb-storage doesn't remove the /dev/sda1 entry when clié is no longer connected.. Therefore, there is no way to know the device is here or not :(( Can this be changed in the usb-storage module or is nobody willing to touch the kernel modules issues at this point, or is it simply too difficult? Narfi.
[Cooker] Fwd: Free Japanese Fonts
Utuhiro was having some trouble with the mailing list so he sent me this message. Maybe I'll have more luck sending this to the list than he did. I showed these fonts to my wife and asked her to rate them, she put kochi gothic and kochi mincho at the top since the other fonts were cartoonish. Of course they are still perfectly usable. Is this the same kochi gothic as you are packaging? Is the kochi mincho included? Thanks Utuhiro, Narfi. -- Forwarded Message -- Subject: Free Japanese Fonts Date: Fri, 06 Sep 2002 17:55:36 +0900 From: utuhiro [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi Gwenole, If you know other *free* and freely redistributable Japanese fonts in TrueType or Type1 format, you are very welcome to suggest them. Ok, I suggest them. See this page: http://www.geocities.jp/knee2525/fonts-jp/ All fonts are TrueType. These fonts are free, but you need to mail to authors if you pack them for Mandrake. --- Aqua_fonts are made by a Japanese lady (Aqua). http://aquablue.milkcafe.to/tears/ http://aquablue.milkcafe.to/tears/font/dl.htm How to mail: go to http://aquablue.milkcafe.to/tears/ and click Mail. Kochi Gothic is a famous Japanese free font. http://www.on.cs.keio.ac.jp/~yasu/jp_fonts.html mailto:[EMAIL PROTECTED] The author is Yasuyuki Furukawa. He also make Kochi-Mincho. Ushi-hand is there http://www.octp-net.ne.jp/~ushi/ mailto:[EMAIL PROTECTED] The author is USHI. Y.Oz is a father of a four years old child. http://users.hoops.ne.jp/yozk/ http://users.hoops.ne.jp/yozk/download.html mailto:[EMAIL PROTECTED] GN-Cute-Pop http://fine.tok2.com/home/g7/ http://fine.tok2.com/home/g7/hpfont/cutepop2.html mailto:[EMAIL PROTECTED] The author is gen_shichi. This font is so cute! ---
[Cooker] rpmdrake-sources
When I try to start rpmdrake-sources as a non-privileged user, it first asks me for the root password and then it exits. Of course, I expected the program window to appear after I had typed in the correct password. rpmdrake works fine in this regard, but I did not try rpmdrake-remove. This is using rpmdrake-2.0-20mdk Narfi.
[Cooker] OO and fonts
I cannot select the font HG Mincho Light J from the font pull-down box, I have to type it in the font selection box in order to switch to that font. This happens regardless of whether the environment is completely Japanese, a mixture ja/en_US or fully en_US. Best, Narfi. OpenOffice.org-libs-1.0.1-7mdk OpenOffice.org-l10n-en-1.0.1-7mdk OpenOffice.org-l10n-ja-1.0.1-7mdk OpenOffice.org-1.0.1-7mdk
Re: [Cooker] OO and fonts
On Thursday 05 September 2002 14:24, Gwenole Beauchesne wrote: Hi, I cannot select the font HG Mincho Light J from the font pull-down box, I have to type it in the font selection box in order to switch to that font. Hmm, if you don't see that font in the font pull-down box, then it's probably because OOo doesn't support it at all? What sort of font is it? TrueType? Type1? Beats me. However, this is the font that OO suggests: 1) Clean ~/.openoffice 2) Start OO, go to Tools-Options-Language Settings-Languages and enable Asian languages, set Japanese to be the default. Close the dialog. 2) Go to Tools-Options-Text Document-Basic Fonts (Asian) and you'll see that OO has suggested to use HG Mincho Light J. Narfi.
Re: [Cooker] Adding cooker ftp to soft manager
On Thursday 05 September 2002 13:50, Joan Tur wrote: Probably I'm doing something wrong but I haven't been able to add those cooker sources to soft manager. I've chosen to add a ftp source, I've given it the name cooker and I've copyed the ftp link. I've also tryed urpmi: # urpmi.addmedia cooker ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandrake-devel/cooker with hdlist.cz With no luck 8( Thanks!! You're very close: urpmi.addmedia cooker ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandrake-devel/cooker/i586/Mandrake/RPMS/ with ../base/hdlist.cz should work. You can also use ../base/synthesis.hdlist.cz instead of ../base/hdlist.cz. The synthesis is a smaller file (i.e. a much faster download) but stores much less info. Right now, the synthesis file is 136 kb for cooker, whereas hdlist.cz is approx 14 MB. Narfi.
[Cooker] Re: OpenOffice-ja shows wrong characters
I am guessing this is similar to what utuhiro wrote in: http://www.mail-archive.com/cooker@linux-mandrake.com/msg73401.html When I did a fresh install of RC1 + updates, OO seemed to work very well under the Japanese locale. However, after I added more fonts to the system, OO comes up completely garbled in the Japanese locale. I'd venture to guess that it chose to use some font which doesn't support Japanese so all non-English text is unreadable. Perhaps somebody can at least tell me how to change the font OO uses for its menus and dialogs so that I can change it back into something readable. A proper fix would of course be the best. Narfi ps. If this will be fixed in OOo-8mdk, then my hat's off to you!
[Cooker] localedrake
Using drakxtools-1.1.9-34mdk.i586.rpm 3 things: 1) localedrake asks the user for his/her password in order to log out. When running localedrake from the shell, this is not a problem since the password prompt appears in the shell. However, this also means that when the user changes the language settings in the KDE control center and localedrake pops up, the user can't enter the password. Why on earth is the password needed anyway? 2) Why is localedrake in /usr/sbin? This seems like a per-user utility and not to be restricted to the sys-admin. 3) Things are getting more and more complicated for multilingual users. In order to be able to type in Japanese text but keep the UI in English, I have to: a) Go to the KDE control center [Contry language], change the country to Japan and keep it open. b) Then localedrake pops up, I select Japanese, click ok. Then localedrake asks me if I want to log out, I click cancel. c) Change the country to C in the control center. d) Then localedrake pops up again, click cancel. e) Click OK in the control center f) Then localedrake pops up yet again, click cancel. g) Edit ~/.i18n and change LC_MESSAGES from ja to C. Even if you don't write a single new line of code for multilingual users, please don't write the code for single language users in such a way that it makes life difficult for the others. Narfi.
Re: [Cooker] Suggestion: Better Japanese-Input
On Friday 02 August 2002 08:38, utuhiro wrote: Mandrake's kinput2 is not easy to use. In Mandrake: XIM ON: shift+space XIM OFF: shift+\ How to input Japanese n: type n Most distributions: XIM ON: shift+space XIM OFF: shift+space How to input Japanese n: type nn 1) I beg to differ on the shift+space vs. ctrl+\ issue: Both my wife and I hit shift+space by accident all the time -- when typing in simple commands like grep '^ $' foo_* and thereby we accidentally switch to Japanese input mode when we intend to write in English. Having it both start and stop the kinput2 would make matters even worse since that would cause us trouble also when we're writing in Japanese! I am fully aware of the fact that it's customary to have shift+space toggle between Japanese input mode and ascii input mode and have ctrl+\ turn off the Japanese input mode, but I fully support the Mandrake keystrokes in this regard. Actually, we would like the most to abolish the shift+space keystroke for kinput2, but that would be to stray too far from the conventions, I guess. 2) I fully agree with you on the n versus nn issue, but I have no idea where to change that. 3) wnn vs. canna: I have no idea, never tried canna. Narfi.
Re: [Cooker] 9.2b2: won't boot on msi k7t266 pro2
On Friday 02 August 2002 21:41, H. Narfi Stefansson wrote: I tried to boot off the CD, hit enter for regular installation, the progress bar showing the loading moved... till it was 3/4 done, then the screen went black and the computer was unresponsive ever after that. The md5sums on the download images were fine, I tried burning the CDs twice. Same thing happened when I tried to boot from cd.img or hd.img I did check the md5 sums of cd.img and hd.img before copying them to a floppy. Hardware: msi k7t266 pro2, bios version 3.4 ati xpert 2000 SIIG controller card linksys network card lucent PCI modem Connected to the motherboard controllers: wd 440bb DVD drive Connected to the SIIG controller card: IBM hard drive, with zip drive as a slave. HP CD-Writer 9100 attached: lspci and dmesg when running 8.2 Narfi. I may add to this that I've also tried F1 when booting from CD, the screen changes color and then the computer locks up. I've tried text based install and still lockup. I did get the installation started with 2.2.19, though ! When choosing text mode with hd.img, I got some status information: Checking 'hlt' instruction ... OK Checking for poped bug ... OK POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESRvalue before enabling vector: 2 and then I got the lockup again. Narfi.
Re: [Cooker] Rxvt, Emacs X resources via .Xdefaults?
On Thursday 23 May 2002 02:27, you wrote: I'm running 8.2 but I've had this problem with earlier releases of Mandrake, too. How, exactly, do X resources get set on Mandrake? For instance, I have Rxvt*font, Rxvt*background and Rxvt*foreground set in my ~/.Xdefaults file. The font resource works, but the colour settings get ignored. emacs*Font also has no effect. xterm*background is set to 'white' but I get some sort of pale lemon yellow instead. This does it for me: # cat ~/.Xdefaults emacs.background: white emacs.foreground: black emacs.font: fixed Narfi.
Re: [Cooker] Japanese IME in 8.2 b4
On Saturday 09 March 2002 06:07 am, Michael Beddow wrote: I can get it to start up and accept input using the normal shift-space key combination, but the same combination should toggle it off again, and it doesn't, so it's not possible to revert to ASCII input. And the TAB to cycle between input modes doesn't seem to work either. But doesn't ctrl-\ work to get back to ASCII input? Does Ctrl-w work to cycle between input modes? I've had no problems with kinput2 since the middle of the testing cycle of beta3. My reference for the key strokes in kinput2 in Mandrake has always been http://www.mozilla.org/quality/intl/kinput2/kinput2keys.html I just tested the keystrokes again, and they all worked as documented on that webpage. Narfi.
Re: [Cooker] rpmdrake: SHOULD NOT HAPPEN
On Friday 08 March 2002 08:32 pm, huug wrote: rpminst didn't install: 'gnome-core-1.4.0.6-11mdk' 'gnome-core-1.4.0.6-11mdk' added to the already_installed_list rpminst didn't install: 'ldconfig-2.2.4-25mdk' 'ldconfig-2.2.4-25mdk' added to the already_installed_list already installed: 'ldconfig', SHOULD NOT HAPPEN already installed: 'gnome-core', SHOULD NOT HAPPEN You are not the only one. This started happening to me last night with a different package. I'm using urpmi-3.3-21mdk, rpmdrake-1.4-17mdk Suggestions? Narfi. [root@dhcp-104-6 root]# rpm -q userdrake userdrake-0.3-21mdk [root@dhcp-104-6 root]# rpmdrake % Total% Received % Xferd Average Speed Time Curr. Dload Upload TotalCurrent LeftSpeed 100 223k 100 223k0 0 46970 0 0:00:04 0:00:04 0:00:00 168k rpm2header /var/cache/urpmi/rpms/userdrake-0.3-22mdk.i586.rpm/var/cache/urpmi/rpms/userdrake-0.3-22mdk.i586.rpm rpminst didn't install: 'userdrake-0.3-22mdk' 'userdrake-0.3-22mdk' added to the already_installed_list already installed: 'userdrake', SHOULD NOT HAPPEN [root@dhcp-104-6 root]# rpm -q userdrake userdrake-0.3-21mdk [root@dhcp-104-6 root]# urpmi userdrake everything already installed
[Cooker] drakfont/ttf fonts not available in KDE.
[narfi@dhcp-104-6 Mail]$ rpm -q XFree86 XFree86-xfs kdebase drakxtools XFree86-4.2.0-8mdk XFree86-xfs-4.2.0-8mdk kdebase-2.2.2-86mdk drakxtools-1.1.7-91mdk I installed 8.2 beta4, with English as a primary language and Japanese, Icelandic and German as secondary languages. I've upgraded everything to cooker. I'm in runlevel 5 with en_US as my locale, working in KDE. Critial point in setup: I'm using anti-aliasing in KDE Summary: I start with a clean drakfont/ttf and drakfont/Type1 directory. Then I choose to import a single ttf font, verdana.ttf, using drakfont. It does not show up in the KDE font selection dialog. Additionally, I tried to run ttmkfdir and mkfdir in drakfont/ttf and restart xfs, but I still can't see Verdana in the KDE font selection dialog. Summary of fix: If I copy verdana.ttf to /usr/share/fonts/ttf/western/, run ttmkfdir, mkfdir and xftcache there and restart xfs, I can then select Verdana in the KDE font selection dialog. My guess: For some reason, KDE does not look for fonts the directory /usr/X11R6/lib/X11/fonts/drakfont/ttf. Please ask if you have more questions. Narfi. Detailed list of commands: # First import using drakfont. # Then the /usr/X11R6/lib/X11/fonts/drakfont/ttf/fonts.dir file is empty (!). # Recreate everything in drakfont/ttf: [root@dhcp-104-6 western]# cd /usr/X11R6/lib/X11/fonts/drakfont/ttf/ [root@dhcp-104-6 ttf]# ttmkfdir -o fonts.scale [root@dhcp-104-6 ttf]# mkfontdir [root@dhcp-104-6 ttf]# xftcache ./ [root@dhcp-104-6 ttf]# service xfs restart Restarting X Font Server. [ OK ] [root@dhcp-104-6 ttf]# chkfontpath Current directories in font path: 1: /usr/X11R6/lib/X11/fonts/misc:unscaled 2: /usr/X11R6/lib/X11/fonts/75dpi:unscaled 3: /usr/X11R6/lib/X11/fonts/100dpi:unscaled 4: /usr/X11R6/lib/X11/fonts/misc:unscaled 5: /usr/X11R6/lib/X11/fonts/Type1 6: /usr/X11R6/lib/X11/fonts/TTF 7: /usr/X11R6/lib/X11/fonts/Speedo 8: /usr/share/fonts/ttf/decoratives 9: /usr/share/fonts/ttf/western 10: /usr/share/fonts/ttf/japanese 11: /usr/X11R6/lib/X11/fonts/drakfont/ttf 12: /usr/X11R6/lib/X11/fonts/drakfont/Type1 [root@dhcp-104-6 ttf]# # Verdana cannot be selected in K Menu-Configuration-KDE-LookNFeel-Fonts # Copy to /usr/share/fonts/ttf/western and set font up there: [root@dhcp-104-6 ttf]# cp verdana.ttf /usr/share/fonts/ttf/western/ [root@dhcp-104-6 ttf]# cd /usr/share/fonts/ttf/western [root@dhcp-104-6 western]# ttmkfdir -o fonts.scale unknown font foundry code SFT [root@dhcp-104-6 western]# mkfontdir [root@dhcp-104-6 western]# xftcache ./ [root@dhcp-104-6 western]# service xfs restart Restarting X Font Server. [ OK ] [root@dhcp-104-6 western]# chkfontpath Current directories in font path: 1: /usr/X11R6/lib/X11/fonts/misc:unscaled 2: /usr/X11R6/lib/X11/fonts/75dpi:unscaled 3: /usr/X11R6/lib/X11/fonts/100dpi:unscaled 4: /usr/X11R6/lib/X11/fonts/misc:unscaled 5: /usr/X11R6/lib/X11/fonts/Type1 6: /usr/X11R6/lib/X11/fonts/TTF 7: /usr/X11R6/lib/X11/fonts/Speedo 8: /usr/share/fonts/ttf/decoratives 9: /usr/share/fonts/ttf/western 10: /usr/share/fonts/ttf/japanese 11: /usr/X11R6/lib/X11/fonts/drakfont/ttf 12: /usr/X11R6/lib/X11/fonts/drakfont/Type1 # Now I can select Verdana in K Menu-Configuration-KDE-LookNFeel-Fonts It should be noted that after I've imported verdana.ttf using drakfont, it becomes immediately available in drakfont and openoffice. It also becomes available in KDE without anti-aliasing. But it is not available in KDE with AA. I chose to use verdana.ttf for the purposes of this example, but the same thing applies to all the windows fonts I've looked at. This is reproducible, meaning that once I remove verdana.ttf from /usr/share/fonts/ttf/western, I cannot select it in KDE. It still exists in /usr/X11R6/lib/X11/fonts/drakfont/ttf though!
[Cooker] Re: openoffice crashes when fonts-ttf-japanese is installed
On Friday 08 March 2002 10:32 am, you wrote: On Fri, 8 Mar 2002, H. Narfi Stefansson wrote: [narfi@dhcp-104-6 narfi]$ rpm -q openoffice openoffice-6.0.41-2mdk [narfi@dhcp-104-6 narfi]$ rpm -q fonts-ttf-japanese fonts-ttf-japanese-0.19990222-12mdk Known bug fixed in -5mdk by simply omitting /usr/share/fonts/ttf/japanese/ from OOo font paths since they appear broken or OOo can't handle those. Other people said that OOo was not the sole application in that case. Bye, Gwenole. Good to hear that it's been fixed. But where can I find -5mdk? Looked at sunet.se, mandrake.redbox.cz and ftp.ciril.fr but I can't find the openoffice rpm. Narfi.
[Cooker] openoffice crashes when fonts-ttf-japanese is installed
[narfi@dhcp-104-6 narfi]$ rpm -q openoffice openoffice-6.0.41-2mdk [narfi@dhcp-104-6 narfi]$ rpm -q fonts-ttf-japanese fonts-ttf-japanese-0.19990222-12mdk I installed 8.2 beta4, with English as a primary language and Japanese, Icelandic and German as secondary languages. I've upgraded everything to cooker. Scenario: OpenOffice crashes when I use the mouse to scroll in the font list in the font drop-down selection dialog in the toolbar if fonts-ttf-japanese is installed. My tests: I'm using the en_US locale, both in ~/.i18n and in KDE. I went through the font packages and uninstalled them one by one and then re-installed them one by one. I had to uninstall 3 of them until I got rid of the crashes. I installed 2 of them back again (fonts-ttf-decoratives 1.3-9 and fonts-ttf-west_european 1.3-9) and open office still ran without crashes. As soon as I install the 3rd one, fonts-ttf-japanese-0.19990222-12mdk, I can crash openoffice using the method described above. Note: This also happened with fonts-ttf-japanese-0.19990222-11mdk I hope this bug report is up to the current standards of bug reports here on cooker. If it turns out to be fodder for the FAQ, please tell me why :-) Please ask if you need more info, Narfi.
[Cooker] xmms-1.2.7-1mdk
I was surprised that I couldn't find anything reported about this on cooker already ... I don't think those locale files should be installed in /home/gc: Narfi. # rpm -q -p xmms-1.2.7-1mdk.i586.rpm --list /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/af/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/az/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/bg/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/ca/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/cs/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/da/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/de/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/el/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/eo/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/es/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/eu/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/fr/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/ga/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/gl/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/hr/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/hu/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/id/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/it/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/ja/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/ko/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/lt/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/lv/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/nl/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/nn/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/no/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/pl/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/pt/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/pt_BR/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/ro/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/ru/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/sk/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/sr/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/sv/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/tg/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/th/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/tr/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/uk/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/vi/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/wa/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/zh_CN.GB2312/LC_MESSAGES/xmms.mo /home/gc/rpm/tmp/xmms-1.2.7-1mdk-root/usr/share/locale/zh_TW/LC_MESSAGES/xmms.mo /usr/bin/wmxmms /usr/bin/xmms /usr/bin/xmms-shell /usr/lib/menu/xmms /usr/lib/xmms/Effect/libecho.la /usr/lib/xmms/Effect/libecho.so /usr/lib/xmms/Effect/libsox.la /usr/lib/xmms/Effect/libsox.so /usr/lib/xmms/Effect/libstereo.la /usr/lib/xmms/Effect/libstereo.so /usr/lib/xmms/Effect/libvoice.la /usr/lib/xmms/Effect/libvoice.so /usr/lib/xmms/General/libir.la /usr/lib/xmms/General/libir.so /usr/lib/xmms/General/libjoy.la /usr/lib/xmms/General/libjoy.so /usr/lib/xmms/General/libsong_change.la /usr/lib/xmms/General/libsong_change.so /usr/lib/xmms/Input/libcdaudio.la /usr/lib/xmms/Input/libcdaudio.so /usr/lib/xmms/Input/libidcin.la /usr/lib/xmms/Input/libidcin.so /usr/lib/xmms/Input/libmpg123.la /usr/lib/xmms/Input/libmpg123.so /usr/lib/xmms/Input/libtonegen.la /usr/lib/xmms/Input/libtonegen.so /usr/lib/xmms/Input/libvorbis.la /usr/lib/xmms/Input/libvorbis.so /usr/lib/xmms/Input/libwav.la /usr/lib/xmms/Input/libwav.so /usr/lib/xmms/Output/libOSS.la /usr/lib/xmms/Output/libOSS.so /usr/lib/xmms/Visualization/libbscope.la /usr/lib/xmms/Visualization/libbscope.so /usr/lib/xmms/Visualization/libsanalyzer.la /usr/lib/xmms/Visualization/libsanalyzer.so /usr/share/doc/xmms-1.2.7 /usr/share/doc/xmms-1.2.7/AUTHORS /usr/share/doc/xmms-1.2.7/COPYING /usr/share/doc/xmms-1.2.7/FAQ /usr/share/doc/xmms-1.2.7/NEWS /usr/share/doc/xmms-1.2.7/README /usr/share/icons/large/xmms.xpm /usr/share/icons/mini/xmms.xpm /usr/share/icons/xmms.xpm /usr/share/man/man1/wmxmms.1.bz2 /usr/share/man/man1/xmms.1.bz2 /usr/share/xmms/wmxmms.xpm /usr/share/xmms/xmms.xpm
[Cooker] font bugs in KDE and OpenOffice.org using imported Windows TT fonts.
First of all, sorry for the heavy cross-posting, I'm just in over my head here. May somebody more versed in font matters than I am please take over this one. I'm running 8.1 beta4, upgraded to cooker tonight from sunet. I've used drakfont to import my windows fonts. After I have imported them, they all show up in drakfont without any problems. They show up in the KDE font selection dialogs when not using AA. They don't show up in the KDE font selection dialogs when I'm using AA. [Configuration-LookNFeel-Fonts] They are half-way visible in OpenOffice, and browsing the fonts from the OO toolbar causes it to crash with a segmentation fault. Here are 2 screenshots I took of the KDE font selection dialogs and one of the OO font selection pull-down menu. Half of the OO pull-down menu is empty. http://www.cs.wisc.edu/~narfi/snapshot_kde_AA.png http://www.cs.wisc.edu/~narfi/snapshot_kde_noAA.png http://www.cs.wisc.edu/~narfi/snapshot_ooffice.png Can anyone reproduce this? I tried to copy my 8.1 drakfont directory to the 8.2 drakfont/ttf directory and restart xfs, but it had no effect. All these fonts work for me in 8.1 when using AA in KDE, so this really bugs me. We're talking about fonts such as Verdana, Times New Roman, Arial Unicode, Bitstream Cyberbit that are not accessible in AA in KDE or in OpenOffice.org, all very important for various reasons such as aesthetics or language support. Feel free to ask me further questions, although font setup is really not my strong side. Believe me, I would have supplied a patch for this one if I could have :-) Best, Narfi.
[Cooker] WinTV Go drakxtv
82 beta4 In short: My TV card was detected, but drakxtv failed to create a xawtvrc file for me I'm using NTSC, US cable The standard error output from running drakxtv is: full pci_probe sh: -c: line 1: syntax error near unexpected token `(c' sh: -c: line 1: `xvt -T 'Scanning for TV channels ' -e scantv -n NTSC -f USA (cable) -o ~/xawtv' After this, xawtv starts, but in the wrong mode I can change the mode and get picture [I didn't get any sound either, but I forgot to look at my mixer settings and check sound in other applications Argh, that's sloppy testing!! Please ignore this point until I reboot again in 82 beta4] Below is the output from lspcidrake -v -f Best, Narfi agpgart : Intel Corporation|440BX/ZX - 82443BX/ZX Host bridge [BRIDGE_HOST] (vendor:8086 device:7190) unknown : Intel Corporation|440BX/ZX - 82443BX/ZX AGP bridge [BRIDGE_PCI] (vendor:8086 device:7191) unknown : Intel Corporation|82371AB PIIX4 ISA [BRIDGE_ISA] (vendor:8086 device:7110) unknown : Intel Corporation|82371AB PIIX4 IDE [STORAGE_IDE] (vendor:8086 device:7111) usb-uhci: unknown (8086/7112//) [SERIAL_USB] sonypi : Intel Corporation|82371AB PIIX4 ACPI - Bus Master IDE Controller [BRIDGE_OTHER] (vendor:8086 device:7113) bttv: Brooktree Corporation|Bt878 [MULTIMEDIA_VIDEO] (vendor:109e device:036e subv:0070 subd:13eb) btaudio : Brooktree Corporation|Bt878 [MULTIMEDIA_OTHER] (vendor:109e device:0878 subv:0070 subd:13eb) snd-card-ymfpci : Yamaha Corporation|YMF-724F [DS-1 Audio Controller] [MULTIMEDIA_AUDIO] (vendor:1073 device:000d) hptraid : Triones|HPT366 [STORAGE_OTHER] (vendor:1103 device:0004) hptraid : Triones|HPT366 [STORAGE_OTHER] (vendor:1103 device:0004) tulip : Lite-On|LC82C115 PNIC-II [NETWORK_ETHERNET] (vendor:11ad device:c115 subv:11ad subd:c001) Card:ATI Rage 128: ATI|Rage 128 VR AGP 1x/2x [DISPLAY_VGA] (vendor:1002 device:524c subv:1002 subd:0008) unknown : Virtual|Hub [] (vendor: device:)
[Cooker] drakfont: ttmkfdir missing in default install.
8.2 beta4, updated to cooker. When installing truetype fonts, drakfont complains about ttmkfdir missing. The program is of course in the freetype-tools package which does not get installed by default. Here's the standard error from drakfont when I tried to install ArialUnicode.TTF. Note the 4th line: mv: missing file argument Try `mv --help' for more information. cp: cannot stat `*.ttf': No such file or directory sh: /usr/sbin/ttmkfdir: No such file or directory I would expect this to explain why my /usr/X11R6/lib/X11/fonts/drakfont/ttf/fonts.dir file was empty after I had imported my Windows fonts. Installing freetype-tools removed the error message and then /usr/X11R6/lib/fonts/drakfont/ttf/fonts.dir was created. Narfi.
[Cooker] drakfont: Fails on Arialuni.TTF
8.2 beta4, updated to cooker. drakxtools-1.1.7-89mdk As I explained in a separate email, I've installed freetype-tools. When I selected the file Arianuni.TTF using drakfont, I received the following on the standard error: mv: missing file argument Try `mv --help' for more information. font ./LucidaBrightDemiBold.ttf: unknown usWeightClass 6 font ./LucidaBrightDemiItalic.ttf: unknown usWeightClass 6 font ./LucidaBrightItalic.ttf: unknown usWeightClass 5 ... Renaming it to Arialuni.ttf causes it to be installed, it gets mentioned in /usr/X11R6/lib/X11/fonts/drakfont/ttf/fonts.dir but I still can't select it when I'm using anti-aliased fonts in KDE, though. I would need some advice in order to make further experiments about how to make it available for AA. Narfi.
Re: [Cooker] drakfont in current cooker
On Monday 04 March 2002 06:14, dams wrote: [EMAIL PROTECTED] (H. Narfi Stefansson) writes: Did not import Cyberbit.TTF from my windows directory when I chose to import the windows fonts. I then used Advanced-Add and selected Cyberbit.TTF explicitly. Drakfont proceeded to import the font and claimed to have done so successfully. However, a quick inspection of /usr/.../drakfont/ showed that it had not done that. When I renamed Cyberbit.TTF to cyberbit.ttf, I could use Advanced-Add to successfully import the font. which drakxtools pversion? I fixed this in the last package Here's an experiment I ran this morning: rpm -q drakxtools gives drakxtools-1.1.7-89mdk I used drakfont to remove Bitstream Cyberbit from the drakfont/ttf and drakfont/Type1 directories. I then restarted drakfont and used it to import Cyberbit.TTF. It failed. The std. output and std. err are at the bottom of this email as well as type1inst.log On a related note: The file /usr/X11R6/lib/X11/fonts/drakfont/ttf/fonts.dir is empty whereas /usr/X11R6/lib/X11/fonts/drakfont/Type1/fonts.dir is not. Is this the reason why I can't use my imported TTF fonts when I'm using AA in KDE, but I can use them when I'm not using antialiasing? Thanks, Narfi. ### Standard error from drakfont when importing Cyberbit.TTF: mv: missing file argument Try `mv --help' for more information. cp: cannot stat `*.ttf': No such file or directory sh: /usr/sbin/ttmkfdir: No such file or directory mv: cannot stat `*.gsf': No such file or directory mv: cannot stat `*.pfb': No such file or directory mv: cannot stat `*.pfm': No such file or directory mv: cannot stat `*.afm': No such file or directory There are no PostScript fonts in this directory mv: cannot stat `*.pfm': No such file or directory mv: cannot stat `*.gsf': No such file or directory mv: cannot stat `*.afm': No such file or directory mv: cannot stat `*.pfb': No such file or directory chkfontpath: /usr/X11R6/lib/X11/fonts/drakfont/ttf already in list ### Standard output from drakfont when importing Cyberbit.TTF: -- Before installing any fonts, be sure that you have the right to use and install them on your system. -You can install the fonts using the normal way. In rare cases, bogus fonts may hang up your X Server. Install Specifics Fonts... Font to install : /mnt/win_c/windows/fonts/Cyberbit.TTF type1inst Version 0.6.1 (11th February 1998) Copyright (C) 1996-1998 James Macnicol ([EMAIL PROTECTED]) type1inst Version 0.6.1 (11th February 1998) Copyright (C) 1996-1998 James Macnicol ([EMAIL PROTECTED]) There are a total of 209 PostScript fonts in this directory [10] [20] [30] [40] [50] [60] [70] [80] [90] [100] [110] [120] [130] [140] [150] [160] [170] [180] [190] [200] --- 209 fonts found 209 were standard PostScript fonts I skipped 209 of these fonts because they already had overriding entries in both fonts.scale and/or Fontmap (X Windows fonts or Ghostscript fonts respectively). --- While reading the existing fonts.scale file I saw 1 entry which mentioned a filename which now does not exist. Most likely you removed or renamed the file. I ignored these entries. --- While reading the existing Fontmap file I saw 1 entry which mentioned a filename which now does not exist. Most likely you removed or renamed the file. I ignored these entries. --- A log of errors is located in the file type1inst.log retarting xfs.. The End... ## The file /usr/X11R6/lib/X11/fonts/drakfont/Type1/type1inst.log It obviously reflects the fact that I had previously removed Bitstream Cyberbit from drakfont/Type1 using drakfont. type1inst Version 0.6.1 (11th February 1998) Copyright (C) 1996-1998 James Macnicol ([EMAIL PROTECTED]) Run started at Mon Mar 4 07:36:33 CST 2002 Reading fonts.scale Removed fonts.scale entry cyberbit.pfb -bitstream-bitstream cyberbit-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific since the file did not exist Done. Reading Fontmap Removed Fontmap entry /BitstreamCyberbit-Roman (cyberbit.pfb) ; since the file did not exist Done. Writing fonts.scale Done. Writing Fontmap Done.
[Cooker] Drakfont imported fonts fonts missing when using AA
I'm running cooker, updated 1 hour ago I added Arial Unicode MS and Bitstream Cyberbit, among others, using drakfont and I can use those fonts when I am not using antialiasing in KDE When I switch to AA in KDE, these fonts are not available This is not the case in 81, I'm writing this in KDE in 81 using AA and Arial Unicode, it looks just beautiful I have of course no idea where the problem lies, so please ask for more info if you need it, Narfi ps In cooker, my /usr/X11R6/lib/X11/fonts/drakfont/ttf/fontsdir is empty Is that normal?
Re: [Cooker] XFree86 localization KDE crash (was: Re: KDE crashes in current cooker)
On Wednesday 27 February 2002 19:11, Pixel wrote: H. Narfi Stefansson [EMAIL PROTECTED] writes: Gentlemen: I believe I have seen a part of the reason why X/KDE crashes under the Japanese locale. I'll put my findings below our previous emails to the list. this may help: --=-=-= Name: xinitrc Relocations: (not relocateable) Version : 2.4.4 Vendor: MandrakeSoft Release : 60mdk Build Date: Wed Feb 27 17:34:09 2002 --=-=-= Unfortunately it does not solve this last crash right after reading /usr/X11R6/lib/X11/locale/locale.dir (1) and /usr/X11R6/lib/X11/locale/locale.alias (2) if I remember correctly. Anyway, I think it's better for me to test other things until somebody else has looked at the Japanese setup in XFree86 and either confirmed or denied that it is suspect. To recall, I made changes to /usr/X11R6/lib/X11/locale/Compose.dir (3) and /usr/X11R6/lib/X11/locale/ja/Compose (4) and was thereby able to get KDE running under Japanese locale, as long as the XIM* variables are unset. If they are set, KDE still crashes right after reading (1) and (2). More exactly: nspulginscan crashes after reading (1) and (2) and then ksmserver crashes after reading (1) and (2) and xinit halts. straces from yesterdays cooker are available if anybody is interested. Feel free to ask if you need any more info, Narfi.
[Cooker] Japanese packages missing in 8.2b3
These packages are missing in 82b3, due to space constraints I presume I would really appreciate it if somebody could confirm that they will indeed ship with 82 final and that they will be installed if Japanese is selected as a primary or secondary language during the installation If they will also be included in RC1, then that's even better :-) kinput2-wnn4 FreeWnn kde-i18n-ja man-pages-ja Thanks, Narfi
[Cooker] weird version numbers in rpmdrake
Am I the only one that sees version numbers such as 3000:245 when I update my cooker system using rpmdrake? I put a screenshot of rpmdrake up at http://wwwcswiscedu/~narfi/rpmdrakepng where the following version numbers are shown: cdrecord3:111-0a151mdk kdevelop3:202-9mdk with version 3:202-8mdk installed kdebase-devel 1:222-62mdk with version 1:222-59mdk installed kdebase 1222-62mdk with version 1:222-59mdk installed Of course rpm -q on the command line does not report any such odd version numbers Narfi
[Cooker] XFree86 localization KDE crash (was: Re: KDE crashes in current cooker)
Gentlemen: I believe I have seen a part of the reason why X/KDE crashes under the Japanese locale. I'll put my findings below our previous emails to the list. On Saturday 23 February 2002 14:02, David BAUDENS wrote: On Saturday 23 February 2002 04:39, you wrote: Platform: 8.2 beta3, updated to cooker at 8pm central time from sunet. Use /usr/sbin/localedrake to change the language to Japanese-EUC or Japanese-UTF-8. Log out and back in again. Start KDE with xinit /usr/bin/startkde -- :0 and bingo - crash. I selected English as the primary language during install, Japanese, Icelandic and German as secondary languages. I also installed kinput2 and FreeWnn from cooker so that I could possibly type in some Japanese! I put straces up at http://www.cs.wisc.edu/~narfi/xinit.en_US.out http://www.cs.wisc.edu/~narfi/xinit.ja.EUC.out http://www.cs.wisc.edu/~narfi/xinit.ja.UTF-8.out Maybe they well you something more than they tell me! The first strace there only for reference. Of course KDE did not crash with the locale set to en_US. Don't hesitate to ask if you have any further questions/comments. .xsession-errors please. Thanks for the report. Instead of starting KDE with xinit /usr/bin/startkde -- :0, I copied /usr/bin/startkde to ~/startkde and added strace-calls all over the place and started KDE as: xinit ~/startkde -- :0 This made me go through realizing and trying the following: 1) Crash occurred right after reading /usr/X11R6/lib/X11/locale/compose.dir and a brief inspection of that file showed that the lines for Japanese were commented out. I uncommented them. 2) On the next startup, KDE crashed right after not finding /usr/X11R6/lib/X11/locale/ja/Compose. That file only contains comments in 8.1, so I just copied it from my 8.1 partition to my cooker partition. 3) On the next startup, KDE crashes right after reading /usr/X11R6/lib/X11/locale/locale.alias 4) Now, if I issue the following commands on the console, right before invoking xinit, I can avoid the crash in 3): /bin/rm ~/.i18n unset XIM XMODIFIERS LANGUAGE ENC XIM_PROGRAM unset LC_MESSAGES LC_TIME LC_NUMERIC LC_CTYPE LC_MONETARY LC_COLLATE export LC_ALL=ja export LANG=ja xinit ~/startkde -- :0 Then I kde starts and it seems to work. However, if I run the following commands at the console and then start KDE, it crashes upon invokation at the same point as in 3): export XIM=kinput2; export XMODIFIERS=@im=kinput2; export XIM_PROGRAM=kinput2 xinit ~/startkde -- :0 As the situation is right now, I find the localization of XFree86 for Japanese quite suspect and this may put the KDE setup in the clear. That is of course eventually for you guys to decide. Best, Narfi.
Re: [Cooker] KDE crashes in current cooker
On Saturday 23 February 2002 14:02, you wrote: On Saturday 23 February 2002 04:39, you wrote: Platform: 8.2 beta3, updated to cooker at 8pm central time from sunet. Use /usr/sbin/localedrake to change the language to Japanese-EUC or Japanese-UTF-8. Log out and back in again. Start KDE with xinit /usr/bin/startkde -- :0 and bingo - crash. I selected English as the primary language during install, Japanese, Icelandic and German as secondary languages. I also installed kinput2 and FreeWnn from cooker so that I could possibly type in some Japanese! I put straces up at http://www.cs.wisc.edu/~narfi/xinit.en_US.out http://www.cs.wisc.edu/~narfi/xinit.ja.EUC.out http://www.cs.wisc.edu/~narfi/xinit.ja.UTF-8.out Maybe they well you something more than they tell me! The first strace there only for reference. Of course KDE did not crash with the locale set to en_US. Don't hesitate to ask if you have any further questions/comments. .xsession-errors please. Thanks for the report. I first updated to the latest cooker. Localedrake has changed its names for the locales, they are now called Japanese and Japanese UTF-8. I ran kde from init level 3 using the regular xinit /usr/bin/startkde -- :0 2 xinit.locale.errors in the locales en_US, ja and ja_JP.UTF-8 Those files are at: http://www.cs.wisc.edu/~narfi/xinit.en_US.errors http://www.cs.wisc.edu/~narfi/xinit.ja.errors http://www.cs.wisc.edu/~narfi/xinit.ja_JP.UTF-8.errors and then I ran kde from init level 5 and copied the .xsession-errors files for these same 3 locales: http://www.cs.wisc.edu/~narfi/xsession-errors.en_US http://www.cs.wisc.edu/~narfi/xsession-errors.ja http://www.cs.wisc.edu/~narfi/xsession-errors.ja_JP.UTF-8 Just in case you are wondering: The Japanese message in these files means segmentation fault. Now I've learnt one more phrase in Japanese, a lot more to go :-) Narfi.
[Cooker] Cooker: ghostscript 6.53 fails on sample gs files
I'm running a fully Cooker-ized 8.2 beta3. Updated at 8pm central time from sunet. Here's the crux of the problem: ghostscript fails on these sample files: /usr/share/ghostscript/6.53/examples/cjk/*.ps These are all files which use the new CID-keyed fonts. They are for all 3 languages: Chinese, Japanese and Korean. I have other sample files myself which work really well on my 8.1 system (after I had fixed a bug in the gs/vflib setup) but fail on gs 6.53 in cooker. Just ask if you want one. setup: 8.2 beta3, English as the primary language, Japanese, Icelandic and German as secondary languages. Has now been updated to cooker. Feel free to ask if you have any questions, Narfi.
[Cooker] KDE crashes in current cooker
Platform: 8.2 beta3, updated to cooker at 8pm central time from sunet. Use /usr/sbin/localedrake to change the language to Japanese-EUC or Japanese-UTF-8. Log out and back in again. Start KDE with xinit /usr/bin/startkde -- :0 and bingo - crash. I selected English as the primary language during install, Japanese, Icelandic and German as secondary languages. I also installed kinput2 and FreeWnn from cooker so that I could possibly type in some Japanese! I put straces up at http://www.cs.wisc.edu/~narfi/xinit.en_US.out http://www.cs.wisc.edu/~narfi/xinit.ja.EUC.out http://www.cs.wisc.edu/~narfi/xinit.ja.UTF-8.out Maybe they well you something more than they tell me! The first strace there only for reference. Of course KDE did not crash with the locale set to en_US. Don't hesitate to ask if you have any further questions/comments. Narfi.
[Cooker] 8.2b3: Qt maintainers: Qt(konqueror) and Japanese.
Summary: Konqueror fails to create valid PostScript files for Japanese in 8.2 beta3. My explanation: Qt is missing a patch. Pointer to patch below. This same bug is present in 8.1. How to solve this problem: Here is my explanation: Qt-2.3.1 has a printing problem due to a gcc 2.96 bug. This bug is present in 8.1 and requires people to patch and recompile their Qt if they want to be able to print Japanese from Qt programs on their 8.1 systems. I am confident this same bug is causing trouble in 8.2 beta3 since I cannot see this patch in the changelog in the spec file for qt. Qt maintainers: Please have a look at at the patches provided by the Japanese KDE users group. They have a total of 6 patches to Qt 2.3.1, one of them for the printing problem. Please evaluate the others as well. http://www.kde.gr.jp/patch/ Thanks, Narfi. [This is not my patch. I have nothing to do with the Japanese KDE users group.] How I arrived at this conclusion: In my last email, I stated that printing http://www.asahi.com to file in Mozilla created a postscript file that could not be viewed in gv. I now tried to do the same with konqueror and the viewing failed in gv on 8.2 beta3 with the same error messages from VFlib. No surprises there. However, I moved those 2 postscript files (one created in Mozilla, one created in Konqueror) to my 8.1 which I have hacked to provide proper Japanese setup. Viewing these files there showed: The mozilla postscript file was displayed properly under 8.1 which confirms my suspicion in my previous email that VFlib is broken in 8.2 beta3. The konqueror postscript file was not displayed properly under 8.1. This means that there are more things wrong on 8.2 beta3 than just the VFlib setup. The whole thing looks the same way my 8.1 box did before I patched Qt as described above.
Re: [Cooker] Japanese fails in 8.2b3
8.2, beta 3. Three issues: 1) kinput2 and freewnn are still missing from the CDs. 2) Printing Japanese still fails. VFlib seems to be at fault. 3) KDE now crashes under Japanese locale. Changing /usr/share/ghostscript/6.52/vflib/kconfig.ps in the following manner solves problem 2 for me: # diff kconfig.ps kconfig.ps.org 28,29c28,29 /Ryumin-Light 430 (min) VFlibkanji /GothicBBB-Medium 4300200 (goth) VFlibkanji --- /Ryumin-Light 430 (r-kochi-mincho)VFlibkanji /GothicBBB-Medium 4300200 (r-kochi-gothic)VFlibkanji This change was suggested to me by Xiaoming as a solution to the same problem in 8.1. Can it be incorporated into the distribution this time? It's shameful to release with the same bug twice! Summary: This change enables me to view and print postscript files containing Japanese characters. Narfi.
[Cooker] Japanese fails in 8.2b3
Summary: 8.2, beta 3. Three issues: 1) kinput2 and freewnn are still missing from the CDs. 2) Printing Japanese still fails. VFlib seems to be at fault. 3) KDE now crashes under Japanese locale. I hope this will be fixed before RC1 so that I can actually start testing the handling of Japanese. Thanks, Narfi. Details: I selected English as the primary language during install with Japanese, Icelandic and German as secondary languages. I set everything up on a clean partition, note in particular that /home is clean. I removed ~/.kde and ~/.DCOP* at regular intervals between my tests. 1) I ran /usr/sbin/localedrake and selected Japanese-EUC and it set up my ~/.i18n file for Japanese. I logged out and logged in again. Localedrake sets kinput2 as the XIM: LANG=ja LC_CTYPE=ja LC_NUMERIC=ja LC_TIME=ja LC_COLLATE=ja LC_MONETARY=ja LC_MESSAGES=ja LC_PAPER=ja LC_NAME=ja LC_ADDRESS=ja LC_TELEPHONE=ja LC_MEASUREMENT=ja LC_IDENTIFICATION=ja LC_ALL= but kinput2 is neither of the 2 CDs. Nor is FreeWnn to be found there. I suspect that both should be installed automatically once Japanese is selected during the installation. [Already reported in incident 14411 on MandrakeExpert on Feb. 13, but obviously still not fixed.] 2) VFlib fails: I used mozilla to go to http://www.asahi.com and it displays the page beautifully. I printed it to file, tried to view the ps file in gv and it failed with this error message: GNU Ghostscript 6.52: VFlib: Cannot open the font `r-kochi-mincho'. [Reported on Mandrakeforum on Feb. 16, but obviously not fixed in b3.] 3) I set the computer to boot into runlevel 3. I ran /usr/sbin/localedrake and selected Japanese-EUC. This set up my locale as shown above. I logged out and in again. Then I started KDE with xinit /usr/bin/startkde -- :0 and it crashed with the following output: [My wife tells me that the Japanese error messages mean segmentation fault. I took the liberty of translating those 2 lines in the output] XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.17-2mdksmp i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Wed Feb 20 20:08:30 2002 (==) Using config file: /etc/X11/XF86Config-4 /usr/bin/startkde: line 91: 3566 [In Japanese: Segmentation fault] /usr/bin/nspluginscan kdeinit: Launched DCOPServer, pid = 3574 result = 0 _KDE_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root DCOP: register 'anonymous-3574' - number of clients is now 1 DCOPServer up and running. DCOP: unregister 'anonymous-3574' kdeinit: Launched KLauncher, pid = 3578 result = 0 DCOP: register 'klauncher' - number of clients is now 1 DCOP: unregister 'klauncher' DCOP: register 'klauncher' - number of clients is now 1 DCOP: register 'anonymous-3578' - number of clients is now 2 DCOP: new daemon klauncher DCOP: unregister 'anonymous-3578' kdeinit: Launched KDED, pid = 3581 result = 0 DCOP: register 'kded' - number of clients is now 1 DCOP: unregister 'kded' DCOP: register 'kded' - number of clients is now 1 DCOP: register 'anonymous-3581' - number of clients is now 2 DCOP: register 'anonymous-3582' - number of clients is now 3 kdeinit: Got EXEC_NEW 'kbuildsycoca' from launcher. DCOP: register 'kbuildsycoca' - number of clients is now 4 kdeinit: PID 3583 terminated. DCOP: unregister 'kbuildsycoca' DCOP: unregister 'anonymous-3582' DCOP aborting call from 'anonymous-3581' to 'kded' DCOP: unregister 'kded' ERROR: KUniqueApplication: DCOP communication error! kdeinit: PID 3581 terminated. kdeinit: opened connection to :0.0 DCOP: unregister 'anonymous-3581' kdeinit: Launched 'kcminit', pid = 3584 result = 0 kdeinit: PID 3584 terminated. kdeinit: Launched 'knotify', pid = 3585 result = 0 DCOP: register 'knotify' - number of clients is now 1 DCOP: register 'anonymous-3585' - number of clients is now 2 DCOP aborting call from 'anonymous-3585' to 'knotify' DCOP: unregister 'knotify' ERROR: KUniqueApplication: DCOP communication error! DCOP: unregister 'anonymous-3585' kdeinit: PID 3585 terminated. /usr/bin/startkde: line 165: 3587 [In Japanese: Segmentation fault] ksmserver --restore waiting for X server to shut down kdeinit: Fatal IO error: client killed kdeinit: sending SIGHUP to children. KLauncher: Exiting on signal 1 DCOP: unregister 'klauncher' kdeinit: sending SIGTERM to children. kdeinit: Exit.
