[gentoo-dev] Portage question

[gentoo-dev] Portage question

[Christopher Burgess]

How do I emerge a package, but before it's built apply my own patches to the
source?
e.g. use emerge to download the source, unpack it etc - stop it here, do my
own mods to the source - then let emerge build and install it.

The main reason is that I am having some problems with xfree4.1.0 locking up
on with my radeon card (on startx it just locks up and sends the monitor
into power save mode) unless I use the "noaccel" option which is horribly
slow and I don't get DRI with that. I have searched the xfree mailing lists
and found a small hand patch which might fix it, but rather than downloading
it manually (the xfree source) I'd rather use emerge. However to be able to
do this on other packages (modifying the source before emerge builds) would
be useful.
Also is there anyone else having a Radeon problem with xfree?

Thanks

Chris

Re: [gentoo-dev] Portage question

[Mikael Hallendal]

Den 25 Aug 2001 21:54:57 +0100 skrev Christopher Burgess:
> How do I emerge a package, but before it's built apply my own patches to the
> source?
> e.g. use emerge to download the source, unpack it etc - stop it here, do my
> own mods to the source - then let emerge build and install it.
> 
> The main reason is that I am having some problems with xfree4.1.0 locking up
> on with my radeon card (on startx it just locks up and sends the monitor
> into power save mode) unless I use the "noaccel" option which is horribly
> slow and I don't get DRI with that. I have searched the xfree mailing lists
> and found a small hand patch which might fix it, but rather than downloading
> it manually (the xfree source) I'd rather use emerge. However to be able to
> do this on other packages (modifying the source before emerge builds) would
> be useful.
> Also is there anyone else having a Radeon problem with xfree?

Hi!

You can do this by:

ebuild package.ebuild unpack
apply your changes
ebuild package.ebuild qmerge

If this is a patch that others would have need of (and it doesn't break
anything for folks with other graphic cards) we should consider adding
it by default.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden

Re: [gentoo-dev] Portage question

[Daniel Robbins]

On Sat, Aug 25, 2001 at 11:06:01PM +0000, Mikael Hallendal wrote:

> You can do this by:
> 
> ebuild package.ebuild unpack
> apply your changes
> ebuild package.ebuild qmerge

That last step should be "ebuild package.ebuild merge", not qmerge.
A qmerge will skip the install step and bomb out.

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] Portage question

[Mikael Hallendal]

Den 25 Aug 2001 15:19:28 -0600 skrev Daniel Robbins:
> On Sat, Aug 25, 2001 at 11:06:01PM +0000, Mikael Hallendal wrote:
> 
> > You can do this by:
> > 
> > ebuild package.ebuild unpack
> > apply your changes
> > ebuild package.ebuild qmerge
> 
> That last step should be "ebuild package.ebuild merge", not qmerge.
> A qmerge will skip the install step and bomb out.

Damn, correct, I always mix them up :) sorry about that.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden

Re: [gentoo-dev] Portage question

[Djamil ESSAISSI]

well well well , tell me , have you ever screwed around with a voodoo3 lately ? i'm having a hard time getting some descent framerate out of it ...at 4.1.0 

On Sat, 25 Aug 2001 21:54:57 +0100
"Christopher Burgess" <chris@uknet.demon.co.uk> wrote:

:-)How do I emerge a package, but before it's built apply my own patches
:-)to the
:-)source?
:-)e.g. use emerge to download the source, unpack it etc - stop it here,
:-)do my
:-)own mods to the source - then let emerge build and install it.
:-)
:-)The main reason is that I am having some problems with xfree4.1.0
:-)locking up
:-)on with my radeon card (on startx it just locks up and sends the
:-)monitor
:-)into power save mode) unless I use the "noaccel" option which is
:-)horribly
:-)slow and I don't get DRI with that. I have searched the xfree mailing
:-)lists
:-)and found a small hand patch which might fix it, but rather than
:-)downloading
:-)it manually (the xfree source) I'd rather use emerge. However to be
:-)able to
:-)do this on other packages (modifying the source before emerge builds)
:-)would
:-)be useful.
:-)Also is there anyone else having a Radeon problem with xfree?
:-)
:-)Thanks
:-)
:-)Chris
:-)
:-)
:-)_______________________________________________
:-)gentoo-dev mailing list
:-)gentoo-dev@cvs.gentoo.org
:-)http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
:-)


-- 
================================================
System Administrateur / Support Technique
Tel:01.58.64.22.44 - Fax:01.58.64.26.81

Djamil ESSAISSI
============================================================
www.francexpress.com - www.serveur-express.com
Hébergement professionnel & Location de serveurs dédiés
Tel:01.58.64.26.44 Fax:01.58.64.26.81 djamil@francexpress.com

[gentoo-dev] portage question

[Leon Chiver]

I've installed gentoo and I must say that I'm very pleased whith it. 
Marvelous job.
But there's still one feature I'm missing and which regards the update 
procedure: wouldn't it be nice if we could upgrade from one version of a 
package to another by only downloading the diff? A few days before I've 
installed mozilla-1.0, today I emerged 1.0.1. But I had to download the 
entire 1.0.1 archive, instead of only a diff file. For people with a 
limited internet access this would be a really great feature.
Does anyone know, is such an improvement planned?

Anyway, marvelous job, a great 10x.
Leon

Re: [gentoo-dev] portage question

[Henti Smith]

On Tue, 01 Oct 2002 23:09:14 +0000
Leon Chiver <leon@level7.ro> wrote:

> I've installed gentoo and I must say that I'm very pleased whith it. 
> Marvelous job.
> But there's still one feature I'm missing and which regards the update 
> procedure: wouldn't it be nice if we could upgrade from one version of a 
> package to another by only downloading the diff? A few days before I've 
> installed mozilla-1.0, today I emerged 1.0.1. But I had to download the 
> entire 1.0.1 archive, instead of only a diff file. For people with a 
> limited internet access this would be a really great feature.
> Does anyone know, is such an improvement planned?

I had a look on the bugzilla page and did a few searches .. didn't se anything that pertains to this, but I have to admit .. 
In the image of gentoo this should have been in portage already. 

being able to update packages just with patches would be really nice for us low bandwidth users .. 

Henti Smith 

Re: [gentoo-dev] portage question

[Evan Read]

On Wed, Oct 02, 2002 at 09:22:06AM +0200, Henti Smith wrote: > On Tue, 01
Oct 2002 23:09:14 +0000 > Leon Chiver <leon@level7.ro> wrote: > > > I've
installed gentoo and I must say that I'm very pleased whith it.  > >
Marvelous job. > > But there's still one feature I'm missing and which
regards the update > > procedure: wouldn't it be nice if we could upgrade
from one version of a > > package to another by only downloading the diff?
A few days before I've > > installed mozilla-1.0, today I emerged 1.0.1.
But I had to download the > > entire 1.0.1 archive, instead of only a diff
file. For people with a > > limited internet access this would be a really
great feature. > > Does anyone know, is such an improvement planned? > > I
had a look on the bugzilla page and did a few searches .. didn't se
anything that pertains to this, but I have to admit ..  > In the image of
gentoo this should have been in portage already.  > > being able to update
packages just with patches would be really nice for us low bandwidth users
..  >

There was a thread about why the kernel stuff isn't done that way.  It was 
discussed that it is very hard to allow for people that sit at very 
different kernel versions to be able to upgrade with one ebuild.  Yes, one 
can do all the checks to see what is needed to go from 2.4.x to 2.4.19 (or 
even 2.2.x to 2.4.19) and just fetch the right diff, but that is much more 
difficult than "get latest source, unpack into /usr/src and patch".

There is nothing stopping anyone from creating thes ebuild themselves and 
posting them on the web say "diff2.4.16to2.4.19.ebuild" and giving people 
the ability to use them , even if they don't get commited.

Back to Mozilla, mozilla is a less complicated beast.  If someone has a 
diff, then numberous ebuilds can be created to cover all the bases, or 
build the logic into one ebuild.  Maybe email the maintainer to ask "why 
not" and if he says "because", then write one yourself ;)

-- 
Evan Read
http://eread.freeshell.org

"The future comes 60 minutes an hour no matter who you are or what you 
do." 
	The Screwtape Letters - C.S. Lewis

Re: [gentoo-dev] portage question

[Alexander Gretencord]

On Wednesday 02 October 2002 09:39, Evan Read wrote:
> On Wed, Oct 02, 2002 at 09:22:06AM +0200, Henti Smith wrote: > On Tue, 01
> Oct 2002 23:09:14 +0000 > Leon Chiver <leon@level7.ro> wrote: > > > I've
> installed gentoo and I must say that I'm very pleased whith it.  > >
> Marvelous job. > > But there's still one feature I'm missing and which
> regards the update > > procedure: wouldn't it be nice if we could upgrade
> from one version of a > > package to another by only downloading the diff?
> A few days before I've > > installed mozilla-1.0, today I emerged 1.0.1.
> But I had to download the > > entire 1.0.1 archive, instead of only a diff
> file. For people with a > > limited internet access this would be a really
> great feature. > > Does anyone know, is such an improvement planned? > > I
> had a look on the bugzilla page and did a few searches .. didn't se
> anything that pertains to this, but I have to admit ..  > In the image of
> gentoo this should have been in portage already.  > > being able to update
> packages just with patches would be really nice for us low bandwidth users
> ..  >

Sorry for that but you _had_ to see that mess. Didn't think mutt would do such 
stuff or do you fake your User-Agent Header and are using Outlook? :)

> There was a thread about why the kernel stuff isn't done that way.  It was
> discussed that it is very hard to allow for people that sit at very
> different kernel versions to be able to upgrade with one ebuild.  Yes, one
> can do all the checks to see what is needed to go from 2.4.x to 2.4.19 (or
> even 2.2.x to 2.4.19) and just fetch the right diff, but that is much more
> difficult than "get latest source, unpack into /usr/src and patch".

Huh? What's so difficult about unpack source from version x, unpack from 
version y run a diff over the two directories and put that into 
patch-source-package z.

Now lets say we want to update our kernel from gentoo-sources-2.4.18 to 
gentoo-sources-2.4.19-r7. Portage sees there's already a linux-2.4.18.tar.bz2 
so we don't download the linux-2.4.19.tar.bz2 from kernel.org but instead 
download the patch from 2.4.18 to 2.4.19, unpack the 2.4.18 into our new 
directory, patch it to 2.4.19 and then patch in the stuff that makes a 
gentoo-sources-r7 out of it.

I don't see where this would be a problem either with the kernel or any other 
package. Of course you'd need quite some patches on the servers for that 
thats true :)

> There is nothing stopping anyone from creating thes ebuild themselves and
> posting them on the web say "diff2.4.16to2.4.19.ebuild" and giving people
> the ability to use them , even if they don't get commited.

No, don't build it into the ebuilds, let portage do it. The ebuild has nothing 
to do with it!


Alex
-- 
"They that can give up essential liberty to obtain a little temporary safety 
deserve neither liberty nor safety."
Benjamin Franklin

Re: [gentoo-dev] portage question

[Paul de Vrieze]

On Wednesday 02 October 2002 11:02, Alexander Gretencord wrote:
>
> Now lets say we want to update our kernel from gentoo-sources-2.4.18 to
> gentoo-sources-2.4.19-r7. Portage sees there's already a
> linux-2.4.18.tar.bz2 so we don't download the linux-2.4.19.tar.bz2 from
> kernel.org but instead download the patch from 2.4.18 to 2.4.19, unpack the
> 2.4.18 into our new directory, patch it to 2.4.19 and then patch in the
> stuff that makes a gentoo-sources-r7 out of it.
>
> I don't see where this would be a problem either with the kernel or any
> other package. Of course you'd need quite some patches on the servers for
> that thats true :)
>
> No, don't build it into the ebuilds, let portage do it. The ebuild has
> nothing to do with it!
>

I wish it was so simple. The only way that portage is going to know about 
patches is when we tell portage about them. This would involve some file that 
describes how to get from source 1 to source 2. It also only would work when 
the ebuild doesn't explicitly unpack the source file. 

In short this is very complex and not really supported by portages original 
design. It would be nice though, but at the moment there are more important 
things to do for portage.

Paul

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

Re: [gentoo-dev] portage question

[Toby Dickenson]

(resend)

On Wednesday 02 Oct 2002 10:12 am, Paul de Vrieze wrote:
> On Wednesday 02 October 2002 11:02, Alexander Gretencord wrote:

> > No, don't build it into the ebuilds, let portage do it. The ebuild has
> > nothing to do with it!

> I wish it was so simple. The only way that portage is going to know about
> patches is when we tell portage about them. 

It could be made simple, with no changes to portage, if this bandwidth 
optimisation was encapsulated inside the download process....

If the uncompressed tar archives were made available for download from an 
rsync server then we could replace wget with a wrapper script that chooses a 
previously downloaded archive of an older version of the same package, and 
uses rsync to transfer the differences.


A few years ago this project <http://rproxy.samba.org/> tried to integrate 
exactly this process directly into the http protocol. It seems to be dead now 
:-(

Re: [gentoo-dev] portage question

[Toby Dickenson]

(re-re-send)


On Wednesday 02 Oct 2002 10:12 am, Paul de Vrieze wrote:
> On Wednesday 02 October 2002 11:02, Alexander Gretencord wrote:

> I wish it was so simple. The only way that portage is going to know about
> patches is when we tell portage about them.


It could be made simple, with no changes to portage, if this bandwidth 
optimisation was encapsulated inside the download process....

If the uncompressed tar archives were made available for download from an 
rsync server then we could replace wget with a wrapper script that chooses a 
previously downloaded archive of an older version of the same package, and 
uses rsync to transfer the differences.


A few years ago this project <http://rproxy.samba.org/> tried to integrate 
exactly this process directly into the http protocol. It seems to be dead now 
:-(

Re: [gentoo-dev] portage question

[Henti Smith]

> Huh? What's so difficult about unpack source from version x, unpack from 
> version y run a diff over the two directories and put that into 
> patch-source-package z.
> 
> Now lets say we want to update our kernel from gentoo-sources-2.4.18 to 
> gentoo-sources-2.4.19-r7. Portage sees there's already a linux-2.4.18.tar.bz2 
> so we don't download the linux-2.4.19.tar.bz2 from kernel.org but instead 
> download the patch from 2.4.18 to 2.4.19, unpack the 2.4.18 into our new 
> directory, patch it to 2.4.19 and then patch in the stuff that makes a 
> gentoo-sources-r7 out of it.

This should be fairly easy to implement .. 
patches have a naming standard as well .. or should have anyway .. 

having a look at kernel stuff .. the naming is : 

patch-2.4.19.bz2

So .. if you have linux-2.4.15.tar.bz2 installed portage know to grab 

patch-2.4.16.bz2
patch-2.4.17.bz2
patch-2.4.18.bz2
patch-2.4.19.bz2

and applying them in order to linux-2.4.15.tar.bz2

Seems pretty simple and straight forward to me ... 

> I don't see where this would be a problem either with the kernel or any other 
> package. Of course you'd need quite some patches on the servers for that 
> thats true :)
> 
> No, don't build it into the ebuilds, let portage do it. The ebuild has nothing 
> to do with it!

I agree ... this should be handled in portage .. not the ebuild .. 
yes there should be a PATCH_SRC_URI setting for the patches but thats about it 

Henti 

Re: [gentoo-dev] portage question

[Christian Skarby]

I kind of like the idea of this feature, but AFAIK are diffs most usefull
when there are little difference from the source-files we already have.
I.e. as soon as all the code is changed a diff-file will include both the
old and the new source. If we implement this feature I think it would be
nice to put some logic into it so that it can (f.ex. by looking at
file-sizes) decide if one should download a patch or two or rather
download the full source.

Christian

>> Huh? What's so difficult about unpack source from version x, unpack
>> from  version y run a diff over the two directories and put that into
>> patch-source-package z.
>>
>> Now lets say we want to update our kernel from gentoo-sources-2.4.18
>> to  gentoo-sources-2.4.19-r7. Portage sees there's already a
>> linux-2.4.18.tar.bz2  so we don't download the linux-2.4.19.tar.bz2
>> from kernel.org but instead  download the patch from 2.4.18 to 2.4.19,
>> unpack the 2.4.18 into our new  directory, patch it to 2.4.19 and then
>> patch in the stuff that makes a  gentoo-sources-r7 out of it.
>
> This should be fairly easy to implement ..
> patches have a naming standard as well .. or should have anyway ..
>
> having a look at kernel stuff .. the naming is :
>
> patch-2.4.19.bz2
>
> So .. if you have linux-2.4.15.tar.bz2 installed portage know to grab
>
> patch-2.4.16.bz2
> patch-2.4.17.bz2
> patch-2.4.18.bz2
> patch-2.4.19.bz2
>
> and applying them in order to linux-2.4.15.tar.bz2
>
> Seems pretty simple and straight forward to me ...
>
>> I don't see where this would be a problem either with the kernel or
>> any other  package. Of course you'd need quite some patches on the
>> servers for that  thats true :)
>>
>> No, don't build it into the ebuilds, let portage do it. The ebuild has
>> nothing  to do with it!
>
> I agree ... this should be handled in portage .. not the ebuild ..  yes
> there should be a PATCH_SRC_URI setting for the patches but thats about
> it
>
> Henti
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] portage question

[Henti Smith]

On Wed, 2 Oct 2002 13:53:39 +0200 (CEST)
"Christian Skarby" <christian@skarby.no> wrote:

> I kind of like the idea of this feature, but AFAIK are diffs most usefull
> when there are little difference from the source-files we already have.
> I.e. as soon as all the code is changed a diff-file will include both the
> old and the new source. If we implement this feature I think it would be
> nice to put some logic into it so that it can (f.ex. by looking at
> file-sizes) decide if one should download a patch or two or rather
> download the full source.

the whole point of a diff/patch file is to make only changes made to the source .. not carry the original .. 

Henti Smith 

Re: [gentoo-dev] portage question

[Christian Skarby]

> On Wed, 2 Oct 2002 13:53:39 +0200 (CEST)
> "Christian Skarby" <christian@skarby.no> wrote:
>
>> I kind of like the idea of this feature, but AFAIK are diffs most
>> usefull when there are little difference from the source-files we
>> already have. I.e. as soon as all the code is changed a diff-file will
>> include both the old and the new source. If we implement this feature
>> I think it would be nice to put some logic into it so that it can
>> (f.ex. by looking at file-sizes) decide if one should download a patch
>> or two or rather download the full source.
>
> the whole point of a diff/patch file is to make only changes made to the
> source .. not carry the original ..
>
> Henti Smith

:) I think I'll have to be a bit more spesific on this

If we have a source-1.0 that reads
/*
 This is a lovely comment
*/

and then a source-1.1 that reads
/*
 This comment make more sense
*/

a diff would look something like
/*
- This is a lovely comment
+ This comment make more sense
*/

As we see the diff is larger than both the sources, and this will happen
as soon as the all the source is fully replaced. This is actually a worst
case scenario and hence not a good example, nevertheless I believe that
fetching source-1.0.tar.gz and patch-1.1.tar.gz often will result in
downloading more than just source-1.1.tar.gz, thus it will not be cost
effective to get the patch unless one already have the sources that the
patch applies to. Therefor I believe that if we should implement this into
portage it would be nice to have some checks looking at what relevant
source-files we already have, how large the patches are and how large the
full source download is. Then it should be quite easy to consider what
will be the least time consuming download.

Taking in consideration that many (most/all?) gentoo-users keep their
systems up to date at all times with emerge -u world it probably would be
a great ideá just with patches, but I think that new installs and install
of packages with huge rewrites will benefit from having clean full source
downloads. Thus I suggest these checks.

Please arrest me if I am wrong ..

All the best,
Christian

Re: [gentoo-dev] portage question

[Henti Smith]

> :) I think I'll have to be a bit more spesific on this
> 
> If we have a source-1.0 that reads
> /*
>  This is a lovely comment
> */
> 
> and then a source-1.1 that reads
> /*
>  This comment make more sense
> */
> 
> a diff would look something like
> /*
> - This is a lovely comment
> + This comment make more sense
> */


this is verey understandable ...... but 

If you as a developer is going to change he's whole codebase and only 
bump the version from 1.0 to 1.0.1 ... peopl are going to shoot you !!! 
That is also another reason why people MUST learn to read changelogs before 
doing anything as a whole codebase shift should be commented in thw changelog.

> As we see the diff is larger than both the sources, and this will happen
> as soon as the all the source is fully replaced. This is actually a worst
> case scenario and hence not a good example, nevertheless I believe that
> fetching source-1.0.tar.gz and patch-1.1.tar.gz often will result in
> downloading more than just source-1.1.tar.gz, thus it will not be cost
> effective to get the patch unless one already have the sources that the
> patch applies to. Therefor I believe that if we should implement this into
> portage it would be nice to have some checks looking at what relevant
> source-files we already have, how large the patches are and how large the
> full source download is. Then it should be quite easy to consider what
> will be the least time consuming download.

99,9% of the time .. a patch will be smaller then the whole tarball .. 
yes there are duplicate lines in a patch .. but no changes will be THAT drastic as 
to make the patch bigger then the original source. 

Even if it is ... the developer who releases a patch bigger then the target complete source 
is not worth he's salt in this comunity

> Taking in consideration that many (most/all?) gentoo-users keep their
> systems up to date at all times with emerge -u world it probably would be
> a great ideá just with patches, but I think that new installs and install
> of packages with huge rewrites will benefit from having clean full source
> downloads. Thus I suggest these checks.

I think size is the only consern here .. as long as the md5 checks out only size should be considered.
It's smaller to download patches from verion x to y then to download y completely.

therefor get patches ... 

If there are people that HAVE to use source ... look at something like USE to pass the variable in 

USE="-x -gtk -patch" will no use X, GTK, or patches to make ... 
USE="x gtk patch" will use X, GTK and patches not the source ...

> Please arrest me if I am wrong ..

woulnd't dream of it ... freedom is what this is all about :) 

Henti Smith 

Re: [gentoo-dev] portage question

[Alexander Gretencord]

On Wednesday 02 October 2002 14:23, Christian Skarby wrote:

> Taking in consideration that many (most/all?) gentoo-users keep their
> systems up to date at all times with emerge -u world it probably would be
> a great ideá just with patches, but I think that new installs and install
> of packages with huge rewrites will benefit from having clean full source
> downloads. Thus I suggest these checks.

I don't. I only upgrade if I need to or am feeling like it. I like gentoo for 
it's system not for the bleeding stuff. Of course I like current software 
(running my desktop on newest kernel, newest nvidia drivers etc.) but I don't 
really wanna bleed :)

And there's things like the new ghostscript 7.05 ebuild which just sucks! 
(Already bugreported lets see). I won't install the whole of gimp just 
because some ebuild writer was too lazy or using gimp anyway ... :)


Alex

-- 
"They that can give up essential liberty to obtain a little temporary safety 
deserve neither liberty nor safety."
Benjamin Franklin

Re: [gentoo-dev] Portage question

[Christopher Burgess]

> You can do this by:

> ebuild package.ebuild unpack
> apply your changes
> ebuild package.ebuild qmerge

Thanks, I'll try that  - btw (so I can learn more about the portage system)
a) what's the difference/function of emerge and ebuild, and b) why "qmerge"
in the above command, what does that stand for/mean?

> If this is a patch that others would have need of (and it doesn't break
> anything for folks with other graphic cards) we should consider adding
> it by default.

Well I'm trying to find more about patch, though it doesn't seem official,
and there isn't much comment on it. See:
http://www.xfree86.org/archives/xfree86/2001-Jul/0017.shtml
I will post here when I have found out if it works for me.

Regards,

Chris Burgess

Re: [gentoo-dev] Portage question

[Mikael Hallendal]

Den 25 Aug 2001 22:23:22 +0100 skrev Christopher Burgess:
> > You can do this by:
> 
> > ebuild package.ebuild unpack
> > apply your changes
> > ebuild package.ebuild qmerge
>
> Thanks, I'll try that  - btw (so I can learn more about the portage system)
> a) what's the difference/function of emerge and ebuild, and b) why "qmerge"
> in the above command, what does that stand for/mean?

As in the mail from Drobbins, it should be merge not qmerge.

Ebuild is a tool which lets you excecute step by step in the
build-process. Please look at 'man ebuild' and 'man emerge' for the
differences.

> > If this is a patch that others would have need of (and it doesn't break
> > anything for folks with other graphic cards) we should consider adding
> > it by default.
> 
> Well I'm trying to find more about patch, though it doesn't seem official,
> and there isn't much comment on it. See:
> http://www.xfree86.org/archives/xfree86/2001-Jul/0017.shtml
> I will post here when I have found out if it works for me.

Thanks.

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden

[gentoo-dev] useradd q

[Dave Bresson]

Ok, quick question.  After getting everything running and what not on my
new rc4_pre2 machine, i'm starting to customize everything to my liking.
I'd like to be able to create my own non-root account (for obvious
reasons) however i'm getting an error with adduser like so "PAM
authentication failed".  This comes after typing in the password for my
new account i'm trying to create.  Surely there must be some PAM setting
which is wrong by default or something, since you should be able to create
a new account without too much fuss.  Or perhaps there is some new tool
for creating new accounts i don't know about, as i'm still acclimating to
my new gentoo environs.  Could anyone shine some light on this problem?


thanks,


dave

Re: [gentoo-dev] useradd q

[Achim Gottinger]

Dave Bresson wrote:

> Ok, quick question.  After getting everything running and what not on my
> new rc4_pre2 machine, i'm starting to customize everything to my liking.
> I'd like to be able to create my own non-root account (for obvious
> reasons) however i'm getting an error with adduser like so "PAM
> authentication failed".  This comes after typing in the password for my
> new account i'm trying to create.  Surely there must be some PAM setting
> which is wrong by default or something, since you should be able to create
> a new account without too much fuss.  Or perhaps there is some new tool
> for creating new accounts i don't know about, as i'm still acclimating to
> my new gentoo environs.  Could anyone shine some light on this problem?
>
> thanks,

Make /etc/pam.d/useradd as follows:
---------------
auth            required    pam_rootok.so
account      required    pam_pwdb.so
session         required    pam_pwdb.so
--------------
copy this to /etc/pam.d/shadow

and things should work better you still get a warning like
useradd: PAM chauthok failed.

I will look into this a little deeper

achim~

>
>
> dave
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

[gentoo-dev] portage question

[John McCaskey]

Ok this is a totally lame question. ;)  I have everything working alright
now thanks to the answers on the hde and hdg.  However I don't really know
anything about portage and I was wondering if there is a website with some
general info on it like the main site for it or such, or anything else that
would be helpful.  I tried to search for it on the web but failed to find
anything.  So if anyone can point me to something about it that would be
appreciated.  Thanks.

John McCaskey