[gentoo-dev] SuSE Kernel Sources

[gentoo-dev] SuSE Kernel Sources

[Paul Varner]

All:

It was suggested to me that I post this here so that all of you nice
developers could take a look if interested.  Anyhow, I posted this earlier
to the gentoo-user email list as well as the Other things Gentoo forum.
What follows is my original message.

Regards,
Paul

> Being a big fan of SuSE before coming to Gentoo, I was interested to
> note that gentoo had RedHat kernel sources, but not SuSE sources.
> Since I have always preferred the stability of the SuSE kernel over
> RedHat's [I know it's a subjective opinion, so no comments please :)
> ] I decided to rectify the situation and create an ebuild for the
> SuSE kernel sources.
>
> I have installed the kernel on my desktops at work and at home and
> they have been running solid with the SuSE kernel for about two weeks
> now, with no issues arising concerning the kernel.
>
> Some features of the SuSE kernel  that are not present in the
> gentoo-2.4.20-r7 sources are ALSA support built in, and more extensive
> support for Video for Linux support to include support for the
> Hauppauge WinTV cards.
>
> The gotcha's that I have noticed with using the SuSE kernel are:
>
> 1. The kernel sources are distributed by SuSE as an RPM.  The RPM
> data is compressed with bzip instead of gzip.  I discovered that
> rpm2targz doesn't understand bzipped RPM files and would not
> correctly process the rpm. Because of this, an explicit dependency
> for the kernel is the rpm ebuild. The only thing that is used from
> rpm is the rpm2cpio command to unpack the sources into the ebuild
> sandbox.  I don't use rpm in any other way.  The second dependency is
> cpio.  This one really isn't an issue since it is part of the system,
> but to be safe, I included it anyway.
>
> 2. SuSE comes with ALSA ported into the kernel.  The ALSA version
> used by SuSE is 0.9.0, while the Gentoo stable release is 0.9.2.  I
> have configured the kernel to both use and not use the ALSA drivers
> bundled with the kernel and have not noticed a problem using either
> configuration.
>
> The following are the steps I took to install the kernel using
> genkernel. For those of you who completely roll your own kernel, I'm
> making the assumption, that you can figure it out from these
> instructions.  I am also assuming that you already have your system
> up and running with another kernel, and that you have some familarity
> with the kernel compiling process.
>
> 1. Get the ebuild from:
>
http://varnerfamily.org/pvarner/gentoo/suse-sources-2.4.20.100.ebuild.tar.bz2
> 2. mkdir /usr/local/portage
> 3. cd /usr/local/portage
> 4. tar xvjf suse-sources-2.4.20.100.ebuild.tar.bz2
> 5. Edit /etc/make.conf and uncomment the PORTDIR_OVERLAY variable and
> set it to PORTDIR_OVERLAY=/usr/local/portage
> 6. emerge suse-sources
> 7.cd /usr/src
> 8. rm linux
> 9. ln -s linux-2.4.20-SuSE-100 linux
> 10. cp /usr/src/linux-2.4.20-gentoo-r7/.config
> /etc/kernels/config-2.4.20-SuSE-100
> 11. genkernel --config
> 12. In the kernel configuration, Processor Type and Features, ensure
> that Local APIC Support on uniprocessors and IO-APIC support on
> uniprocessors is turned on or ACPI support will not compile.
> 13. In the file systems section, ensure that /dev file system support
> and Automatically mount at boot is turned on.  Turn off /dev/pts file
> system for Unix98 PTYs
> 14. Peruse through the rest of the configuration and set everything
> to match your hardware and desires.
> 15. Exit and save the config
> 16. Let genkernel do it's thing.
> 17. Modify the boot loader and add the entry for the new kernel and
> initrd
>
> Prior to rebooting, If I used built in ALSA support.
> 1. /etc/init.d/alsasound stop
> 2. emerge unmerge alsa-driver
> 3. emerge -i alsa-driver (inject the stub, so emerge -u won't try to
> reinstall alsa-driver)
> 4. reboot
> 5. login or su to root after the reboot and use lsmod to insure the
> sound modules loaded, use the alsamixer to make sure that the volume
> levels are set correctly.
>
> If I did not use the built in ALSA support.
> 1. /etc/init.d/alsasound stop
> 2. emerge alsa-driver
> 3. reboot
> 4. login or su to root after the reboot and use lsmod to insure the
> sound modules loaded, use the alsamixer to make sure that the volume
> levels are set correctly.
>
> Rebuild the other drivers that depend upon the kernel.  For me, I
> have an nvidia card and use vmware, so I also execute the following.
>
> emerge nvidia-kernel
> vmware-config.pl
>
> If I get enough interest in the ebuild, I will submit it to gentoo for
> possible inclusion in the portage tree.  At this point, besides
> determining possible interest, I'm also looking for problems with the
> ebuild as well as enhancements.
>
> One of the things that I would like to see, is an ebuild for creating
> only rpm2cpio.  I have figured out how to build and install only
> rpm2cpio manually from the rpm sources.  But I haven't decided the
> better method for creating and using such an ebuild.  Should it block
> the install of rpm, or should the rpm ebuild be modified to unmerge
> the rpm2cpio ebuild if it is installed.  Secondly, I'm not sure how I
> would specify in the suse-sources ebuild, the either the rpm or
> rpm2cpio ebuild would satisfy the dependency.
>
> Finally, as the SuSE /etc/motd would say "Have a Lot of Fun!"



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SuSE Kernel Sources

[Georgi Georgiev]

On 02/10/2003 at 20:47:32(-0500), Paul Varner used 5.2K just to say:
> > 1. The kernel sources are distributed by SuSE as an RPM.  The RPM
> > data is compressed with bzip instead of gzip.  I discovered that
> > rpm2targz doesn't understand bzipped RPM files and would not
> > correctly process the rpm. Because of this, an explicit dependency
> > for the kernel is the rpm ebuild. The only thing that is used from
> > rpm is the rpm2cpio command to unpack the sources into the ebuild
> > sandbox.  I don't use rpm in any other way.  The second dependency is
> > cpio.  This one really isn't an issue since it is part of the system,
> > but to be safe, I included it anyway.

How did you discover that?

Please check the latest version of rpm2targz, bug #23249 and the rpm.eclass (in
reverse order). You can also take a look at the ebuilds for dev-lang/icc and
dev-lang/ifc (the first two that come to mind) for hints on how to use the
rpm.eclass.

-- 
(*   Georgi Georgiev   (* Get in touch with your feelings of hostility (*
*)    chutz@gg3.net    *) against the dying light. -- Dylan Thomas     *)
(*  +81(90)6266-1163   (* [paraphrased periphrastically]               (*

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SuSE Kernel Sources

[Paul Varner]

Georgi Georgiev wrote:
> On 02/10/2003 at 20:47:32(-0500), Paul Varner used 5.2K just to say:
>>> 1. The kernel sources are distributed by SuSE as an RPM.  The RPM
>>> data is compressed with bzip instead of gzip.  I discovered that
>>> rpm2targz doesn't understand bzipped RPM files and would not
>>> correctly process the rpm. Because of this, an explicit dependency
>>> for the kernel is the rpm ebuild. The only thing that is used from
>>> rpm is the rpm2cpio command to unpack the sources into the ebuild
>>> sandbox.  I don't use rpm in any other way.  The second dependency
>>> is cpio.  This one really isn't an issue since it is part of the
>>> system, but to be safe, I included it anyway.
>
> How did you discover that?
>
> Please check the latest version of rpm2targz, bug #23249 and the
> rpm.eclass (in reverse order). You can also take a look at the
> ebuilds for dev-lang/icc and dev-lang/ifc (the first two that come to
> mind) for hints on how to use the rpm.eclass.

I discovered it, because I used the redhat-sources ebuild as my inital
template.  When rpm2targz didn't work as expected I read through the script
to debug what it was doing. As I was stepping though the script, I saw that
it was the gunzip part that was failing, so I produced the output up to that
point and saw that I had bzipped data instead of gzipped data.
Additionally, since I saw no reason to create a tar.gz file, just to turn
around and unpack the file, I decided to use rpm2cpio directly.

Anyhow, after seeing your comments on the rpm.eclass, I know what the r1
ebuild will be using!  This is not intended as a putdown, but I have had a
hard time finding all of the information that I have been looking for to
build the ebuild.  The documentation once I find it is great, but I still
feel like I'm looking for the needle in a haystack right now. I'm sure that
it will get easier over time.

Regards,
Paul



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SuSE Kernel Sources

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

I thought I'd drop some input on this..I personally have a copy of rpm2targz
copied into my home dir in which all I did was change-

dd ibs=`rpmoffset < $i` skip=1 if=$i 2> /dev/null | gzip -dc > $ofn
to-
dd ibs=`rpmoffset < $i` skip=1 if=$i 2> /dev/null | bzip2 -dc > $ofn
because SuSe isn't the only ones to bzip2 their rpms (cant remember the
others right off), but I bet if someone took the time to make another case
in the script that dropped down to the bzip2 on the gzip failure, it
wouldn't require any of those complicated suggestions noted in the bug. I
have neither the time or the inclination to do it myself, but it shouldn't
be too hard:)

__
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] SuSE Kernel Sources

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

On 02/10/2003 at 21:17:11(-0700), C. Brewer used 1.3K just to say:
> I thought I'd drop some input on this..I personally have a copy of rpm2targz
> copied into my home dir in which all I did was change-
> 
> dd ibs=`rpmoffset < $i` skip=1 if=$i 2> /dev/null | gzip -dc > $ofn
> to-
> dd ibs=`rpmoffset < $i` skip=1 if=$i 2> /dev/null | bzip2 -dc > $ofn

Or you can make a script that does something similar to what rpm.eclass does.
Or you can look at the bug I mentioned in my previous post -- there are a few
more ideas over there (one of them is used in rpm.eclass). You can then use
only one script without worrying that there'd be a failure.

-- 
 /   Georgi Georgiev    / "The first rule of magic is simple. Don't     /
\     chutz@gg3.net    \  waste your time waving your hands and hoping \
 /  +81(90)6266-1163    / when a rock or a club will do." --            /
\  ------------------- \  McCloctnik the Lucid                         \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] SuSE Kernel Sources

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

True, there were solid suggestions in the bug, but IIRC most of them
revolved around rpm/rpm2cpio, negating the need for rpm2tgz in the first
place. Maybe I ( or someone with the time) will work out the hitch in
rpm2tgz. IMHO its bad enough needing to install rpms in the first place,
without adding the rpm program as well. Just a thought:)



-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] SuSE Kernel Sources

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

On 03/10/2003 at 00:20:45(-0700), C. Brewer used 1.0K just to say:
> True, there were solid suggestions in the bug, but IIRC most of them
> revolved around rpm/rpm2cpio, negating the need for rpm2tgz in the first
> place.

The reason I opened that bug in the first place, is because I didn't want to
compile rpm to install icc on a friend's computer. So even though rpm/rpm2cpio
negates the need for rpm2tgz, there is a solid reason why we do need a quick,
easy, small solution for uncompressing rpms.

1. feature(gzip + bzip2 + rpmoffset) == feature(rpm2cpio)

2. size(gzip + bzip2 + rpmoffset) <<<<<< size(rpm2cpio) == size(rpm)

> Maybe I ( or someone with the time) will work out the hitch in
> rpm2tgz.

What hitch? We've alrady worked around that hitch. However if you read the bug
correctly -- there was a suggestion for fixing the rpm2tgz package itself, but
Mr.Tse decided to simply fix the rpm.eclass. Which IMHO is a solution good
enough as we mostly need to uncompress RPMs in ebuilds.

> IMHO its bad enough needing to install rpms in the first place,
> without adding the rpm program as well. Just a thought:)

It is *not* a bad idea, and here is why:

First of all, Gentoo does not "install" rpms. Gentoo doesn't care about
dependency information in the rpm, nor does it need to update some freaky
database that rpm uses. It only needs the files. So in Gentoo terms -- the RPM
package is just a freaky tarball. Why would I need the rpm package to
uncompress that freaky tarball if I can go without it?

-- 
\    Georgi Georgiev   \  QOTD: "Everything I am today I owe to        \
/     chutz@gg3.net    /  people, whom it is now to late to punish."   /
\   +81(90)6266-1163   \                                               \

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] SuSE Kernel Sources

[Alastair Tse]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Fri, 2003-10-03 at 05:17, C. Brewer wrote:
> because SuSe isn't the only ones to bzip2 their rpms (cant remember the
> others right off), but I bet if someone took the time to make another case
> in the script that dropped down to the bzip2 on the gzip failure, it

I believe the rpm.eclass does that for you. Another RPM that uses bzip2
compression is app-i18n/scim-chinese. It is obscure but just another
example. 

Cheers,
-- 
Alastair 'liquidx' Tse
 >> Gentoo Developer
 >> http://www.liquidx.net/ | http://dev.gentoo.org/~liquidx/
 >> GPG Key : http://dev.gentoo.org/~liquidx/liquidx_gentoo_org.asc
 >> FingerPrint : 579A 9B0E 43E8 0E40 EE93  BB1C 38CE 1C7B 3907 14F6

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] SuSE Kernel Sources

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

I hear what you're saying, but I guess I wasn't particularly clear.
Basically, you have the fix for it, and it's nice, and it works. However,
what I was trying to get at is this- rather than write an eclass, why not
fix the package itself and kick it back to Slack? Sure, there's a chance
they won't care to change it, and the eclass would be necessary, but now
we're at a point with everyone fixing everything, the tree is getting to
carry almost the amount of patches as it does packages. So I apologize if
I'm unclear or frustrated, but it feels as if rather than sharpen an old
knife to do the work, we just make a new knife. I realize that's not the
intent of anyone, but if the fixes and work arounds don't get back
upstream, how long until patches and fixes do outweigh the packages?
(I'm up to ~60k files from the ~20k when I first installed!)


-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] SuSE Kernel Sources

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On 03/10/2003 at 10:57:40(-0700), C. Brewer used 1.5K just to say:
> I hear what you're saying, but I guess I wasn't particularly clear.
> Basically, you have the fix for it, and it's nice, and it works. However,
> what I was trying to get at is this- rather than write an eclass, why not
> fix the package itself and kick it back to Slack?

This idea was also in one of the comments of the bug.

http://bugs.gentoo.org/show_bug.cgi?id=23249#c13

(second comment from the bottom for now)

> Sure, there's a chance
> they won't care to change it, and the eclass would be necessary, but now
> we're at a point with everyone fixing everything, the tree is getting to
> carry almost the amount of patches as it does packages. So I apologize if
> I'm unclear or frustrated, but it feels as if rather than sharpen an old
> knife to do the work, we just make a new knife. I realize that's not the
> intent of anyone, but if the fixes and work arounds don't get back
> upstream, how long until patches and fixes do outweigh the packages?
> (I'm up to ~60k files from the ~20k when I first installed!)

-- 
/\   Georgi Georgiev   /\ A real friend isn't someone you use once and /\
\/    chutz@gg3.net    \/ then throw away. A real friend is someone    \/
/\  +81(90)6266-1163   /\ you can use over and over again.             /\

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]