Re: [gentoo-dev] Naming of repositories: gento-x86 edition, bike shedding wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 14 Mar 2015 22:25:56 + Robin H. Johnson robb...@gentoo.org wrote: Questions: 0. What names for the tree/repository. git://anongit.gentoo.org/portage-tree.git ? 1. afaik everyone is calling it this way already anyway. 2. Since it is hosted directly on gentoo.org/ there should be no need to further qualify it's The portage tree. - -- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJVCrPZAAoJEIN+7RD5ejahX9sH/iZ89zzs+/9AMtQJAeF1vVOK QehdJzsdysM8TqI3kzpoHvFkFw8IXp54pnckcPyiNwJFjsMFP4R+uOGqoYskaCnm SCX3ovm/sgHY6tscCEfaqFtrzRK/Nt0ESG7Gyz+RVtBU75CcZT0YviCB2MBOYdag d7hONjPhOK0i6dHeocf1321Oi40P2XPqU2wepKpLhc8zcAGczDdYisDUcFwWH/m2 fVizZZmpJYdu6ecNCHNYOm/D+BY37BsHeoHzDC+0Tt/F7IseDQZFmy6Xbgm4fHf+ dkjTBl5N8zF/sdOiuXxPJBr/g/yZ0rrOJWolG5ZZeObUra+TpAUmH4R/y6QZLx4= =CUHS -END PGP SIGNATURE-
Re: [gentoo-dev] Regarding my final year thesis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 16 Jan 2015 21:00:24 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 16/01/15 18:30, Jan Matejka wrote: On Fri, 07 Nov 2014 10:49:13 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 07/11/14 06:06, Harsh Bhatt wrote: Also make might enjoy improvements. shake? Anything written in haskell tend to be impractical to deploy. http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf tup managed to get lots of great ideas spoiled by being impractically extremist in tracking the directory changes. I don't know what tup is but I'm guessing it's an application. Are you judging a language to be impractical because one application made (allegedly) a bad design decision? - -- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJUz7MtAAoJEIN+7RD5ejahmuoH/1CYfKRdrgtcms2U1Rcio2HQ oJsDY+5SZerGSJrnnohd7l/FHbxcA51H04IUws22GlJ7OnIlVRD/IuYlAyLogc9m bvg/Tt/OuRavHqdhi5JmJfQqYUVZJiEBQok5jG9Aa6+0+d1rPYzUQFsbNQ4ywO12 LLdVATR/2ovrEgVNmgUJQlfeZy6Axo3MwHbBRjsoi+2eKlSVBwKmAQMvpifLr5bI 8l2hOa7CGis02uWa8t8JixZ3XSkqrcjExGQYcBbWdCYVulfXgUbz0pNkQipOCOh+ +bNzubNDOGMSyiJ1mmtRG46vEKhgefns+IvxEhiOIIeJajPJR+R3EU0cV2LAvD0= =+ORA -END PGP SIGNATURE-
Re: [gentoo-dev] Regarding my final year thesis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 07 Nov 2014 10:49:13 +0100 Luca Barbato lu_z...@gentoo.org wrote: On 07/11/14 06:06, Harsh Bhatt wrote: Also make might enjoy improvements. shake? - -- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJUuUqnAAoJEIN+7RD5ejahNwMH/R2OruTRy0yi4cwKFhPGqVZv SKVLp5jNGkY9pTFnMApuqqh53Tb4OW3uDO99wpkzpyzzr0wgarGFg1N6YAMkRf+g 3Vy+WvDrK6zQeu0IYq1VBMODSun6fgWUsNiEBgqYbDPqa/SmfTAGhIF3dt5HH6Gx J6T2SVFjjPFN+6LtWxVHph3G6/zSvKlHXKevqr4Po7PqnMXDnDBJ24LreNPVV0Aw 9G2lzT8/yuIvTF1x8FMinqOAWlp3CXYcfhizdYaFmMb7ROGZZFZJISx4L4GhkEK+ ojW457sX20Payc3GnY0O6yT29FDAf+1HQEhpEW2WEQ2hdP1lovtAiq+qyJnubrA= =lB3d -END PGP SIGNATURE-
Re: [gentoo-dev] don't rely on dynamic deps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 23 Jul 2014 00:05:32 +0200 Tom Wijsman tom...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 21 Jul 2014 16:41:39 -0400 Ian Stakenvicius a...@gentoo.org wrote: I wonder if there may be some form of extension we could add to portage, such that it could do a VDB-only re-emerge somehow, when the in-tree ebuild doesn't match the in-VDB one. If that could be implemented properly (and i'm not sure that it could, tbh), maybe that would help reduce issues with dynamic deps, too... Hmm, dynamic dependencies ... dynamic rebuilds ... dynamic compilation; one day we will have hot code pushes where upstream changes immediately reflects itself upon one's system. Does such a gimmick succeed? Meteor! https://en.wikipedia.org/wiki/KGraft - -- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJT/gT1AAoJEIN+7RD5ejahISgIAKbVgqLmuJADmJ37TddtmPPP 7WPq5UYdGT4wq9rElrU3GCu10u+pxQqOOKzVjnXiSlcCF1xqkG07caaYO/Xw/ccS VclMPDngRU7YUSl9F6UeDkDK9l+48qE/1/ohrSL9f8giA5H5SZ3G3fanWN/oFp6W FsGx7J6ddRmM/LaSHrso4ngbMU7XIMFZgUeR5X3t5bWef/Si9adxJzfbMoCQFUDN 7qXT8EkY9U9Po5/aAqtsriyGWZttuIvjGbmiNdrdJI/IT/Rshlqzqy/viqcK2aOX bCO1dn5wRLxfV7JBgmg14UJqcDK6HgkSkl4rrl574M4arq7kZtbMEKbSvDcpurw= =Wphr -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Changes in installed ebuilds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 24 Jun 2014 21:25:40 +0200
Jörg Schaible joerg.schai...@gmx.de wrote:
Alexandre Rostovtsev wrote:
On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote:
So, why the heck, was the dependency to dev-libs/glib changed for
an existing ebuild without increasing its version (e.g.
dbus-glib-0.100.2-r2)?
Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615
These blocks had nothing to do with the multilibs ABI. It has been
just the updated versions for the dependencies.
I have to use an older Eclipse 3.8.x version for my daily work and
since it is broken with latest gtk versions (a lot of crashes), I
use still some old ebuilds and have masked new ones.
Please file a bug report about this. If nobody tells us that a new
gtk+ version broke something important, we will soon mark the new
version as stable and then remove the old version.
My understanding the problematic change is:
- -CDEPEND==dev-libs/expat-2[${MULTILIB_USEDEP}]
- - =dev-libs/glib-2.26:2[${MULTILIB_USEDEP}]
- - =sys-apps/dbus-1.6.2[${MULTILIB_USEDEP}]
+CDEPEND==dev-libs/expat-2.1.0-r3[${MULTILIB_USEDEP}]
+ =dev-libs/glib-2.38.2-r1:2[${MULTILIB_USEDEP}]
+ =sys-apps/dbus-1.6.18-r1[${MULTILIB_USEDEP}]
given that only micro version was bumped for dbus and while glib
changes minor version, it's the same slot. Therefore my understanding
is the resulting libraries should not break API/ABI and therefore there
shouldn't be an issue.
In that case I think revbump is not warranted since it should continue
to work for existing installation and new installations shouldn't be
any different beside the dependency and not revbumping eliminates some
needless rebuilts.
And that seems to be the case since you say it's actually problem in
eclipse …
I report anything, if it is worth it. However, in this case the
problem is on Eclipse's side and fixed in newer versions. Alas, it
does not help me, because I have to use that old version for my daily
work. So, there's no blame on Gentoo and nothing the devs should have
to waste their time.
Therefore I still use the once stable versions of GTK (~5 months old
now), where this old version of Eclipse runs, i.e. I already
preserved some older versions locally that are already vanished from
the portage tree. The newer ones are hard masked.
However, if some of my currently installed stable packages suddenly
require newer versions, my portage tree gets in serious trouble.
Nothing would have happen if the revision number of the affected
packages had been simply increased.
I guess you could fork the needed packages (you can always get older
versions from cvs) into your custom overlay for old eclipse and maintain
them there under some slot.
Caveat Emptor: I'm not particulary experienced with neither API/ABI
changes and slotting so I don't know how accurate this information is.
- --
Jan Matějka| Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCgAGBQJTqqNfAAoJEIN+7RD5ejah2J4H/0QOC7K1CYzF91HNbP6T3S/v
pl2vRF9JvOg5+SS/GzO7gqu8YPIF/GaViXPTWps7Ab6SqT0ARf3IPA0v6NCXymqf
vSUKMZDOVtBGq5mUjhiBTFZYFLtp0Nnj0lgv8ysv40ObzKvaT/Af7xGz67zm83pl
v0nr0gArH4oVVXFZg9w/22cw+0jLEaagLwS2SbgHsVgOfPBWHrIEMM46lk+DyEq6
wq1RMgMrFQ+QXHdO4zKM0+xLGahL3So05j7xlKmg4jIKlnlxXalYn3WY/ebrSoR3
uSuerahzlDo+qKR31Rldc/piurah7KnNoJSFa+Yny7upcueb0aWHbcPcZ9Js35o=
=ULrp
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 24 Mar 2014 15:25:12 +0100 Jeroen Roovers j...@gentoo.org wrote: On Mon, 24 Mar 2014 12:36:19 +0100 Jan Matejka y...@gentoo.org wrote: Categories are essentially tags, only less powerful as they can express relationship of 1:N while tags are can express M:N No, categories are essentially directories. fixed: categories are essentially also directories. same thing, 1:N relationship without symlinks and other misuse of filesystem. I was asking about tags, not about categories. The original mails are: On Sun, 23 Mar 2014 15:46:09 +0100 Jeroen Roovers j...@gentoo.org wrote: On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner anta...@gentoo.org wrote: https://wiki.gentoo.org/wiki/Package_Tags This GLEP author would love to blight categories out of gentoo history as a giant mistake. Why? jer Categories are essentially tags, only less powerful as they can express relationship of 1:N while tags are can express M:N How is this a question about tags and not categories? It appears it's very hard to answer the simple questions of why we need tags and how we would use them. The answers should typically involve some explanation of how you're going to use the things once you have them. jer - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJTMSouAAoJEIN+7RD5ejaho4AH/1YFbArFwx6t8OoI8yrWCulA LDt5qBAcZiJoqV9H1V5YdNgcNiLDKIyTCPbkWc4obkgRuNVIJxFAe+duYRQydudW 6KKS2lYQXWSkbDRmJTWOt7BnerHyemvk6AluQn741a2uPZyUI//FPQL8fZkYlR6i 3HFFlW0dI6PHa/9Np8G+RBAs29e8qAR7QKQzDLd9BF/s+6KIK2/FO8pAgMdZBVKk jJ4Aq1AuRsqrdY0HO940Boiy0ylBFjxB27ej59UmjAzvyOMj9YRf1LqNkgMABENu ohEckguSryOpBjjD2ZaZrfMbbJTGqfVgz44nhT0s6Nbocb5RmVYp988GIwFQCg4= =1uIP -END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 24 Mar 2014 09:32:40 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: Who is going to approve/disapprove tagable attributes and the tags themselves? How will you resolve disagreements people have? Sounds like a job for QA What about the case of a package maintainer that simply can't be bothered doing tags at all? I'm not against tagging per se, they can be useful. But they do have to be strictly controlled otherwise things get out of hand very quickly. Every case I've seen of software that uses a freeform tagging mechanism fails almost instantly as it becomes very inconsistent. I have one of these apps in a corporate setting right now, have you any idea how many ways people can come up with to tag the concept of cloud? Some of these could probably be detected by meeting a treshold in Levenshtein distance (or some variant of) and making a suggestion to consider found alternative before doing the commit - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJTMS9uAAoJEIN+7RD5ejah5bIH/i6dERPVS2i/rd76HQRHjynr w7C4N5OQi+cN339f2/JusPwxrfBrUiN7ulsgWACMPz4s8/ZA9yrsRRnqvC2P8bnR 25n94z0vUZa3K5V3MIuDugfKa6nwVY9gZHZj6BP8KNnl84ETasxpG5lR3XTqs0az 4pJG18rbwtk22+7q38hXQv9/vRfAZH3Lx5ilG1+F0+I39miXW6ylsS37ovkdrQ97 rUvNasT+5GcB6jd3tXDQuOJs8UgGuBNgTjzZfrk5Y+6+Dqj2oL5ERRONOS6UN5RB TYGw9KI1Rj7pRWE1gIi/fhoXbugj0DZArRC8fA3D2NEyYFIStopjI0hI3bXljFs= =Z9+y -END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 23 Mar 2014 17:40:20 -0400 Joshua Kinard ku...@gentoo.org wrote: TBH, I don't like the use of XML at all. No, we don't need to go one level (format) deeper. The 'all' thing is probably unnecessary What problem does having 'all' tag solve? Seems pretty useless to me. Granted, a tag of dev offers no value (dev-python - 'dev','python'), but if you were looking for a web browser versus a web server, having default tags of 'www','client' or 'www','servers' helps for packages in www-client and www-servers. This might be helpful but rather as one-time, initial, hand-picked generation on case-by-case (by the category) basis. I've always wondered is we allowed portage to have one additional level of nesting if that'd help any (i.e., games-* - games/*). Squashing games-*/ to just games/ and defining genre by tags. Seems pretty doable, I like this. - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJTMTZeAAoJEIN+7RD5ejah85gIAItDtxuEntu2nhb4uvltKHfu dpnT0KePuAZKwV8H59jRx7AovfMo9nTjqs88Sgw6v9NbbKNxRmW3PPWmuJUnLniU eG31vMsUJ1CgXxNLWaXaYZRi1QTYnJqJM5LDnfFsh4mj9Dk7t1/XCA6rKcICO3qQ sqEDaSAyOYLBsTGPOyC2trrZNAsLEu2oLImzECXNHa6tNMJt75BJdGfKzFDTGBtF XiG/qi2IV7ClYxVZP4W1LwN+SVUmLiEDUyMeP6FRgVdEmZcdlQGLm6kBiYD0A/2F xeWHPoQpgkPRZuLRNv0vvvatO+A2KpXY1rs0s3BYb0xk3MDEGwE+X1ZrcDRVsIg= =5YXb -END PGP SIGNATURE-
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner anta...@gentoo.org wrote: https://wiki.gentoo.org/wiki/Package_Tags Object or forever hold your peace. Or argue for 100 posts, either way. -A It might be worthwile to prototype this functionality as an external service. 1. It should be easier to crowdsource the tags definitions, assignments and QA and therefore helps to build consistent database faster and easier. 2. decouples tagging from maintaining a package, therefore makes more community driven and prevents THAT'S MY PACKAGE, DON'T TOUCH IT YOU SCHMUCK type of quarrel. 3. Classic prototyping benefit - might identify problematic areas for implementation. The downside is the implementation might be more time consuming depending on architecture. Mostly due to 1. I guess but that could be handled by using git and pull requests for crowdsource and then the implementation should be basicly no different from using portage itself, besides using different VCS. - -- Jan Matějka| Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJTMTicAAoJEIN+7RD5ejahIlsH/1UmMa1P+QBEZ/HpfOPX1d4Z S0nYho8vinPQVenOXMY/0KVvh4bzhmrTZWm4itLVB/5taI88m5fzQbvYSNlEn+Nn zRTcmyuze+3mmDf3++mfzzjmByYLiYJwCdhNF7HH4V04Ph/aEQbjO++9EL37bW/J uCYs8b0Vtn97utW2mJcUa7Wbgluo6jhCDHW8yGuZW4JfCo6bRQfqqlxGGGufIXK9 N8FX01Kbt2HFqgwdK7uZIfn0Gh9xGkIL2Jk2WCFzUHjZgJTy0UuPGeUSCOsTt7wg CcETDWrzscuydtdhZaFmtZ3Xs7eQ7I98nwEdlkSdgbsfQFYQlPvomCGZyGehtTo= =ykWo -END PGP SIGNATURE-
Re: [gentoo-dev] dev-lang/go
On Thu, 13 Feb 2014 11:59:16 -0600
William Hubbs willi...@gentoo.org wrote:
Hi all,
I responded to this a while back, but I guess my email didn't go out
for some reason.
As the primary go maintainer, I do want to be involved in this. :-)
On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway em...@vfemail.net wrote:
I really like working with Go, and would like to see a means of
merging Go packages with Portage. In short I am asking if anyone
else is interested in a Go project.
I might be. I have packaged something for private use but it just a
bunch of hacks. Anyway, I have some production go code.
For those who aren't familiar with Go, I will sumarise why
Portage and Go do not play well together.
Go is static linked by default.
The Go compiler creates static libraries and binaries. Libraries
compilied with different versions of Go (1.1/1.2) may not be
linked into the same binary.
Haskell is staticaly linked as well (by default) and you can see the
gentoo haskell project. I don't see this as a problem, we just will
have all dependencies in DEPEND and will have to scope on the go
compiler version under something like /usr/lib/go-1.{1,2}/...
That could be done easily enough, but what about the tools in /usr/bin
(there aren't many, but there are a couple), and these do not change
name with each version of go.
Please see what python does for different python versions (which you
omitted from my previous email).
Go libraries are usually unversioned.
Libraries outside the system library are resolved with an import
statement that specifies a source code repository, such as a git
or mecurial repository. Most often Go libraries are installed
using the 'go get' tool that clones a repository, and simply
assumes HEAD/tip is the best revision to build against. There is
some support for using git tags but it is not well documented.
Often these libraries are very small for the sake of reuse and to
keep APIs simple.
My understanding is that a library repo will have branches based on
the version of go, so for example, it might have a branch called go-1
which will be where go get will look to find the latest version of
the code that works with go-1.x.
In this case we just have to require upstream to make releases or
publish either live ebuilds, or ebuilds versioned something like
0_pre-MM-DD.ebuild [1]
I don't think we are going to be able to require upstream to make
releases, so that leaves us with:
1) using live ebuilds, which will never be allowed to have keywords by
gentoo policy, or
2) publishing snapshots, which also means we have to create tarballs
to match them. This will be a lot of work for us as maintainers.
Also, the only way we will know when a new version of the library
is released is to closely monitor the upstream git repository.
As I said in previous email, I think at least part of go community sees
this as an issue and this is something we can not solve right now but
rather need to work on this on case-by-case basis.
Some upstreams may be willing to do releases / follow semver.org or
something like that. But there will also be upstream which won't and
that's fine, we should be able to handle both cases.
Anyway, asking the upstream to do a release is simple enough and you
won't know until you ask.
The other concern, which I believe zero was talking about is, once a
library is installed in GOPATH, I don't think the go build system
rebuilds it. In other words, go get will see that it is already
there and I don't think it goes back out to the net to check for any
changes.
I think when doing a `go build` it will check if newer version is
available and print a warning.
William
--
Jan Matějka| Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B
signature.asc
Description: PGP signature
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 What's the point of having nonempty XDG_ variables in ebuilds? Use of these variables is scoped to user applications that use these in runtime, therefore I see no business for them in package (de)installation and it should be ok for portage to unset the variables and if application is using these during build/install (in system context) it's a problem with the application. - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJS6MKtAAoJEIN+7RD5ejah6GsH+wcuWYyl3Ki3J/U0KT8QTrOx s5mixaNjrZ6sveU/3dUtCvKz/l9ZyR4YmKcQ8/Syv/UmoGQRdwYs+AgFsmfPPx6Z N46KK0pg6KAgVpHjJtJ1ZAbKO0tu39dz7c+GimnUYTqjUdrNtSHu4AUiaEQKCBft DTzD68LGE7lthoXtz1Y5OPjD/U0PXpOowcLo98RSgQnGOggdjBxPNBE05WWVWxM6 9XIKFNdca9sFGBuJQwoXiPNTXxnzizTXnukUgzvuctMg5uPPq2hfKVyktCilslGA X+JHZ2jT5bzJgeHbJK+6zEoPfjgxrY4fVg2DmLfUmnt7gP8N3wU/6MKILt7CpdM= =aSXC -END PGP SIGNATURE-
Re: [gentoo-dev] New global use flags: 3dnowext, mmxext, ssse3, sse4_1, avx, avx2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 15 Dec 2013 15:34:13 -0800 Matt Turner matts...@gentoo.org wrote: And at the same time, clean up the descriptions of the other flags. The existing descriptions were clearly copy-and-pasted and contained things like faster floating point optimization for SSSE3 capable chips when SSSE3 didn't add any floating point instructions. 3dnow: Use the 3DNow! instruction set 3dnowext: Use the Enhanced 3DNow! instruction set mmx: Use the MMX instruction set mmxext: Use the Extended MMX instruction set (intersection of Enhanced 3DNow! and SSE instruction sets) (3dnowext or sse in cpuinfo) sse: Use the SSE instruction set sse2: Use the SSE2 instruction set sse3: Use the SSE3 instruction set (pni in cpuinfo) ssse3: Use the SSSE3 instruction set sse4_1: Use the SSE 4.1 instruction set avx: Use the AVX instruction set avx2: Use the AVX2 instruction set I'll make these changes in a few days. We don't seem to have a use of an sse4_2 USE flag anywhere yet, notably. Unfortunately we do have two uses of sse4, which should be corrected to be more specific: media-libs/freeverb3 net-misc/bfgminer Is it possible to make this in a way so all the instruction set use flags can be read from the use.desc by some simple epression? Like 1. is prefix/postfix for Instruction Set or 2. include the \sinstruction set\s in the description? or 3. have them listed in special file for that or 4. whatever we can agree on is the proper way. I'm asking because https://github.com/yaccz/cufd - -- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJSsuKDAAoJEIN+7RD5ejahBlkH+wRiFLAzxazKQ9a/jdpYOeJr j4uY8Q9iAu/4xK3QMXscosaShrz5bW/XGAxRvfT0pqAe8APUrQTw5V+0cFX/yVJ1 2FQBSPgGXPKyq/AQQ6kPlwsQaCVaYxcWA5bOv+dxfVsEcSMYSQsGeX1BdK2S7wHN h6upIw3qFWln75TLUcO52PHR9YNgWTYZvqJWmaLJDDXBDzcuJAVmLJLtf+ketiCK SjNxZlUQpKQzgszb3dTUPeMSbpPuiCNRG9JFG/q8eXlrfLt9qygJvYpFn7OKmEem 8Bmc1LeERhDEvxCb+xAJDFF4UTHNOpj5H57EMmuakiIrEd4f+xMUK4lJtvRTpbU= =25vk -END PGP SIGNATURE-
