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 e
On Tue, Jun 9, 2009 at 12:57 PM, 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 ebuilds
On Tuesday 09 June 2009, Mike Frysinger wrote:
> 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 ...
You are correct, I s
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% m
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
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
> > correc
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.
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 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 incen
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/, s
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 C
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 combination
[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 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 + and when not, so it's just up t
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 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-20
-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 interchang
-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
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 + and when not, so it's just up to developer's
taste.
While it usually doesn't do any part
On Mon, 08 Jun 2009 19:17:56 +0100
Steven J Long 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, that the issue was simp
O
>
> Date: Sat, 06 Jun 2009 23:31:47 +0100
> From: Roy Bamford
> 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 GLEP55 and
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 ke
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 file
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
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 onl
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
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.
H
Mike Frysinger wrote:
the original discussion made it sound like /etc/openrc-version always existed
independent of libexec
That is incorrect.
Thanks
Roy
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 ;-)
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 allo
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
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
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 w
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 t
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:
> 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 (u
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 specifi
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 platfo
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
>
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: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
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: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 t
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 s
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
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 mem
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.
47 matches
Mail list logo
