On Thu, 11 Sep 2014 23:40:32 +
hasufell hasuf...@gentoo.org wrote:
I don't see [...]
It is hard to connect the dots if you don't know about the dots;
do your homework to find them, ask questions when you don't.
[...] any sense in what you say. You sound confused.
Without those dots, your
On Sat, 13 Sep 2014 22:44:49 +
hasufell hasuf...@gentoo.org wrote:
Jauhien Piatlicki:
In the ideal country of elves. In the real life it can be not
possible to build and install software in a given distribution
without downstream patches. You can find examples of such live
ebuilds
2014-09-10 15:59 GMT+01:00 Tom Wijsman tom...@gentoo.org:
On Wed, 10 Sep 2014 13:56:04 +
hasufell hasuf...@gentoo.org wrote:
Tom Wijsman:
On Tue, 09 Sep 2014 19:12:28 +
hasufell hasuf...@gentoo.org wrote:
Jauhien Piatlicki:
When I accept ~arch I expect that no live ebuilds
2014-09-13 21:03 GMT+01:00 Peter Stuge pe...@stuge.se:
I would actually expect
there to be a policy which forbids patches on live ebuilds. Make
another live ebuild or maybe an overlay if you want to offer a
different set of commits than the upstream repo.
For me, the whole point of live
On Mon, 15 Sep 2014 10:11:08 +0100
Georg Rudoy 0xd34df...@gmail.com wrote:
How frequently the list of supported arches does shrink? Is it
statistically significant?
The amount of software that exists makes this impossible to determine.
2014-09-15 10:24 GMT+01:00 Tom Wijsman tom...@gentoo.org:
On Mon, 15 Sep 2014 10:11:08 +0100
Georg Rudoy 0xd34df...@gmail.com wrote:
How frequently the list of supported arches does shrink? Is it
statistically significant?
The amount of software that exists makes this impossible to
On Mon, 15 Sep 2014 10:28:16 +0100
Georg Rudoy 0xd34df...@gmail.com wrote:
Let's limit our sample to Gentoo tree then. How frequently arches list
shrinked as a result of bumping the version (because the upstream has
chosen so, not because of insufficient resources to keep testing all
Jauhien Piatlicki wrote:
Emerging live ebuild usually is quite a risky thing,
I don't know. It depends on the culture of the particular repository,
and while it is true that many open source repos are utter crap I'm
not sure if that is the common case?
I like to believe that developers actually
13.09.14 19:31, Peter Stuge написав(ла):
Jauhien Piatlicki wrote:
Emerging live ebuild usually is quite a risky thing,
I don't know. It depends on the culture of the particular repository,
and while it is true that many open source repos are utter crap I'm
not sure if that is the common
Jauhien Piatlicki wrote:
The question is not about crap in the upstream, but about changed
dependencies, behavior, whatever else.
That's a good point.
E.g. we in downstream have some patches, when upstream changes
related code (e.g. applying our patches), ebuild fails to build.
I consider
Hi,
13.09.14 22:03, Peter Stuge написав(ла):
E.g. we in downstream have some patches, when upstream changes
related code (e.g. applying our patches), ebuild fails to build.
I consider this a separate issue however. I would actually expect
there to be a policy which forbids patches on live
Jauhien Piatlicki:
In the ideal country of elves. In the real life it can be not possible to
build and install software in a given distribution without downstream
patches. You can find examples of such live ebuilds in Gentoo tree.
I think it's not appropriate and shouldn't generally be done
On Wed, 10 Sep 2014 15:09:38 +
hasufell hasuf...@gentoo.org wrote:
Tom Wijsman:
It improves usability by providing additional information.
Usability is not to be found in information that is subject to
change.
Please also set DEPEND, RDEPEND, EGIT_REPO_URI, DESCRIPTION and the
Tom Wijsman:
On Wed, 10 Sep 2014 15:09:38 +
hasufell hasuf...@gentoo.org wrote:
Tom Wijsman:
It improves usability by providing additional information.
Usability is not to be found in information that is subject to
change.
Please also set DEPEND, RDEPEND, EGIT_REPO_URI, DESCRIPTION
On Tue, 09 Sep 2014 19:12:28 +
hasufell hasuf...@gentoo.org wrote:
Jauhien Piatlicki:
When I accept ~arch I expect that no live ebuilds will be built. I
think other gentoo users expect the same.
Just because users are used to it doesn't make it better.
How does it make it better
Tom Wijsman:
On Tue, 09 Sep 2014 19:12:28 +
hasufell hasuf...@gentoo.org wrote:
Jauhien Piatlicki:
When I accept ~arch I expect that no live ebuilds will be built. I
think other gentoo users expect the same.
Just because users are used to it doesn't make it better.
How does it
On Wed, 10 Sep 2014 13:56:04 +
hasufell hasuf...@gentoo.org wrote:
Tom Wijsman:
On Tue, 09 Sep 2014 19:12:28 +
hasufell hasuf...@gentoo.org wrote:
Jauhien Piatlicki:
When I accept ~arch I expect that no live ebuilds will be built. I
think other gentoo users expect the
Tom Wijsman:
It improves usability by providing additional information.
Usability is not to be found in information that is subject to change.
Please also set DEPEND, RDEPEND, EGIT_REPO_URI, DESCRIPTION and the rest
of them to , because they are all subject to change.
So, both quotes
On 08/09/14 06:47, Rick Zero_Chaos Farina wrote:
On 09/07/2014 09:03 PM, Rich Freeman wrote:
Right now the general policy is that we don't allow unmasked (hard or
via keywords) ebuilds in the tree if they use an scm to fetch their
sources. There are a bunch of reasons for this, and for the
Samuli Suominen:
On 08/09/14 06:47, Rick Zero_Chaos Farina wrote:
On 09/07/2014 09:03 PM, Rich Freeman wrote:
Right now the general policy is that we don't allow unmasked (hard or
via keywords) ebuilds in the tree if they use an scm to fetch their
sources. There are a bunch of reasons for
Dnia 2014-09-09, o godz. 17:41:27
hasufell hasuf...@gentoo.org napisał(a):
Samuli Suominen:
On 08/09/14 06:47, Rick Zero_Chaos Farina wrote:
On 09/07/2014 09:03 PM, Rich Freeman wrote:
Right now the general policy is that we don't allow unmasked (hard or
via keywords) ebuilds in the
Michał Górny:
Dnia 2014-09-09, o godz. 17:41:27
hasufell hasuf...@gentoo.org napisał(a):
Samuli Suominen:
On 08/09/14 06:47, Rick Zero_Chaos Farina wrote:
On 09/07/2014 09:03 PM, Rich Freeman wrote:
Right now the general policy is that we don't allow unmasked (hard or
via keywords)
Dnia 2014-09-09, o godz. 17:58:17
hasufell hasuf...@gentoo.org napisał(a):
Michał Górny:
Dnia 2014-09-09, o godz. 17:41:27
hasufell hasuf...@gentoo.org napisał(a):
Samuli Suominen:
On 08/09/14 06:47, Rick Zero_Chaos Farina wrote:
On 09/07/2014 09:03 PM, Rich Freeman wrote:
Right
On Tue, Sep 9, 2014 at 2:16 PM, Michał Górny mgo...@gentoo.org wrote:
Dnia 2014-09-09, o godz. 17:58:17
hasufell hasuf...@gentoo.org napisał(a):
Michał Górny:
Dnia 2014-09-09, o godz. 17:41:27
hasufell hasuf...@gentoo.org napisał(a):
Samuli Suominen:
On 08/09/14 06:47, Rick
On Mon, Sep 8, 2014 at 2:59 AM, Ulrich Mueller u...@gentoo.org wrote:
What is the problem with making snapshot of some git commit and
placing it on mirrors?
To be clear, there isn't one. The more typical approach for fixes is
to use the upstream main release tarball and continue to provide
Michał Górny:
And how can you test a VCS ebuild? You can't assume upstream will be
stuck on one commit.
I don't see the argument. It sounds like you are saying one day,
upstream might stop supporting architecture xy, so better we just omit
all of them from KEYWORDS. Err?
For example, I
Dnia 2014-09-07, o godz. 21:03:00
Rich Freeman ri...@gentoo.org napisał(a):
Right now the general policy is that we don't allow unmasked (hard or
via keywords) ebuilds in the tree if they use an scm to fetch their
sources. There are a bunch of reasons for this, and for the most part
they
Hi,
09.09.14 20:36, hasufell написав(ла):
Michał Górny:
And how can you test a VCS ebuild? You can't assume upstream will be
stuck on one commit.
I don't see the argument. It sounds like you are saying one day,
upstream might stop supporting architecture xy, so better we just omit
all
Jauhien Piatlicki:
When I accept ~arch I expect that no live ebuilds will be built. I think
other gentoo users expect the same.
Just because users are used to it doesn't make it better.
Emerging live ebuild usually is quite a risky thing, so hiding such stuff
behind dropped keywords is
Right now the general policy is that we don't allow unmasked (hard or
via keywords) ebuilds in the tree if they use an scm to fetch their
sources. There are a bunch of reasons for this, and for the most part
they make sense.
I was wondering if this policy still made sense in the case of scm
On 09/07/2014 09:03 PM, Rich Freeman wrote:
Right now the general policy is that we don't allow unmasked (hard or
via keywords) ebuilds in the tree if they use an scm to fetch their
sources. There are a bunch of reasons for this, and for the most part
they make sense.
Hard masking is a relic
31 matches
Mail list logo
