You are not logged in.
As ck users probably already know, 2.6.18-ck1 is now available, and I'll be building the package this morning. The stock Arch 2.6.18 kernel is in testing, and I would like to know if kernel26ck users want the new release in community now, or whenever stock goes current.
My inclination is to wait, as this package was always intended to be the current stock package plus ck - no more, no less. OTOH, the last 2.6.17-ck update was 3 months ago, so I wouldn't be at all surprised if people want to get their hands on this asap.
Any comments,questions, etc - post them here. I'll make a decision this evening.
Offline
I was thinking about trying out testing 2.6.18 ... but as it loads as kernel26 package it wipes over my custom (working kernel!)
Would it better/possible for testing (ck will be named ...!!) kernel to be named ie kernel26test so I can dual boot them
Maybe wrong place to ask (again!)
No O/T I would like to try ck kernel never had problems using it.... you built it I'll test it lol
Mr Green I like Landuke!
Offline
Would it better/possible for testing (ck will be named ...!!) kernel to be named ie kernel26test so I can dual boot them
That's a question for the devs. Apart from that, it's highly unlikely that testing/kernel26 would break your system - it's up the usual high standards that we've come to expect for Arch kernels.
No O/T I would like to try ck kernel never had problems using it.... you built it I'll test it lol
Thanks. Whether it goes in community today or not, I'll upload it somewhere when it's ready. Watch this space.
Offline
Waiting for stock 2.6.18 release will be reasonable IMO.
BTW im using custom 2.6.18 kernel with -ck patchset included and everything is ok for now. Testing it since yesterday evening - nothing wrong happened.
:: create while you can ::
Offline
I have been using kernel26ck for a long time. I would like an update ASAP, however, for consistency, you should wait until the stock kernel leaves testing.
Offline
@tomk: I have already updated to kernel26suspend2 2.6.18 in community, there is nothing preventing you from doing the same.
Offline
@tomk no dude ... if I can run both I would happier switch between in lilo/grub just my2c
testing kernel sure it will not break my system never said it would lol
Come on get on with it I'm waiting for ck rofl
/me loves tomk very much
Mr Green I like Landuke!
Offline
I'm always looking for new way to destroy my system
Anyway i would like to see it now
Offline
StormBlast - as I'd expect, but good to know anyway. I've been running 2.6.18-rc5-ck1 myself for the last few weeks, and all's well.
Slash - your restraint is admirable - thanks.
brain0 - yes, I know. I'm just getting some user input.
/me loves tomk very much
/me blushes, hides laptop from wife - and Ole Erik.
I'm always looking for new way to destroy my system
Better not use this package then . As mentioned above, it will be available for download somewhere later today. The purpose of this thread is to gauge whether it should go to community before the official 2.6.18 kernel package goes to current.
Offline
does this decision really deserve a thread? it's a simple packager's judgement call tomk, and an easy to resolve one at that.
I say release it.
Take a look on lkml, there's been no real issues with this release, it's looking like a solid release, after all, wasnt this release going to be a little toned back anyway? Another good sign is that Greg KH hasnt posted any candidsate patches for 2.6.18.1, meaning that there werent any missed in 2.6.18, and that there arent many waiting.
The gentoo genpatches, which are primarily fixes, are at a bare bones release for 2.6.18, with all of the fixes from the past releases having been included in 2.6.18.
And as for CK's stability, the CK mailing list has been an absolute ghost town. There's been nobody posting, and no problems. Con himself hasnt done much work on CK, so there's no new code to worry about. The patchset has also been workin fine on the 2.6.18-rc kernels, so it should be sweet.
James
Offline
Good points, iph - thanks.
Despite the apparent stability of 2.6.18, you and your colleagues on the dev team have decided to put the stock kernel in testing first. As a TU, working in the community repo, I don't have access to an equivalent facility. Also, community packages are meant to be in sync with current/extra, not testing.
Does the decision need a thread? No, but it doesn't do any harm either. As you said, it's my call, and I'm not going to update a community package to the equivalent of a testing release without giving users a chance to air their views.
Offline
I am all for releasing it right now (in 'extra', not in 'testing').
Offline
Well... only a dev can put it in extra. I suppose you could post a feature request, and see what happens.
Offline
I am all for releasing it right now (in 'extra', not in 'testing').
I think that the 2.6.18 kernel will remain in testing for a while. Mainly because that version only works with initcpio so the devs probably wants to give time to the users who don't read the news often to switch to initcpio.
Offline
actually the main reason that 2.6.18 is in testing is that tpowa is busy at the moment with exams and doesnt have the time to run around pushing out new releases to fix anything he doesnt know about, or any mistakes he's made.
Snowman: 2.6.18 would work fine with mkinitrd/mkinitramfs, but they're being superseded by mkinitcpio.
James
Offline
Even with his exams, he's been busy - it's up to 2.6.18-4 already. Go tpowa!
Meanwhile, as promised for those of you who just can't wait, here (finally) is kernel26ck 2.6.18.ck1-1, md5sum 6b8add7501f57e1dc4850e2f3d55c652. This package incorporates all amendments to the testing kernel up to 2.6.18-4.
The associated build tarball is here.
Offline
actually the main reason that 2.6.18 is in testing is that tpowa is busy at the moment with exams and doesnt have the time to run around pushing out new releases to fix anything he doesnt know about, or any mistakes he's made.
Snowman: 2.6.18 would work fine with mkinitrd/mkinitramfs, but they're being superseded by mkinitcpio.
James
Thanks for the clarification.
I thought that there was a technical reason to deprecate initrd/initramfs when kernel 2.6.18 came out. But it seems that it's not the case.
Offline
initrd and initramfs worked quite nice, but they had one downside: they require root privileges to build the image and they require ext2 and loopback device support in the kernel to generate the image. With initcpio you can just generate it with some stupid tool. Only thing to take care of: never unpack it as root if you don't know how cpio works, it will overwrite your / with initcpio binaries, which cause your system to fail.
2.6.17 has been the release where both systems were supported, with a big fat warning about initrd/initramfs disappearing for 2.6.18 or sooner. The only support that has been removed is auto-generation of these images on postinstall, for the rest initrd/initramfs would be fine, except for one thing: ext2 support is now modular in 2.6.18, so that wrecks at least initramfs.
Offline
ck ok here dvd drive is showing up good sign ,,,, nvidia will not load do I need a new package or install manually ?
TIA
Mr Green I like Landuke!
Offline
does anyone know if kernel-2.6.18 or kernel-2.6.18.ck1-1 have any issues with the latest wine?
I'm running kernel-2.6.18 and any apps needing wine like dssi and fst segmentation fault.
I would switch to kernel-2.6.17beyond and it all works fine.
I'm afraid to upgrade to kernel-2.6.18.ck1-1 because I rely on those apps.
Offline
Only thing to take care of: never unpack it as root if you don't know how cpio works, it will overwrite your / with initcpio binaries, which cause your system to fail.
Ouch.
Unthinking respect for authority is the greatest enemy of truth.
-Albert Einstein
Offline
Thanks for the clarification.
![]()
I thought that there was a technical reason to deprecate initrd/initramfs when kernel 2.6.18 came out. But it seems that it's not the case.
Well, yeah there is a technical reason - they suck
nobody wants to maintain them, and mkinitcpio works far far far better.
James.
Offline
I've managed to compile ati-fglrx-ck for 2.6.18-ck. Don't forget to modify other necessary parts of PKGBUILD for ck. Happy compiling.
-------------------------
PKGBUILD starting at line 39 add the bolded
-------------------------
else
cp $startdir/src/archive_files/x690/* $startdir/src/ -r
fi
cd $startdir/src/lib/modules/fglrx/
patch -p1 < $startdir/2.6.18.patch || return 1
cd $startdir/src/lib/modules/fglrx/build_mod/
# Build the kernel module
--------------------------
Here's the patch.
--------------------------
2.6.18.patch
--------------------------
diff -ru fglrx.orig/build_mod/firegl_public.c fglrx/build_mod/firegl_public.c
--- fglrx.orig/build_mod/firegl_public.c 2006-06-22 20:30:28.000000000 +0200
+++ fglrx/build_mod/firegl_public.c 2006-08-08 00:59:05.000000000 +0200
@@ -23,6 +23,9 @@
// ============================================================
#include <linux>
+/* jikos hack to make this thing compilable against recent kernels */
+#include <linux>
+#define VM_SHM 0x00000000
#ifdef MODVERSIONS
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,71)
#include <linux>
diff -ru fglrx.orig/build_mod/make.sh fglrx/build_mod/make.sh
--- fglrx.orig/build_mod/make.sh 2006-06-22 20:30:28.000000000 +0200
+++ fglrx/build_mod/make.sh 2006-08-08 00:48:21.000000000 +0200
@@ -223,7 +223,7 @@
kernel_release=`cat $src_file | grep UTS_RELEASE | cut -d'"' -f2`
else
# UTS-define is in external version-*.h files, i.e. linux-2.2.14-5.0-RedHat does this flaw
- kernel_release=`cat $linuxincludes/linux/version-*.h | grep UTS_RELEASE | grep "$OsRelease" | cut -d'"' -f2`
+ kernel_release=`cat $linuxincludes/linux/utsrelease.h | grep UTS_RELEASE | grep "$OsRelease" | cut -d'"' -f2`
fi
fi
Offline
initrd and initramfs worked quite nice, but they had one downside: they require root privileges to build the image and they require ext2 and loopback device support in the kernel to generate the image. With initcpio you can just generate it with some stupid tool. Only thing to take care of: never unpack it as root if you don't know how cpio works, it will overwrite your / with initcpio binaries, which cause your system to fail.
There's a few other upsides too - namely the extensibility so that individual packages can contain early-userspace hooks (i.e. gensplash).
On a side note, I plan on adding image inspection options to mkinitcpio, to prevent users from accidentally overwriting things as JGC mentions. mkinitcpio --inspect /boot/kernel26.img or something
Offline