Posts

重新开始玩synergy

http://www.linux.com/article.pl?sid=06/05/25/1439237 要分享键盘鼠标的机器是server,执行synergys 没有键盘鼠标的是client,执行synergyc serverip 我的配置文件 $ cat /etc/synergy.conf # sample synergy configuration file # # comments begin with the # character and continue to the end of # line. comments may appear anywhere the syntax permits. section: screens # three hosts named: moe, larry, and curly loongson: adriano: end section: links loongson: down = adriano adriano: up = loongson end section: options switchDelay = 500 end

distcc

Distcc is working. Howerver, I didn't get it working at the beginning. Because I am curious about what messages distccd's pass between themselves. So I fired up wireshark, then I go to sleep. As you would expect, eventually wireshark occupied all free space on /tmp which is also used by distcc to produce object files. And as a consequence, distcc failed. Originally, the distcc run with "--log-level critical", so it sent nothing to syslog. By using this command, you can see what distcc is doing in real time: distccd --verbose --log-stderr --daemon --user distcc --allow 192.168.1.103 --no-detach

I will give up cross compiling KDE

Two posts related to this decision: http://zhllg.blogspot.com/2007/03/rfcpossible-improvements-to-with.html http://zhllg.blogspot.com/2007/03/some-ideas-about-dependrdepend.html I will try distcc.

some ideas about DEPEND/RDEPEND

(zhllg) Is it possible that a runtime dependency is not a build time dependency? or could a package be built without some package, but require it in order to run? (igli) yes (zhllg) igli, any example? (igli) not necessarily required at run time; in any case eg an app that runs a cmd (igli) might not need to be built against the other app (zhllg) oh that is true (igli) synfig has run time deps for i think jpeg and stuff (igli) need to work on ebuild.. :( (zhllg) igli, what about the runtime dependency is a library (igli) usu if it's a dep against a lib, it's compile time (marienz) both. (igli) depends on whether it looks for the .h files (marienz) normally both. (igli) oh sorry, yes runtime as well of course (igli) as lib needed on system when app is running :) doh! (zhllg) then IMHO maybe in that case just specify the dependency in RDEPEND is enough, what do you think? (marienz) you normally need the lib present at build time or the link will fail. (zhllg) yes (igli) yup (igli)

[RFC]possible improvements to --with-sysroot

The following suggestion is based on my understanding of --with-sysroot, if there were any error, please correct me. To my understanding, currently if cross-compile tool chain (including gcc) is configured with --with-sysroot when installing them, then when cross compiling, ld will look for libraries in $SYSROOT/usr/lib and $SYSROOT/usr/local/lib. Wouldn't it be great that we go one step further that we let ld look for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf, we prefix $SYSROOT to it. Comments are welcomed. Thanks! -- Zhang Le, Robert This is an email I have posted to gcc mailing list.

emerging KDE on loongson

I have got DRI working in Gentoo on loongson. mesa/libdrm/kernel/xorg-server/xf86-video-ati need to be patched in order to achieve this. I have set up a loongson overlay, including the necessary patches. Get it here: http://gentoo.linuxsir.org/download/loongson-overlay.tar.bz2

kgdb and 64bit loongson kernel

The kernel crashed at last. But it didn't drop into gdb. I have set up a breakpoint at panic(), so it is not a panic. My speculation proved wrong, and I have no idea what went wrong here. I will give up for the time being. Gotta read some books and help to make the 32bit loongson port stable.

gorg on loongson box

I have successfully run gorg on my loongson box. Find more info about gorg here: http://gentoo.neysx.org/mystuff/gorg/gorg.xml more info about loongson here: http://en.wikipedia.org/wiki/Loongson

kgdb

最近在玩kgdb 似乎人们对于kgdb的热情不高 现在sf.net上cvs里的kgdb只能打在2.6.17内核上 目前的龙芯用的是2.6.18.1,好在要改动的地方不是很多,也不难 kgdb管理补丁用的是quilt,稍微看看man就明白了,用起来很方便 其实vanilla 2.6.18.1里也有一个kgdb选项,但实际上似乎是不能用的,连个断点都设置不了 之前我编的内核有两个问题,一个是网络传输速度慢,scp的时候经常断,如果用debian,速度恒定保持在2.x M/s,一个是字符界面在显示器上显示不出,显示器报告超出范围,debian里正常。我之前用的是从dev.lemote.com里checkout出来的内核代码里面自带的配置文件,稍做了改动。后来我用了debian的/proc/config.gz,就好了。可是我对比两个config也没看出有什么差异可以导致这两个问题。目前还是一个谜。 最后玩kgdb光靠串口来控制还是不行,现在continue之后,gdb里显示到free多少多少memory之后,就没有任何信息了,但是在显示器上可以看到实际上已经成功启动了。 kgdb真的很爽,如果想让目标机器的内核停止运行,并等待被开发机器上的gdb连接和控制,只需要在开发机器上执行 echo -e "\003" > /dev/ttyS1

gentoo's mips toolchain

Gentoo's mips64el toolchain(created by 'crossdev') support n32 by default. However, I want o32. Good news is I don't need mips64el, instead I need mipsel. Thanks to spbecker for pointing it out to me. I think mips64 here is the name of processor architecture. Apparently loongson doesn't belong to that category.

按音序排序的utf8和gb18030 locale

https://gro.clinux.org/frs/download.php/1962/locale-pinyin-0.1.tar.gz 下载后,解压缩 cd locale-pinyin-0.1 make sudo cp zh_CN.hacked /usr/share/i18n/locales/zh_CN sudo cp iso14651_t1.pinyin /usr/share/i18n/locales/ locale-gen 修改/etc/env.d/xxi18n,如果LANG不是zh_CN.utf8,一定要单独设定LC_COLLATE  $ cat /etc/env.d/100i18n LANGUAGE=en_US LC_CTYPE=zh_CN.utf8 LC_COLLATE=zh_CN.utf8 LANG=en_US.utf8

the difference between GB18030 charmap of redhat's glibc and that of GNU's glibc

GB18030 charmap of redhat's glibc is different from that of GNU's glibc. I don't know exactly what this difference means to users. But I wonder why this difference exists. Get the former at http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/localedata/charmaps/?cvsroot=glibc Get the latter at http://www.gnu.org/software/libc/resources.html#projectweb I've created a diff which could be get here: http://robert.zhangle.googlepages.com/diff

be careful when you are on #paludis

In my opinion, a good community should treat new comers well. But some people think otherwise. http://www.gentoo.org/news/en/gwn/20061002-newsletter.xml#doc_chap3 (zhllg) i think many people like the idea installation could resume automatically when failure occur, is it possible with paludis? (mlangc) zhllg: http://www.paludis.org/faq.html#skipfirst  mlangc maskd masterdriverz maxauthority midnite__ mzli  mlangc maskd masterdriverz maxauthority midnite__ mzli (zhllg) mlangc, i've seen that actually, just wonder why, is it difficult to implement technically? (mlangc) i don't think so; as far as i know it is not implemented by __design__ - but you should better ask someone that actually works on paludis; i'm a simple user myself (rbrown`) zhllg: er no. Too unreliable, too flaky and far too widely abused; (zlin) zhllg: wouldn't it be much better to fix the packages that cause it to fail in the first place... (zhllg) zlin, yeah, from a developer's perspective * dleverto