[gentoo-project] Call for agenda items - Council meeting 2013-08-13

[gentoo-project] Call for agenda items - Council meeting 2013-08-13

[Ulrich Mueller]

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

In less than two weeks from now, the council will meet again.
This is the time to raise and prepare items that the council should
put on the agenda to discuss or vote on.

Please respond to this message with agenda items. Do not hesitate
to repeat your agenda item here with a pointer if you previously
suggested one (since the last meeting).

The agenda for the next meeting will be sent out on Tuesday
2013-08-06.

Please respond to the gentoo-project list, if possible.

Ulrich

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-08-13

[William Hubbs]

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

Council members,

As we all know, the way most linux distros support having /usr on a
separate file system from / is via an initramfs. One of these can be
built easily in gentoo with dracut, genkernel, or you can build one
manually [1].

In april 2012, the council voted that "separate /usr is a supported
configuration". According to a number of people at the time and since
then, the intent was to mandate that maintainers must support separate /usr
configurations without an initramfs.

This is the reason for the "sep-usr" use flag in busybox. This use flag
is a Gentoo-specific option that drops the busybox static binary in / with a
different name (ginit). Then you add init=/ginit on your kernel command
line with your boot loader configuration to run this binary which just
mounts / and /usr and starts the real init.

The council never really took a position on how separate /usr is
supported, so there are people who use separate /usr with neither of
these options and still expect this configuration to work.

There are significant advantages if we do not require maintainers to
support the use of separate /usr configurations without an early boot
mechanism like an initramfs or the sep-usr use flag on busybox.

First, we will not have to worry any more about making sure all of the
libraries needed by binaries in /{bin,sbin} are in /lib*. Also, we will
not have to be concerned about programs on / trying to read data from
/usr/share in early boot.

Also, the support for separate /usr setups without any kind of early
boot mechanism is going to become more complex over time due to the
evolution of modern software. Our QA lead has some blog posts on the
separate /usr issue and the boot process which discuss these issues in
more detail [2] [3]. Another thing to consider is FHS 3 [4]. The division
between / and /usr is becoming blurred because any combination of
actual directories and symlinks are allowed in /.

Because of this information, I propose that we vote not to
require maintainers to support separate /usr configurations without an
initramfs or some other early boot mechanism.

William

[1] http://www.gentoo.org/doc/en/initramfs-guide.xml
[2] https://blog.flameeyes.eu/2012/12/my-take-on-the-separate-usr-issue
[3] https://blog.flameeyes.eu/2013/01/the-boot-process
[4] http://www.linuxbase.org/betaspecs/fhs/fhs.html

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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-08-13

[Alexis Ballier]

On Wed, 31 Jul 2013 19:36:14 -0500
William Hubbs <williamh@gentoo.org> wrote:
[...]
> First, we will not have to worry any more about making sure all of the
> libraries needed by binaries in /{bin,sbin} are in /lib*. Also, we
> will not have to be concerned about programs on / trying to read data
> from /usr/share in early boot.

Why are those programs in / in the first place ? If they can't work
without /usr they are sort of useless in /.

[...]
> Because of this information, I propose that we vote not to
> require maintainers to support separate /usr configurations without an
> initramfs or some other early boot mechanism.

'not to require' leaves it up to the maintainers e.g. if they want to
call gen_usr_ldscript or install into /, right ? Or does that imply they
should not do it ?

The current requirement imposes some consistency, and lifting it would
leave us with some bastardized system where some random files are in /
and others in /usr.

I have no opinion whether separate usr should be supported or not: I
have not been using this layout since years. However, I strongly prefer
some kind of consistency: The traditional layout with a minimal / to
boot or the usr move both have their advantages; if we go for something
in between we get none of them.

I think most of what is in / currently is maintained by base-system@.
base-system@, or the council, could decide to provide a way to drop the
self-contained / properly. Say, you have to define a variable in
make.conf, let's call it GENTOO_USR_MOVE, and this variable would no-op
gen_usr_ldscript (they waste space if /usr is required anyway) and then
some packages could decide to install to /usr instead of / if this
variable is set, etc. Once this is ready, you can define this variable
in the profiles and get all the profit advertised by Fedora usr move.

Alexis.

Re: [gentoo-project] Call for agenda items - Council meeting 2013-08-13

[William Hubbs]

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

On Thu, Aug 01, 2013 at 04:04:34PM -0400, Alexis Ballier wrote:
> On Wed, 31 Jul 2013 19:36:14 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> [...]
> > First, we will not have to worry any more about making sure all of the
> > libraries needed by binaries in /{bin,sbin} are in /lib*. Also, we
> > will not have to be concerned about programs on / trying to read data
> > from /usr/share in early boot.
 
 First off, this is all related to Linux only, so keep that in mind when
 I answer below.

> Why are those programs in / in the first place ? If they can't work
> without /usr they are sort of useless in /.

Not really. if you use an initramfs or some early boot mechanism like
that to make sure / and /usr are mounted at the same time, that
separation is irrelivant.

> > Because of this information, I propose that we vote not to
> > require maintainers to support separate /usr configurations without an
> > initramfs or some other early boot mechanism.
> 
> 'not to require' leaves it up to the maintainers e.g. if they want to
> call gen_usr_ldscript or install into /, right ? Or does that imply they
> should not do it ?
 
 I'll talk about gen_usr_ldscript below.

> The current requirement imposes some consistency, and lifting it would
> leave us with some bastardized system where some random files are in /
> and others in /usr.
 
As I said in my original proposal, there is or is not a
 requirement depending on who you talk to and where you read. The
 summary of the meeting doesn't say anything about such a requirement,
 even though the log does, so it is not a clear situation right now.

> I have no opinion whether separate usr should be supported or not: I
> have not been using this layout since years. However, I strongly prefer
> some kind of consistency: The traditional layout with a minimal / to
> boot or the usr move both have their advantages; if we go for something
> in between we get none of them.

What we currently have is in between. To really make separate /usr work
would require a /share top level directory, patching gettext at least to
look in both /usr/share/locale and /share/locale, and who knows what else.

I'm not advocating the /usr merge at this time, maybe later, but right
now I just want to make it official that we do not support separate /usr
without an early boot mechanism like an initramfs or the sep-usr flag on
busybox under Linux.

> 
> I think most of what is in / currently is maintained by base-system@.
> base-system@, or the council, could decide to provide a way to drop the
> self-contained / properly. Say, you have to define a variable in
> make.conf, let's call it GENTOO_USR_MOVE, and this variable would no-op
> gen_usr_ldscript (they waste space if /usr is required anyway) and then
> some packages could decide to install to /usr instead of / if this
> variable is set, etc. Once this is ready, you can define this variable
> in the profiles and get all the profit advertised by Fedora usr move.

(putting my base-system hat on)

I'm not sure why we would need a profile variable like you are
suggesting.

The reason gen_usr_ldscript came into being is that we were already
moving shared libraries from /usr/lib* to /lib* and we hit bug 4411, where the
linker was choosing a static library in /usr/lib over a dynamic library
in /lib. Besides moving the shared library from /usr/lib* to /lib*, it
writes a linker script in /usr/lib* to redirect the linker to look for
the shared library in /lib*. So, I think it has to be disabled
completely on Linux before the /usr move can be considered. It is smart
enough to be able to tell when it is on linux (by checking the CHOST
value like it already does for some things), so at some point I want to
talk to the rest of base-system and toolchain to figure out a sane
procedure for turning it off on linux. Again that has to be done after
this vote.

William


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

Re: [gentoo-project] Call for agenda items - Council meeting 2013-08-13

[Alexis Ballier]

On Thu, 1 Aug 2013 16:07:12 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Thu, Aug 01, 2013 at 04:04:34PM -0400, Alexis Ballier wrote:
> > On Wed, 31 Jul 2013 19:36:14 -0500
> > William Hubbs <williamh@gentoo.org> wrote:
> > [...]
> > > First, we will not have to worry any more about making sure all
> > > of the libraries needed by binaries in /{bin,sbin} are in /lib*.
> > > Also, we will not have to be concerned about programs on / trying
> > > to read data from /usr/share in early boot.
>  
>  First off, this is all related to Linux only, so keep that in mind
> when I answer below.
> 
> > Why are those programs in / in the first place ? If they can't work
> > without /usr they are sort of useless in /.
> 
> Not really. if you use an initramfs or some early boot mechanism like
> that to make sure / and /usr are mounted at the same time, that
> separation is irrelivant.

Exactly :) so for the sake of consistency these should be in /usr and
not be lying to be some core enough program that doesn't need /usr.

[...]
> > I have no opinion whether separate usr should be supported or not: I
> > have not been using this layout since years. However, I strongly
> > prefer some kind of consistency: The traditional layout with a
> > minimal / to boot or the usr move both have their advantages; if we
> > go for something in between we get none of them.
> 
> What we currently have is in between. To really make separate /usr
> work would require a /share top level directory, patching gettext at
> least to look in both /usr/share/locale and /share/locale, and who
> knows what else.

I haven't tried but I seriously hope gettext can provide non localized
strings if it cannot access the localized ones. This is the very
least I would expect from a system without /usr.

> I'm not advocating the /usr merge at this time, maybe later, but right
> now I just want to make it official that we do not support
> separate /usr without an early boot mechanism like an initramfs or
> the sep-usr flag on busybox under Linux.

An announcement to the users and a council decision telling the
developer community to try to support separate usr or not are different
things. I'm all for the former, and it has already been done I think,
but your request sounded more like the latter.

> > I think most of what is in / currently is maintained by
> > base-system@. base-system@, or the council, could decide to provide
> > a way to drop the self-contained / properly. Say, you have to
> > define a variable in make.conf, let's call it GENTOO_USR_MOVE, and
> > this variable would no-op gen_usr_ldscript (they waste space
> > if /usr is required anyway) and then some packages could decide to
> > install to /usr instead of / if this variable is set, etc. Once
> > this is ready, you can define this variable in the profiles and get
> > all the profit advertised by Fedora usr move.
> 
> (putting my base-system hat on)
> 
> I'm not sure why we would need a profile variable like you are
> suggesting.

The idea is to do things incrementally and opt-in. If all of a sudden
someone starts disabling gen_usr_ldscript and moving things to /usr,
I would bet there will be someone else yelling at him. If, on the other
hand, usr-moved systems have been in place for some time, are easy to
transition to, and nobody cares about maintaining a /usr barrier, I
would expect much less people to be against it being the default.
The variable also has the advantage that it makes it possible to
reverse course easily.

The end result will very likely be the same but one is perceived as
dictatorship and the other as democracy and freedom of choice :)

Alexis.

Build log locales (was: [gentoo-project] Call for agenda items - Council meeting 2013-08-13)

[Andreas K. Huettel]

Sorry this comes out so late (I'm travelling at the moment), but... I'd like 
to suggest the question of build log locales for discussion and decision. 

Basically:
1) do we want to require english build logs in bugzilla (ie. non-english logs 
make a bug invalid)?
2) do we want to make the build logs english by default (i.e. even if a locale 
is set globally, the user would have to install a second override in e.g. 
make.conf to obtain localized build logs)?
3) if yes to 2), which locale?

As for my personal opinion, 
1) yes
2) yes
3) don't care as long as it is english, and I consider any build system that 
fails depending on locale as br0ken and in need of fixing.

Cheers, A

Am Mittwoch, 31. Juli 2013, 11:41:54 schrieb Ulrich Mueller:
> In less than two weeks from now, the council will meet again.
> This is the time to raise and prepare items that the council should
> put on the agenda to discuss or vote on.
> 
> Please respond to this message with agenda items. Do not hesitate
> to repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).
> 
> The agenda for the next meeting will be sent out on Tuesday
> 2013-08-06.
> 
> Please respond to the gentoo-project list, if possible.
> 
> Ulrich


-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[gentoo-project] Re: Build log locales

[Michael Weber]

On 08/06/2013 04:13 PM, Andreas K. Huettel wrote:
> Basically:
> 1) do we want to require english build logs in bugzilla 
yes
> (ie. non-english logs make a bug invalid)?
don't be harsh.

> 2) do we want to make the build logs english by default (i.e. even if a locale 
> is set globally, the user would have to install a second override in e.g. 
> make.conf to obtain localized build logs)?
yes

> 3) if yes to 2), which locale?
LC_ALL=en_US.UTF-8 ?!

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: Build log locales (was: [gentoo-project] Call for agenda items - Council meeting 2013-08-13)

[Michał Górny]

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

Dnia 2013-08-06, o godz. 16:13:03
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> Basically:
> 1) do we want to require english build logs in bugzilla (ie. non-english logs 
> make a bug invalid)?

We prefer english build logs. I won't myself reject bug outright just
because of non-english messages.

> 2) do we want to make the build logs english by default (i.e. even if a locale 
> is set globally, the user would have to install a second override in e.g. 
> make.conf to obtain localized build logs)?

Yes.

> 3) if yes to 2), which locale?

C.utf8

> 3) don't care as long as it is english, and I consider any build system that 
> fails depending on locale as br0ken and in need of fixing.

So far the major problem was that we can't assume any specific locale
being available. If we use invalid locale string, it's not software
being broken but the environment.

-- 
Best regards,
Michał Górny

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

[gentoo-project] Re: Build log locales

[Ulrich Mueller]

>>>>> On Tue, 6 Aug 2013, Andreas K Huettel wrote:

> 1) do we want to require english build logs in bugzilla (ie.
> non-english logs make a bug invalid)?

I would leave this at the maintainer's discretion. IMHO it could at
most be a guideline that logs should be in English, but e.g. bug
wranglers shouldn't close a bug as invalid if the log is in another
language.

> 2) do we want to make the build logs english by default (i.e. even
> if a locale is set globally, the user would have to install a second
> override in e.g. make.conf to obtain localized build logs)?

See above.

> 3) if yes to 2), which locale?

POSIX (or C) is the only choice that is guaranteed to exist
everywhere.

> [...] I consider any build system that fails depending on locale as
> br0ken and in need of fixing.

+1

> Am Mittwoch, 31. Juli 2013, 11:41:54 schrieb Ulrich Mueller:

What about the locale used to send e-mail to our lists? :p

Ulrich

Re: [gentoo-project] Re: Build log locales

[Mike Gilbert]

On Tue, Aug 6, 2013 at 12:07 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 6 Aug 2013, Andreas K Huettel wrote:
>> [...] I consider any build system that fails depending on locale as
>> br0ken and in need of fixing.
>
> +1
>

You are welcome to waste your time fixing python setup.py files and
unit tests that are broken unless you have a UTF-8 locale set. I think
there are better uses of our time.

Re: [gentoo-project] Re: Build log locales

[Rich Freeman]

On Tue, Aug 6, 2013 at 2:35 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Tue, Aug 6, 2013 at 12:07 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>>> On Tue, 6 Aug 2013, Andreas K Huettel wrote:
>>> [...] I consider any build system that fails depending on locale as
>>> br0ken and in need of fixing.
>>
>> +1
>>
>
> You are welcome to waste your time fixing python setup.py files and
> unit tests that are broken unless you have a UTF-8 locale set. I think
> there are better uses of our time.
>

I think we're drifting topic-wise.  The main concern is about bug
reports written in languages other than english that may be difficult
for most developers to read, and not so much about build-system
compatibility with locale settings.  Sure, they should support
everything, but it isn't a critical bug if they don't.

My personal feeling on this is that maintainers should not be required
to accept bugs that contain logs generally written in something other
than English.  They may still accept them at their own discretion.

I'm also fine with default portage configurations that support logs in
English by default even when the system locale is not set this way, as
long as users have a way to override the setting.

Rich

Re: [gentoo-project] Re: Build log locales

[Ulrich Mueller]

>>>>> On Tue, 6 Aug 2013, Mike Gilbert wrote:

> On Tue, Aug 6, 2013 at 12:07 PM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
>>>>>>> On Tue, 6 Aug 2013, Andreas K Huettel wrote:
>>> [...] I consider any build system that fails depending on locale
>>> as br0ken and in need of fixing.
>> 
>> +1

> You are welcome to waste your time fixing python setup.py files and
> unit tests that are broken unless you have a UTF-8 locale set. I
> think there are better uses of our time.

I'm aware of the Python situation. It is a sad state of affairs,
though.

Ulrich

Re: [gentoo-project] Re: Build log locales

[Michał Górny]

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

Dnia 2013-08-06, o godz. 14:35:21
Mike Gilbert <floppym@gentoo.org> napisał(a):

> On Tue, Aug 6, 2013 at 12:07 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>>> On Tue, 6 Aug 2013, Andreas K Huettel wrote:
> >> [...] I consider any build system that fails depending on locale as
> >> br0ken and in need of fixing.
> >
> > +1
> >
> 
> You are welcome to waste your time fixing python setup.py files and
> unit tests that are broken unless you have a UTF-8 locale set. I think
> there are better uses of our time.

But wasn't this solved by deciding to set LC_MESSAGES only?

-- 
Best regards,
Michał Górny

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

Re: Build log locales (was: [gentoo-project] Call for agenda items - Council meeting 2013-08-13)

[Alexis Ballier]

On Tue, 6 Aug 2013 17:52:38 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > 3) if yes to 2), which locale?
> 
> C.utf8

A bit OT, but is it standardized these days ? Is it available by
default?


Alexis.

Re: [gentoo-project] Re: Build log locales

[Mike Gilbert]

On Tue, Aug 6, 2013 at 3:31 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-08-06, o godz. 14:35:21
> Mike Gilbert <floppym@gentoo.org> napisał(a):
>
>> On Tue, Aug 6, 2013 at 12:07 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> >>>>>> On Tue, 6 Aug 2013, Andreas K Huettel wrote:
>> >> [...] I consider any build system that fails depending on locale as
>> >> br0ken and in need of fixing.
>> >
>> > +1
>> >
>>
>> You are welcome to waste your time fixing python setup.py files and
>> unit tests that are broken unless you have a UTF-8 locale set. I think
>> there are better uses of our time.
>
> But wasn't this solved by deciding to set LC_MESSAGES only?
>

Yes, LC_MESSAGES is fine.

Re: Build log locales (was: [gentoo-project] Call for agenda items - Council meeting 2013-08-13)

[Mike Gilbert]

On Tue, Aug 6, 2013 at 3:34 PM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Tue, 6 Aug 2013 17:52:38 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>> > 3) if yes to 2), which locale?
>>
>> C.utf8
>
> A bit OT, but is it standardized these days ? Is it available by
> default?
>

I think debian is still creating this locale themselves.

http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/localedata/locale-C.diff?view=log

[gentoo-project] Council meeting: Tuesday 2013-08-13, 19:00 UTC

[Ulrich Mueller]

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

The next council meeting will be on Tuesday 2013-08-13, 19:00 UTC [1]
in the #gentoo-council channel on Freenode.


Proposed agenda:

1. Introduction and roll call (5 minutes)

2. Support for separate /usr partition - williamh (25 minutes) [2]

3. Locale for build logs in bugzilla  - dilfridge (15 minutes) [3]

4. Open bugs with council involvement (5 minutes)
   - Bug 477030 - Missing summary for 20130611 council meeting [4]

5. Open floor (10 minutes)


[1] http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00
[2] Message-ID: <20130801003614.GA29807@linux1> (not in archives)
[3] http://article.gmane.org/gmane.linux.gentoo.project/2926
[4] https://bugs.gentoo.org/show_bug.cgi?id=477030

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

Re: Build log locales (was: [gentoo-project] Call for agenda items - Council meeting 2013-08-13)

[Andreas K. Huettel]

> >> > 3) if yes to 2), which locale?
> >> 
> >> C.utf8
> > 
> > A bit OT, but is it standardized these days ? Is it available by
> > default?
> 
> I think debian is still creating this locale themselves.
> 
> http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patch
> es/localedata/locale-C.diff?view=log

Well that's a problem then. 

If we want to enable an english locale by default, we also have to make sure 
it is present by default. Would it be acceptable to force generation of 
en_US.UTF8 ?

[Please don't go into a bikeshed now about currencies, decimal delimiter etc. 
This is for build logs. Nothing else. en_US.UTF8 seems like a reasonable 
compromise.]

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[gentoo-project] Re: Build log locales

[Ulrich Mueller]

>>>>> On Wed, 7 Aug 2013, Andreas K Huettel wrote:

> Well that's a problem then.

> If we want to enable an english locale by default, we also have to
> make sure it is present by default. Would it be acceptable to force
> generation of en_US.UTF8 ?

Why? What is wrong with LC_MESSAGES=C?

Ulrich

Re: [gentoo-project] Re: Build log locales

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 568 bytes --]

Am Mittwoch, 7. August 2013, 12:08:26 schrieb Ulrich Mueller:
> >>>>> On Wed, 7 Aug 2013, Andreas K Huettel wrote:
> > Well that's a problem then.
> > 
> > If we want to enable an english locale by default, we also have to
> > make sure it is present by default. Would it be acceptable to force
> > generation of en_US.UTF8 ?
> 
> Why? What is wrong with LC_MESSAGES=C?
> 

If the Python guys are happy with that, then I'm happy with it too.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]