[gentoo-dev] Gstreamer + Use Flags

2005-08-16 Thread Fabian Zeindl
Hi

Some time ago I opened a bug concerning Gstreamer's useflags, which are
handled completely unlogical at the moment. *every* package depending on the
gstreamer multimediaframework brings it's own use flags for gstreamer-plugins,
instead of putting the use flags centrally in the gstreamer package itself.

I know this has been discussed before on bugzilla and the lists, and I read
through all discussions I found. I certainly don't want to waste any
developer's time with this, but the current handling of this is unlogical and
not the gentoo way. I think that many users share my opinion here although
some devs (foser e.g.) don't agree with this.

https://bugs.gentoo.org/show_bug.cgi?id=100872 and
https://bugs.gentoo.org/show_bug.cgi?id=84663 decribe the problem.

So my proposal is putting UseFlags for additional GstreamerPlugins in the
Gstreamerpackage and remove it in the packages depending on Gstreamer (totem
for example).

Benefits of this:
 * you have ONE place where you can decide what gstreamer plugins to install
 * you don't have 'wasted useflags'. It's not logical if I compile amarok
without mad and still can use mad, cause another application already used this
useflag...
 * you don't have to reemerge EVERY single application that has gstreamer
useflags, when you want to install ONE additional gstreamerplugin, that's
completely UNNECESSARY
 * people don't get confused when using xine and useflags doesn't have an
impact. (mp3 doesn't work - recompile amarok with xine and mad - mp3 still
doesn't work cause mad useflag doesn't influence xine)
 
CONS:
 * you have to understand that you use gstreamer: when you want to have
additional capabilities simple recompiling of amarok (p.e.) doesn't work, you
have to recompile gstreamer or emerge -uDN world

For me the PROS outweigh the CONS. What do you say?

greetings and hoping that I don't annoy anyone with this mail

fabian


-- 
 ... I want something good to die for
To make it beautiful to live.
I want a new mistake, lose is more than hesitate.
Do you believe it in your head?

  - Queens of the Stone Age - Go with the Flow

I prefer signed/encrypted Mail: 
Fingerprint: CFE8 38A7 0BC4 3CB0 E454  FA8D 04F9 B3B6 E02D 25BA

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Looking for developers for a new 'Planet' web-app

2005-08-16 Thread Daniel Drake

Hi,

As the Planet Gentoo admin (http://planet.gentoo.org), I often get feature 
ideas and requests for ways to enhance the Planet website.


Right now, a python script called planet (www.planetplanet.org) powers the 
site. planet is a nice simple script, which is invoked by cron every hour - it 
fetches the weblog content for all the developers it knows about, finds the 
most recent 60 articles, and formats them into a HTML page which is saved to 
an area of disk served up by apache at http://planet.gentoo.org.


planet is a nice system and makes it dead easy to set up a Planet-style 
aggregator. However the feature requests that I am recieving go out of the 
scope of what a simple script can do.


Examples of what people are requesting:
- Ability to browse the 'archives' (i.e. the content which has dropped off the
  end of the page, which planet discards)
- Ability to search the content and the archives
- Ability to browse by Gentoo herd, i.e. view the weblogs of the apache
  maintainers.

I'm seeking people who would be interested in developing and maintaining a 
more dynamic Planet web-application which could handle features such as these.


I hope that this will create a new open-source project (or an effort to extend 
an existing system, if there are any) which would be used to power Planet 
Gentoo in the future, and be easily available for other communities who wish 
to use it.


I envision this being a database-driven application but all implementation 
details will be up to the volunteers who take up the task :)
Unfortunately I don't have time to get heavily involved with the development, 
but I will oversee the project.


This is open to everyone (not only Gentoo developers...) - infact I'd like to 
see this bringing a few more people into Gentoo development.


If you are interested, please send me an email ([EMAIL PROTECTED]) with the 
following info:


 1. Your preferred web development languages/platforms/etc.
 2. Other languages/platforms you would be prepared to work with should the
majority of other volunteers wish to work with those instead.
 3. Your previous experience developing web-applications and working with
related software (don't worry if this isn't much).
 4. Any experience you have with blogs/aggregation/RSS/...

Feel free to spam me with related ideas/comments if you have any :)

Thanks,
Daniel
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app

2005-08-16 Thread PaweĊ‚ Madej

Daniel Drake wrote:


Hi,

As the Planet Gentoo admin (http://planet.gentoo.org), I often get 
feature ideas and requests for ways to enhance the Planet website.


Right now, a python script called planet (www.planetplanet.org) 
powers the site. planet is a nice simple script, which is invoked by 
cron every hour - it fetches the weblog content for all the developers 
it knows about, finds the most recent 60 articles, and formats them 
into a HTML page which is saved to an area of disk served up by apache 
at http://planet.gentoo.org.


planet is a nice system and makes it dead easy to set up a 
Planet-style aggregator. However the feature requests that I am 
recieving go out of the scope of what a simple script can do.


Examples of what people are requesting:
- Ability to browse the 'archives' (i.e. the content which has dropped 
off the

  end of the page, which planet discards)
- Ability to search the content and the archives
- Ability to browse by Gentoo herd, i.e. view the weblogs of the apache
  maintainers.

I'm seeking people who would be interested in developing and 
maintaining a more dynamic Planet web-application which could handle 
features such as these.


I hope that this will create a new open-source project (or an effort 
to extend an existing system, if there are any) which would be used to 
power Planet Gentoo in the future, and be easily available for other 
communities who wish to use it.


I envision this being a database-driven application but all 
implementation details will be up to the volunteers who take up the 
task :)
Unfortunately I don't have time to get heavily involved with the 
development, but I will oversee the project.


This is open to everyone (not only Gentoo developers...) - infact I'd 
like to see this bringing a few more people into Gentoo development.


If you are interested, please send me an email ([EMAIL PROTECTED]) with 
the following info:


 1. Your preferred web development languages/platforms/etc.
 2. Other languages/platforms you would be prepared to work with 
should the

majority of other volunteers wish to work with those instead.
 3. Your previous experience developing web-applications and working with
related software (don't worry if this isn't much).
 4. Any experience you have with blogs/aggregation/RSS/...

Feel free to spam me with related ideas/comments if you have any :)

Thanks,
Daniel


As i suppose i could help some programming with that site but not 
earlier than on november. If you will need some help then we could talk 
more about then.


--
Paul
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app

2005-08-16 Thread Daniel Drake

Sebastian Bergmann wrote:

 Have you looked at the software [1] that runs on Planet PHP [2]?

 --
 [1] http://svn.bitflux.ch/repos/public/planet-php/trunk/
 [2] http://www.planet-php.net/


Thanks, I hadn't heard of that. It seems in tune to what we need: Storing 
entries in a MySQL database, providing a loose form of archives and a search 
facility. I'll make sure we consider this.


Daniel
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] eselect modules

2005-08-16 Thread Jeremy Huddleston
I've recently updated opengl-update to use the eselect framework.  I
think the team has done a great job as it was extremely easy to port the
bash script to an eselect module.  However, when I placed it in the
portage tree, it sparked a little bit of a policy discussion between
myself and the core eselect devs on how to best include modules in the
tree, so I'd like to let other devs chime in as well.

Firstly if you don't know what eselect is, check out:
http://www.gentoo.org/proj/en/eselect/index.xml 

The eselect developers want to keep all eselect modules in their svn
repository and distributed through a single package (app-admin/eselect).
Their main reasons for this are better QA and less overhead for releases
and merging.

I have a problem with this policy because:
1) Stability of the modules should not be tied to stability of the core
package.  Basically, I'd like to determine when my modules get pushed
into stable without considering how it'll effect the eselect modules of
other developers.  Similarly, I don't want bugs in another module
holding up my module from going into stable.

2) Not all users will want all modules.  The goal of the eselect project
is to provide a framework to replace java-config, motif-config,
gcc-config, binutils-config, opengl-update, etc, but not all users will
need all modules.

3) Some modules require extra files (opengl-update installs header
files, gcc-config installs a wrapper, etc), and the app-admin/eselect
package is not the correct place to provide these files.

Also, what should the correct way to introduce these modules into
portage?
Should we keep them in the packages they're replacing
(x11-base/opengl-update)?
Should we place them in a new package in the same category as the script
they're replacing (x11-base/eselect-opengl)?
Should we place them in app-admin/eselect-module name or perhaps
app-eselect/module name?

Note that for backwards compatibility in all cases,
x11-base/opengl-update will RDEPEND on this eselect module and install a
backwards-compatible frontend to the eselect module until all packages
in portage have been updated to use the eselect module instead.



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


Re: [gentoo-dev] eselect modules

2005-08-16 Thread Donnie Berkholz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremy Huddleston wrote:
| The eselect developers want to keep all eselect modules in their svn
| repository and distributed through a single package (app-admin/eselect).
| Their main reasons for this are better QA and less overhead for releases
| and merging.

And unnecessarily tying releases together of things that have no reason
to be tied together.

It's fine to keep all the source in the same repository, but don't lock
releases of unrelated modules together. That's the same thing X went
through and has finally learned with the modularization effort.

Thanks,
Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDAjzGXVaO67S1rtsRAt/jAKC5iEbkyTvqTAm44EB1PVur7wqDiwCcC/HD
umiI6mrs67f+YBVxDAJz/0U=
=yK5P
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] eselect modules

2005-08-16 Thread Chris Gianelloni
On Tue, 2005-08-16 at 12:21 -0700, Donnie Berkholz wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Jeremy Huddleston wrote:
 | The eselect developers want to keep all eselect modules in their svn
 | repository and distributed through a single package (app-admin/eselect).
 | Their main reasons for this are better QA and less overhead for releases
 | and merging.
 
 And unnecessarily tying releases together of things that have no reason
 to be tied together.
 
 It's fine to keep all the source in the same repository, but don't lock
 releases of unrelated modules together. That's the same thing X went
 through and has finally learned with the modularization effort.

There's also the size issue.  I use opengl-update on the LiveCD builds,
and have exactly zero need for *any* other eselect module, so why should
I be required to have them all to just get the one that I need?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


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


Re: [gentoo-dev] eselect modules

2005-08-16 Thread Ciaran McCreesh
On Tue, 16 Aug 2005 15:38:08 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| There's also the size issue.  I use opengl-update on the LiveCD
| builds, and have exactly zero need for *any* other eselect module, so
| why should I be required to have them all to just get the one that I
| need?

Heh. You complain about the size of an eselect module, and then go and
include a stinkin' great bitmap splash screen.

Anyway, I'm in favour of separate distribution of modules once eselect
reaches a 1.0 release. Until then there's still a chance someone might
go and change the API...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp57cnfewKex.pgp
Description: PGP signature


Re: [gentoo-dev] eselect modules

2005-08-16 Thread Ciaran McCreesh
On Tue, 16 Aug 2005 21:52:25 +0200 Danny van Dyk [EMAIL PROTECTED]
wrote:
| b) The possibility to change all modules in one move in case we change
| ~   something like a default behaviour, or function names, etc.

That kind of thing shouldn't happen once a stable release is out...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpHsPftqAxYu.pgp
Description: PGP signature


[gentoo-dev] generating ChangeLog files automatically from `cvs commit`

2005-08-16 Thread Mike Frysinger
suggestion:
stop keeping ChangeLog files in CVS and instead, let them be generated 
automagically by the cvs server using the last arbitrary number of commit 
messages.  if you really want to keep a commit message out of the changelog, 
then we come up with a simple policy of prefixing the message with a period 
(to keep it hidden :P).

logic:
 - i'm lazy
 - i hate typing the samething twice (yes, bash scripting with echangelog can 
kind of take care of this) ... it doesnt handle if you want to use different 
commit messages for different files
 - shrinks ChangeLog size for packages which have been around a very long time
 - forces cvs log messages to actually be worthwhile to read and makes 
browsing cvs history much nicer (it's very easy to look at the differences 
between two files and match up a good commit message rather than trying to 
figure out what message in the ChangeLog goes with it, assuming there is one)
 - easily standardize ChangeLog format wrt to header, copyrights, licensing, 
message formatting, name/date format
 - generate dates in UTC down to the second rather than having devs hand type 
them in their local timezone for just the current day
 - maybe some other things i havent thought of
 - i'm lazy
-mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`

2005-08-16 Thread Jeremy Huddleston
On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote:
 suggestion:
 stop keeping ChangeLog files in CVS and instead, let them be generated 
 automagically by the cvs server using the last arbitrary number of commit 
 messages.  if you really want to keep a commit message out of the changelog, 
 then we come up with a simple policy of prefixing the message with a period 
 (to keep it hidden :P).

I like the idea.  This should force people to actually make their cvs
commit statements worth something.


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


Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app

2005-08-16 Thread Rob Cakebread

Daniel Drake wrote:


Examples of what people are requesting:
- Ability to browse the 'archives' (i.e. the content which has dropped 
  off the end of the page, which planet discards)

- Ability to search the content and the archives
- Ability to browse by Gentoo herd, i.e. view the weblogs of the apache
  maintainers.



I patched the Planet source to add all the entries to an sql
database then wrote a quick CherryPy demo [1] that uses the existing
Planet's template system.

The example just has the entries for a few random developers. You can
search the titles or full text. Source code available [2] for
the curious. You'll need dev-python/cherrypy and USE='sqlite'
dev-python/sqlobject.

If I can get ahold of the config.ini and template for the actual
Planet Gentoo I'll be able to get the herd info from usernames
(and make it look like the real deal).

[1] http://gentooexperimental.org:9898/
[2] http://dev.gentoo.org/~pythonhead/planetdb.tbz2


--
Rob Cakebread
Gentoo Linux Developer
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x96BA679B
Key fingerprint = 5E1A 57A0 0FA6 939D 3258  8369 81C5 A17B 96BA 679B
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`

2005-08-16 Thread Alec Warner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeremy Huddleston wrote:
 On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote:
 
suggestion:
stop keeping ChangeLog files in CVS and instead, let them be generated 
automagically by the cvs server using the last arbitrary number of commit 
messages.  if you really want to keep a commit message out of the changelog, 
then we come up with a simple policy of prefixing the message with a period 
(to keep it hidden :P).
 
 
 I like the idea.  This should force people to actually make their cvs
 commit statements worth something.

Also forcing a Changelog syntax makes portage's -l feature useful, since
 it attempts to parse the Changelog to provide sane entries...but some
Changelogs don't seem to be in the correct syntax that the -l
functionality requires.  With a changelog standard this tool will be
much more useful.

- -Alec Warner (antarus)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQwKM2GzglR5RwbyYAQIWDw//WqWVf7BUhU++4RjHUYeLd95xxpPo7fmk
EEebEFF7XMjIij9YYticJvOfDKsjzndU1Vkd/F27WHdDe/NCTGJQcCmTGjJfuKKa
JRlD2U5Em5QF/j93dOeRJzOIBCbNRbxQevze4fU8SBfDdB1MRb0g3Y5fd0An991h
4GiO9UtCrNmSV51R6KFCBW76YbaV7pWFhDNJRjsWLhfQZh/sCKfugduv4boJVOih
e2GIyiP4C0dUJnXlpbfsJuNsdxA783inKfSyy4p9+iuCdDd11rSvua2mz2HdZIVB
3BvWatoWTDflNpcxrmpHnmTj1MN9usC4van1Yq9KPogSBcwkIjyCmA7YVB5stFxs
e2sBGDftmBXzC3ZOCa0IiWkE3Kr4gC5eCSHkDDJ7lW+u8FojSCxUm2my5RO4rSAr
Wm0cB+LojvANZV93bz4qfF90B4IBr6w8fE6vCfC4WsoeW9G/EVtsjYvIHjvv20YZ
cLQAgWDPsOT9bxfsHgJXAKqot3erKmVksBbV6cwWvxRkjwp0k09IpbEytxxFUs+3
CtC2TOERPk2NWdsfRimRSZz0zUUBOMzSUX1+88W4L7GASG7DuuXK7TpaZvMOwxEy
UaBXhH+oAwk3lePXx/3HvQpC0T2oSUwGGr7CBR3z7VRhwAcO04AiHVt7tQie8dvO
G5eWBwF0UCE=
=Yj6C
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Devconference archives

2005-08-16 Thread Nathan L. Adams
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
 That being said, thanks to IU for doing the webcast... now everybody
 gets to see what we look like... *grin*

If you're like me, you have a perfect face... for email. :P

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDAqRe2QTTR4CNEQARAseAAKCjAE5e4Lu5nfw337AcKR1jiPc8/ACeNdTs
ALsdqQbyiJnsaoc5a+0J3H8=
=vCyM
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] USE_EXPAND and IUSE

2005-08-16 Thread Jason Stubbs
On Wednesday 22 June 2005 02:07, Donnie Berkholz wrote:
 Alec Warner wrote:
  Donnie Berkholz wrote:
  The reasoning for that is that hardware support doesn't make sense as
  USE flags, so it should be something else. In this case, that was
  INPUT_DEVICES. We haven't been able to take much advantage of it yet,
  but it may work out better after X's upstream modularization.
 
So those make no sense but 3dnow,sse,sse2,makemyprocessorgrow are
  fine as USE flags?  Those also enable support for special hardware.

 I think we had that argument already. Try searching the archives and see
 whether you can find it.

I tried searching but no luck. Care to elaborate on how building optional 
support for drivers doesn't fall under the umbrella of building optional 
support?

-- 
Jason Stubbs


pgprRwCi8t55Z.pgp
Description: PGP signature


[gentoo-portage-dev] [PATCH] sane USE_EXPAND + IUSE check

2005-08-16 Thread Brian Harring
Hola-
basically, use_expand'd vars need to be exempted from IUSE checks, as 
long as the USE_EXPAND var is in IUSE.
This does that.
~harring
Index: ebuild.sh
===
RCS file: /var/cvsroot/gentoo-src/portage/bin/ebuild.sh,v
retrieving revision 1.201.2.40
diff -u -r1.201.2.40 ebuild.sh
--- ebuild.sh   9 Aug 2005 11:25:44 -   1.201.2.40
+++ ebuild.sh   17 Aug 2005 00:50:27 -
@@ -15,6 +15,7 @@
if [ -f ${T}/environment ]; then
source ${T}/environment /dev/null
fi
+   USE_EXPAND=$(echo ${USE_EXPAND} | tr A-Z a-z)
 fi
 
 if [ -n $# ]; then
@@ -130,7 +131,19 @@

# Make sure we have this USE flag in IUSE
if ! hasq ${u} ${IUSE} ${E_IUSE}  ! hasq ${u} ${PORTAGE_ARCHLIST} 
selinux; then
-   echo QA Notice: USE Flag '${u}' not in IUSE for 
${CATEGORY}/${PF} 2
+   local x
+   local invalid=1
+   for x in ${USE_EXPAND}; do
+   if [ ${u:0:${#x}} == ${x} ]; then
+   if hasq ${x} ${IUSE} ${E_IUSE}; then
+   unset invalid
+   fi
+   break
+   fi
+   done
+   if [ -n ${invalid} ]; then
+   echo QA Notice: USE Flag '${u}' not in IUSE for 
${CATEGORY}/${PF} 2
+   fi
fi
 
for x in ${USE}; do


pgpVlG8eJOxdX.pgp
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH] sane USE_EXPAND + IUSE check

2005-08-16 Thread Jason Stubbs
You hijacked a thread again...

On Wednesday 17 August 2005 09:52, Brian Harring wrote:
 basically, use_expand'd vars need to be exempted from IUSE checks, as
 long as the USE_EXPAND var is in IUSE.

I don't really like the idea of this without a companion patch that provides 
some way to get a list of relevant env vars and their possible settings to 
the user without having to look at the ebuild. The list of possiblities 
could live in use.desc or a similar file, but at minimum the list of vars 
needs to be provided.

Another patch is also required that will allow disabling of the QA check on 
certain vars, preferably defined in a file in the tree similar to 
info_vars. This would be used for vars such as USERLAND which are profile 
defined.

In other words, don't kill the QA check without addressing the issue that 
the QA check is warning about. ;)

-- 
Jason Stubbs


pgpyAsoZCE427.pgp
Description: PGP signature