Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub

[Michał Górny]

Dnia 2015-08-12, o godz. 22:43:24
Dean Stephens  napisał(a):

> 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?

Because:

a) LDAP is PITA,

b) therefore almost nobody cares to update team listings except for
occasional updates when they happen to need to change SSH keys or
something,

c) team listings in LDAP are cleartext and completely random.

-- 
Best regards,
Michał Górny



pgpb5klI8FvDV.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: useflag policies

[Zac Medico]

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

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

On Wed, 12 Aug 2015 18:03:52 +0200
Michał Górny  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] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Gilbert]

On Wed, Aug 12, 2015 at 11:17 PM, Mike Frysinger  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 
> +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.

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Mike Frysinger]

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

[gentoo-dev] [PATCH] document openssh-7.0 dsa key change #557388

[Mike Frysinger]

---
 .../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 
+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] .gitignore

[Mike Frysinger]

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] Mirroring Gentoo project/team members on GitHub

[Dean Stephens]

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?

Re: [gentoo-dev] Referencing bug reports in git

[Steev Klimaszewski]

> 
> Someone end the bikeshed train please.

Seconded.

Re: [gentoo-dev] .gitignore

[Mike Gilbert]

On Wed, Aug 12, 2015 at 6:22 PM, Alan McKinnon  wrote:
> On 13/08/2015 00:21, James Le Cuirot wrote:
>> On Thu, 13 Aug 2015 00:11:45 +0200
>> Alan McKinnon  wrote:
>>
>>> On 12/08/2015 23:29, James Le Cuirot wrote:
 Mike Frysinger  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 
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] .gitignore

[Brian Dolbec]

On Thu, 13 Aug 2015 00:22:34 +0200
Alan McKinnon  wrote:

> On 13/08/2015 00:21, James Le Cuirot wrote:
> > On Thu, 13 Aug 2015 00:11:45 +0200
> > Alan McKinnon  wrote:
> > 
> >> On 12/08/2015 23:29, James Le Cuirot wrote:
> >>> Mike Frysinger  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 

Re: [gentoo-dev] Re: useflag policies

[Patrick Lauer]

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] Introduce ppc64le architecture into gentoo ! please share your comments

[姜渠]

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 ?

>
>
-- Linda

Re: [gentoo-dev] .gitignore

[Alan McKinnon]

On 13/08/2015 00:21, James Le Cuirot wrote:
> On Thu, 13 Aug 2015 00:11:45 +0200
> Alan McKinnon  wrote:
> 
>> On 12/08/2015 23:29, James Le Cuirot wrote:
>>> Mike Frysinger  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] .gitignore

[James Le Cuirot]

On Thu, 13 Aug 2015 00:11:45 +0200
Alan McKinnon  wrote:

> On 12/08/2015 23:29, James Le Cuirot wrote:
> > Mike Frysinger  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

[Alan McKinnon]

On 12/08/2015 23:29, James Le Cuirot wrote:
> Mike Frysinger  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] .gitignore

[James Le Cuirot]

Mike Frysinger  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] Re: useflag policies

[Kent Fredric]

On 12 August 2015 at 16:21, Ciaran McCreesh
 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] Re: useflag policies

[Ciaran McCreesh]

On Wed, 12 Aug 2015 21:22:48 +0200
Alexis Ballier  wrote:
> On Wed, 12 Aug 2015 19:25:37 +0100
> Ciaran McCreesh  wrote:
> > On Wed, 12 Aug 2015 20:19:08 +0200
> > Alexis Ballier  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

Re: [gentoo-dev] Re: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 19:25:37 +0100
Ciaran McCreesh  wrote:

> On Wed, 12 Aug 2015 20:19:08 +0200
> Alexis Ballier  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

[Ian Stakenvicius]

-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
>  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 
>>>  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

[Alexis Ballier]

On Wed, 12 Aug 2015 14:24:06 -0400
Ian Stakenvicius  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
> >  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

[Peter Stuge]

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

[Alexis Ballier]

On Wed, 12 Aug 2015 14:36:12 -0400
Ian Stakenvicius  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
> >  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

[Ian Stakenvicius]

-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
>  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

[Ciaran McCreesh]

On Wed, 12 Aug 2015 20:19:08 +0200
Alexis Ballier  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

[Ian Stakenvicius]

-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

[Ciaran McCreesh]

On Wed, 12 Aug 2015 20:00:42 +0200
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
> }

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

[Ian Stakenvicius]

-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
>  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

[Ian Stakenvicius]

-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

[Alexis Ballier]

On Wed, 12 Aug 2015 20:00:42 +0200
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
> }

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

[Ian Stakenvicius]

-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
>  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

[Ulrich Mueller]

> 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: Referencing bug reports in git

[hasufell]

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  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: " or similar long form: 2-3
>>
>> I'm in favor of Gentoo-Bug:  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

[Alexis Ballier]

On Wed, 12 Aug 2015 13:39:21 -0400
Ian Stakenvicius  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
> >  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 
>   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

Re: [gentoo-dev] Re: useflag policies

[Ciaran McCreesh]

On Wed, 12 Aug 2015 19:43:55 +0200
Ulrich Mueller  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: Referencing bug reports in git

[Dmitry Yu Okunev]

On 08/12/2015 08:38 PM, Matt Turner wrote:
> On Wed, Aug 12, 2015 at 3:40 AM, hasufell  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: " or similar long form: 2-3
> 
> I'm in favor of Gentoo-Bug:  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

[Ian Stakenvicius]

-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: useflag policies

[Ulrich Mueller]

> 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: useflag policies

[Ciaran McCreesh]

On Wed, 12 Aug 2015 19:38:21 +0200
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.

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

[Ian Stakenvicius]

-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
>  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 
  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: Referencing bug reports in git

[Matt Turner]

On Wed, Aug 12, 2015 at 3:40 AM, hasufell  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: " or similar long form: 2-3

I'm in favor of Gentoo-Bug:  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:  seems better.

Re: [gentoo-dev] Re: useflag policies

[Ulrich Mueller]

> 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: useflag policies

[Ciaran McCreesh]

On Wed, 12 Aug 2015 09:38:19 -0500
William Hubbs  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

[Alexis Ballier]

On Wed, 12 Aug 2015 13:06:43 -0400
Ian Stakenvicius  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 
> >>  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

[Ciaran McCreesh]

On Wed, 12 Aug 2015 17:08:59 +0200
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.

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

[Ulrich Mueller]

> 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

[Ian Stakenvicius]

-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 
>>  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: useflag policies

[Ian Stakenvicius]

-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
>  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

[Ian Stakenvicius]

-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: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 12:57:25 -0400
Ian Stakenvicius  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

[Alexis Ballier]

On Wed, 12 Aug 2015 12:27:15 -0400
Ian Stakenvicius  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
> >  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

[Ian Stakenvicius]

-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

[Ulrich Mueller]

> 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

[Ulrich Mueller]

> 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: Referencing bug reports in git

[Ian Stakenvicius]

-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
>  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] Re: Referencing bug reports in git

[Michał Górny]

Dnia 2015-08-12, o godz. 18:25:07
Chí-Thanh Christopher Nguyễn  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



pgpkGDHB8vrMj.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

-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
>  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

[Chí-Thanh Christopher Nguyễn]

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: Referencing bug reports in git

[hasufell]

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: " 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]

Dnia 2015-08-12, o godz. 17:59:03
Chí-Thanh Christopher Nguyễn  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: " 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



pgpC1eGhgSGd0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Referencing bug reports in git

[Chí-Thanh Christopher Nguyễn]

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: " 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: useflag policies

[Alexis Ballier]

On Wed, 12 Aug 2015 11:30:39 -0400
Ian Stakenvicius  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

[Alexis Ballier]

On Wed, 12 Aug 2015 17:08:59 +0200
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.


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


both are equally expressive:

|| ( a b ) <-> !a? ( b )
(or !b? ( a ) depending on preference)
Here PM will enable b if a is disabled (a if b is disabled in the
latter form)

^^ ( a b ) <-> !a? ( b ) a? ( !b )
Here PM will enable b if a is disabled; disable b if a is enabled


No need for a new syntax :)

Alexis.

Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

-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] Re: useflag policies

[Ulrich Mueller]

> 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

[Ian Stakenvicius]

-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

[William Hubbs]

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  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

[Michael Orlitzky]

On 08/12/2015 12:21 AM, Ciaran McCreesh wrote:
> On Tue, 11 Aug 2015 23:30:31 +1000
> Michael Palimaka  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

[Alexis Ballier]

On Wed, 12 Aug 2015 05:21:20 +0100
Ciaran McCreesh  wrote:

> On Tue, 11 Aug 2015 23:30:31 +1000
> Michael Palimaka  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

Re: [gentoo-dev] git.gentoo.org: Could not read from remote repository

[Heather]

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

[gentoo-dev] git.gentoo.org: Could not read from remote repository

[grozin]

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

[gentoo-dev] Re: Referencing bug reports in git

[hasufell]

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: " or similar long form: 2-3

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/

[hasufell]

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  gentoo  org>
 AuthorDate: Tue Aug 11 06:28:16 2015 +
 Commit: Mike Frysinger  gentoo  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] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/

[hasufell]

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  gentoo  org>
>>> AuthorDate: Tue Aug 11 06:28:16 2015 +
>>> Commit: Mike Frysinger  gentoo  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.

Re: [gentoo-powerpc] Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Luca Barbato]

On 12/08/15 11:46, Shuai Zhao wrote:
> 2015-08-12 15:47 GMT+08:00 Mike Frysinger :
> 
>> 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] Introduce ppc64le architecture into gentoo ! please share your comments

[Shuai Zhao]

2015-08-12 15:47 GMT+08:00 Mike Frysinger :

> 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.

[gentoo-dev] Re: Bisecting Was: Referencing bug reports in git

[Duncan]

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

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Anthony G. Basile]

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] Mirroring Gentoo project/team members on GitHub

[Heather]

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?

[gentoo-dev] Re: useflag policies

[Duncan]

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

[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

> 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

Re: [gentoo-dev] Bisecting Was: Referencing bug reports in git

[Jason Zaman]

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_workflow&diff=352978&oldid=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
> 
> 

[gentoo-dev] Re: useflag policies

[Duncan]

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

[gentoo-dev] Bisecting Was: Referencing bug reports in git

[Duncan]

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_workflow&diff=352978&oldid=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

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Leno Hou]

On Wed, Aug 12, 2015 at 11:50 AM, Mike Frysinger  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