On Monday 21 November 2005 21:50, Donnie Berkholz wrote:
> Here's the change:
> "virtual/x11" -> "<=x11-base/xorg-x11-6.99"
virtual/x11 isn't xorg for all profiles.
Carsten
pgpKJHUHNPisT.pgp
Description: PGP signature
On Saturday 19 November 2005 12:00, Thierry Carrez wrote:
> The intermediary decision (during the October meeting, one month ago)
> was that the GLEP would be approved, pending a list of changes. During
> last month, nobody raised his voice to say this list of changes was
> fundamentally flawed. Wh
On Thursday 03 November 2005 18:06, Sebastian Bergmann wrote:
> One thing I am interested would be whether or not I am allowed to add
> packages like latexmk [1] to the tree although I am not a member of the
> herd in charge of the respective category.
As long as you maintain it on your own and
On Thursday 03 November 2005 17:42, Tom Martin wrote:
> Could everyone please take a moment to scan through them?
More important would be imho, if everyone would take the time and have a look
at the maintainer-needed bugs, instead continuously adding new packages while
the share of unmaintained
On Tuesday 01 November 2005 18:43, Jon Portnoy wrote:
> You are technically correct in the sense that there is literally no
> policy stating "keep unmaintained stuff in the repository."
All I wanted to say is that we have no policy about it and a fair share of
rotten ebuilds in the repository ref
On Tuesday 01 November 2005 18:11, Jakub Moc wrote:
> OK, lets remove perl.
Such a reply is not an argument, but pointless. As you know as well, Perl is
not exactly something other packages do not depend on.
Carsten
pgpUegjBwwo3a.pgp
Description: PGP signature
On Monday 31 October 2005 22:44, Petteri Räty wrote:
> Checked the bugzilla and the two open bugs seem to be version bumps. I
> think the policy is not to remove working ebuilds from the tree although
> they are not maintained by anyone.
It's not policy to keep unmaintained stuff in the repository
Please forget my earlier email. After having a closer look almost all of those
ebuilds get the hompage set via the eclass they inherit, so Simons statement
is pretty much void.
Carsten
pgpc6tkeiU21V.pgp
Description: PGP signature
On Tuesday 25 October 2005 21:54, Simon Stelling wrote:
> Too bad reality doesn't match.
The list of ebuilds without homepage is indeed quite shocking. When you look
at our ebuild howto¹, the variables SLOT, LICENSE, KEYWORDS, DESCRIPTION,
SRC_URI, HOMEPAGE and IUSE are mandatory, so all these ~
On Thursday 20 October 2005 21:35, Diego 'Flameeyes' Pettenò wrote:
> Too many people using -* (due to auto flags) so that will break for most of
> them.
So we have the three things we should deprecate in a single thread:
a) no* flags
b) auto flags
c) -* and - for all architectures in one ebuild.
On Friday 14 October 2005 00:33, Diego 'Flameeyes' Pettenò wrote:
> I already tried preparing a list, but right now, they are probably limited
> to tar and mpg123/mpg321 ... sort of.
Add sys-apps/star to your list.
> * don't install the symlink in src_install
> * in pkg_postinst, look at ${ROOT}/
On Thursday 08 September 2005 03:48, Michael Stewart (vericgar) wrote:
> - A new gentoo-webroot that will eventually provide a gentoo-themed
>icon-set, error documents, and default website. This has been put in
>it's own package, and includes a USE-flag to not install the
>gentoo-webro
On Saturday 17 September 2005 01:00, Ciaran McCreesh wrote:
> Policy is rather specific about it. It's not a matter of interpretation
> at all.
That I disagree should prove that this is not a case. It's one thing to
consider an application to "just work" for the user and another having e.g.
the
On Friday 16 September 2005 23:57, Martin Schlemmer wrote:
> We still have KEYWORDS="-*".
I'd appreciate, if we disallow that and all use package.mask.
Carsten
pgpanBD00AO4P.pgp
Description: PGP signature
On Friday 16 September 2005 23:26, Ciaran McCreesh wrote:
> No. You *can* ask the package maintainer, if you feel that such a move
> would be useful and productive.
No. There're lot of issues an arch maintainer not necessarily knows about.
Without a way to indicate which ebuild is good, the whole
On Friday 16 September 2005 23:50, Mike Frysinger wrote:
> actually, going with say 'testing.mask' instead of '?arch' may be better
> ... reinforce the fact that this is a package-level issue rather than
> arch-specific
> -mike
That's nearly as bad as having to deal with package.mask all the time.
On Friday 16 September 2005 23:34, Ciaran McCreesh wrote:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1
As I said - your interpretation doesn't match mine - or the policy is not good
enough.
> Good time for package maintainers to start following policy properly,
> eh
On Friday 16 September 2005 22:38, Ciaran McCreesh wrote:
> That's not my idea. That's policy. I just happen to a) have actually
> read what policy says and b) agree with it.
First: I know you're proposing this regularly, but please show me the policy -
I'm sure your interpretation doesn't match
On Friday 16 September 2005 21:34, Ciaran McCreesh wrote:
> Those should be in package.mask. ~arch is for candidates for arch that
> haven't yet proven themselves.
No. Your idea how it should work simply doesn't match reality. When you e.g.
have upstream devs following the maxim "release early an
On Monday 12 September 2005 19:56, Jakub Moc wrote:
> Since you said above, that you really don't care if those user-submitted
> ebuilds will ever get into portage or will stay in maintainer-wanted queue
> forever and that's the stuff in portage that actually matters QA-wise, I'm
> missing why are
On Monday 12 September 2005 19:03, Ciaran McCreesh wrote:
> The easiest way to improve those ebuilds' chances
> of getting into the tree is by getting them up to a good enough
> standard that whoever picks them up is very unlikely to have to do
> major extra work on them.
To have even more unmaint
On Monday 12 September 2005 02:25, Ciaran McCreesh wrote:
> If you're not up for having your code reviewed, don't contribute to an
> open source project. No-one expects you to produce perfect code
> straight off (at least, we don't until we give you commit access). We
> *do* expect you to be prepar
On Wednesday 10 August 2005 21:04, Ciaran McCreesh wrote:
> Doesn't solve the SRC_URI problem.
Point taken. Doesn't help that this expansion stuff is fugly, imho.
Carsten
pgpf2HCETwZ68.pgp
Description: PGP signature
On Wednesday 10 August 2005 20:35, Ciaran McCreesh wrote:
> Check the cache instead.
My cache doesn't include the whole cvs tree, but I don't see what should be
different.
> Uh, the way I suggested needs no portage changes.
My bad. I don't like the feature flag approach and would say a TDEPEND
On Wednesday 10 August 2005 19:45, Ciaran McCreesh wrote:
> You didn't count very well... And you're only picking up the ones
Don't know what should be wrong with
find . -iname "*\.ebuild" -exec grep -H IUSE {} \; | grep test
> that're using USE=test, not the ones that have unlisted test
> depen
On Wednesday 10 August 2005 19:26, Mike Frysinger wrote:
> oh, you mean like portage ?
Eh? Of course in $D, not global. I see no reason for "noman" being feature
flag. Don't care about it though.
Carsten
pgpDy0C18phXB.pgp
Description: PGP signature
On Wednesday 10 August 2005 18:19, Diego 'Flameeyes' Pettenò wrote:
> Just look at how much packages there are which has a "test" useflag to add
> dependencies. There are quite a few.
I counted 7 - seven - packages and toolchain-binutils.eclass. That's not even
a thousandth part of the tree. Come
On Wednesday 10 August 2005 17:31, Ciaran McCreesh wrote:
> Then please introduce TESTDEPEND, MANDEPEND and INFODEPEND instead.
TESTDEPEND!? Are there numbers how many packages are affected and what
dependencies are in question, which are usually not available on every box
anyways? This getting
On Tuesday 09 August 2005 15:03, Caleb Tennis wrote:
> Let me follow up with that I'm all for adding the use flags IF other
> packages would make use of them as well. I just really hate adding 8 local
> use flags for this pretty heavily used package that won't add much utility
> to anything else a
On Friday 29 July 2005 19:09, Donnie Berkholz wrote:
> I just don't see how his comment had anything to do with PATCHES.
Gasp - communication is not error free. News to you!? I mistook him, that's
all.
> Thus, your comment doesn't make any sense to me, either.
In my context it does, unfortunat
On Friday 29 July 2005 18:39, Donnie Berkholz wrote:
> That doesn't really make any sense. You could just as easily use PATCHES
> if you ran s/patch -p0
pgpG7wF0z1ROa.pgp
Description: PGP signature
On Friday 29 July 2005 17:40, Diego 'Flameeyes' Pettenò wrote:
> This can be read as "it's good to use epatch" ? :P
It's just less text to write PATCHES="foo ...", if you don't have a src_unpack
function in the particular ebuild.
Carsten
pgpVewopKrcSC.pgp
Description: PGP signature
On Friday 22 July 2005 01:04, Herbert Fischer wrote:
> I'll take some time reading it and maybe contributing to it.
Well, the status is withdrawn. There were at least two long discussions about
it, but no satisfying results. It needs to be resurrected at some time, but
definitely after the next
201 - 233 of 233 matches
Mail list logo
