On Thursday 18 August 2005 05:29, Georgi Georgiev wrote:
maillog: 18/08/2005-03:03:40(+0200): Diego 'Flameeyes' Pettenò types
media-video/mplayer:dts - Enables libdts (5.1 surround sound audio)
support
I'll commit this tomorrow, when I'll be sure it's ok after an awake
check. If nobody
On Thursday 18 August 2005 05:29, Georgi Georgiev wrote:
I am certain that I have watched DVDs that had DTS audio with 7
channels.
Yeah but I'm not sure if libdts is capable to decode them..
Anyway I changed the description to
dts - Enables libdts (DTS Coherent Acoustics decoder) support
to
Use INSTALL_MASK to keep /usr/bin/mysqld or whatever from getting installed. We
aren't generally in the habit of splitting packages into a bunch of different
ebuilds. There are exceptions, but
--Iggy
Christian Parpart wrote:
Hi all,
well, regarding the request on bug 88490 [1] (and my
Mike Frysinger wrote:
On Thursday 18 August 2005 10:28 am, Christian Parpart wrote:
Do we have a general accepted gentoo policy for this?
general policy is to not split packages (and i agree with this ...)
bind and bind-tools is split ;) Why is it so bad to split packages? (I'm
just
On Thu, 18 Aug 2005 10:13:33 -0500 Lance Albertson
[EMAIL PROTECTED] wrote:
| bind and bind-tools is split ;) Why is it so bad to split packages?
| (I'm just curious) Seems a bit odd that we can't have a library only,
| client only, etc package like the other distros. Of course, I
| understand
Luca Barbato wrote:
Christian Parpart wrote:
Using the minimal useflag for this - IMHO - is a misuse of the idea of
minimal semantically - as I do understand minimal in a way like don't
overbloat me with patches and other feature additions-alike.
minimal is about keeping the package
On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote:
2) ebuild maintenance will be a nightmare- every new version will
require again walking the source to see if the lines you've drawn for
dividing the source are still proper.
This is another good point. I have two split packages
Lance Albertson wrote:
Mike Frysinger wrote:
On Thursday 18 August 2005 10:28 am, Christian Parpart wrote:
Do we have a general accepted gentoo policy for this?
general policy is to not split packages (and i agree with this ...)
bind and bind-tools is split ;) Why is it
On Thursday 18 August 2005 11:19 am, Diego 'Flameeyes' Pettenò wrote:
I'm thinking about adding bsdmk to main tree and make ash/csh use it to
find pmake
considering the number of packages that use pmake, why do you want an eclass
for it ? i'd say just put the logic in the ebuilds themselves
On Thu, Aug 18, 2005 at 11:37:05AM -0400, Chris Gianelloni wrote:
Other distributions are also binary-only, so there's no real comparison
here. While I think having client and server type USE-flags is
really a bad idea, I don't see a problem with providing a library.
I 100% disagree with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
| Kind of curious about people's opinion on the IUSE default use flag
| thing, initial syntax was (using the above example)
| IUSE=+client server
| with client defaulting to on unless the user's config disables it-
| note,
On Thursday 18 August 2005 17:55, Mike Frysinger wrote:
considering the number of packages that use pmake, why do you want an
eclass for it ? i'd say just put the logic in the ebuilds themselves
Add all the ones we use on G/FBSD overlay, and the count increase :)
The eclass is currently in
On Thu, Aug 18, 2005 at 09:08:51AM -0700, Donnie Berkholz wrote:
Brian Harring wrote:
| Kind of curious about people's opinion on the IUSE default use flag
| thing, initial syntax was (using the above example)
| IUSE=+client server
| with client defaulting to on unless the user's config
On Thursday 18 August 2005 12:31 pm, Brian Harring wrote:
On Thu, Aug 18, 2005 at 09:08:51AM -0700, Donnie Berkholz wrote:
Brian Harring wrote:
| Kind of curious about people's opinion on the IUSE default use flag
| thing, initial syntax was (using the above example)
| IUSE=+client server
On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| Best solution in my opinon? Two use flags address this, client, and
| server. Regardless of the setting of the two, you get the library;
| from there, you just set client and server as defaulting to on, and
| packages
On Thursday 18 August 2005 19:19, Mike Frysinger wrote:
ok, but then you still have the fact that you're writting an eclass for a
single function ... isnt that the point of eutils ?
A part eutils being polluted, when pmake is used directly with bsd-style MK
definitions, bsdmk take care of most
On Thu, Aug 18, 2005 at 01:16:05PM -0400, Alec Warner wrote:
As long as there is a way provided disable the 'default use flags' in
this case referring to the IUSE=+foo stuff, with a big warning that
says crap generally isn't expected to work great with that setting on,
then thats fine. I
On Thu, Aug 18, 2005 at 01:18:17PM -0400, Mike Frysinger wrote:
Yes, very. Saves us from hacky local USE flag handling by naming them
no* or adding them to profiles.
Which then raises the question of whether or not -* in a users USE
should disable it.
I say no, since -* is mainly for
On Thu, Aug 18, 2005 at 06:24:03PM +0100, Ciaran McCreesh wrote:
On Thu, 18 Aug 2005 10:56:06 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| Best solution in my opinon? Two use flags address this, client, and
| server. Regardless of the setting of the two, you get the library;
| from
On Thursday 18 August 2005 01:28 pm, Diego 'Flameeyes' Pettenò wrote:
On Thursday 18 August 2005 19:19, Mike Frysinger wrote:
ok, but then you still have the fact that you're writting an eclass for a
single function ... isnt that the point of eutils ?
A part eutils being polluted, when
On Thursday 18 August 2005 21:33, Mike Frysinger wrote:
then why not think bigger ... call it 'bsdeutils' or something rather than
limiting yourself to bsd make
Because for a mk-based project (and fbsd/dfly/nbsd source packages) we can
just inherit bsdmk and src_compile and src_unpack are
Currently, things assigned to maintainer-wanted get the following
keywords (bugzilla, not ebuild):
* EBUILD if an ebuild is attached
* REQUEST if an ebuild is requested
I've been going through the EBUILD list at random and providing lists of
things that need to be fixed before the ebuild can be
Ciaran McCreesh wrote:
Can anyone suggest
a name? Best I can come up with is STYLE_CHECKED(nickname)...
I like the idea.
SYNTAX_CHECKED(nick) maybe?
lu
--
Luca Barbato
Gentoo/linux Developer Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero
--
On Thu, Aug 18, 2005 at 09:28:47PM +0100, Ciaran McCreesh wrote:
Bah! No I'm not, because Sven pointed out that it collides with the
bugzilla resolution. So I'm going with CHECKED instead.
Whoah! Isn't REVIEWED the perfect keyword?
--
Maurice van der Pot
Gentoo Linux Developer [EMAIL
Maurice van der Pot wrote:
On Thu, Aug 18, 2005 at 09:28:47PM +0100, Ciaran McCreesh wrote:
Bah! No I'm not, because Sven pointed out that it collides with the
bugzilla resolution. So I'm going with CHECKED instead.
Whoah! Isn't REVIEWED the perfect keyword?
or APPROVED?
--
Fabian
It's dead upstream and the ebuild need to be rewritten from scratch.
Unless there is some volenterous it will be sadly removed 2005-08-29
See bugs 77539,93725
--
gentoo-dev@gentoo.org mailing list
On Thu, Aug 18, 2005 at 11:05:43PM +0200, Grobian wrote:
Maurice van der Pot wrote:
On Thu, Aug 18, 2005 at 09:28:47PM +0100, Ciaran McCreesh wrote:
Bah! No I'm not, because Sven pointed out that it collides with the
bugzilla resolution. So I'm going with CHECKED instead.
Whoah! Isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fernando J. Pereda wrote:
I think APPROVED doesn't reflect the idea; since nobody 'approved' the
ebuild. A developer just checked it looks good and 'seems to work'.
REVIEWED or CHECKED make more sense imho.
I like REVIEWED; it seems to reflect
On Thu, 18 Aug 2005 20:22:30 -0400 Nathan L. Adams [EMAIL PROTECTED]
wrote:
| Fernando J. Pereda wrote:
| I think APPROVED doesn't reflect the idea; since nobody 'approved'
| the ebuild. A developer just checked it looks good and 'seems to
| work'. REVIEWED or CHECKED make more sense imho.
|
|
On Fri, Aug 19, 2005 at 01:06:35AM +0100, Ciaran McCreesh wrote:
On Thu, 18 Aug 2005 13:13:56 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| You're a bit vague in the 'die in pkg_setup' bit; if you're
| referencing doing the changes now, and sticking a die in, I already
| explicitly stated
On Thursday 18 August 2005 19:01, Georgi Georgiev wrote:
maillog: 18/08/2005-16:28:40(+0200): Christian Parpart types
Using the minimal useflag for this - IMHO - is a misuse of the idea of
minimal semantically - as I do understand minimal in a way like don't
overbloat me with patches and
On Thursday 18 August 2005 17:44, Chris Gianelloni wrote:
On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote:
2) ebuild maintenance will be a nightmare- every new version will
require again walking the source to see if the lines you've drawn for
dividing the source are still
On Thursday 18 August 2005 17:01, Georgi Georgiev wrote:
vanilla - Do not add extra patches which change default behaviour
For features, I would expect individual USE flags-- what if I want one patch,
but not another?
For changing mere defaults, a gentoo USE flag seems like it would make
On Fri, Aug 19, 2005 at 05:30:42AM +0200, Christian Parpart wrote:
On Thursday 18 August 2005 17:44, Chris Gianelloni wrote:
On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote:
2) ebuild maintenance will be a nightmare- every new version will
require again walking the source to see
maillog: 19/08/2005-02:59:46(+): Luke-Jr types
On Thursday 18 August 2005 17:01, Georgi Georgiev wrote:
vanilla - Do not add extra patches which change default behaviour
For features, I would expect individual USE flags-- what if I want one patch,
but not another?
I agree.
35 matches
Mail list logo
