Currently, there is no really working version of it in the tree:
https://bugs.gentoo.org/show_bug.cgi?id=494624
But due its bumps and current bugs, this needs a maintainer...
otherwise, I would treeclean it (the problem is that looks like some
people use it, but without none of them willing to ma
[Replying again since my mailer messed up my original message.]
On Tue, 2014-01-28 at 12:03 -0500, Mike Gilbert wrote:
> Option 3: Unset the variables
>
> This should cause applications to default to locations under ${HOME}.
> This could be done in global scope (unless I am overlooking something
On Wed, 2014-01-29 at 03:15 +, Duncan wrote:
> Tom Wijsman posted on Tue, 28 Jan 2014 14:11:48 +0100 as excerpted:
>
> [Seven J. Long wrote...]
>
> >> There's plenty of ways to stay on the bleeding-edge; throwing out the
> >> baby with the bathwater will only tip you over it, and bork the dis
On January 28, 2014 12:03:04 PM EST, Mike Gilbert wrote:
>Option 3: Unset the variables
>
>This should cause applications to default to locations under ${HOME}.
Only those applications that properly comply with standards :)
For instance, glib did not start respecting ${HOME} until version 2.36
Tom Wijsman posted on Tue, 28 Jan 2014 14:11:48 +0100 as excerpted:
[Seven J. Long wrote...]
>> There's plenty of ways to stay on the bleeding-edge; throwing out the
>> baby with the bathwater will only tip you over it, and bork the distro
>> for the rest of us, and everyone down the line.
>
> W
On Tue, Jan 28, 2014 at 12:23 PM, Jeroen Roovers wrote:
> On Tue, 28 Jan 2014 08:33:05 -0800
> ""Paweł Hajdan, Jr."" wrote:
>
>> Why not allow maintainers to drop redundant stable and even ~arch
>> keywords from their packages?
>
> This is standard practice already.
If there is still pain then m
On Tuesday, January 28, 2014 05:53:52 Jeroen Roovers wrote:
> On Mon, 27 Jan 2014 18:14:54 -0500 Mike Frysinger wrote:
> > > It's more obvious with the fancy colouring
> >
> > if you dislike the color format, then pick a different one. there
> > are a large number available.
>
> I didn't intend
On Tue, 28 Jan 2014 08:33:05 -0800
""Paweł Hajdan, Jr."" wrote:
> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?
This is standard practice already.
jer
On Mon, Jan 27, 2014 at 6:02 PM, Gilles Dartiguelongue wrote:
> People are encouraged to provide a prototype implementation of such
> eclass in the previously mentioned bug report.
>
Ok, lets discuss the eclass approach here. The 4 variables we want to
deal with are:
XDG_DATA_HOME
XDG_CONFIG_HOM
On Tue, 28 Jan 2014 08:33:05 -0800
""Paweł Hajdan, Jr."" wrote:
> Why not allow maintainers to drop redundant stable and even ~arch
> keywords from their packages?
We already do that to a great extent; only removing the last keyword
present is a bad idea, because in that case the package would n
On 28/01/14 11:33 AM, "Paweł Hajdan, Jr." wrote:
> Here's a proposal that may address concerns from the long "rfc:
> revisiting our stabilization policy" thread.
>
> It seems at least one of the problems is that with old ebuilds being
> stable on slow arches but not the more recent ebuilds, it is
Here's a proposal that may address concerns from the long "rfc:
revisiting our stabilization policy" thread.
It seems at least one of the problems is that with old ebuilds being
stable on slow arches but not the more recent ebuilds, it is a
maintenance burden to keep supporting the old ebuilds eve
On Tue, 28 Jan 2014 14:52:59 +0200
Alan McKinnon wrote:
> On 28/01/2014 14:37, Steven J. Long wrote:
> > I concur that "QA should be focusing on making stable, actually
> > stable, not more bleeding edge." That's not a "performance" issue
> > as you put it, except in management nuspeek. It's the
On Tue, 28 Jan 2014 12:37:40 +
"Steven J. Long" wrote:
> Please set your client not to embed people's email addresses in your
> responses: it's spambait in web archives. Thanks.
It's as much a spambait as it is listed in the From: header on the web
archives; in other words, it are the web ar
Alec Warner wrote:
> Sorry, I work on Portage. What I'm saying is that We are free to change the
> behavior of *portage* now; rather than waiting for a new EAPI. If an ebuild
> needs to define EAPI=eapi-next to 'correctly' use XDG_*, well that is
> someone else's can of worms.
Agreed: portage can
On 28/01/2014 14:37, Steven J. Long wrote:
> I concur that "QA should be focusing on making stable, actually stable,
> not more bleeding edge." That's not a "performance" issue as you put it,
> except in management nuspeek. It's the whole bloody point of the distro,
> in overarching terms: to test
Please set your client not to embed people's email addresses in your
responses: it's spambait in web archives. Thanks.
Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > Tom Wijsman wrote:
> > > "Steven J. Long" wrote:
> > > > What? Without a stable tree, Gentoo is useless afaic.
> > >
> > > It mov
Dnia 2014-01-28, o godz. 11:59:33
Jauhien Piatlicki napisał(a):
> net-misc/rsync upstream provides a tarball with additional patches that
> can be useful for some users. I think it would be nice to have them
> handled automatically by portage using e.g. USE_EXPAND.
>
> Of course these patches ca
Hi,
net-misc/rsync upstream provides a tarball with additional patches that
can be useful for some users. I think it would be nice to have them
handled automatically by portage using e.g. USE_EXPAND.
Of course these patches can be just picked by user an applied using
epatch_user, but I think it w
19 matches
Mail list logo
