headers
Bret Towe | 1 Sep 2004 01:05
Picon

Re: Compaq Presario 905 AU with ATI IGP 320M video

i have a emachines m5310 that has a ati igp 320m
it does work fine in linux it has some accerlated 3d
but from what i hear its missing some compression thing that reduces
the amount of stuff that has to be transfered from ram which helps
with large textures i guess and it does show in celestia
it is better with 'accelerated 3d' than with software gl anyhow

dont expect to play ut2k3 in linux lets put it that way for now
(somewhat playable in xp with latest drivers btw)

On Wed, 01 Sep 2004 09:22:41 +1200, Nick Rout <nick <at> rout.co.nz> wrote:
> 
> On Tue, 31 Aug 2004 16:18:35 -0400
> "Stephen P. Becker" <geoman <at> gentoo.org> wrote:
> 
> > This really isn't discussion material for gentoo-dev.
> 
> maybe, and maybe not. it is probably of concern to  dev's as to what
> works and what doesn't on gentoo, although this may be better thought of
> as an upstream issue. Also I saw some relevant posts from "spyderous" on
> the forums, and I think he inhabits this list.
> 
> > Have you tried
> > the forums or google yet?
> >
> 
> I thought the answer to that may have been obvious from me saying "I can find plenty
> of older info suggesting that 3d hardware accel will not work with this
> chipset, and that vesa was the only driver, but I am not sure if any of
> that has changed since 2003 " Yes I have googled and forumed. I am an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Stubbs | 1 Sep 2004 01:18
Picon
Favicon

Re: repoman failing (seemingly) incorrectly

On Wednesday 01 September 2004 06:40, Armando Di Cianno wrote:
> Before I file a bug on repoman, I thought I'd toss this out there, and
> see what everyone thinks.  This problem I'm having is just about to
> drive me crazy, and, since I'd rather not ignore repoman, I'm not sure
> what to do.
>
> My problem is chronicled here:
> http://dev.gentoo.org/~fafhrd/whydoesrepomanhateme.html

> Currently, in cvs, I've committed "virtual/gnustep-back 
> gnustep-base/gnustep-back-xlib" to .../profiles/base/virtuals (atm, 
> whereever GNUstep builds requires x11) and "virtual/gnustep-back 
> gnustep-base/gnustep-back-art" to .../profiles/default-linux/virtuals (not 
> committed yet) as that backend looks a lot better where it's possibly 
> supported. There exist other backends, but they are in heavier development, 
> and I do not plan on supporting them, atm.      

Check gentoo-x86/profiles/profiles.desc for a list of the profiles that 
repoman uses for each architecture.

Regards,
Jason Stubbs

--
gentoo-dev <at> gentoo.org mailing list
Permalink | Reply | 1 comment |
headers
Mike Frysinger | 1 Sep 2004 01:28
Picon
Favicon
Gravatar

Re: per-package environment variables.

On Tuesday 31 August 2004 06:26 pm, Antst GD wrote:
> For the moment both solutions looks ugly for me. At least I can't
> imaging simple and easy-to-understand syntax for package.env, which will
> look nice and will parce without problems.
>
> What do you think about?

most of what you proposed seems excessive and confusing (and like you say, 
ugly) ... a cleaner/simpler solution can be taken from your work though i 
think ...

we have a directory:
/etc/profile/packages.env/

in this directory we have simple bash (bash because we can just source it and 
be done with it) files which line up in a similar fashion to the portage 
tree ... for example, if i want an env file for bash, i would have:
/etc/profile/packages.env/app-shells/bash

i think this is about all we need ... and like Antst pointed out, this looks 
like it'd be real simple to implement ...
-mike
Permalink | Reply | 13 comments |
headers
Stephen P. Becker | 1 Sep 2004 01:50
Picon
Favicon

Re: Compaq Presario 905 AU with ATI IGP 320M video

This material would really be better suited to the gentoo-desktop 
mailing list.  This list is for issues concerning the development of gentoo.

Steve

Nick Rout wrote:
> On Tue, 31 Aug 2004 16:18:35 -0400
> "Stephen P. Becker" <geoman <at> gentoo.org> wrote:
> 
> 
>>This really isn't discussion material for gentoo-dev. 
> 
> 
> maybe, and maybe not. it is probably of concern to  dev's as to what
> works and what doesn't on gentoo, although this may be better thought of
> as an upstream issue. Also I saw some relevant posts from "spyderous" on
> the forums, and I think he inhabits this list.
> 
> 
>>Have you tried 
>>the forums or google yet?
>>
> 
> 
> I thought the answer to that may have been obvious from me saying "I can find plenty
> of older info suggesting that 3d hardware accel will not work with this
> chipset, and that vesa was the only driver, but I am not sure if any of
> that has changed since 2003 " Yes I have googled and forumed. I am an
> experienced linux user, and I do know how to search for information.
> google is full of references to polish speaking email forums, its not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anton Starikov | 1 Sep 2004 02:00
Picon
Picon
Favicon

Re: per-package environment variables.

I didn't get it :)
I'm one person, Anton Starikov and Antst :) antst - just my mailbox :))

So, /etc/portage/packages.env/ seems to be good. That sound cleaner, 
right. But, can you imaging, I'm going to edit 10 files next time, when 
to ICC, for example, will be added some nice optimization flag which I'm 
going to use.
So, the basic point is that they are really "per-package" sollution. If 
we want to keep it. I guess it can be extended, to have directories like 
/etc/portage/packages.env/bash/
Where you can put multiple files similar to /etc/env.d/
So, you can make one env file, and make just symbolic links to it for 
different packages.
So, idea to include some kind of sollution which not strictly 
"per-package". So, you can define something, and easy include/exclude it 
for different packages.

Mike Frysinger wrote:
> On Tuesday 31 August 2004 06:26 pm, Antst GD wrote:
> 
>>For the moment both solutions looks ugly for me. At least I can't
>>imaging simple and easy-to-understand syntax for package.env, which will
>>look nice and will parce without problems.
>>
>>What do you think about?
> 
> 
> most of what you proposed seems excessive and confusing (and like you say, 
> ugly) ... a cleaner/simpler solution can be taken from your work though i 
> think ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Stubbs | 1 Sep 2004 02:03
Picon
Favicon

Re: repoman failing (seemingly) incorrectly

On Wednesday 01 September 2004 07:07, Carsten Lohrke wrote:
> On Tuesday 31 August 2004 23:40, Armando Di Cianno wrote:
> > ... if anyone has a moment, _please_ read over that page, and smack me
> > over the head (if need be) to point out what's wrong, or let me know
> > if you're stumped to.
>
> Appreciated this "feature", too - repoman/portage.50 sux. :)

Ermm...?

Regards,
Jason Stubbs

--
gentoo-dev <at> gentoo.org mailing list
Permalink | Reply | 1 comment |
headers
Anton Starikov | 1 Sep 2004 02:13
Picon
Picon
Favicon

Re: per-package environment variables.

But with /etc/profile/packages.env/ there is only one thing, which not 
good enough. I really can't make a one look and see what and where I 
define. I mean, if I look into one file, I see something like, let say, 
30 lines, which looks clear and understandable for me.
But with recursive subdirectories...Simple sollution is ls -R, but if I 
have 30 packages with redefinition, and, let say, average two ENV files 
in each directory... That going to be a difficult for simple 
understanding, probably :) Of course directories more logic. But I guess 
  it will be never 300 definitions of some ENV's for 300 packages. 
But...who know..

And about confusing...I just think that mostly this ENV files will be 
used for some kind of typical job. So, you will not have 100 files for 
100 packages. But raser you will have 10 files, no more (there is just 
not so many things to define :) ). And will include some of them to some 
of 100 packages, more than one at the same time, probably.

Anton Starikov aka Antst :)

Mike Frysinger wrote:
> On Tuesday 31 August 2004 06:26 pm, Antst GD wrote:
> 
>>For the moment both solutions looks ugly for me. At least I can't
>>imaging simple and easy-to-understand syntax for package.env, which will
>>look nice and will parce without problems.
>>
>>What do you think about?
> 
> 
> most of what you proposed seems excessive and confusing (and like you say,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armando Di Cianno | 1 Sep 2004 02:16
Picon
Favicon

Re: repoman failing (seemingly) incorrectly

On 2004-08-31 19:18:55 -0400 Jason Stubbs <jstubbs <at> gentoo.org> wrote:

>> My problem is chronicled here:
>> http://dev.gentoo.org/~fafhrd/whydoesrepomanhateme.html

> Check gentoo-x86/profiles/profiles.desc for a list of the profiles 
> that 
> repoman uses for each architecture.

Just to follow up, in case anyone else has this problem, this, indeed, 
was the problem.

Thanks, Jason!

__Armando Di Cianno

--
gentoo-dev <at> gentoo.org mailing list
Permalink | Reply | 0 comments |
headers
Nicholas Jones | 1 Sep 2004 02:26
Picon
Favicon

Re: per-package environment variables.


Disclaimer:
Don't mind that it starts off ranting. I actually like some
of the implementation ideas presented. Any discussion on my
dillusions of grandjeur or my inability to spell will get
you smited in a very not nice way.

> 1) Possibility to change ENV during building some packages.

I certainly hope you realize the depths to which people go to
make your life miserable when attempting to do support.

Something like this will happen:
	source /etc/profile

Which does something great to the users console, but will
probably have destructive results otherwise. Bugs will now
require you to review not only the settings that portage
reports, but you will also have to check every related script
that the user decides to make part of the build process.
Unless we ignore anyone using these features. Would be funny
in that bated, ironic-reversal kinda way.

If they decide to alias something, it will have an affect
IN THE BUILD. Portage makes a lot of effort to prevent
things like this right now. unsets + unalias, are a quick
example.

> 2) it should be automatic, no more definition of environment variables 
> and manual emerging packages. No more spaming /etc/make.conf with some
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anton Starikov | 1 Sep 2004 02:51
Picon
Picon
Favicon

Re: per-package environment variables.

Nicholas Jones wrote:
>>1) Possibility to change ENV during building some packages.
> 
> 
> I certainly hope you realize the depths to which people go to
> make your life miserable when attempting to do support.
Yes :) There is something
> The idea is that it takes effort. If it's not trivial, you have to
> LEARN to make it work. Having super-easy things is great, but not
> when it happens to make FIXING it super complicated, developers lose.
Yes, but sollution can be simple...some kind of, probably, limitation 
applied, at first (for example ONLY env variables, nothing more in this 
script, onle A=B syntax). And second, idea to get this environment 
BEFORE something. So, it should be absolutely equal, theoretically, to 
something like this:
CC="bla-bla-bla" CFLAGS="bla-bla-bla" I_WANT_THAT="bla-bla-bla" emerge 
nice_package
I thing that is OK, because anyway users can do it now :)

> Some of this might be nice. If you're going to make this kind of
> effort, why not integrate it into the ebuild?
If I uderstand right, you mean make copy of 10 ebuilds into local 
overlay and edit them twice a week? When new version of ebuild is 
coming? :) And in the middle have troubles, because fresh version will 
be at first automatically updated with standard ENV and at morning I'll 
reallize that my code don't want to be linked against of library XXX, 
which was compiled at night with g77 instead ifc or lf95 or pgf90 or 
something else ? :) That is boring. I've checked already :)

>>4) BTW, in such case it also not bad to have option to include something
(Continue reading)

Permalink | Reply | 0 comments |

Gmane