Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Hans de Graaff]

On Mon, 2017-06-05 at 18:38 +0700, Vadim A. Misbakh-Soloviov wrote:
> > 
> Although, in-tree version is obsolete anyway, and upstream made few
> next 
> releases with brain-exploding buildsystem, so I just pushed 
> version to my 
> "public sandbox" overlay, and happy with it on the projects that
> depends on 
> phantomjs.

I have been tracking the upstream git repository for some time. It was
going in the right direction by dropping all bundled code and use
system qtwebkit. Unfortunately it either did not build correctly or if
it did it would crash on 80% of the included test suite. Otherwise I
would have added a snapshot.

Hans

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Hans de Graaff]

On Mon, 2017-06-05 at 23:06 +1200, Kent Fredric wrote:
> 
> Can phantomjs be simply masked for a longer period until the
> development
> world has had an opportunity to catch up?

What kind of timeframe do you propose?

> 1.5 Months from "We're not working on this" to "its dead jim, kill it
> from orbit"
> is a bit fast for anything entrenched.

The problems were there a lot longer so for me at least it still feels
slow. The fact that Chromium is now an alternative finally made it
easier to mask this, but really we should have masked this months ago.
If not for security reasons than for all the QA violations such as tons
of bundled code.

> Chromium 59 is also, similarly, quite new.

It has hit stable upstream so we should see stable versions in Gentoo
soon, I expect.

Hans

signature.asc
Description: This is a digitally signed message part

[gentoo-dev] media-libs/libsfml: preferred way of preventing RDEPs on certain platforms

[Marty Plummer]

Greetings.

As you folks may be aware I've been submitting patches here and there
for the ebuild repo to improve crossdev for mingw-w64 toolchains. Its
slow going and will take a while to cover all the edge cases this use
introduces, but every step is a good one.

My current package I'm working on is media-libs/libsfml, but the
questions here could equally apply to any package that makes sense to
have for a windows cross-compiler. In this case, its the virtual/libudev
and x11-libs/* RDEPs. While the latter may be useful in certain cases
(such as running a local x11 server on cygwin), the udev dep is largely
unneeded to my understanding. I've so far added an X use flag for those,
but I'm wondering if slapping a udev use flag is the best/correct option
in this case. wraeth has suggested a use conditional on kernel_Winnt,
what do you guys think?

Regards,
Marty.

Re: [gentoo-portage-dev] [PATCH] GitSync: Support setting environment variables for git

[Zac Medico]

On Mon, Jun 5, 2017 at 6:39 AM, Brian Dolbec  wrote:

> On Mon,  5 Jun 2017 01:40:08 -0700
> Zac Medico  wrote:
>
> > From: Manuel Rüger 
> >
> > This can be used to provide private SSH keys to portage in order to
> > clone repositories from a non-public repository.
> >
> > An exemplary usage would be setting this in the repositories'
> > repos.conf: sync-git-env = "GIT_SSH_COMMAND=ssh
> > -i /etc/portage/.ssh/id_rsa -o
> > UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=false
> > sync-git-pull-env = "GIT_SSH_COMMAND=ssh -i /etc/portage/.ssh/id_rsa
> > -o UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=true
> > sync-git-clone-env = "GIT_SSH_COMMAND=ssh -i /etc/portage/.ssh/id_rsa
> > -o UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=true
> > --- man/portage.5| 24
> > +++- pym/portage/sync/modules/git/__init__.py |
> > 5 - pym/portage/sync/modules/git/git.py  | 24
> > ++-- 3 files changed, 49 insertions(+), 4
> > deletions(-)
>
> looks good, Thanks Manuel, Zac
>

Thanks, pushed:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=8aa1a070921dc643d615a3c38b4f60e55e709850
-- 
Thanks,
Zac

[gentoo-dev] Last rites: 9 more packages + some *-sharp (mostly obsolete)

[Michał Górny]

# Michał Górny  (05 Jun 2017)
# Mask split *-sharp packages for removal. Replaced by combined:
# - >=dev-dotnet/gtk-sharp-2.12.21,
# - >=dev-dotnet/gnome-sharp-2.24.2-r1.
# Removal in 14 days.
 (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained since addition. Obsolete version that requires ancient
# dev-python/mock version. No reverse dependencies.
# Removal in 30 days. Bug #616292.
dev-python/cassandra-driver

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained. Does not use python eclasses. Unhandled bug reports.
# Removal in 30 days. Bug #615920.
dev-util/rpmdevtools

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Dead upstream. No reverse dependencies. Fails to build.
# Removal in 30 days. Bug #594384.
dev-libs/libjit

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained upstream. Fails to build.
# Removal in 30 days. Bug #513416.
media-sound/pianobooster

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained library with no reverse dependencies. Last consumer
# of unmaintained gpe.eclass.
# Removal in 30 days. Bug #610490.
x11-libs/libxsettings-client

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo, awfully old version. Uses obsolete
# built_with_use.
# Removal in 30 days. Bug #610454.
net-misc/ser

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Abandoned upstream before Gentoo got to
# bumping it.
# Removal in 30 days. Bug #360767.
www-apps/pyblosxom

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# The libgnomeuimm is long dead upstream.
# Removal in 30 days. Bug #608948.
dev-cpp/libgnomeuimm

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained upstream and in Gentoo. Requires old wxGTK version.
# Removal in 30 days. Bug #564100.
net-analyzer/fe3d

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Ciaran McCreesh]

On Mon, 05 Jun 2017 20:10:12 +0200
Michał Górny  wrote:
> I'm sure Ciaran will love to elaborate ;-).

It's doomed. Even if you get it to work, which you won't, it won't
survive ten seconds contact with the enemy.

-- 
Ciaran McCreesh

[gentoo-dev] Last rites: 12 more packages (broken, obsolete deps)

[Michał Górny]

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained upstream. Already suffers heavy patching in Gentoo.
# Multiple bugs filed, including build failures.
# Removal in 30 days. Bug #515760.
media-sound/rezound

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Requires old wxPython. GAMESS itself
# is masked for removal already.
# Removal in 30 days. Bug #564104.
sci-chemistry/gamessq

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Abandoned upstream. Require obsolete GNOME libraries. Multiple
# alternatives exist. Removal in 30 days.
# app-dicts/gjiten -- bug #608404; alternative: app-dicts/gwaei
# app-i18n/im-ja -- bug #608418.
# games-board/gamazons -- bug #608424.
app-dicts/gjiten
app-i18n/im-ja
games-board/gamazons

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Discontinued blob driver. Fails to build against modern kernels.
# Removal in 30 days. Bug #574026.
net-dialup/martian-modem

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. The current version is obsolete, and the new
# versions cause issues preventing adding.
# Removal in 30 days. Bug #368257.
x11-misc/etm

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. The current Gentoo version no longer builds.
# Removal in 30 days. Bug #602820.
media-plugins/vdr-xineliboutput

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained upstream. Seems to fail at Python. Depends on multiple
# deprecated GNOME libraries.
# Removal in 30 days. Bug #562416.
dev-java/java-gnome

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained upstream. Bad quality code.
# Removal in 30 days. Bug #603562.
dev-libs/dee

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Discontinued upstream. Plugins no longer get updates, resulting
# in security vulnerabilities.
# Removal in 30 days. Bug #603282.
www-plugins/pipelight

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Does not support ffmpeg-3. Maintainer is unable to solve that,
# and nobody seems to be interested.
# Removal in 30 days. Bug #575138.
media-plugins/vdr-audiorecorder

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Michał Górny]

On pon, 2017-06-05 at 19:24 +0200, Alexis Ballier wrote:
> On Mon, 05 Jun 2017 16:10:25 +0200
> Michał Górny  wrote:
> 
> > On pon, 2017-06-05 at 09:55 +0200, Alexis Ballier wrote:
> > > On Sun, 4 Jun 2017 10:59:38 +0200
> > > Alexis Ballier  wrote:
> > >   
> > > > Here's a quick n dirty code to play with, based on yours: 
> > > > https://github.com/aballier/required-use  
> > > 
> > > I've run that on the whole tree (considering all ebuilds with non
> > > empty REQUIRED_USE), some stats:
> > > 
> > > $ time python3 classify.py requsel 
> > > Stats:
> > >   Parse error: 16  
> > 
> > Hmm, how did you get those numbers? I just tested parsing and found
> > only 7 unique REQUIRED_USE entries that fail. However, my sample file
> > is only around 1000 entries long, so either I failed to get all of
> > them, or you didn't deduplicate your list ;-). More on it below.
> 
> I did not deduplicate anything. I took every single ebuild and
> generated a list of req use out of it. Meaning if you had 10 ebuilds
> for 1 package with the same req use that'd count as 10 above.
> 
> [...]
> > > The cycle is mostly due to:
> > > $ python3 nsolve.py 'llvm? ( gallium ) gallium? ( llvm )'
> > > [...]
> > > toposort.CircularDependencyError: Circular dependencies exist among
> > > these items: {[gallium]? => [llvm]:{[llvm]? => [gallium]}, [llvm]?
> > > => [gallium]:{[gallium]? => [llvm]}}
> > > 
> > > 
> > > This is something I had overseen when replacing 'a q'_j is some p_i
> > > and one of q_1 ... q_m might be false' by only 'a q'_j is some
> > > p_i'; it can be replaced without changing anything in the way PM
> > > would solve it by "a q'_j is some p_i and the set of {q_j} is not a
> > > subset of q' union p'" (that is, {q_i} is not trivially true if the
> > > 2nd clause is applied). Extending that, we get those stats:  
> > 
> > I'm not even trying to understand the things you say with indexes but
> > I trust you know what you're doing.
> 
> With that kind of things it's good to have someone having a second
> look. It's so easy to forget a case or to miss a simplification.

I'm sure Ciaran will love to elaborate ;-).

> > Well, I guess it's time to hit the next level. For a start, we have to
> > handle all-of groups, i.e.:
> > 
> >   ( a b c )
> > 
> > Stand-alone makes little sense (and little trouble) but as you could
> > have seen it's used nested in other thingies:
> > 
> > 1. || ( ( a b ) ( c d ) e )
> > 
> > 2. ?? ( ( a b ) ( c d ) e )
> > 
> > 3. ^^ ( ( a b ) ( c d ) e )
> 
> Yeah that's the nesting problem causing a parse error.
> Those should be expanded to implications. What I'm relying onto is all
> clauses to be of the form '[list of conditions]? [list of constraints]'

I've noticed that you turned the implications into multi-conditions,
breaking all my scripts ;-). Is the [list of conditions] conjunctive or
disjunctive?

> > For verifying constraints, they are not bad. We just follow the
> > generic rule that the branch evaluates to true if all subexpressions
> > are true. 
> > 
> > For solving, it might be a little unclear on how to proceed with
> > partially true branches but for the sake of simplicity I would just
> > ignore them and behave as if they were false. That is, case (1) with
> > USE='c' would result in 'a b' being enabled.
> > 
> > The practical uses I've seen are:
> > 
> > a. || ( deprecated ( gtk3 introspection ) )
> > 
> > I guess this one would be equivalent to:
> > 
> >   !gtk3? ( !introspection? ( deprecated ) )
> 
> Unfortunately no. Favoring leftmost, you need to enable 'deprecated'
> when either gtk3 or introspection is false.
> 
> That'd be:
> !gtk3? ( deprecated )
> !introspection? ( deprecated )

Well, I meant 'by current rules', without considering preferences.

> Fortunately we can distribute \/ and /\:
> > > ( deprecated ( gtk3 introspection ) )
> 
> is equivalent to:
> > > ( deprecated gtk3 )
> > > ( deprecated introspection )
> 
> giving the above implication translation.
> 
> This can be extended to 
> > > ( ( a1 a2 a3 ... ) ( b1 b2 b3 ... ) ... ) to handle all cases.
> 
> 
> 
> > b. ^^ ( ( !32bit 64bit ) ( 32bit !64bit ) ( 32bit 64bit ) )
> > 
> > This looks like a crazy way of saying:
> > 
> >   || ( 32bit 64bit )
> 
> Hmm yes
> 
> 
> > c. ^^ ( ( !ruby !s7 ) ( ruby !s7 ) ( !ruby s7 ) )
> > 
> > This looks like an insane version of:
> > 
> >   ?? ( ruby s7 )
> 
> 
> yes too it seems
> 
> 
> 
> > except that per my solver it just disables both when both are set ;-).
> 
> That's kind of the point. And that's why it is important to have the
> solving rules well defined. Depending on how REQUIRED_USE is written,
> it will be solved differently even for equivalent logical formulas.
> 
> 
> > Not sure if the extra complexity is worth for roughly one valid use
> > case, and a lot of insanity.
> 
> I think this can be done without too much pain. As you noticed, replace
> '^^ ( whatever )' by '|| ( whatever ) ?? ( whatever )' so we're left
> with 

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Kent Fredric]

On Mon, 5 Jun 2017 13:42:50 -0400
Michael Orlitzky  wrote:

> Hans was
> attempting to fix it, but now that upstream is dead, it will remain
> insecure forever.

IME, as long as that's clear from the pmask, and its clear what those
security vectors are, as long as an end user makes sure those vectors
can't happen, having an insecure-in-theory-but-not-in-practice
phantomjs is better than having no phantomjs. 


pgpTvAqhrhnTO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Michael Orlitzky]

On 06/05/2017 07:06 AM, Kent Fredric wrote:
> On Mon, 05 Jun 2017 09:11:27 +0200
> Hans de Graaff  wrote:
> 
>> # Hans de Graaff  (05 Jun 2017)
>> # Bundles obsolete and vulnerable webkit version.
>> # Upstream has stopped development and recommends using
>> # headless mode in >=www-client/chromium-59.
>> # Masked for removal in 30 days. Bug #589994.
>> www-client/phantomjs
> 
> Can phantomjs be simply masked for a longer period until the development
> world has had an opportunity to catch up?
> 

The real reason for the mask is that it bundles an ancient version of
qtwebkit with a ton of known security vulnerabilities. Hans was
attempting to fix it, but now that upstream is dead, it will remain
insecure forever.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Mon, 05 Jun 2017 16:10:25 +0200
Michał Górny  wrote:

> On pon, 2017-06-05 at 09:55 +0200, Alexis Ballier wrote:
> > On Sun, 4 Jun 2017 10:59:38 +0200
> > Alexis Ballier  wrote:
> >   
> > > Here's a quick n dirty code to play with, based on yours: 
> > > https://github.com/aballier/required-use  
> > 
> > I've run that on the whole tree (considering all ebuilds with non
> > empty REQUIRED_USE), some stats:
> > 
> > $ time python3 classify.py requsel 
> > Stats:
> > Parse error: 16  
> 
> Hmm, how did you get those numbers? I just tested parsing and found
> only 7 unique REQUIRED_USE entries that fail. However, my sample file
> is only around 1000 entries long, so either I failed to get all of
> them, or you didn't deduplicate your list ;-). More on it below.

I did not deduplicate anything. I took every single ebuild and
generated a list of req use out of it. Meaning if you had 10 ebuilds
for 1 package with the same req use that'd count as 10 above.

[...]
> > The cycle is mostly due to:
> > $ python3 nsolve.py 'llvm? ( gallium ) gallium? ( llvm )'
> > [...]
> > toposort.CircularDependencyError: Circular dependencies exist among
> > these items: {[gallium]? => [llvm]:{[llvm]? => [gallium]}, [llvm]?
> > => [gallium]:{[gallium]? => [llvm]}}
> > 
> > 
> > This is something I had overseen when replacing 'a q'_j is some p_i
> > and one of q_1 ... q_m might be false' by only 'a q'_j is some
> > p_i'; it can be replaced without changing anything in the way PM
> > would solve it by "a q'_j is some p_i and the set of {q_j} is not a
> > subset of q' union p'" (that is, {q_i} is not trivially true if the
> > 2nd clause is applied). Extending that, we get those stats:  
> 
> I'm not even trying to understand the things you say with indexes but
> I trust you know what you're doing.

With that kind of things it's good to have someone having a second
look. It's so easy to forget a case or to miss a simplification.

> For completeness, we need to
> consider three cross-dependent states:
> 
> a. a? ( b ) b? ( a )


that's exactly the above :p

{q_j} is {b}, {q'} is {a}, {p'} is {b}; {b} is a subset of {a} union
{b}


[...]
> b. !a? ( !b ) !b? ( !a )

that's also the above with s/!b/b/ s/!a/a/ :=)

> c. a? ( b ) !a? ( !b )

that's already handled.

[...]
> > I'll let you play with it, but for me it seems this would work quite
> > nicely.
> >   
> 
> Well, I guess it's time to hit the next level. For a start, we have to
> handle all-of groups, i.e.:
> 
>   ( a b c )
> 
> Stand-alone makes little sense (and little trouble) but as you could
> have seen it's used nested in other thingies:
> 
> 1. || ( ( a b ) ( c d ) e )
> 
> 2. ?? ( ( a b ) ( c d ) e )
> 
> 3. ^^ ( ( a b ) ( c d ) e )

Yeah that's the nesting problem causing a parse error.
Those should be expanded to implications. What I'm relying onto is all
clauses to be of the form '[list of conditions]? [list of constraints]'


> For verifying constraints, they are not bad. We just follow the
> generic rule that the branch evaluates to true if all subexpressions
> are true. 
> 
> For solving, it might be a little unclear on how to proceed with
> partially true branches but for the sake of simplicity I would just
> ignore them and behave as if they were false. That is, case (1) with
> USE='c' would result in 'a b' being enabled.
> 
> The practical uses I've seen are:
> 
> a. || ( deprecated ( gtk3 introspection ) )
> 
> I guess this one would be equivalent to:
> 
>   !gtk3? ( !introspection? ( deprecated ) )

Unfortunately no. Favoring leftmost, you need to enable 'deprecated'
when either gtk3 or introspection is false.

That'd be:
!gtk3? ( deprecated )
!introspection? ( deprecated )


Fortunately we can distribute \/ and /\:
|| ( deprecated ( gtk3 introspection ) )
is equivalent to:
|| ( deprecated gtk3 )
|| ( deprecated introspection )

giving the above implication translation.

This can be extended to 
|| ( ( a1 a2 a3 ... ) ( b1 b2 b3 ... ) ... ) to handle all cases.



> b. ^^ ( ( !32bit 64bit ) ( 32bit !64bit ) ( 32bit 64bit ) )
> 
> This looks like a crazy way of saying:
> 
>   || ( 32bit 64bit )

Hmm yes


> c. ^^ ( ( !ruby !s7 ) ( ruby !s7 ) ( !ruby s7 ) )
> 
> This looks like an insane version of:
> 
>   ?? ( ruby s7 )


yes too it seems



> except that per my solver it just disables both when both are set ;-).

That's kind of the point. And that's why it is important to have the
solving rules well defined. Depending on how REQUIRED_USE is written,
it will be solved differently even for equivalent logical formulas.


> Not sure if the extra complexity is worth for roughly one valid use
> case, and a lot of insanity.

I think this can be done without too much pain. As you noticed, replace
'^^ ( whatever )' by '|| ( whatever ) ?? ( whatever )' so we're left
with only || and ?? (and 'and' denoted by space and grouping in our
notation).

|| ( clause1 clause2 ... ) is replaced by
[!clause1 !clause2 ...]?[clause1]

?? ( 

[gentoo-dev] Last rites: 16 unmaintained (broken, vulnerable) packages

[Michał Górny]

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Security vulnerability.
# Removal in 30 days. Bug #552628.
dev-libs/libmimedir

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Abandoned downstream and upstream. Permanently masked due to
# a dependency on vulnerable library.
# Removal in 30 days. Bug #337473.
sys-block/afacli

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Reported not to work. Uses old wxPython.
# Removal in 30 days. Bug #601192.
sci-geosciences/cdat-lite

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Multiple bugs, including a security
# vulnerability. Removal in 30 days. Bug #581960.
net-irc/atheme-services

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Abandoned in Gentoo. Fail to build with gcc-6.
# Removal in 30 days. Bugs:
# app-backup/boxbackup - #595412
# dev-lang/falcon - #595416
# net-p2p/ppcoin-qt - #598366
app-backup/boxbackup
dev-lang/falcon
net-p2p/ppcoin-qt

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Abandoned upstream and unmaintained in Gentoo. Requires old wxPython
# and pycrypto. Removal in 30 days. Bug #313923.
app-mobilephone/bitpim

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Security vulnerability.
# Removal in 30 days. Bug #562896.
net-irc/charybdis

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Security vulnerability. No reverse
# dependencies. Removal in 30 days. Bug #551216.
www-apache/mod_jk

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Multiple versions behind upstream.
# Security vulnerabilities. No reverse dependencies anymore.
# Removal in 30 days. Bug #512292.
dev-db/ctdb

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained in Gentoo. Multiple versions behind upstream. Multiple
# security vulnerabilities. Removal in 30 days. Bug #509920.
www-apps/egroupware

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Unmaintained. Fails to build. Removal in 30 days. Bug #541702.
net-mail/topal

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Abandoned upstream and downstream. Reported not to work. CAPI flags
# in reverse dependencies are masked for some time already.
# Removal in 30 days. Bug #379975.
net-dialup/capi4k-utils

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Abandoned upstream and downstream. Buggy. Segfaults hard on Python
# upgrades. Use one of the *CGI modules instead.
# Removal in 30 days. Bug #536134.
www-apache/mod_python

# Michał Górny  (05 Jun 2017)
# (on behalf of Treecleaner project)
# Abandoned upstream and downstream. Buggy to the point of producing
# corrupted media. Use the original app-cdr/cdrtools or one of the many
# other alternatives (app-cdr/dvd+rw-tools, dev-libs/libburn...).
# Removal in 30 days. Bugs #254312, #591778.
app-cdr/cdrkit

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml

[Kent Fredric]

On Mon, 5 Jun 2017 11:40:15 -0400
Alec Warner  wrote:

> Do we really need to store and distribute this data though?

Aggregating this kind of data by cross-referencing multiple providers
and then trying discovery against debians equivalents of that, while
workable, would be likely fragile and unpredictable.

If you can determine this list yourself from the existing data, I'd
suggest we start with that, and then see how painful it is to do on the
fly.

I'd expect the round-trip times to resolve such questions would be
little expensive, so you'd want a sort of job that does this
periodically and creates an index outside of the repository, and then
services can query *that* for things like "Can haz an screenshots?" 

And then, it could be reasonable to then simplify this proposal such
that the typical usage of introducing additional data would be to
exclusively augment data that can't be discovered by other means.

This would solve *both* the problems of "hard to automate" and "too much
cruft in the repo", while keeping the hand-edited metadata close to the
package definitions.





pgp9Ob77Nw7BQ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Addition of a new field to metadata.xml

[Alec Warner]

On Sat, Jun 3, 2017 at 3:58 AM, Michał Górny  wrote:

> On sob, 2017-06-03 at 03:22 +1200, Kent Fredric wrote:
> > On Fri, 02 Jun 2017 16:51:25 +0200
> > Michał Górny  wrote:
> >
> > > ...so if a Gentoo package is split into 40 packages in Debian, are you
> > > going to list all of them?
> >
> > If it would be useful to do so, maybe.
> >
> > But its a text file, people are capable of making judgements about
> > adding 3.2k of text, I hope. ( worst-case, 40 lines of 80 characters
> each )
> >
> > If the text at that size has a use, then, why not?
> >
> > As long as that 40-package example is an exceptional case, where it was
> deemed
> > useful, not the norm.
>
> It's not that exceptional in binary distributions where it's normal to
> split a single source into a few dozen packages (libraries, headers,
> tools, plugins...):
>
> https://packages.debian.org/source/sid/systemd
>
> and that's a small one. I guess we could avoid this if you restricted
> those remotes to the source package used to build them all.
>

I would argue that specifying source package remotes is what should be done
for every package. UI layers can use the source package remote to look up
metadata for the source package and get a list of the binary packages it
produces when built; maintaining this list inside of Gentoo seems ill
advised. (I could perhaps be swayed by a script where you populate the
source package remote and a tool fills in the binary packages as sourced
from debian sid or whatever.)

Do we really need to store and distribute this data though?

-A


>
> --
> Best regards,
> Michał Górny
>

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Michał Górny]

On pon, 2017-06-05 at 09:55 +0200, Alexis Ballier wrote:
> On Sun, 4 Jun 2017 10:59:38 +0200
> Alexis Ballier  wrote:
> 
> > Here's a quick n dirty code to play with, based on yours: 
> > https://github.com/aballier/required-use
> 
> I've run that on the whole tree (considering all ebuilds with non
> empty REQUIRED_USE), some stats:
> 
> $ time python3 classify.py requsel 
> Stats:
>   Parse error: 16

Hmm, how did you get those numbers? I just tested parsing and found only
 7 unique REQUIRED_USE entries that fail. However, my sample file is
only around 1000 entries long, so either I failed to get all of them, or
you didn't deduplicate your list ;-). More on it below.

>   Good: 8316
>   Need topo sort: 140
>   Cyclic: 57
> 
> real  0m2.996s
> user  0m2.950s
> sys   0m0.004s
> 
> 
> Running time is good I think.
> Parse error is some nested construct not supported by your parser that
> I have not fixed either.

Yes, the time is great. It means we can actually think about integrating
it with repoman/pkgcheck.

> The cycle is mostly due to:
> $ python3 nsolve.py 'llvm? ( gallium ) gallium? ( llvm )'
> [...]
> toposort.CircularDependencyError: Circular dependencies exist among
> these items: {[gallium]? => [llvm]:{[llvm]? => [gallium]}, [llvm]? =>
> [gallium]:{[gallium]? => [llvm]}}
> 
> 
> This is something I had overseen when replacing 'a q'_j is some p_i and
> one of q_1 ... q_m might be false' by only 'a q'_j is some p_i'; it can
> be replaced without changing anything in the way PM would solve it by
> "a q'_j is some p_i and the set of {q_j} is not a subset of q' union
> p'" (that is, {q_i} is not trivially true if the 2nd clause is
> applied). Extending that, we get those stats:

I'm not even trying to understand the things you say with indexes but I
trust you know what you're doing. For completeness, we need to consider
three cross-dependent states:

a. a? ( b ) b? ( a )

i.e.:

  y_1 = y_2 = x_1 v x_2

iow, enabling either of the flags causes both of them being enabled. I'm
not sure if we have a valid use case to keep such flags long-term but
short-term they could be useful to handle transition periods when
upstream merges two features (or makes them cross-dependent) and we want
to preserve compatibility with split flags.

b. !a? ( !b ) !b? ( !a )

i.e.:

  y_1 = y_2 = x_1 ^ x_2

iow, you have to enable both flags to keep them enabled. Not sure if we
have any valid use case for this.

c. a? ( b ) !a? ( !b )

i.e.

  y_1 = y_2 = x_1

This mostly a reduced result of:

  a? ( || ( b c d ... ) ) !a? ( !b !c !d ... )

[NB: it would be useful to have a short syntax for that]

I suspect this will be commonly useful to express provider dependencies,
i.e. enforcing a particular constraint for providers only when
the feature flag is enabled, and disabling all provider flags when it is
not.

FWICS, my version solves all three cases correctly, and your does not
explode on them.

> I'll let you play with it, but for me it seems this would work quite
> nicely.
> 

Well, I guess it's time to hit the next level. For a start, we have to
handle all-of groups, i.e.:

  ( a b c )

Stand-alone makes little sense (and little trouble) but as you could
have seen it's used nested in other thingies:

1. || ( ( a b ) ( c d ) e )

2. ?? ( ( a b ) ( c d ) e )

3. ^^ ( ( a b ) ( c d ) e )

For verifying constraints, they are not bad. We just follow the generic
rule that the branch evaluates to true if all subexpressions are true. 

For solving, it might be a little unclear on how to proceed with
partially true branches but for the sake of simplicity I would just
ignore them and behave as if they were false. That is, case (1) with
USE='c' would result in 'a b' being enabled.

The practical uses I've seen are:

a. || ( deprecated ( gtk3 introspection ) )

I guess this one would be equivalent to:

  !gtk3? ( !introspection? ( deprecated ) )

b. ^^ ( ( !32bit 64bit ) ( 32bit !64bit ) ( 32bit 64bit ) )

This looks like a crazy way of saying:

  || ( 32bit 64bit )

c. ^^ ( ( !ruby !s7 ) ( ruby !s7 ) ( !ruby s7 ) )

This looks like an insane version of:

  ?? ( ruby s7 )

except that per my solver it just disables both when both are set ;-).

Not sure if the extra complexity is worth for roughly one valid use
case, and a lot of insanity.

I've pushed a simple update to my parser to account for this. However,
it doesn't support replace_nary atm, so it won't work for you.


Of course past that there's a deeper insanity: all those constructs can
be nested without limits. Verification is possible, solving maybe -- but
I'm not sure if we even want to try to think what the correct solution
would be.

There's only one use of this:

  ?? ( gl3plus ( || ( gles2 gles3 ) ) )

FWICS, it probably works like this;

 g   g
 l   l
 3 g g   3 g g
 p l l   p l l
 l e e   l e e
 u s s   u s s
 s 2 3 | s 2 3
 0 0 0 | 0 0 0 (==)
 0 0 1 | 0 0 1 (==)
 0 1 0 | 0 1 0 (==)
 0 1 1 | 0 1 1 (==)
 1 0 0 | 1 0 0 

Re: [gentoo-portage-dev] [PATCH] GitSync: Support setting environment variables for git

[Brian Dolbec]

On Mon,  5 Jun 2017 01:40:08 -0700
Zac Medico  wrote:

> From: Manuel Rüger 
> 
> This can be used to provide private SSH keys to portage in order to
> clone repositories from a non-public repository.
> 
> An exemplary usage would be setting this in the repositories'
> repos.conf: sync-git-env = "GIT_SSH_COMMAND=ssh
> -i /etc/portage/.ssh/id_rsa -o
> UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=false
> sync-git-pull-env = "GIT_SSH_COMMAND=ssh -i /etc/portage/.ssh/id_rsa
> -o UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=true
> sync-git-clone-env = "GIT_SSH_COMMAND=ssh -i /etc/portage/.ssh/id_rsa
> -o UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=true
> --- man/portage.5| 24
> +++- pym/portage/sync/modules/git/__init__.py |
> 5 - pym/portage/sync/modules/git/git.py  | 24
> ++-- 3 files changed, 49 insertions(+), 4
> deletions(-)
> 
> diff --git a/man/portage.5 b/man/portage.5
> index 366a1fa85..5f1f2bbb0 100644
> --- a/man/portage.5
> +++ b/man/portage.5
> @@ -1,4 +1,4 @@
> -.TH "PORTAGE" "5" "Jan 2017" "Portage VERSION" "Portage"
> +.TH "PORTAGE" "31" "May 2017" "Portage VERSION" "Portage"
>  .SH NAME
>  portage \- the heart of Gentoo
>  .SH "DESCRIPTION"
> @@ -979,9 +979,31 @@ Specifies CVS repository.
>  .B sync\-depth
>  This is a deprecated alias for the \fBclone\-depth\fR option.
>  .TP
> +.B sync\-git\-clone\-env
> +Set environment variables for git when cloning repository (git
> clone). +This will override settings from sync-git-env.
> +.RS
> +.TP
> +.I Example:
> +sync-git-clone-env="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"
> +.br
> +Gives three variables "VAR1", "VAR2", "VAR3" with the values "word1
> word2", +"word3", "$word 5 6".
> +.RE
> +.TP
>  .B sync\-git\-clone\-extra\-opts
>  Extra options to give to git when cloning repository (git clone).
>  .TP
> +.B sync\-git\-env
> +Set environment variables for git when cloning or pulling the
> repository. +These will be overridden by setting them again in
> sync-git-clone-env and sync-git-pull-env. +See also example for
> sync-git-clone-env. +.TP
> +.B sync\-git\-pull\-env
> +Set environment variables for git when updating repository (git
> pull). +This will override settings from sync-git-env.
> +See also example for sync-git-clone-env.
> +.TP
>  .B sync\-git\-pull\-extra\-opts
>  Extra options to give to git when updating repository (git pull).
>  .TP
> diff --git a/pym/portage/sync/modules/git/__init__.py
> b/pym/portage/sync/modules/git/__init__.py index 60b7395b8..e7206e12d
> 100644 --- a/pym/portage/sync/modules/git/__init__.py
> +++ b/pym/portage/sync/modules/git/__init__.py
> @@ -1,4 +1,4 @@
> -# Copyright 2014 Gentoo Foundation
> +# Copyright 2014-2017 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
>  doc = """Git plug-in module for portage.
> @@ -52,7 +52,10 @@ module_spec = {
>   },
>   'validate_config': CheckGitConfig,
>   'module_specific_options': (
> + 'sync-git-clone-env',
>   'sync-git-clone-extra-opts',
> + 'sync-git-env',
> + 'sync-git-pull-env',
>   'sync-git-pull-extra-opts',
>   ),
>   }
> diff --git a/pym/portage/sync/modules/git/git.py
> b/pym/portage/sync/modules/git/git.py index d432886dd..bea79c7e7
> 100644 --- a/pym/portage/sync/modules/git/git.py
> +++ b/pym/portage/sync/modules/git/git.py
> @@ -1,4 +1,4 @@
> -# Copyright 2005-2015 Gentoo Foundation
> +# Copyright 2005-2017 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
>  import logging
> @@ -6,7 +6,7 @@ import subprocess
>  
>  import portage
>  from portage import os
> -from portage.util import writemsg_level
> +from portage.util import writemsg_level, shlex_split
>  from portage.output import create_color_func
>  good = create_color_func("GOOD")
>  bad = create_color_func("BAD")
> @@ -50,6 +50,16 @@ class GitSync(NewBase):
>   sync_uri = sync_uri[6:]
>  
>   git_cmd_opts = ""
> + if
> self.repo.module_specific_options.get('sync-git-env'):
> + shlexed_env =
> shlex_split(self.repo.module_specific_options['sync-git-env'])
> + env = dict((k, v) for k, _, v in
> (assignment.partition('=') for assignment in shlexed_env) if k)
> + self.spawn_kwargs['env'].update(env)
> +
> + if
> self.repo.module_specific_options.get('sync-git-clone-env'):
> + shlexed_env =
> shlex_split(self.repo.module_specific_options['sync-git-clone-env'])
> + clone_env = dict((k, v) for k, _, v in
> (assignment.partition('=') for assignment in shlexed_env) if k)
> 

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Vadim A. Misbakh-Soloviov]

> Can phantomjs be simply masked for a longer period until the development
> world has had an opportunity to catch up?

Just exactly what I thought.

Although, in-tree version is obsolete anyway, and upstream made few next 
releases with brain-exploding buildsystem, so I just pushed  version to my 
"public sandbox" overlay, and happy with it on the projects that depends on 
phantomjs.

By the way, headless chrome, well, work a bit different in comparsion with 
"analogs" (including wkhtmlto{img,pdf}), so, it needs much more time than a 
month to get full analogs.

So, I'm disagree with monthly dropping in this context too (well, I disagree 
with the idea. As I just said, I by myself is in safe from being affected by 
it).

Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Kent Fredric]

On Mon, 05 Jun 2017 09:11:27 +0200
Hans de Graaff  wrote:

> # Hans de Graaff  (05 Jun 2017)
> # Bundles obsolete and vulnerable webkit version.
> # Upstream has stopped development and recommends using
> # headless mode in >=www-client/chromium-59.
> # Masked for removal in 30 days. Bug #589994.
> www-client/phantomjs

Can phantomjs be simply masked for a longer period until the development
world has had an opportunity to catch up?

There's still respectable amounts of JS based testing code dependent on 
phantomjs
and all removing this means is "people who want to do this have to work this out
themselves"

1.5 Months from "We're not working on this" to "its dead jim, kill it from 
orbit"
is a bit fast for anything entrenched.

Chromium 59 is also, similarly, quite new.


pgp9r4awBntUu.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites: x11-misc/lightdm-kde and kde-apps/plasma-runtime

[Andreas Sturmlechner]

# Andreas Sturmlechner  (05 Jun 2017)
# Relies on obsolete and vulnerable qtwebkit version. Dead upstream.
# Masked for removal in 30 days. Bugs #620792, #620796
x11-misc/lightdm-kde
kde-apps/plasma-runtime

[gentoo-portage-dev] [PATCH] GitSync: Support setting environment variables for git

[Zac Medico]

From: Manuel Rüger 

This can be used to provide private SSH keys to portage in order to
clone repositories from a non-public repository.

An exemplary usage would be setting this in the repositories' repos.conf:
sync-git-env = "GIT_SSH_COMMAND=ssh -i /etc/portage/.ssh/id_rsa -o 
UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=false
sync-git-pull-env = "GIT_SSH_COMMAND=ssh -i /etc/portage/.ssh/id_rsa -o 
UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=true
sync-git-clone-env = "GIT_SSH_COMMAND=ssh -i /etc/portage/.ssh/id_rsa -o 
UserKnownHostsFile=/etc/portage/.ssh/known_hosts" GIT_TRACE=true
---
 man/portage.5| 24 +++-
 pym/portage/sync/modules/git/__init__.py |  5 -
 pym/portage/sync/modules/git/git.py  | 24 ++--
 3 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/man/portage.5 b/man/portage.5
index 366a1fa85..5f1f2bbb0 100644
--- a/man/portage.5
+++ b/man/portage.5
@@ -1,4 +1,4 @@
-.TH "PORTAGE" "5" "Jan 2017" "Portage VERSION" "Portage"
+.TH "PORTAGE" "31" "May 2017" "Portage VERSION" "Portage"
 .SH NAME
 portage \- the heart of Gentoo
 .SH "DESCRIPTION"
@@ -979,9 +979,31 @@ Specifies CVS repository.
 .B sync\-depth
 This is a deprecated alias for the \fBclone\-depth\fR option.
 .TP
+.B sync\-git\-clone\-env
+Set environment variables for git when cloning repository (git clone).
+This will override settings from sync-git-env.
+.RS
+.TP
+.I Example:
+sync-git-clone-env="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"
+.br
+Gives three variables "VAR1", "VAR2", "VAR3" with the values "word1 word2",
+"word3", "$word 5 6".
+.RE
+.TP
 .B sync\-git\-clone\-extra\-opts
 Extra options to give to git when cloning repository (git clone).
 .TP
+.B sync\-git\-env
+Set environment variables for git when cloning or pulling the repository.
+These will be overridden by setting them again in sync-git-clone-env and 
sync-git-pull-env.
+See also example for sync-git-clone-env.
+.TP
+.B sync\-git\-pull\-env
+Set environment variables for git when updating repository (git pull).
+This will override settings from sync-git-env.
+See also example for sync-git-clone-env.
+.TP
 .B sync\-git\-pull\-extra\-opts
 Extra options to give to git when updating repository (git pull).
 .TP
diff --git a/pym/portage/sync/modules/git/__init__.py 
b/pym/portage/sync/modules/git/__init__.py
index 60b7395b8..e7206e12d 100644
--- a/pym/portage/sync/modules/git/__init__.py
+++ b/pym/portage/sync/modules/git/__init__.py
@@ -1,4 +1,4 @@
-# Copyright 2014 Gentoo Foundation
+# Copyright 2014-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 doc = """Git plug-in module for portage.
@@ -52,7 +52,10 @@ module_spec = {
},
'validate_config': CheckGitConfig,
'module_specific_options': (
+   'sync-git-clone-env',
'sync-git-clone-extra-opts',
+   'sync-git-env',
+   'sync-git-pull-env',
'sync-git-pull-extra-opts',
),
}
diff --git a/pym/portage/sync/modules/git/git.py 
b/pym/portage/sync/modules/git/git.py
index d432886dd..bea79c7e7 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -1,4 +1,4 @@
-# Copyright 2005-2015 Gentoo Foundation
+# Copyright 2005-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 import logging
@@ -6,7 +6,7 @@ import subprocess
 
 import portage
 from portage import os
-from portage.util import writemsg_level
+from portage.util import writemsg_level, shlex_split
 from portage.output import create_color_func
 good = create_color_func("GOOD")
 bad = create_color_func("BAD")
@@ -50,6 +50,16 @@ class GitSync(NewBase):
sync_uri = sync_uri[6:]
 
git_cmd_opts = ""
+   if self.repo.module_specific_options.get('sync-git-env'):
+   shlexed_env = 
shlex_split(self.repo.module_specific_options['sync-git-env'])
+   env = dict((k, v) for k, _, v in 
(assignment.partition('=') for assignment in shlexed_env) if k)
+   self.spawn_kwargs['env'].update(env)
+
+   if self.repo.module_specific_options.get('sync-git-clone-env'):
+   shlexed_env = 
shlex_split(self.repo.module_specific_options['sync-git-clone-env'])
+   clone_env = dict((k, v) for k, _, v in 
(assignment.partition('=') for assignment in shlexed_env) if k)
+   self.spawn_kwargs['env'].update(clone_env)
+
if self.settings.get("PORTAGE_QUIET") == "1":
git_cmd_opts += " --quiet"
if self.repo.clone_depth is not None:
@@ -86,6 +96,16 @@ class 

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Mon, 29 May 2017 17:33:13 +0200
Michał Górny  wrote:

> 2.4. Backwards compatibility
> 


Considering the discussions in that thread, a natural way to move
forward now seems to be:

1. Define a way to solve constraints deterministically
2. Get a warning check into repoman to ensure REQUIRED_USE are solved
   that way.
3. Get those repoman warnings fixed.
4. Implement an optional FEATURES in portage for automatic solving
   of REQUIRED_USE.
5. If all goes well, mandate that solving in next EAPI and make the
   repoman warning an error for those EAPIs.

Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Sun, 4 Jun 2017 10:59:38 +0200
Alexis Ballier  wrote:

> Here's a quick n dirty code to play with, based on yours: 
> https://github.com/aballier/required-use

I've run that on the whole tree (considering all ebuilds with non
empty REQUIRED_USE), some stats:

$ time python3 classify.py requsel 
Stats:
Parse error: 16
Good: 8316
Need topo sort: 140
Cyclic: 57

real0m2.996s
user0m2.950s
sys 0m0.004s


Running time is good I think.
Parse error is some nested construct not supported by your parser that
I have not fixed either.


~2.5% simply need to be reordered. ~0.6% require more clever thinking.


Let's have a look at a few of them:

sys-fs/cryptsetup-1.7.5
^^ ( gcrypt kernel nettle openssl ) python? ( ||
( python_targets_python2_7 python_targets_python3_4
python_targets_python3_5 python_targets_python3_6 ) )
static? ( !gcrypt )

USE='-* static' is painful: the first ^^ will enable gcrypt, static?
( !gcrypt ) will disable it. Reordering the ^^ so that kernel appears
first fixes the cycle.


media-libs/mesa-13.0.6
|| ( gcrypt libressl nettle openssl ) d3d9?
( dri3 gallium ) llvm? ( gallium ) opencl? ( gallium llvm ) openmax?
( gallium ) gles1? ( egl ) gles2? ( egl ) vaapi? ( gallium ) vdpau?
( gallium ) vulkan? ( video_cards_i965 ) wayland? ( egl gbm ) xa?
( gallium ) video_cards_freedreno? ( gallium ) video_cards_intel?
( classic ) video_cards_i915? ( || ( classic gallium ) )
video_cards_i965? ( classic ) video_cards_nouveau? ( || ( classic
gallium ) ) video_cards_radeon? ( || ( classic gallium ) gallium?
( x86? ( llvm ) amd64? ( llvm ) ) ) video_cards_r100? ( classic )
video_cards_r200? ( classic ) video_cards_r300? ( gallium x86? ( llvm )
amd64? ( llvm ) ) video_cards_r600? ( gallium ) video_cards_radeonsi?
( gallium llvm ) video_cards_vmware? ( gallium )

The cycle is mostly due to:
$ python3 nsolve.py 'llvm? ( gallium ) gallium? ( llvm )'
[...]
toposort.CircularDependencyError: Circular dependencies exist among
these items: {[gallium]? => [llvm]:{[llvm]? => [gallium]}, [llvm]? =>
[gallium]:{[gallium]? => [llvm]}}


This is something I had overseen when replacing 'a q'_j is some p_i and
one of q_1 ... q_m might be false' by only 'a q'_j is some p_i'; it can
be replaced without changing anything in the way PM would solve it by
"a q'_j is some p_i and the set of {q_j} is not a subset of q' union
p'" (that is, {q_i} is not trivially true if the 2nd clause is
applied). Extending that, we get those stats:

Stats:
Parse error: 16
Good: 8325
Need topo sort: 146
Cyclic: 42

real0m1.575s
user0m1.563s
sys 0m0.012s


Now we seem to get only valid warnings (I have not checked them all
though):

sys-firmware/seabios-1.10.1:
debug? ( !binary ) !amd64? ( !x86? ( binary ) )

USE="debug -amd64 -x86" ?


sci-libs/ceres-solver-1.11.0:
test? ( gflags ) sparse? ( lapack ) abi_x86_32? ( !sparse !lapack )

USE='-* sparse -lapack abi_x86_32' shows a conflict between the last 2
clauses. Better write:

test? ( gflags ) !abi_x86_32? ( sparse? ( lapack ) ) abi_x86_32?
( !sparse !lapack )

which makes the test work



mail-mta/exim-4.89
dane? ( !gnutls ) dmarc? ( spf dkim ) pkcs11? ( gnutls ) spf?
( exiscan-acl ) srs? ( exiscan-acl )

USE="dane pkcs11" ?

sci-libs/hdf5-1.8.18:
threads? ( !cxx !mpi !fortran !hl ) fortran2003? ( fortran )

USE="threads fortran2003" ?





I'll let you play with it, but for me it seems this would work quite
nicely.


Alexis.

[gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist

[Hans de Graaff]

# Hans de Graaff  (05 Jun 2017)
# Bundles obsolete and vulnerable webkit version.
# Upstream has stopped development and recommends using
# headless mode in >=www-client/chromium-59.
# Masked for removal in 30 days. Bug #589994.
www-client/phantomjs
dev-ruby/poltergeist

signature.asc
Description: This is a digitally signed message part