Mailing List Archive

Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-18, o godz. 21:44:05
Michał Górny <mgorny@gentoo.org> napisał(a):

> Hello,
>
> I would like to commit the following flags as cpu_flags_x86_desc.
> The list combines global USE flags with some local USE flags I've been
> able to find.

Following your suggestions, I'm attaching three files:

1. updated cpu_flags_x86.desc, with:

a. fma3/fma4 distinction,

b. aes-ni renamed to aes for consistency with cpuinfo, we no longer
have to worry about USE flag collision with other USE=aes uses,

c. complete and machine-parseable listing of cpuinfo flags.

2. cpuinfo2cpuflags-x86.py script that parses cpu_flags_x86.desc
and /proc/cpuinfo and generates a nice CPU_FLAGS_X86 value for you. We
need to decide where to put it (scripts/?).

3. Initial text of the news item for review.

--
Best regards,
Michał Górny
Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On Tue, 20 Jan 2015 10:40:17 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> # Copyright 1999-2014 Gentoo Foundation.
> # Distributed under the terms of the GNU General Public License v2
> # $Header$
>
> # Whenever the flag name does not correspond to /proc/cpuinfo flags,
> # please put the cpuinfo flag in square brackets. If more than one
> flag # is specified, any of them will enable the respective USE flag.
>

nice


now, letmegrepitforyou:


> avx - Adds support for Advanced Vector Extensions instructions

media-video/ffmpeg:avx - Adds support for Advanced Vector Extensions
instructions (Intel Sandy Bridge, AMD Bulldozer and later chips)

> avx2 - Adds support for Advanced Vector Extensions 2 instructions

media-video/ffmpeg:avx2 - Adds support for Advanced Vector Extensions 2
instructions (Intel Haswell and later chips)

> fma3 - Use the Fused Multiply Add 3 instruction set ([fma] in cpuinfo)

media-video/ffmpeg:fma3 - Enables FMA3 optimizations: AMD processors
starting with Piledriver architecture and Intel Haswell based
processors or later.

> fma4 - Use the Fused Multiply Add 4 instruction set

media-video/ffmpeg:fma4 - Enables FMA4 optimizations: AMD processors
starting with Bulldozer architecture.

> sse4_1 - Enable SSE4.1 instruction support

media-libs/libvpx:sse4_1 - Enable optimization for SSE4_1 capable
processors (Intel Core 2 Penryn and later chips)


> sse4_2 - Enable SSE4.2 instruction support

media-video/ffmpeg:sse4_2 - Enables SSE4.2 optimizations: Nehalem-based
Intel Core i7 or later.

> ssse3 - Use the SSSE3 instruction set (NOT sse3/pni)

media-libs/libvpx:ssse3 - faster floating point optimization for SSSE3
capable chips (Intel Core 2 and later chips)






I like the "available in cpu $foo and later" because this influences me
in what to buy: If I know that I will have noticeable gain with hand
written asm in a package that is critical to me, I know it will perform
better for my needs despite benchmarks might be saying otherwise.


Alexis.
Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Michał Górny posted on Tue, 20 Jan 2015 10:40:17 +0100 as excerpted:

> Display-If-Keyword: amd64 ~amd64 x86 ~x86
>
> The USE flags corresponding to intruction sets and other features
> specific to the x86 architecture are being moved into a separate USE
> flag group called CPU_FLAGS_X86.

So based on this preliminary news item, I decided to get ahead of the
game and add the use_expand to the appropriate make.conf sourced file...

... and IMMEDIATELY ran into this:

CPU_FLAGS_X86 ?? I'm ~amd64, do I leave it as-is, change it to
CPU_FLAGS_X86_64 (kernel style), or change it to CPU_FLAGS_AMD64 (gentoo
style)?

Knowing what I know about gentoo's use of use_expand, I'm almost certain
I leave it as-is: CPU_FLAGS_X86 . But if it's triggering the slightest
doubt and hesitation here, and it is, it's certain to be a rather larger
source of confusion to many. So...

Please update the news item to specify that yes, it's _X86 for amd64
users as well (assuming my near-certainty above is correct, else make
explicit whatever actually applies).

Here's a second-draft pass at more explicit wording (also corrects a
typo, "intruction", that spell-check flagged when I select-pasted):

The USE flags corresponding to instruction sets and other features
specific to the x86 (and amd64) architecture are being moved into a
separate USE flag group called CPU_FLAGS_X86. (Because amd64 is an
extension of x86, amd64 users use the same group, CPU_FLAGS_X86.)


Additionally, unless the change is going to be atomic across the tree,
including existing stable packages /and/ the news item at exactly the
same time, I'd suggest an additional paragraph in the news item,
suggesting keeping the existing USE flags for some period (the
traditional 1-year supported update time period?) as well. First-draft
wording (please suggest updates, I'm not entirely comfortable with this
but it suffices for first-draft):

In ordered to cover the transition period, you may wish to keep existing
copies of any USE flags transfered to CPU_FLAGS_X86 for a suggested
period of one year, or until you've merged updates with the new
use_expand form of all affected packages, after which you can remove the
old form from your normal USE.


Thanks. The extra work that this whole change entails is appreciated!
=:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-21, o godz. 00:18:50
Duncan <1i5t5.duncan@cox.net> napisał(a):

> Michał Górny posted on Tue, 20 Jan 2015 10:40:17 +0100 as excerpted:
>
> > Display-If-Keyword: amd64 ~amd64 x86 ~x86
> >
> > The USE flags corresponding to intruction sets and other features
> > specific to the x86 architecture are being moved into a separate USE
> > flag group called CPU_FLAGS_X86.
>
> So based on this preliminary news item, I decided to get ahead of the
> game and add the use_expand to the appropriate make.conf sourced file...

Attaching a new version.

--
Best regards,
Michał Górny
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On 01/23/2015 02:13 PM, Michał Górny wrote:
> To help you enable the correct USE flags, we are providing a Python
> script which generates the correct value from your /proc/cpuinfo [1].
> The Python script can be downloaded and executed using the following
> command:
>
> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python

Can we not encourage people to pipe stuff from a plain-http website into
an interpreter?

But that's not the biggest problem with the wget thing: the first time
someone runs this it's going to fail.

$ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
...
Unable to determine PORTDIR, please set it before calling this script

Now they get to download it again. Perhaps a bigger problem:

$ echo $PORTDIR
/var/cache/portage/repositories/gentoo
$ python cpuinfo2cpuflags-x86.py
Unable to determine PORTDIR, please set it before calling this script

ಠ_ಠ
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-23, o godz. 14:26:48
Michael Orlitzky <mjo@gentoo.org> napisał(a):

> On 01/23/2015 02:13 PM, Michał Górny wrote:
> > To help you enable the correct USE flags, we are providing a Python
> > script which generates the correct value from your /proc/cpuinfo [1].
> > The Python script can be downloaded and executed using the following
> > command:
> >
> > $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
>
> Can we not encourage people to pipe stuff from a plain-http website into
> an interpreter?

Find a better solution.

> But that's not the biggest problem with the wget thing: the first time
> someone runs this it's going to fail.
>
> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
> ...
> Unable to determine PORTDIR, please set it before calling this script

Don't you have Portage installed?

> Now they get to download it again. Perhaps a bigger problem:
>
> $ echo $PORTDIR
> /var/cache/portage/repositories/gentoo
> $ python cpuinfo2cpuflags-x86.py
> Unable to determine PORTDIR, please set it before calling this script

Did you export PORTDIR?

--
Best regards,
Michał Górny
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On 01/23/2015 03:22 PM, Michał Górny wrote:
> Dnia 2015-01-23, o godz. 14:26:48
> Michael Orlitzky <mjo@gentoo.org> napisał(a):
>
>> On 01/23/2015 02:13 PM, Michał Górny wrote:
>>> To help you enable the correct USE flags, we are providing a Python
>>> script which generates the correct value from your /proc/cpuinfo [1].
>>> The Python script can be downloaded and executed using the following
>>> command:
>>>
>>> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
>>
>> Can we not encourage people to pipe stuff from a plain-http website into
>> an interpreter?
>
> Find a better solution.
>

Is there an easy way for users to verify our signatures against the keys
in LDAP?

Even `wget --no-check-certificate` would be a big improvement. Or since
Firefox seems happy with the dev.gentoo.org certificate, we could just
ask them to download it with their browsers.

Longer term: can we make wget like our SSL certificate?


>> But that's not the biggest problem with the wget thing: the first time
>> someone runs this it's going to fail.
>>
>> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
>> ...
>> Unable to determine PORTDIR, please set it before calling this script
>
> Don't you have Portage installed?

I do.

$ emerge --info | grep PORTDIR
PORTDIR="/var/cache/portage/repositories/gentoo"


>> Now they get to download it again. Perhaps a bigger problem:
>>
>> $ echo $PORTDIR
>> /var/cache/portage/repositories/gentoo
>> $ python cpuinfo2cpuflags-x86.py
>> Unable to determine PORTDIR, please set it before calling this script
>
> Did you export PORTDIR?
>

No, but the error says to set it, not export it =)
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On 01/23/2015 03:22 PM, Michał Górny wrote:
>
>> But that's not the biggest problem with the wget thing: the first time
>> someone runs this it's going to fail.
>>
>> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
>> ...
>> Unable to determine PORTDIR, please set it before calling this script
>
> Don't you have Portage installed?
>

This one depends on the eselected version of python. I had python-3.4
eselected, but portage was built with the default
PYTHON_TARGETS="python2_7 python3_3".
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On Fri, Jan 23, 2015 at 3:16 PM, Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/23/2015 03:22 PM, Michał Górny wrote:
> > Dnia 2015-01-23, o godz. 14:26:48
> > Michael Orlitzky <mjo@gentoo.org> napisał(a):
> >
> >> On 01/23/2015 02:13 PM, Michał Górny wrote:
> >>> To help you enable the correct USE flags, we are providing a Python
> >>> script which generates the correct value from your /proc/cpuinfo [1].
> >>> The Python script can be downloaded and executed using the following
> >>> command:
> >>>
> >>> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
> >>
> >> Can we not encourage people to pipe stuff from a plain-http website into
> >> an interpreter?
> >
> > Find a better solution.
>

If you trust GitHub, put it on a Gist, and it'll be accessible via HTTPS
and SSH.
If the "raw" URL is too ugly, and you trust Google, use the HTTPS version
of goo.gl to shorten it.


> Even `wget --no-check-certificate` would be a big improvement. Or since
> Firefox seems happy with the dev.gentoo.org certificate, we could just
> ask them to download it with their browsers.
>
> Longer term: can we make wget like our SSL certificate?


"DigiCert SHA2 High Assurance Server CA" is not in ca-certificates.
Funnily, DigiCert's download link for it is via plain HTTP so reasonable
paranoia demands manually verifying the chain after downloading.
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On Fri, 23 Jan 2015 21:22:31 +0100 Michał Górny wrote:
> > > To help you enable the correct USE flags, we are providing a Python
> > > script which generates the correct value from your /proc/cpuinfo [1].
> > > The Python script can be downloaded and executed using the following
> > > command:
> > >
> > > $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
> >
> > Can we not encourage people to pipe stuff from a plain-http website into
> > an interpreter?
>
> Find a better solution.

Why not to ship this script together with portage (using some
USE=tools)? Alternatively it may be added as an independent ebuild
in app-admin (like we already have different cleaners and updaters).

Best regards,
Andrew Savchenko
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-24, o godz. 00:59:24
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Fri, 23 Jan 2015 21:22:31 +0100 Michał Górny wrote:
> > > > To help you enable the correct USE flags, we are providing a Python
> > > > script which generates the correct value from your /proc/cpuinfo [1].
> > > > The Python script can be downloaded and executed using the following
> > > > command:
> > > >
> > > > $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
> > >
> > > Can we not encourage people to pipe stuff from a plain-http website into
> > > an interpreter?
> >
> > Find a better solution.
>
> Why not to ship this script together with portage (using some
> USE=tools)? Alternatively it may be added as an independent ebuild
> in app-admin (like we already have different cleaners and updaters).

Because it's a tiny script people are supposed to run once and be done
with it.

--
Best regards,
Michał Górny
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-23, o godz. 16:16:25
Michael Orlitzky <mjo@gentoo.org> napisał(a):

> On 01/23/2015 03:22 PM, Michał Górny wrote:
> > Dnia 2015-01-23, o godz. 14:26:48
> > Michael Orlitzky <mjo@gentoo.org> napisał(a):
> >
> >> On 01/23/2015 02:13 PM, Michał Górny wrote:
> >>> To help you enable the correct USE flags, we are providing a Python
> >>> script which generates the correct value from your /proc/cpuinfo [1].
> >>> The Python script can be downloaded and executed using the following
> >>> command:
> >>>
> >>> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py | python
> >>
> >> Can we not encourage people to pipe stuff from a plain-http website into
> >> an interpreter?
> >
> > Find a better solution.
> >
>
> Is there an easy way for users to verify our signatures against the keys
> in LDAP?

No. At least not that I'm aware of. Maybe gentoo-keys has something.

> Even `wget --no-check-certificate` would be a big improvement.

...because?

> Or since
> Firefox seems happy with the dev.gentoo.org certificate, we could just
> ask them to download it with their browsers.

The link to the project page is below. If someone wants to download by
hand, he can clone the repo as well.

> >> Now they get to download it again. Perhaps a bigger problem:
> >>
> >> $ echo $PORTDIR
> >> /var/cache/portage/repositories/gentoo
> >> $ python cpuinfo2cpuflags-x86.py
> >> Unable to determine PORTDIR, please set it before calling this script
> >
> > Did you export PORTDIR?
> >
>
> No, but the error says to set it, not export it =)

Thanks, mr troll. REALLY HELPFUL.

--
Best regards,
Michał Górny
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On 01/23/2015 05:07 PM, Michał Górny wrote:
>
>> Even `wget --no-check-certificate` would be a big improvement.
>
> ...because?
>

You rule out some 13-year-olds in coffee shops as attackers. I
overstated -- since the user isn't replying with any data, it's not a
big improvement, but it's still a little better.


>>
>> No, but the error says to set it, not export it =)
>
> Thanks, mr troll. REALLY HELPFUL.
>

Ok it looks stupid, but I was serious. I source my make.conf in
~/.bashrc, so I have PORTDIR and friends set in my shell. I have PORTDIR
set, and the thing is telling me to set PORTDIR? It took me a moment to
realize what was wrong. It will certainly stump others.

If what you really want them to do is prepend PORTDIR="..." before the
wget command, then why give them the wget command without it? Or if the
environment variable needs to be set and then exported, why not just say
that? The news items go out to tens of thousands of people so the more
explicit the instructions are, the better. Because then people won't bug
you about all the ways in which they misinterpreted the instructions.
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-23, o godz. 17:27:16
Michael Orlitzky <mjo@gentoo.org> napisał(a):

> On 01/23/2015 05:07 PM, Michał Górny wrote:
> >
> >> Even `wget --no-check-certificate` would be a big improvement.
> >
> > ...because?
> >
>
> You rule out some 13-year-olds in coffee shops as attackers. I
> overstated -- since the user isn't replying with any data, it's not a
> big improvement, but it's still a little better.

So I have a few options at hand:

1. put a checksum in the news item. The item is GPG-signed, so
the checksum will be protected. Of course, nobody bothers to check
the signature but anyway... Bad news is that I don't know of any
command to check signature that would really fit in 80 chars.

2. Put it .gpg-protected. Then oneliner is simple 'wget -O - ... | gpg
-d | python' (I have no idea how far gpg verifies there). But it means
that people who don't care and don't have GPG won't be able to use
the one-liner.

3. Put it in an ebuild, after all. This will add a lot of complexity
but GPG comes for free, plus some people will actually test
and stabilize it.

Do you like 3.?

> >>
> >> No, but the error says to set it, not export it =)
> >
> > Thanks, mr troll. REALLY HELPFUL.
> >
>
> Ok it looks stupid, but I was serious. I source my make.conf in
> ~/.bashrc, so I have PORTDIR and friends set in my shell. I have PORTDIR
> set, and the thing is telling me to set PORTDIR? It took me a moment to
> realize what was wrong. It will certainly stump others.
>
> If what you really want them to do is prepend PORTDIR="..." before the
> wget command, then why give them the wget command without it? Or if the
> environment variable needs to be set and then exported, why not just say
> that? The news items go out to tens of thousands of people so the more
> explicit the instructions are, the better. Because then people won't bug
> you about all the ways in which they misinterpreted the instructions.

People usually won't need to do that. Unless they do something stupid
like switching to a Python interpreter they disabled in the eclass...

--
Best regards,
Michał Górny
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On Fri, 23 Jan 2015 16:16:25 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:

> On 01/23/2015 03:22 PM, Michał Górny wrote:
> > Dnia 2015-01-23, o godz. 14:26:48
> > Michael Orlitzky <mjo@gentoo.org> napisał(a):
> >
> >> On 01/23/2015 02:13 PM, Michał Górny wrote:
> >>> To help you enable the correct USE flags, we are providing a
> >>> Python script which generates the correct value from
> >>> your /proc/cpuinfo [1]. The Python script can be downloaded and
> >>> executed using the following command:
> >>>
> >>> $ wget -O - dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py |
> >>> python
> >>
> >> Can we not encourage people to pipe stuff from a plain-http
> >> website into an interpreter?
> >
> > Find a better solution.
> >
>
> Is there an easy way for users to verify our signatures against the
> keys in LDAP?
>
> Even `wget --no-check-certificate` would be a big improvement. Or
> since Firefox seems happy with the dev.gentoo.org certificate, we
> could just ask them to download it with their browsers.
>
> Longer term: can we make wget like our SSL certificate?
>

Yes, if this data or python code is to be downloaded routinely, then
api.gentoo.org is the new https service specifically designed for this.

Please talk to infra for a subdirectory assignment for this data/code.

Also, for python based apps, dev-python/ssl-fetch was specifically
designed for retrieving from api.g.o (or any url) with certificate
authentication.

Taking it one step further, the gentoo-keys project (uses ssl-fetch) is
just entering the tree and can be used to download and verify files and
gpg signatures of those files. app-crypt/gkeys-0.1-r1 is in the tree
and installs with the gentoo release media gpg keys and downloads the
current gentoo-devs seed file. The developers gpg keys must be
installed for them to be verified against.

eg:

$ gkeys verify -F dev.gentoo.org/~mgorny/cpuinfo2cpuflags-x86.py

should do it, it will automatically look for a matching *.sig to use to
verify with against the installed gpg keys. It can even save and use
timestamps to prevent unneeded downloads for unchanged data in a local
cache.

But, for gkeys to become commonplace in usage, it also requires devs to
fix their current keys and LDAP data, or generate new GLEP 63 compliant
keys. But that is an off topic discussion

--
Brian Dolbec <dolsen>
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On Fri, Jan 23, 2015 at 4:38 PM, Michał Górny <mgorny@gentoo.org> wrote:

>
> 3. Put it in an ebuild, after all. This will add a lot of complexity
> but GPG comes for free, plus some people will actually test
> and stabilize it.
>
>
I think this should be in an ebuild. You mentioned that it's only needed
ONCE, but it's needed ONCE for everytime one install gentoos, along the
same lines as mirrorselect. A couple of years from now, do we want users
to have to dig through several dozen old news items to get this tool?

I know the ebuild's a bit of extra work but then the python issues can also
be properly handled. And bugs can be properly handled, etc etc.

-Ben
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On 01/23/2015 05:38 PM, Michał Górny wrote:
>
> 3. Put it in an ebuild, after all. This will add a lot of complexity
> but GPG comes for free, plus some people will actually test
> and stabilize it.
>

I do. It seems like a lot of work, but we can test and quick-stable it.
Thank you.


>> If what you really want them to do is prepend PORTDIR="..." before the
>> wget command, then why give them the wget command without it? Or if the
>> environment variable needs to be set and then exported, why not just say
>> that? The news items go out to tens of thousands of people so the more
>> explicit the instructions are, the better. Because then people won't bug
>> you about all the ways in which they misinterpreted the instructions.
>
> People usually won't need to do that. Unless they do something stupid
> like switching to a Python interpreter they disabled in the eclass...
>

It's not my fault this time. Remember when python-3.4 went stable for a
minute and this news item went out?

Python 3.4 is now enabled by default, replacing Python 3.3 as the
default Python 3 interpreter.
...
Once the changes have taken place, a world update should take care of
reinstalling any python libraries you have installed. You should also
switch your default python3 interpreter using eselect python.

For example:

eselect python set --python3 python3.4


A few hours later, PYTHON_TARGETS was reverted, and no news item went
out telling me to undo the eselect.
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-23, o godz. 17:56:49
Michael Orlitzky <mjo@gentoo.org> napisał(a):

> On 01/23/2015 05:38 PM, Michał Górny wrote:
> >
> > 3. Put it in an ebuild, after all. This will add a lot of complexity
> > but GPG comes for free, plus some people will actually test
> > and stabilize it.
> >
>
> I do. It seems like a lot of work, but we can test and quick-stable it.
> Thank you.

Ebuild committed. Now review the news item :P.

--
Best regards,
Michał Górny
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On 01/23/2015 06:12 PM, Michał Górny wrote:
> To help you enable the correct USE flags, we are providing a Python
> script tool generates the correct value using your /proc/cpuinfo.
> It can be found in app-portage/cpuinfo2cpuflags package:

I think you accidentally a word here, but otherwise it looks good to me.
The only other suggestion I have is to include $PORTDIR in the path
before profiles/desc/cpu_flags_x86.desc because the profiles/desc
directory isn't familiar to most users.

I see you updated the error message, too. Thanks.
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On Sat, 24 Jan 2015 00:12:15 +0100 Michał Górny wrote:
> To help you enable the correct USE flags, we are providing a Python
> script tool generates the correct value using your /proc/cpuinfo.
> It can be found in app-portage/cpuinfo2cpuflags package:
>
> $ emerge -1v app-portage/cpuinfo2cpuflags
> $ cpuinfo2cpuflags-x86.py

A bit pedantry here: emerge should be preceded by # instead of $,
since normally one can't install packages as a user.

Best regards,
Andrew Savchenko
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-24, o godz. 02:29:26
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Sat, 24 Jan 2015 00:12:15 +0100 Michał Górny wrote:
> > To help you enable the correct USE flags, we are providing a Python
> > script tool generates the correct value using your /proc/cpuinfo.
> > It can be found in app-portage/cpuinfo2cpuflags package:
> >
> > $ emerge -1v app-portage/cpuinfo2cpuflags
> > $ cpuinfo2cpuflags-x86.py
>
> A bit pedantry here: emerge should be preceded by # instead of $,
> since normally one can't install packages as a user.

As far as I'm concerned, # is a comment in shell script :P.

--
Best regards,
Michał Górny
Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-20, o godz. 10:40:17
Michał Górny <mgorny@gentoo.org> napisał(a):

> Dnia 2015-01-18, o godz. 21:44:05
> Michał Górny <mgorny@gentoo.org> napisał(a):
>
> > Hello,
> >
> > I would like to commit the following flags as cpu_flags_x86_desc.
> > The list combines global USE flags with some local USE flags I've been
> > able to find.
>
> Following your suggestions, I'm attaching three files:
>
> 1. updated cpu_flags_x86.desc, with:
>
> a. fma3/fma4 distinction,
>
> b. aes-ni renamed to aes for consistency with cpuinfo, we no longer
> have to worry about USE flag collision with other USE=aes uses,
>
> c. complete and machine-parseable listing of cpuinfo flags.
>
> 2. cpuinfo2cpuflags-x86.py script that parses cpu_flags_x86.desc
> and /proc/cpuinfo and generates a nice CPU_FLAGS_X86 value for you. We
> need to decide where to put it (scripts/?).
>
> 3. Initial text of the news item for review.

Ok, the hopefully-final text for the news item attached.

--
Best regards,
Michał Górny
Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Michał Górny posted on Fri, 23 Jan 2015 20:13:34 +0100 as excerpted:

> Dnia 2015-01-21, o godz. 00:18:50 Duncan <1i5t5.duncan@cox.net>
> napisał(a):
>
>> Michał Górny posted on Tue, 20 Jan 2015 10:40:17 +0100 [as snipped]
>>
>> So based on this preliminary news item, I decided to get ahead of the
>> game and add the use_expand to the appropriate make.conf sourced
>> file...
>
> Attaching a new version.

Thanks. The general notification and use-expand instructions look much
better now (and I like your wording FAR more than my suggested wording
=:^).

It looks like the script details are being dealt with elsewhere, so all
that remains is ...

This should be yet another minor improvement to gentoo, but it's all
those minor improvements that add up and make the gentoo experience
better over time, so really, /thanks/ for the extra work you're putting
into this. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
On Fri, 23 Jan 2015 16:45:34 -0600
Ben Kohler <bkohler@gmail.com> wrote:

>
> I think this should be in an ebuild. You mentioned that it's only
> needed ONCE, but it's needed ONCE for everytime one install gentoos,
> along the same lines as mirrorselect. A couple of years from now, do
> we want users to have to dig through several dozen old news items to
> get this tool?
>
Maybe it's better to integrate this new tool with eselect tool?
Re: Re: Review: news item and script for CPU_FLAGS_X86 [ In reply to ]
Dnia 2015-01-24, o godz. 10:27:47
Diamond <diamond@hi-net.ru> napisał(a):

> On Fri, 23 Jan 2015 16:45:34 -0600
> Ben Kohler <bkohler@gmail.com> wrote:
>
> >
> > I think this should be in an ebuild. You mentioned that it's only
> > needed ONCE, but it's needed ONCE for everytime one install gentoos,
> > along the same lines as mirrorselect. A couple of years from now, do
> > we want users to have to dig through several dozen old news items to
> > get this tool?
> >
> Maybe it's better to integrate this new tool with eselect tool?

No. It doesn't resemble eselect in any way.

--
Best regards,
Michał Górny

1 2  View All