XRP Ninja

Update: It is said that this problem has already been fixed . I will test it later. Actually I intended to send this to LKML, but just before I was about to send I found there was already some discussions about this . So instead I decided to just post it here. To make long story short, please take a look at these two files first: The first file , which will become part of /usr/include/endian.h. This file defines both __LITTLE_ENDIAN and __BIG_ENDIAN. And this file will be included by the second file. The second file , which will be /usr/include/linux/byteorder.h Obviously, this test in the second file will fail: #if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN) # error Fix asm/byteorder.h to define one endianness #endif It seems that there is an inconsistency between Linux and glibc on handling __LITTLE_ENDIAN and __BIG_ENDIAN. Linux treats them like a flag, while glibc treats them like a value. glibc uses __BYTE_ORDER to determine the endianness. This problem must be...

I got a donation of a Lemote Loongson 2F box somewhere around July this year and have been working on it in my spare time since I got it. The other day I made a summary about what I have done so far and posted it on Lemote's bbs. The links is http://www.lemote.com/bbs/viewthread.php?tid=20134 My work involves toolchain, kernel, xorg-server MIPS or Loongson support and userland library/application gcc 4.4 patch. The most prominent achievement so far is an N32 ABI stage3 (well, actually just a tarball, not made using catalyst) optimized for Loongson 2F with MIPS PLT support. It is actually not that easy as you would've imagined, N32 has many problems as you can see from the above posted link. I posted it on Lemote's bbs along with some instructions of how to use it: http://www.lemote.com/bbs/viewthread.php?tid=20125 According to some testers, performance of some applications in this system has an up to 30% increase comparing with the performance of the same apps in system Usi...

Background: http://ciaranm.wordpress.com/2008/09/28/eapi-2-src_uri-arrows/ Today I found arrows in SRC_URI is not working in my box, so I took a look at the code, found something, and sent this: http://www.nabble.com/a-little-patch-related-to-arrow-in-SRC_URI-td20732745.html However, as Zac pointed out, the better solution is not to define your own fetch and resume command but rely on the default one. The default ones are defined in /etc/make.globals: FETCHCOMMAND="/usr/bin/wget -t 5 -T 60 --passive-ftp -O \"\${DISTDIR}/\${FILE}\" \"\${URI}\"" RESUMECOMMAND="/usr/bin/wget -c -t 5 -T 60 --passive-ftp -O \"\${DISTDIR}/\${FILE}\" \"\${URI}\"" The rules of thumb is to make sure you save the file at ${DISTDIR}/${FILE}, since FILE is just the file name, doesn't include path. Previously I have fetch and resume command defined in make.conf, and have used "-P ${DISTDIR}" instead of "-O ${DISTDIR}/${FILE}". Maybe...

I have reported on gcc mailing list. http://gcc.gnu.org/ml/gcc/2008-11/msg00076.html Also I found the solution: http://gcc.gnu.org/ml/gcc/2008-11/msg00087.html Now I have built gcc-4.4 with my modified patch with "-march=mips3", and am building itself again using "-march=loongson2f". Note that enabling -O2 in later stages is not working yet. Please check this bug report for more information if you are interested: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38052 EDIT: just heard from Kumba, this flag used together with -O1 will trigger this bug: -foptimize-sibling-calls Optimize sibling and tail recursive calls. Enabled at levels -O2, -O3, -Os. The modified gcc 4.4 ebuild is here and some relevant libraries here .

http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00273.html I have put it in my loongson overlay . BTW, the gcc svn ebuild is from dirtyepic's overlay. Thanks, ;) zhangle@2f ~ $ cat hello.c #include<stdio.h> int mul(){ unsigned long a = 0xffffffff; unsigned long b = 0xf; return a * b; } zhangle@2f ~ $ gcc -march=loongson2f hello.c -S zhangle@2f ~ $ gcc -march=mips3 hello.c -S -o hello-mips3.s zhangle@2f ~ $ diff -u hello.s hello-mips3.s --- hello.s 2008-11-08 18:16:52.000000000 +0800 +++ hello-mips3.s 2008-11-08 18:16:55.000000000 +0800 @@ -25,7 +25,8 @@ sw $2,8($fp) lw $3,12($fp) lw $2,8($fp) - multu.g $2,$3,$2 + mult $3,$2 + mflo $2 move $sp,$fp lw $fp,20($sp) addiu $sp,$sp,24

distcc's got zeroconf support That is cool! However, there are problems (althouth not everyone got these problems). One of them is that if you have multiple version of gcc's or even cross compilers, distcc clients can't discover them, since distccd will only register your current active gcc. And if you want to change your native compiler's version, you must restart distccd in order to let it take effect. Having multiple gcc's may not be common in other distribution, but this is common in gentoo. This is what I have on my x86 notebook: gcc-config -l [1] i686-pc-linux-gnu-4.3.1 * [2] mipsel-unknown-linux-gnu-4.3.0-alpha20080731 [3] mipsel-unknown-linux-gnu-4.3.1 [4] mipsel-unknown-linux-gnu-4.4.0-alpha20080718 * [5] mipsel-unknown-linux-gnu-4.4.0-alpha20080801 [6] powerpc-unknown-linux-gnu-4.2.3 * So I made a little patch: https://bugs.gentoo.org/show_bug.cgi?id=233843 Hope there will be a distcc-2.18.3-r14 or distcc-3.0_rc4 in tree soon, ;)

It makes me very uncomfortable that awstat-6.7-r2 in tree does not have support for Gentoo So I made a little patch and a little icon. http://tinyurl.com/5dj2x3 I have already tested it on www.gentoo-cn.org . It works. Hope upstream would accept it soon.

Maybe I am not the right person to write about it. But I felt the necessity to write about it. So I will just write something about preserve-libs, leaving other FEATURES to more competent people. Portage-2.2 has already entered unstable tree. Many people has started using it. It has many new features, like preserve-libs, sets, license filter and so on. Please check README and RELEASE-NOTES for a complete list. I will only talk about preserve-libs. To understand why we need it, we have to know some background information. First of all, applications are not built from scratch. Any non trivial apps use lot of libraries. In GNU/Linux, most of them are shared libraries, i.e. .so files. You can use `ldd /usr/bin/mplayer` to check what shared libraries an app has been linked to, replace mplayer to whatever program you'd like to check. Shared libraries have versions. E.g. /usr/lib/libavformat.so.51, here 51 denotes its version. After upgrading, the version number may change. E.g. /usr/lib/...

1. Documentation get updates regularly as usual. http://www.gentoo-cn.org/gitweb/?p=gentoo-cn;a=summary 2. Our table now can distinguish between file owner and file last updater when the file in question need to be updated. If the last updater is the owner, there will be an email link on the name; otherwise, there will be no link, but the name will be in red. The name is in the last column. http://www.gentoo-cn.org/trads/ http://rubyurl.com/0BD4 3. I will get my loongson 2f box soon, :-D 4. Just fixed an as-needed problem: http://bugs.gentoo.org/show_bug.cgi?id=225117 http://www.gentoo.org/proj/en/qa/asneeded.xml

Although I don't know the direct cause of council's decision this time, it reminds me of an old story. http://r0bertz.blogspot.com/2007/01/be-careful-when-you-are-on-paludis.html Quote some Diego's words: Don’t think we woke up this morning and decided to get rid of any developer. We considered this for a quite long time. Over all, I think the decision was took after a too long time. You can criticise, you can joke, but if the people you joke upon don’t laugh with you at the joke, then apologise and stop it!

1. Gcc's support for loongson is coming: http://gcc.gnu.org/ml/gcc/2008-04/msg00551.html 2. Lemote Loongson 2F box's release has been postponed to June 30. http://202.201.0.147/Html/inner/2008-4/11/201803589.html For those who want to order 2F box: I have talked to 2F box's product manager, he recommended sending email to sales@lemote.com directly. That's it, ;) PS: Lemote has Loongson laptop, too.

Releases: http://mirror.mcs.anl.gov/pub/gentoo/releases/x86/2008.0_beta1 Handbooks: http://www.gentoo.org/doc/zh_cn/handbook/handbook-x86.xml http://www.gentoo-cn.org/gitweb/?p=gentoo-cn;a=summary http://cia.vc/stats/author/r0bertz Enjoy!

EDIT: updated link in this article. ssh-add can let your ssh-agent remember the passphrase of your ssh secret key, so that you don't need to type any password when loging into a remote machine. However, it is an interactive program, you can't call it in a cron job. Even if you can, you will expose your passphrase in a file, which is not safe. The solution is actually very easy. You don't really need to ssh-add. All you need to do is letting ssh know some environment variable. First of all, I recommend you set up ssh-agent forwarding with GNU screen following instruction here: http://www.deadman.org/sshscreen.php Then in your cron job script, source ${HOME}/bin/fixssh first. Done! Enjoy ;)

http://www.gentoo-cn.org/trads/ http://www.gentoo-cn.org/doc/zh_cn/handbook/draft/ http://www.gentoo-cn.org/doc/zh_cn/handbook/2008.0/ http://www.gentoo-cn.org/gitweb/?p=gentoo-cn;a=shortlog Not too much work to do actually. First I copied current handbook and 2007.0 networkless handbook. Then wrote a little script to update version number and date and change all occurrences of 2007.0 to 2008.0 automatically. Then made a diff between old and new English handbook. Then modify old handbook according to the diff of English version. Done ;)

I put it on my gentoo-cn.org: http://www.gentoo-cn.org/trads I have done some modification to neysx's trads script. And I have written a new perl script which could generate a totally new trads.xml (think it like a config file to trads) from scratch. I am using git as version control software. The gitweb page is here: http://www.gentoo-cn.org/gitweb/?p=trads;a=summary The gen_trads_xml.pl script is here: http://www.gentoo-cn.org/gitweb/?p=trads;a=tree;f=xml

First of all, thanks to neysx and his excellent tool . Also thanks to Simone Li for translating the original French template to English. Actually, it is not finished yet. I have to finish translating the page to Chinese, then write a script to auto update trads.xml which records the priority, translated version, current version of each doc. Anyway if you want to take a preview, the URL is here: http://dev.gentoo.org/~r0bertz/trads-zh_cn.xml Notice: don't be fooled, :) Although the current list on the above page is almost empty, we have actually translated a lot of docs into Chinese, especially the whole handbook, ;) So, check it out: http://www.gentoo.org/doc/zh_cn/list.xml

I have written a live binutils ebuild. It is now in my loongson overlay. I wrote it because binutils cvs already got loongson 2e and 2f support, but new version is not released yet. The ebuild itself is quite simple, thanks to cvs.eclass and toolchain.eclass. However, in order to make it really work, I have to modify cvs.eclass. The reason is: The checked out directory name of binutils is called "src". While cvs.eclass expects the checked out directory name is the same as the package name, i.e. "binutils". Unfortunately, "co -d binutils binutils" doesn't work. If I use "co -d binutils binutils", I can only checked out the "binutils" directory, while the actual binutils module contains more than that. So, the most straight forward way to solve this would be to "mv src binutils" after checking it out, and this was exactly what I did. I need a new variable name to hold "src". I call it ECVS_CO_DIR. Some other things...

Recently I have tried sharing /usr/portage among several boxes via NFS after I've read http://www.gentoo.org/proj/en/portage/doc/faq.xml. I followed portage's manpage, created /etc/portage/modules on nfs client $ cat /etc/portage/modules portdbapi.auxdbmodule = cache.metadata_overlay.database And removed all cache files under /var/cache/edb/dep/usr/portage So that I don't need to run emerge --metadata on nfs client after emerge --sync. It is not over yet for eix users. If you have a $HOME/.eixrc and defines in it PORTDIR_CACHE_METHOD as something like "portage-2.1"/"cdb"/"sqlite"(check man eix), you may want to remove the ~/.eixrc file. Since those methods requires you to run emerge --metadata before update-eix, and thus defeat our purpose in the first place.