[gentoo-dev] Add bc back to the stage3

[gentoo-dev] Add bc back to the stage3

[Luca Barbato]

The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.

lu

Re: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Tue, Sep 16, 2014 at 7:47 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
> The bc utility is part of the posix tools and it might be used to build
> linux among the other stuff.
>

I'm fine with including useful utilities in the stage3s, as long as
they don't go into the system set.  We really need to get beyond
equating the two.  Otherwise our systems will become a jumble of stuff
that somebody finds useful for something, and then when we remove some
of it we'll get occasional breakage because nobody will declare them
as dependencies.  That just isn't in the spirit of Gentoo.

The system set should only contain stuff that a large percentage of
the tree needs to depend on (let's say more than 20%), or which is
required to be available to bootstrap the rest of the tree.

Once mix-in-like support is available, then profiles can be a dumping
ground for anything anybody finds useful, and the more the merrier...

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Jorge Manuel B. S. Vicetto]

On Wed, 17 Sep 2014, Luca Barbato wrote:

> The bc utility is part of the posix tools and it might be used to build
> linux among the other stuff.

Luca,

bc is not in the system set and is a dependency of the kernel or any other 
package that needs it, so why do we need to include a package that takes 
~20 seconds to build?

> lu

Regards,

Jorge Manuel B. S. Vicetto
Gentoo Developer

Re: [gentoo-dev] Add bc back to the stage3

[vivo75]

Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
> On Wed, 17 Sep 2014, Luca Barbato wrote:
>
>> The bc utility is part of the posix tools and it might be used to build
>> linux among the other stuff.
>
> Luca,
>
> bc is not in the system set and is a dependency of the kernel or any
> other package that needs it, so why do we need to include a package
> that takes ~20 seconds to build?

Most people don't use the ebuild for the kernel

Re: [gentoo-dev] Add bc back to the stage3

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On 2014-09-17 14:20, vivo75@gmail.com wrote:
> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
> > On Wed, 17 Sep 2014, Luca Barbato wrote:
> >
> >> The bc utility is part of the posix tools and it might be used to build
> >> linux among the other stuff.
> >
> > Luca,
> >
> > bc is not in the system set and is a dependency of the kernel or any
> > other package that needs it, so why do we need to include a package
> > that takes ~20 seconds to build?
> 
> Most people don't use the ebuild for the kernel

That's a rather outrageous and difficult to substantiate claim. Given
what I've seen in the forums and on IRC, it would appear the reverse
is true; most people use the ebuild for the kernel.

I wouldn't consider people who deviate from the supported methods as
our concern. If you're smart enough to do that and want to make your
own path, you're smart enough to emerge bc.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanofold@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[Alan McKinnon]

On 17/09/2014 14:49, Aaron W. Swenson wrote:
> On 2014-09-17 14:20, vivo75@gmail.com wrote:
>> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
>>> On Wed, 17 Sep 2014, Luca Barbato wrote:
>>>
>>>> The bc utility is part of the posix tools and it might be used to build
>>>> linux among the other stuff.
>>>
>>> Luca,
>>>
>>> bc is not in the system set and is a dependency of the kernel or any
>>> other package that needs it, so why do we need to include a package
>>> that takes ~20 seconds to build?
>>
>> Most people don't use the ebuild for the kernel
> 
> That's a rather outrageous and difficult to substantiate claim. Given
> what I've seen in the forums and on IRC, it would appear the reverse
> is true; most people use the ebuild for the kernel.
> 
> I wouldn't consider people who deviate from the supported methods as
> our concern. If you're smart enough to do that and want to make your
> own path, you're smart enough to emerge bc.
> 


Agreed. I've been on -user for 10+ years and only a very few fetch their
kernels directly from upstream. The vast majority of users who have
described how they do it simply emerge one of the source packages just
like the handbook says to do.

There's an even split between genkernel users and those who make
menuconfig (100% unscientific survey taken from my brain and nowhere else)



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Wed, Sep 17, 2014 at 9:29 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 17/09/2014 14:49, Aaron W. Swenson wrote:
>
> Agreed. I've been on -user for 10+ years and only a very few fetch their
> kernels directly from upstream. The vast majority of users who have
> described how they do it simply emerge one of the source packages just
> like the handbook says to do.
>

Agree.  Lots of people install web applications by hand, but that
doesn't mean that we should make every web development framework out
there a dependency of apache.

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Samuli Suominen]

On 17/09/14 16:29, Alan McKinnon wrote:
> On 17/09/2014 14:49, Aaron W. Swenson wrote:
>> On 2014-09-17 14:20, vivo75@gmail.com wrote:
>>> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
>>>> On Wed, 17 Sep 2014, Luca Barbato wrote:
>>>>
>>>>> The bc utility is part of the posix tools and it might be used to build
>>>>> linux among the other stuff.
>>>> Luca,
>>>>
>>>> bc is not in the system set and is a dependency of the kernel or any
>>>> other package that needs it, so why do we need to include a package
>>>> that takes ~20 seconds to build?
>>> Most people don't use the ebuild for the kernel
>> That's a rather outrageous and difficult to substantiate claim. Given
>> what I've seen in the forums and on IRC, it would appear the reverse
>> is true; most people use the ebuild for the kernel.
>>
>> I wouldn't consider people who deviate from the supported methods as
>> our concern. If you're smart enough to do that and want to make your
>> own path, you're smart enough to emerge bc.
>>
>
> Agreed. I've been on -user for 10+ years and only a very few fetch their
> kernels directly from upstream. The vast majority of users who have
> described how they do it simply emerge one of the source packages just
> like the handbook says to do.
>
> There's an even split between genkernel users and those who make
> menuconfig (100% unscientific survey taken from my brain and nowhere else)
>
>
>

I've never used gentoo-sources in my life, and always fetched sources by
hand from kernel.org,
but, at the same time, I find it's 100% my own responsibility to cover
any fallout from that,
including manually emerging required dependencies.

- Samuli

Re: [gentoo-dev] Add bc back to the stage3

[Anthony G. Basile]

On 09/17/14 10:13, Samuli Suominen wrote:
> On 17/09/14 16:29, Alan McKinnon wrote:
>> On 17/09/2014 14:49, Aaron W. Swenson wrote:
>>> On 2014-09-17 14:20, vivo75@gmail.com wrote:
>>>> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
>>>>> On Wed, 17 Sep 2014, Luca Barbato wrote:
>>>>>
>>>>>> The bc utility is part of the posix tools and it might be used to build
>>>>>> linux among the other stuff.
>>>>> Luca,
>>>>>
>>>>> bc is not in the system set and is a dependency of the kernel or any
>>>>> other package that needs it, so why do we need to include a package
>>>>> that takes ~20 seconds to build?
>>>> Most people don't use the ebuild for the kernel
>>> That's a rather outrageous and difficult to substantiate claim. Given
>>> what I've seen in the forums and on IRC, it would appear the reverse
>>> is true; most people use the ebuild for the kernel.
>>>
>>> I wouldn't consider people who deviate from the supported methods as
>>> our concern. If you're smart enough to do that and want to make your
>>> own path, you're smart enough to emerge bc.
>>>
>> Agreed. I've been on -user for 10+ years and only a very few fetch their
>> kernels directly from upstream. The vast majority of users who have
>> described how they do it simply emerge one of the source packages just
>> like the handbook says to do.
>>
>> There's an even split between genkernel users and those who make
>> menuconfig (100% unscientific survey taken from my brain and nowhere else)
>>
>>
>>
> I've never used gentoo-sources in my life, and always fetched sources by
> hand from kernel.org,
> but, at the same time, I find it's 100% my own responsibility to cover
> any fallout from that,
> including manually emerging required dependencies.
>
> - Samuli
>
I agree.  Anyone is free to build and install anything without the 
ebuild, but then they're on their own.

Also, who says we're building a linux kernel with our stage3s?  I may 
want on just as a chroot or container, or run it on a non-linux kernel.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Add bc back to the stage3

[Luca Barbato]

On 17/09/14 14:09, Jorge Manuel B. S. Vicetto wrote:
> On Wed, 17 Sep 2014, Luca Barbato wrote:
>
>> The bc utility is part of the posix tools and it might be used to build
>> linux among the other stuff.
>
> Luca,
>
> bc is not in the system set and is a dependency of the kernel or any
> other package that needs it, so why do we need to include a package that
> takes ~20 seconds to build?

Because I'd expect a stage3 to be posix compliant and it is a pain to 
remember that Gentoo doesn't have it by default (since the errors can be 
quite vague).

lu

Re: [gentoo-dev] Add bc back to the stage3

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

On Sat, 27 Sep 2014 12:47:14 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Because I'd expect a stage3 to be posix compliant

I agree. It's time to replace nano with Vim.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[Vladimir Romanov]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Em. I don't agree. I prefer Emacs and don't like Vim. But if i must choose
between Vim and Nano, i prefer Nano

2014-09-27 18:22 GMT+06:00 Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:

> On Sat, 27 Sep 2014 12:47:14 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > Because I'd expect a stage3 to be posix compliant
>
> I agree. It's time to replace nano with Vim.
>
> --
> Ciaran McCreesh
>

[-- Attachment #2: Type: text/html, Size: 855 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]

On Sat, 27 Sep 2014 18:31:03 +0600
Vladimir Romanov <blueboar2@gmail.com> wrote:
> Em. I don't agree. I prefer Emacs and don't like Vim. But if i must
> choose between Vim and Nano, i prefer Nano

But vi is POSIX.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[Vladimir Romanov]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

Well, if vi is posix, and it is so important, then you may use it. But
please, don't delete nano.

2014-09-27 18:40 GMT+06:00 Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:

> On Sat, 27 Sep 2014 18:31:03 +0600
> Vladimir Romanov <blueboar2@gmail.com> wrote:
> > Em. I don't agree. I prefer Emacs and don't like Vim. But if i must
> > choose between Vim and Nano, i prefer Nano
>
> But vi is POSIX.
>
> --
> Ciaran McCreesh
>

[-- Attachment #2: Type: text/html, Size: 887 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[Ben de Groot]

On 27 September 2014 20:40, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 27 Sep 2014 18:31:03 +0600
> Vladimir Romanov <blueboar2@gmail.com> wrote:
>> Em. I don't agree. I prefer Emacs and don't like Vim. But if i must
>> choose between Vim and Nano, i prefer Nano
>
> But vi is POSIX.

vi is available through busybox already

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Add bc back to the stage3

[Luca Barbato]

On 27/09/14 14:22, Ciaran McCreesh wrote:
> On Sat, 27 Sep 2014 12:47:14 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Because I'd expect a stage3 to be posix compliant
>
> I agree. It's time to replace nano with Vim.
>

Surely certain stuff might enjoy having ex available as well.

Probably busybox could be enough for both use-cases.

lu

Re: [gentoo-dev] Add bc back to the stage3

[Luca Barbato]

On 27/09/14 15:19, Luca Barbato wrote:
> On 27/09/14 14:22, Ciaran McCreesh wrote:
>> On Sat, 27 Sep 2014 12:47:14 +0200
>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> Because I'd expect a stage3 to be posix compliant
>>
>> I agree. It's time to replace nano with Vim.
>>
>
> Surely certain stuff might enjoy having ex available as well.
>
> Probably busybox could be enough for both use-cases.

What about documenting this detail somewhere?

lu

Re: [gentoo-dev] Add bc back to the stage3

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

On 28 September 2014 00:22, Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
wrote:

>
> I agree. It's time to replace nano with Vim.



http://i.imgur.com/qRNTQGi.png

-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[hasufell]

Kent Fredric:
> On 28 September 2014 00:22, Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
> wrote:
> 
>>
>> I agree. It's time to replace nano with Vim.
> 
> 
> 
> http://i.imgur.com/qRNTQGi.png
> 

We need a moderated development mailing list.

Re: [gentoo-dev] Add bc back to the stage3

[Mike Gilbert]

On Sat, Sep 27, 2014 at 8:22 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 27 Sep 2014 12:47:14 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Because I'd expect a stage3 to be posix compliant
>
> I agree. It's time to replace nano with Vim.
>

To restate this: There are numerous other utilities specified in POSIX
which we do not have in @system (or the stage3 tarball).

Re: [gentoo-dev] Add bc back to the stage3

[Anthony G. Basile]

On 09/27/14 11:19, Mike Gilbert wrote:
> On Sat, Sep 27, 2014 at 8:22 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Sat, 27 Sep 2014 12:47:14 +0200
>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> Because I'd expect a stage3 to be posix compliant
>> I agree. It's time to replace nano with Vim.
>>
> To restate this: There are numerous other utilities specified in POSIX
> which we do not have in @system (or the stage3 tarball).
>
Agreed.  The argument "its posix and should be in there" doesn't fit the 
criterion for a stage3 tarball.  A stage3 should be "a minimal set from 
which any gentoo system can be built" (modulo arch, abi, libc, ..., of 
course.)  Emerging any linux kernel package will pull in bc (see 
REDEPEND in kernel-2.eclass) and therefore bc is not needed to complete 
that minimal set.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Add bc back to the stage3

[Panagiotis Christopoulos]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On 11:24 Sat 27 Sep     , Anthony G. Basile wrote:
> On 09/27/14 11:19, Mike Gilbert wrote:
> > On Sat, Sep 27, 2014 at 8:22 AM, Ciaran McCreesh
> > <ciaran.mccreesh@googlemail.com> wrote:
> >> On Sat, 27 Sep 2014 12:47:14 +0200
> >> Luca Barbato <lu_zero@gentoo.org> wrote:
> >>> Because I'd expect a stage3 to be posix compliant
> >> I agree. It's time to replace nano with Vim.
> >>
> > To restate this: There are numerous other utilities specified in POSIX
> > which we do not have in @system (or the stage3 tarball).
> >
> Agreed.  The argument "its posix and should be in there" doesn't fit the 
> criterion for a stage3 tarball.  A stage3 should be "a minimal set from 
> which any gentoo system can be built" (modulo arch, abi, libc, ..., of 
> course.)  Emerging any linux kernel package will pull in bc (see 
> REDEPEND in kernel-2.eclass) and therefore bc is not needed to complete 
> that minimal set.
> 

(picking up the most relevant reply)

Here[1] is the original discussion regarding the removal of bc and ed from
the system set. I do prefer bc in system set too because I'm lazy to emerge the damn
thing but their reasons were valid at that time(2005), and they 're still valid right now(2014).

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/27216

-- 
Panagiotis Christopoulos ( pchrist )
    ( Gentoo Lisp Project )

[-- Attachment #2: Type: application/pgp-signature, Size: 274 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[Tom Wijsman]

On Sat, 27 Sep 2014 13:22:45 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 27 Sep 2014 12:47:14 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > Because I'd expect a stage3 to be posix compliant
> 
> I agree. It's time to replace nano with Vim.

Vim is not fully POSIX compliant; you may find it claim "mostly" in its
documentation, but that's where it stays at and thus doesn't suffice...

While we're at it, we must make everyone use a POSIX IDE with a ribbon!

Jokes aside, this sub discussion is pointless; if we want results, a
moderated mailing list as suggested in a reply won't cut it!

What is really needed here is a vote by the Council on whether to add bc
back to the stage3. If the people do insist, another vote regarding
adding or changing an editor to stage3 could be done as well.

Re: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Sat, Sep 27, 2014 at 5:52 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>
> What is really needed here is a vote by the Council on whether to add bc
> back to the stage3. If the people do insist, another vote regarding
> adding or changing an editor to stage3 could be done as well.
>

The call for agenda goes out on Tuesday, so if somebody wants a vote
please put it up.  Don't let mgorny be the only one with agenda items.
:)

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Anthony G. Basile]

On 09/27/14 18:46, Rich Freeman wrote:
> On Sat, Sep 27, 2014 at 5:52 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> What is really needed here is a vote by the Council on whether to add bc
>> back to the stage3. If the people do insist, another vote regarding
>> adding or changing an editor to stage3 could be done as well.
>>
> The call for agenda goes out on Tuesday, so if somebody wants a vote
> please put it up.  Don't let mgorny be the only one with agenda items.
> :)
>
> --
> Rich
>
He isn't ... remember GLEP 64 :)

And now for something completely different ... drum roll ... Really!  We 
have to have a council vote on whether bc goes into stage3?  If this 
does go to the council, then I want a pre-vote vote: should we bounce 
the decision back to the releng team?  We should not micro manage to 
this level.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Sat, Sep 27, 2014 at 7:39 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> And now for something completely different ... drum roll ... Really!  We
> have to have a council vote on whether bc goes into stage3?  If this does go
> to the council, then I want a pre-vote vote: should we bounce the decision
> back to the releng team?  We should not micro manage to this level.
>

I never said we have to have a council vote.  However, any dev can ask
for the Council to take up any agenda item.  The Council can always
choose to defer to another team.  As of this moment, nobody has asked
to put it on the agenda.  However, putting it on the agenda is better
than having a huge flamewar with no resolution.

I don't think the Council needs to vote on individual packages being
in/out of @system and so on, but it does make sense for the Council to
decide the guidelines for what does go in.

There is a big debate here about whether @system should be a
collection of useful stuff, or a minimal set of core dependencies,
etc.  That seems like a topic worth discussing to me...

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 2769 bytes --]

On 09/27/2014 07:39 PM, Anthony G. Basile wrote:
> On 09/27/14 18:46, Rich Freeman wrote:
>> On Sat, Sep 27, 2014 at 5:52 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>> What is really needed here is a vote by the Council on whether to add bc
>>> back to the stage3. If the people do insist, another vote regarding
>>> adding or changing an editor to stage3 could be done as well.
>>>
>> The call for agenda goes out on Tuesday, so if somebody wants a vote
>> please put it up.  Don't let mgorny be the only one with agenda items.
>> :)
>>
>> -- 
>> Rich
>>
> He isn't ... remember GLEP 64 :)
> 
> And now for something completely different ... drum roll ... Really!  We
> have to have a council vote on whether bc goes into stage3?  If this
> does go to the council, then I want a pre-vote vote: should we bounce
> the decision back to the releng team?  We should not micro manage to
> this level.
> 

May I suggest an alternative? We could implement sys-virtual/posix and
make it depend on all packages that are not necessary for @system, but
are necessary for proper POSIX compliance. Then we can tell users who
need/want an environment containing all tools specified by POSIX, such
as those not using sys-kernel/*-sources, to `emerge virtual/posix`.

That said, the larger matter of standards conformance that needs to be
considered. Illumos' Garrett D'amore has been working on standards
conformance tests for libc:

https://bitbucket.org/gdamore/illumos-gate/src/8815a50c9cc3f6f213931e12f72c252504363a82/usr/src/test/libc-tests/?at=core

Garrett told me yesterday that the changes necessary to run them on
Linux should be very small and are likely restricted to a few dozen
lines in 1 file. I want to try running them to catch POSIX conformance
issues in our base system. That will likely come later this year, as I
recently became aware of a SUS conformance issue in ZFS' implementation
of mmap() where PROT_WRITE + MAP_PRIVATE on a readonly file fails.
Fixing that will take priority over reviewing the standards conformance
of libc (others can review libc before i do if they wish).

I imagine that the tests will catch issues in our present conformance
when they are run. Once we have the results, we will need to decide how
proactive we intend to be about fixing them. We will definitely want to
work with upstream libcs to get issues that tests identified fixed.
However, there would be the question of whether we wish to fix them
immediately or wait for the patches fixing them to be upstreamed. If the
matter of adding bc to the base system for POSIX conformance goes to the
Council, it might be worth thinking about how far we wish to go for
standards conformance when further issues are identified.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3

[Robin H. Johnson]

On Sun, Sep 28, 2014 at 12:31:16PM -0400, Richard Yao wrote:
> May I suggest an alternative? We could implement sys-virtual/posix and
> make it depend on all packages that are not necessary for @system, but
> are necessary for proper POSIX compliance. Then we can tell users who
> need/want an environment containing all tools specified by POSIX, such
> as those not using sys-kernel/*-sources, to `emerge virtual/posix`.
I like this idea, for a virtual/posix; would let us trim a lot of other
things from some environments.

In a similar vein, would releng be open to moving stage1/2/3 package
sets to virtual packages or package sets? Presently they are inside
catalyst, and I think this would clean things up a lot.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Fri, Oct 10, 2014 at 09:22:18PM +0000, Robin H. Johnson wrote:
> In a similar vein, would releng be open to moving stage1/2/3 package
> sets to virtual packages or package sets? Presently they are inside
> catalyst, and I think this would clean things up a lot.

They're already in the Portage tree (the profile's packages.build for
stage1, scripts/bootstrap.sh for stage2, and the profile's packages
for stage3) [1].

Cheers,
Trevor

[1]: http://git.tremily.us/?p=catalyst.git;a=blob;f=doc/HOWTO.txt;h=cec22c35484d480fa127beb7be6bbdd9e942dc39;hb=HEAD#l139

     Linking to my public repo, because the gitweb service on
     git.overlays.gentoo.org is still broken.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King <wking@tremily.us> wrote:
> On Fri, Oct 10, 2014 at 09:22:18PM +0000, Robin H. Johnson wrote:
>> In a similar vein, would releng be open to moving stage1/2/3 package
>> sets to virtual packages or package sets? Presently they are inside
>> catalyst, and I think this would clean things up a lot.
>
> They're already in the Portage tree (the profile's packages.build for
> stage1, scripts/bootstrap.sh for stage2, and the profile's packages
> for stage3) [1].

Obviously this entails work on somebody's part, but would it still
make sense to make the stage build process more generic along the
lines Robin suggested?  That is, instead of having 3 specific places
we use to generate a stage1/2/3, we instead just define a stage as a
virtual of some kind that optionally depends on another stage (not
necessarily using the standard DEPEND mechanism) and then pulls in a
list of packages.  The root stage would not depend on another stage,
and therefore would be built from the host system.

The build system would just iteratively start at the bottom and output
a tarball or whatever as each level is completed, then use that as the
basis for bootstrapping the next.

Such a design would also eliminate the need to have the same list of
packages define the contents of @system and a stage3.  It could also
support any number of stages, with any names we wish.

My intent here isn't to get three cheers for making the releng team do
more work.  I'm actually more interested in feedback as to whether
there are any obvious flaws in an approach like this that I'm missing,
or whether something entirely different would be better.

I would also still have stage builds use a profile of some kind - that
could be useful from a standpoint of setting USE flags and so on.
However, if it made sense to build earlier stages with different flags
they could still be specified as USE dependencies (maybe due to
circular deps you have to build a package with different set of USE
flags before you can build the desired USE flags in a later stage).

--
Rich

Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On Fri, Oct 10, 2014 at 09:45:37PM -0400, Rich Freeman wrote:
> Obviously this entails work on somebody's part, but would it still
> make sense to make the stage build process more generic along the
> lines Robin suggested?  That is, instead of having 3 specific places
> we use to generate a stage1/2/3, we instead just define a stage as a
> virtual of some kind that optionally depends on another stage (not
> necessarily using the standard DEPEND mechanism) and then pulls in a
> list of packages.  The root stage would not depend on another stage,
> and therefore would be built from the host system.

Why bother with multiple layers and per-profile package lists if a
straight emerge is all you need?  My ideal long-term situation would
be to explicitly list all a package's dependencies (no implicit
@system dependencies).  Then have the stage1 just emerge a
self-hosting virtual/toolchain (which can have per-arch dependencies
if it needs them) from an arbitrary seed, and stage2 rebuild -e using
itself.  Everything after that could be user-generated @world stuff,
and you might want virtual/release with nano and whatever else you
want to put up under
releases/$ARCH/autobuilds/gentoo-$ARCH-$DATE.tar.bz.  That's less
magical, and Catalyst could be a bit simpler, but I don't have the
energy to move things there ;).  It's also pretty much what we have
now, except @system is floating around between virtual/toolchain (our
current stage1 packages) and virtual/release (our current stage3
packages).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3

[Jorge Manuel B. S. Vicetto]

On Fri, 10 Oct 2014, Rich Freeman wrote:

> On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King <wking@tremily.us> wrote:
>> On Fri, Oct 10, 2014 at 09:22:18PM +0000, Robin H. Johnson wrote:
>>> In a similar vein, would releng be open to moving stage1/2/3 package
>>> sets to virtual packages or package sets? Presently they are inside
>>> catalyst, and I think this would clean things up a lot.
>>
>> They're already in the Portage tree (the profile's packages.build for
>> stage1, scripts/bootstrap.sh for stage2, and the profile's packages
>> for stage3) [1].
>
> Obviously this entails work on somebody's part, but would it still
> make sense to make the stage build process more generic along the
> lines Robin suggested?  That is, instead of having 3 specific places
> we use to generate a stage1/2/3, we instead just define a stage as a
> virtual of some kind that optionally depends on another stage (not
> necessarily using the standard DEPEND mechanism) and then pulls in a
> list of packages.  The root stage would not depend on another stage,
> and therefore would be built from the host system.

All of the above suggestions would require changes to catalyst.
In any case, given the way we build a stage1 and bootstrap stage2, that 
isn't possible. For stage1 and stage2 the *order* we build packages is 
relevant. We rely on portage following that list in sequence.
Furthermore, because of the implicit dependencies and issues with circular 
dependencies, it would likely be impossible for portage to resolve the 
list of packages to build for stage1 and stage2 from a virtual.

> The build system would just iteratively start at the bottom and output
> a tarball or whatever as each level is completed, then use that as the
> basis for bootstrapping the next.

That's how catalyst already works.
To address one point in your last sentence in the above quote:

"The root stage would not depend on another stage, and therefore would be 
built from the host system."

You almost always don't want to build with the state of a live system, but 
of a clean seed - that's why releng tells catalyst to use a stage3 as the 
seed for the stage1.

> Such a design would also eliminate the need to have the same list of
> packages define the contents of @system and a stage3.  It could also
> support any number of stages, with any names we wish.

No, not really. You're "over-thinking" this. To be able to "split" the 
system set and the stages releng provides, all we need is to fix the bug 
that was already mentioned before and have releng provide stages built 
from a stage3 (while removing some packages from the system set) and a 
list of packages that we want to provide (the ones dropped from system and 
a select "few" others).

> I would also still have stage builds use a profile of some kind - that
> could be useful from a standpoint of setting USE flags and so on.
> However, if it made sense to build earlier stages with different flags
> they could still be specified as USE dependencies (maybe due to
> circular deps you have to build a package with different set of USE
> flags before you can build the desired USE flags in a later stage).

We build stages using a profile. One of the variables set on stage specs 
is "profile" to list the profile to be used in the stage.

> --
> Rich

Regards,
Jorge Manuel B. S. Vicetto
Gentoo Developer


PS - As I've warned before, I'm not following closely the dev ml. So you 
got this reply now, because I just happened to look at the emails in this 
ml. If you want me to comment further, your best option is to poke me 
about it.

Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

On Thu, Oct 16, 2014 at 12:13:45AM +0000, Jorge Manuel B. S. Vicetto wrote:
> For stage1 and stage2 the *order* we build packages is relevant.

Is this really true?  The stage1 is being built with ROOT, so it's
only using the seed stage3 packages.  It's hard to have cyclic
dependencies when you're using packages from one root (the seed
stage3) but installing into another (/tmp/stage1root).  Looking
through a stage1 log I see:

  emerge --quiet --oneshot --nodeps --update sys-apps/portage
  …
  emerge --quiet --update --deep --newuse --complete-graph --rebuild-if-new-ver gcc
  …
  emerge --quiet --usepkg --buildpkg --newuse --oneshot --nodeps sys-apps/baselayout
  …
  emerge --quiet --usepkg --buildpkg --newuse --oneshot sys-devel/gnuconfig sys-devel/bison …

The first two are just covering us against serious missmatches between
the package tree and the seed stage3 (and are installed with ROOT=/).
I expect we could handle shoving baselayout into the final emerge
along with the other packages.build stuff.

The logs for stage2 aren't as clear, but looking through the script I
only see:

* A Portage-updating emerge
* The main GCC, binutils, … emerge
* A possible 'emerge --prune sys-devel/gcc'

I'm not sure this is needed at all.  I'll try and find time to build a
stage3 directly from a stage1, and we'll see if it blows up ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[gentoo-dev] Re: virtual/{posix,stage1,2,3} Was: Add bc back to the stage3

[Steven J. Long]

On Fri, Oct 10, 2014 at 09:22:18PM +0000, Robin H. Johnson wrote:
> On Sun, Sep 28, 2014 at 12:31:16PM -0400, Richard Yao wrote:
> > May I suggest an alternative? We could implement sys-virtual/posix and
> > make it depend on all packages that are not necessary for @system, but
> > are necessary for proper POSIX compliance. Then we can tell users who
> > need/want an environment containing all tools specified by POSIX, such
> > as those not using sys-kernel/*-sources, to `emerge virtual/posix`.

kernel-sources doesn't get you that afaict: it just gets you bc. Certainly
doesn't get you ed, which is tiny and designed to be used in rootfs.

I just don't see the point in not providing a POSIX.2 system by default.
It feels like crippling the distro before it's out the door.

> I like this idea, for a virtual/posix; would let us trim a lot of other
> things from some environments.

Such as?

Not arguing with your use-case. Just wondering why ed and bc are considered
such major burdens, but polkit+systemd+udev+dbug+glib+glibc+godknows are a
minimal base.

I feel like I've gone through the looking-glass. (pam pulling in polkit?)

Anyhow, it seems to that in the minimal embedded env you're talking about,
the user can quite easily remove or package.provide things, and that
can be done in the profile as well as myriad other options for the expert
use-case; none of which speak to the default.

We used to have LDAP enabled by default, for the best part of a decade
to my recollection, just so that people could plug a disk into a Windows
environment, on the grounds that this made us look more "professional."
With respect, nothing looks more amateurish than a *nix that doesn't even
comply with POSIX.2.

It's not exactly hard, yet we don't manage it, but meantime let's add in
massively complex layers. It seems very masochistic sometimes, from an
external perspective. Loads of extra work, discussion and what often
reads like heartache, for want of a better word, in order to achieve what
you could have done really simply.

Still, moar code must be better, right?

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: virtual/{posix,stage1,2,3} Was: Add bc back to the stage3

[Rich Freeman]

On Sat, Oct 11, 2014 at 1:25 AM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
> Not arguing with your use-case. Just wondering why ed and bc are considered
> such major burdens, but polkit+systemd+udev+dbug+glib+glibc+godknows are a
> minimal base.

Nobody is talking about adding most of that stuff to the @system set.

The issue is that in general we're trying to reduce @system and list
explicit dependencies.  Honestly, my personal preference would be to
ditch it altogether as an implicit set of dependencies.

I'm all for having virtuals or profiles that make it easy for users to
install commonly-used sets of packages, including convenience ones
that reflect particular configurations.

The whole idea of dependencies, however, is that we don't have to have
endless debates about whether dbus is or isn't a great package to
install by default.  Instead, people just install the packages they
want, and they get the baggage that necessarily comes along with it.

So, this isn't about keeping ed/bc out while we have openssh of all
things in.  The concern is more about not adding more to something
that feels more like a hack at this point, and finding a better way of
letting users easily have sane defaults.  In the end, it is actually
about choice.  If done right it should actually make it easier for you
to have a system free of udev+glibc (I don't think the rest of what
you put there is part of the system set today).

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Tom Wijsman]

On Sat, 27 Sep 2014 19:39:44 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> And now for something completely different ... drum roll ... Really!
> We have to have a council vote on whether bc goes into stage3?  If
> this does go to the council, then I want a pre-vote vote: should we
> bounce the decision back to the releng team?  We should not micro
> manage to this level.

The Council gets involved when there is disagreement, which makes
this more serious than micro management; but sure, if they want to
revisit the case then that could work out as well. The releng team's
input on this case is important, even if it ends up going to Council.

Re: [gentoo-dev] Add bc back to the stage3

[Jorge Manuel B. S. Vicetto]

On Sat, 27 Sep 2014, Tom Wijsman wrote:

> On Sat, 27 Sep 2014 13:22:45 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
>> On Sat, 27 Sep 2014 12:47:14 +0200
>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>> Because I'd expect a stage3 to be posix compliant
>>
>> I agree. It's time to replace nano with Vim.
>
> Vim is not fully POSIX compliant; you may find it claim "mostly" in its
> documentation, but that's where it stays at and thus doesn't suffice...
>
> While we're at it, we must make everyone use a POSIX IDE with a ribbon!
>
> Jokes aside, this sub discussion is pointless; if we want results, a
> moderated mailing list as suggested in a reply won't cut it!

It seems like everyone needs to "chill" a bit. Ciaran wasn't trolling, he 
was making a point. I'm sure everyone around here understood his point.
There were no attacks and no "foul language", so can we move forward?

> What is really needed here is a vote by the Council on whether to add bc
> back to the stage3. If the people do insist, another vote regarding
> adding or changing an editor to stage3 could be done as well.

No, there isn't a need for a Council vote here. This is something up to 
Releng (in respect to what is in the stages) and to everyone in respect to 
what is part of the system set.
Further, to me, this is a case where if anyone tries to side-step Releng 
and go over it with a Council decision, than the council members should be 
ready to start doing Releng work.

I've stopped following this mailing list regularly quite sometime ago. To 
see this thread is still going on and no one bothered to cc releng, to me 
shows a lack of respect for the people actually doing releases around 
here, as well as a real lack of interest in getting this done as you can 
discuss this all you want, but in the end, it's releng that works on this.

Regards,

Jorge Manuel B. S. Vicetto
Gentoo Developer
(Releng Lead)

Re: [gentoo-dev] Add bc back to the stage3

[Peter Stuge]

Jorge Manuel B. S. Vicetto wrote:
> I've stopped following this mailing list regularly quite sometime ago.
> To see this thread is still going on and no one bothered to cc releng,
> to me shows a lack of respect

I expected you to participate on the developer list to some degree,
since you are developers.

Isn't that even mentioned in a quiz somewhere?


//Peter

Re: [gentoo-dev] Add bc back to the stage3

[Tom Wijsman]

On Mon, 29 Sep 2014 06:08:11 +0200
Peter Stuge <peter@stuge.se> wrote:

> Jorge Manuel B. S. Vicetto wrote:
> > I've stopped following this mailing list regularly quite sometime
> > ago. To see this thread is still going on and no one bothered to cc
> > releng, to me shows a lack of respect
> 
> I expected you to participate on the developer list to some degree,
> since you are developers.
> 
> Isn't that even mentioned in a quiz somewhere?

Only a small few MLs are mandatory; as for most others, a developer is
free to sub/unsub to/from a ML as they see fit. There was a mail[1] send
out by the Gentoo Council regarding awareness of gentoo-dev ML threads.

 [1]: http://article.gmane.org/gmane.linux.gentoo.project/3549 (see 2-3)

Re: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Mon, Sep 29, 2014 at 12:05 AM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
>
> No, there isn't a need for a Council vote here. This is something up to
> Releng (in respect to what is in the stages) and to everyone in respect to
> what is part of the system set.

I don't think many really care about deferring to releng on what is in
the stages.

My concern is what is in @system, since that has a big impact on everybody.

> I've stopped following this mailing list regularly quite sometime
> ago. To see this thread is still going on and no one bothered to cc
> releng, to me shows a lack of respect for the people actually doing
> releases around here, as well as a real lack of interest in getting
> this done as you can discuss this all you want, but in the end, it's
> releng that works on this.

Nobody is intending to show a lack of respect for anybody.  The whole
point of having a mailing list is so that you don't have to CC every
single developer on every single thread.

Nobody is required to read -dev, but as was pointed out recently,
claiming that you don't read -dev isn't really a good starting point
for a complaint that you've been left out of something.  [1]

> Further, to me, this is a case where if anyone tries to side-step Releng and
> go over it with a Council decision, than the council members should be ready
> to start doing Releng work.
>

So, do you have an opinion on this that you'd like to share?  I think
it makes more sense to discuss what the best path forward is rather
than argue about who gets to make the decision.

Believe it or not, the folks who are on the Council aren't really
interested in micro-managing everything that goes on in Gentoo.
However, as you pointed out, everybody is impacted by what is in the
system set, and the way "everybody" in Gentoo decides on things is
through the Council.  The alternative is endless threads like this
one.

No, the members of the Council aren't aware of every detail of
everything that happens with Gentoo, and they don't possess every
skill collectively possessed by every member of the community.  About
the only thing the Council can claim is that people voted for them to
represent the community, so it functions best when we actually act
like a community.

[1] - http://www.gentoo.org/proj/en/council/meeting-logs/20140408-summary.txt

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Anthony G. Basile]

On 09/29/14 07:14, Rich Freeman wrote:
> On Mon, Sep 29, 2014 at 12:05 AM, Jorge Manuel B. S. Vicetto
> <jmbsvicetto@gentoo.org> wrote:
>> No, there isn't a need for a Council vote here. This is something up to
>> Releng (in respect to what is in the stages) and to everyone in respect to
>> what is part of the system set.
> I don't think many really care about deferring to releng on what is in
> the stages.
>
> My concern is what is in @system, since that has a big impact on everybody.

The original point and reasoning was about getting bc back into stage3.  
The @system discussion came up secondarily because of the relationship 
between the two.  But note that, if the status quo remains (ie bc 
doesn't belong in stage3) then there would be no issue about @system.

>
>> I've stopped following this mailing list regularly quite sometime
>> ago. To see this thread is still going on and no one bothered to cc
>> releng, to me shows a lack of respect for the people actually doing
>> releases around here, as well as a real lack of interest in getting
>> this done as you can discuss this all you want, but in the end, it's
>> releng that works on this.
> Nobody is intending to show a lack of respect for anybody.  The whole
> point of having a mailing list is so that you don't have to CC every
> single developer on every single thread.
>
> Nobody is required to read -dev, but as was pointed out recently,
> claiming that you don't read -dev isn't really a good starting point
> for a complaint that you've been left out of something.  [1]
>
>> Further, to me, this is a case where if anyone tries to side-step Releng and
>> go over it with a Council decision, than the council members should be ready
>> to start doing Releng work.
>>
> So, do you have an opinion on this that you'd like to share?  I think
> it makes more sense to discuss what the best path forward is rather
> than argue about who gets to make the decision.
>
> Believe it or not, the folks who are on the Council aren't really
> interested in micro-managing everything that goes on in Gentoo.
> However, as you pointed out, everybody is impacted by what is in the
> system set, and the way "everybody" in Gentoo decides on things is
> through the Council.  The alternative is endless threads like this
> one.

What's in stage3 also impacts "everybody".  The point about 
micro-managing is a judgment call about how large the impact.  In my 
judgment, adding bc to stage3 or keeping the status quo is not a big 
enough issue that releng can't decide on their own.  While anything may 
come to the Council and be entertained by it (at the cost of time), it 
would be my position to motion that the issue be pushed back to releng 
for a decision.  At that point the Council will effectively be deciding 
whether or not they agree with me, namely, that this issue really 
doesn't impact everyone sufficiently to be taken out of releng's hands.  
It is important that the Council reflect the body's sensibilities about 
what is significant and what isn't.  If we start judging everything as 
having a "significant impact" and taking it from the respective teams, 
then we will be micro-managing despite our words to the contrary.  
Jorge's response "than the council members should be ready to start 
doing Releng work" would not be atypical if we start overstepping that 
line.  Although, I must say, Jorge's is being little premature here, and 
I doubt the Council will act rashly.

>
> No, the members of the Council aren't aware of every detail of
> everything that happens with Gentoo, and they don't possess every
> skill collectively possessed by every member of the community.  About
> the only thing the Council can claim is that people voted for them to
> represent the community, so it functions best when we actually act
> like a community.
>
> [1] - http://www.gentoo.org/proj/en/council/meeting-logs/20140408-summary.txt
>
> --
> Rich


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Mon, Sep 29, 2014 at 7:53 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Although, I must say, Jorge's is being little premature here, and I
> doubt the Council will act rashly.

So, while I was trying to be balanced in my reply, I'll admit it may
have still been a bit too emotionally motivated.

I think this was really the bit that I was reacting to.  In general I
do agree that it is best to let individual teams make the call before
escalating to council.

I just don't like attitudes along the lines of "I'll do what I think
is best, and if you don't like it you can do it instead."  It is true
that we're all volunteers, and we all need to be mindful of that.
However, if all Gentoo is to somebody is a place to host their
sole-committer git repo, you could probably do better.

I don't really think that was how Jorge felt, and I think we're all
just venting, and my response probably wasn't more helpful than what I
replied to, so apologies to all for the line noise.

For what its worth, this still isn't on the agenda (I'll probably send
out the call later today).  I also think that if anybody is feeling
really frustrated over the content of stage3/@system and so on,
they're probably best off directing that frustration towards getting
something like mix-ins supported.  :)  Gentoo is about choice, but we
can only offer the choices that our tools support.

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Jorge Manuel B. S. Vicetto]

On Mon, 29 Sep 2014, Rich Freeman wrote:

> On Mon, Sep 29, 2014 at 7:53 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> Although, I must say, Jorge's is being little premature here, and I
>> doubt the Council will act rashly.
>
> So, while I was trying to be balanced in my reply, I'll admit it may
> have still been a bit too emotionally motivated.
>
> I think this was really the bit that I was reacting to.  In general I
> do agree that it is best to let individual teams make the call before
> escalating to council.
>
> I just don't like attitudes along the lines of "I'll do what I think
> is best, and if you don't like it you can do it instead."  It is true
> that we're all volunteers, and we all need to be mindful of that.
> However, if all Gentoo is to somebody is a place to host their
> sole-committer git repo, you could probably do better.

In this case I reacted more "emotionally" that I should have.
Using your expression above, please consider it as "releng is doing what 
it thinks is best." As the team lead, I was also expressing that to see 
something as "ordinary" as deciding if bc should be in stage3 sent to the 
council to "decide", those pushing for that (and that critic wasn't 
directed to the council members but those pushing this to council), 
shouldn't be surprised if releng members get upset and decide to spend 
their time elsewhere.

> I don't really think that was how Jorge felt, and I think we're all
> just venting, and my response probably wasn't more helpful than what I
> replied to, so apologies to all for the line noise.

Yes, I was venting. I got a bit upset to see something as simple and 
ordinary still being discussed (I believe the last time I read about it 
had been 2 weeks before).
To me, this isn't the first time that someone decides to discuss in the 
dev ml about releng work, without even bothering to let releng know about 
it.
I know that our policies state that technical issues should be raised in 
the dev ml, although they also support doing the discussion in specialized 
mls, but they also mention that one should make an effort to contact those 
involved in the matter.

> For what its worth, this still isn't on the agenda (I'll probably send
> out the call later today).  I also think that if anybody is feeling
> really frustrated over the content of stage3/@system and so on,
> they're probably best off directing that frustration towards getting
> something like mix-ins supported.  :)  Gentoo is about choice, but we
> can only offer the choices that our tools support.
>
> --
> Rich

Regards,

Jorge Manuel B. S. Vicetto
Gentoo Developer

Re: [gentoo-dev] Add bc back to the stage3

[Rich Freeman]

On Wed, Oct 1, 2014 at 7:59 AM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
> I know that our policies state that technical issues should be raised in the
> dev ml, although they also support doing the discussion in specialized mls,
> but they also mention that one should make an effort to contact those
> involved in the matter.
>

++

I think people just assume everybody reads these threads.  That isn't
always the case, and we can all stand a reminder once in a while...

--
Rich

Re: [gentoo-dev] Add bc back to the stage3

[Peter Stuge]

Hey Jorge,

Jorge Manuel B. S. Vicetto wrote:
> I know that our policies state that technical issues should be raised in 
> the dev ml, although they also support doing the discussion in specialized 
> mls, but they also mention that one should make an effort to contact those 
> involved in the matter.

I completely agree that that is certainly the least someone can do.


Thanks

//Peter

Re: [gentoo-dev] Add bc back to the stage3

[Tom Wijsman]

On Mon, 29 Sep 2014 04:05:19 +0000 (UTC)
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:

> On Sat, 27 Sep 2014, Tom Wijsman wrote:
> 
> > On Sat, 27 Sep 2014 13:22:45 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> >
> >> On Sat, 27 Sep 2014 12:47:14 +0200
> >> Luca Barbato <lu_zero@gentoo.org> wrote:
> >>> Because I'd expect a stage3 to be posix compliant
> >>
> >> I agree. It's time to replace nano with Vim.
> >
> > Vim is not fully POSIX compliant; you may find it claim "mostly" in
> > its documentation, but that's where it stays at and thus doesn't
> > suffice...
> >
> > While we're at it, we must make everyone use a POSIX IDE with a
> > ribbon!
> >
> > Jokes aside, this sub discussion is pointless; if we want results, a
> > moderated mailing list as suggested in a reply won't cut it!
> 
> It seems like everyone needs to "chill" a bit. Ciaran wasn't
> trolling, he was making a point. I'm sure everyone around here
> understood his point. There were no attacks and no "foul language",
> so can we move forward?

Constructiveness does not rely on just making points, as replacing nano
with Vim is out of the context of adding bc back to stage3. Editors are
a world apart from a build tool, even more so from being POSIX. In
order to move forward beyond this point, that needs to be recognized.

Does that make him attacking / foulish / trollish / unchilling? No;
actually, it is helpful / smart / fluffy / chilling towards consensus
as both the opposite and sarcastic interpretations help form that.

> > What is really needed here is a vote by the Council on whether to
> > add bc back to the stage3. If the people do insist, another vote
> > regarding adding or changing an editor to stage3 could be done as
> > well.
> 
> No, there isn't a need for a Council vote here.

Not in the way of having the Council actually vote, but by waking up
everyone from these endless side points sub discussions by escalation.

> This is something up
> to Releng (in respect to what is in the stages) and to everyone in
> respect to what is part of the system set.
> Further, to me, this is a case where if anyone tries to side-step
> Releng and go over it with a Council decision, than the council
> members should be ready to start doing Releng work.
> 
> I've stopped following this mailing list regularly quite sometime
> ago. To see this thread is still going on and no one bothered to cc
> releng, to me shows a lack of respect for the people actually doing
> releases around here, as well as a real lack of interest in getting
> this done as you can discuss this all you want, but in the end, it's
> releng that works on this.

If people desire a change, it'll be discussed for an eternity; until ...

Re: [gentoo-dev] Add bc back to the stage3

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

On Mon, 29 Sep 2014 23:37:20 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:
> On Mon, 29 Sep 2014 04:05:19 +0000 (UTC)
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> > On Sat, 27 Sep 2014, Tom Wijsman wrote:
> > > On Sat, 27 Sep 2014 13:22:45 +0100
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > >> On Sat, 27 Sep 2014 12:47:14 +0200
> > >> Luca Barbato <lu_zero@gentoo.org> wrote:
> > >>> Because I'd expect a stage3 to be posix compliant
> > >>
> > >> I agree. It's time to replace nano with Vim.
> >
> > It seems like everyone needs to "chill" a bit. Ciaran wasn't
> > trolling, he was making a point. I'm sure everyone around here
> > understood his point. There were no attacks and no "foul language",
> > so can we move forward?
> 
> Constructiveness does not rely on just making points, as replacing
> nano with Vim is out of the context of adding bc back to stage3.
> Editors are a world apart from a build tool, even more so from being
> POSIX. In order to move forward beyond this point, that needs to be
> recognized.

But POSIX does describe vi. That was the point...

(And until fairly recently, texlive used to require 'ex' if you wanted
to build it fully from unpatched sources.)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Add bc back to the stage3

[Tom Wijsman]

On Tue, 30 Sep 2014 18:58:18 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Mon, 29 Sep 2014 23:37:20 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> > On Mon, 29 Sep 2014 04:05:19 +0000 (UTC)
> > "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> > > On Sat, 27 Sep 2014, Tom Wijsman wrote:
> > > > On Sat, 27 Sep 2014 13:22:45 +0100
> > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > >> On Sat, 27 Sep 2014 12:47:14 +0200
> > > >> Luca Barbato <lu_zero@gentoo.org> wrote:
> > > >>> Because I'd expect a stage3 to be posix compliant
> > > >>
> > > >> I agree. It's time to replace nano with Vim.
> > >
> > > It seems like everyone needs to "chill" a bit. Ciaran wasn't
> > > trolling, he was making a point. I'm sure everyone around here
> > > understood his point. There were no attacks and no "foul
> > > language", so can we move forward?
> > 
> > Constructiveness does not rely on just making points, as replacing
> > nano with Vim is out of the context of adding bc back to stage3.
> > Editors are a world apart from a build tool, even more so from being
> > POSIX. In order to move forward beyond this point, that needs to be
> > recognized.

Ah, quotes are getting cut out, lovely; it focuses on what is crucial.

[gentoo-dev] Re: Add bc back to the stage3

[Steven J. Long]

On Mon, Sep 29, 2014 at 04:05:19AM +0000, Jorge Manuel B. S. Vicetto wrote:
> It seems like everyone needs to "chill" a bit.

++

> On Sat, 27 Sep 2014, Tom Wijsman wrote:
> > What is really needed here is a vote by the Council on whether to add bc
> > back to the stage3. If the people do insist, another vote regarding
> > adding or changing an editor to stage3 could be done as well.
> 
> No, there isn't a need for a Council vote here. This is something up to 
> Releng (in respect to what is in the stages) and to everyone in respect to 
> what is part of the system set.

Yeah, my bad, for my part I was really thinking of @system, though ed outside
chroot would make install-scripting easier. (I have a penchant for running
off the minimal install iso; yes I know the alternatives, thx.)

Cheers for your continued hard-work; from where I'm sitting releng works
well, though could perhaps use one or two dedicated helpers.

Regards,
igli
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Add bc back to the stage3

[Steven J. Long]

On Sat, Sep 27, 2014, Luca Barbato wrote:
> On 17/09/14 14:09, Jorge Manuel B. S. Vicetto wrote:
> > On Wed, 17 Sep 2014, Luca Barbato wrote:
> >
> >> The bc utility is part of the posix tools and it might be used to build
> >> linux among the other stuff.
> >
> > Luca,
> >
> > bc is not in the system set and is a dependency of the kernel or any
> > other package that needs it, so why do we need to include a package that
> > takes ~20 seconds to build?
> 
> Because I'd expect a stage3 to be posix compliant and it is a pain to 
> remember that Gentoo doesn't have it by default (since the errors can be 
> quite vague).
> 

I agree; ed should be supplied too for the same reason (and not be
considered as a provider for the virtual.) It's a pita not being able to
rely on a POSIX.2 base.

Similarly with vi/ex too (again, not providing the virtual); though vim
should likely be another package, unless it's much easier just to bundle
it. AFAIR you get into all the gvim/X questions then, but I can't say as
I use it, so defer to whomever. ex is useful for scripters, though we
use ed more, since it avoids the vi question and we've had reports of
ex not being as reliable as ed, on other platforms.

busybox ed should never be built afaic. GNU ed has tight linkage for
rootfs usage (like sed and awk, which should be in /bin), and actually
works:
$ ldd $(type -p ed)
  linux-vdso.so.1
  libc.so.6 => /lib64/libc.so.6
  /lib64/ld-linux-x86-64.so.2

Regards,
steveL
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)