Re: [gentoo-dev] Re: useflag policies
On Wed, Aug 12, 2015 at 09:40:00AM -0400, Michael Orlitzky wrote: On 08/12/2015 12:21 AM, Ciaran McCreesh wrote: On Tue, 11 Aug 2015 23:30:31 +1000 Michael Palimaka kensing...@gentoo.org wrote: I invite you to reproduce the problem yourself then make the judgement. Using REQUIRED_USE like this makes the affected packages unusable. Can't we all (except for the usual suspect) just agree that REQUIRED_USE was a mistake, and go back to pkg_pretend? The only justification for REQUIRED_USE was that it could allegedly be used in an automated fashion, and this hasn't happened. I'm starting to see the light. USE flags and their combinations/conflicts are almost always package- if not ebuild-specific. The problem isn't that REQUIRED_USE forces me to do something, it's that portage will only ever be able to output 45 pages of garbage rather than telling me how to fix it (which again, depends on the package/ebuild). At the very least, we need to be able to tag REQUIRED_USE conflicts with human readable error messages. OK, so I know I can't have USE=qt4 qt5 for this package... but why? How do I fix it? We can do that with pkg_pretend and a bunch of if statements, or maybe there's value in having the requirements in a variable -- who knows. The former is a lot simpler to implement. I always wondered why pkg_pretend never caught on. I to can see the advantage of it over REQUIRED_USE; it would allow the package maintainer to give specific error messages about why use flag combinations are invalid for a package. Without really knowing what the opposing viewpoint is, I think pkg_pretend is the better way to go as well. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015, Alexis Ballier wrote: i.e. something that really tells the PM how to automate the choice: - 'qt5 - !qt4' is rather straightforward to solve and tells the PM how (note that it is not equivalent to 'qt4 - !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to automate it I was thinking about some syntax like this: REQUIRED_USE=|| ( +foo bar ) ^^ ( +qt5 -qt4 ) The package manager would first evaluate each group in REQUIRED_USE with the original set of USE flags. If that doesn't evaluate to true, retry with flags changed as indicated by the + and - signs. Ulrich pgptPvjWEli86.pgp Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 09:40 AM, Michael Orlitzky wrote: At the very least, we need to be able to tag REQUIRED_USE conflicts with human readable error messages. OK, so I know I can't have USE=qt4 qt5 for this package... but why? How do I fix it? We can do that with pkg_pretend and a bunch of if statements, or maybe there's value in having the requirements in a variable -- who knows. The former is a lot simpler to implement. I still think it's really important to note the meaning of Can't here. Can't IMO should still really mean cannot -- that setting both flags is going to cause a problem that'll break the system, conflicts that will cause things to not work. This whole qt4/qt5 discussion isn't about can't, but about doesn't. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXLWoAACgkQAJxUfCtlWe2GAwD/dgkq8Iyd4njMd2tAvO8zWVOr JddKwKnUxMxT4haGYDYBAIxIQbT5BM3+iHkNWXF8nKm6GXukNKqUODhZl3eNRoUi =kAZd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 11:08 AM, Ulrich Mueller wrote: On Wed, 12 Aug 2015, Alexis Ballier wrote: i.e. something that really tells the PM how to automate the choice: - 'qt5 - !qt4' is rather straightforward to solve and tells the PM how (note that it is not equivalent to 'qt4 - !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to automate it I was thinking about some syntax like this: REQUIRED_USE=|| ( +foo bar ) ^^ ( +qt5 -qt4 ) The package manager would first evaluate each group in REQUIRED_USE with the original set of USE flags. If that doesn't evaluate to true, retry with flags changed as indicated by the + and - signs. Ulrich Having the ability for REQUIRED_USE to provide a default resolution path should definitely help with things; I assume this is meant to do its work via --autounmask-write or similar, ie to help users adjust their config files? Or was the thought to allow PMs to override USE immediately? Questions: 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE? 2 - is there a particular reasoning for the - in front of qt4 here? I only ask because it would seem that a single default-enable should suffice in lists like this to indicate a resolution path, no? That is, '^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like it would be the same as '^^ ( +flag1 flag2 flag3 flag4 )' 3 - will having REQUIRED_USE be able to force flags on (and others off) likely result in abuse of profiles and other use defaults? I forsee this being a way, for instance, for a dev to get around users setting USE=-* in make.conf to ensure a default use flag setting is honoured. 4 - Will a change to which flag the '+' is on likely to require a revbump for VDB updates? For something like '^^ ( +qt4 qt5 )' I could see maintainers wanting to switch which flag is default across a bunch of packages at once when, say, the qt team wants qt5 to become the de-facto default. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXLZp8ACgkQAJxUfCtlWe0NcgEAzt6FjitYEyk6h2HufX4WiKko tldpUk71Wnj+y5ejB38A/R23oq0E4PakpXg5ML8pqG8gPnyXJmIN8Fuh6Gj1Y+6Y =UaQK -END PGP SIGNATURE-
Re: [gentoo-dev] .gitignore
On 13/08/2015 00:21, James Le Cuirot wrote: On Thu, 13 Aug 2015 00:11:45 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 12/08/2015 23:29, James Le Cuirot wrote: Mike Frysinger vapier at gentoo.org writes: On 10 Aug 2015 09:17, Michał Górny wrote: Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): On 10 Aug 2015 08:28, Justin (jlec) wrote: I like to propose to add the md5-cache into it. Which other files are of interest? /distfiles/ /local/ /packages/ Those directories should not be ignored. Those should not exist for a long time. there's no reason people can't use these on their own system. there's no reason they should be added to the git repo which means, if a user opted to utilize them, they should be ignored. I agree and I'm not sure what mgorny is basing his statement on anyway. Apart from /local/, which I forget the purpose of, the default locations for DISTDIR and PKGDIR still seem to be /usr/portage/distfiles and /usr/portage/packages. I must admit that I'm struggling to find the logic for this in Portage but those are the defaults nonetheless. So why would they not exist? I'm certainly using them here and I would like to see them in .gitignore. /usr/portage/local was the original location for the user's own personal ebuild space - an overlay if you will. /usr/portage/distfiles and /usr/portage/packages are there because that's where ports has put them for decades, and no-one has gotten around to changing it in portage yet. FreeBSD defines the use of /usr very differently to what Linux users are used to. Those dirs really should be in /var/portage, and the user's overlay has no business being under main tree itself I didn't say they were the most appropriate locations and I agree that /var/portage is best but that doesn't change the fact that they are still the defaults. :) Indeed. And it's equally true they should be git ignored. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
2015-08-12 15:47 GMT+08:00 Mike Frysinger vap...@gentoo.org: On 12 Aug 2015 15:20, Leno Hou wrote: 2. How to control endian difference via profiles ? i.e. *How to get ppc64le as a full stage/profile along side ppc64* ? Could you give me in detail ? you probably want to create a new profile dir: profiles/arch/powerpc/ppc64/little-endian/ then add a make.defaults file with the right CHOST defaults. as we find packages that have problems on little endian, that provides you a safe space to mask features too. then create a new target for linux users: profiles/default/linux/powerpc/ppc64/13.0/64bit-userland/little-endian/ that'll inherit the arch/powerpc/ppc64/little-endian parent I tried this way and could merge some packages quite well, that's great and really helpful. But I still quite confused about the CHOST, such as if I couldn't compile sandbox successfully in this method, however when I tried to use ppc32's profile, it builds well without any errors (similar situation of other packages on ppc64's profile as well). What's that mean? how to fix this? Could you give me some details ? -- Linda
Re: [gentoo-dev] .gitignore
Mike Frysinger vapier at gentoo.org writes: On 10 Aug 2015 09:17, Michał Górny wrote: Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): On 10 Aug 2015 08:28, Justin (jlec) wrote: I like to propose to add the md5-cache into it. Which other files are of interest? /distfiles/ /local/ /packages/ Those directories should not be ignored. Those should not exist for a long time. there's no reason people can't use these on their own system. there's no reason they should be added to the git repo which means, if a user opted to utilize them, they should be ignored. I agree and I'm not sure what mgorny is basing his statement on anyway. Apart from /local/, which I forget the purpose of, the default locations for DISTDIR and PKGDIR still seem to be /usr/portage/distfiles and /usr/portage/packages. I must admit that I'm struggling to find the logic for this in Portage but those are the defaults nonetheless. So why would they not exist? I'm certainly using them here and I would like to see them in .gitignore. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpSredWaJ3fn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] .gitignore
On Thu, 13 Aug 2015 00:11:45 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 12/08/2015 23:29, James Le Cuirot wrote: Mike Frysinger vapier at gentoo.org writes: On 10 Aug 2015 09:17, Michał Górny wrote: Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): On 10 Aug 2015 08:28, Justin (jlec) wrote: I like to propose to add the md5-cache into it. Which other files are of interest? /distfiles/ /local/ /packages/ Those directories should not be ignored. Those should not exist for a long time. there's no reason people can't use these on their own system. there's no reason they should be added to the git repo which means, if a user opted to utilize them, they should be ignored. I agree and I'm not sure what mgorny is basing his statement on anyway. Apart from /local/, which I forget the purpose of, the default locations for DISTDIR and PKGDIR still seem to be /usr/portage/distfiles and /usr/portage/packages. I must admit that I'm struggling to find the logic for this in Portage but those are the defaults nonetheless. So why would they not exist? I'm certainly using them here and I would like to see them in .gitignore. /usr/portage/local was the original location for the user's own personal ebuild space - an overlay if you will. /usr/portage/distfiles and /usr/portage/packages are there because that's where ports has put them for decades, and no-one has gotten around to changing it in portage yet. FreeBSD defines the use of /usr very differently to what Linux users are used to. Those dirs really should be in /var/portage, and the user's overlay has no business being under main tree itself I didn't say they were the most appropriate locations and I agree that /var/portage is best but that doesn't change the fact that they are still the defaults. :) -- James Le Cuirot (chewi) Gentoo Linux Developer pgpUauEWjDia6.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] .gitignore
On 12/08/2015 23:29, James Le Cuirot wrote: Mike Frysinger vapier at gentoo.org writes: On 10 Aug 2015 09:17, Michał Górny wrote: Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): On 10 Aug 2015 08:28, Justin (jlec) wrote: I like to propose to add the md5-cache into it. Which other files are of interest? /distfiles/ /local/ /packages/ Those directories should not be ignored. Those should not exist for a long time. there's no reason people can't use these on their own system. there's no reason they should be added to the git repo which means, if a user opted to utilize them, they should be ignored. I agree and I'm not sure what mgorny is basing his statement on anyway. Apart from /local/, which I forget the purpose of, the default locations for DISTDIR and PKGDIR still seem to be /usr/portage/distfiles and /usr/portage/packages. I must admit that I'm struggling to find the logic for this in Portage but those are the defaults nonetheless. So why would they not exist? I'm certainly using them here and I would like to see them in .gitignore. /usr/portage/local was the original location for the user's own personal ebuild space - an overlay if you will. /usr/portage/distfiles and /usr/portage/packages are there because that's where ports has put them for decades, and no-one has gotten around to changing it in portage yet. FreeBSD defines the use of /usr very differently to what Linux users are used to. Those dirs really should be in /var/portage, and the user's overlay has no business being under main tree itself -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: useflag policies
On 12 August 2015 at 16:21, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Can't we all (except for the usual suspect) just agree that REQUIRED_USE was a mistake, and go back to pkg_pretend? The only justification for REQUIRED_USE was that it could allegedly be used in an automated fashion, and this hasn't happened. I think such a proposal needs to be tested on places where it is used heavily, for instance, python modules where REQUIRED_USE is employed extensively, which could mean a significant number of pkg_pretend phases executing, which *could* be more expensive than the equivalent static dependency code. ( And it could be required that python eclass consumers would all have to provide a pkg_pretend() even if they didn't need required_use behaviour ) I'm not saying it *is*, but a side by side comparison of real-world problems there would be important. ( Maybe the complex dependency resolver stuff is much slower, hard to tell ) -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
On 08/11/15 10:32, Michał Górny wrote: Hello, everyone. Now that we're officially on git and can officially use pull requests to provide rapid community interaction, it'd be convenient to have a little better framework for pinging package maintainers. With the unofficial mirror/pull request project, I was either looking for project member GitHub accounts and pinging found project members by name, or talking to them directly on IRC. However, with the growth in number of pull requests this will become more and more inconvenient. Therefore, I think it's time to be able to mirror teams willing to work with GitHub community there for easier 'pings'. I have two ideas right now: 1. creating GitHub Gentoo project teams corresponding to willing Gentoo teams, 2. preparing lists of GitHub usernames on project wiki pages. Solution 1. is cleaner. In this case, we create GitHub teams under the Gentoo projects, and add appropriate Gentoo developers having GitHub accounts to the teams. Then, in PRs we can just ping the whole team like @Gentoo/Qt or like. Solution 2. avoids adding any GitHub teams. In this case, in team wiki page we collect team member usernames like @Pesa, @kensington, ... so we could copy-paste it to pull requests. We still require extra effort when 'assigning' PRs but at least I don't have to lookup the same people over and over again. With some Wiki people help, we could even implement updating GitHub teams automatically following Wiki member changes. Your thoughts? Why not use LDAP?
[gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388
--- .../2015-08-13-openssh-weak-keys.en.txt| 26 ++ 1 file changed, 26 insertions(+) create mode 100644 2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt diff --git a/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt new file mode 100644 index 000..8dece5e --- /dev/null +++ b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt @@ -0,0 +1,26 @@ +Title: OpenSSH 7.0 disables ssh-dss keys by default +Author: Mike Frysinger vap...@gentoo.org +Content-Type: text/plain +Posted: 2015-08-13 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: net-misc/openssh + +Starting with the 7.0 release of OpenSSH, support for ssh-dss keys has +been disabled by default at runtime. If you rely on these key types, +you will have to take corrective action or risk being locked out. + +Your best option is to generate new keys using newer types such as rsa +or ecdsa or ed25519. RSA keys will give you the greatest portability +with other clients/servers while ed25519 will get you the best security +with OpenSSH (but requires recent versions of client server). + +If you are stuck with DSA keys, you can re-enable support locally by +updating your sshd_config file with a line like so: + PubkeyAcceptedKeyTypes=+ssh-dss + +Be aware though that eventually OpenSSH will drop support for DSA keys +entirely, so this is only a stop gap solution. + +More details can be found on OpenSSH's website: + http://www.openssh.com/legacy.html -- 2.4.4
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
On 13 Aug 2015 07:58, 姜渠 wrote: 2015-08-12 15:47 GMT+08:00 Mike Frysinger: On 12 Aug 2015 15:20, Leno Hou wrote: 2. How to control endian difference via profiles ? i.e. *How to get ppc64le as a full stage/profile along side ppc64* ? Could you give me in detail ? you probably want to create a new profile dir: profiles/arch/powerpc/ppc64/little-endian/ then add a make.defaults file with the right CHOST defaults. as we find packages that have problems on little endian, that provides you a safe space to mask features too. then create a new target for linux users: profiles/default/linux/powerpc/ppc64/13.0/64bit-userland/little-endian/ that'll inherit the arch/powerpc/ppc64/little-endian parent I tried this way and could merge some packages quite well, that's great and really helpful. But I still quite confused about the CHOST, such as if I couldn't compile sandbox successfully in this method, however when I tried to use ppc32's profile, it builds well without any errors (similar situation of other packages on ppc64's profile as well). What's that mean? how to fix this? Could you give me some details ? w/out error messages it's hard to guess at what the problem is you're seeing. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: useflag policies
On 08/12/15 22:38, William Hubbs wrote: I always wondered why pkg_pretend never caught on. Because, in a way, it triggers at the wrong point of the merge. emerge -pv fnurk = dependencies look ok emerge fnurk = pkg_pretend bails out ... eh?! (This would be a little bit confusing, if not actively hostile, and useflags + required_use are a lot more 'natural' to the emerge workflow) I to can see the advantage of it over REQUIRED_USE; it would allow the package maintainer to give specific error messages about why use flag combinations are invalid for a package. And now someone will say annotations. Sigh. have fun, Patrick
Re: [gentoo-dev] .gitignore
On Wed, Aug 12, 2015 at 6:22 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 13/08/2015 00:21, James Le Cuirot wrote: On Thu, 13 Aug 2015 00:11:45 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 12/08/2015 23:29, James Le Cuirot wrote: Mike Frysinger vapier at gentoo.org writes: On 10 Aug 2015 09:17, Michał Górny wrote: Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): On 10 Aug 2015 08:28, Justin (jlec) wrote: I like to propose to add the md5-cache into it. Which other files are of interest? /distfiles/ /local/ /packages/ Those directories should not be ignored. Those should not exist for a long time. there's no reason people can't use these on their own system. there's no reason they should be added to the git repo which means, if a user opted to utilize them, they should be ignored. I agree and I'm not sure what mgorny is basing his statement on anyway. Apart from /local/, which I forget the purpose of, the default locations for DISTDIR and PKGDIR still seem to be /usr/portage/distfiles and /usr/portage/packages. I must admit that I'm struggling to find the logic for this in Portage but those are the defaults nonetheless. So why would they not exist? I'm certainly using them here and I would like to see them in .gitignore. /usr/portage/local was the original location for the user's own personal ebuild space - an overlay if you will. /usr/portage/distfiles and /usr/portage/packages are there because that's where ports has put them for decades, and no-one has gotten around to changing it in portage yet. FreeBSD defines the use of /usr very differently to what Linux users are used to. Those dirs really should be in /var/portage, and the user's overlay has no business being under main tree itself I didn't say they were the most appropriate locations and I agree that /var/portage is best but that doesn't change the fact that they are still the defaults. :) Indeed. And it's equally true they should be git ignored. I went ahead and added them. commit 0f87115a27f70502eed95cd27b71449eb66dc7b1 Author: Mike Gilbert flop...@gentoo.org Date: Wed Aug 12 21:27:59 2015 -0400 Add some additional legacy directories to .gitignore diff --git a/.gitignore b/.gitignore index 87c1cce..1f8c184 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,5 @@ /.ebuild.x -profiles/use.local.desc +/distfiles/ +/local/ +/packages/ +/profiles/use.local.desc
Re: [gentoo-dev] Referencing bug reports in git
Someone end the bikeshed train please. Seconded.
[gentoo-dev] Re: Referencing bug reports in git
On Wed, 12 Aug 2015 18:03:52 +0200 Michał Górny mgo...@gentoo.org wrote: Can we make it clear whether we are allowed/supposed to use the short form: https://bugs.gentoo.org/333531 ? I'd like this to be the preferred form. It's cleaner, the show_bug.cgi=id? is just noise. If we do go with a URI is it possible to do some kind of magic behind the scenes to canonicalize it? By that I mean is that any of these: Gentoo-Bug: https://bugs.gentoo.org/333531 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 Gentoo-Bug: 333531 would automatically be converted to https://bugs.gentoo.org/333531 (or whatever is decided on). That way everyone can use whatever they like best and it'll all come out consistent. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 pgpZvwfTybaI_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] .gitignore
On 12 Aug 2015 18:27, Brian Dolbec wrote: 2) There is another alternate location that you can define files to ignore locally without having to commit them to .gitignore. Consider .gitignore a global setting. There is another setting inside .git/info/exclude which is a local config file that will persist and not be affected by pulls. So please use that for local exclusions you want to add and not try to force them into a global .gitignore which is part of the repo. Something that seems to be hotly debated. ;) as i stated, there's no reason for these paths to ever be committed. conversely, some people (not unreasonably so) will place files in there that have historically had known meanings. adding these to the global gitignore is simply the right thing to do and negatively impacts no one. -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: useflag policies
On 08/12/2015 05:44 PM, Patrick Lauer wrote: On 08/12/15 22:38, William Hubbs wrote: I always wondered why pkg_pretend never caught on. Because, in a way, it triggers at the wrong point of the merge. emerge -pv fnurk = dependencies look ok emerge fnurk = pkg_pretend bails out ... eh?! (This would be a little bit confusing, if not actively hostile, and useflags + required_use are a lot more 'natural' to the emerge workflow) The nice thing about REQUIRED_USE is that it is math expression, and math is a sort of universal language. It leads to uniform error messages. You can imagine that pkg_pretend messages will tend to be much less uniform! I to can see the advantage of it over REQUIRED_USE; it would allow the package maintainer to give specific error messages about why use flag combinations are invalid for a package. And now someone will say annotations. Sigh. Well, nothing stops people from using pkg_pretend to create fancy error messages now! have fun, Patrick -- Thanks, Zac
Re: [gentoo-dev] .gitignore
On Thu, 13 Aug 2015 00:22:34 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 13/08/2015 00:21, James Le Cuirot wrote: On Thu, 13 Aug 2015 00:11:45 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 12/08/2015 23:29, James Le Cuirot wrote: Mike Frysinger vapier at gentoo.org writes: On 10 Aug 2015 09:17, Michał Górny wrote: Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a): On 10 Aug 2015 08:28, Justin (jlec) wrote: I like to propose to add the md5-cache into it. Which other files are of interest? /distfiles/ /local/ /packages/ Those directories should not be ignored. Those should not exist for a long time. there's no reason people can't use these on their own system. there's no reason they should be added to the git repo which means, if a user opted to utilize them, they should be ignored. I agree and I'm not sure what mgorny is basing his statement on anyway. Apart from /local/, which I forget the purpose of, the default locations for DISTDIR and PKGDIR still seem to be /usr/portage/distfiles and /usr/portage/packages. I must admit that I'm struggling to find the logic for this in Portage but those are the defaults nonetheless. So why would they not exist? I'm certainly using them here and I would like to see them in .gitignore. /usr/portage/local was the original location for the user's own personal ebuild space - an overlay if you will. /usr/portage/distfiles and /usr/portage/packages are there because that's where ports has put them for decades, and no-one has gotten around to changing it in portage yet. FreeBSD defines the use of /usr very differently to what Linux users are used to. Those dirs really should be in /var/portage, and the user's overlay has no business being under main tree itself I didn't say they were the most appropriate locations and I agree that /var/portage is best but that doesn't change the fact that they are still the defaults. :) Indeed. And it's equally true they should be git ignored. Two things... 1) /var/portage is ABSOLUTELY the wrong name. with teh move which should happen soon, it will be named gentoo just like the repo name. The final location path is not yet 100% set and will not likely come to any agreement amongst the populous. It hasn't yet ;) But is will end up somewhere in /var/.../repos/gentoo most likely. The MAIN reason, is there is often too much confusion between portage the package manager and portage the gentoo ebuild tree. So to follow the overlay naming rules for inclusion in the repositories.xml file, the directory name must be the same as the repo name. 2) There is another alternate location that you can define files to ignore locally without having to commit them to .gitignore. Consider .gitignore a global setting. There is another setting inside .git/info/exclude which is a local config file that will persist and not be affected by pulls. So please use that for local exclusions you want to add and not try to force them into a global .gitignore which is part of the repo. Something that seems to be hotly debated. ;) -- Brian Dolbec dolsen
Re: [gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388
On Wed, Aug 12, 2015 at 11:17 PM, Mike Frysinger vap...@gentoo.org wrote: --- .../2015-08-13-openssh-weak-keys.en.txt| 26 ++ 1 file changed, 26 insertions(+) create mode 100644 2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt diff --git a/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt new file mode 100644 index 000..8dece5e --- /dev/null +++ b/2015/2015-08-13-openssh-weak-keys/2015-08-13-openssh-weak-keys.en.txt @@ -0,0 +1,26 @@ +Title: OpenSSH 7.0 disables ssh-dss keys by default +Author: Mike Frysinger vap...@gentoo.org +Content-Type: text/plain +Posted: 2015-08-13 +Revision: 1 +News-Item-Format: 1.0 +Display-If-Installed: net-misc/openssh + +Starting with the 7.0 release of OpenSSH, support for ssh-dss keys has +been disabled by default at runtime. If you rely on these key types, +you will have to take corrective action or risk being locked out. + +Your best option is to generate new keys using newer types such as rsa +or ecdsa or ed25519. RSA keys will give you the greatest portability +with other clients/servers while ed25519 will get you the best security +with OpenSSH (but requires recent versions of client server). + +If you are stuck with DSA keys, you can re-enable support locally by +updating your sshd_config file with a line like so: + PubkeyAcceptedKeyTypes=+ssh-dss + +Be aware though that eventually OpenSSH will drop support for DSA keys +entirely, so this is only a stop gap solution. + +More details can be found on OpenSSH's website: + http://www.openssh.com/legacy.html -- 2.4.4 Looks good to me, thanks for writing it.
[gentoo-dev] Re: Bisecting Was: Referencing bug reports in git
Jason Zaman posted on Wed, 12 Aug 2015 15:38:01 +0800 as excerpted: Tho I can definitely think of a non-traditional use for bisect. [When a system hasn't been updated in over a year, bisect the update.] I like the idea, but its probably easier to just git checkout $(git rev-list -n 1 --before=2015-12-01 12:00 master) and then you just change the date a month at a time or something You're correct, and I did think about that, but... The nice thing with bisect at least in something like the kernel where most of the direct main-tree changes are merges, is that it'll stay at the higher merge level as long as possible, drilling down to individual commits only after bisects to an individual merge. Again, however, I'm not entirely sure how that translates to gentoo's rebase-and-fast-forward recommendation, with fewer merges. But at the 3-4 month level, if it avoids landing in the middle of a kde or gnome update, that'd be very useful. It could well be that with gentoo's merges-discouraged workflow, the effect would be the same either way, in which case, you're correct, your suggestion would be easier. But it's still a creative use of bisect I hadn't thought of before, even if bisect isn't the most efficient method to that end. Which means I know a bit more about bisect than I did. =:^) -- 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
[gentoo-dev] Bisecting Was: Referencing bug reports in git
hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted: In addition, we just took the freedom to add the clause all commits must be repoman-valid: https://wiki.gentoo.org/index.php? title=Gentoo_git_workflowdiff=352978oldid=352858 That will be necessary too for the CI work mgorny is doing and will also make bisecting and cherry-picking easier. The mention of bisect got me thinking... I'm not exactly sure I'm wording this right, but hopefully the question is clear enough... What are the practical implications of and reasons for doing a bisect, on a package-tree repo, where it's typically the out-of-tree package sources where most functionality-bisection would happen, and in-tree commits tend to result in atomic package updates, or at least atomic USE flag, etc, changes on a package? The typical reason for a bisect is to find the commit where a bug originated, but that's upstream package/project bisects. I don't quite see how that maps to distro package tree repo bisects, as it seems to me there's nothing really to bisect -- problems should be with specific package versions or with USE flag or similar changes within an ebuild/ eclass, and it seems to me that's known along with awareness of the problem in the first place, leaving no reason to bisect to find the problem. Tho arguably eclass change issues are an exception, and bisectable in the usual sense for the usual purpose. Actually, that could make troubleshooting eclass updates MUCH simpler than it was before. Luckily, at least I as a user didn't end up with too many direct eclass issues to troubleshoot. Tho I can definitely think of a non-traditional use for bisect. While I update my workstation more or less weekly, I updated my 32-bit netbook[1] far less frequently, every year or two. It occurs to me that using git bisect to automate working out the resulting update issues might be far easier than some of the manual tricks and workaround I used to end up doing, to finally get an updated to current, working system once again. Bisect start, immediately declare bisect bad, inner looping until I got to about a three-month update, update to it, bisect reset, outer-looping on the bisect to another 3-4 month update... until I was caught up. Of course one can't go back past our current switch to git, but in five years, one could in theory pull the old laptop out that was last updated yesterday, and roll back gentoo's now five-years-future tree four years and nine months, and start the update process, ultimately bringing it upto date without starting with a new stage tarball install, as would have been the only really feasible pre-git alternative for a five-year-outdated system. Not that a new stage tarball wouldn't be faster after five years in any case, but at least the incremental update- in-place should now be possible. --- [1] 32-bit netbook: Now gone and not yet replaced, but I intend to get another, tho amd64 this time so I can mostly build once for both, one for three if I setup an amd64-based router as I intend to as well, and hopefully avoid the year-plus update period issue as I can just binpkg- update after the first one. -- 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
[gentoo-dev] Re: useflag policies
Alexandre Rostovtsev posted on Tue, 11 Aug 2015 09:13:36 -0400 as excerpted: On Tue, 2015-08-11 at 16:04 +0300, Sergey Popov wrote: You want to migrate to such decision? Like: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. That flag should be called gui. Not qt. This would be the real solution to gnome team's gtk/gtk2/gtk3 flag problem and to qt team's flag problem too. Hasn't the X USE flag effectively been the gui USE flag (with curses as a semi-gui USE flag)? With wayland coming along, what will be the effect, since we'll effectively have two separate GUIs, then, instead of X being the de facto gui USE flag? Of course X remains the default for now, but for how long? -- 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] Introduce ppc64le architecture into gentoo ! please share your comments
On Wed, Aug 12, 2015 at 11:50 AM, Mike Frysinger vap...@gentoo.org wrote: On 11 Aug 2015 10:45, Anthony G. Basile wrote: On 8/11/15 10:33 AM, Ian Stakenvicius wrote: On 11/08/15 06:11 AM, Leno Hou wrote: I think ppc64le would become popular, https://en.wikipedia.org/wiki/Ppc64. 1. enable porting x86 Linux based application with minimal effort. 2. Some PowerPC user, little endian apparently feels cheap, wrong, and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE already support little endian in powerpc. In terms of the codepaths, what's different between ppc64le vs ppc64, and ppc64le vs amd64 ? Obviously kernels will differ, but in terms of C/C++/other compiled source code what needs to change? If all this needs is its own profile for a CHOST/CBUILD specification and it can leverage an existing keyword, then this should be rather simple to implement yes? We would leverage this on ppc64 keyword. It is a bit dangerous to claim that a pkg stable on ppc64 is stable on ppc64le, but we would live with that risk. Ideally you should test on both. The situation is analogous to mips where there are many different ISAs and both be and le. It is one of the reasons mips is hard to move back into stable. But having stable keywords is really nice when it comes to building and maintaining stages and keeping base pkgs versions in sync with the other arches. For this reason, I would even been in favor of restoring stable mips with the understanding that stable carries something of a risk when crossing the be/le boundry, or the mips I vs mips III, or 32 vs 64, etc. yes, we should just re-use the existing KEYWORDS and control the endian differences via profiles. it's how other arches (mips, ppc, arm, arm64) are handled currently. note: people have already built Gentoo for ppc little endian, but that tends to only be used in embedded setups, so the builds don't get published like other arches as stages. -mike 1. I have successfully complied ppc64le chroot environment manually. General Steps that omitted modify USE flag are here. https://docs.google.com/document/d/1zGO5Gvu4DGPX7Pn70q5vbW_uF___4h8_pIpOtoOEdnY/edit?usp=sharing 2. How to control endian difference via profiles ? i.e. *How to get ppc64le as a full stage/profile along side ppc64* ? Could you give me in detail ? 3. ppc64 already have stage3, why ppc64le tends to only be used in embedded setups ? If embedded setups, please let me know any forward/ steps . http://distfiles.gentoo.org/releases/ppc/autobuilds/current-iso/ 4. I would like become a developer of porting gentoo on ppc64le. Anyone could help/mentor me to join this project ? https://wiki.gentoo.org/wiki/Project:PowerPC appreciated your assistance and help. 5. https://wiki.gentoo.org/wiki/Porting The Section 'Converting to Gentoo' needs to be updated. From portage-2.2.20 on, please download portage and install it by 'python setup.py install' **Most importantly, Any Ideas/steps of how to porting gentoo on ppc64le architecture?** Leno Hou E-mail: leno...@gmail.com
Re: [gentoo-dev] Bisecting Was: Referencing bug reports in git
On Wed, Aug 12, 2015 at 07:20:54AM +, Duncan wrote: hasufell posted on Tue, 11 Aug 2015 13:58:20 +0200 as excerpted: In addition, we just took the freedom to add the clause all commits must be repoman-valid: https://wiki.gentoo.org/index.php? title=Gentoo_git_workflowdiff=352978oldid=352858 That will be necessary too for the CI work mgorny is doing and will also make bisecting and cherry-picking easier. The mention of bisect got me thinking... I'm not exactly sure I'm wording this right, but hopefully the question is clear enough... What are the practical implications of and reasons for doing a bisect, on a package-tree repo, where it's typically the out-of-tree package sources where most functionality-bisection would happen, and in-tree commits tend to result in atomic package updates, or at least atomic USE flag, etc, changes on a package? The typical reason for a bisect is to find the commit where a bug originated, but that's upstream package/project bisects. I don't quite see how that maps to distro package tree repo bisects, as it seems to me there's nothing really to bisect -- problems should be with specific package versions or with USE flag or similar changes within an ebuild/ eclass, and it seems to me that's known along with awareness of the problem in the first place, leaving no reason to bisect to find the problem. Tho arguably eclass change issues are an exception, and bisectable in the usual sense for the usual purpose. Actually, that could make troubleshooting eclass updates MUCH simpler than it was before. Luckily, at least I as a user didn't end up with too many direct eclass issues to troubleshoot. I agree that bisecting would typically not happen that often because usually you'd just emerge =cat/pkg-1.2.3 but there are times when updates are done without a revbump that might have broken something so it could be useful. Also eclasses would definitely be useful. There are a few useful cases when it might make things easier but probably rare, tho its good to have the tool available in case. Tho I can definitely think of a non-traditional use for bisect. While I update my workstation more or less weekly, I updated my 32-bit netbook[1] far less frequently, every year or two. It occurs to me that using git bisect to automate working out the resulting update issues might be far easier than some of the manual tricks and workaround I used to end up doing, to finally get an updated to current, working system once again. Bisect start, immediately declare bisect bad, inner looping until I got to about a three-month update, update to it, bisect reset, outer-looping on the bisect to another 3-4 month update... until I was caught up. Of course one can't go back past our current switch to git, but in five years, one could in theory pull the old laptop out that was last updated yesterday, and roll back gentoo's now five-years-future tree four years and nine months, and start the update process, ultimately bringing it upto date without starting with a new stage tarball install, as would have been the only really feasible pre-git alternative for a five-year-outdated system. Not that a new stage tarball wouldn't be faster after five years in any case, but at least the incremental update- in-place should now be possible. I like the idea, but its probably easier to just git checkout $(git rev-list -n 1 --before=2015-12-01 12:00 master) and then you just change the date a month at a time or something -- Jason --- [1] 32-bit netbook: Now gone and not yet replaced, but I intend to get another, tho amd64 this time so I can mostly build once for both, one for three if I setup an amd64-based router as I intend to as well, and hopefully avoid the year-plus update period issue as I can just binpkg- update after the first one. -- 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] Introduce ppc64le architecture into gentoo ! please share your comments
On 12 Aug 2015 15:20, Leno Hou wrote: 2. How to control endian difference via profiles ? i.e. *How to get ppc64le as a full stage/profile along side ppc64* ? Could you give me in detail ? you probably want to create a new profile dir: profiles/arch/powerpc/ppc64/little-endian/ then add a make.defaults file with the right CHOST defaults. as we find packages that have problems on little endian, that provides you a safe space to mask features too. then create a new target for linux users: profiles/default/linux/powerpc/ppc64/13.0/64bit-userland/little-endian/ that'll inherit the arch/powerpc/ppc64/little-endian parent 3. ppc64 already have stage3, why ppc64le tends to only be used in embedded setups ? i said ppc little endian, not ppc64le. historically speaking, ppc64le hasn't been a thing, and the only people doing ppc little endian are 32bit embedded users. that doesn't mean we can't make stages/iso for both. 4. I would like become a developer of porting gentoo on ppc64le. Anyone could help/mentor me to join this project ? ideally someone on the ppc side would pick you up, but i think they've been a bit of a skeleton team of late. so if need be, i can help you here. 5. https://wiki.gentoo.org/wiki/Porting The Section 'Converting to Gentoo' needs to be updated. From portage-2.2.20 on, please download portage and install it by 'python setup.py install' you mean my bootstrap-portage script ? **Most importantly, Any Ideas/steps of how to porting gentoo on ppc64le architecture?** do you have hardware ? then it's simply a matter of booting Gentoo in it and filing/fixing bugs :). -mike signature.asc Description: Digital signature
[gentoo-dev] Re: useflag policies
Sergey Popov posted on Tue, 11 Aug 2015 15:58:49 +0300 as excerpted: 11.08.2015 15:30, Michael Palimaka пишет: On 11/08/15 20:10, Sergey Popov wrote: Err, i have read the whole thread and still does not get a point, why i am wrong. You clearly have not. The reasoning behind Qt team's policy is described on the page and has been reiterated on this list. You are undermining what little confidence there is in the QA team by making decisions with no consultation about problems you do not understand. It's old battle like we have beforce with gtk meaning any versions of GTK flag. This behaviour should be killed with fire. Let's me reiterate some of the cases: 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can be chosen, but not both. Fix this with REQUIRED_USE, do not enable any of Qt flags by default Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. User choice of using USE flags is NOT a problem [As has been said elsewhere in the thread but you apparently haven't seen...] But if the profile enables both qt4 and qt5, as at least one profile, the new plasma (aka kde5) profile does, and really must? The desktop profile enables qt4. The plasma profile inherits qt4 from there and enables qt5, so both are enabled. And because kde5 is an incremental switchover that still includes many kde4-based apps, some of which likely have deps that need qt4 in the USE flags and users likely still want it enabled in any case, it's not as simple as disabling the qt4 USE flag in the plasma profile, either. Furthermore, as qt5 matures and more apps base on it, it's likely that qt5 will need enabled in the desktop profile as well, well before qt4 can be conveniently disabled. So there's some users now, the ones using the plasma profile, and will soon be very many users, anyone using a desktop-inheriting profile, that will have and arguably need, both qt4 and qt5 enabled. You're really saying that *all* of them should be forced to deal with dozens of package-specific package.use settings, to negate the effects of REQUIRED_USE when both qt4 and qt5 are enabled in their gentoo-shipped profile? This is why it's a problem. If it were just the people that specifically set both qt4 and qt5 in make.conf. it'd be a much smaller problem and could perhaps be simply ignored as a user-created problem. But when it's the default setting in all desktop profiles, as it's very likely to be within a year, it's no longer simply a user-created problem. [Personally, I both run with USE=-* ... and started trying qt5 and kde5/ plasma back when they were both still in the overlay, so I've long since worked out the biggest such problems here. I didn't complain as it's simply part of both trying things that far ahead and specifying that I /want/ the choice and will deal with the consequences of such things by setting USE=-*. But it'd be very nice if our stable desktop users didn't have to go thru the same thing I did, once they get plasma5, just because they use a desktop profile.] -- 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] Introduce ppc64le architecture into gentoo ! please share your comments
On 8/12/15 3:47 AM, Mike Frysinger wrote: 4. I would like become a developer of porting gentoo on ppc64le. Anyone could help/mentor me to join this project ? ideally someone on the ppc side would pick you up, but i think they've been a bit of a skeleton team of late. so if need be, i can help you here. I can help out here. **Most importantly, Any Ideas/steps of how to porting gentoo on ppc64le architecture?** do you have hardware ? then it's simply a matter of booting Gentoo in it and filing/fixing bugs :). -mike We should also start building stage3s. -- 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
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/
On Tue, 11 Aug 2015 13:17:10 +0200 hasufell wrote: On 08/11/2015 08:34 AM, Mike Frysinger wrote: commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Tue Aug 11 06:28:16 2015 + Commit: Mike Frysinger vapier AT gentoo DOT org CommitDate: Tue Aug 11 06:34:22 2015 + URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=719cc5ef microcode-ctl: stop installing the init script Updating microcode on the fly is dangerous as it can modify the set of valid instructions. An active example of this is Intel's TSX insns -- the latest microcode push disables the insn on newer CPUs and causes SIGILL when you try to use it. But if you test for the insn before the microcode is updated, it will execute fine. For daemons that launched before the update, they'll find the flag works, and then crash later on when the insn no longer exists. Thus the only safe way to update microcode is at boot time via a builtin initramfs. Details on this operation can be found in #528712#41. I've already asked you twice on the ML why you keep ignoring the standard we set for the commit message summary and pretty much everyone is following except you. Let me remind you that: 1. this is not a standard, but a draft; 2. not all issues are clear right now (e.g. how to reference bugs); 3. it is not approved by the Council; 4. not everyone agrees with these rules anyway. Best regards, Andrew Savchenko pgpX1D8IcKPzO.pgp Description: PGP signature
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
2 cents from me in case of connection with contributions on github: - Someone should automate mirroring for https://github.com/gentoo/gnome - And review periodically pull requests there if there will be some... On 11.08.2015 18:32, Michał Górny wrote: Hello, everyone. Now that we're officially on git and can officially use pull requests to provide rapid community interaction, it'd be convenient to have a little better framework for pinging package maintainers. With the unofficial mirror/pull request project, I was either looking for project member GitHub accounts and pinging found project members by name, or talking to them directly on IRC. However, with the growth in number of pull requests this will become more and more inconvenient. Therefore, I think it's time to be able to mirror teams willing to work with GitHub community there for easier 'pings'. I have two ideas right now: 1. creating GitHub Gentoo project teams corresponding to willing Gentoo teams, 2. preparing lists of GitHub usernames on project wiki pages. Solution 1. is cleaner. In this case, we create GitHub teams under the Gentoo projects, and add appropriate Gentoo developers having GitHub accounts to the teams. Then, in PRs we can just ping the whole team like @Gentoo/Qt or like. Solution 2. avoids adding any GitHub teams. In this case, in team wiki page we collect team member usernames like @Pesa, @kensington, ... so we could copy-paste it to pull requests. We still require extra effort when 'assigning' PRs but at least I don't have to lookup the same people over and over again. With some Wiki people help, we could even implement updating GitHub teams automatically following Wiki member changes. Your thoughts?
Re: [gentoo-powerpc] Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
On 12/08/15 11:46, Shuai Zhao wrote: 2015-08-12 15:47 GMT+08:00 Mike Frysinger vap...@gentoo.org: On 12 Aug 2015 15:20, Leno Hou wrote: **Most importantly, Any Ideas/steps of how to porting gentoo on ppc64le architecture?** do you have hardware ? then it's simply a matter of booting Gentoo in it and filing/fixing bugs :). -mike Yeah, we has several virtual machines of PPC64le. Are they based on qemu or something completely different? lu
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/
On 08/12/2015 12:11 PM, hasufell wrote: On 08/12/2015 08:48 AM, Andrew Savchenko wrote: On Tue, 11 Aug 2015 13:17:10 +0200 hasufell wrote: On 08/11/2015 08:34 AM, Mike Frysinger wrote: commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Tue Aug 11 06:28:16 2015 + Commit: Mike Frysinger vapier AT gentoo DOT org CommitDate: Tue Aug 11 06:34:22 2015 + URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=719cc5ef microcode-ctl: stop installing the init script Updating microcode on the fly is dangerous as it can modify the set of valid instructions. An active example of this is Intel's TSX insns -- the latest microcode push disables the insn on newer CPUs and causes SIGILL when you try to use it. But if you test for the insn before the microcode is updated, it will execute fine. For daemons that launched before the update, they'll find the flag works, and then crash later on when the insn no longer exists. Thus the only safe way to update microcode is at boot time via a builtin initramfs. Details on this operation can be found in #528712#41. I've already asked you twice on the ML why you keep ignoring the standard we set for the commit message summary and pretty much everyone is following except you. Let me remind you that: 1. this is not a standard, but a draft; 2. not all issues are clear right now (e.g. how to reference bugs); 3. it is not approved by the Council; 4. not everyone agrees with these rules anyway. So you want to sabotage consistency and wait until the council approves every minor detail that has been worked out by the community? These things WERE discussed (half a year ago or more) and there was consensus. Things that are still not clear (such as referencing bug reports) were not added to the wiki. Don't mix things up. If we say everyone is allowed to ignore all the rules as long as it repoman-checks, then I don't know why I even keep throwing out discussions, emails and editing the wiki. Commit message format is really not a workflow-limiting thing. I don't know why you complain like that. And vapier has not participated much in that discussion and has not expressed his interest in a different format. So how is anyone supposed to react to that? This is not constructive. And as I see it, even vapier does it now. So everything is good. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3581b2c101337dec32c2bd6779db7927ff96732a It was probably related to repoman lacking proper support there. Thanks for your cooperation.
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
2015-08-12 15:47 GMT+08:00 Mike Frysinger vap...@gentoo.org: On 12 Aug 2015 15:20, Leno Hou wrote: **Most importantly, Any Ideas/steps of how to porting gentoo on ppc64le architecture?** do you have hardware ? then it's simply a matter of booting Gentoo in it and filing/fixing bugs :). -mike Yeah, we has several virtual machines of PPC64le.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/
On 08/12/2015 08:48 AM, Andrew Savchenko wrote: On Tue, 11 Aug 2015 13:17:10 +0200 hasufell wrote: On 08/11/2015 08:34 AM, Mike Frysinger wrote: commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Tue Aug 11 06:28:16 2015 + Commit: Mike Frysinger vapier AT gentoo DOT org CommitDate: Tue Aug 11 06:34:22 2015 + URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=719cc5ef microcode-ctl: stop installing the init script Updating microcode on the fly is dangerous as it can modify the set of valid instructions. An active example of this is Intel's TSX insns -- the latest microcode push disables the insn on newer CPUs and causes SIGILL when you try to use it. But if you test for the insn before the microcode is updated, it will execute fine. For daemons that launched before the update, they'll find the flag works, and then crash later on when the insn no longer exists. Thus the only safe way to update microcode is at boot time via a builtin initramfs. Details on this operation can be found in #528712#41. I've already asked you twice on the ML why you keep ignoring the standard we set for the commit message summary and pretty much everyone is following except you. Let me remind you that: 1. this is not a standard, but a draft; 2. not all issues are clear right now (e.g. how to reference bugs); 3. it is not approved by the Council; 4. not everyone agrees with these rules anyway. So you want to sabotage consistency and wait until the council approves every minor detail that has been worked out by the community? These things WERE discussed (half a year ago or more) and there was consensus. Things that are still not clear (such as referencing bug reports) were not added to the wiki. Don't mix things up. If we say everyone is allowed to ignore all the rules as long as it repoman-checks, then I don't know why I even keep throwing out discussions, emails and editing the wiki. Commit message format is really not a workflow-limiting thing. I don't know why you complain like that. And vapier has not participated much in that discussion and has not expressed his interest in a different format. So how is anyone supposed to react to that? This is not constructive.
[gentoo-dev] Re: Referencing bug reports in git
So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015, Ian Stakenvicius wrote: On 12/08/15 11:08 AM, Ulrich Mueller wrote: I was thinking about some syntax like this: REQUIRED_USE=|| ( +foo bar ) ^^ ( +qt5 -qt4 ) The package manager would first evaluate each group in REQUIRED_USE with the original set of USE flags. If that doesn't evaluate to true, retry with flags changed as indicated by the + and - signs. Having the ability for REQUIRED_USE to provide a default resolution path should definitely help with things; I assume this is meant to do its work via --autounmask-write or similar, ie to help users adjust their config files? Or was the thought to allow PMs to override USE immediately? In fact, I was thinking about overriding it immediately. It is the same as the ebuild explicitly picking a working default from conflicting flags, where there is also no user interaction required. (The PM should emit a warning, though.) Questions: 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE? Apart from the similar syntax, they are not related. 2 - is there a particular reasoning for the - in front of qt4 here? I only ask because it would seem that a single default-enable should suffice in lists like this to indicate a resolution path, no? That is, '^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like it would be the same as '^^ ( +flag1 flag2 flag3 flag4 )' If the user has both qt4 qt5, then enabling qt5 alone won't help to resolve ^^ ( qt5 qt4 ). 3 - will having REQUIRED_USE be able to force flags on (and others off) likely result in abuse of profiles and other use defaults? It wouldn't look for the origin of a USE flag setting in its input data. So, yes. I forsee this being a way, for instance, for a dev to get around users setting USE=-* in make.conf to ensure a default use flag setting is honoured. 4 - Will a change to which flag the '+' is on likely to require a revbump for VDB updates? I don't think so. For Portage users, it would be handled by --newuse, I guess. For something like '^^ ( +qt4 qt5 )' I could see maintainers wanting to switch which flag is default across a bunch of packages at once when, say, the qt team wants qt5 to become the de-facto default. Ulrich pgpi4HeTmPlXu.pgp Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 12:27:15 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 11:55 AM, Alexis Ballier wrote: On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 11:08 AM, Ulrich Mueller wrote: On Wed, 12 Aug 2015, Alexis Ballier wrote: i.e. something that really tells the PM how to automate the choice: - 'qt5 - !qt4' is rather straightforward to solve and tells the PM how (note that it is not equivalent to 'qt4 - !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to automate it I was thinking about some syntax like this: REQUIRED_USE=|| ( +foo bar ) ^^ ( +qt5 -qt4 ) The package manager would first evaluate each group in REQUIRED_USE with the original set of USE flags. If that doesn't evaluate to true, retry with flags changed as indicated by the + and - signs. Ulrich Having the ability for REQUIRED_USE to provide a default resolution path should definitely help with things; I assume this is meant to do its work via --autounmask-write or similar, ie to help users adjust their config files? Or was the thought to allow PMs to override USE immediately? I think it is better seen as a list of implications, esp. for this kind of questions :) With that in mind, there is no autounmask-write: effective USE for a given package is input USE with these implications applied. ..if I'm understanding what you're saying here, you see this as something the PM will use to adjust the input use list so that the emerge itself will go ahead with the newly adjusted flags; am I understanding that correctly? In other words, there won't be any user control/alert/override for what the default actions will be, if the user's profile isn't set up in a way that satisfies REQUIRED_USE, correct? so if I have 'app-cat/pkg qt4' in my package.use, but USE=qt5 in my profile, then because both flags end up being enabled the REQUIRED_USE=^^ ( +qt5 qt4 ) in app-cat/pkg will just force-off my package.use entry and everything will proceed as if it wasn't there? Questions: 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE? This questions remains. I see use-defaults in IUSE as part of input USE above. Yes, just as it is now, the use-defaults in IUSE are part of the input use. What I'm wondering is, would the +foo in REQUIRED_USE=|| ( +foo bar ) be something that should be used in combination with IUSE=+foo (perhaps even require it) or would its functionality and specification be entirely independent of it? Right now for ||(), setting IUSE=+foo gets around that issue in almost all cases, the only case it doesn't is when the user has explicitly set USE=-foo (or USE=-*). [...] 3 - will having REQUIRED_USE be able to force flags on (and others off) likely result in abuse of profiles and other use defaults? I forsee this being a way, for instance, for a dev to get around users setting USE=-* in make.conf to ensure a default use flag setting is honoured. How? This assumes that the PM will just set the flags that resolve the REQUIRED_USE directly (ie modify the input use based on the defaults provided) and go ahead, which seems to be what you're implying will be the implementation, earlier on. See my response re #1 above as well, since if I understand this correctly the REQUIRED_USE=|| ( +foo bar ) will set +foo even if USE=-* in the profile right? Answering all the above questions I think: input use and effective use are unrelated. The point here is to give PM a way to solve REQUIRED_USE which we currently lack. How PM does it: by autounmask-write, a warning, an error (as currently), or silently is up to each user's preference. I agree though that forcibly solving the conflicts silently might not be a terrible idea and it'd be much better to have an option to control that behavior. Alexis.
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
On 12/08/15 01:00 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
2 - is there a particular reasoning for the - in front
of qt4 here? I only ask because it would seem that a
single default-enable should suffice in lists like this
to indicate a resolution path, no? That is, '^^ ( +flag1
-flag2 -flag3 -flag4 )' to me seems like it would be the
same as '^^ ( +flag1 flag2 flag3 flag4 )'
If the user has both qt4 qt5, then enabling qt5 alone
won't help to resolve ^^ ( qt5 qt4 ).
Right, but the PM knows based on a particular REQUIRED_USE
operator what it would need to do when a particular flag is
set to default. Given '^^' is must-be-one-of, the +flag would
be enabled and all the other flags would be disabled, right?
Here's how I'd see it mapping out:
|| ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ (
+flag1 flag2 ... ) , PM forces-on flag1, forces-off all
others ?? ( +flag2 flag2 ... ) , PM forces off all but flag1
I'm not sure if the following make sense though... thoughts?
{,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? (
+!flag2 ) , PM forces !flag2, meaning forces-off flag2
I'm just wondering if it's really necessary in terms of
syntax to specify the flag-negation that the PM would need to
do.
See my other email: neither + nor - are necessary :)
I'd disagree on that -- technically they aren't necessary, but
the whole reason why these new operators were added in the first
place was so that it's a lot easier for developers to fill in
REQUIRED_USE and get the logic right. Mapping out a ^^ ( flag1
flag2 flag3 flag4 ) into all of its permissible flag-a? ( flagb
!flagc !flagd ) variants is a royal pain. Plus there's
readability/understandability to consider here.
err, flaga? ( !flagb !flagc !flagd ) i mean..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLfSMACgkQAJxUfCtlWe3jQQD7B9BCbF/3qfE9sQCygNpxKhlo
svefcKCbomBA6fTg6bsA/0QLz/Qw8nL4d7P9I4fruwgyU1vZb/VIBmXynwbAij2L
=NW7S
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Referencing bug reports in git
On 08/12/2015 05:59 PM, Chí-Thanh Christopher Nguyễn wrote: hasufell schrieb: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 As there was no formal call for a vote, I don't think you can take the number of voiced opinions as an indicator for the support of an option. Uhm, why not? When I ask for ++, then that is a rough call for opinions. If someone doesn't voice his opinion, then it doesn't count, just like in a formal vote. The only argument you can make is that you want a formal vote, because the amount of consensus is not high enough (is it not?). I guess you will have the same people participating who have already voiced their opinion here. As a compromise, I guess we could say that people are allowed to do both (but must do one of them). The additional code that this would impose on parsing tools is minor. So, either: = app-misc/foo: stabilize and stuff Gentoo-Bug: 333531, 502062, 562062, 502772, 502077 Gentoo-Bug: 502362, 512062 = Or = app-misc/foo: stabilize and stuff Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=502062 ... = If people don't want this either, then I'm done with this topic and will do whatever I like, until someone wants to take this the formal route. I'm not interested to go there for such a trivial thing.
Re: [gentoo-dev] Re: Referencing bug reports in git
Michał Górny schrieb: Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the https://bugs.gentoo.org/show_bug.cgi?id=; optional for Gentoo Bugzilla, would be a compromise I can accept. I would not like having to redundantly give the bug number when I already gave the URL. Can we make it clear whether we are allowed/supposed to use the short form: https://bugs.gentoo.org/333531 ? As that redirects to the longer form I don't see a problem with allowing that. Note that the short form does not allow for referencing individual comments, because https://bugs.gentoo.org/333531#c4 redirects to https://bugs.gentoo.org/show_bug.cgi?id=333531 and not https://bugs.gentoo.org/show_bug.cgi?id=333531#c4 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015, Ian Stakenvicius wrote: On 12/08/15 11:55 AM, Alexis Ballier wrote: I think it is better seen as a list of implications, esp. for this kind of questions :) With that in mind, there is no autounmask-write: effective USE for a given package is input USE with these implications applied. This very well summarises it. ..if I'm understanding what you're saying here, you see this as something the PM will use to adjust the input use list so that the emerge itself will go ahead with the newly adjusted flags; am I understanding that correctly? In other words, there won't be any user control/alert/override for what the default actions will be, if the user's profile isn't set up in a way that satisfies REQUIRED_USE, correct? so if I have 'app-cat/pkg qt4' in my package.use, but USE=qt5 in my profile, then because both flags end up being enabled the REQUIRED_USE=^^ ( +qt5 qt4 ) in app-cat/pkg will just force-off my package.use entry and everything will proceed as if it wasn't there? Indeed, maybe there would be too much magic at work there. However, note that also currently you won't be able to emerge the package with a package.use that results in conflicting flags. Ulrich pgp02Zm3PApGy.pgp Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
2 - is there a particular reasoning for the - in front of qt4
here? I only ask because it would seem that a single
default-enable should suffice in lists like this to indicate a
resolution path, no? That is, '^^ ( +flag1 -flag2 -flag3 -flag4
)' to me seems like it would be the same as '^^ ( +flag1 flag2
flag3 flag4 )'
If the user has both qt4 qt5, then enabling qt5 alone won't
help to resolve ^^ ( qt5 qt4 ).
Right, but the PM knows based on a particular REQUIRED_USE operator
what it would need to do when a particular flag is set to default.
Given '^^' is must-be-one-of, the +flag would be enabled and all the
other flags would be disabled, right?
Here's how I'd see it mapping out:
|| ( +flag1 flag2 ... ) , PM only forces-on flag1
^^ ( +flag1 flag2 ... ) , PM forces-on flag1, forces-off all others
?? ( +flag2 flag2 ... ) , PM forces off all but flag1
I'm not sure if the following make sense though... thoughts?
{,!}flag1? ( +flag2 ) , PM forces-on flag2
{,!}flag1? ( +!flag2 ) , PM forces !flag2, meaning forces-off flag2
I'm just wondering if it's really necessary in terms of syntax to
specify the flag-negation that the PM would need to do.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLevUACgkQAJxUfCtlWe2egAD+K8DCAD4UfqR3A6GKNBcSzIL9
9NaJrt8TX/LRl3uSP8MBAJjwh5ybmY42dEe3lTBlHhlAv7entRSdzKM6tmwB26WW
=scA5
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 12:53 PM, Ulrich Mueller wrote: On Wed, 12 Aug 2015, Ian Stakenvicius wrote: On 12/08/15 11:55 AM, Alexis Ballier wrote: I think it is better seen as a list of implications, esp. for this kind of questions :) With that in mind, there is no autounmask-write: effective USE for a given package is input USE with these implications applied. This very well summarises it. ..if I'm understanding what you're saying here, you see this as something the PM will use to adjust the input use list so that the emerge itself will go ahead with the newly adjusted flags; am I understanding that correctly? In other words, there won't be any user control/alert/override for what the default actions will be, if the user's profile isn't set up in a way that satisfies REQUIRED_USE, correct? so if I have 'app-cat/pkg qt4' in my package.use, but USE=qt5 in my profile, then because both flags end up being enabled the REQUIRED_USE=^^ ( +qt5 qt4 ) in app-cat/pkg will just force-off my package.use entry and everything will proceed as if it wasn't there? Indeed, maybe there would be too much magic at work there. However, note that also currently you won't be able to emerge the package with a package.use that results in conflicting flags. Ulrich How would that be determined, then? These REQUIRED_USE flag forces would somehow occur in between the USE= assignment from the profile/make.conf and the entries from package.use ? This is why I was wondering if it'd make more sense for these REQUIRE_USE defaults to just help portage resolve the deptree, and then --autounmask-write to fix package.use to match before proceeding. Not as nice to end-users I know, but at least portage would resolve currently-unresolvable solutions to a known default; afaik portage can't even suggest a default solution the way things are now, can it? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXLfAIACgkQAJxUfCtlWe1LhgEAtWKXnWtYLGxt/o6e+cKSXn3u VWidCNO/QKlT9Ji5uQQA/R9biZJqccv4I64JFW9tKWKAuWA3S67VaE9Rj/QZ3GNy =Mbw/ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Referencing bug reports in git
hasufell schrieb: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 As there was no formal call for a vote, I don't think you can take the number of voiced opinions as an indicator for the support of an option. After all, if someone's opinion is already sufficiently represented by an existing post, that person would not have reason to write to -dev and further clutter the discussion. The only thing you can derive from this counting is that consensus has not been reached. Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the https://bugs.gentoo.org/show_bug.cgi?id=; optional for Gentoo Bugzilla, would be a compromise I can accept. I would not like having to redundantly give the bug number when I already gave the URL. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Referencing bug reports in git
Dnia 2015-08-12, o godz. 17:59:03 Chí-Thanh Christopher Nguyễn chith...@gentoo.org napisał(a): hasufell schrieb: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 As there was no formal call for a vote, I don't think you can take the number of voiced opinions as an indicator for the support of an option. After all, if someone's opinion is already sufficiently represented by an existing post, that person would not have reason to write to -dev and further clutter the discussion. The only thing you can derive from this counting is that consensus has not been reached. Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the https://bugs.gentoo.org/show_bug.cgi?id=; optional for Gentoo Bugzilla, would be a compromise I can accept. I would not like having to redundantly give the bug number when I already gave the URL. Can we make it clear whether we are allowed/supposed to use the short form: https://bugs.gentoo.org/333531 ? -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpC1eGhgSGd0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:00 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
2 - is there a particular reasoning for the - in front of
qt4 here? I only ask because it would seem that a single
default-enable should suffice in lists like this to
indicate a resolution path, no? That is, '^^ ( +flag1
-flag2 -flag3 -flag4 )' to me seems like it would be the
same as '^^ ( +flag1 flag2 flag3 flag4 )'
If the user has both qt4 qt5, then enabling qt5 alone
won't help to resolve ^^ ( qt5 qt4 ).
Right, but the PM knows based on a particular REQUIRED_USE
operator what it would need to do when a particular flag is set
to default. Given '^^' is must-be-one-of, the +flag would be
enabled and all the other flags would be disabled, right?
Here's how I'd see it mapping out:
|| ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ ( +flag1
flag2 ... ) , PM forces-on flag1, forces-off all others ?? (
+flag2 flag2 ... ) , PM forces off all but flag1
I'm not sure if the following make sense though... thoughts?
{,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? ( +!flag2
) , PM forces !flag2, meaning forces-off flag2
I'm just wondering if it's really necessary in terms of syntax
to specify the flag-negation that the PM would need to do.
See my other email: neither + nor - are necessary :)
I'd disagree on that -- technically they aren't necessary, but the
whole reason why these new operators were added in the first place
was so that it's a lot easier for developers to fill in REQUIRED_USE
and get the logic right. Mapping out a ^^ ( flag1 flag2 flag3 flag4
) into all of its permissible flag-a? ( flagb !flagc !flagd )
variants is a royal pain. Plus there's
readability/understandability to consider here.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLfMYACgkQAJxUfCtlWe3JpQD9Gt87cclSsz3FTw5KbnlsSjVX
zf4FXOa4IMI4AcRCy+EA/37u0n/USxmMUDQxbVZT7Kp4O9EkdYR/DdNHQNUlBYMe
=Cpmr
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 12:57:25 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
2 - is there a particular reasoning for the - in front of qt4
here? I only ask because it would seem that a single
default-enable should suffice in lists like this to indicate a
resolution path, no? That is, '^^ ( +flag1 -flag2 -flag3 -flag4
)' to me seems like it would be the same as '^^ ( +flag1 flag2
flag3 flag4 )'
If the user has both qt4 qt5, then enabling qt5 alone won't
help to resolve ^^ ( qt5 qt4 ).
Right, but the PM knows based on a particular REQUIRED_USE operator
what it would need to do when a particular flag is set to default.
Given '^^' is must-be-one-of, the +flag would be enabled and all the
other flags would be disabled, right?
Here's how I'd see it mapping out:
|| ( +flag1 flag2 ... ) , PM only forces-on flag1
^^ ( +flag1 flag2 ... ) , PM forces-on flag1, forces-off all others
?? ( +flag2 flag2 ... ) , PM forces off all but flag1
I'm not sure if the following make sense though... thoughts?
{,!}flag1? ( +flag2 ) , PM forces-on flag2
{,!}flag1? ( +!flag2 ) , PM forces !flag2, meaning forces-off flag2
I'm just wondering if it's really necessary in terms of syntax to
specify the flag-negation that the PM would need to do.
See my other email: neither + nor - are necessary :)
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 11:08 AM, Ulrich Mueller wrote: On Wed, 12 Aug 2015, Alexis Ballier wrote: i.e. something that really tells the PM how to automate the choice: - 'qt5 - !qt4' is rather straightforward to solve and tells the PM how (note that it is not equivalent to 'qt4 - !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to automate it I was thinking about some syntax like this: REQUIRED_USE=|| ( +foo bar ) ^^ ( +qt5 -qt4 ) The package manager would first evaluate each group in REQUIRED_USE with the original set of USE flags. If that doesn't evaluate to true, retry with flags changed as indicated by the + and - signs. Ulrich Having the ability for REQUIRED_USE to provide a default resolution path should definitely help with things; I assume this is meant to do its work via --autounmask-write or similar, ie to help users adjust their config files? Or was the thought to allow PMs to override USE immediately? I think it is better seen as a list of implications, esp. for this kind of questions :) With that in mind, there is no autounmask-write: effective USE for a given package is input USE with these implications applied. Questions: 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE? This questions remains. I see use-defaults in IUSE as part of input USE above. [...] 3 - will having REQUIRED_USE be able to force flags on (and others off) likely result in abuse of profiles and other use defaults? I forsee this being a way, for instance, for a dev to get around users setting USE=-* in make.conf to ensure a default use flag setting is honoured. How? 4 - Will a change to which flag the '+' is on likely to require a revbump for VDB updates? For something like '^^ ( +qt4 qt5 )' I could see maintainers wanting to switch which flag is default across a bunch of packages at once when, say, the qt team wants qt5 to become the de-facto default. It'll require a rebuild for those whose default changes anyway. I'd say no revbump since we don't revbump all affected packages when we add default enabled flags to make.defaults. Alexis.
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 11:55 AM, Alexis Ballier wrote: On Wed, 12 Aug 2015 11:30:39 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 11:08 AM, Ulrich Mueller wrote: On Wed, 12 Aug 2015, Alexis Ballier wrote: i.e. something that really tells the PM how to automate the choice: - 'qt5 - !qt4' is rather straightforward to solve and tells the PM how (note that it is not equivalent to 'qt4 - !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to automate it I was thinking about some syntax like this: REQUIRED_USE=|| ( +foo bar ) ^^ ( +qt5 -qt4 ) The package manager would first evaluate each group in REQUIRED_USE with the original set of USE flags. If that doesn't evaluate to true, retry with flags changed as indicated by the + and - signs. Ulrich Having the ability for REQUIRED_USE to provide a default resolution path should definitely help with things; I assume this is meant to do its work via --autounmask-write or similar, ie to help users adjust their config files? Or was the thought to allow PMs to override USE immediately? I think it is better seen as a list of implications, esp. for this kind of questions :) With that in mind, there is no autounmask-write: effective USE for a given package is input USE with these implications applied. ..if I'm understanding what you're saying here, you see this as something the PM will use to adjust the input use list so that the emerge itself will go ahead with the newly adjusted flags; am I understanding that correctly? In other words, there won't be any user control/alert/override for what the default actions will be, if the user's profile isn't set up in a way that satisfies REQUIRED_USE, correct? so if I have 'app-cat/pkg qt4' in my package.use, but USE=qt5 in my profile, then because both flags end up being enabled the REQUIRED_USE=^^ ( +qt5 qt4 ) in app-cat/pkg will just force-off my package.use entry and everything will proceed as if it wasn't there? Questions: 1 - how does +foo in REQUIRED_USE relate to use-defaults set in IUSE? This questions remains. I see use-defaults in IUSE as part of input USE above. Yes, just as it is now, the use-defaults in IUSE are part of the input use. What I'm wondering is, would the +foo in REQUIRED_USE=|| ( +foo bar ) be something that should be used in combination with IUSE=+foo (perhaps even require it) or would its functionality and specification be entirely independent of it? Right now for ||(), setting IUSE=+foo gets around that issue in almost all cases, the only case it doesn't is when the user has explicitly set USE=-foo (or USE=-*). [...] 3 - will having REQUIRED_USE be able to force flags on (and others off) likely result in abuse of profiles and other use defaults? I forsee this being a way, for instance, for a dev to get around users setting USE=-* in make.conf to ensure a default use flag setting is honoured. How? This assumes that the PM will just set the flags that resolve the REQUIRED_USE directly (ie modify the input use based on the defaults provided) and go ahead, which seems to be what you're implying will be the implementation, earlier on. See my response re #1 above as well, since if I understand this correctly the REQUIRED_USE=|| ( +foo bar ) will set +foo even if USE=-* in the profile right? 4 - Will a change to which flag the '+' is on likely to require a revbump for VDB updates? For something like '^^ ( +qt4 qt5 )' I could see maintainers wanting to switch which flag is default across a bunch of packages at once when, say, the qt team wants qt5 to become the de-facto default. It'll require a rebuild for those whose default changes anyway. I'd say no revbump since we don't revbump all affected packages when we add default enabled flags to make.defaults. Thinking about it I think I answered my own question, in that there shouldn't be any need for this to affect VDB since the end-result is expressed in the state recorded in 'USE'. And no VDB change means no need for a revbump. Whether or not the change results in a rebuild on -N will depend on whether or not the state of the user's profile will result in a REQUIRED_USE conflict that needs to be default-resolved or not, and that's true from emerge to emerge no matter what. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXLc+MACgkQAJxUfCtlWe3GKgEAvfYZ3SD2NcKCeZjf4qlfzy2G Fjzfub0X2BfuiAVJnbgA/RIaxTQRGt7PL693qNS3HxOX/q2T7l6W3Hv105NeBTlT =S9wv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Referencing bug reports in git
Dnia 2015-08-12, o godz. 18:25:07 Chí-Thanh Christopher Nguyễn chith...@gentoo.org napisał(a): Michał Górny schrieb: Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the https://bugs.gentoo.org/show_bug.cgi?id=; optional for Gentoo Bugzilla, would be a compromise I can accept. I would not like having to redundantly give the bug number when I already gave the URL. Can we make it clear whether we are allowed/supposed to use the short form: https://bugs.gentoo.org/333531 ? As that redirects to the longer form I don't see a problem with allowing that. Note that the short form does not allow for referencing individual comments, because https://bugs.gentoo.org/333531#c4 redirects to https://bugs.gentoo.org/show_bug.cgi?id=333531 and not https://bugs.gentoo.org/show_bug.cgi?id=333531#c4 Well, to be clear it doesn't actually redirect. If you didn't use one of those fancy new-age web browsers, you'd notice #c4 works as expected. I suspect it does some fancy JavaScript addressbar update though. Anyway, breaking '#c4' should be definitely treated as a bug, not expected limitation. -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpkGDHB8vrMj.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Referencing bug reports in git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 12:34 PM, Michał Górny wrote: Dnia 2015-08-12, o godz. 18:25:07 Chí-Thanh Christopher Nguyễn chith...@gentoo.org napisał(a): Michał Górny schrieb: Bug: https://bugs.gentoo.org/show_bug.cgi?id=333531 format, with the https://bugs.gentoo.org/show_bug.cgi?id=; optional for Gentoo Bugzilla, would be a compromise I can accept. I would not like having to redundantly give the bug number when I already gave the URL. Can we make it clear whether we are allowed/supposed to use the short form: https://bugs.gentoo.org/333531 ? As that redirects to the longer form I don't see a problem with allowing that. Note that the short form does not allow for referencing individual comments, because https://bugs.gentoo.org/333531#c4 redirects to https://bugs.gentoo.org/show_bug.cgi?id=333531 and not https://bugs.gentoo.org/show_bug.cgi?id=333531#c4 Well, to be clear it doesn't actually redirect. If you didn't use one of those fancy new-age web browsers, you'd notice #c4 works as expected. I suspect it does some fancy JavaScript addressbar update though. Anyway, breaking '#c4' should be definitely treated as a bug, not expected limitation. Can we assume if a URL is to be the format, that any URL which resolves to whatever it is you're trying to link to is permitted (within reason, ideally we don't want ones with 128-character-long session-id hashes in them of course)..? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXLdtQACgkQAJxUfCtlWe06rQEAiTu9MxA6AeEnGXahOtd7c74U c0rLqHJcXmgRPrdj/qwA/2i7CtmCU2uNoaq0tlcaqIky6cgtxY7pQ9bNDTRM0ujH =1f2m -END PGP SIGNATURE-
Re: [gentoo-dev] git.gentoo.org: Could not read from remote repository
Hello possibly using wrong ssh key... I suggest to contact infra in case if you want to update your ssh key because in that case you should have same error accessing your LDAP workspace. On 12.08.2015 16:13, gro...@gentoo.org wrote: I'm trying to follow https://wiki.gentoo.org/wiki/Gentoo_git_workflow: grozin@elrond ~ $ git clone --depth=50 git+ssh://g...@git.gentoo.org/repo/gentoo.git Cloning into 'gentoo'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. What am I doing wrong? Andrey
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 05:21:20 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 11 Aug 2015 23:30:31 +1000 Michael Palimaka kensing...@gentoo.org wrote: I invite you to reproduce the problem yourself then make the judgement. Using REQUIRED_USE like this makes the affected packages unusable. Can't we all (except for the usual suspect) just agree that REQUIRED_USE was a mistake, and go back to pkg_pretend? The only justification for REQUIRED_USE was that it could allegedly be used in an automated fashion, and this hasn't happened. +1 or restrict it so that it is not yet another sat instance i.e. something that really tells the PM how to automate the choice: - 'qt5 - !qt4' is rather straightforward to solve and tells the PM how (note that it is not equivalent to 'qt4 - !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to automate it
[gentoo-dev] git.gentoo.org: Could not read from remote repository
I'm trying to follow https://wiki.gentoo.org/wiki/Gentoo_git_workflow: grozin@elrond ~ $ git clone --depth=50 git+ssh://g...@git.gentoo.org/repo/gentoo.git Cloning into 'gentoo'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. What am I doing wrong? Andrey
Re: [gentoo-dev] Re: useflag policies
On 08/12/2015 12:21 AM, Ciaran McCreesh wrote: On Tue, 11 Aug 2015 23:30:31 +1000 Michael Palimaka kensing...@gentoo.org wrote: I invite you to reproduce the problem yourself then make the judgement. Using REQUIRED_USE like this makes the affected packages unusable. Can't we all (except for the usual suspect) just agree that REQUIRED_USE was a mistake, and go back to pkg_pretend? The only justification for REQUIRED_USE was that it could allegedly be used in an automated fashion, and this hasn't happened. I'm starting to see the light. USE flags and their combinations/conflicts are almost always package- if not ebuild-specific. The problem isn't that REQUIRED_USE forces me to do something, it's that portage will only ever be able to output 45 pages of garbage rather than telling me how to fix it (which again, depends on the package/ebuild). At the very least, we need to be able to tag REQUIRED_USE conflicts with human readable error messages. OK, so I know I can't have USE=qt4 qt5 for this package... but why? How do I fix it? We can do that with pkg_pretend and a bunch of if statements, or maybe there's value in having the requirements in a variable -- who knows. The former is a lot simpler to implement.
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015, Alexis Ballier wrote: it is more in the line of what we currently do, but that doesn't resolve the 'sat' problem: it doesnt make clear we don't want to satisfy it but rather walk through a list of causes and consequences now that i'm thinking more about it, killing || and ^^ would probably solve the automation problem: qt? ( !qt4? ( qt5 ) qt4? ( !qt5 ) ) vs 'qt? ( ^^ ( qt4 qt5 ) )' a bit longer but PM now knows what to do [...] No need for a new syntax :) Indeed. What is the general opinion, would it be worth the price of somewhat longer expressions? Ulrich pgpO2bIpGyvzQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 09:38:19 -0500 William Hubbs willi...@gentoo.org wrote: I always wondered why pkg_pretend never caught on. I to can see the advantage of it over REQUIRED_USE; it would allow the package maintainer to give specific error messages about why use flag combinations are invalid for a package. Without really knowing what the opposing viewpoint is, I think pkg_pretend is the better way to go as well. The opposing viewpoint was ferringb believing he could do automatic dependency resolution for a build server setup, without trying it and without an implementation, and that a human-readable pkg_pretend would somehow preclude that. (Incidentally, Exherbo has automatic dependency resolution for a build server setup, and human-readable messages, and it got there by trying stuff out before inflicting it upon everyone by diktat...) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:22 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
On 12/08/15 01:00 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
2 - is there a particular reasoning for the - in
front of qt4 here? I only ask because it would seem
that a single default-enable should suffice in lists
like this to indicate a resolution path, no? That is,
'^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like
it would be the same as '^^ ( +flag1 flag2 flag3
flag4 )'
If the user has both qt4 qt5, then enabling qt5 alone
won't help to resolve ^^ ( qt5 qt4 ).
Right, but the PM knows based on a particular
REQUIRED_USE operator what it would need to do when a
particular flag is set to default. Given '^^' is
must-be-one-of, the +flag would be enabled and all the
other flags would be disabled, right?
Here's how I'd see it mapping out:
|| ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ (
+flag1 flag2 ... ) , PM forces-on flag1, forces-off all
others ?? ( +flag2 flag2 ... ) , PM forces off all but
flag1
I'm not sure if the following make sense though...
thoughts?
{,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? (
+!flag2 ) , PM forces !flag2, meaning forces-off flag2
I'm just wondering if it's really necessary in terms of
syntax to specify the flag-negation that the PM would
need to do.
See my other email: neither + nor - are necessary :)
I'd disagree on that -- technically they aren't necessary,
but the whole reason why these new operators were added in
the first place was so that it's a lot easier for developers
to fill in REQUIRED_USE and get the logic right. Mapping out
a ^^ ( flag1 flag2 flag3 flag4 ) into all of its permissible
flag-a? ( flagb !flagc !flagd ) variants is a royal pain.
Plus there's readability/understandability to consider here.
err, flaga? ( !flagb !flagc !flagd ) i mean..
It is indeed longer (n flags to roughly n² flags expanded i'd
say), but i disagree on the readability: i find it much more
readable as if flaga is enabled then flagb, flagc and flagd must
be disabled etc. which express clearly the preference than
exactly one of flaga flagb flagc flagd except if there is a
problem then flaga but not the others.
Also, there's something we've overseen with the +/- syntax: What
about ^^ ( +flaga -flagb -flagc -flagd ) with USE=-flaga flagb
flagc ? The only way to solve it would be USE=flaga -flagb
-flagc while the implication syntax could give you USE=-flaga
flagb -flagc (or any other preference of the ebuild writer).
I don't think we've overseen that. If there's a conflict due to any
two flags being set in ^^ ( +a b c d ), the default resolution is to
enable a and disable b,c,d. Doesn't matter if a is one of the ones
enabled or not.
If you want to try and roll out the syntax, such that for any
particular given set of flags being enabled there is a preferable
default, then yes it'll have to be written out longhand for sure.
OR we could just adjust PMS to assume flag order determines
precedence and still not bother with a new operator: For ^^ ( a b
c ) if a then b,c forced-off; elif b then c forced-off; elif !c
then a forced-on; fi
Finally, about getting the logic right, since it's a subset of
the current syntax I don't think that should be a problem :)
The superset of the {,!}flag1? ( {,!}flag2 ) syntax was requested
and created I believe -because- dev's were finding it
difficult/annoying to write the logic out longhand and get it right.
AND it made the messages a lot more clear to end-users too, as I
recall, as only-one-of ( flagset ) is a lot more clear and concise
than flag1-enabled so must-enable/disable-the-rest-in-flagset. I
didn't pay that much attention at the time though so if anyone
involved with those operator requests etc could chime in on
reasoning I'd appreciate it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLhMkACgkQAJxUfCtlWe2A3wEA0jrf9slDrcM92yhXpGpTzBbD
baQAYRUrJsNEI+frKx4BAM9gWVbmGr6U9KAwBdzUVkOFUmZmFj9h7BHFdDsniI1t
=7UNL
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 19:43:55 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Wed, 12 Aug 2015, Ulrich Mueller wrote:
Hm, how about adding a new PM command like required_use foo -bar?
It would be used exclusively in pkg_pretend, and tell the PM to
suggest the necessary package.use changes to the user (or even
update them automatically with the appropriate --autounmask-*
option).
To clarify, I'm thinking about something like this:
pkg_pretend() {
if use qt4; then
required_use -qt5
else
required_use qt5
fi
}
The advantage would be that any number of elog messages could be added
which would further explain things to the user.
And how would the PM understand that -qt5 is conditional upon qt4? Such
knowledge is required if it's supposed to auto-resolve stuff...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() {
if use qt4; then
required_use -qt5
else
required_use qt5
fi
}
And how would the PM understand that -qt5 is conditional upon qt4?
Such knowledge is required if it's supposed to auto-resolve stuff...
Right, the above was too simple (and wrong). It should have been:
pkg_pretend() {
use qt4 use qt5 required_use -qt5
use qt4 || use qt5 || required_use qt4
}
pgpm4i07nf1_x.pgp
Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 02:00 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 fi }
And how would the PM understand that -qt5 is conditional upon
qt4? Such knowledge is required if it's supposed to
auto-resolve stuff...
Right, the above was too simple (and wrong). It should have
been:
pkg_pretend() { use qt4 use qt5 required_use -qt5 use qt4
|| use qt5 || required_use qt4 }
I think Ciaran's point was more, if required_use is going to i.e.
elog, it needs to elog that qt4 is being enabled because neither-of
qt4 or qt5 are off, and similarly for why qt5 is being disabled.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLjdwACgkQAJxUfCtlWe3K6QD+L3kdVxSIJDp3N+wBZEtuhtNT
5kT7NXTdXuubE4Dgv7wA/1auz4k+rYQDZP7DP+i/JsHA/RMhOgUt7yc5a0H8yYHS
=FXa+
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 20:00:42 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() {
if use qt4; then
required_use -qt5
else
required_use qt5
fi
}
And how would the PM understand that -qt5 is conditional upon qt4?
Such knowledge is required if it's supposed to auto-resolve stuff...
Right, the above was too simple (and wrong). It should have been:
pkg_pretend() {
use qt4 use qt5 required_use -qt5
use qt4 || use qt5 || required_use qt4
}
Doesn't help the PM, unless you're expecting it to parse bash code...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 14:36:12 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 01:52 PM, Alexis Ballier wrote: On Wed, 12 Aug 2015 13:39:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: ...OR we could just adjust PMS to assume flag order determines precedence and still not bother with a new operator: For ^^ ( a b c ) if a then b,c forced-off; elif b then c forced-off; elif !c then a forced-on; fi that's another possible option indeed Is this something that we would need to change PMS for? Syntax stays the same, just the way portage (in particular here) acts on it would be different... For testing, is what I'm thinking, say tied to a resolve-required-use feature? If we don't -need- to change PMS we could just -do- this and see if it works. we could since that's de facto equivalent to the +/- syntax; however, I have serious doubts that the outcome will be what people who wrote the REQUIRED_USE line intended that'd be a very good proof of concept though
Re: [gentoo-dev] Re: useflag policies
Sergey Popov wrote: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. May I suggest instead: qt? ( qt5? ( dev-lang/qt$something:5 ) qt4? ( dev-lang/qt$something:4 ) ) Alexandre Rostovtsev wrote: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. That flag should be called gui. Not qt. This would be the real solution to gnome team's gtk/gtk2/gtk3 flag problem and to qt team's flag problem too. Unlike gtk+, using Qt does not mean that there is any GUI. Qt provides many things, and sometimes non-GUI Qt bits are used independently in console-only applications. //Peter
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 14:24:06 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 02:19 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 20:00:42 +0200 Ulrich Mueller
u...@gentoo.org wrote:
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 fi }
And how would the PM understand that -qt5 is conditional upon
qt4? Such knowledge is required if it's supposed to
auto-resolve stuff...
Right, the above was too simple (and wrong). It should have
been:
pkg_pretend() { use qt4 use qt5 required_use -qt5 use qt4
|| use qt5 || required_use qt4 }
what is the difference ?
pkg_pretend still needs to be executed to guess what useflags
are enabled or not, which information is needed before
dependency calculation
or are we talking about moving pkg_pretend into dependency
calculation?
pkg_pretend is already executed during dependency calculation in
portage, although this doesn't seem to actually be specified in PMS:
The pkg_pretend function is called some unspecified time before a
(possibly hypothetical) normal sequence. as per PMS sec.9.2
that's definitely not the impression I've got with emerge -uDNa world:
dep calculation, show result, wait for input, accept, and then
pkg_pretend stuff gets executed.
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 03:15 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 14:24:06 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 02:19 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 20:00:42 +0200 Ulrich Mueller
u...@gentoo.org wrote:
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 fi }
And how would the PM understand that -qt5 is conditional
upon qt4? Such knowledge is required if it's supposed to
auto-resolve stuff...
Right, the above was too simple (and wrong). It should
have been:
pkg_pretend() { use qt4 use qt5 required_use -qt5 use
qt4 || use qt5 || required_use qt4 }
what is the difference ?
pkg_pretend still needs to be executed to guess what
useflags are enabled or not, which information is needed
before dependency calculation
or are we talking about moving pkg_pretend into dependency
calculation?
pkg_pretend is already executed during dependency calculation
in portage, although this doesn't seem to actually be specified
in PMS: The pkg_pretend function is called some unspecified
time before a (possibly hypothetical) normal sequence. as per
PMS sec.9.2
that's definitely not the impression I've got with emerge -uDNa
world: dep calculation, show result, wait for input, accept, and
then pkg_pretend stuff gets executed.
Apologies if I'm wrong on that; i'm rather sleep deprived and i
didn't actually check an emerge -uDN before I posted. I was sure i
saw the checking for sufficient space messages show up during the
dependency-calcs though.
Regardless, the role and point of execution of pkg_pretend would
definitely need to be clarified in PMS as yes we would be talking
about ensuring it happens at a specific point in the dependency
calculation process for each package.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLnIEACgkQAJxUfCtlWe1RpQD9H0WKWDdl7tVHj6KgOoOHPswT
kPQQ0GFadfeo/isbxesBAIEL24JrVyzAEDY2KrofwYe+OVE3LV71jwMpnaGIBAHL
=AMxp
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 19:25:37 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2015 20:19:08 +0200 Alexis Ballier aball...@gentoo.org wrote: pkg_pretend still needs to be executed to guess what useflags are enabled or not, which information is needed before dependency calculation You'd probably be implementing this in a SAT modulo theories kind of way: find a solution, do the pkg_pretend checks, and if it fails spit a nogood back into the resolver. But this entire discussion is pointless, since Portage doesn't and won't auto-resolve this stuff. considering its speed (at least for portage) and the complexity of the thing, running the dep solver N times, where N is probably unbounded doesn't seem benefical at all esp. since a modified REQUIRED_USE can achieve the same
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015, Ciaran McCreesh wrote: The opposing viewpoint was ferringb believing he could do automatic dependency resolution for a build server setup, without trying it and without an implementation, and that a human-readable pkg_pretend would somehow preclude that. Hm, how about adding a new PM command like required_use foo -bar? It would be used exclusively in pkg_pretend, and tell the PM to suggest the necessary package.use changes to the user (or even update them automatically with the appropriate --autounmask-* option). REQUIRED_USE could be banned at the same time. Ulrich pgpqDaZ8sQAQf.pgp Description: PGP signature
Re: [gentoo-dev] Re: Referencing bug reports in git
On Wed, Aug 12, 2015 at 3:40 AM, hasufell hasuf...@gentoo.org wrote: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 I'm in favor of Gentoo-Bug: url in case we're voting. I don't see much use in the Gentoo- prefix if it's a URL though. In that case, just Bug: url seems better.
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 01:38 PM, Ulrich Mueller wrote: On Wed, 12 Aug 2015, Ciaran McCreesh wrote: The opposing viewpoint was ferringb believing he could do automatic dependency resolution for a build server setup, without trying it and without an implementation, and that a human-readable pkg_pretend would somehow preclude that. Hm, how about adding a new PM command like required_use foo -bar? It would be used exclusively in pkg_pretend, and tell the PM to suggest the necessary package.use changes to the user (or even update them automatically with the appropriate --autounmask-* option). REQUIRED_USE could be banned at the same time. Ulrich That's an interesting idea from the PM perspective do we have any functions that can directly affect deptree calculations now? Crossing that line is the only thing I forsee right now as being the main issue with this one. Would the 'required_use' function just suggest/set/force the necessary change or would it perform the logic too? ie, would we just call 'required_use foo -bar', or would we: 'if use foo use bar ; then required_use foo -bar ; fi' ? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXLhpgACgkQAJxUfCtlWe0bXwEAtDn5LL2VE0xBJqVxQ193kPeo Wn8sm6ud5YgUA2hJkBMA/0IDzi4hg7UZsnqdw59m/DGiYE6Devlfo4LoactUVpDD =4bED -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Referencing bug reports in git
On 08/12/2015 08:38 PM, Matt Turner wrote: On Wed, Aug 12, 2015 at 3:40 AM, hasufell hasuf...@gentoo.org wrote: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 I'm in favor of Gentoo-Bug: url in case we're voting. May be Bug-Gentoo should be used instead. It's to use the same header name format as Debian in their patches (Bug-Debian). -- Best regards, Dmitry signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 13:39:21 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:22 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
On 12/08/15 01:00 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
2 - is there a particular reasoning for the - in
front of qt4 here? I only ask because it would seem
that a single default-enable should suffice in lists
like this to indicate a resolution path, no? That is,
'^^ ( +flag1 -flag2 -flag3 -flag4 )' to me seems like
it would be the same as '^^ ( +flag1 flag2 flag3
flag4 )'
If the user has both qt4 qt5, then enabling qt5 alone
won't help to resolve ^^ ( qt5 qt4 ).
Right, but the PM knows based on a particular
REQUIRED_USE operator what it would need to do when a
particular flag is set to default. Given '^^' is
must-be-one-of, the +flag would be enabled and all the
other flags would be disabled, right?
Here's how I'd see it mapping out:
|| ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ (
+flag1 flag2 ... ) , PM forces-on flag1, forces-off all
others ?? ( +flag2 flag2 ... ) , PM forces off all but
flag1
I'm not sure if the following make sense though...
thoughts?
{,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? (
+!flag2 ) , PM forces !flag2, meaning forces-off flag2
I'm just wondering if it's really necessary in terms of
syntax to specify the flag-negation that the PM would
need to do.
See my other email: neither + nor - are necessary :)
I'd disagree on that -- technically they aren't necessary,
but the whole reason why these new operators were added in
the first place was so that it's a lot easier for developers
to fill in REQUIRED_USE and get the logic right. Mapping out
a ^^ ( flag1 flag2 flag3 flag4 ) into all of its permissible
flag-a? ( flagb !flagc !flagd ) variants is a royal pain.
Plus there's readability/understandability to consider here.
err, flaga? ( !flagb !flagc !flagd ) i mean..
It is indeed longer (n flags to roughly n² flags expanded i'd
say), but i disagree on the readability: i find it much more
readable as if flaga is enabled then flagb, flagc and flagd must
be disabled etc. which express clearly the preference than
exactly one of flaga flagb flagc flagd except if there is a
problem then flaga but not the others.
Also, there's something we've overseen with the +/- syntax: What
about ^^ ( +flaga -flagb -flagc -flagd ) with USE=-flaga flagb
flagc ? The only way to solve it would be USE=flaga -flagb
-flagc while the implication syntax could give you USE=-flaga
flagb -flagc (or any other preference of the ebuild writer).
I don't think we've overseen that. If there's a conflict due to any
two flags being set in ^^ ( +a b c d ), the default resolution is to
enable a and disable b,c,d. Doesn't matter if a is one of the ones
enabled or not.
If you want to try and roll out the syntax, such that for any
particular given set of flags being enabled there is a preferable
default, then yes it'll have to be written out longhand for sure.
OR we could just adjust PMS to assume flag order determines
precedence and still not bother with a new operator: For ^^ ( a b
c ) if a then b,c forced-off; elif b then c forced-off; elif !c
then a forced-on; fi
that's another possible option indeed
Finally, about getting the logic right, since it's a subset of
the current syntax I don't think that should be a problem :)
The superset of the {,!}flag1? ( {,!}flag2 ) syntax was requested
and created I believe -because- dev's were finding it
difficult/annoying to write the logic out longhand and get it right.
:)
I'd rather bet it's been copied from what we're used to: license dep
strings.
AND it made the messages a lot more clear to end-users too, as I
recall, as only-one-of ( flagset ) is a lot more clear and concise
than flag1-enabled so must-enable/disable-the-rest-in-flagset. I
didn't pay that much attention at the time though so if anyone
involved with those operator requests etc could chime in on
reasoning I'd appreciate it.
I think autounmask-write is much more clear than any kind of error
message
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/08/15 01:52 PM, Alexis Ballier wrote: On Wed, 12 Aug 2015 13:39:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: ...OR we could just adjust PMS to assume flag order determines precedence and still not bother with a new operator: For ^^ ( a b c ) if a then b,c forced-off; elif b then c forced-off; elif !c then a forced-on; fi that's another possible option indeed Is this something that we would need to change PMS for? Syntax stays the same, just the way portage (in particular here) acts on it would be different... For testing, is what I'm thinking, say tied to a resolve-required-use feature? If we don't -need- to change PMS we could just -do- this and see if it works. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXLkhwACgkQAJxUfCtlWe2icgD/fvbn2O70mE2QJs5+mOfxwZEx Y6huevd2KkJnaEHmlPEBAOvLe3gLDR/KUgvQVytBAXxgu+XsDcN/SDZEt94K0ptE =ySbZ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 13:06:43 -0400
Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:05 PM, Ian Stakenvicius wrote:
On 12/08/15 01:00 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius
a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 12/08/15 12:42 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ian Stakenvicius wrote:
2 - is there a particular reasoning for the - in front
of qt4 here? I only ask because it would seem that a
single default-enable should suffice in lists like this
to indicate a resolution path, no? That is, '^^ ( +flag1
-flag2 -flag3 -flag4 )' to me seems like it would be the
same as '^^ ( +flag1 flag2 flag3 flag4 )'
If the user has both qt4 qt5, then enabling qt5 alone
won't help to resolve ^^ ( qt5 qt4 ).
Right, but the PM knows based on a particular REQUIRED_USE
operator what it would need to do when a particular flag is
set to default. Given '^^' is must-be-one-of, the +flag would
be enabled and all the other flags would be disabled, right?
Here's how I'd see it mapping out:
|| ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ (
+flag1 flag2 ... ) , PM forces-on flag1, forces-off all
others ?? ( +flag2 flag2 ... ) , PM forces off all but flag1
I'm not sure if the following make sense though... thoughts?
{,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? (
+!flag2 ) , PM forces !flag2, meaning forces-off flag2
I'm just wondering if it's really necessary in terms of
syntax to specify the flag-negation that the PM would need to
do.
See my other email: neither + nor - are necessary :)
I'd disagree on that -- technically they aren't necessary, but
the whole reason why these new operators were added in the first
place was so that it's a lot easier for developers to fill in
REQUIRED_USE and get the logic right. Mapping out a ^^ ( flag1
flag2 flag3 flag4 ) into all of its permissible flag-a? ( flagb
!flagc !flagd ) variants is a royal pain. Plus there's
readability/understandability to consider here.
err, flaga? ( !flagb !flagc !flagd ) i mean..
It is indeed longer (n flags to roughly n² flags expanded i'd say), but
i disagree on the readability: i find it much more readable as if
flaga is enabled then flagb, flagc and flagd must be disabled etc.
which express clearly the preference than exactly one of flaga flagb
flagc flagd except if there is a problem then flaga but not the others.
Also, there's something we've overseen with the +/- syntax: What about
^^ ( +flaga -flagb -flagc -flagd ) with USE=-flaga flagb flagc ?
The only way to solve it would be USE=flaga -flagb -flagc while the
implication syntax could give you USE=-flaga flagb -flagc (or any
other preference of the ebuild writer).
Finally, about getting the logic right, since it's a subset of the
current syntax I don't think that should be a problem :)
Alexis.
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 19:38:21 +0200 Ulrich Mueller u...@gentoo.org wrote: On Wed, 12 Aug 2015, Ciaran McCreesh wrote: The opposing viewpoint was ferringb believing he could do automatic dependency resolution for a build server setup, without trying it and without an implementation, and that a human-readable pkg_pretend would somehow preclude that. Hm, how about adding a new PM command like required_use foo -bar? It would be used exclusively in pkg_pretend, and tell the PM to suggest the necessary package.use changes to the user (or even update them automatically with the appropriate --autounmask-* option). REQUIRED_USE could be banned at the same time. Why add support for a hypothetical package mangler feature that doesn't exist and that isn't necessary in practice? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015, Ulrich Mueller wrote:
Hm, how about adding a new PM command like required_use foo -bar?
It would be used exclusively in pkg_pretend, and tell the PM to
suggest the necessary package.use changes to the user (or even update
them automatically with the appropriate --autounmask-* option).
To clarify, I'm thinking about something like this:
pkg_pretend() {
if use qt4; then
required_use -qt5
else
required_use qt5
fi
}
The advantage would be that any number of elog messages could be added
which would further explain things to the user.
Ulrich
pgp6Y2g0jbm_a.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Referencing bug reports in git
On 08/12/2015 07:48 PM, Dmitry Yu Okunev wrote: On 08/12/2015 08:38 PM, Matt Turner wrote: On Wed, Aug 12, 2015 at 3:40 AM, hasufell hasuf...@gentoo.org wrote: So, I've just tried to count the ++ for different ideas and even if I missed one or two or misread someone's opinion, I think the result is pretty clear: reference the bug only in the summary: 1 don't make any of this mandatory: 1 Gentoo-Bug: 123 or similar short form: 9 Gentoo-Bug: url or similar long form: 2-3 I'm in favor of Gentoo-Bug: url in case we're voting. May be Bug-Gentoo should be used instead. It's to use the same header name format as Debian in their patches (Bug-Debian). I'm out of the discussion. Do whatever you want with bug references. We clearly need more different opinions. Someone end the bikeshed train please.
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 01:50 PM, Ciaran McCreesh wrote:
On Wed, 12 Aug 2015 19:43:55 +0200 Ulrich Mueller
u...@gentoo.org wrote:
On Wed, 12 Aug 2015, Ulrich Mueller wrote:
Hm, how about adding a new PM command like required_use foo
-bar? It would be used exclusively in pkg_pretend, and tell
the PM to suggest the necessary package.use changes to the
user (or even update them automatically with the appropriate
--autounmask-* option).
To clarify, I'm thinking about something like this:
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 fi }
The advantage would be that any number of elog messages could
be added which would further explain things to the user.
And how would the PM understand that -qt5 is conditional upon
qt4? Such knowledge is required if it's supposed to auto-resolve
stuff...
I don't think required_use could auto-resolve here, without some
other rather large changes to PMs -- for instance, the spec
pkg_pretend likely needs to be assured to be taken into account
before dependency resolution of that package somehow.
Also, the required_use function needs to be permitted to modify
effective-use and/or do whatever else it does, meaning that for what
I believe is the first time we will have function calls in ebuilds
modifying the precursors to dependency resolution dynamically rather
than it being deterministic based on state and pre-defined static
logic. (i hope that makes sense, unsure if i'm using anything even
close to the correct terminology)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLjWcACgkQAJxUfCtlWe2eDwEAzIcJWKlyFVbKzRCWIYEzP+JX
DxdOOgnWd9IVfVdwAqQBAOQaJuXjPPpahfyq0qGQDjX6YKhGY2M2b/D/LjIV81HW
=oko+
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 20:00:42 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() {
if use qt4; then
required_use -qt5
else
required_use qt5
fi
}
And how would the PM understand that -qt5 is conditional upon qt4?
Such knowledge is required if it's supposed to auto-resolve stuff...
Right, the above was too simple (and wrong). It should have been:
pkg_pretend() {
use qt4 use qt5 required_use -qt5
use qt4 || use qt5 || required_use qt4
}
what is the difference ?
pkg_pretend still needs to be executed to guess what useflags are
enabled or not, which information is needed before dependency
calculation
or are we talking about moving pkg_pretend into dependency calculation?
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 02:18 PM, Ian Stakenvicius wrote:
On 12/08/15 02:00 PM, Ulrich Mueller wrote:
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 fi }
And how would the PM understand that -qt5 is conditional
upon qt4? Such knowledge is required if it's supposed to
auto-resolve stuff...
Right, the above was too simple (and wrong). It should have
been:
pkg_pretend() { use qt4 use qt5 required_use -qt5 use
qt4 || use qt5 || required_use qt4 }
I think Ciaran's point was more, if required_use is going to
i.e. elog, it needs to elog that qt4 is being enabled because
neither-of qt4 or qt5 are *ON*, and similarly for why qt5 is
being disabled.
^^^ corrected logic
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLjh8ACgkQAJxUfCtlWe3TTAEAuJPVQQ9yoWBeBTRH2AFnFZoW
3aWWdhmClQRMo3MI43IBANkaRZOtWHhnWi31wvK+Pw0GvzkAmzEaWOFS7YxxWORO
=ccVT
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 20:19:08 +0200 Alexis Ballier aball...@gentoo.org wrote: pkg_pretend still needs to be executed to guess what useflags are enabled or not, which information is needed before dependency calculation You'd probably be implementing this in a SAT modulo theories kind of way: find a solution, do the pkg_pretend checks, and if it fails spit a nogood back into the resolver. But this entire discussion is pointless, since Portage doesn't and won't auto-resolve this stuff. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 17:08:59 +0200 Ulrich Mueller u...@gentoo.org wrote: On Wed, 12 Aug 2015, Alexis Ballier wrote: i.e. something that really tells the PM how to automate the choice: - 'qt5 - !qt4' is rather straightforward to solve and tells the PM how (note that it is not equivalent to 'qt4 - !qt5') - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to automate it I was thinking about some syntax like this: REQUIRED_USE=|| ( +foo bar ) ^^ ( +qt5 -qt4 ) The package manager would first evaluate each group in REQUIRED_USE with the original set of USE flags. If that doesn't evaluate to true, retry with flags changed as indicated by the + and - signs. The problem with REQUIRED_USE was someone having an idea and not implementing it and trying it out before inflicting it upon people. Why not start with a test implementation? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/08/15 02:19 PM, Alexis Ballier wrote:
On Wed, 12 Aug 2015 20:00:42 +0200 Ulrich Mueller
u...@gentoo.org wrote:
On Wed, 12 Aug 2015, Ciaran McCreesh wrote:
pkg_pretend() { if use qt4; then required_use -qt5 else
required_use qt5 fi }
And how would the PM understand that -qt5 is conditional upon
qt4? Such knowledge is required if it's supposed to
auto-resolve stuff...
Right, the above was too simple (and wrong). It should have
been:
pkg_pretend() { use qt4 use qt5 required_use -qt5 use qt4
|| use qt5 || required_use qt4 }
what is the difference ?
pkg_pretend still needs to be executed to guess what useflags
are enabled or not, which information is needed before
dependency calculation
or are we talking about moving pkg_pretend into dependency
calculation?
pkg_pretend is already executed during dependency calculation in
portage, although this doesn't seem to actually be specified in PMS:
The pkg_pretend function is called some unspecified time before a
(possibly hypothetical) normal sequence. as per PMS sec.9.2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXLj0YACgkQAJxUfCtlWe1NwgD/UlFiaP1Xyh4yfHlEH+nGIYN/
NTqMi1IFiKXpgKJjVWEA/1BdSHkivkFhodChHJ0jlYCX9xHg0Xc0VDzPN0S1aPRn
=KQmI
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
On Wed, 12 Aug 2015 21:22:48 +0200 Alexis Ballier aball...@gentoo.org wrote: On Wed, 12 Aug 2015 19:25:37 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2015 20:19:08 +0200 Alexis Ballier aball...@gentoo.org wrote: pkg_pretend still needs to be executed to guess what useflags are enabled or not, which information is needed before dependency calculation You'd probably be implementing this in a SAT modulo theories kind of way: find a solution, do the pkg_pretend checks, and if it fails spit a nogood back into the resolver. But this entire discussion is pointless, since Portage doesn't and won't auto-resolve this stuff. considering its speed (at least for portage) and the complexity of the thing, running the dep solver N times, where N is probably unbounded doesn't seem benefical at all esp. since a modified REQUIRED_USE can achieve the same But you'd be running it N times to fix a REQUIRED_USE problem anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
