Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-15 Thread Benda Xu
Hi,

R0b0t1  writes:

> I have seen similar choices made before, but this is the first time I
> have seen a good case for the choice you selected. E.g.:
>
> (Current.)
> *>
>*=>
>   *==>
>  *===>
>
> vs.
>
> (Usually seen.)
> *==*
>*==*
>   *==*
>  *===>
>
> vs.
>
> (What it would actually mean for prefix.)
> *==*->
>*==*-->
>   *==*--->
>  *===>
>

Nice assci art! Indeed the 3rd case is what I want to express.  It is a
big challenge though to express it within 20 characters in the profile
name.  So I chose the first one as approximation.

>>> This setup would prevent having to verify that old code works on new
>>> systems, which is implied to be supported.by the + naming (again, not
>>> sure if it matters).
>>
>> It is always supported to run an old glibc version on a new kernel, the
>> linux kernel is ABI-backwords compatible.  There is no need to verify
>> that.  Besides, by always using the most recent
>> sys-kernel/linux-headers, we are guaranteed with the newest kernel API.
>>
>
> It might be for the foreseeable future, but that might change. The
> comment was more about the features exposed to glibc and the programs
> installed via portage. It seems to me as the kernel and userland
> progress, The older profile would require constant adjustment. Perhaps
> I am not explaining it well, my apologies.

That is the norm for maintaining profiles.  We are actually doing
constant adjustment to profiles until they are deprecated and removed.
So don't worry.  We have enough time to react if that changes.

Yours,
Benda



Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-15 Thread R0b0t1
Erm.

On Mon, Jan 15, 2018 at 11:23 PM, R0b0t1  wrote:
> Hello, and my apologies for missing your message.
>
> On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu  wrote:
>> Hi R0b0t1,
>>
>> R0b0t1  writes:
>>
>>> I don't want to just comment on naming, but:
>>>
>>> It might be more natural to go the other way. Split profiles off based
>>> on version when breakage occurs, and otherwise do not reference a
>>> specific version.
>>>
>>> Then, the name indicates the most recent kernel supported by the
>>> profile. So remove the plus and (I think) shift all of the names
>>> "forward."
>>
>>> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.
>>>
>>> This seems more natural but does change the semantics of the
>>> name. Would that be a problem?
>>
>> Let's call this 'breakage-indicating scheme'.  I have considered it, but
>> finally I chose the original proposal:
>>
>> Consider one running kernel 3.8 with the newest profile, called
>> 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the
>> breakage-indicating scheme.  When glibc decides to break > in the breakage-indicating scheme, you will have to change the profile
>> to 'prefix/kernel-3.10-older'.
>>
>> Consider otherwise one running kernel 4.9, you will not not need to
>> switch profile 'prefix/kernel-3.2+' in the original proposal, although
>> 'prefix/kernel-3.10+' will be a better profile.
>>
>> In either case, the original proposal does not force a profile switch
>> when glibc breaks old kernel.  Therefore I prefer it.
>>
>
> This makes sense. While I agree that minimizing breakage is a good
> idea, I am not sure it should be favored over all alternatives.
>
>>> Is it expected people would want to use the profiles with
>>> compatibility features on newer kernels?
>>
>> One use case is that: I want to bootstrap on my new and powerful server
>> a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting
>> Prefix to an aging RHEL 5.  Bootstrapping a 'prefix/kernel-2.6.32-older'
>> on kernel 4.9 feels awkward.
>>
>> But it is not about use cases, it is about logical consistancy: if we
>> are not forbidden to run an old glibc on a new kernel, we should not
>> indicate so in profile names.
>>
>
> I have seen similar choices made before, but this is the first time I
> have seen a good case for the choice you selected. E.g.:
>

(Lines up in a monospaced font.)

>>> This setup would prevent having to verify that old code works on new
>>> systems, which is implied to be supported.by the + naming (again, not
>>> sure if it matters).
>>
>> It is always supported to run an old glibc version on a new kernel, the
>> linux kernel is ABI-backwords compatible.  There is no need to verify
>> that.  Besides, by always using the most recent
>> sys-kernel/linux-headers, we are guaranteed with the newest kernel API.
>>
>
> It might be for the foreseeable future, but that might change. The
> comment was more about the features exposed to glibc and the programs
> installed via portage. It seems to me as the kernel and userland
> progress, the older profile. Perhaps I am not explaining it well, my
> apologies.
>

The older profile would require constant adjustment.



Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-15 Thread R0b0t1
Hello, and my apologies for missing your message.

On Fri, Jan 12, 2018 at 1:59 AM, Benda Xu  wrote:
> Hi R0b0t1,
>
> R0b0t1  writes:
>
>> I don't want to just comment on naming, but:
>>
>> It might be more natural to go the other way. Split profiles off based
>> on version when breakage occurs, and otherwise do not reference a
>> specific version.
>>
>> Then, the name indicates the most recent kernel supported by the
>> profile. So remove the plus and (I think) shift all of the names
>> "forward."
>
>> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.
>>
>> This seems more natural but does change the semantics of the
>> name. Would that be a problem?
>
> Let's call this 'breakage-indicating scheme'.  I have considered it, but
> finally I chose the original proposal:
>
> Consider one running kernel 3.8 with the newest profile, called
> 'prefix/kernel-3.2+' in the original proposal and 'prefix' in the
> breakage-indicating scheme.  When glibc decides to break  in the breakage-indicating scheme, you will have to change the profile
> to 'prefix/kernel-3.10-older'.
>
> Consider otherwise one running kernel 4.9, you will not not need to
> switch profile 'prefix/kernel-3.2+' in the original proposal, although
> 'prefix/kernel-3.10+' will be a better profile.
>
> In either case, the original proposal does not force a profile switch
> when glibc breaks old kernel.  Therefore I prefer it.
>

This makes sense. While I agree that minimizing breakage is a good
idea, I am not sure it should be favored over all alternatives.

>> Is it expected people would want to use the profiles with
>> compatibility features on newer kernels?
>
> One use case is that: I want to bootstrap on my new and powerful server
> a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting
> Prefix to an aging RHEL 5.  Bootstrapping a 'prefix/kernel-2.6.32-older'
> on kernel 4.9 feels awkward.
>
> But it is not about use cases, it is about logical consistancy: if we
> are not forbidden to run an old glibc on a new kernel, we should not
> indicate so in profile names.
>

I have seen similar choices made before, but this is the first time I
have seen a good case for the choice you selected. E.g.:

(Current.)
*>
   *=>
  *==>
 *===>

vs.

(Usually seen.)
*==*
   *==*
  *==*
 *===>

vs.

(What it would actually mean for prefix.)
*==*->
   *==*-->
  *==*--->
 *===>

>> This setup would prevent having to verify that old code works on new
>> systems, which is implied to be supported.by the + naming (again, not
>> sure if it matters).
>
> It is always supported to run an old glibc version on a new kernel, the
> linux kernel is ABI-backwords compatible.  There is no need to verify
> that.  Besides, by always using the most recent
> sys-kernel/linux-headers, we are guaranteed with the newest kernel API.
>

It might be for the foreseeable future, but that might change. The
comment was more about the features exposed to glibc and the programs
installed via portage. It seems to me as the kernel and userland
progress, the older profile. Perhaps I am not explaining it well, my
apologies.

Cheers,
 R0b0t1



Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-12 Thread Benda Xu
Hi Patrice,

Patrice Clement  writes:

> Thanks for the work.
>
> Could you also consider adding a Prefix profile compatible with
> FreeBSD?

We have supported BSD before.  But at the moment, no one on the Prefix
team have access to BSD hosts.


Historically, fauli has developped Prefix on FreeBSD 8:

  https://wiki.gentoo.org/wiki/Project:Prefix

But now the port is outdated and removed in Jan 2017:

  
https://archives.gentoo.org/gentoo-alt/message/cf3af6ba4d2c56ea6c2451435b33eddf


You are more than welcomed to revive Prefix on FreeBSD.

Cheers,
Benda



Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-12 Thread Patrice Clement
Hi Benda

Monday 08 Jan 2018 15:38:49, Benda Xu wrote :
> Hi,
> 
> I would like to introduce some 17.0 profile for Prefix.  It also
> introduces separate profiles to support different ranges of linux
> kernels.
> 
>   | name | linux| glibc |
>   |--+--+---|
>   | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 |
>   | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 |
>   | beyond-kernel-3.2| [3.2, latest)| latest|
> 
> Attached is the patch.  Thoughts and comments?
> 
> Yours,
> Benda
> ---
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi   | 1 +
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi   | 1 +
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent | 2 ++
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi  | 1 +
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent| 2 ++
>  profiles/default/linux/amd64/17.0/no-multilib/prefix/parent | 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi| 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent  | 2 ++
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi| 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent  | 2 ++
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi   | 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent | 2 ++
>  profiles/default/linux/x86/17.0/prefix/parent   | 1 +
>  profiles/profiles.desc  | 6 
> ++
>  15 files changed, 26 insertions(+)
>  create mode 100644 
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
>  create mode 100644 
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
>  create mode 100644 
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
>  create mode 100644 
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
>  create mode 100644 
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
>  create mode 100644 
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
>  create mode 100644 
> profiles/default/linux/amd64/17.0/no-multilib/prefix/parent
>  create mode 100644 
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi
>  create mode 100644 
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent
>  create mode 100644 
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi
>  create mode 100644 
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent
>  create mode 100644 
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi
>  create mode 100644 
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent
>  create mode 100644 profiles/default/linux/x86/17.0/prefix/parent
> 
> diff --git 
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
>  
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
> new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++ 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
> @@ -0,0 +1 @@
> +5
> diff --git 
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
>  
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
> new file mode 100644
> index ..6a349d3df196
> --- /dev/null
> +++ 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
> @@ -0,0 +1,2 @@
> +..
> +../../../../../../../features/prefix/standalone/beyond-kernel-2.6.16
> diff --git 
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
>  
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
> new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++ 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
> @@ -0,0 +1 @@
> +5
> diff --git 
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
>  
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
> new file mode 100644
> index ..f14f9dcf77ee
> --- /dev/null
> +++ 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
> @@ -0,0 +1,2 @@
> +..
> +../../../../../../../features/prefix/standalone/beyond-kernel-2.6.32
> diff --git 
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi 
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
> new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++ 
> 

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-12 Thread Benda Xu
Hi R0b0t1,

R0b0t1  writes:

> I don't want to just comment on naming, but:
>
> It might be more natural to go the other way. Split profiles off based
> on version when breakage occurs, and otherwise do not reference a
> specific version.
>
> Then, the name indicates the most recent kernel supported by the
> profile. So remove the plus and (I think) shift all of the names
> "forward."

> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.
>
> This seems more natural but does change the semantics of the
> name. Would that be a problem?

Let's call this 'breakage-indicating scheme'.  I have considered it, but
finally I chose the original proposal:

Consider one running kernel 3.8 with the newest profile, called
'prefix/kernel-3.2+' in the original proposal and 'prefix' in the
breakage-indicating scheme.  When glibc decides to break  Is it expected people would want to use the profiles with
> compatibility features on newer kernels?

One use case is that: I want to bootstrap on my new and powerful server
a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting
Prefix to an aging RHEL 5.  Bootstrapping a 'prefix/kernel-2.6.32-older'
on kernel 4.9 feels awkward.

But it is not about use cases, it is about logical consistancy: if we
are not forbidden to run an old glibc on a new kernel, we should not
indicate so in profile names.

> This setup would prevent having to verify that old code works on new
> systems, which is implied to be supported.by the + naming (again, not
> sure if it matters).

It is always supported to run an old glibc version on a new kernel, the
linux kernel is ABI-backwords compatible.  There is no need to verify
that.  Besides, by always using the most recent
sys-kernel/linux-headers, we are guaranteed with the newest kernel API.

Yours,
Benda



[gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-11 Thread R0b0t1
On Wednesday, January 10, 2018, Benda Xu  wrote:
> Hi MJ,
>
> "M. J. Everitt"  writes:
>
>> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
>> different between 2.6.16+ and 2.6.32+ .. should this potentially be
>> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
>> and more confusing to others
>
> 2.6.16+ means that it can be used in any cases when the kernel is newer
> than 2.6.16.  For example, you can use it on linux-4.14, just with
> unnecessary backward compatibility code.
>
> Besides, with the newest profile, kernel-3.2+, the ending kernel version
> is not known.  We will have to rename it when glibc jumps if the profile
> is named with a version range.
>

I don't want to just comment on naming, but:

It might be more natural to go the other way. Split profiles off based on
version when breakage occurs, and otherwise do not reference a specific
version.

Then, the name indicates the most recent kernel supported by the profile.
So remove the plus and (I think) shift all of the names "forward."

So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.

This seems more natural but does change the semantics of the name. Would
that be a problem? Is it expected people would want to use the profiles
with compatibility features on newer kernels?

This setup would prevent having to verify that old code works on new
systems, which is implied to be supported.by the + naming (again, not sure
if it matters).

Cheers,
R0b0t1


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-11 Thread M. J. Everitt
On 11/01/18 03:18, Benda Xu wrote:
> Hi MJ,
>
> "M. J. Everitt"  writes:
>
>> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
>> different between 2.6.16+ and 2.6.32+ .. should this potentially be
>> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
>> and more confusing to others
> 2.6.16+ means that it can be used in any cases when the kernel is newer
> than 2.6.16.  For example, you can use it on linux-4.14, just with
> unnecessary backward compatibility code.
>
> Besides, with the newest profile, kernel-3.2+, the ending kernel version
> is not known.  We will have to rename it when glibc jumps if the profile
> is named with a version range.
>
>
> Hope this addresses your concern.
>
> Cheers,
> Benda
Thanks, that does make sense!

MJE



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-10 Thread Benda Xu
Hi MJ,

"M. J. Everitt"  writes:

> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
> different between 2.6.16+ and 2.6.32+ .. should this potentially be
> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
> and more confusing to others

2.6.16+ means that it can be used in any cases when the kernel is newer
than 2.6.16.  For example, you can use it on linux-4.14, just with
unnecessary backward compatibility code.

Besides, with the newest profile, kernel-3.2+, the ending kernel version
is not known.  We will have to rename it when glibc jumps if the profile
is named with a version range.


Hope this addresses your concern.

Cheers,
Benda


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-10 Thread M. J. Everitt
On 10/01/18 14:00, kuzetsa wrote:
> On 01/09/2018 08:21 AM, Aaron Bauman wrote:
>> On January 8, 2018 9:39:47 PM EST, Benda Xu  wrote:
>>> Hi kuzetsa,
>>>
>>> kuzetsa  writes:
>>>
 The term "beyond" feels wrong & confusing.
 (Not sure what to replace it with though)
>>> How about this?
>>>
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
>>>
>>> Yours,
>>> Benda
>> I like this as it is shorter and makes the version ranges more clear.  Lgtm.
>>
>> -Aaron
> Yes. Using a plus looks nicer / cleaner to me too.
>
Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
different between 2.6.16+ and 2.6.32+ .. should this potentially be
2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
and more confusing to others

MJE



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-10 Thread kuzetsa
On 01/09/2018 08:21 AM, Aaron Bauman wrote:
>
> On January 8, 2018 9:39:47 PM EST, Benda Xu  wrote:
>> Hi kuzetsa,
>>
>> kuzetsa  writes:
>>
>>> The term "beyond" feels wrong & confusing.
>>> (Not sure what to replace it with though)
>> How about this?
>>
>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
>>
>> Yours,
>> Benda
> I like this as it is shorter and makes the version ranges more clear.  Lgtm.
>
> -Aaron

Yes. Using a plus looks nicer / cleaner to me too.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-09 Thread Aaron Bauman


On January 8, 2018 9:39:47 PM EST, Benda Xu  wrote:
>Hi kuzetsa,
>
>kuzetsa  writes:
>
>> The term "beyond" feels wrong & confusing.
>> (Not sure what to replace it with though)
>
>How about this?
>
>  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
>
>Yours,
>Benda

I like this as it is shorter and makes the version ranges more clear.  Lgtm.

-Aaron
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread Benda Xu
Hi Aaron,

Aaron Bauman  writes:

> I am not too familair with prefix other than the purpose of it (e.g. I
> have never built it), but is there a better naming standard for the
> profiles? I understand the need to distinguish between the kernel and
> glibc versions.

> Is there a standard I am missing for profile names?

From PMS, there is no words on profile naming.  But I think adopting
naming of category [A-Za-z0-9+_.-] will not be too wrong:

  https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-170003.1.1

> Could there be a wiki explaining a prefix profile versioning that
> correlates to the glibc and kernel versions? Or is the intent to keep
> it simple and easily identifiable from within the PM?

A wiki page would be a good idea for detailed explanations.

> Not a big deal, but just my thoughts. Thanks for your work on prefix
> and I am sure many will benefit from the new profiles :)

Thanks for inputs!

Yours,
Benda


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread Benda Xu
Hi kuzetsa,

kuzetsa  writes:

> The term "beyond" feels wrong & confusing.
> (Not sure what to replace it with though)

How about this?

  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+

Yours,
Benda


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread Aaron Bauman
On Monday, January 8, 2018 1:38:49 AM EST Benda Xu wrote:
> Hi,
> 
> I would like to introduce some 17.0 profile for Prefix.  It also
> introduces separate profiles to support different ranges of linux
> kernels.
> 
>   | name | linux| glibc |
>   |
>   |--+--+---|
>   |
>   | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 |
>   | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 |
>   | beyond-kernel-3.2| [3.2, latest)| latest|
> 
> Attached is the patch.  Thoughts and comments?
> 
> Yours,
> Benda
> ---
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi   | 1 +
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi   | 1 +
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent | 2 ++
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi  | 1 +
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent| 2 ++
>  profiles/default/linux/amd64/17.0/no-multilib/prefix/parent | 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi| 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent  | 2 ++
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi| 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent  | 2 ++
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi   | 1 +
>  profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent | 2 ++
>  profiles/default/linux/x86/17.0/prefix/parent   | 1 +
>  profiles/profiles.desc  | 6
> ++ 15 files changed, 26 insertions(+)
>  create mode 100644
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/e
> api create mode 100644
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/p
> arent create mode 100644
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/e
> api create mode 100644
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/p
> arent create mode 100644
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
> create mode 100644
> profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/pare
> nt create mode 100644
> profiles/default/linux/amd64/17.0/no-multilib/prefix/parent create mode
> 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi
> create mode 100644
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent create
> mode 100644
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi create
> mode 100644
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent create
> mode 100644 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi
> create mode 100644
> profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent create mode
> 100644 profiles/default/linux/x86/17.0/prefix/parent
> 
> diff --git
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16
> /eapi
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16
> /eapi new file mode 100644
> index ..7ed6ff82de6b
> --- /dev/null
> +++
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16
> /eapi @@ -0,0 +1 @@
> +5
> diff --git
> a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16
> /parent
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16
> /parent new file mode 100644
> index ..6a349d3df196
> --- /dev/null
> +++
> b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16
> /parent @@ -0,0 +1,2 @@
> +..

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


Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread kuzetsa
On 01/08/2018 01:38 AM, Benda Xu wrote:
> Hi,
>
> I would like to introduce some 17.0 profile for Prefix.  It also
> introduces separate profiles to support different ranges of linux
> kernels.
>
>   | name | linux| glibc |
>   |--+--+---|
>   | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 |
>   | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 |
>   | beyond-kernel-3.2| [3.2, latest)| latest|
>
> Attached is the patch.  Thoughts and comments?
>
> Yours,
> Benda
> ---
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi   | 1 +
>  .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++

[...]

Not sure what else is changed / added.

The term "beyond" feels wrong & confusing.
(Not sure what to replace it with though)




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread Benda Xu
Hi,

I would like to introduce some 17.0 profile for Prefix.  It also
introduces separate profiles to support different ranges of linux
kernels.

  | name | linux| glibc |
  |--+--+---|
  | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 |
  | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 |
  | beyond-kernel-3.2| [3.2, latest)| latest|

Attached is the patch.  Thoughts and comments?

Yours,
Benda
---
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi   | 1 +
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi   | 1 +
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent | 2 ++
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi  | 1 +
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent| 2 ++
 profiles/default/linux/amd64/17.0/no-multilib/prefix/parent | 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi| 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent  | 2 ++
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi| 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent  | 2 ++
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi   | 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent | 2 ++
 profiles/default/linux/x86/17.0/prefix/parent   | 1 +
 profiles/profiles.desc  | 6 ++
 15 files changed, 26 insertions(+)
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
 create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/parent
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent
 create mode 100644 profiles/default/linux/x86/17.0/prefix/parent

diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
new file mode 100644
index ..7ed6ff82de6b
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
@@ -0,0 +1 @@
+5
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
new file mode 100644
index ..6a349d3df196
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
@@ -0,0 +1,2 @@
+..
+../../../../../../../features/prefix/standalone/beyond-kernel-2.6.16
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
new file mode 100644
index ..7ed6ff82de6b
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
@@ -0,0 +1 @@
+5
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
new file mode 100644
index ..f14f9dcf77ee
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
@@ -0,0 +1,2 @@
+..
+../../../../../../../features/prefix/standalone/beyond-kernel-2.6.32
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
new file mode 100644
index ..7ed6ff82de6b
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
@@ -0,0 +1 @@
+5
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
new file mode 100644