Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On 01/23/2015 01:48 AM, Alexis Ballier wrote: On Thu, 22 Jan 2015 09:06:39 -0800 Zac Medico zmed...@gentoo.org wrote: [...] That's what I understand from Michał's comment (quoting him): 1. if you have dynamic-deps enabled, portage will want to install both ffmpeg (because of :=) and libav (because of ||). The effective deps will look like: || ( ffmpeg:0/51= libav ) ffmpeg:0/51= As I understand it, portage (correctly) marks this package for rebuild (because ffmpeg:0/51= dep isn't satisfied anymore), but I don't get why it doesn't consider the original '|| ( ffmpeg:= libav:= )' dep for the depgraph and wants to pull ffmpeg in because of :=. It does consider the original dep. However, it also uses various heuristics when making choices for || deps, and the fact that an instance of ffmpeg is currently installed is taken into account in the heuristics. good then; i'm assuming: people have ffmpeg installed and built a package 'foo' with || ( ffmpeg:= libav:= ); now, he removes ffmpeg, installs libav (put it in world), and masks ffmpeg (shouldnt be needed since it blocks libav but may hint portage solver). Yes, putting ffmpeg in package.mask is not strictly necessary, but it may help you avoid having portage try to pull in ffmpeg to satisfy a dependency at some point. what Michał claims is that 'foo' will want ffmpeg, no matter what. Maybe he's talking about some case where portage failed to trigger a rebuild when appropriate. We've had a number of bugs like this that have been fixed. The most recent recent example is bug 531656 [1]. how can it be possible if 'foo' is slatted for rebuild ? It's not possible, as long as a rebuild has be properly triggered. or maybe it is that portage does not slat it for rebuild (dynamic deps or not) ? Yeah, we may find more bugs similar to bug 531656. When we discover bugs like this, I make them block bug 300071 [2]. how can it force to install ffmpeg then ? It will only happen if portage fails to trigger a rebuild. If you have a problem like this, then I would recommend to try all of the following (starting with the least invasive): 1) emerge --deselect media-video/ffmpeg (remove from world file) 2) echo media-video/ffmpeg /etc/portage/package.mask (mask ffmpeg) 3) emerge --unmerge media-video/ffmpeg [1] https://bugs.gentoo.org/show_bug.cgi?id=531656 [2] https://bugs.gentoo.org/show_bug.cgi?id=300071 -- Thanks, Zac
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
Anthony G. Basile: On 01/23/15 00:56, Michał Górny wrote: Dnia 2015-01-23, o godz. 01:51:24 hasufell hasuf...@gentoo.org napisał(a): Regarding the last libav discussion I think we should also go with a libressl USE flag instead of creating a virtual that makes handling SUBSLOTs impossible. If libressl and openssl would have matching ABIs, that wouldn't be necessary and you could what virtual/libudev does, i.e. explicit subslot deps. *if* I'm not sure they will even though that's the plan. If you look in the libressl overlay, you'll see lots of patches to make big ticket items like apache play nice with libressl. These patches involve things like +#ifndef HAVE_SSL_CTX_USE_CERTIFICATE_CHAIN int SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int, pem_password_cb *); +#else +int _SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int, pem_password_cb *); +#endif which points to the differences in functions are being exported by the two. This makes me lean towards a USE flag which can also be tied to applying patches rather than a virtual which is better suited for simple drop in substitutions. The problem I see now is that people will have a hard time to actually switch, because unlike gnutls we cannot have openssl and libressl be installed at the same time. For people to be able to switch we'd have to add libressl USE flags everywhere, even if we don't know if it builds.
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-23, o godz. 14:26:48 Michael Orlitzky m...@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 pgpFgSPf1SrVh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-21, o godz. 00:18:50 Duncan 1i5t5.dun...@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 Title: CPU_FLAGS_X86 introduction Author: MichaÅ Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-xx Revision: 1 News-Item-Format: 1.0 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. In order not to lose CPU-specific optimizations, users will be required to update their make.conf (and package.use) file. For example, if the following USE flags were present: USE=mmx mmxext sse sse2 sse3 Those flags need to be copied into: CPU_FLAGS_X86=mmx mmxext sse sse2 sse3 Please note that CPU_FLAGS_X86 is used both on x86 and amd64 systems. When in doubt, please consult profiles/desc/cpu_flags_x86.desc. Most of the flag names match /proc/cpuinfo names, with the notable exception of SSE3 which is called 'pni' in /proc/cpuinfo (please also do not confuse it with distinct SSSE3). 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 In order to ensure safe migration and maintain compatibility with external repositories, it is recommended to preserve the old USE settings for a period of one year or until no package of interest is still using them. [1]:https://bitbucket.org/mgorny/cpuinfo2cpuflags pgp1j_jorBzmc.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-23, o godz. 16:16:25 Michael Orlitzky m...@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 m...@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 pgpDRfW7qFlfd.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
On Fri, Jan 23, 2015 at 3:18 PM, hasufell hasuf...@gentoo.org wrote: The problem I see now is that people will have a hard time to actually switch, because unlike gnutls we cannot have openssl and libressl be installed at the same time. I personally find it annoying when people fork projects, decide not to maintain ABI compatibility with the original project, and then keep filenames the same/etc such that the packages collide in their recommended configurations. I get that in the beginning everybody is just getting started and you just don't have time to do anything other than revert some annoying commits and maybe strip all the copyright notices (ducks!). However, projects should quickly decide whether they intend to remain compatible or not (I get that there are valid reasons for either depending on the circumstances), and if the latter change their filenames/etc. -- Rich
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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 pgpuVwo2M_VSu.pgp Description: PGP signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-24, o godz. 00:59:24 Andrew Savchenko birc...@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 pgp4aGVrjwc7z.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-23, o godz. 17:27:16 Michael Orlitzky m...@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 pgpKaJdGqdNTc.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
On Fri, Jan 23, 2015 at 3:16 PM, Michael Orlitzky m...@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 m...@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: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND
On Wed, 21 Jan 2015 01:13:08 + (UTC) Duncan wrote: Andrew Savchenko posted on Tue, 20 Jan 2015 23:59:23 +0300 as excerpted: On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote: On January 20, 2015 12:47:03 AM PST, Alexis Ballier aball...@gentoo.org wrote: So, you're telling me that if you have a list of 90 cpu extensions, you will from time to time open that list to see if there is a 91st one added ? I think most people won't even notice, at best they'll look for the changelog. No, actually, I’m advocating the exact opposite. I’m saying that, as long as the list file is kept up to date, then I will look at those 90 flags when I first install and never again. If a 91st flag appears some day, then as long as the file was maintained as I described in an earlier message (i.e. flags are added as soon as manufacturers announce features), I already know I can reliably ignore the new flag. After all, if the flag didn’t exist when I installed the system, then my CPU must necessarily not have that feature—unless CPUs are in the habit of sprouting new instructions after you buy them! Not exactly. CPUs are not in a habit, but software is. Some brand new instuction set may be supported in (any of) packages with some delay. Thus it is possible that instruction set supported by your CPU will appear in the list of cpu flags after your ininial install. PMFJI... chead's idea is (I believe) simply to have the description file updated with all current hardware feature flags as soon as they are known (he said announced, but sometimes they change between announcement and actually appearing in hardware, so known, as in known to actually appear in hardware, would seem to be better). That way, no matter what the software supported at the time and what flags were thus actually used in packages, when someone first installs gentoo on a new machine, or when they first upgrade their CPU to something with new features, they can run the script and update their use_expand to match their hardware _ONCE_, without worrying about whether or when a package with support for it might appear. If no package with that support ever appears, no harm done, that entry in the use_expand is simply never used. OTOH when some package /does/ get support for new hardware instructions and adds the appropriate flag, it'll appear in portage's output, but because the use_expand was already set when gentoo was installed or the cpu upgraded, the user won't have to worry about needing to look it up and decide whether to set it, again, it'll already be done, back when the _hardware_ changed, _not_ sometime later, when the _software_ changed to support the new hardware. Of course if the user upgrades hardware after a package supports a feature, they'll have to upgrade their use_expand setting appropriately or miss support for the new instructions, but that's always the case. Just if handled as chead suggests, it'd be the case ONLY when the hardware is updated, instead of every time a package upgrades its own support. Correct, chead? Does that make things clearer, aballier and bircoph? Yeah, thanks. I misunderstood original intention. It's all clear now. Best regards, Andrew Savchenko pgp3WmXtTRs_U.pgp Description: PGP signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
On Fri, 23 Jan 2015 16:16:25 -0500 Michael Orlitzky m...@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 m...@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: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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 pgpC4a32XOt0t.pgp Description: PGP signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
On 01/23/2015 03:22 PM, Michał Górny wrote: Dnia 2015-01-23, o godz. 14:26:48 Michael Orlitzky m...@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: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
On Fri, Jan 23, 2015 at 4:38 PM, Michał Górny mgo...@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: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-23, o godz. 17:56:49 Michael Orlitzky m...@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 Title: CPU_FLAGS_X86 introduction Author: MichaÅ Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-xx Revision: 1 News-Item-Format: 1.0 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. In order not to lose CPU-specific optimizations, users will be required to update their make.conf (and package.use) file. For example, if the following USE flags were present: USE=mmx mmxext sse sse2 sse3 Those flags need to be copied into: CPU_FLAGS_X86=mmx mmxext sse sse2 sse3 Please note that CPU_FLAGS_X86 is used both on x86 and amd64 systems. When in doubt, please consult profiles/desc/cpu_flags_x86.desc. Most of the flag names match /proc/cpuinfo names, with the notable exception of SSE3 which is called 'pni' in /proc/cpuinfo (please also do not confuse it with distinct SSSE3). 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 In order to ensure safe migration and maintain compatibility with external repositories, it is recommended to preserve the old USE settings for a period of one year or until no package of interest is still using them. pgpWKv40QLbwE.pgp Description: OpenPGP digital signature
[gentoo-dev] Review: USE=libav news item
Hi, Attaching the news item for planned USE=libav introduction. The emphasis on letting users know that they may need to set USE=-libav to get their systems back in working condition. I hope that we've finally agreed on going for variant 1. I was trying to come up with a hybrid possibly-friendly variant but any variant that assumes that more than one flag can enable ffmpeg/libav support is pretty much borked because second-level reverse dependencies need to be able to somehow depend on dev-foo/bar:=[ffmpeg]. -- Best regards, Michał Górny Title: USE=libav introduction Author: MichaÅ Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-yy Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav The support for automatic choice between ffmpeg and libav is going to be deprecated in favor of explicit choice via USE flags. This change aims to solve multiple repeating issues, including Portage undesirably wanting to replace one package with the other, subslot upgrade issues and some of the hard-to-understand blocker issues. The current USE=ffmpeg will maintain its role of enabling optional support for ffmpeg or a compatible implementation (libav) in a package. However, whenever appropriate additional USE=libav will be introduced to control the preference of libav over ffmpeg. Users who currently use libav (the Gentoo default) do not have to perform any action since USE=libav is enabled by default. It should be noted that those users will need to enable USE=ffmpeg on packages with optional libav support as well. Users who want to use the ffmpeg fork instead need to specify USE=-libav explicitly. Please also note that some packages support only one of the two implementations. An attempt to install one of those packages will result in blockers unless the user changes the global USE=libav state. The most notable example of such package is media-video/mplayer which relies on deprecated APIs available only in ffmpeg. media-video/mplayer2 or media-video/mpv may be used as a more modern replacement. pgpcN53T2O2e5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-24, o godz. 02:29:26 Andrew Savchenko birc...@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 pgpNUsNtIBYYf.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Review: news item and script for CPU_FLAGS_X86
Dnia 2015-01-20, o godz. 10:40:17 Michał Górny mgo...@gentoo.org napisał(a): Dnia 2015-01-18, o godz. 21:44:05 Michał Górny mgo...@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 Title: CPU_FLAGS_X86 introduction Author: MichaÅ Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-01-xx Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: amd64 ~amd64 x86 ~x86 The USE flags corresponding to the instruction sets and other features specific to the x86 architecture are being moved into a separate USE flag group called CPU_FLAGS_X86. In order not to lose CPU-specific optimizations, users will be required to update their make.conf (and package.use) file. For example, if the following USE flags were present: USE=mmx mmxext sse sse2 sse3 Those flags need to be copied into: CPU_FLAGS_X86=mmx mmxext sse sse2 sse3 Please note that the CPU_FLAGS_X86 variable is used both on x86 and amd64 systems. When in doubt, please consult the profiles/desc/cpu_flags_x86.desc file available in the Gentoo repository checkout. Most of the flag names match /proc/cpuinfo names, with the notable exception of SSE3 which is called 'pni' in /proc/cpuinfo (please also do not confuse it with distinct SSSE3). To help users enable the correct USE flags, we are providing a Python script that generates the correct value using /proc/cpuinfo. It can be found in the app-portage/cpuinfo2cpuflags package: $ emerge -1v app-portage/cpuinfo2cpuflags $ cpuinfo2cpuflags-x86.py In order to ensure safe migration and maintain compatibility with external repositories, it is recommended to preserve the old USE settings for a period of one year or until no package of interest is still using them. pgp0bEvHez0mM.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
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.dun...@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: [gentoo-dev] Re: Review: news item and script for CPU_FLAGS_X86
On Fri, 23 Jan 2015 16:45:34 -0600 Ben Kohler bkoh...@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: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
But they don't. See my two blog posts on the matter. ABI compatibility is explicitly not. What they care about. On 23 Jan 2015 05:56, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-23, o godz. 01:51:24 hasufell hasuf...@gentoo.org napisał(a): Regarding the last libav discussion I think we should also go with a libressl USE flag instead of creating a virtual that makes handling SUBSLOTs impossible. If libressl and openssl would have matching ABIs, that wouldn't be necessary and you could what virtual/libudev does, i.e. explicit subslot deps. -- Best regards, Michał Górny
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Thu, 22 Jan 2015 09:06:39 -0800 Zac Medico zmed...@gentoo.org wrote: [...] That's what I understand from Michał's comment (quoting him): 1. if you have dynamic-deps enabled, portage will want to install both ffmpeg (because of :=) and libav (because of ||). The effective deps will look like: || ( ffmpeg:0/51= libav ) ffmpeg:0/51= As I understand it, portage (correctly) marks this package for rebuild (because ffmpeg:0/51= dep isn't satisfied anymore), but I don't get why it doesn't consider the original '|| ( ffmpeg:= libav:= )' dep for the depgraph and wants to pull ffmpeg in because of :=. It does consider the original dep. However, it also uses various heuristics when making choices for || deps, and the fact that an instance of ffmpeg is currently installed is taken into account in the heuristics. good then; i'm assuming: people have ffmpeg installed and built a package 'foo' with || ( ffmpeg:= libav:= ); now, he removes ffmpeg, installs libav (put it in world), and masks ffmpeg (shouldnt be needed since it blocks libav but may hint portage solver). what Michał claims is that 'foo' will want ffmpeg, no matter what. how can it be possible if 'foo' is slatted for rebuild ? or maybe it is that portage does not slat it for rebuild (dynamic deps or not) ? how can it force to install ffmpeg then ? Alexis.
Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl
On 01/23/15 00:56, Michał Górny wrote: Dnia 2015-01-23, o godz. 01:51:24 hasufell hasuf...@gentoo.org napisał(a): Regarding the last libav discussion I think we should also go with a libressl USE flag instead of creating a virtual that makes handling SUBSLOTs impossible. If libressl and openssl would have matching ABIs, that wouldn't be necessary and you could what virtual/libudev does, i.e. explicit subslot deps. *if* I'm not sure they will even though that's the plan. If you look in the libressl overlay, you'll see lots of patches to make big ticket items like apache play nice with libressl. These patches involve things like +#ifndef HAVE_SSL_CTX_USE_CERTIFICATE_CHAIN int SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int, pem_password_cb *); +#else +int _SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int, pem_password_cb *); +#endif which points to the differences in functions are being exported by the two. This makes me lean towards a USE flag which can also be tied to applying patches rather than a virtual which is better suited for simple drop in substitutions. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
