There's an error in the package build in community. I believe iphitus knows about it and I assume it will be resolved soon. There is some mention of it on the forums as well. He based his pkgbuild on the official kernel26 pkgbuild changing just what needed to be changed to get the kernel to build. He forgot to change the maintainer line, left mkinitrd in the depends even though the package uses mkinitramfs instead, and changed the replaces line so it replaces kernel26 but removed the -scsi from the end of it as the original pkgbuild had. That last one makes no sense to me. Anyway I'm sure he'll work the bugs out of it soon. He's just taken over the duties of maintaining the community packages so there are bound to be a few problems at first.
-- -andy [EMAIL PROTECTED] gpg key: http://home.comcast.net/~phydeaux37/phy_pub_key.txt Attila wrote: > Hi, > > at first the archck kernel is a nice option and i respect the work for it very > much. > > I have [community] in my pacman.conf active and so i recognize at the last > sync with pacman and abs that the new PKBUILD have judd as maintainer and a > replaces line for the currnet kernel26. So my question is will arch switch to > the archck kernel? > > If it is not too late i suggest to stay as it is: kernel26 in current and > kernel26archck as an option because mkinitrd can make img's for other kernels > too. > > The current kernel26 runs very smooth and since the ck kernels have this swap > prefetch feature i wasn't overzealously as i was before. Here it swaps after > my fancy too early and the kernel26 use my 1GB ram in the way that i await. > > Before i get hints to solve this, i have at last after a lot of experiments > this in my rc.local for my last custom ck kernel > > if [ $(uname -r) = "2.6.15-ck1" ]; then > echo 100 > /proc/sys/vm/mapped # avoiding swap > echo 0 > /proc/sys/vm/swap_prefetch # disable it > fi > > to disable all but i still again get situations where about 200MB ram and more > than 300MB swap is used. For me this is a mismatch that swap is used i such a > situation and the current kernel26 didn't do this. > > This described thing is my problem and i have to solve it for myself but my > purpose is another thing: If it is not too late to suggest something let the > current kernel26 survive. > > See you, Attila > > > _______________________________________________ > arch mailing list > [email protected] > http://www.archlinux.org/mailman/listinfo/arch > _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
