Ulrich Mueller wrote:
On Wed, 25 Feb 2009, Petteri Räty wrote:
Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks.
I've already commented on this
David Leverton wrote:
For comparson, another alternative that some people have suggested is putting
it in a specially formatted comment. This avoids the issue I mentioned
because bash doesn't try to parse those at all, so the only rules are those
that specify what format the comment should
Denis Dupeyron wrote:
1. EAPI-suffixed ebuilds (obviously)
2. EAPI in the filename with one-time extension change
3. Easily fetchable EAPI inside the ebuild and one-time extension change
My preference goes to 3 with a .eb extension and EAPI on the first line.
I second this. :)
Jorge Manuel B. S. Vicetto wrote:
As others have commented, we should probably make this the last comment
line in the header. Any suggestions for a specific identification string
or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ?
Well, if a she-bang, should be the first line.
Thomas Anderson wrote:
- Vote on GLEP 54
This vote was called for by dertobi123. The vote was on whether to
approve GLEP 54 conditional on whether GLEP 55 is passed. The reason
for this is that GLEP 54 is unimplementable without the problems
mentioned in GLEP 55
Ciaran McCreesh wrote:
3. Extend versioning rules in an EAPI - for example, addition of the
scm suffix - GLEP54 [1] or allowing more sensible version formats like
1-rc1, 1-alpha etc. to match upstream more closely.
Apart from GLEP54, I believe our versioning scheme works reasonably
well. I
Ciaran McCreesh wrote:
On Mon, 18 May 2009 16:07:20 +0100
Steven J Long sl...@rathaus.eclipse.co.uk wrote:
I missed the clamour of developers complaining about this
oh-so-burdensome restriction that they've been dealing with for at
least 5 years.
Why do you think I wrote the awful hack
Ulrich Mueller wrote:
Hyphens within PV are a Bad Thing, and we should really think about
replacing the separator for scm by something else, like a period or
an underscore. For example, the following two would be unique:
${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
Roy Bamford wrote:
GLEP 55 still confuses the problem and the solution.
Adding metadata to the filename is not required and is bad system
design practice. Its also the first step on the slippery slope to
adding more metadata in the future.
++
Changing the .ebuild extension, to blind
Alec Warner wrote:
No, it's entirely objective. GLEP 55 clearly shows how the filename
based options are objectively better than anything else.
But the decision will not be based entirely on objective merits
(although I will concede that EAPI in filename is the 'best' technical
choice).
Alec Warner wrote:
Lets agree to disagree on the definition of technical then and
instead agree that putting EAPI in the filename is a bad design
decision (technicalness aside) and then have a beer!
Wow. That's a *great* idea! ;)
-Cheers, Joe
Mike Frysinger wrote:
maybe, but since we arent going to use /libexec/ at this time, that means
/etc
is the next best place
How about /usr/share/openrc/version?
Since /usr/share is supposed to contain package-specific (but platform
independent) files that are *not* meant to be modified
Mike Frysinger wrote:
/usr isnt guaranteed to be mounted for all init.d scripts
Right... Well, then the best choice is probably /etc out of the list [Roy
pointed out] of the only OS-nonspecific dirs, unless we want to have a small
executable script in /bin or /sbin that spits out the version.
Denis Dupeyron wrote:
I'd be ready to believe part of it was that he wanted to
experiment. And experiments sometimes succeed, or sometimes they fail,
Well, experimentation is OK (and I would encourage it for many things),
but I'm not sure I'd agree that experimentally giving someone council
# Joe Peterson lava...@gentoo.org (13 Mar 2010)
# Old, unmainted standalone kernel modules for older kernels.
# Kernels 2.6.29-rc1 and newer include integrated btrfs.
# Bug #285357 reports version 0.17 (newest standalone) does not build.
# Last rited: to be removed in 30 days.
sys-fs/btrfs
-Joe
On 03/31/2010 02:18 AM, Mike Frysinger wrote:
i'm already using ~/.forward which means mail still goes to mail.g.o and that
server takes care of forwarding it to my private gmail.com account. then my
mail client fetches it from gmail.com via the normal pop/imap methods. there
is no need
On 03/31/2010 01:40 PM, Mike Frysinger wrote:
Those, like me, who have several google apps accounts (I have a personal
business one, a personal one, and a work one) can keep accounts separate
this way. Also, since it's the gentoo.org google apps account, the
email address looks the same as
On 03/31/2010 02:28 PM, Sebastian Pipping wrote:
I am worried that if people start using say Google Docs for
collaborating on Gentoo content, everyone else is forced to use Google
Docs to participate.
Gentoo could set policies that such shared resources should not be done
via google calender,
# Joe Peterson lava...@gentoo.org (03 Jun 2010)
# Masked for removal in 30 days:
# Fails to build with gcc 4.4 (see bug #290105)
# Requires non-open-source components that never worked well
# - e.g. voice, media
# - this (source) package never behaved quite like the binary
# Really should
I think a better solution, if we need to indicate this, is to have
bugzilla grab the status from devaway and display it next to the dev's
name in bug reports. Changing the user's name seems a bit cumbersome,
and I don't agree that people will know what devaway means - i.e.
they may not even
Thanks for the tip. I added failed to install genlop (via dobin) -
not sure if there is a standard way to do this, as it seems many ebuilds
just do dobin failed, and some do failed to install
-Joe
Christian Faulhammer wrote:
Joe Peterson
Faulhammer wrote:
Joe Peterson [EMAIL PROTECTED]:
Thanks for the tip. I added failed to install genlop (via dobin) -
not sure if there is a standard way to do this, as it seems many
ebuilds just do dobin failed, and some do failed to install
It is mainly to localise which die command
Fabian Groffen wrote:
The problem is those replies may contain information of use in fixing the
bug. If the mail gets null-spaced...
I don't see your point. If you have a mailserver running on localhost
that accepts mail for /dev/null (i.e. it thinks it is a valid email
address) and
Mike Frysinger wrote:
wrong. bash and GNU prevail because they provide useful extensions. it may
be worthwhile to force `find` in the portage environment to be GNU find so we
can stop wasting time trying to figure out how to rewrite expressions in
ebuilds (which can be done trivially with
Andrew Gaffney wrote:
Denis Dupeyron wrote:
Yes people, Mike is older than Uncle Seemant, and even older than me.
But is he older than nerdboy? Do we have competition for the Crotchety Old
Man
title? Are we going to hear lots of stories that start with when I was your
age?
Or... My
Mart Raudsepp wrote:
Damn, mine had 48K
Luxury!
Welcome Mike!
And I forgot to welcome Mike; so welcome Mike!
-Joe
--
[EMAIL PROTECTED] mailing list
Mike Frysinger wrote:
as mentioned, GNU is the main bread and butter of Gentoo. forcing the
majority of people to go pure POSIX in the face of GNU extensions that make
life easier is wrong. so the minority gets screwed, that's life. especially
considering it's trivial for the minority to
Fabian Groffen wrote:
On 07-10-2007 10:19:43 -0600, Joe Peterson wrote:
So there are a couple of options, as I see it:
1) Limit tool options to those that are common to all tool variants
2) Port a standard (i.e. GNU) set of tools to all platforms
3) Force all gentoo ports to use GNU userland
Mike Frysinger wrote:
Fabian has summed it up nicely, thanks. i could care less what your userland
is outside of the ebuild environment since it doesnt matter to ebuild
writers. you want a deficient runtime environment, more power to you, but
forcing that environment onto ebuild
(Sorry for the previous reply to announce..)
--
[EMAIL PROTECTED] mailing list
Robin H. Johnson wrote:
After a LOT of development, Gentoo Infra is pleased to announce the
return of the new packages.gentoo.org site. The new site is a complete
rewrite.
Great! Glad to see it back; thanks for the hard work! And hey, fbsd is
now considered exotic! I kinda like the ring of
Doug Klima wrote:
Robin's e-mail did set the Reply-To. Joe just broke the world.. bad Joe!
Yeah, even reply-to is no match for the mighty reply all button! :)
Giving myself 50 lashes now...
-Joe
--
[EMAIL PROTECTED] mailing list
Petteri Räty wrote:
It's my usual please to announce a new ebuild monkey. Justin hails from
Brighton, Massachusetts. His educational background should provide a
good theoretical approach to all the future flames on gentoo-dev:
I'm pretty much self taught computer wise as I went to the
Piotr Jaroszyński wrote:
Hello,
attaching the GLEP.
most current version:
http://dev.gentoo.org/~peper/glep-0055.html
http://dev.gentoo.org/~peper/glep-0055.txt
Abstract
This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
(for example,
Ciaran McCreesh wrote:
On Tue, 18 Dec 2007 01:36:51 +0100
Thomas de Grenier de Latour [EMAIL PROTECTED] wrote:
Why can't it be in the file but readable without sourcing? For
instance, it could be mandatory that EAPI=X, if present, must be the
first non-blank and non-comment line of the ebuild
Ciaran McCreesh wrote:
On Mon, 17 Dec 2007 18:05:23 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
This option is worth thinking about more - there may be satisfactory
ways to mediate the issues. It is certainly more elegant
Introducing new parse and format requirements upon bash files
Ulrich Mueller wrote:
It seems to me that this will inconvenience the users, in order to
solve a technical problem of the package manager.
Absolutely, +1. This does indeed sound like a technical issue; how
would requiring a dev to manually mirror the EAPI in the filename
extension provide any
Santiago M. Mola wrote:
One example was mentioned in this thread before: You cannot use
find -name '*.ebuild' anymore.
So people could use a bit more elaborated expression to find them.
Things like this shouldn't be a reason for not applying
EAPI/GLEPs/PM-behaviour changes. If this GLEP is
Steve Long wrote:
Ciaran McCreesh wrote:
There is no duplication of information, nor redundancy.
So what were the QA checks you mentioned to confirm that the same EAPI is
set in both the filename and the ebuild, for-- if not integrity of
duplicated data?
+1
Really. It's a heck of a lot
Thomas Pani wrote:
My concern is technical: Filenames are for identifying files uniquely.
An ebuild is uniquely identified by cat/pn-pv, so that's what it's
filename should be. Adding anything else to the filename will only
clutter the tree and lead to additional inconsitencies. Yes, you can
Assuming that the file extension must change to prevent current PMs from
trying to parse new format ebuilds (and not require waiting a year or
more), I'd be a lot happier seeing it change *once* to a new fixed
extension, with the requirement that the new ebuilds are required to
contain within them
Denis Dupeyron wrote:
So please everybody, give a warm welcome to Richard.
Richard, big welcome!
-Joe
--
[EMAIL PROTECTED] mailing list
Denis Dupeyron wrote:
Jean-Noël currently lives in Paris, France, but he studied in
Vancouver, Canada for some time. He is 26 and happily married. Apart
from computers, he has a passion for games (video, role-playing and
boardgames), music (progressive metal rock), and outdoors
(especially
Denis Dupeyron wrote:
It's my pleasure to introduce Ingmar Vanhassel (ingmar) as a new
Gentoo developer. He will be on the KDE team, as he already has
extensive experience with the KDE4 overlay. Quoting his mentor in his
new-dev bug:
He has rewritten large parts of the KDE4 eclasses,
On Thu, Jan 17, 2008 at 10:56:36AM +, Steve Long wrote:
Ryan Hill wrote:
I agree, though year of birth might be interesting. Income and children
are a bit too private.
++ in general although I do think parenthood (if responsible) is as relevant
as age. A 28 year old with a 5 year old
Steve Long wrote:
My apologies if I caused you any offense, Joe. I fully agree that choosing
not to have children is just as mature as deciding to procreate, and more
mature than simply drifting into parenthood.
No offense taken, and I agree about the drifting into thing. My
wife's brother
Robert Buchholz wrote:
Oh, and great to have you on the team.
I totally welcome Kenneth - I use Gentoo amd64 on a server at work
(mostly using stable keywords, of course). It's awesome to have a
64-bit OS to take advantage of our Core2 Quad, and it's great to have
yet another person here to
Ciaran McCreesh wrote:
On Thu, 10 Apr 2008 17:37:31 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:
That's why I setup them up with the ability to rsync it, and they
never got back to me on that, nor used it ever.
Hrm, curious. They seem interested and alive currently. Perhaps it's
worth
Roy Marples wrote:
config_eth0=1.2.3.4 netmask 255.255.255.0
5.6.7.8 netmask 255.255.0.0
routes_eth0=1.2.4.0 netmask 255.255.255.0 gw 1.2.3.6
5.6.7.9 gw 5.6.7.10
default gw 1.2.3.1
If one choose to separate by lines, will tabs or spaces be allowed in
subsequent lines? Like:
Roy Marples wrote:
The point is to remove the hard newline, which you've kept in your examples.
Roy, yes, I realized that after I emailed - at first I thought it was
remaining as an option. :)
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
Has anyone volunteered to take net-misc/ntp? I know there are alternatives
(like OpenNTPD), but this one is the official one, so I'd hate to see it
slip into substandard quality. Also, e.g. OpenNTPD is a subset and is less
accurate, so it is not a complete replacement. I will take it on if no
Joe Peterson wrote:
Has anyone volunteered to take net-misc/ntp? I know there are alternatives
(like OpenNTPD), but this one is the official one, so I'd hate to see it
slip into substandard quality. Also, e.g. OpenNTPD is a subset and is less
accurate, so it is not a complete replacement. I
William L. Thomson Jr. wrote:
On Wed, 2008-06-04 at 20:52 -0400, William L. Thomson Jr. wrote:
I think a more ideal solution, less drastic to implement might be
allowing 2 arguments to be passed. So you could do like
elog A blank line precedes this one
elog A blank line follow this one
William L. Thomson Jr. wrote:
On Sat, 2008-06-07 at 00:42 +0200, Vlastimil Babka wrote:
There could be also switch to add newline
before the message but I can't think of a use for it myself.
The question is how to name the switch :) -n could be confusing as
echo -n has the opposite effect.
Vlastimil Babka wrote:
I'd like to nominate:
zmedico (Zac Medico)
Seconded.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
Donnie Berkholz wrote:
On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote:
looks like every nominee wants the council to be more technical so I
have a few technical questions for you:
1. GLEP54
2. GLEP55
I don't have any particular objections to these, besides the vague
aesthetic one of
[EMAIL PROTECTED] wrote:
1) Increase of [needless] complexity in filenames/extensions (and only one
example of the impact is that searching for ebuild files becomes less
straightforward), when things like SLOT, EAPI, etc., etc., seem to
naturally belong as part of the script
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 19:49:08 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
I'm not saying it's a lot harder. But it is more complex and less
elegant. Also, it is error-prone. If someone, by habit, looks for
all *.ebuild, he will miss a portion of the ebuilds
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 20:15:56 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
Yes, if everyone is perfect and remembers to do things perfectly
right, there would never be issues in many things, but when you make
something more complicated, there will be more errors.
So we
Ciaran McCreesh wrote:
And a file extension is far less obscurely complex than enforcing
arbitrary syntax restrictions upon ebuilds.
I disagree. One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyone looking at the portage
tree.
No it
Ciaran McCreesh wrote:
On Mon, 9 Jun 2008 22:35:25 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:
Did anyone already propose specifying this in metadata.xml?
Yup. That's a no-go, since metadata.xml is quite rightly treated as
being not suitable for anything the package manager really needs.
Rémi Cardona wrote:
Ciaran McCreesh a écrit :
picard_facepalm.jpg
I don't think any of us are completely thrilled by either proposals, but
the EAPI-in-a-separate-file does have the potential for more
flexibility, ie package-wide EAPI.
And it does keep filenames simple enough.
+1
Luca Barbato wrote:
Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask it...
And placing it out-of-band (like # EAPI=...) avoids any sourcing
errors, makes parsing faster, etc.
-Joe
--
Jan Kundrát wrote:
If the user knows that keywords are set by the KEYWORDS variable, then
she must be familiar with the EAPI. The meaning of the KEYWORDS variable
is defined by the EAPI.
But that's not really what I find objectionable. There's no need to
make EAPI so special that it alters
Rémi Cardona wrote:
Ciaran McCreesh a écrit :
Kills the upgrade path completely. No good.
Lemme sum this up in layman's terms :
1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
avoid that for various reasons, all 100% valid.
2) Putting the EAPI in the filename :
Fernando J. Pereda wrote:
On 10 Jun 2008, at 15:33, Joe Peterson wrote:
Luca Barbato wrote:
Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask
it...
And placing it out-of-band (like # EAPI=...) avoids any
Bernd Steinhauser wrote:
And that is, what this is about, making EAPI bumps as less painful as
possible. The filename is the easiest solution for that.
In any design, there are easy short-cuts that can be taken. But
sometimes these short-cuts break paradigms that are fundamental. If you
Richard Freeman wrote:
On the other hand, this is a big change from the present, and I'm not
convinced that it will actually be a big improvement over some of the
other EAPI ideas being floated around. However, it is a
potentially-neat idea...
Rich, interesting thoughts! But yeah, I
Peter Volkov wrote:
Well for me .ebuild-eapi is much more confusing.
I still don't see why it's impossible to have eapi as a part of name but
not in extension...
Although putting EAPI in the name and not the extension is *slightly*
preferable to using the extension, I still do not think that
Ryan Hill wrote:
(...I would change the suffix to -live, just because i
hate the term SCM :P)
++ on using live and not the scm acronym (no matter which idea is
selected), especially since there are various different acronyms for
config mgmt (scm, cm...), and scm's meaning is less obvious at
Benedikt Morbach wrote:
On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov [EMAIL PROTECTED] wrote:
But speaking about names of options - -A and -B are easier to remember
as -A stands for above and -B for below and grep users already knew
that.
for grep -A means after and -B before ;)
I (not
Duncan wrote:
Jim Ramsay [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Mon, 16
Jun 2008 08:34:01 -0400:
Well, this is true and it isn't... In the case of:
ewarn line one
eblank
ewarn line two
Obviously it would be the same as ewarn. However, what about here:
Tony Chainsaw Vroon wrote:
The time I can spend
trawling upstream sites for new releases is limited.
Same here - I would never mind getting a 0-day bump request, since
someone else might have noticed before I did that a new version is
available.
Just an idea:
How about a metadata.xml tag
Donnie Berkholz wrote:
I actually object to having crap in dev-python, because things should be
categorized functionally instead of by the language they're implemented
in. 90% of the time you don't care about the language. But category
moves are pretty much pointless, so I don't normally
Donnie Berkholz wrote:
I meant moves were largely pointless, although categories are to a
lesser extent. Tags would be a lot better, since nothing can be
categorized perfectly into a single place.
Yes, I can see the benefit of a tag paradigm. I, myself, find it more
trouble than benefit to
Marijn Schouten (hkBst) wrote:
I suppose you mean git. Since it tracks content and not files, moves are
trivial. Git actually finds your moves for you, after you've moved content
around; such as when doing a bump.
Even better!
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
Petteri Räty wrote:
I am saying that it makes sense to approve both at the same time or have
other official package managers approved before accepting the GLEP.
In addition, I'd want to see why the particular approach suggested in this
GELP is the only way (as some seem to claim). I have yet
Marius Mauch wrote:
The eclass also contains it's own implementation of unpack (renamed to
unpack2) and src_unpack so the logic which tools/packages are used for
unpacking can be maintained in a single place instead of being
splitted between the package manager and the tree.
Marius, these
Peter Volkov wrote:
This means that every ebuild which uses 'unpack ${A}' should have in
DEPEND a program which is selected by filename extension of sources. So
as I understood your initial suggestion was to make this happen
automatically. And this is very logical as makes ebuilds cleaner and
Vaeth wrote:
The main point in introducing the live USE flag should be IMHO to
let the user decide whether the sources should be fetched. The fact
that IUSE then marks live ebuilds in the way which you wanted is an
additional side effect.
A tend to agree with Zac that USE flags should not
Zac Medico wrote:
What you're missing is that only a specific subset of variables is
cached in /usr/portage/metadata/cache. Now that you mention it, we
could introduce a new variable called EBUILD_FLAGS and start caching
it in new versions of portage. It wouldn't necessarily require an
EAPI
Zac Medico wrote:
Personally I think people are far too concerned about the name of
the variable. I only see a what I consider to be a trivial or
negligible benefit in separating these things into two different
variables. However, it it makes more people happy then I guess I'm
for it.
Zac Medico wrote:
To simplify things, how about if we just do a
PROPERTIES=live-src-unpack for now, to indicate exclusive access to
$DISTDIR during src_unpack? Thats a simple and portable baseline
that will be quite useful even without anything finer grained.
No need for a convoluted and long
Zac Medico wrote:
Please consider the introduction of a new PROPERTIES variable to
the ebuild metadata cache that's distributed via the rsync mirrors
and resides locally in the ${PORTDIR}/metadata/cache/ directory.
This variable is intended to have identical syntax to the existing
RESTRICT
Jeremy Olexa wrote:
Also, devs willing to maintain
packages but then later retiring and leaving the packages in limbo.
Maybe there should be some policy such as, when devs retire if no one
else steps up to maintain the package, then it automatically gets
moved to sunrise overlay and only
Duncan wrote:
That's an interesting idea. I don't personally care either way, as long
as @world continues to /not/ include system/@system, but having world
(without the @) continue to include system /would/ be useful for backward
compatibility. I think it'd be much better in terms of ease
Steve Long wrote:
@system == system
...but...
@world != world
This, I would think, could cause confusion too - and we'd have to live
with and document this quirk.
I don't see that as major from a user pov; as soon as you see @ you're in
set territory, which is for finer-grained control.
Zac Medico wrote:
Do the name and definition of this PROPERTIES=live value seem good?
Would anybody like to discuss any changes to the name, definition,
or both?
++
-Joe
Zac Medico wrote:
Then change the name. Call it zero-install-cost.
I'm inclined toward virtual since it's more brief and I think it
might strike a chord with more people because of their familiarity
with the virtual category and old-style PROVIDE virtuals. We'll
have to see what others have
Ciaran McCreesh wrote:
Users don't need to see it.
I cannot quite agree on that point. Given that Gentoo is a distro that
appeals to the more technically-oriented users, I personally believe
that what we expose as ebuild syntax is actually exposed to many users
fairly profoundly.
Marius Mauch wrote:
If it's only used to indicate that the package doesn't install any
files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual'
somehow implies that it's only applicable to packages in the 'virtual'
category, which isn't the case with the given definition (as you
Marius Mauch wrote:
Not sure if 'live' is really the best choice here, as many things also
apply to e.g. automated daily/nightly snapshots/builds that might also
be useful to support. Maybe 'unversioned' is more accurate.
I think the most important thing to convey with this property is that
Marius Mauch wrote:
First, regarding the news item, I'd suggest that instead of telling
users to modify world_sets manually to use `emerge --noreplace @system`.
++
Second for the suggestions on how to handle the transition:
- treating 'world' and '@world' differently is a no go from my POV.
Ciaran McCreesh wrote:
Except it doesn't. A virtual ebuild:
* installs nothing
* does nothing
I'd say that virtual does indeed do something: it pulls in other packages.
* should be treated as being very quickly installable
* should be treated as having zero cost for installs
The
Christian Faulhammer wrote:
everyone working on bugs, please add all people from metadata.xml to
the assignee or cc field, I regularly have to search for bugs where a
team and I maintain a package because only the team has been added.
Second, please use full atoms (cat-egory/package) in the
Jeroen Roovers wrote:
Sorry if this answer can be found elsewhere, but if one has a proxy
maintainer (i.e. not a Gentoo dev) for a package, can/should this
person be added to metadata.xml? Is there a special tag for this? I
can certainly see this being helpful (so that person automatically
# Joe Peterson [EMAIL PROTECTED] (22 Sep 2008)
# Masked for removal in 30 days (see bug #238442)
# Replaced by package: media-sound/squeezecenter
media-sound/slimserver
-Joe
# Joe Peterson [EMAIL PROTECTED] (23 Sep 2008)
# Masked for removal in 30 days (see bug #238442)
# Depends on old media-sound/slimserver
# Will bring back in a form that works with media-sound/squeezecenter
media-plugins/slimserver-alienbbc
Michael Hammer wrote:
* Doug Goldstein [EMAIL PROTECTED] [081031 15:53]:
If no one opposes, I say we redact this USE flag asap.
++
I was also wondering why kerberos was on by default - I definitely
approve of nuking it.
-Joe
Petteri Räty wrote:
The names of eclasses aren't shown to users and I think figuring out a
new name is a minor inconvenience so I would just go with the safe route.
I disagree: we should use care in choosing names, since these names will be
around for a long time. Using an ugly name might not
1 - 100 of 130 matches
Mail list logo
