Hi Dmitry,
One way to work around the next emerge sync problem and be able to use your personal tarball is to copy the kernel 2.5.66 ebuild to your PORTDIR_OVERLAY directory.
To do so:
- Uncomment and set the PORTDIR_OVERLAY in your /etc/make.conf file.
- Copy the kernel ebuild to /usr/local/portage/sys-kernel/development-sources/ directory. You may need the ChangeLog file, i'm not sure
- emerge development-sources-2.5.66; it will tell you how to generate the digest file (something like ebuild development-sources-2.5.66 digest). Do it.
- emerge development-sources-2.5.66
I did not test this directly with the development kernel, but it's a way that I use to bypass the masked packages that I want on my stable machine (actually one of them).
I personnally have tried to compile the 2.5.66 kernel, but get stuck while compiling the fbdev stuff for the voodoo3 and a cirrus on-board adapter, on a good old P200MMX. I will try to remove these components when I will find some time.
Max
Dmitry wrote:
At first thanks for reply, Dave :)
MD5 sums will tell you with whether the files match with a very high sensitivity to any change.
I fully understand that. :)
Odds are that there are mild differences between your patched tree and the official kernel.org tarball for the kernel.
But why my patched tree have do be different from kernel.org tarball? I thought that patches bring the source EXACTLY the same through different versions - that's all its about. If they aren't, then I would expect troubles on compiling and such. Maybe i thought wrong? )
I can agree that MD5 sums may differ from one bzip2 compression level to another. :) But as for patches - i'm not quite sure. Please explain me, if you don't mind :).
I believe portage tells you what to do to correct the MD5
Yes, it told me to remove linux-2.5.66 and replace it with right one :). I.e. - download right one. :) I have only one problem with that - THE 56K MODEM :). I'm in Russia, you know :). We don't have Internet services well adopted to people - but i beleive that we will in near future. :) At least all goes on to this :). But price for even ISDN connection is too expecive for me at the moment. :( I'm a student and don't have much money to spend :). But that seems to be my own problem, yeah? )) So let's leave it :))).
Sounds like a timezone problem or GMT RTC problem. Check into /etc/localtime:
ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 2002-09-19 14:38 /etc/localtime -> /usr/share/zoneinfo/US/Central
Checked this out - it's all right with this file - it points to my timezone "/usr/share/Europe/Moscow"
Btw, when I rebooted with stable kernel, first thing that i've done -- set the correct time and date. But when I rebooted again (stable) i got again the April 6!!! :( So I think that's not a kernel bug :). I will look in config files, but not quite sure what it can be :).
Also look at what you have for your kernel config under General, there is an option there for "RTC stores time in GMT"
That option is not set - i'm sure. I already know about it :).
Since you mentioned it, is there any particular reason you are running unstable kernels? I've tended to avoid anything but release candidates/stable for machines I care about (heck, I only recently started compiling my kernel with gcc 3.x!). If you are just looking to play, it would be far safer to do so in UML or a virtualizer such as VMWare or bochs. Sure you won't get a feel for speed improvements, but you aren't risking your data on unstable I/O developments. Just a friendly suggestion... <remembers the umount sync fiasco... and that was on "stable" kernels!>
Just wanted to give it a try :). And to look at the UNSTABLE kernel - since i was never tried it before. :). Just interesting :). Another reason - I have Nvidia Nforce2 chipset on my MB and it is not supported by last stable kernel :(.
And another reason - someone in list a few days ago told that's not enough people in linux community that would agree to test new kernel and that's why its development goes slowly ;). I'd like to help, so i decided at least to try to help :).
Truly, I expected MUCH more problems with unstable kernel - I even thought that it can crush at once as i run it :). But maybe my current problems are only at the begining :)))
Just don't know yet what would I do - solve this problems and stay with unstable kernel, or move to old, but proven good one? :) What would anyone suggest? :)
Thanks anyway. :)
Best regards, Dmitry.
-- [EMAIL PROTECTED] mailing list
-- [EMAIL PROTECTED] mailing list
