On 11/12/13 22:41, William Hubbs wrote:
> All,
>
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].
which we ship as app-shells/rc and rename 'rc' to 'rcsh'
Dnia 2013-12-11, o godz. 23:10:12
Greg Turner napisał(a):
> Encouraging everyone to wrap headers, even, for example, in
> pathological cases where there is not, in fact, any header conflict
> between ABI's, to begin with, seems to me like incurring a cost
> (likelihood of broken autotools macros)
On Wed, Dec 11, 2013 at 10:33 PM, Michał Górny wrote:
>> Regardless, if our standard advice is "try not to use this automagic
>> header wrapping feature, it can break autoconf assumptions" (IIRC, it
>> is -- but if it isn't, it probably should be), then we ought to
>> provide /some/ convenient mea
Dnia 2013-12-11, o godz. 17:20:08
Greg Turner napisał(a):
> On Wed, Dec 11, 2013 at 1:37 PM, hasufell wrote:
> > On 12/11/2013 10:18 PM, Greg Turner wrote:
> >>
> >
> > this needs more explanation. Why do we want this?
>
> Sometimes the automagic header stuff is working against the ebuild
> aut
On Wed, Dec 11, 2013 at 6:33 PM, Jonathan Callen wrote:
> The *last* eclass inherited
Well I'll be ferschnookered!
Googling confirms this. I'm quite shocked. I have believed the
opposite, for a very long time, with perfect confidence. No idea why
I thought so -- in retrospect, I'm pretty sure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/11/2013 07:54 PM, Greg Turner wrote:
> On Wed, Dec 11, 2013 at 2:01 PM, hasufell wrote:
>> I actually feel that some parts of this is not documentation, but rather
>> "wiki". So maybe
>> that's exactly where to put it?
>>
>> The doc in the e
On Wed, Dec 11, 2013 at 3:18 PM, Greg Turner wrote:
> sorry for attaching these rather than in-lining but google insists on
> 78-wrapping plain-text e-mail. If HTML mail would be a better
> solution for people I'd be happy to re-send (unless maybe a single
> person requests it and a chorus of obj
On Wed, Dec 11, 2013 at 6:37 PM, Patrick Lauer wrote:
> On 12/12/2013 04:41 AM, William Hubbs wrote:
>> All,
>>
>> We got a request from Debian to rename the "rc" binary of OpenRC due to
>> a naming conflict they have. They have a port of the at&t plan 9 shell,
>> which has a binary named "rc" as
On Wed, Dec 11, 2013 at 1:37 PM, hasufell wrote:
> On 12/11/2013 10:18 PM, Greg Turner wrote:
>>
>
> this needs more explanation. Why do we want this?
Sometimes the automagic header stuff is working against the ebuild
author, or at least threatens to, in the future.
The most plausible etiology w
On Wed, Dec 11, 2013 at 1:44 PM, hasufell wrote:
> It should be made clear who is the initial/original author. Maintainer
> can be quite anyone.
IIRC there's now a @DOC_THINGY for that; I'll use it in the next
version of this patch series, should there be one.
-gmt
On Wed, Dec 11, 2013 at 2:01 PM, hasufell wrote:
> I actually feel that some parts of this is not documentation, but rather
> "wiki". So maybe that's exactly where to put it?
>
> The doc in the eclass should only describe the behavior of the eclass
> and the main points you need to know in order t
On 12/12/2013 05:28 AM, Rich Freeman wrote:
> On Wed, Dec 11, 2013 at 3:47 PM, Chris Reffett wrote:
>> The idea of running a sed on inittab in an ebuild, no matter what the
>> context, terrifies me. Perhaps we can ease this in slowly by renaming rc ->
>> openrc and symlinking rc -> openrc and maki
On 12/12/2013 04:41 AM, William Hubbs wrote:
> All,
>
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].
>
> My thought is to rename our "rc" to "openrc", s
On Wed, Dec 11, 2013 at 2:41 PM, Michał Górny wrote:
> Very limited usefulness, a lot of extra complexity
Can't say I entirely agree on either point, but it wouldn't
meaningfully jam up my patch queues, which makes me much less inclined
to be attached to it.
Another reason, upon consideration, n
On Wed, Dec 11, 2013 at 2:40 PM, Michał Górny wrote:
>> This patch adds multilib_src_{configure,compile,test}_all
>> callbacks, analogous to the existing multilib_src_install_all
>> callback.
>
> No real benefit in having those.
There is no fundamental semantic benefit I can think of; indeed, as
On Tue, Dec 10, 2013 at 8:55 PM, Pacho Ramos wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=197625#c14
>
> This has reminded me that maybe we should switch to cronie from
> vixie-cron as default and recommended cron provider in Handbook. Last
> time I checked, vixie-cron upstream was died while
Dnia 2013-12-11, o godz. 13:18:54
Greg Turner napisał(a):
> This patch adds multilib_src_{configure,compile,test}_all
> callbacks, analogous to the existing multilib_src_install_all
> callback.
No real benefit in having those. They will introduce more confusion
because -- as hasufell pointed out
On Wed, Dec 11, 2013 at 09:09:16PM +, Markos Chandras wrote:
> If that's the case then I see no reason to go through the migration path
> for users :) The symlink thing can be done immediately.
> I am wondering, wouldn't Debian be able to rename "rc" to "openrc" in
> their openrc package just b
On Wed, Dec 11, 2013 at 09:28:09PM +, Duncan wrote:
> Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 + as excerpted:
>
> > On 12/11/2013 08:47 PM, Chris Reffett wrote:
> >> On 12/11/2013 3:41 PM, William Hubbs wrote:
> >>>
> >>> My thought is to rename our "rc" to "openrc", since that
Dnia 2013-12-11, o godz. 13:19:04
Greg Turner napisał(a):
>
Very limited usefulness, a lot of extra complexity. We'd rather work on
making eclasses simpler.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11.12.2013 22:07, Peter Stuge wrote:
>> If vixie-cron upstream is dead as you say
> Define dead?
The latest upstream release is this:
cron_4.1.shar 2004-Jan-23 19:20:23200.7K application/octet-stream
As you can see, it will turn ten soon.
On Wed, Dec 11, 2013 at 1:30 PM, Peter Stuge wrote:
>
>
> I think that nobody who is not intimately familiar with the
> development in both projects can think anything that is actionable.
>
> It's insulting to see how people all over the internet run as fast
> as they possibly can in whatever dire
On 12/11/2013 10:18 PM, Greg Turner wrote:
>
I actually feel that some parts of this is not documentation, but rather
"wiki". So maybe that's exactly where to put it?
The doc in the eclass should only describe the behavior of the eclass
and the main points you need to know in order to get it go
On 12/11/2013 10:47 PM, Ulrich Mueller wrote:
>> On Wed, 11 Dec 2013, hasufell wrote:
>
>> I'd actually consider to remove all "*_all" phases since you can achive
>> the same via:
>
>> src_install() {
>> multilib-minimal_src_install
>> generic install crap || die
>> }
>
>> and hav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
we will need to wait for @multilib to comment as well, because
multilib-minimal is used in autotools-multilib.eclass and netsurf.eclass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.
> On Wed, 11 Dec 2013, hasufell wrote:
> I'd actually consider to remove all "*_all" phases since you can achive
> the same via:
> src_install() {
> multilib-minimal_src_install
> generic install crap || die
> }
> and have more control over the call order.
It's not completely e
It should be made clear who is the initial/original author. Maintainer
can be quite anyone.
On 12/11/2013 10:18 PM, Greg Turner wrote:
>
this needs more explanation. Why do we want this?
I'd actually consider to remove all "*_all" phases since you can achive
the same via:
src_install() {
multilib-minimal_src_install
generic install crap || die
}
and have more control over the call order.
But then again that will change behavior. So I am not sure about this
featur
Markos Chandras posted on Wed, 11 Dec 2013 20:53:04 + as excerpted:
> On 12/11/2013 08:47 PM, Chris Reffett wrote:
>> On 12/11/2013 3:41 PM, William Hubbs wrote:
>>>
>>> My thought is to rename our "rc" to "openrc", since that would be
>>> unique.
>>>
>>> I know at least one thing that will br
On Wed, Dec 11, 2013 at 3:47 PM, Chris Reffett wrote:
> The idea of running a sed on inittab in an ebuild, no matter what the
> context, terrifies me. Perhaps we can ease this in slowly by renaming rc ->
> openrc and symlinking rc -> openrc and making a release with that change
> concurrent with a
That's all folks! Let the flame-war begin!
:P
-gmt
P.S., stay tuned, there's more where these came from.
--- 005-MULTILIB_PARALLEL_PHASES/multilib-minimal.eclass 2013-12-03 02:59:33.687448429 -0800
+++ 006-authors/multilib-minimal.eclass 2013-12-03 03:03:07.574913106 -0800
@@ -5,6 +5,10 @@
# @
This patch adds a new frob, MULTILIB_PARALLEL_PHASES, to
multlib-minimal.eclass, which implements eclass-consumer-selectable
parallelization of src_configure, src_compile, and src_test.
By default, all parallelization is deactivated, which represents
a change from the previous gentoo-x86 behavior
This patch adds multilib_src_{configure,compile,test}_all
callbacks, analogous to the existing multilib_src_install_all
callback.
--- 003-in-source-doc/multilib-minimal.eclass 2013-12-03 02:45:19.428664959 -0800
+++ 004-multilib-phase-all/multilib-minimal.eclass 2013-12-03 02:54:40.045335905 -080
This rewrites the multilib-minimal.eclass in-source documentation,
providing considerably more hand-holding for end-users, exploring
some pitfalls that users may encounter, and clarifying some
less-than lucid language.
It also reverses an existing in-source comment about inheritance
ordering, whi
Groking flow-of-control in multibuild-based ebuilds is
nontrivial. These can help.
--- 000-header/multilib-minimal.eclass 2013-12-03 02:13:48.115445273 -0800
+++ 001-debug-print-function/multilib-minimal.eclass 2013-12-03 02:17:30.144384409 -0800
@@ -36,7 +36,11 @@ EXPORT_FUNCTIONS src_configure
Add a MULTILIB_INSECURE_INSTALL variable to eclass/multilib-minimal.eclass
Sometimes the "multilib magic header" business is an unwanted
feature. For example, it is infuriating to be forced
to wrap a header file (or, less offensively, but still quite
offensively, to be forced to implement inter-
sorry for attaching these rather than in-lining but google insists on
78-wrapping plain-text e-mail. If HTML mail would be a better
solution for people I'd be happy to re-send (unless maybe a single
person requests it and a chorus of objections are raised :P).
This series is available also in bug
On Wed, Dec 11, 2013 at 09:09:16PM +, Markos Chandras wrote:
> If that's the case then I see no reason to go through the migration path
> for users :) The symlink thing can be done immediately.
Awesome. Great to hear it!
> I am wondering, wouldn't Debian be able to rename "rc" to "openrc" in
On 12/11/2013 08:56 PM, Paul Tagliamonte wrote:
>
> [I'm not the OpenRC maintainer, I'm only on gentoo-devel because I'm
> generally interested, and I saw this, I'm not speaking for zigo or
> anything here.]
>
> On Wed, Dec 11, 2013 at 03:47:57PM -0500, Chris Reffett wrote:
>>The idea of ru
Markos Chandras wrote:
> > Last time I checked, vixie-cron upstream was died
>
> If vixie-cron upstream is dead as you say
Define dead?
//Peter
On Wed Dec 11 23:30:58 2013 Peter Stuge wrote:
> Pacho Ramos wrote:
> > Last time I checked, vixie-cron upstream was died while cronie
> > forked it fixing some bugs :/
> >
> > What do you think?
>
> I think that nobody who is not intimately familiar with the
> development in both projects can t
On Wed, Dec 11, 2013 at 10:47:49PM +0200, Alon Bar-Lev wrote:
> On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs wrote:
> >
> > All,
> >
> > We got a request from Debian to rename the "rc" binary of OpenRC due to
> > a naming conflict they have. They have a port of the at&t plan 9 shell,
> > which
[I'm not the OpenRC maintainer, I'm only on gentoo-devel because I'm
generally interested, and I saw this, I'm not speaking for zigo or
anything here.]
On Wed, Dec 11, 2013 at 03:47:57PM -0500, Chris Reffett wrote:
>The idea of running a sed on inittab in an ebuild, no matter what the
>
On 12/11/2013 08:47 PM, Chris Reffett wrote:
> On 12/11/2013 3:41 PM, William Hubbs wrote:
>> All,
>>
>> We got a request from Debian to rename the "rc" binary of OpenRC due to
>> a naming conflict they have. They have a port of the at&t plan 9 shell,
>> which has a binary named "rc" as well[1].
>>
On 12/11/2013 3:41 PM, William Hubbs wrote:
> All,
>
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].
>
> My thought is to rename our "rc" to "openrc", sinc
On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs wrote:
>
> All,
>
> We got a request from Debian to rename the "rc" binary of OpenRC due to
> a naming conflict they have. They have a port of the at&t plan 9 shell,
> which has a binary named "rc" as well[1].
>
> My thought is to rename our "rc" to
All,
We got a request from Debian to rename the "rc" binary of OpenRC due to
a naming conflict they have. They have a port of the at&t plan 9 shell,
which has a binary named "rc" as well[1].
My thought is to rename our "rc" to "openrc", since that would be
unique.
I know at least one thing that
On 12/10/2013 08:55 PM, Pacho Ramos wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=197625#c14
>
> This has reminded me that maybe we should switch to cronie from
> vixie-cron as default and recommended cron provider in Handbook. Last
> time I checked, vixie-cron upstream was died while cronie fo
On Wed, Dec 11, 2013 at 2:25 PM, Michael Orlitzky wrote:
> On 12/10/2013 09:18 PM, Paul B. Henson wrote:
>>
>> I'd say go one step further and get rid of vixie-cron completely, is
>> there anything it does that cronie can't do as well or better?
>
> Is cronie a drop-in replacement, or do I have to
Pacho Ramos wrote:
> Last time I checked, vixie-cron upstream was died while cronie
> forked it fixing some bugs :/
>
> What do you think?
I think that nobody who is not intimately familiar with the
development in both projects can think anything that is actionable.
It's insulting to see how peo
On 12/10/2013 09:18 PM, Paul B. Henson wrote:
>
> I'd say go one step further and get rid of vixie-cron completely, is
> there anything it does that cronie can't do as well or better?
Is cronie a drop-in replacement, or do I have to do some thinking when
replacing vixie-cron?
On Tue, Dec 10, 2013 at 09:55:05PM +0100, Pacho Ramos wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=197625#c14
>
> This has reminded me that maybe we should switch to cronie from
> vixie-cron as default and recommended cron provider in Handbook. Last
> time I checked, vixie-cron upstream was di
On Tue, Dec 10, 2013, Steev Klimaszewski wrote:
> On Tue, 2013-12-10, Rich Freeman wrote:
> > On Tue, Dec 10, 2013, Steev Klimaszewski wrote:
> > > On Mon, 2013-12-09, Rich Freeman wrote:
> > > You're thinking with your x86/amd64 hat on here.
> >
> > Actually, I probably just underquoted. I am we
54 matches
Mail list logo
