Re: [gentoo-dev] RFC: mesa.eselect

2010-11-01 Thread Ulrich Mueller
 On Sun, 31 Oct 2010, Chí-Thanh Christopher Nguyễn wrote:

 Attached you will find the eselect module which we used in the X11 
 overlay, and the configuration file from mesa.

Is there a specific reason why the list action doesn't output a
numbered list? Also the set action should accept a number argument.

Ulrich



[gentoo-dev] Re: RFC: mesa.eselect

2010-11-01 Thread Duncan
Chí-Thanh Christopher Nguyễn posted on Sun, 31 Oct 2010 23:30:36 +0100 as
excerpted:

 media-libs/mesa-7.9 has been sitting in the X11 overlay for some time
 and the X11 team are planning to move it to portage soon.
 The new release brings a number of improvements, including much better
 Gallium3D support. One feature that we would like to add to Mesa in
 Gentoo is the ability to switch between classic and gallium drivers
 via an eselect module.

I've been running the x11 overlay for some time, and had been wondering 
how I was supposed to switch between gallium and classic for Radeon.  I'd 
noticed eselect-mesa being merged, but hadn't made the connection.

So thanks for the hint!  Now I can try gallium on the r600 =:^) (and 
actually see that I had classic selected, something I thought was the 
case, but had no idea how to check, before).  I figured it should be 
possible, but hadn't really looked into how, too deeply.

FWIW, if there was anything about how that's supposed to work in the
post-install messages or the like, I must have missed it, and I'm 
/usually/ pretty good about going thru those.  So perhaps either adding 
such messages or making them a bit more visible might be useful.

Now that I know about it, I'm going to try it.  If I find any bugs, I'll 
be sure and file them. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] la-file removal and || die

2010-11-01 Thread Hanno Böck
Just stepped upon a bug on a .la-file-removal-action that I'd like to share so 
others don't repeat that bug if we'll soon mass-add la-file-removal-code to 
ebuilds.

file-roller-2.32.0.ebuild has these lines:

find ${ED}usr/$(get_libdir)/nautilus -name *.la -delete \
|| die la file removal failed

This will die if the directory in place is not found. Unfortunately, this can 
be the case here as file-roller has a use-flag nautilus and the above 
directory only get's created if this flag is set.

I don't know if there's any valid reason to add || die to the la-file-removal-
command. Anyway, the already proposed eutils-function for lafile-removal would 
probably be the best way to avoid such problems for good.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: RFC: mesa.eselect

2010-11-01 Thread Christian Faulhammer
Hi,

Chí-Thanh Christopher Nguyễn chith...@gentoo.org:
   * Accept numbers as do_set() arguments

 Taken from emacs.eselect

# target may be specified by its name or its index
if is_number ${target}; then
# numeric index, find the target's name
targets=( $(find_targets) )
[[ ${target} -ge 1  ${target} -le ${#targe...@]} ]] \
|| die -q Number out of range: ${1}
target=${targets[target-1]}
fi

 I would love to have more comments to explain in general and
specifically for the structure of MESA_DRIVERS.  The rest of the review
is mostly a matter of style.

 CONFIG_DIR=${EROOT}/usr/share/mesa

 Maybe something less generic as variable name?  Also the local x, y, z
variables could be named a bit more obvious.

 for y in classic gallium; do
   z=$(get_drivername ${family} ${y})
   [ -f ${MESA_DIR}/${z} -o -L ${MESA_DIR}/${z} ] 
 ret+=${y}  done

 I would welcome more if constructs instead of , as it makes the code
more readable.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://gentoo.faulhammer.org/


signature.asc
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild

2010-11-01 Thread Duncan
Jeroen Roovers posted on Sun, 31 Oct 2010 18:36:25 +0100 as excerpted:

[Duncan wrote...]

 However, Gentoo policy has always been that even ~arch is only
 upstream- stable packages, the ~arch keyword denoting Gentoo package
 testing (basically, the ebuild script and dependencies), /not/ upstream
 testing. In with certain exceptions, in particular for packages where
 Gentoo itself is upstream, if it's not a package that could at least in
 theory be Gentoo- stable if no bugs appear during the 30-day standard
 stabilizing period, it's not supposed to be ~arch keyworded either.
 
 This doesn't even make sense.

Well, then, perhaps the developer handbook and devmanual versions
make sense to you:

Developer Handbook:

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap4

1.d QA policy, under ~ARCH in KEYWORDS


There is a difference between using package.mask and ~arch for ebuilds.
The use of ~arch denotes an ebuild requires testing. The use of
package.mask denotes that the application or library itself is deemed
unstable. For example, if gimp-1.2.0 is the stable release from Gimp
developers, and a new bug fix release is available as 1.2.1, then a
developer should mark the ebuild as ~arch for testing in portage because
the release is deemed to be stable. In another example, if Gimp decides to
release an unstable/development series marked as 1.3.0, then these ebuilds
should be put in package.mask because the software itself is of
development quality and is not recommended by the developers for
distribution.


Devmanual:

http://devmanual.gentoo.org/keywording/index.html


The different levels of keyword are: 

arch (x86, ppc-macos) 
 Both the package version and the ebuild are widely tested, known to
 work and not have any serious issues on the indicated platform. 
~arch (~x86, ~ppc-macos) 
 The package version and the ebuild are believed to work and do not
 have any known serious bugs, but more testing is required before the
 package version is considered suitable for arch. 


As I said, ~arch keywords denote Gentoo package testing, /not/ upstream
testing.  ~arch should be stable upstream, or it belongs in package.mask,
not ~arch.  (In practice, there are exceptions, the biggest one being
where Gentoo's the upstream, such as with portage itself.  The reasoning
as I understand it is that upstream needs testing to stabilize, and since
Gentoo's it's own upstream in these cases...)

So there is indeed /some/ developer responsibility for maintaining a
reasonably stable system, even for ~arch.  If it's known-broken or
upstream is deliberately labeling it beta and saying it's not ready
for general use, it doesn't belong in ~arch either, but rather in
package.mask.

So here's your original statement to which I took issue:

 I didn't push it on all users. Maybe ~arch users, but they get to keep
 the pieces when they break their systems, if I recall correctly.

My reply:

 To some extent, yes[, however, Gentoo policy, the top quote above]

To which you say:

 No, to the full extent.

The point that I'm making is that the clear Gentoo policy as outlined
in the quotes above, is that if it's known broken, upstream beta clearly
not intended for general usage yet, or hasn't been tested by the committing
dev, it's that dev's responsibility.  Thus, the to some extent on the
~arch users get to keep the pieces bit.  It's known to be less well
tested and in fact is ~arch for the /purpose/ of getting that testing,
but if there are known serious issues, or if upstream itself doesn't
call it ready for general distribution, in general, it shouldn't be in
~arch at all, but in package.mask.

That's the clearly stated policy, whether it makes sense to you or not.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] Re: RFC: mesa.eselect

2010-11-01 Thread Duncan
Ulrich Mueller posted on Mon, 01 Nov 2010 09:43:17 +0100 as excerpted:

 On Sun, 31 Oct 2010, Chí-Thanh Christopher Nguyễn wrote:
 
 Attached you will find the eselect module which we used in the X11 
 overlay, and the configuration file from mesa.
 
 Is there a specific reason why the list action doesn't output a
 numbered list? Also the set action should accept a number argument.

You apparently missed this from the TODO list (with the note that he 
doesn't consider the TODOs a blocker for addition to the tree):

  * Accept numbers as do_set() arguments

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] Re: RFC: mesa.eselect

2010-11-01 Thread Ulrich Mueller
 On Mon, 1 Nov 2010, Duncan  wrote:

 Is there a specific reason why the list action doesn't output a
 numbered list? Also the set action should accept a number
 argument.

 You apparently missed this from the TODO list

Looks like. Sorry for that.

 (with the note that he doesn't consider the TODOs a blocker for
 addition to the tree):

   * Accept numbers as do_set() arguments

One of the points of eselect is that there is a unique user interface
in different modules. Therefore one shouldn't deviate from conventions
without a very good reason.

Besides, the list action not displaying a numbered list will break
bash completion.

Ulrich



Re: [gentoo-dev] RFC: mesa.eselect

2010-11-01 Thread Pacho Ramos
El dom, 31-10-2010 a las 23:30 +0100, Chí-Thanh Christopher Nguyễn
escribió:
 Hi,
 
 media-libs/mesa-7.9 has been sitting in the X11 overlay for some time 
 and the X11 team are planning to move it to portage soon.
 The new release brings a number of improvements, including much better 
 Gallium3D support. One feature that we would like to add to Mesa in 
 Gentoo is the ability to switch between classic and gallium drivers 
 via an eselect module.
 
 Attached you will find the eselect module which we used in the X11 
 overlay, and the configuration file from mesa. There are still some 
 things on the TODO list but I consider them not blockers for addition to 
 the tree. As this is the first eselect module I have written, I would 
 welcome your comments and pointers.
 
 TODO:
   * Add support for switching emul-linux-x86-opengl on amd64 multilib
   * Accept numbers as do_set() arguments
   * Make the code a bit more compact
 Untested:
   * Prefix support
 
 
 Best regards,
 Chí-Thanh Christopher Nguyễn
 

Is there any kind of information (doc page, news item...) planned for
explaining when it's better to switch to gallium3d and when not? For
example, one of the systems I administrate has a r300 device, but I
haven't followed at all gallium progress and, I guess, you cannot asume
most of the people know about all this. Then, I think that, for example,
a news item would be useful to know what drivers should we use.

Thanks a lot


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] EAPI versioning of files in profiles

2010-11-01 Thread Arfrever Frehtes Taifersar Arahesis
I would like to suggest improvement in handling of EAPI in profiles:
Some files could optionally end with :${EAPI}, which would be used to 
specify, which EAPI
should be used for parsing of given file. It would concern at least the 
following files:
  package.mask
  package.use
  use.force
  use.mask
  package.use.force
  package.use.mask
And maybe also use.unsatisfiable and package.use.unsatisfiable.

Examples:
  profiles/package.mask:5 could be used to mask dependency atoms with -scm or 
-live suffix
  (if EAPI=5 supports this suffix).

  profiles/base/use.mask:4 could be used to mask USE flags (which use 
EAPI=4-specific syntax)
  on all profiles inheriting from base profile.

Without support for EAPI-versioned files, such actions from above examples 
might require copying
of whole tree of profiles, adding eapi file to new profiles etc.

eapi files would still be used to specify EAPI for EAPI-unversioned files in 
given profiles.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] EAPI versioning of files in profiles

2010-11-01 Thread Fabian Groffen
On 01-11-2010 18:06:19 +0100, Arfrever Frehtes Taifersar Arahesis wrote:
 I would like to suggest improvement in handling of EAPI in profiles:
 Some files could optionally end with :${EAPI}, which would be used to 
 specify, which EAPI

Please don't use ':', neither any other special characters.  It's likely
to give problems with filesystems, and much more, such as scripts
looking at grep's output for instance.


-- 
Fabian Groffen
Gentoo on a different level



Re: [gentoo-dev] EAPI versioning of files in profiles

2010-11-01 Thread Roy Bamford
On 2010.11.01 17:06, Arfrever Frehtes Taifersar Arahesis wrote:
 I would like to suggest improvement in handling of EAPI in profiles:
 Some files could optionally end with :${EAPI}, 

[snip]
 
 -- 
 Arfrever Frehtes Taifersar Arahesis
 

Why does this remind me of GLEP55 ?

If we are going to add metadata like this, or some other way, lets make 
it consistent throughout the tree.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
gentoo-ops
forum-mods
trustees




Re: [gentoo-dev] RFC: mesa.eselect

2010-11-01 Thread Ondřej Súkup
 Best regards,
 Chí-Thanh Christopher Nguyễn


 Is there any kind of information (doc page, news item...) planned for
 explaining when it's better to switch to gallium3d and when not? For
 example, one of the systems I administrate has a r300 device, but I
 haven't followed at all gallium progress and, I guess, you cannot asume
 most of the people know about all this. Then, I think that, for example,
 a news item would be useful to know what drivers should we use.

 Thanks a lot


r300g is in good state, fully supported:)



Re: [gentoo-dev] Changes in server profiles

2010-11-01 Thread Peter Volkov
В Вск, 31/10/2010 в 16:38 +0200, Alex Alexander пишет:
 On Sun, Oct 31, 2010 at 11:50:02AM +, Markos Chandras wrote:
  On Sat, Oct 30, 2010 at 10:59:08PM -0400, Richard Freeman wrote:
   Isn't this essentially what the default profile is?  Basically server is
   just default + USE=apache2 ldap mysql snmp truetype xml.
  Well it shouldn't be like that. And if the default profile is pretty
  much the same as the server one, then please consider removing the
  server profile as it makes no sense then
 
 Please don't. The fact that there are only a few changes doesn't make it
 useless. Also, you'd be forcing all users currently using the profile to
 migrate without any real reason.

But what is the target group of this profile? It sets only 6 USE flags
that are really useless on half of servers (e.g. VPN/mail server). I'd
better set only -perl -python there to make servers less dependent on
python/perl updaters and decrease rebuilds for servers. Also it's good
idea to make them hardened only as hardened works very well for
servers. 

-- 
Peter.




Re: [gentoo-dev] Changes in server profiles

2010-11-01 Thread Markos Chandras
On Mon, Nov 01, 2010 at 08:41:34PM +0300, Peter Volkov wrote:
 В Вск, 31/10/2010 в 16:38 +0200, Alex Alexander пишет:
  On Sun, Oct 31, 2010 at 11:50:02AM +, Markos Chandras wrote:
   On Sat, Oct 30, 2010 at 10:59:08PM -0400, Richard Freeman wrote:
Isn't this essentially what the default profile is?  Basically server is
just default + USE=apache2 ldap mysql snmp truetype xml.
   Well it shouldn't be like that. And if the default profile is pretty
   much the same as the server one, then please consider removing the
   server profile as it makes no sense then
  
  Please don't. The fact that there are only a few changes doesn't make it
  useless. Also, you'd be forcing all users currently using the profile to
  migrate without any real reason.
 
 But what is the target group of this profile? It sets only 6 USE flags
 that are really useless on half of servers (e.g. VPN/mail server). I'd
 better set only -perl -python there to make servers less dependent on
 python/perl updaters and decrease rebuilds for servers. Also it's good
 idea to make them hardened only as hardened works very well for
 servers. 
 
 -- 
 Peter.
 
 
Errr no. There are also home based fileservers, media servers, routers,
radio servers blah blah blah. Not everyone needs the hardened
toolchain/kernel/security/etc. The target group are lightweight servers for home
or SOHO usage, file sharing, nfs, etc. I maintain such a server group so
I am talking based on personal experience. As I said before server usage is
not always security oriented. 
Yes, perhaps using -python/-perl might be good. 
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411  3477 F7F7 1E8E 441A C410


pgpAVjdhSzEuz.pgp
Description: PGP signature


Re: [gentoo-dev] Re: RFC: mesa.eselect

2010-11-01 Thread Chí-Thanh Christopher Nguyễn

Christian Faulhammer schrieb:

   * Accept numbers as do_set() arguments
 

  Taken from emacs.eselect
   


Thanks, this looks easier than I expected. So I will implement this 
before committing to portage.



CONFIG_DIR=${EROOT}/usr/share/mesa
 

  Maybe something less generic as variable name?  Also the local x, y, z
variables could be named a bit more obvious.
   


Will fix.


I would welcome more if constructs instead of, as it makes the code
more readable.
   


Ok, I am going to change this.


Thanks,
Chí-Thanh Christopher Nguyễn



Re: [gentoo-dev] RFC: mesa.eselect

2010-11-01 Thread Chí-Thanh Christopher Nguyễn

Pacho Ramos schrieb:

Is there any kind of information (doc page, news item...) planned for
explaining when it's better to switch to gallium3d and when not? For
example, one of the systems I administrate has a r300 device, but I
haven't followed at all gallium progress and, I guess, you cannot asume
most of the people know about all this. Then, I think that, for example,
a news item would be useful to know what drivers should we use.
   


I am not aware of official Mesa documentation which explains when 
Gallium3D should be used rather than classic. Mostly, such information 
spreads as word of mouth and sometimes as news articles on websites like 
phoronix.com.


There will be a default set for new eselect-mesa installations, so if 
you upgrade to mesa-7.9 today you will get the r300 gallium driver and 
the r600 classic driver. When we set a new default, then a news item to 
inform users about the change is certainly a good idea.



Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild

2010-11-01 Thread Jeroen Roovers
On Mon, 1 Nov 2010 10:34:21 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 Well, then, perhaps the developer handbook and devmanual versions
 make sense to you:

Stop throwing the book at me, please.


 jer



[gentoo-dev] New category for Lua related packages

2010-11-01 Thread Rafael Goncalves Martins
Hi all,

as said in my blog post [1], I'm planing to improve our support to the
Lua [2] programming language, adding packages for the libraries and
the related software. Actually we already have some libraries on the
tree but they are spread in some categories like dev-lang and
dev-libs.

I think that a first step should be create a new category, maybe
called dev-lua, for all the Lua related stuff.

Are any of you against the creation of this new category?

[1] http://rafaelmartins.eng.br/en-us/post/lua-libraries-on-gentoo/
[2] http://www.lua.org/

Best regards,

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/