On 09/08/2012 02:43 AM, Ciaran McCreesh wrote:
On Fri, 07 Sep 2012 18:55:10 -0400 Michael Orlitzky
mich...@orlitzky.com wrote:
I think that dependencies are ultimately not hierarchical
Situations like foo? ( bar? ( || ( a ( b c ) ) ) ) do happen, so
any new syntax would have to be able
On 09/07/2012 07:45 AM, Ciaran McCreesh wrote:
Since DEPENDENCIES hasn't been written up in a Gentoo-friendly
manner, and since the Exherbo documentation doesn't seem to suffice
to explain the idea here, here's some more details on the
DEPENDENCIES proposal.
It seems to me that the problem
On 09/05/2012 12:15 PM, Mike Gilbert wrote:
On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky mich...@orlitzky.com wrote:
On 09/04/2012 05:06 PM, Brian Harring wrote:
As a compromise, it could be made policy that bump to EAPI=foo bugs
are valid. If someone would benefit from such a bump, he
On 09/05/2012 05:29 PM, Brian Harring wrote:
Yes, I stated it because I view it as useful/sane.
and isn't a compromise at all.
I think you're mistaken in assuming a compromise is the required
outcome of this. Given the choice between something productive, and
something not
On 09/04/2012 05:06 PM, Brian Harring wrote:
As a compromise, it could be made policy that bump to EAPI=foo bugs
are valid. If someone would benefit from such a bump, he can file a bug
and know that it won't be closed WONTFIX. On the other hand, the dev is
under no more pressure than usual to
On 09/02/2012 09:46 AM, Rich Freeman wrote:
On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel dilfri...@gentoo.org
wrote:
What I dont actually understand at all is why bumping the EAPI should be so
complicated or involved that it even deserves so much resistance...
rantOk, it REALLY
On 08/01/12 16:18, Andreas K. Huettel wrote:
If it turns out that C or POSIX is the most common response, we should
then default the locale to en_US.UTF-8 if we really want to default to
a UTF-8 setting. The reason being it makes sense to have the default
locale set to the country of
On 07/30/12 15:02, Walter Dnes wrote:
Would forcing UTF-8 cause problems for packages that expect
specific ISO encodings in X fonts?
Not that I know of (and setting a default wouldn't force anything).
xfreecell's readme states Make sure there is a font named 7x14 and
another thread mentions
On 07/27/12 16:16, Aaron W. Swenson wrote:
No user will be happy with whatever we decide to use as a default.
The defaults should be what's best for the most people, with a bias
towards safety. Why don't we just take a survey and choose the most
common utf8 response?
On 07/30/12 10:41, Michał Górny wrote:
On Mon, 30 Jul 2012 10:35:36 -0400
Michael Orlitzky mich...@orlitzky.com wrote:
On 07/27/12 16:16, Aaron W. Swenson wrote:
No user will be happy with whatever we decide to use as a default.
The defaults should be what's best for the most people
On 07/30/12 12:28, Michał Górny wrote:
My point here is that you want the thing to change. So you first try to
convince people here to change. We practically did a small survey here
and in the result we didn't agree on doing the change.
So you're saying we should do another survey on
On 07/26/12 14:26, Rich Freeman wrote:
I've been messing around with namespaces and some of what systemd has
been doing with them, and I have an idea for a portage feature.
But before doing a brain dump of ideas, how useful would it be to have
a FEATURE for portage to do a limited-visibility
On 07/24/12 09:21, Ian Stakenvicius wrote:
Given that this just affects new installs, is a news item (via
portage) a particularly good way to inform everyone? I was wondering
if it'd make more sense to notify on the website and *definitely*
change the Handbook...
..and maybe include an
On 07/24/12 14:52, Rick Zero_Chaos Farina wrote:
This is a big enough change that it will throw users who do not know,
and my first impression of /etc/make.conf et all missing on a new stage
is file a bug report for a broken stage and assign it to those morons
in releng. (please note the
On 07/17/12 07:21, Eray Aslan wrote:
On 07/17/2012 02:00 PM, Dirkjan Ochtman wrote:
It may be a small issue, but since the potential pain is quite large,
Yes, that's the idea.
since postfix config file changes are usually
pretty hard to review for merges.
Hmm, that's a failure on our
On 06/15/12 09:32, Michał Górny wrote:
It is a little confusing when the function reports .a removal when no
such file exists. Also, explain why the file is removed.
Why keep the -f?
---
eclass/eutils.eclass |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On 05/31/12 16:09, Michał Górny wrote:
On Thu, 31 May 2012 15:58:43 -0400
Rich Freeman ri...@gentoo.org wrote:
On Thu, May 31, 2012 at 3:33 PM, Michał Górny mgo...@gentoo.org
wrote:
What would git signing work with rebased commits? Would all of them
have to be signed once again?
The
On 05/30/2012 05:23 PM, Mike Frysinger wrote:
On Wednesday 30 May 2012 13:01:24 Michał Górny wrote:
This issue was given my attention through bug 418217 [1]. Long
story short -- there are applications which call pager
implicitly. Those are git systemd. They don't actually require
any pager
How about introducing e.g. FEATURES=nouserpriv, and make the current
userpriv behavior the default?
The migration might be a bit more confusing, but it allows portage to
gradually adopt better stuff without having FEATURES=everything under
the sun.
On 05/29/12 15:58, Mike Gilbert wrote:
On Tue, May 29, 2012 at 3:46 PM, Michael Orlitzky mich...@orlitzky.com
wrote:
How about introducing e.g. FEATURES=nouserpriv, and make the current
userpriv behavior the default?
Portage currently defaults to running the build process as root
On 05/05/12 14:40, Andreas K. Huettel wrote:
Hiya,
there's a growing culture of libreoffice extensions, and (with the help of an
eclass prepared by scarabeus) it would be nice to get some of them into the
portage tree. Now we have to decide where to put them.
Suggestion: new category
On 03/22/2012 03:29 AM, Samuli Suominen wrote:
On 03/22/2012 09:25 AM, Samuli Suominen wrote:
If anyone is intrested in helping around with Xfce we have 2 bigger
tasks on going:
1) Pass --libexecdir=${EPREFIX} to all plugins installing to
/usr/libexec/xfce4/ as opposed to /usr/lib/xfce4/
On 03/16/12 11:18, Greg KH wrote:
At least find a package that people use :)
www-client/httrack?
On 03/13/2012 08:29 PM, Walter Dnes wrote:
I'm answering Ciaran's and Brian's posts together, because the answer
is the same for both... namely, we need a 2-pass processor, regardless
of whether it's bash/perl/python/whatever. Pass 1 checks for syntax
errors and retrieves special variables,
On 03/13/2012 10:05 PM, Zac Medico wrote:
On 03/13/2012 06:42 PM, Brian Harring wrote:
Leaving it such that the PM has to enforce things like don't have
multiple EAPI assignments means by default, one of them isn't going
to... leading to the ebuilds breaking... specifically the common case
On 03/13/2012 10:36 PM, Zac Medico wrote:
On 03/13/2012 07:23 PM, Michael Orlitzky wrote:
Someone should really throw up a table on wiki.g.o with a comparison of
the proposed methods.
We've got one already:
http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms
*facepalm*
On 03/12/12 13:12, Ciaran McCreesh wrote:
On Mon, 12 Mar 2012 18:05:46 +0100
Ulrich Mueller u...@gentoo.org wrote:
See above, even if we should ever move away from bash, GLEP 55 is
still not needed.
...but we might as well go with GLEP 55 anyway, since GLEP 55
definitely works, whereas
On 03/09/12 00:51, Zac Medico wrote:
On 03/08/2012 09:35 PM, Michael Orlitzky wrote:
The function can do any crazy thing you want.
We don't need a function. We need to know the EAPI before we source the
ebuild, and a function doesn't give us that.
Surely we can source one or two lines
On 03/09/12 10:05, Zac Medico wrote:
Surely we can source one or two lines of the ebuild safely, like the
example shows?
Why would we though, when sourcing is a relatively costly operation, and
there are much more efficient ways to get the EAPI?
There do not seem to be any that people
On 03/09/12 10:58, Zac Medico wrote:
On 03/09/2012 07:51 AM, Alexis Ballier wrote:
On Fri, 09 Mar 2012 07:41:09 -0800
Zac Medico zmed...@gentoo.org wrote:
On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
The advantage that the eapi function has over a comment is that
it's not magic -- it's
On 03/09/12 11:29, Michał Górny wrote:
What if bash starts to parse the script completely and barfs at 'syntax
error' before it starts executing stuff?
It doesn't parse the script completely, it executes line-by-line, so we
can bail out early.
This returns 1:
exit 1
On 03/09/12 12:11, Ulrich Mueller wrote:
On Fri, 09 Mar 2012, Michael Orlitzky wrote:
What if bash starts to parse the script completely and barfs at
'syntax error' before it starts executing stuff?
It doesn't parse the script completely, it executes line-by-line, so
we can bail out early
On 03/09/12 12:47, Zac Medico wrote:
Ulrich is talking about extensions which require a newer version of
bash. These kinds of extensions are quite common and don't cause
massive breaking because people simply have to upgrade bash in order
to use the new extensions, and their old scripts
On 03/09/12 13:02, James Broadhead wrote:
On 9 March 2012 17:31, Michael Orlitzky mich...@orlitzky.com wrote:
At any rate, I'm now convinced that we all want GLEP 55, but with a
different name.
I think that moving the data to the filename is probably a better
approach than semi- or repeat
On 03/09/12 13:56, Zac Medico wrote:
On 03/09/2012 10:33 AM, Michael Orlitzky wrote:
On 03/09/12 13:02, James Broadhead wrote:
On 9 March 2012 17:31, Michael Orlitzky mich...@orlitzky.com wrote:
At any rate, I'm now convinced that we all want GLEP 55, but with a
different name.
I think
On 03/08/2012 07:03 AM, Michał Górny wrote:
Someone suggested using a standard shebang the last time this came
up, and if I remember correctly it was one of the least-disagreeable
solutions proposed. We could of course define our own custom format,
but I think something like,
On 03/07/2012 03:41 PM, Ulrich Mueller wrote:
*** Proposal 1: Parse the EAPI assignment statement ***
There's also libbash now:
http://www.gentoo.org/proj/en/libbash/index.xml
Anyone know how close we are to being able to use it to parse the EAPI?
On 03/08/2012 12:28 PM, Michał Górny wrote:
And something will need to provide that /usr/bin/eapi4 thing. And that
introduces new problems:
I'm just parroting someone else's suggestion; I don't really know enough
about the details to answer these properly. Not that that will stop me.
1)
On 03/08/2012 12:53 PM, Ciaran McCreesh wrote:
On Thu, 08 Mar 2012 12:48:51 -0500
Michael Orlitzkymich...@orlitzky.com wrote:
On 03/08/2012 12:28 PM, Michał Górny wrote:
And something will need to provide that /usr/bin/eapi4 thing. And
that introduces new problems:
I'm just parroting
On 03/08/2012 01:48 PM, Ciaran McCreesh wrote:
If they're code, they're code, and we need to execute them somehow.
The notion of execute them somehow that's used doesn't fit in with
the #! interpreter model. You aren't executing ebuilds via an
interpreter. You're performing an action that
On 03/09/2012 12:04 AM, Michał Górny wrote:
This is of course isomorphic to requiring a specific EAPI=4 format,
but does allow you to do stupid things like x=`seq 4 4`; eapi $x; if
you want.
What advantage does it give us? We still can't change ebuild syntax in
global scope because bash will
On 03/07/2012 03:41 PM, Ulrich Mueller wrote:
*** Proposal 2: EAPI in header comment ***
A different approach would be to specify the EAPI in a specially
formatted comment in the ebuild's header. No syntax has been suggested
yet, but I believe that the following would work as a specification:
901 - 942 of 942 matches
Mail list logo
