Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

[Michael Orlitzky]

On 02/01/2017 04:03 PM, Michał Górny wrote:
>>  SLOT="0"
>> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr"
>> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux
>> xattr"
> 
> Wouldn't it be better to enable it by default?
> 

Please don't enshrine personal preferences into IUSE defaults unless
they're critical to the package.

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[William Hubbs]

On Wed, Feb 01, 2017 at 12:25:37PM -0500, james wrote:
> On 02/01/2017 10:40 AM, William Hubbs wrote:
> > On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote:
> >> On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote:
> >>> As I said on the bug, the downside is the addition of py3 and ninja as
> >>> build time dependencies, but I think the upside (a build system where
> >>> we don't have to worry about parallel make issues or portability)
> >>> outweighs that.
> >> Could you please link or otherwise explain the portability issue?
> >
> > I'm not talking about a specific instance, just the flexability you get
> > with a build system. You let it handle the details of building
> > executables, linking libraries, etc.
> >
> > I have heard from more than one person that the OpenRC makefiles are
> > not written well, and I agree, so I've been looking for a build system
> > for a while.
> >
> > I thought about autotools. I'm not really fond of its syntax, and I've
> > been told that, to use autotools correctly, I would need to start
> > generating manual release tarballs again because I would need to put the
> > autotools generated cruft in them.
> >
> > I'm open to suggestions. I picked meson to experiment with because it
> > has a very nice clean syntax.
> >
> > William
> >
> 
> 'TUP' is the fastest build system of the all? I believe many build
> systems leverage or imitate what TUP does. I've read that for hand 
> crafting a specific build system, TUP is the most fundamental of the
> building blocks. Here are a few links, there are many for your perusal::
> 
> 
> http://gittup.org/tup/make_vs_tup.html
> 
> https://news.ycombinator.com/item?id=12622097
> 
> 
> I think TUP would really shine in a build system for embedded and 
> otherwise constrained build environments (limited resources) but
> I have not vetted that theory out, as I usually lean on others
> with greater depth of understanding in such matters. Still, from what I 
> read, TUP warrants monitoring as new code contributions keep moving this
> blazingly fast build system tool forward.

I took a brief look at this earlier. It appears to be a make
replacement. In otherwords, it would be a back end that cmake or meson
could leverage by writing tupfiles.

cmake or meson are replacements for autotools
(autoconf/automake/libtool). All of these (autotools, cmake, meson, etc)
generate makefiles that are run by another tool to actually do the
build.

William



signature.asc
Description: Digital signature

Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

[Zac Medico]

On 02/01/2017 01:03 PM, Michał Górny wrote:
> W dniu 01.02.2017, śro o godzinie 09∶06 -0800, użytkownik Zac Medico
> napisał:
>> The native-extensions USE flag will enable building of the
>> libc bindings. This is not enabled by default because it does
>> not support cross compilation.
>>
>> X-Gentoo-bug: 571444
>> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444
>> ---
>>  sys-apps/portage/metadata.xml| 1 +
>>  sys-apps/portage/portage-.ebuild | 7 ++-
>>  2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/sys-apps/portage/metadata.xml b/sys-
>> apps/portage/metadata.xml
>> index e032ea5..882d3ba 100644
>> --- a/sys-apps/portage/metadata.xml
>> +++ b/sys-apps/portage/metadata.xml
>> @@ -12,6 +12,7 @@
>>
>>  Build html API documentation with
>> epydoc.
>>  Use inter-process communication between portage
>> and running ebuilds.
>> +Build native extensions. Cross-
>> compilation is not supported.
>>  Preserve extended attributes (filesystem-
>> stored metadata) when installing files. Usually only required for
>> hardened systems.
>>
>>  
>> diff --git a/sys-apps/portage/portage-.ebuild b/sys-
>> apps/portage/portage-.ebuild
>> index 6a6f515..981db26 100644
>> --- a/sys-apps/portage/portage-.ebuild
>> +++ b/sys-apps/portage/portage-.ebuild
>> @@ -19,7 +19,7 @@ HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Porta
>> ge"
>>  LICENSE="GPL-2"
>>  KEYWORDS=""
>>  SLOT="0"
>> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr"
>> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux
>> xattr"
> 
> Wouldn't it be better to enable it by default?

Yeah, that should be fine. We may get a few duplicates of bug 594744
reported, but that's no reason not to enable it by default.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

[Michał Górny]

W dniu 01.02.2017, śro o godzinie 09∶06 -0800, użytkownik Zac Medico
napisał:
> The native-extensions USE flag will enable building of the
> libc bindings. This is not enabled by default because it does
> not support cross compilation.
> 
> X-Gentoo-bug: 571444
> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444
> ---
>  sys-apps/portage/metadata.xml| 1 +
>  sys-apps/portage/portage-.ebuild | 7 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/sys-apps/portage/metadata.xml b/sys-
> apps/portage/metadata.xml
> index e032ea5..882d3ba 100644
> --- a/sys-apps/portage/metadata.xml
> +++ b/sys-apps/portage/metadata.xml
> @@ -12,6 +12,7 @@
>    
>  Build html API documentation with
> epydoc.
>  Use inter-process communication between portage
> and running ebuilds.
> +Build native extensions. Cross-
> compilation is not supported.
>  Preserve extended attributes (filesystem-
> stored metadata) when installing files. Usually only required for
> hardened systems.
>    
>  
> diff --git a/sys-apps/portage/portage-.ebuild b/sys-
> apps/portage/portage-.ebuild
> index 6a6f515..981db26 100644
> --- a/sys-apps/portage/portage-.ebuild
> +++ b/sys-apps/portage/portage-.ebuild
> @@ -19,7 +19,7 @@ HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Porta
> ge"
>  LICENSE="GPL-2"
>  KEYWORDS=""
>  SLOT="0"
> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr"
> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux
> xattr"

Wouldn't it be better to enable it by default?

>  
>  DEPEND="!build? ( $(python_gen_impl_dep 'ssl(+)') )
>   >=app-arch/tar-1.27
> @@ -85,6 +85,11 @@ pkg_setup() {
>  python_prepare_all() {
>   distutils-r1_python_prepare_all
>  
> + if use native-extensions; then
> + printf "[build_ext]\nportage-ext-modules=true" >> \
> + setup.cfg || die
> + fi
> +
>   if ! use ipc ; then
>   einfo "Disabling ipc..."
>   sed -e "s:_enable_ipc_daemon =
> True:_enable_ipc_daemon = False:" \

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

[Zac Medico]

On 02/01/2017 09:57 AM, Brian Dolbec wrote:
> On Wed,  1 Feb 2017 09:06:37 -0800
> Zac Medico  wrote:
> 
>> The native-extensions USE flag will enable building of the
>> libc bindings. This is not enabled by default because it does
>> not support cross compilation.
>>
>> X-Gentoo-bug: 571444
>> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444
>> ---
>>  sys-apps/portage/metadata.xml| 1 +
>>  sys-apps/portage/portage-.ebuild | 7 ++-
>>  2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/sys-apps/portage/metadata.xml
>> b/sys-apps/portage/metadata.xml index e032ea5..882d3ba 100644
>> --- a/sys-apps/portage/metadata.xml
>> +++ b/sys-apps/portage/metadata.xml
>> @@ -12,6 +12,7 @@
>>
>>  Build html API documentation with
>> epydoc. Use inter-process communication
>> between portage and running ebuilds.
>> +Build native extensions.
>> Cross-compilation is not supported. > name="xattr">Preserve extended attributes (filesystem-stored
>> metadata) when installing files. Usually only required for hardened
>> systems.   diff --git
>> a/sys-apps/portage/portage-.ebuild
>> b/sys-apps/portage/portage-.ebuild index 6a6f515..981db26 100644
>> --- a/sys-apps/portage/portage-.ebuild +++
>> b/sys-apps/portage/portage-.ebuild @@ -19,7 +19,7 @@
>> HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Portage;
>> LICENSE="GPL-2" KEYWORDS=""
>>  SLOT="0"
>> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr"
>> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux
>> xattr" 
>>  DEPEND="!build? ( $(python_gen_impl_dep 'ssl(+)') )
>>  >=app-arch/tar-1.27  
>> @@ -85,6 +85,11 @@ pkg_setup() {
>>  python_prepare_all() {
>>  distutils-r1_python_prepare_all
>>  
>> +if use native-extensions; then
>> +printf "[build_ext]\nportage-ext-modules=true" >> \
>> +setup.cfg || die
>> +fi
>> +
>>  if ! use ipc ; then
>>  einfo "Disabling ipc..."
>>  sed -e "s:_enable_ipc_daemon =
>> True:_enable_ipc_daemon = False:" \
> 
> looks good :)
> 

Thanks, pushed:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dbe0bd44461aff3097fde6c64147f1a61e30816d
-- 
Thanks,
Zac

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[William Hubbs]

On Wed, Feb 01, 2017 at 09:03:49AM -0600, William Hubbs wrote:
> On Wed, Feb 01, 2017 at 11:54:41AM +0100, Tobias Klausmann wrote:
> > Hi! 
> > 
> > On Mon, 30 Jan 2017, William Hubbs wrote:
> > > I have been looking at the meson build system [1] [2], and I like what I
> > > see.
> > > 
> > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> > > meson build system [3].
> > > 
> > > As I said on the bug, the downside is the addition of py3 and ninja as
> > > build time dependencies, but I think the upside (a build system where
> > > we don't have to worry about parallel make issues or portability)
> > > outweighs that.
> > > 
> > > What do folks think here?
> > 
> > Meson isn't even keyworded anywhere but amd64 and x86 and I
> > couldn't find an indication that they care about off-mainstream
> > architectures at all. Yes, it's written in Python as such is more
> > portable than if it were written in C or somesuch, but for a
> > build system, the arch it runs on and targets are more important
> > than for most other programs.
>  
>  You are right that meson isn't keyworded anywhere but amd64 and x86,
>  and I will ask them about this because If they didn't want to support
>  off-mainstream arches this would be a blocker. Not just for OpenRC, but
>  for all consumers that convert to it.
 
 I checked with meson upstream, and they pointed me to Debian. Debian
 already has packages that use Meson on all arches such as
 https://packages.debian.org/sid/pitivi.

It looks like it would just be a matter of keywording meson as other
projects need it.

Again, the makefiles can't go anywhere at this point. this is an
upstream experiment to see how well meson would work.


William



signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Ian Stakenvicius]

On 01/02/17 10:39 AM, William Hubbs wrote:
> 
> I thought about autotools. I'm not really fond of its syntax, and I've
> been told that, to use autotools correctly, I would need to start
> generating manual release tarballs again because I would need to put the
> autotools generated cruft in them.


Well, #1, you should do that anyways.  But, #2, no you don't -need- to
have autoconf already run inside the tarball if you really don't want
to; it's convention but there are projects that don't.  Also, #3,
doing this is as easy as running 'make dist' when you have an
autotools build system, so generating said tarballs for release may
actually be -easier- than what you're doing now.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[james]

On 02/01/2017 10:39 AM, William Hubbs wrote:

On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote:

On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote:

As I said on the bug, the downside is the addition of py3 and ninja as
build time dependencies, but I think the upside (a build system where
we don't have to worry about parallel make issues or portability)
outweighs that.

Could you please link or otherwise explain the portability issue?


I'm not talking about a specific instance, just the flexability you get
with a build system. You let it handle the details of building
executables, linking libraries, etc.

I have heard from more than one person that the OpenRC makefiles are
not written well, and I agree, so I've been looking for a build system
for a while.

I thought about autotools. I'm not really fond of its syntax, and I've
been told that, to use autotools correctly, I would need to start
generating manual release tarballs again because I would need to put the
autotools generated cruft in them.

I'm open to suggestions. I picked meson to experiment with because it
has a very nice clean syntax.

William




'TUP' is the fastest build system of the all? I believe many build 
systems leverage or imitate what TUP does. I've read that for hand 
crafting a specific build system, TUP is the most fundamental of the 
building blocks. Here are a few links, there are many for your perusal::


http://gittup.org/tup/make_vs_tup.html

https://news.ycombinator.com/item?id=12622097


I think TUP would really shine in a build system for embedded and 
otherwise constrained build environments (limited resources) but I have 
not vetted that theory out, as I usually lean on others with greater 
depth of understanding in such matters. Still, from what I read, TUP 
warrants monitoring as new code contributions keep moving this blazingly 
fast build system tool forward. If others have first hand experience 
with TUP, I'd very much like to read about their comments and 
experiences with TUP.



hth,
James

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[james]

On 02/01/2017 10:40 AM, William Hubbs wrote:

On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote:

On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote:

As I said on the bug, the downside is the addition of py3 and ninja as
build time dependencies, but I think the upside (a build system where
we don't have to worry about parallel make issues or portability)
outweighs that.

Could you please link or otherwise explain the portability issue?


I'm not talking about a specific instance, just the flexability you get
with a build system. You let it handle the details of building
executables, linking libraries, etc.

I have heard from more than one person that the OpenRC makefiles are
not written well, and I agree, so I've been looking for a build system
for a while.

I thought about autotools. I'm not really fond of its syntax, and I've
been told that, to use autotools correctly, I would need to start
generating manual release tarballs again because I would need to put the
autotools generated cruft in them.

I'm open to suggestions. I picked meson to experiment with because it
has a very nice clean syntax.

William



'TUP' is the fastest build system of the all? I believe many build
systems leverage or imitate what TUP does. I've read that for hand 
crafting a specific build system, TUP is the most fundamental of the

building blocks. Here are a few links, there are many for your perusal::


http://gittup.org/tup/make_vs_tup.html

https://news.ycombinator.com/item?id=12622097


I think TUP would really shine in a build system for embedded and 
otherwise constrained build environments (limited resources) but

I have not vetted that theory out, as I usually lean on others
with greater depth of understanding in such matters. Still, from what I 
read, TUP warrants monitoring as new code contributions keep moving this

blazingly fast build system tool forward.


hth,
James

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[William Hubbs]

On Mon, Jan 30, 2017 at 03:08:42PM -0600, Dustin C. Hatch wrote:
> On 2017-01-30 14:04, William Hubbs wrote:
> > I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> > meson build system [3].
> > 
> > …
> > 
> > What do folks think here?
> > 
> 
> I looked at Meson a bit, and I liked almost everything, except the
> configuration file-based mechanism for cross-compiling. Has anyone
> thought about how that will integrate with Portage, or more
> specifically, with cross-emerge/emerge-wrapper, and the environment
> variable-based mechanism used by other build systems?

I've never done any cross-compiling, but this is something that would
need to be looked at before  I could make this live in Gentoo if that
happens.

There is also an open bug for an eclass for the meson build system which
I have been thinking about.

Keep in mind folks that this thread was started along with the upstream
issue to gather ideas.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[James Le Cuirot]

On Wed, 1 Feb 2017 10:46:12 -0600
William Hubbs  wrote:

> On Wed, Feb 01, 2017 at 03:55:17PM +, James Le Cuirot wrote:
> > On Wed, 1 Feb 2017 09:39:34 -0600
> > William Hubbs  wrote:
> >   
> > > I thought about autotools. I'm not really fond of its syntax, and
> > > I've been told that, to use autotools correctly, I would need to
> > > start generating manual release tarballs again because I would
> > > need to put the autotools generated cruft in them.  
> > 
> > Not all that hard, to be honest. Autotools adds a "make dist"
> > target and then you just upload that tarball to GitHub by adding a
> > new release.  
> 
> Is that functionality available through the github API, or do you have
> to go to the web site?

The API has it covered.

https://developer.github.com/v3/repos/releases/#create-a-release
https://developer.github.com/v3/repos/releases/#upload-a-release-asset

> Also, another concern I would have is the tarballs are not
> reproducible that way.

True though I see it has been discussed not all that long ago. There
may even be a solution somewhere but I didn't find one in a hurry.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[William Hubbs]

On Wed, Feb 01, 2017 at 03:55:17PM +, James Le Cuirot wrote:
> On Wed, 1 Feb 2017 09:39:34 -0600
> William Hubbs  wrote:
> 
> > I thought about autotools. I'm not really fond of its syntax, and I've
> > been told that, to use autotools correctly, I would need to start
> > generating manual release tarballs again because I would need to put
> > the autotools generated cruft in them.
> 
> Not all that hard, to be honest. Autotools adds a "make dist" target and
> then you just upload that tarball to GitHub by adding a new release.

Is that functionality available through the github API, or do you have
to go to the web site?

Also, another concern I would have is the tarballs are not reproducible
that way.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[James Le Cuirot]

On Wed, 1 Feb 2017 09:39:34 -0600
William Hubbs  wrote:

> I thought about autotools. I'm not really fond of its syntax, and I've
> been told that, to use autotools correctly, I would need to start
> generating manual release tarballs again because I would need to put
> the autotools generated cruft in them.

Not all that hard, to be honest. Autotools adds a "make dist" target and
then you just upload that tarball to GitHub by adding a new release.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[William Hubbs]

On Wed, Feb 01, 2017 at 01:37:04AM +, Robin H. Johnson wrote:
> On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote:
> > As I said on the bug, the downside is the addition of py3 and ninja as
> > build time dependencies, but I think the upside (a build system where
> > we don't have to worry about parallel make issues or portability)
> > outweighs that.
> Could you please link or otherwise explain the portability issue?

I'm not talking about a specific instance, just the flexability you get
with a build system. You let it handle the details of building
executables, linking libraries, etc.

I have heard from more than one person that the OpenRC makefiles are
not written well, and I agree, so I've been looking for a build system
for a while.

I thought about autotools. I'm not really fond of its syntax, and I've
been told that, to use autotools correctly, I would need to start
generating manual release tarballs again because I would need to put the
autotools generated cruft in them.

I'm open to suggestions. I picked meson to experiment with because it
has a very nice clean syntax.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[William Hubbs]

On Wed, Feb 01, 2017 at 11:54:41AM +0100, Tobias Klausmann wrote:
> Hi! 
> 
> On Mon, 30 Jan 2017, William Hubbs wrote:
> > I have been looking at the meson build system [1] [2], and I like what I
> > see.
> > 
> > I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> > meson build system [3].
> > 
> > As I said on the bug, the downside is the addition of py3 and ninja as
> > build time dependencies, but I think the upside (a build system where
> > we don't have to worry about parallel make issues or portability)
> > outweighs that.
> > 
> > What do folks think here?
> 
> Meson isn't even keyworded anywhere but amd64 and x86 and I
> couldn't find an indication that they care about off-mainstream
> architectures at all. Yes, it's written in Python as such is more
> portable than if it were written in C or somesuch, but for a
> build system, the arch it runs on and targets are more important
> than for most other programs.
 
 You are right that meson isn't keyworded anywhere but amd64 and x86,
 and I will ask them about this because If they didn't want to support
 off-mainstream arches this would be a blocker. Not just for OpenRC, but
 for all consumers that convert to it.

 As I said on the upstream bug, this would be a long-term project if it
 goes through. The other blockers would be ninja and the cross build
 issue pointed out earlier at least.

 William



signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Ian Stakenvicius]

On 01/02/17 09:43 AM, William Hubbs wrote:
> On Wed, Feb 01, 2017 at 01:18:42PM +0100, Michał Górny wrote:
>> W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs
>> napisał:
>>> All,
>>>
>>> I have been looking at the meson build system [1] [2], and I like
>>> what I
>>> see.
>>>
>>> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
>>> meson build system [3].
>>>
>>> As I said on the bug, the downside is the addition of py3 and ninja
>>> as
>>> build time dependencies, but I think the upside (a build system where
>>> we don't have to worry about parallel make issues or portability)
>>> outweighs that.
>>>
>>> What do folks think here?
>>
>> On behalf of systemd team, I would like to officially contradict any
>> rumors that those ideas are in any way caused by systemd team. OpenRC
>> developers are shooting their own feet of their own choice.
> 
> I don't even know what this is about. I have said nothing about systemd
> or any other package like that.
> 

Pre-emptive strike is all.  We all know systemd gets blamed for
everything. :D





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[William Hubbs]

On Wed, Feb 01, 2017 at 01:18:42PM +0100, Michał Górny wrote:
> W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs
> napisał:
> > All,
> > 
> > I have been looking at the meson build system [1] [2], and I like
> > what I
> > see.
> > 
> > I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> > meson build system [3].
> > 
> > As I said on the bug, the downside is the addition of py3 and ninja
> > as
> > build time dependencies, but I think the upside (a build system where
> > we don't have to worry about parallel make issues or portability)
> > outweighs that.
> > 
> > What do folks think here?
> 
> On behalf of systemd team, I would like to officially contradict any
> rumors that those ideas are in any way caused by systemd team. OpenRC
> developers are shooting their own feet of their own choice.

I don't even know what this is about. I have said nothing about systemd
or any other package like that.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] Profile cleanup, pt. 2: multilib mess

[Michał Górny]

W dniu 21.01.2017, sob o godzinie 23∶59 +0100, użytkownik Michał Górny
napisał:
> The main goal was to reduce the role of features/* subtree that
> served
> as some kind of weird all-in-one middleware for multiple profiles.
> These
> patches:
> 
> a. kill features/*bit-* completely -- all stuff is moved to
> appropriate
> arch profiles,
> 
> b. kill LIBDIR declarations out of features/multilib -- also moved to
> appropriate arch profiles.
> 
> The main goal is simplicity. I think it's really better when you
> don't
> have to guess which of 10 implicitly inherited profiles set the final
> value, and it's really bad when minor parent order changes in some
> profile can randomly effect the results of a derived one.
> 
> Right now this is terrible. For example, the arch/amd64/x32 profile
> inherited features/multilib a second time just to reset libdir which
> has
> been indirectly set by parent profile.
> 
> I can't stay this is enough to make things perfect but I think it's
> a step in the right direction. Cleaner profiles make it easier to
> improve them more in the future.

Merged.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Michał Górny]

W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs
napisał:
> All,
> 
> I have been looking at the meson build system [1] [2], and I like
> what I
> see.
> 
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
> 
> As I said on the bug, the downside is the addition of py3 and ninja
> as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
> 
> What do folks think here?

On behalf of systemd team, I would like to officially contradict any
rumors that those ideas are in any way caused by systemd team. OpenRC
developers are shooting their own feet of their own choice.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Tobias Klausmann]

Hi! 

On Mon, 30 Jan 2017, William Hubbs wrote:
> I have been looking at the meson build system [1] [2], and I like what I
> see.
> 
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
> 
> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
> 
> What do folks think here?

Meson isn't even keyworded anywhere but amd64 and x86 and I
couldn't find an indication that they care about off-mainstream
architectures at all. Yes, it's written in Python as such is more
portable than if it were written in C or somesuch, but for a
build system, the arch it runs on and targets are more important
than for most other programs.

As others have pointed out, the gains are not quite as obvious as
the potential downsides are.

Just my 2 Rappen,
Tobias

-- 
Sent from aboard the Culture ship
GSV Just the Washing Instruction Chip in Life's Rich Tapestry

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Rich Freeman]

On Tue, Jan 31, 2017 at 9:29 PM, Kent Fredric  wrote:
>
> And we should be keeping the @system essentials set required for new 
> installations
> to be as minimal as possible without losing functionality.
>

Keep in mind that it is pretty safe to put openrc in package.provided,
well, as long as you create one symlink for all the broken packages
that still reference the wrong path for functions.sh.

/me ducks

-- 
Rich