On Sun, 7 Jun 2009, Robin H Johnson wrote:
Is [[ a bashism or not? That's all I'm asking.
/bin/sh under FreeBSD 7.0:
$ [[ -n foo ]]
[[: not found
Ulrich
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires us to actually utilize /libexec/ which is not a Linux convention
on any system ive ever seen. i
Hi all,
currently I am the only active developer in the apache herd, but
quite busy with work and life, so I'd like to ask all of you to fix bugs
assigned to apache-bugs@ if you come across them/if they annoy you etc,
since i cannot keep up with bugs currently. I'd also like to see more
active
Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote:
Roy: [[ or [?
Entirely depends on system.
OpenRC uses /bin/sh to process the actual init script. We rely on /bin/sh
claiming POSIX compat [1]. On Gentoo Linux systems, this is normally a link
to bash, so you
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires us to actually utilize /libexec/ which is not a Linux convention
on any
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires us to actually
On Sat, 2009-06-06 at 23:31 +0100, Roy Bamford wrote:
I've spent some time reading all of this years emails on GLEP55 and
added a few lines to version 1.5 which is the last offical version.
Is there a specific reason not to include the inherit eapi[1][2]
thing?
IMHO this would fit best in
On Monday 08 June 2009 06:00:14 Roy Marples wrote:
Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 12:00:59AM +0100, Roy Marples wrote:
IIRC vapier patched busybox to alias [[ to [, which is worse as you
still have to quote correctly as if [ and you don't get the =~ operator
from [[.
i
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version (possible including a git ID) of the release.
that requires
On Monday 08 June 2009 06:35:37 Roy Marples wrote:
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing the
version
On Monday 08 June 2009 06:39:53 Joe Peterson wrote:
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
Joe Peterson wrote:
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?
The only dirs that are guaranteed to be available at boot are
/dev
/etc
/lib
/bin
/sbin
Plus these OS
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.
Mike Frysinger wrote:
On Monday 08 June 2009 06:35:37 Roy Marples wrote:
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC will provide /libexec/rc/version, a text file containing
On Monday 08 June 2009, Benedikt Böhm wrote:
Hi all,
currently I am the only active developer in the apache herd, but
quite busy with work and life, so I'd like to ask all of you to fix
bugs assigned to apache-bugs@ if you come across them/if they annoy
you etc, since i cannot keep up with
On Monday 08 June 2009 07:03:37 Roy Marples wrote:
Mike Frysinger wrote:
On Monday 08 June 2009 06:35:37 Roy Marples wrote:
Mike Frysinger wrote:
On Monday 08 June 2009 06:12:04 Roy Marples wrote:
Mike Frysinger wrote:
On Sunday 07 June 2009 15:59:50 Robin H. Johnson wrote:
1. OpenRC
i didnt see any real discussion of /sbin/functions.sh ... i dont recall there
being a reason historically for not checking for this file to detect
baselayout-1 vs openrc, and no one has complained about its usage in mdadm ...
-mike
Roy Bamford wrote:
On 2009.06.07 10:34, Ulrich Mueller wrote:
On Sun, 07 Jun 2009, Steven J Long wrote:
I'd just like to know what the implications would be for users if
we
kept the .ebuild extension, and a new PMS were rolled out stating
that the mangler were allowed to find the EAPI
Jorge Manuel B. S. Vicetto wrote:
I'd like to second: amne solar grobian leio and darkside
and nominate: robbat2
As ever, I'm disappointed I can't nominate you, jmb.
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Mike Frysinger wrote:
the original discussion made it sound like /etc/openrc-version always existed
independent of libexec
That is incorrect.
Thanks
Roy
Mike Frysinger wrote:
i didnt see any real discussion of /sbin/functions.sh ... i dont recall there
being a reason historically for not checking for this file to detect
baselayout-1 vs openrc, and no one has complained about its usage in mdadm ...
That works as a baselayout-1 vs openrc test.
On Monday 08 June 2009 09:01:46 Roy Marples wrote:
Mike Frysinger wrote:
i didnt see any real discussion of /sbin/functions.sh ... i dont recall
there being a reason historically for not checking for this file to
detect baselayout-1 vs openrc, and no one has complained about its usage
in
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it should
itself be setting up an env var for init.d scripts to key off of rather than
having to figure out what's going on via the filesystem. the point of this
thread is to detect baselayout-1 vs openrc
On Monday 08 June 2009 09:09:43 Roy Marples wrote:
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it should
itself be setting up an env var for init.d scripts to key off of rather
than having to figure out what's going on via the filesystem. the point
Mike Frysinger wrote:
On Monday 08 June 2009 09:09:43 Roy Marples wrote:
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it should
itself be setting up an env var for init.d scripts to key off of rather
than having to figure out what's going on via the
On Monday 08 June 2009 10:00:23 Roy Marples wrote:
Mike Frysinger wrote:
On Monday 08 June 2009 09:09:43 Roy Marples wrote:
Mike Frysinger wrote:
if openrc versions are causing a level of incompatibility, then it
should itself be setting up an env var for init.d scripts to key off of
O
Date: Sat, 06 Jun 2009 23:31:47 +0100
From: Roy Bamford neddyseag...@gentoo.org
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] GLEP 55 Version 2
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ladies and Gentlemen,
I've spent some time reading all of this years emails on
On Mon, 08 Jun 2009 19:17:56 +0100
Steven J Long sl...@rathaus.eclipse.co.uk wrote:
If the problem had been adequately communicated in the first place
(which is pretty much required for any proposal ime) instead of people
being told they don't understand so go away we could have agreed
then,
Hi
I'd like to raise your attention on problem of in my opinion overusing IUSE
defaults in various packages.
Currently there seems to be no policy whatsoever at least advising when it's
appropriate to add +useflag and when not, so it's just up to developer's
taste.
While it usually doesn't do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.06.08 19:35, Ciaran McCreesh wrote:
[snip]
Easily-extractable EAPI either has change scope limitations or a
considerable performance impact.
That needs to be quantified. e.g. 20ms to 200ms is a factor of 10x but
it would not be considered
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2009.06.08 16:48, Ferris McCormick wrote:
[snip]
Very small point. There is a difference between EAPI in the file
name
extension and just EAPI in the file name. I think the intent here
is
the latter, but it speaks of them interchangeably it
On Monday 08 June 2009 20:35:22 Ciaran McCreesh wrote:
On Mon, 08 Jun 2009 19:17:56 +0100
And how much developer time would be wasted to do so, and indeed has
already been wasted on this?
Thanks to emails like yours, lots.
5-2009, 800 emails
11.75% ciaran.mccreesh.googlemail.com
4-2009,
On Monday 08 of June 2009 22:41:12 Patrick Lauer wrote:
[snip]
Thanks for your useless statistics.
--
Cheers
Dawid
On Monday 08 June 2009 16:12:23 Maciej Mrozowski wrote:
I'd like to raise your attention on problem of in my opinion overusing IUSE
defaults in various packages.
Currently there seems to be no policy whatsoever at least advising when
it's appropriate to add +useflag and when not, so it's just
[Answering to a random posting in this thread.]
Please, stop this now, or continue your discussion in private.
Thanks
Ulrich
On Monday 08 June 2009, Maciej Mrozowski wrote:
...
While it usually doesn't do any particular harm (but I guess security
and prefix/alt team won't agree on this) - insanely enabling
everything by default is not the best idea in my opinion.
The Security Team supports all use flag combinations,
On Mon, Jun 08, 2009 at 01:49:38PM +0100, Steven J Long wrote:
Jorge Manuel B. S. Vicetto wrote:
I'd like to second: amne solar grobian leio and darkside
and nominate: robbat2
As I present trustees, I cannot take this position.
I've been on the council before, some years ago, during the CoC
On Mon, Jun 08, 2009 at 07:27:02AM -0400, Mike Frysinger wrote:
Also, should Gentoo (Linux) never break with tradition even if
somethings are better elsewhere?
no, there is no innovation here nor any incentive to do so. i also
personally dont believe in /usr/libexec/, so i'm not going
On Monday 08 June 2009 19:23:01 Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 07:27:02AM -0400, Mike Frysinger wrote:
Also, should Gentoo (Linux) never break with tradition even if
somethings are better elsewhere?
no, there is no innovation here nor any incentive to do so. i
Maciej Mrozowski wrote:
While it usually doesn't do any particular harm (but I guess security and
prefix/alt team won't agree on this) - insanely enabling everything by default
The Prefix team does not care either way.
is not the best idea in my opinion.
Of course we need an example. Let's
On Monday 08 June 2009 18:25:18 Robert Buchholz wrote:
And personally, I hate having to enable USE=png on all my desktop
machines so I can use a desktop background
eh ? USE=png is in all default desktop profiles ...
-mike
signature.asc
Description: This is a digitally signed message part.
On Mon, Jun 08, 2009 at 07:42:17PM -0400, Mike Frysinger wrote:
One of the reasons to move stuff OUT of /lib are all the profiles where
SYMLINK_LIB is disabled AND LIBDIR_${arch} != lib. On non-multilib
systems (so there is no lib23/64) or multilib systems where /lib is the
correct
On Monday 08 June 2009 20:44:35 Robin H. Johnson wrote:
On Mon, Jun 08, 2009 at 07:42:17PM -0400, Mike Frysinger wrote:
One of the reasons to move stuff OUT of /lib are all the profiles where
SYMLINK_LIB is disabled AND LIBDIR_${arch} != lib. On non-multilib
systems (so there is no
i like to use g-cpan more, but as lately it seems not to be so much stable
with latest portage :/
my question is how to make a bug on it or even if its worth doing it, is
there a better proper way of make cpan modules into ebuilds as it was one
time ?
--
http://localhost/ 100% uptime and 100%
On Tue, Jun 9, 2009 at 12:57 PM, Benny Pedersen m...@junc.org wrote:
i like to use g-cpan more, but as lately it seems not to be so much stable
with latest portage :/
my question is how to make a bug on it or even if its worth doing it, is
there a better proper way of make cpan modules into
On Tue, Jun 09, 2009 at 02:57:31AM +0200, Benny Pedersen wrote:
i like to use g-cpan more, but as lately it seems not to be so much stable
with latest portage :/
my question is how to make a bug on it or even if its worth doing it, is
there a better proper way of make cpan modules into
47 matches
Mail list logo
