Re: [gentoo-user] Gentoo sources
The archived sources (afaik) for installed (and probably downloaded sources as well) programs are stored in /usr/portage/distfiles. This includes all patches to the application as well. Digby Tarvin wrote: This is a question from somebody who is just testing the water with the gentoo distribution.. probably basic, but I couldn't see the answer in the documentation or faq so... First some background - I am a long time user of the BSD/OS flavour of BSD Unix (since the days when Minix was the only open source *nix), and over the last 2-3 years have dabbled with Red Hat and SuSE Linux distributions because of the better hardware support and availability of 3rd party software like vmware... However I was not keen on the Microsoft style GUI based system install and administration used in both distros, which seemed to assume that the packager knew best, and the user doesn't need to understand what is going on 'under the hood'. I also missed my readily available sourcode on my BSD system. The Linux distros did not default to loading the source onto the disk, and when sources were installed, I did not find it simple or intuitive to locate them and know how to rebuild my binaries from them. On my BSD system, if I wanted to find the source for /usr/bin/foo, I knew I could just 'cd /usr/src/usr.bin/foo' and that was the directory containing the source. To rebuild everything related to that application, I just typed 'make' in that directory... I liked what I had heard about gentoo being built from source, implying that the source for every binary on the system should be accessible. However after going through the install process, the only sources which I can find in an expected place are the kernel sources. So the question is, how to I go about making sure that the sources that my system is built from reside on my disk, and how do I find them? I really want to be able to access the source whenever I want (it is the only way I find to work around the often incomplete documentation on Linux systems) not just when I have an Internet connection available. After all, the only reason I really want to sit around and wait for a compile and build everytime I install a new package is so that I can be sure that the binary I am running corresponds to the source that I have. Regards, DigbyT -- This site uses frames And yet your browser does not. One of these will change. smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-user] Gentoo sources
On Mon, 28 Mar 2005, Digby Tarvin wrote: So the question is, how to I go about making sure that the sources that my system is built from reside on my disk, and how do I find them? A simple answer to your simple question... The sources are in /usr/portage/distfiles -- T.G. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
The source is available in the ${DISTDIR} directory (/var/tmp/distfiles
by default, I think). If you just want the source,
emerge -f packagename
will get the raw source (OpenBSD's 'make fetch'). However, I haven't
found the equivalent of OpenBSD's 'make patch'. It's done as part of
the ebuild process, but there's no individual command. To see the exact
source that you'll compile, this might be a solution:
1) add keeptemp and keepwork to your FEATURES list in /etc/make.conf
(emerge removes the source files after building and installing by default)
2) emerge the package (maybe suspending or breaking the build process
after ebuild patches the source)
3) inspect the patched source under ${PORTAGE_TMPDIR}
hope this helps, and welcome to Gentoo
--myk
Digby Tarvin wrote:
However after going through the install process, the only sources which I
can find in an expected place are the kernel sources.
So the question is, how to I go about making sure that the sources that
my system is built from reside on my disk, and how do I find them?
I really want to be able to access the source whenever I want (it is
the only way I find to work around the often incomplete documentation on
Linux systems) not just when I have an Internet connection available.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Well, some patches are stored in /usr/portage/distfiles. Others are in
/usr/portage/group/pkg/files/. I think the ones in the files/
directory are those created by the Gentoo developers.
Does anyone know if there is an official way to clean the distfiles
directory of old sources. So far, the best I have is:
mount / -o remount,atime
emerge --fetchonly --emptytree world
find /usr/portage/distfiles -atime +1 -exec rm -v {} \;
mount / -o remount,noatime
-Richard
Steven Susbauer wrote:
The archived sources (afaik) for installed (and probably downloaded
sources as well) programs are stored in /usr/portage/distfiles. This
includes all patches to the application as well.
Digby Tarvin wrote:
This is a question from somebody who is just testing the water with
the gentoo distribution.. probably basic, but I couldn't see the answer
in the documentation or faq so...
First some background - I am a long time user of the BSD/OS flavour of
BSD Unix (since the days when Minix was the only open source *nix),
and over the last 2-3 years have dabbled with Red Hat and SuSE Linux
distributions because of the better hardware support and availability
of 3rd party software like vmware...
However I was not keen on the Microsoft style GUI based system install
and administration used in both distros, which seemed to assume that
the packager knew best, and the user doesn't need to understand what
is going on 'under the hood'.
I also missed my readily available sourcode on my BSD system. The Linux
distros did not default to loading the source onto the disk, and when
sources were installed, I did not find it simple or intuitive to locate
them and know how to rebuild my binaries from them.
On my BSD system, if I wanted to find the source for /usr/bin/foo, I
knew
I could just 'cd /usr/src/usr.bin/foo' and that was the directory
containing
the source. To rebuild everything related to that application, I just
typed 'make' in that directory...
I liked what I had heard about gentoo being built from source, implying
that the source for every binary on the system should be accessible.
However after going through the install process, the only sources
which I
can find in an expected place are the kernel sources.
So the question is, how to I go about making sure that the sources that
my system is built from reside on my disk, and how do I find them?
I really want to be able to access the source whenever I want (it is
the only way I find to work around the often incomplete documentation on
Linux systems) not just when I have an Internet connection
available.
After all, the only reason I really want to sit around and wait for a
compile and build everytime I install a new package is so that I can
be sure that the binary I am running corresponds to the source that
I have.
Regards,
DigbyT
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Thanks Myk (and everyone else that responded)..
The bit about 'keeptemp' and 'keepwork' in /etc/make.conf sounds like
the clue I was looking for. I'll have to see if it can be configured to
keep a nice logical source tree similar to what I was used to under
/usr/src so that my souces are always readily browsable without having
to unpack archives and apply patches...
For what it is worth, the way I prefer to work, and the way I used
to work with my BSD system when installing stuff that wasn't part of
the BSDI maintained source tree was to keep a copy of the original
tarball in
/usr/local/src/DIST/packagename.tar.gz
and keep the uppacked and (where necessary) customised code in
/usr/local/src/packagename
with a 'Readme.digbyt' describing everything that I had to do to
get it running (ideally just ./configure;make;make install), with
the installation always going in
/usr/local/bin,/usr/local/lib,/usr/local/man etc...
By creating a 'local' group, nearly everything could be installed
without root priveledge.
Regards,
DigbyT
On Mon, Mar 28, 2005 at 01:27:00AM -0800, Myk Taylor wrote:
The source is available in the ${DISTDIR} directory (/var/tmp/distfiles
by default, I think). If you just want the source,
emerge -f packagename
will get the raw source (OpenBSD's 'make fetch'). However, I haven't
found the equivalent of OpenBSD's 'make patch'. It's done as part of
the ebuild process, but there's no individual command. To see the exact
source that you'll compile, this might be a solution:
1) add keeptemp and keepwork to your FEATURES list in /etc/make.conf
(emerge removes the source files after building and installing by default)
2) emerge the package (maybe suspending or breaking the build process
after ebuild patches the source)
3) inspect the patched source under ${PORTAGE_TMPDIR}
hope this helps, and welcome to Gentoo
--myk
Digby Tarvin wrote:
However after going through the install process, the only sources which I
can find in an expected place are the kernel sources.
So the question is, how to I go about making sure that the sources that
my system is built from reside on my disk, and how do I find them?
I really want to be able to access the source whenever I want (it is
the only way I find to work around the often incomplete documentation on
Linux systems) not just when I have an Internet connection available.
--
Digby R. S. Tarvin [EMAIL PROTECTED]
http://www.digbyt.com
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Digby Tarvin wrote: However after going through the install process, the only sources which I can find in an expected place are the kernel sources. So the question is, how to I go about making sure that the sources that my system is built from reside on my disk, and how do I find them? They do reside on your disk; look in /usr/portage/distfiles for the tarballs. The reason you can find the kernel sources in an expected place is because /usr/src is the standard place to extract kernel sources, and kernel sources are the only sources that reside in an extracted state on an average system (unless you're manually compiling a source tarball outside of Portage control, in which case you know exactly where the source is extracted anyway). The sources for portage-compiled apps don't need to be lying around in an extracted state except during the compile (during which they are extracted to /var/temp/portage, I think), but once the compile is finished, the temp files are removed (naturally), though they will remain there if the emerge fails, taking up space. However, the original tarball remains in /usr/portage/distfiles, unless you blow that folder away to save space (which many of us do, since the only downside of that is that you will have to download the tarball again if you want to reinstall that same package/version). Alternatively, you can just look in the ebuild or at the package description on packages.gentoo.org to find the download location of the tarballs, or the application homepage, and then download the specific sources you want to look at. There's not necessarily a real reason to have *all* of the sources on your HDD (other than the ones you specifically want to look at, or preserve for some other reason)-- but, this being Gentoo, it's up to you how you want to handle the issue (keep every source, or keep some, or keep none). HTH, Holly -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Myk Taylor wrote:
The source is available in the ${DISTDIR} directory
(/var/tmp/distfiles by default, I think). If you just want the source,
emerge -f packagename
will get the raw source (OpenBSD's 'make fetch'). However, I haven't
found the equivalent of OpenBSD's 'make patch'. It's done as part of
the ebuild process, but there's no individual command. To see the
exact source that you'll compile, this might be a solution:
1) add keeptemp and keepwork to your FEATURES list in /etc/make.conf
(emerge removes the source files after building and installing by
default)
2) emerge the package (maybe suspending or breaking the build process
after ebuild patches the source)
Say you want to unpack the source file to where gentoo officially work
with sources without
actually compiling do:
# emerge -f /usr/portage/app-shells/bash/bash-2.05b-r9.ebuild
(to fetch the source tarball), then:
# ebuild /usr/portage/app-shells/bash/bash-2.05b-r9.ebuild unpack
md5 src_uri ;-) bash-2.05b.tar.gz
md5 src_uri ;-) bash-2.05b-gentoo.diff.bz2
md5 src_uri ;-) bash205b-002
md5 src_uri ;-) bash205b-003
md5 src_uri ;-) bash205b-004
md5 src_uri ;-) bash205b-005
md5 src_uri ;-) bash205b-006
md5 src_uri ;-) bash205b-007
Unpacking source...
Unpacking bash-2.05b.tar.gz to /var/tmp/portage/bash-2.05b-r9/work
* Applying bash-2.05b-gentoo.diff.bz2
...[ ok ]
* Applying bash205b-002
... [ ok ]
* Applying bash205b-003
... [ ok ]
* Applying bash205b-004
... [ ok ]
* Applying bash205b-005
... [ ok ]
* Applying bash205b-006
... [ ok ]
* Applying bash205b-007
... [ ok ]
* Applying bash-2.05b-multibyte-locale.patch
... [ ok ]
* Applying bash-2.05b-empty-herestring.patch
... [ ok ]
* Applying bash-2.05b-rbash.patch
...[ ok ]
* Applying bash-2.05b-parallel-build.patch
... [ ok ]
* Applying bash-2.05b-jobs.patch
... [ ok ]
* Using GNU config files from /usr/share/libtool
* Updating
support/config.sub
[ ok ]
* Updating
support/config.guess
[ ok ]
Source unpacked
# ebuild /usr/portage/app-shells/bash/bash-2.05b-r9.ebuild clean
(to clean the manually extracted sources)
#man ebuild
and
# nano -w /usr/portage/app-shells/bash/bash-2.05b-r9.ebuild
for more info
HTH
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Hello Holly, Thanks for the advice. I must say I prefer the original Unix approach of putting all the sources under /usr/src, with the kernel going into /usr/src/sys. One of the reasons I like to have the unpacked sources for everything on my disk is that the with open source the documentation is so often inadequate. (of course it is not unheard of for commercial products to have woeful documentation as well - which is why there are so many third party books on Windows...) If, on the other hand, you treat the source code as the 'definative' documentation, then by keeping it around I know that there is nothing about my system that I cannot find out, and I never have to resort to trial and error to work out how something works. Plus, of course, there is the added bonus that if the feature you are looking for isn't there, you can add it in. Or if the way something works isn't obvious from the source, it is easy to temporarily add the odd diagnostic. It is also useful when writing new code to be able to look at existing source to make sure you are not re-inventing things and are following best practice. It is amazing how often you find that a library already exists to handle something you were about to code from scratch... In theory I could unpack a tarball, but that is a lot more effort than reading a file with is already available and in a predictable place. For me, being able to do that is one of the main benefits of an open source system. Being free is not the major issue. Regards, DigbyT On Mon, Mar 28, 2005 at 11:54:12AM +0200, Holly Bostick wrote: Digby Tarvin wrote: However after going through the install process, the only sources which I can find in an expected place are the kernel sources. So the question is, how to I go about making sure that the sources that my system is built from reside on my disk, and how do I find them? They do reside on your disk; look in /usr/portage/distfiles for the tarballs. The reason you can find the kernel sources in an expected place is because /usr/src is the standard place to extract kernel sources, and kernel sources are the only sources that reside in an extracted state on an average system (unless you're manually compiling a source tarball outside of Portage control, in which case you know exactly where the source is extracted anyway). The sources for portage-compiled apps don't need to be lying around in an extracted state except during the compile (during which they are extracted to /var/temp/portage, I think), but once the compile is finished, the temp files are removed (naturally), though they will remain there if the emerge fails, taking up space. However, the original tarball remains in /usr/portage/distfiles, unless you blow that folder away to save space (which many of us do, since the only downside of that is that you will have to download the tarball again if you want to reinstall that same package/version). Alternatively, you can just look in the ebuild or at the package description on packages.gentoo.org to find the download location of the tarballs, or the application homepage, and then download the specific sources you want to look at. There's not necessarily a real reason to have *all* of the sources on your HDD (other than the ones you specifically want to look at, or preserve for some other reason)-- but, this being Gentoo, it's up to you how you want to handle the issue (keep every source, or keep some, or keep none). HTH, Holly -- gentoo-user@gentoo.org mailing list -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Digby Tarvin wrote: Hello Holly, Thanks for the advice. I must say I prefer the original Unix approach of putting all the sources under /usr/src, with the kernel going into /usr/src/sys. One of the reasons I like to have the unpacked sources for everything on my disk is that the with open source the documentation is so often inadequate. (of course it is not unheard of for commercial products to have woeful documentation as well - which is why there are so many third party books on Windows...) If, on the other hand, you treat the source code as the 'definative' documentation, then by keeping it around I know that there is nothing about my system that I cannot find out, and I never have to resort to trial and error to work out how something works. Works in what way? For most user purposes, man command_name or command_name --help is sufficient to work out how something works. If you mean how it is designed to work, then yes, you certainly need the source, but even so, that's only if you don't agree with the way it's designed, or you want to modify the design. For a normal user, there's very little need to resort to reading the source just to use the application (boy, if that was true, Linux *really* wouldn't be ready for the desktop!). Plus, of course, there is the added bonus that if the feature you are looking for isn't there, you can add it in. Or if the way something works isn't obvious from the source, it is easy to temporarily add the odd diagnostic. Fair enough, but that doesn't mean that every installed source has to be extracted on your system because 1) most sources do actually work, both in terms of compiling properly, and the compiled application working properly, thus they do not need to be diagnosed, and 2) if you're missing a feature and want to code it, you should be using the application's CVS/Subversion source anyway, which will put the extracted and current source on your system, so you can help improve the project as a whole. There's not a lot of point in adjusting the release source code, when some fixes may already exist in CVS towards the next release. It is also useful when writing new code to be able to look at existing source to make sure you are not re-inventing things and are following best practice. It is amazing how often you find that a library already exists to handle something you were about to code from scratch... Again, this doesn't seem to indicate that you'd need *every single source* extracted on your system, but only the ones that bear some relationship to something you might actually code. But it's your system. In theory I could unpack a tarball, but that is a lot more effort than reading a file with is already available and in a predictable place. Seems to me that you could write a script to unpack just the tarballs you want unpacked to a known location, but that's just me; I've never considered unpacking tarballs to be a lot of effort-- certainly not when you could do it as a cron job. The point being, you're clearly not an average user, so you have special needs for your source tarballs. Gentoo is certainly flexible enough to accomodate them (for example, the KEEP_TEMP business suggested earlier), but because you have special needs/desires, you have to make a small effort to make sure they are met to your requirements. For me, being able to do that is one of the main benefits of an open source system. Being free is not the major issue. Nor for me; what I like is being able to customize my system for my personal needs, and being able to contribute to the OS as a whole. But free (in either sense) is nothing to sneeze at, either. :) Holly Regards, DigbyT -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Richard Fish wrote:
Well, some patches are stored in /usr/portage/distfiles. Others are in
/usr/portage/group/pkg/files/. I think the ones in the files/
directory are those created by the Gentoo developers.
Does anyone know if there is an official way to clean the distfiles
directory of old sources. So far, the best I have is:
mount / -o remount,atime
emerge --fetchonly --emptytree world
find /usr/portage/distfiles -atime +1 -exec rm -v {} \;
mount / -o remount,noatime
-Richard
Attached is a script I have used for months. I believe I found it
somewhere on the forum.
--
Tom Wesley [EMAIL PROTECTED]
distclean-0.1.py
Description: application/python
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-user] Gentoo sources
Tom Wesley wrote:
Richard Fish wrote:
Well, some patches are stored in /usr/portage/distfiles. Others are in
/usr/portage/group/pkg/files/. I think the ones in the files/
directory are those created by the Gentoo developers.
Does anyone know if there is an official way to clean the distfiles
directory of old sources. So far, the best I have is:
mount / -o remount,atime
emerge --fetchonly --emptytree world
find /usr/portage/distfiles -atime +1 -exec rm -v {} \;
mount / -o remount,noatime
-Richard
Attached is a script I have used for months. I believe I found it
somewhere on the forum.
To be exact, from my favorite corner of the forums Documentation Tips
Tricks:
Cleaning out stale distfiles
http://forums.gentoo.org/viewtopic.php?t=3011
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Hi, ... If, on the other hand, you treat the source code as the 'definative' documentation, then by keeping it around I know that there is nothing about my system that I cannot find out, and I never have to resort to trial and error to work out how something works. Works in what way? For most user purposes, man command_name or command_name --help is sufficient to work out how something works. If you mean how it is designed to work, then yes, you certainly need the source, but even so, that's only if you don't agree with the way it's designed, or you want to modify the design. For a normal user, there's very little need to resort to reading the source just to use the application (boy, if that was true, Linux *really* wouldn't be ready for the desktop!). Ok, here is a quick example of something I would have dived into the source for yesterday had it not been for the fact that I couln't find any related '.c' files in my source directory. When I emerged and ran 'grip', I found that clicking on the help menus did nothing. I thought I might have been missing some files, so I tried for a man page: 2.gentoo:/root man grip No manual entry for grip Running 'grip --help' gives me a list of command line options, but nothing to shed light on the non-working menu... In the end I booted SuSE and read the help menu documentation there to answer my immediate query (I want to know the % escapes for tweaking the generated file and directory names...).. Without the source, you are back in the Windows situation where problems are sorted out by trial and error, folklore and reinstalling... While I am at it, anyone know what the problem with the grip help menu is on gentoo? Plus, of course, there is the added bonus that if the feature you are looking for isn't there, you can add it in. Or if the way something works isn't obvious from the source, it is easy to temporarily add the odd diagnostic. Fair enough, but that doesn't mean that every installed source has to be extracted on your system because 1) most sources do actually work, both in terms of compiling properly, and the compiled application working properly, thus they do not need to be diagnosed, and 2) if you're missing a feature and want to code it, you should be using the application's CVS/Subversion source anyway, which will put the extracted and current source on your system, so you can help improve the project as a whole. There's not a lot of point in adjusting the release source code, when some fixes may already exist in CVS towards the next release. To me that is a bit like saying you only need to install the man pages of the applications you are actually using. I feel that if you are going to install the application, you should install what you need to maintain it. If I knew in advance what was going to need fixing, (or trawling though to to find out how to make something to work..), then I would fix/solve it as part of the install process. Having the sources all unpacked also has the benefit of allowing me to grep through them - for instance if I want to look for examples of how a particular library has been used, or who creates a certain temp file... You are of course right about the CVS stuff for serious mods, but there are times when a quick hack is needed to test something, and only if it turns out to be a mod that would be generally useful would one bother with the CVS tree. It is also useful when writing new code to be able to look at existing source to make sure you are not re-inventing things and are following best practice. It is amazing how often you find that a library already exists to handle something you were about to code from scratch... Again, this doesn't seem to indicate that you'd need *every single source* extracted on your system, but only the ones that bear some relationship to something you might actually code. But it's your system. It is more a case of having what I 'might' need - same argument as having all the man pages, even though I have only used a subset to date. It would slow me down to much if I had to extract each man page from a tar ball before I could look at it. In theory I could unpack a tarball, but that is a lot more effort than reading a file with is already available and in a predictable place. Seems to me that you could write a script to unpack just the tarballs you want unpacked to a known location, but that's just me; I've never considered unpacking tarballs to be a lot of effort-- certainly not when you could do it as a cron job. The point being, you're clearly not an average user, so you have special needs for your source tarballs. Gentoo is certainly flexible enough to accomodate them (for example, the KEEP_TEMP business suggested earlier), but because you have special needs/desires, you have to make a small effort to make sure they are met to your requirements. I'll look into that. The tricky bit was always
Re: [gentoo-user] Gentoo sources
snip While I am at it, anyone know what the problem with the grip help menu is on gentoo? There's nothing wrong with grip or its help menu. Do you happen to have gnome-extra/yelp installed? I'm fairly certain the problem here is that you're missing the Gnome help browser... -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
That did the trick - thanks. I'm not convinced that this isn't an indication of a problem though. Shouldn't 'emerge grip' have pulled in anything that grip depended on? Or failing that, shouldn't grip have complained about whatever it was looking for being missing rather than just silently failing...? It certainly seems to me like an obscure problem to track down without some inside knowledge from someone like yourself Regards, DigbyT On Mon, Mar 28, 2005 at 10:53:41AM -0500, James Hiscock wrote: snip While I am at it, anyone know what the problem with the grip help menu is on gentoo? There's nothing wrong with grip or its help menu. Do you happen to have gnome-extra/yelp installed? I'm fairly certain the problem here is that you're missing the Gnome help browser... -- gentoo-user@gentoo.org mailing list -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
On Mon, 28 Mar 2005, Digby Tarvin wrote: Thanks for the advice. I must say I prefer the original Unix approach of putting all the sources under /usr/src, with the kernel going into /usr/src/sys. Linux is not UNIX :-) One of the reasons I like to have the unpacked sources for everything on my disk is that the with open source the documentation is so often inadequate. (of course it is not unheard of for commercial products to have woeful documentation as well - which is why there are so many third party books on Windows...) Documentation for a package is often under /usr/share/docs/packagename Plus, of course, there is the added bonus that if the feature you are looking for isn't there, you can add it in. Or if the way something works isn't obvious from the source, it is easy to temporarily add the odd diagnostic. You could write your own ebuild for this kind of stuff. -- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
On Mon, 28 Mar 2005, Digby Tarvin wrote: I'm not convinced that this isn't an indication of a problem though. Shouldn't 'emerge grip' have pulled in anything that grip depended on? Or failing that, shouldn't grip have complained about whatever it was looking for being missing rather than just silently failing...? When I run emerge -pv grip (You always run -pv before doing the actual emerge don't you?), I see gnome-extra/yelp listed so it appears the ebuild does pull in the correct dependencies. So maybe you installed it differently? Any USE flags? Did you use --inject? etc etc etc. The Gentoo documentation on the package system is pretty damn good so I would recommend checking it out. -- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
When I run emerge -pv grip (You always run -pv before doing the actual emerge don't you?), I see gnome-extra/yelp listed so it appears the ebuild does pull in the correct dependencies. So maybe you installed it differently? Any USE flags? Did you use --inject? etc etc etc. Ah, so it was supposed to have pulled it in... From memory, I did an 'emerge --search', followed by 'emerge grip'. Don't know enough to do anything more exotic that that yet... No USE flags other than those that are in my make.defaults as follows: USE=oss apm arts avi berkdb bitmap-fonts crypt cups emboss encode fortran font- server foomaticdb gdbm gif gnome gpm gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib perl png python qt quicktime readline sdl spell ssl svga tcpd truetype truetype-fonts type1-fonts The Gentoo documentation on the package system is pretty damn good so I would recommend checking it out. Bear with me - I am working my way through the documentation. I'm just trying to get enough of a system up and running while I am at it to let me try things out while I am reading Regards, DigbyT -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
Ah, so it was supposed to have pulled it in... ...not necessarily: when I run emerge -pvtDe grip, I don't see yelp in the output... but I'm not entirely sure why. Might be because of my USE flags, or something. I'm also curious if you've got gnome-base/gnome or gnome-base/gnome-light installed. If you do have either of those, then gnome-extra/yelp should've been pulled in. I've got gnome-base/gnome installed here... I have no idea why I'm getting different results, but I don't really care, either: it works for me, and it appears to work for you, so it's all good... (but I _am_ starting to wonder if we've just uncovered a sneaky/annoying/hard to reproduce bug here... ;) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
No, I had not installed gnome-base/gnome or gnome-base/gnome-light yet on my system. I am confident that it would have all worked first time if I had done so. I generally use fvwm as something reasonably lean and unobtrusive, but had also installed KDE to see what the more full blown GUI environments looked like. (for really frugal use of display area, plan 9 is the way to go - no window decorations at all. I hate it when you only a tiny screen on a palmtop and half of the real-estate if used up with window decorations and menu bars...) One thing I did like in the SuSE distro which I havn't worked out how to reproduce on gentoo yet is the way the KDM login prompter includes a 'Session Type' menu of window manager options. It made it nice and easy to experiment with different environments. Anyway, yes, it does seem to work when you know what packages to pull in. It is just a little worrying that it seems that dependencies can sometimes be overlooked. Regards, DigbyT On Mon, Mar 28, 2005 at 02:24:46PM -0500, James Hiscock wrote: Ah, so it was supposed to have pulled it in... ...not necessarily: when I run emerge -pvtDe grip, I don't see yelp in the output... but I'm not entirely sure why. Might be because of my USE flags, or something. I'm also curious if you've got gnome-base/gnome or gnome-base/gnome-light installed. If you do have either of those, then gnome-extra/yelp should've been pulled in. I've got gnome-base/gnome installed here... I have no idea why I'm getting different results, but I don't really care, either: it works for me, and it appears to work for you, so it's all good... (but I _am_ starting to wonder if we've just uncovered a sneaky/annoying/hard to reproduce bug here... ;) -- gentoo-user@gentoo.org mailing list -- Digby R. S. Tarvin [EMAIL PROTECTED] http://www.digbyt.com -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Gentoo sources
One thing I did like in the SuSE distro which I havn't worked out how to reproduce on gentoo yet is the way the KDM login prompter includes a 'Session Type' menu of window manager options. It made it nice and easy to experiment with different environments. My KDM does this by default. If you install a new WM, then it presents a new entry under the Session Type meny. Matt -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gentoo-sources vs. gentoo-dev-sources
On 03/26/05 17:52, Jörgen Andersson wrote: Hi I'm currently on to my very first Gentoo installation and just sitting around waiting for my system to finish the bootstrap.sh. Meanwhile I've been looking around a great deal and started to think about what kernel-package to use. I can't see any reason for not going with a 2.6-kernel and I suppose that is the way Gentoo's default will be moving as well. In doing so I thought using the gentoo-sources already now would save me some time over going with gentoo-dev-sources now and later switch to gentoo-sources. However, all version 2.6.x are masked in gentoo-sources. 2.6.11-r4 is marked as stable, but still masked. I can see the very same version is available in gentoo-dev-sources. Would it then be ok for me to echo =kernel/gentoo-sources-2.6.11-r4 /etc/portage/package.unmask in order to avoid having to switch packages later on? Or am I missing some heavy reason why the 2.6.x kernels is masked in gentoo-sources? /Jörgen Just use gentoo-dev-sources for the moment. I don't see how it would be any trouble to switch later on. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gentoo-sources vs. gentoo-dev-sources
Jörgen Andersson wrote: Hi I'm currently on to my very first Gentoo installation and just sitting around waiting for my system to finish the bootstrap.sh. Meanwhile I've been looking around a great deal and started to think about what kernel-package to use. I can't see any reason for not going with a 2.6-kernel and I suppose that is the way Gentoo's default will be moving as well. In doing so I thought using the gentoo-sources already now would save me some time over going with gentoo-dev-sources now and later switch to gentoo-sources. However, all version 2.6.x are masked in gentoo-sources. 2.6.11-r4 is marked as stable, but still masked. I can see the very same version is available in gentoo-dev-sources. Would it then be ok for me to echo =kernel/gentoo-sources-2.6.11-r4 /etc/portage/package.unmask in order to avoid having to switch packages later on? Or am I missing some heavy reason why the 2.6.x kernels is masked in gentoo-sources? /Jörgen Check the profile you are using. Usually when the dev sources are masked it is because your profile is old. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r5 BIG PROBLEMS
On Wed, Feb 04, 2004 at 02:33:14PM +0100, Arne Vogel wrote: _JusSx_ wrote: Hi, i have installed gentoo-sources-2.4.22-r5 and i got a big problem. Everytime i shutdown my system my kernel start the process, so i can see from console, but my comp will never poweoff Thanx in advance You will probably need to enable APM (or ACPI?) support in the kernel. (in the kernel configuration, General Setup - Power Management Support etc.) -- [EMAIL PROTECTED] mailing list Thanx you very much, you re rigth. i forgot to enable Power Management Support feature. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r5 BIG PROBLEMS
_JusSx_ wrote: Hi, i have installed gentoo-sources-2.4.22-r5 and i got a big problem. Everytime i shutdown my system my kernel start the process, so i can see from console, but my comp will never poweoff Thanx in advance You will probably need to enable APM (or ACPI?) support in the kernel. (in the kernel configuration, General Setup - Power Management Support etc.) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r5
Hi, this is probably because the digest-file in /usr/portage/sys-kernel/gentoo-sources/files/digest-gentoo-sources-2.4.22-r5 claims that the size of gentoo-sources-2.4.22-r5.patch.bz2 has to be 3769551 bytes but the downloaded file has got a file size of 3766950 bytes. Greetz, Thomas Prock Guy Van Sanden wrote: I can't install gentoo-sources-2.4.22-r5, the ebuild doesn't stop downloading even though the file is already there (checked it). I have the same problem with sim 0.9.2 BTW. --upgradeonly implies --update... adding --update to options. Calculating dependencies ...done! emerge (1 of 1) sys-kernel/gentoo-sources-2.4.22-r5 to / Resuming download... Downloading http://194.83.57.3/sites/www.ibiblio.org/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 --10:48:23-- http://194.83.57.3/sites/www.ibiblio.org/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 = `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2' Connecting to 194.83.57.3:80... connected. HTTP request sent, awaiting response... 404 Not Found Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2'. Resuming download... Downloading http://ftp.easynet.nl/mirror/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 --10:48:23-- http://ftp.easynet.nl/mirror/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 = `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2' Resolving ftp.easynet.nl... 195.86.128.57 Connecting to ftp.easynet.nl[195.86.128.57]:80... connected. HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable The file is already fully retrieved; nothing to do. Resuming download... Downloading http://194.83.57.2/sites/www.ibiblio.org/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 --10:48:23-- http://194.83.57.2/sites/www.ibiblio.org/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 = `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2' Connecting to 194.83.57.2:80... connected. HTTP request sent, awaiting response... 404 Not Found Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2'. Resuming download... Downloading http://194.83.57.15/sites/www.ibiblio.org/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 --10:48:23-- http://194.83.57.15/sites/www.ibiblio.org/gentoo/distfiles/gentoo-sources-2.4.22-r5.patch.bz2 = `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2' Connecting to 194.83.57.15:80... connected. HTTP request sent, awaiting response... 404 Not Found Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2'. Resuming download... Downloading http://dev.gentoo.org/~iggy/gentoo-sources-2.4.22-r5.patch.bz2 --10:48:24-- http://dev.gentoo.org/%7Eiggy/gentoo-sources-2.4.22-r5.patch.bz2 = `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2' Resolving dev.gentoo.org... 128.193.0.39 Connecting to dev.gentoo.org[128.193.0.39]:80... connected. HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `/usr/portage/distfiles/gentoo-sources-2.4.22-r5.patch.bz2'. !!! Couldn't download gentoo-sources-2.4.22-r5.patch.bz2. Aborting -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r3
On Thu, 2004-01-08 at 04:56, Marius Mauch wrote: Both r2 and r3 were fixed yesterday, however to be sure use r3 (the patch was added to r2 after it was already deployed, so it's hard to say wether your installation has it). Sorry to prolong the thread, but isn't this not supposed to happen? Isn't the whole point of -rN to indicate when changes have been made? I can accept that changes flow through CVS on -rX that aren't yet marked stable. But certainly, once marked stable, the content of a particular ebuild shouldn't change, should it? So, (just trying to learn), in this case, what happened? AfC -- Andrew Frederick Cowie Operational Dynamics Consulting Pty Ltd Australia: +61 2 9977 6866 North America: +1 646 472 5054 http://www.operationaldynamics.com/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r3
pb wrote: gentoo-sources-2.4.22-r3 (released yesterday) doesn't fix any latestst security problems. in fact, it is identical to 2.4.22-r2. i wonder why it has been released and marked as stable... pb -- Public Key: http://teleinfo.tu.kielce.pl/~pb/gpg.asc Glad I decided to wait to upgrade to r3, as r4 just came out :) Aaron -- http://ka0ttic.dyndns.org/ /usr/bin/fortune says: Hawk, we're going to die. Never say die... and certainly never say we. -- M*A*S*H -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r3
On 01/07/04 pb wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gentoo-sources-2.4.22-r3 (released yesterday) doesn't fix any latestst security problems. in fact, it is identical to 2.4.22-r2. i wonder why it has been released and marked as stable... How did you check this ? Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. pgp0.pgp Description: PGP signature
Re: [gentoo-user] gentoo-sources-2.4.22-r3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
gentoo-sources-2.4.22-r3 (released yesterday) doesn't fix any latestst
security problems. in fact, it is identical to 2.4.22-r2.
i wonder why it has been released and marked as stable...
How did you check this ?
# cd /usr/portage/sys-kernel/gentoo-sources
# diff gentoo-sources-2.4.22-r2 gentoo-sources-2.4.22-r3
3c3
# $Header:
/home/cvsroot/gentoo-x86/sys-kernel/gentoo-sources/gentoo-sources-2.4.22-r2.ebuild,v
1.3 2004/01/06 15:17:52 plasmaroo Exp $
- ---
# $Header:
/home/cvsroot/gentoo-x86/sys-kernel/gentoo-sources/gentoo-sources-2.4.22-r3.ebuild,v
1.1 2004/01/06 20:55:12 plasmaroo Exp $
22c22
http://dev.gentoo.org/~iggy/gentoo-sources-${PVR}.patch.bz2;
- ---
http://dev.gentoo.org/~iggy/gentoo-sources-2.4.22-r2.patch.bz2;
36c36
bzcat ${DISTDIR}/gentoo-sources-${PVR}.patch.bz2 | patch -p1 \
- ---
bzcat ${DISTDIR}/gentoo-sources-2.4.22-r2.patch.bz2 | patch -p1 \
#
i didn't notice that 2.4.22-r2 was also updated when i did emerge sync a
few minutes earlier. another misleading thing was that 2.4.22-r3 had
EXTRAVERSION defined as -gentoo-r2
sorry, my mistake ;)
pb
- --
Public Key: http://teleinfo.tu.kielce.pl/~pb/gpg.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE//Ct9TE0TNzgUY2sRAprnAJ4vDYteUpFB0vua2KYpT/9TlVWo1wCfSUZt
F0swUPYQbDZwQR68bHqnT/E=
=4Rho
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Miércoles, 07 de Enero de 2004 16:24, Marius Mauch escribió:
On 01/07/04 pb wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
gentoo-sources-2.4.22-r3 (released yesterday) doesn't fix any latestst
security problems. in fact, it is identical to 2.4.22-r2.
i wonder why it has been released and marked as stable...
How did you check this ?
[EMAIL PROTECTED] gentoo-sources $ diff gentoo-sources-2.4.22-r2.ebuild
gentoo-sources-2.4.22-r3.ebuild
3c3
#
$Header:
/home/cvsroot/gentoo-x86/sys-kernel/gentoo-sources/gentoo-sources-2.4.22-r2.ebuild,v
1.3 2004/01/06 15:17:52 plasmaroo Exp $
- ---
#
$Header:
/home/cvsroot/gentoo-x86/sys-kernel/gentoo-sources/gentoo-sources-2.4.22-r3.ebuild,v
1.1 2004/01/06 20:55:12 plasmaroo Exp $
22c22
http://dev.gentoo.org/~iggy/gentoo-sources-${PVR}.patch.bz2;
- ---
http://dev.gentoo.org/~iggy/gentoo-sources-2.4.22-r2.patch.bz2;
36c36
bzcat ${DISTDIR}/gentoo-sources-${PVR}.patch.bz2 | patch -p1 \
- ---
bzcat ${DISTDIR}/gentoo-sources-2.4.22-r2.patch.bz2 | patch -p1 \
Marius
Differences are _trivial_.
- --
/* Alberto García Hierro (Skyhusker) */
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE//Cuv4O6JklHkL2cRAhlfAJ93O+03W2bqyWPFEldh5xzLl7lNOQCaAgXI
K2tCoZiqWXeYv/RjTRFH/IU=
=CG+d
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r3
On 01/07/04 Alberto Garcia Hierro wrote: Differences are _trivial_. I wasn't talking about the differences but the vulnerability. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. pgp0.pgp Description: PGP signature
Re: [gentoo-user] gentoo-sources-2.4.22-r3
Marius Mauch wrote: On 01/07/04 Alberto Garcia Hierro wrote: Differences are _trivial_. I wasn't talking about the differences but the vulnerability. So, does gentoo-sources-2.4.22r3 address this recent vulnerability or not? :-) I just finished upgrading everything to 2.4.22r2, so if I'm going to reboot stuff, now is a good time. ;) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r3
On 01/07/04 Jonathan Nichols wrote: So, does gentoo-sources-2.4.22r3 address this recent vulnerability or not? :-) I just finished upgrading everything to 2.4.22r2, so if I'm going to reboot stuff, now is a good time. ;) Both r2 and r3 were fixed yesterday, however to be sure use r3 (the patch was added to r2 after it was already deployed, so it's hard to say wether your installation has it). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. pgp0.pgp Description: PGP signature
Re: [gentoo-user] Gentoo-sources vs GS-sources
Brett I. Holcomb wrote: The Gentoo docs say gs-sources are more stable and reliable then gentoo-sources but gentoo-sources have better performance. How much more stable are the gs vs gentoo-sources? For those who have used both - what is the difference in performance and stability, reliability. Thanks. -- [EMAIL PROTECTED] mailing list First of all, why ask the same question twice within 2 hrs of each other? I have not used gs-sources, only because I haven't needed to. gentoo-sources is plenty stable and is most likely a bit faster as well. I use gentoo-sources on both my desktop system and my mail server (which has been up for 2 months.. it's only been booted up once, right after the install ;) not bad for a really old P233 and 2 really old 7giggers.. oh yeah and the really old 72-pin memory that I used to have on my keychain) before I converted my mail server over to gentoo, it was running RH9 which I had to reboot every 7 days or so because it would start to slow down and get real sluggish. Every day I thank the god of computers that gentoo is here. Aaron -- /usr/bin/fortune says: After a number of decimal places, nobody gives a damn. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources vs gs-sources
I would use vanilla with ck patches for a desktop system, it has got all the cool preempt low latency O1 seduler stuff in :-) - Original Message - From: Brett I. Holcomb [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 31, 2003 1:33 AM Subject: [gentoo-user] gentoo-sources vs gs-sources The Gentoo Kernel Guide says gs is supposed to be more stable then gentoo-sources. How much more stable and reliable is the question or conversely, how much difference is there in performance. I'm running a desktop system used for programing, gaming, and audio work. What is the experience of those who have used both? Thanks. -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: Re: [gentoo-user] Gentoo-sources vs GS-sources
Thank you Aaron. That's what I was looking for - some reassurance as to what more stable was. It sounds like gentoo-sources is pretty stable and reliable. As for asking twice that's my error - I'm just wrapping up the transisiton from Caldera WS 3.1 to Gentoo. KDE on the WS 3.1 box decided to die - again so I'm moving everything over. Part of that is the move to a new mail program and I thought I'd entered the address wrong and that it didn't go through especially when I didn't see the post appear after a long time. So I resent. From: Aaron Walker [EMAIL PROTECTED] Date: 2003/12/31 Wed AM 05:29:47 EST To: [EMAIL PROTECTED] Subject: Re: [gentoo-user] Gentoo-sources vs GS-sources Brett I. Holcomb wrote: The Gentoo docs say gs-sources are more stable and reliable then gentoo-sources but gentoo-sources have better First of all, why ask the same question twice within 2 hrs of each other? I have not used gs-sources, only because I haven't needed to. gentoo-sources is plenty stable and is most likely a bit faster as well. I use gentoo-sources on both my desktop system and my mail server (which has been up for 2 months.. it's only been booted up once, right after the install ;) not bad for a really old P233 and 2 really old 7giggers.. oh yeah and the really old 72-pin memory that I used to have on my keychain) before I converted my mail server over to gentoo, it was running RH9 which I had to reboot every 7 days or so because it would start to slow down and get real sluggish. Every day I thank the god of computers that gentoo is here. Aaron -- /usr/bin/fortune says: After a number of decimal places, nobody gives a damn. -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources vs gs-sources
On Tue, 2003-12-30 at 18:33, Brett I. Holcomb wrote: The Gentoo Kernel Guide says gs is supposed to be more stable then gentoo-sources. How much more stable and reliable is the question or conversely, how much difference is there in performance. I'm running a desktop system used for programing, gaming, and audio work. What is the experience of those who have used both? gs-sources is no longer meant to be more stable than gentoo-sources, it appears; take a look at the versions and descriptions from emerge. -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] gentoo-sources-2.4.22-r1 sound
I tried using esd and directly play audio, no difference. I'm using the ALSA i8x0 driver for my on-board soundchip. has this somehow to do with why gentoo-sources-2.4.22-r1 are masked? if not, what else could cause this behaviour? No promises that this will fix anything, but there has been a lot of traffic on Alsa-Devel about problems like this. I use a different chip from Via, and adding this option helped me. Try adding an option to your /etc/modules.d/alsa file for the Intel chips: alias snd-card-0 snd-i8x0 (or whatever yours actually is) option snd-i8x0 dxs_support=4 Just add the option line. Leave the existing line alone. Try options 0-4 and see which works best for you. It might help. These require a reboot for me, but you might be able to just start and stop Alsa. I don't know. Good luck, and no guarantees! - Mark -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.22-r1 and reiser
On Tue, Dec 09, 2003 at 11:51:23AM +0100, Guy Van Sanden wrote: I treid gentoo-sources 2.4.22-r1 today because of my ongoing problems with 2.4.20-r9, but it is unreasonably slow on reiser internal tree checks. Does anyone else have this problem? This may be related: http://thread.gmane.org/gmane.linux.gentoo.user/56828 - O -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] Gentoo-sources
Title: Message Thanks!! Jeff -Original Message-From: Jesper Frickmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 5:45 PMTo: [EMAIL PROTECTED]Subject: Re: [gentoo-user] Gentoo-sourcesHere is my Netfilter configuration on a 2.6-test8 kernel: M Connection tracking (required for masq/NAT) M FTP protocol support M IRC protocol support M TFTP protocol support M Amanda backup protocol support M Userspace queueing via NETLINK M IP tables support (required for filtering/masq/NAT) M limit match support M IP range match support M MAC address match support M Packet type match support M netfilter MARK match support M Multiple port match support M TOS match support M recent match support M ECN match support M DSCP match support M AH/ESP match support M LENGTH match support M TTL match support M tcpmss match support M Helper match support M Connection state match support M Connection tracking match support M Owner match support M Packet filtering M REJECT target support M Full NAT M MASQUERADE target support M REDIRECT target support NETMAP target support SAME target support [*] NAT of local connections (READ HELP) M Basic SNMP-ALG support (EXPERIMENTAL) M Packet mangling M TOS target support M ECN target support M DSCP target support M MARK target support CLASSIFY target support M LOG target support M ULOG target support M TCPMSS target support M ARP tables support M ARP packet filtering M ARP payload mangling ipchains (2.2-style) support ipfwadm (2.0-style) supportAs far as I remeber, one of the modules also required this under QoS and/or Fair queuing: [*] Packet classifier API TC index classifier M Routing table based classifier Firewall based classifier U32 classifier Good luck!JesperChase Jeffery D wrote: Does anyone have a list of kernel settings for build time that includes iptables/netfilter/mangaling ? I'm having a heck of a time Building the kernel. I continually get errors or genkernel won't get past "Make Modules". I've looked at the log in var but thats not much help. Any help would be greatly appreciated. Jeff -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Gentoo-sources
Here is my Netfilter configuration on a 2.6-test8 kernel: M Connection tracking (required for masq/NAT) M FTP protocol support M IRC protocol support M TFTP protocol support M Amanda backup protocol support M Userspace queueing via NETLINK M IP tables support (required for filtering/masq/NAT) M limit match support M IP range match support M MAC address match support M Packet type match support M netfilter MARK match support M Multiple port match support M TOS match support M recent match support M ECN match support M DSCP match support M AH/ESP match support M LENGTH match support M TTL match support M tcpmss match support M Helper match support M Connection state match support M Connection tracking match support M Owner match support M Packet filtering M REJECT target support M Full NAT M MASQUERADE target support M REDIRECT target support NETMAP target support SAME target support [*] NAT of local connections (READ HELP) M Basic SNMP-ALG support (EXPERIMENTAL) M Packet mangling M TOS target support M ECN target support M DSCP target support M MARK target support CLASSIFY target support M LOG target support M ULOG target support M TCPMSS target support M ARP tables support M ARP packet filtering M ARP payload mangling ipchains (2.2-style) support ipfwadm (2.0-style) support As far as I remeber, one of the modules also required this under QoS and/or Fair queuing: [*] Packet classifier API TC index classifier M Routing table based classifier Firewall based classifier U32 classifier Good luck! Jesper Chase Jeffery D wrote: Gentoo-sources Does anyone have a list of kernel settings for build time that includes iptables/netfilter/mangaling ? I'm having a heck of a time Building the kernel. I continually get errors or genkernel won't get past "Make Modules". I've looked at the log in var but thats not much help. Any help would be greatly appreciated. Jeff -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Gentoo-sources
Jesper Frickmann wrote: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head Can you turn off that HTML thingy please? HTML mails on a public mailing list is rude. Thanks, Norberto pgp0.pgp Description: signature
Re: [gentoo-user] gentoo-sources and freeswan won't compile
On Thursday 11 September 2003 04:17 am, Mike Williams wrote: On Thursday 11 September 2003 05:53, Mike Diehl I'm trying to get FreeSwan IPsec installed on my machines. I emerged a fresh copy of the latest gentoo sources. Then I patched it with the latest freeswan kernel patch. But, when I compile bzImage, I get pages of error messages. To save bandwidth, the error message can be seen at: Are you using the (super-)freeswan ebuild? There is a bit at the top about what kernel you need. I'm using the super-freeswan ebuild. But this ebuild is just for the USERSPACE utilities: * net-misc/super-freeswan Latest version available: 1.99.7.3 Latest version installed: 1.99.7.3 Size of downloaded files: 2,561 kB Homepage:http://www.freeswan.ca/code/super-freeswan/ Description: Super FreeS/WAN IPSec Userspace Utilities I've done an emerge -C gentoo-sources and deleted the linux* directories in /usr/src. Then I've re-emerged gentoo-sources. So, when I do make menuconfig, I only get the option of enabling IPSec, but this isn't the FreeSwan version! I don't get the FreeSwan IPSec until I apply the patch from their website. After applying the patch, the resulting kernel won't compile. The error messages are at: http://dominion.dyndns.org/error.txt The .config file can be seen at: http://dominion.dyndns.org/config.txt. Thanx in advance, Mike Diehl. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources and freeswan won't compile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 11 September 2003 05:53, Mike Diehl (Encrypted email prefer red) wrote: Hi all. I'm trying to get FreeSwan IPsec installed on my machines. I emerged a fresh copy of the latest gentoo sources. Then I patched it with the latest freeswan kernel patch. But, when I compile bzImage, I get pages of error messages. To save bandwidth, the error message can be seen at: Are you using the (super-)freeswan ebuild? There is a bit at the top about what kernel you need. - -- Mike Williams -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/YEu5InuLMrk7bIwRAvkfAKCMPlUvgoJxFm06w1NORwmQjseMUQCghjg/ 3TCC3peUcmASWnNs9t4qIyU= =mr/s -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.20-r2 vs. r6
On Monday 08 September 2003 22:22, Mark Knecht wrote: Hi, Where can I find out what was changed from rev to rev on gentoo-sources? I'd like to understand what's different in the sources between the 2.4.20-r2 I had been running and the 2.4.20-r6 that I switched to today. The online package database doesn't say much at this level, and points only toward very generic homepages. Thanks, Mark The file /usr/portage/sys-kernel/gentoo-sources/ChangeLog should have enough information for you. -- Tom Wesley pgp0.pgp Description: signature
RE: [gentoo-user] gentoo-sources-2.4.20-r2 vs. r6
The file /usr/portage/sys-kernel/gentoo-sources/ChangeLog should have enough information for you. -- Tom Wesley Thanks Tom. I'll check it out. Cheers, Mark -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.20-r2 vs. r6
On 2003.09.08 17:29, Mark Knecht wrote: The file /usr/portage/sys-kernel/gentoo-sources/ChangeLog should have enough information for you. -- Tom Wesley Thanks Tom. I'll check it out. etcat -c packagename This is a fairly new way to do things as well, kinda nice. -- Chris I I feel like a wet parking meter on Darvon! pgp0.pgp Description: PGP signature
Re: [gentoo-user] gentoo-sources-2.4.20-r2 vs. r6
On Monday 08 September 2003 22:57, Chris I wrote: On 2003.09.08 17:29, Mark Knecht wrote: The file /usr/portage/sys-kernel/gentoo-sources/ChangeLog should have enough information for you. -- Tom Wesley Thanks Tom. I'll check it out. etcat -c packagename This is a fairly new way to do things as well, kinda nice. But it seems this only shows the most recent additions, so wouldn't show the r2 to r6 changes -- Tom Wesley pgp0.pgp Description: signature
Re: [gentoo-user] gentoo-sources-2.4.20-r2 vs. r6
On Mon, 2003-09-08 at 15:00, Tom Wesley wrote: On Monday 08 September 2003 22:57, Chris I wrote: etcat -c packagename This is a fairly new way to do things as well, kinda nice. But it seems this only shows the most recent additions, so wouldn't show the r2 to r6 changes and what it shows isn't very deep, but it is helpful: Wizard root # etcat -c gentoo-sources-2.4.20-r2 [ Results for search key : gentoo-sources-2.4.20-r2 ] * gentoo-sources-2.4.20-r2 (19 Mar 2003) : 21 Mar 2003; Jay Pfeifer [EMAIL PROTECTED] gentoo-sources-2.4.20-r2.ebuild: Wizard root # etcat -c gentoo-sources-2.4.20-r5 [ Results for search key : gentoo-sources-2.4.20-r5 ] * gentoo-sources-2.4.20-r5 (10 May 2003) : 10 May 2003; Jay Pfeifer [EMAIL PROTECTED] gentoo-sources-2.4.20-r5.ebuild: Package is currently marked stable (x86). Changes: * Added Barton SSE suport * Minor documentation fixes * Fixed USAGI issue * Other things I am forgetting to mention :) Wizard root # etcat -c gentoo-sources-2.4.20-r6 [ Results for search key : gentoo-sources-2.4.20-r6 ] * gentoo-sources-2.4.20-r6 (08 Aug 2003) : 08 Aug 2003; Daniel Ahlberg [EMAIL PROTECTED] gentoo-source-2.4.20-r6.ebuid : Apply a bunch of security fixes. Wizard root # -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] gentoo-sources
What are your kernel parameters for 1400x1050? I'm using vga=0x318 (1024x768) at the moment but anything higher like vga=0x31A|B (1280x1024) gives blurred fonts like you said. No kernel parameters IIRC. I just enabled the radeon framebuffer in the kernel. It autodetects my LCD correctly, and sets the videomode accordingly. Gwen. -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] gentoo-sources
Am Don, 2003-08-07 um 13.24 schrieb Gwendolyn van der Linden: [...] Autodetection gives a totally warped and unreadable text screen, and all 1400x1050 parameter settings I could think of (playing with color depth and refresh rate) did not work either. Some of the 1280x1024 modes did work. I've seen something like that when playing with the 2.5 kernel series (around 2.5.7x, I assume). The screen looked like an unsynced monitor, totally unreadable. What laptop/LCD/Radeon do you have? Compaq Evo N800C, Radeon Mobility 7500 w/32MB RAM, built-in TFT running @1400x1050. Video-related kernel arguments are: video=radeonfb,mtrr,ywrap which works pretty smooth with the current gentoo-2.4.20 kernel. During boot, it starts with 40x80 text display, and switches over to 1400x1050 very soon. Best regards, - Christian p.s.: Do you see an effect of your screen staying dark during boot every now and then, coming back to live if you switch the console back and forth? -- Christian Aust mailto:[EMAIL PROTECTED] icq: 84500990 - Yahoo!: datenimperator - MSN: datenimperator GPG: 3C89AD72 -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] gentoo-sources
quote who=Gwendolyn van der Linden I have the same problem with 2.5 / 2.6-test kernels with my 7500 mobility. In my case the framebuffer does not autodetect correctly (I get a very distorted display), and only lower resolutions work properly if I hand-pick them. The 2.4 series framebuffer works like a charm without any kernel arguments! I did try to follow the differences in the radeon framebuffer code, but a whole bunch of settings and defaults have changed, and I lost my way. Anybody know more about this? I feel I didn't get enough concrete debug info to report it to the appropriate list. Did you try the vesa driver? Enable vesa driver in kernel and add the following for boot parameters where you can change vga= to whatever resolution you'd like. No, I don't think vesa runs upto 1400x1050. I can run the 2.6 kernel radeon framebuffer in 1280x1024, so I don't see a need for using the vesa framebuffer. Anyway, because I do a lot of text editing in framebuffer mode (emacs/vim), I switched back to 2.4.21, and have a nice crisp 1400x1050 display. Running an LCD on a different resultion than the actual one always seems to give fuzzy characters. My problem really is that the radeon framebuffer works so nicely for 2.4, but not for 2.6. Gwendolyn. -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] gentoo-sources
quote who=Gwendolyn van der Linden I have the same problem with 2.5 / 2.6-test kernels with my 7500 mobility. In my case the framebuffer does not autodetect correctly (I get a very distorted display), and only lower resolutions work properly if I hand-pick them. The 2.4 series framebuffer works like a charm without any kernel arguments! I did try to follow the differences in the radeon framebuffer code, but a whole bunch of settings and defaults have changed, and I lost my way. Anybody know more about this? I feel I didn't get enough concrete debug info to report it to the appropriate list. Did you try the vesa driver? Enable vesa driver in kernel and add the following for boot parameters where you can change vga= to whatever resolution you'd like. video=vesa:ywrap,mtrr vga=0x317 If you do enable vesa make sure you disable all radeon specific options in kernel. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
Chris I wrote: -1400x1050 lcd (seems we all have the same res) I havent tried lower modes yet. I don't suppose anyone knows anything about the vga= mode for 1400x1050 with vesa using an nvidia card? Chris. Many thanks on your input regarding the touchpad. Mine is now working perfectly. I'm told the synaptics driver is now in the xfree ebuild so a re-emerge will acquire and apply it. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
On 2003.08.07 07:24, Gwendolyn van der Linden wrote: Do you think that radeon FB support is generally broke in 2.6? That would be bad, because I've the very same situation as you've described: Laptop, Radeon plus TFT display running best @ 1400x1050. That is interesting... I have an Asus L3800S, with a Radeon mobility 7500. I have tried a few 2.5 kernels, and the 2.6-test1 kernel, but to no avail. Autodetection gives a totally warped and unreadable text screen, and all 1400x1050 parameter settings I could think of (playing with color depth and refresh rate) did not work either. Some of the 1280x1024 modes did work. hmm What laptop/LCD/Radeon do you have? I figure i'd throw myself back in the thread: -Gateway 450x (or 450rog or something, as their support site lists the 450 as being a pentium 4 machine, which mine isnt). -Radeon mobility 7500 w/ 32MB dedicated video ram -1400x1050 lcd (seems we all have the same res) I havent tried lower modes yet. -- Chris I FORTRAN rots the brain. -- John McQuillin pgp0.pgp Description: PGP signature
RE: [gentoo-user] gentoo-sources
Chris I wrote: As I said, framebuffer, at least for me, refuses to work no matter how hard I try, wheras with 2.4 it worked with so little effort it was eerie. This, I think, is due to the fact that the radeonfb is being worked on (was forked) again, and something broke compatability with either my 7500 mobility, or the flat panel on the laptop. I assume you have found the framebuffer information on the link below? http://www.codemonkey.org.uk/post-halloween-2.5.txt I have the same problem with 2.5 / 2.6-test kernels with my 7500 mobility. In my case the framebuffer does not autodetect correctly (I get a very distorted display), and only lower resolutions work properly if I hand-pick them. The 2.4 series framebuffer works like a charm without any kernel arguments! I did try to follow the differences in the radeon framebuffer code, but a whole bunch of settings and defaults have changed, and I lost my way. Anybody know more about this? I feel I didn't get enough concrete debug info to report it to the appropriate list. Gwendolyn. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
Gwendolyn van der Linden wrote: No, I don't think vesa runs upto 1400x1050. I can run the 2.6 kernel radeon framebuffer in 1280x1024, so I don't see a need for using the vesa framebuffer. Anyway, because I do a lot of text editing in framebuffer mode (emacs/vim), I switched back to 2.4.21, and have a nice crisp 1400x1050 display. Running an LCD on a different resultion than the actual one always seems to give fuzzy characters. What are your kernel parameters for 1400x1050? I'm using vga=0x318 (1024x768) at the moment but anything higher like vga=0x31A|B (1280x1024) gives blurred fonts like you said. -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] gentoo-sources
Do you think that radeon FB support is generally broke in 2.6? That would be bad, because I've the very same situation as you've described: Laptop, Radeon plus TFT display running best @ 1400x1050. That is interesting... I have an Asus L3800S, with a Radeon mobility 7500. I have tried a few 2.5 kernels, and the 2.6-test1 kernel, but to no avail. Autodetection gives a totally warped and unreadable text screen, and all 1400x1050 parameter settings I could think of (playing with color depth and refresh rate) did not work either. Some of the 1280x1024 modes did work. What laptop/LCD/Radeon do you have? Gwendolyn. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
Chris I wrote: As I said, framebuffer, at least for me, refuses to work no matter how hard I try, wheras with 2.4 it worked with so little effort it was eerie. This, I think, is due to the fact that the radeonfb is being worked on (was forked) again, and something broke compatability with either my 7500 mobility, or the flat panel on the laptop. I assume you have found the framebuffer information on the link below? http://www.codemonkey.org.uk/post-halloween-2.5.txt I had to go through a bit of trouble to get my synaptics touchpad working. It wasnt hard, it was just different than with 2.4 -- it threw it into a ps/2 compat mode, which i thought was how the device normally worked, wheras I had to change it to use a different mouse driver and protocol. What did you do to get it working? My laptop touchpad won't work at all. -- [EMAIL PROTECTED] mailing list
RE: [gentoo-user] gentoo-sources
p.s.: Do you see an effect of your screen staying dark during boot every now and then, coming back to live if you switch the console back and forth? No, I have not... Gwendolyn. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
Chris I [EMAIL PROTECTED] writes: [ ... ] I had to go through a bit of trouble to get my synaptics touchpad working. It wasnt hard, it was just different than with 2.4 -- it threw it into a ps/2 compat mode, which i thought was how the device normally worked, wheras I had to change it to use a different mouse driver and protocol. bah. lucky bugger, I'm one of the people who have the issue of Synaptics support being detected, but not being there. I had to remove Synaptics support from the kernel to make things work. :-/ and yes, I will eventually try to produce some constructive testing for lkml, it's just that the laptop is currently my main box, and I hate booting it... -- Terje -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
On 2003.08.04 11:46, Terje Kvernes wrote: Chris I [EMAIL PROTECTED] writes: I had to go through a bit of trouble to get my synaptics touchpad working. It wasnt hard, it was just different than with 2.4 -- it threw it into a ps/2 compat mode, which i thought was how the device normally worked, wheras I had to change it to use a different mouse driver and protocol. bah. lucky bugger, I'm one of the people who have the issue of Synaptics support being detected, but not being there. I had to remove Synaptics support from the kernel to make things work. :-/ In the kernel I used there was no synaptics option, but there was in the mm-sources which I am not currently using. What i did was set the mouse driver to synaptics, the protocol to event, and the device to /dev/input/event0. This works like a charm. cat /dev/input/eventX to find out which event interface to use. None of the mouse movements registered in the /dev/input/mice metadevice. Maybe the synaptics option fixes this, but why bother when this works perfectly fine. -Chris I pgp0.pgp Description: PGP signature
Re: [gentoo-user] gentoo-sources
On Saturday 02 August 2003 07:36 pm, Heschi Kreinick wrote: Does anyone know when the gento-sources 2.4.21 will come out? When it's ready. In the meantime you can use pfeifer-sources, which is the development branch for gentoo-sources. -Heschi -- [EMAIL PROTECTED] mailing list Personal I think we should not persue a 2.4.21 kernel, but should be working on a 2.6 kernel so that it will be ready when it reach release status. Since we are progressing so slowly on 2.4.21 I think resources would be better spent on 2.6. -- Yours, Ralph. It said Use Windows XP or better, so I installed Gentoo Linux 1.4 Register Linux User 168814 ICQ #49993234 AIM ralphdewitt jabber.org ralphdewitt GPG Public Key available at hkp://blackhole.pca.dfn.de Key id = 0DE2 085D Kernel version 2.4.20-gentoo-r2 Current Linux uptime: 4 days 2 hours 53 minutes. pgp0.pgp Description: signature
Re: [gentoo-user] gentoo-sources
On 2003.08.03 08:47, Ralph F. De Witt wrote: Personal I think we should not persue a 2.4.21 kernel, but should be working on a 2.6 kernel so that it will be ready when it reach release status. Since we are progressing so slowly on 2.4.21 I think resources would be better spent on 2.6. I don't think this is the greatest idea, but its not terribly bad. It would be best to get gentoo-sources at 2.4.21 (or 2.4.22, whatever), and keep it at 2.4. Automagically changing the generation of one's kernel on their system (with a -u world) is a rather bad idea for several reasons: 1. It is a major change. Alot of things either do not work (having alot of trouble with radeonfb, myself), or work very differently (lm_sensors). Users will be upset if this change is not blatantly obvious to them. They might as well switch to using the HURD and getting everything working the same :) 2. Some changes should not be automatic. There are still people using gcc 2.x. Should there be a 2.6 kernel, it should definately be labelled under a different name from gentoo-sources, not merely a version change. I could see portage bringing in gentoo-sources-2.6.0 and people would jump and point wow, lookie that bg change, and do a `make oldconfig` on a .config from a previous generation of kernel. 3. There already are 2.6 kernels in the tree (im sure you know this though :), they just havent been renamed from development-sources to whatever the new name would be. There isnt a whole lot of reason to maintain an alternate patchset as the kernel has alot of cool things in the kernel source itself now (preempt, etc). Should you wish for 'bleeding-edge' patches on the new series, try mm-sources, which is updated every three days or so with updates. Now, dispite my claims above, I use 2.6 (and went through hell to get it to work on my laptop). I find the power management is alot better than with 2.4. I've been using 2.5 kernels for a few months on my desktop with varying success (do not even have a backup 2.4 to fall back to, my backup kernel is also dev-sources). I had to go through a bit of trouble to get my synaptics touchpad working. It wasnt hard, it was just different than with 2.4 -- it threw it into a ps/2 compat mode, which i thought was how the device normally worked, wheras I had to change it to use a different mouse driver and protocol. Getting pcmcia working also was not hard, just different. There is also little documentation for 2.5/2.6_test kernels online in this area: google returns hundreds of lkml and lkml-archived posts about xyz not working. Eventually I got my wireless card working, but not everyone has an hour or two to spend getting a brand new kernel to work properly, and i'm willing to bet that people will say i want the new kernel, but only if i can have it work _exactly_ like the old one As I said, framebuffer, at least for me, refuses to work no matter how hard I try, wheras with 2.4 it worked with so little effort it was eerie. This, I think, is due to the fact that the radeonfb is being worked on (was forked) again, and something broke compatability with either my 7500 mobility, or the flat panel on the laptop. I agree that having 2.6 in gentoo is a great idea, but look at how long it took to switch from having gcc 2.x to having gentoo install gcc 3.2 as the new default compiler. 3.0 and 3.1 were around for people to use, but switching users cold-turkey was avoided. At this stage, anybody wanting to use 2.6 knows it is in portage. It said Use Windows XP or better, so I installed Gentoo Linux 1.4 This is, indeed, the funniest thing I have ever heard in my life, and I am actually writing it down on a post-it so I will never forget it. :) -Chris I pgp0.pgp Description: PGP signature
Re: [gentoo-user] gentoo-sources
Ralph F. De Witt wrote: On Saturday 02 August 2003 07:36 pm, Heschi Kreinick wrote: Does anyone know when the gento-sources 2.4.21 will come out? When it's ready. In the meantime you can use pfeifer-sources, which is the development branch for gentoo-sources. -Heschi -- [EMAIL PROTECTED] mailing list Personal I think we should not persue a 2.4.21 kernel, but should be working on a 2.6 kernel so that it will be ready when it reach release status. Since we are progressing so slowly on 2.4.21 I think resources would be better spent on 2.6. That's just plain silly. It is impossible to gather, create or apply arrange desired patches onto a 2.6 kernel before the code has been finalised and frozen into a milestone. It's asking someone to work with a kernel that doesn't exist. Any patches prepared now may be utterly useless later on. With regards. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
gabriel wrote: On August 2, 2003 07:44 pm, Svein Harald Soleim wrote: Does anyone know when the gento-sources 2.4.21 will come out? the answer is, as always: when it's ready. Next question: when will it be ready? :-) I'm using pfeifer-sources-2.4.21-pre4 for now. Norberto -- $ man women No manual entry for women pgp0.pgp Description: signature
Re: [gentoo-user] gentoo-sources
On August 2, 2003 07:44 pm, Svein Harald Soleim wrote: Does anyone know when the gento-sources 2.4.21 will come out? the answer is, as always: when it's ready. -- a little science may take one away from God; much science brings one back - roger bacon -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 03 August 2003 02:12, gabriel wrote: On August 2, 2003 07:44 pm, Svein Harald Soleim wrote: Does anyone know when the gento-sources 2.4.21 will come out? the answer is, as always: when it's ready. hehe, as long as 2.4.22 doesn't come out in the meanwhile or even worse 2.6.0 ;) - -- gnuPG key: ID 915B0745 at http://pgp.mit.edu/ http://www.fribyte.uib.no/~svein/PublicKey.asc Key fingerprint = 0123 B179 0994 F5C7 12D3 F253 E0AA 6A67 915B 0745 Registered Linux User #319622 'The maths is easy,' said Chaos. 'AH? WELL, MATHS', said Death, dismissively. 'GENERALLY I NEVER GET MUCH FURTHER THAN SUBTRACTION.' Svein Harald Soleim -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/LFXT4KpqZ5FbB0URAksGAJsHJG3D6jnXg549MUovCYATsuH8ZwCfWWmU ynVDp7IBtJgfPgXU5vbEyEM= =g5qB -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
NSS. Why answer at all. I think this guy is looking for a constructive answer instead of one that challenges a response, such as yours. Tom Veldhouse - Original Message - From: gabriel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 02, 2003 7:12 PM Subject: Re: [gentoo-user] gentoo-sources On August 2, 2003 07:44 pm, Svein Harald Soleim wrote: Does anyone know when the gento-sources 2.4.21 will come out? the answer is, as always: when it's ready. -- a little science may take one away from God; much science brings one back - roger bacon -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources
Does anyone know when the gento-sources 2.4.21 will come out? When it's ready. In the meantime you can use pfeifer-sources, which is the development branch for gentoo-sources. -Heschi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.20-r4 and r5
On Sat, 31 May 2003 09:37:04 +0200 Tony Clark [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 31 May 2003 05.46, Jonathan Kelly wrote: On Fri, 30 May 2003 16:03:54 -0500 Charlton Harrison [EMAIL PROTECTED] wrote: I have the same problem. My dual-processor P3-500 crashed within minutes of installing r5. I had to back down to r2. Hmm, yeah, me too. But before I realized I had a problem I trashed the 2.4.20-r2 source directory, and there is no -r2 ebuild in portage now? How/where can I get an older version of an ebuild that the system thinks is out of date?? Is this a generic portage problem?? You can do it a couple of ways, I've tried neither but they should work. Copy the gentoo-sources-2.4.20-r5 to gentoo-sources-2.4.20-r2 and put it in your local portage tree, else you should find the patch file in /usr/portage/distfiles and manually apply the patch. That seems a bit sad ... oh well, I guess it's back to vanilla for me. tony - -- Contract ASIC and FPGA design. Telephone +46 702 894 667 http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x633E2623 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUBPthbpWkjRGZD9pCjAQIxRwQAzUeMQBQ07vQeGZKK7baN0C26MY0XdzoO YYWmsGhXTCKmhV4t59f1E9qjbV0EQ7j20P6WHOTSiViybkpY/fAfv9iJpSmalpxo QPE8uxXPwVMRJ1UMxc4vKqCrAmG7dPn1i4ht8gFp/3i/3uBRyhGIoWkDB+OO1MaL tTlclhwNUKg= =zX3g -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list -- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.20-r4 and r5
I have the same problem. My dual-processor P3-500 crashed within minutes of installing r5. I had to back down to r2. On Thu, May 29, 2003 at 12:45:22PM +0100, Dhruba Bandopadhyay wrote: On Thu, 2003-05-29 at 08:41, Tony Clark wrote: Does anyone have these patched kernels running correctly on a SMP x86 machine? I have r2 working fine on my dual athlon machine but I can't get r4 and r5 to work correctly on the same machine. It seems to be losing interrups or I would suggest you file a bug about it. -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.20-r4 and r5
On Fri, 30 May 2003 16:03:54 -0500 Charlton Harrison [EMAIL PROTECTED] wrote: I have the same problem. My dual-processor P3-500 crashed within minutes of installing r5. I had to back down to r2. Hmm, yeah, me too. But before I realized I had a problem I trashed the 2.4.20-r2 source directory, and there is no -r2 ebuild in portage now? How/where can I get an older version of an ebuild that the system thinks is out of date?? Is this a generic portage problem?? Cheers. Jonathan. On Thu, May 29, 2003 at 12:45:22PM +0100, Dhruba Bandopadhyay wrote: On Thu, 2003-05-29 at 08:41, Tony Clark wrote: Does anyone have these patched kernels running correctly on a SMP x86 machine? I have r2 working fine on my dual athlon machine but I can't get r4 and r5 to work correctly on the same machine. It seems to be losing interrups or I would suggest you file a bug about it. -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list -- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.20-r4 and r5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 31 May 2003 05.46, Jonathan Kelly wrote: On Fri, 30 May 2003 16:03:54 -0500 Charlton Harrison [EMAIL PROTECTED] wrote: I have the same problem. My dual-processor P3-500 crashed within minutes of installing r5. I had to back down to r2. Hmm, yeah, me too. But before I realized I had a problem I trashed the 2.4.20-r2 source directory, and there is no -r2 ebuild in portage now? How/where can I get an older version of an ebuild that the system thinks is out of date?? Is this a generic portage problem?? You can do it a couple of ways, I've tried neither but they should work. Copy the gentoo-sources-2.4.20-r5 to gentoo-sources-2.4.20-r2 and put it in your local portage tree, else you should find the patch file in /usr/portage/distfiles and manually apply the patch. tony - -- Contract ASIC and FPGA design. Telephone +46 702 894 667 http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x633E2623 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUBPthbpWkjRGZD9pCjAQIxRwQAzUeMQBQ07vQeGZKK7baN0C26MY0XdzoO YYWmsGhXTCKmhV4t59f1E9qjbV0EQ7j20P6WHOTSiViybkpY/fAfv9iJpSmalpxo QPE8uxXPwVMRJ1UMxc4vKqCrAmG7dPn1i4ht8gFp/3i/3uBRyhGIoWkDB+OO1MaL tTlclhwNUKg= =zX3g -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gentoo-sources-2.4.20-r1
On 03 Feb 2003 17:46:17 +1030 Chris van der Pennen [EMAIL PROTECTED] wrote: Has anyone tried the gentoo-sources-2.4.20-r1 kernel? Have they had any issues with it, and is it better than 2.4.19-r10? Chris worked with it for a while without any issues, and right now running 2.4.20-r1 with win4lin sources without any issues either -- [EMAIL PROTECTED] mailing list
