Re: [gentoo-portage-dev] [PATCH 1/2] Use RTNETLINK to configure the loopback interface

2019-08-31 Thread Zac Medico
On 8/30/19 11:24 AM, Mike Gilbert wrote:
> This eliminates the dependency on iproute2 on Linux.
> 
> Signed-off-by: Mike Gilbert 
> ---
>  lib/portage/process.py  | 26 --
>  lib/portage/util/netlink.py | 98 +
>  2 files changed, 108 insertions(+), 16 deletions(-)
>  create mode 100644 lib/portage/util/netlink.py

Thanks, merged:

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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] glsa-check: add exit code for affected GLSAs

2019-08-31 Thread Zac Medico
On 8/30/19 12:18 PM, Aaron Bauman wrote:
> Bug: https://bugs.gentoo.org/587930
> 
> Reported-by: Bandie Yip Kojote 
> Signed-off-by: Aaron Bauman 
> ---
>  bin/glsa-check | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/bin/glsa-check b/bin/glsa-check
> index 83ea6b7c3..b3ddc532a 100755
> --- a/bin/glsa-check
> +++ b/bin/glsa-check
> @@ -282,6 +282,7 @@ if mode == "test":
>   summarylist(outputlist)
>   else:
>   sys.stdout.write("\n".join(outputlist)+"\n")
> + sys.exit(6)
>   else:
>   sys.stderr.write("This system is not affected by any of the 
> listed GLSAs\n")
>   sys.exit(0)
> 

Thanks, merged:

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



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] PATCH: add CPU_FLAGS_PPC USE_EXPAND

2019-08-31 Thread Georgy Yakovlev
Possible users from the tree: 
  altivec useflag consumers (many)
  media libraries (x264, x265, libpng and others.)

also firefox-70[1] will have auto-detection of features but we may want to
prevent automagic optimizations.


cpuid2cpuflags support[2] is ready and and will be merged soon,
so users will have a gentoo-way of setting those flags.


And this patch in github PR[3] format for easy viewing

[1] https://hg.mozilla.org/mozilla-central/rev/252643ff91c5
[2] https://github.com/mgorny/cpuid2cpuflags/pull/13
[3] https://github.com/gentoo/gentoo/pull/12829





[gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 profiles/desc/cpu_flags_ppc.desc | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 profiles/desc/cpu_flags_ppc.desc

diff --git a/profiles/desc/cpu_flags_ppc.desc b/profiles/desc/cpu_flags_ppc.desc
new file mode 100644
index 000..abd2434c4f5
--- /dev/null
+++ b/profiles/desc/cpu_flags_ppc.desc
@@ -0,0 +1,6 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+altivec - Use the AltiVec instruction set
+vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
+vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and later)
-- 
2.23.0




[gentoo-dev] [PATCH 2/2] profiles: Add CPU_FLAGS_PPC to USE_EXPAND

2019-08-31 Thread Georgy Yakovlev
hide everywhere, and unhide in top level powerpc profile

Signed-off-by: Georgy Yakovlev 
---
 profiles/arch/powerpc/make.defaults | 9 +
 profiles/base/make.defaults | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 profiles/arch/powerpc/make.defaults

diff --git a/profiles/arch/powerpc/make.defaults 
b/profiles/arch/powerpc/make.defaults
new file mode 100644
index 000..8613dd7619e
--- /dev/null
+++ b/profiles/arch/powerpc/make.defaults
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# All extra USE/etc should be specified in sub-profiles.
+# DO NOT POLLUTE USE ON THIS PROFILE.
+
+# Georgy Yakovlev 

[gentoo-dev] Last-rite: app-misc/pip3line

2019-08-31 Thread Joonas Niilola

|

#  Joonas  Niilola(2019-08-31)
#  No  maintainer  and  no  one  stepped  in  to  take  it  after  a  mailing  
#  list  announcement.  Has  QA  issues  and  continuous  CI  issues.  Removal  
#  in  30  days.

#  Bugs:  #690784,  #691376,  #693184
app-misc/pip3line

|


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Michał Górny
On Sat, 2019-08-31 at 00:19 -0700, Georgy Yakovlev wrote:
> On 8/30/19 11:11 PM, Michał Górny wrote:
> > On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:
> 
> > > +altivec - Use the AltiVec instruction set
> > > +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
> > > +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and 
> > > later)
> > 
> > Do all those flags have real use cases in ::gentoo?  I'd really prefer
> > not having more 'unused flag' warnings ;-).
> > 
> 
> yeah, I have mentioned possible users above and there are plenty I
> haven't identified yet. patches to ebuilds will follow, I promise =)
> 
> for example x264 if built with proper flags gives a noticeable boost,
> (at least 2x at encoding), totally worth it.
> 
> ppc will not have a lot of flags like on arm or x86, maybe a couple
> more, but that's it for now.
> 

Just to be clear: we're not talking about -m compiler flags, are we? 
'cause those should be handled via CFLAGS.

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Roy Bamford
Hi Michał,
 
On 2019.08.31 09:03, Michał Górny wrote:
> Hello,
> 
> We still have a lot of packages that are keyworded ~x86/x86 but were
> never keyworded ~amd64.  While I suppose there might be exceptions to
> that, in most cases it means that simply nobody has been using it for
> years.

x86, the 32 bit variety, is still popular at the low power end of the spectrum
for things like network appliances. Not the sort of hardware you would
play many games on these days. 

Proceed with caution. Mask them and leave them in the tree. Wait and
see who shouts, if anyone.

Low power systems don't get updated terribly regularly, so be prepared 
to leave the packages in the tree for a lot longer than the customary 30
days.
 
> 
> Many of them are still at EAPI 0; some were ported to newer EAPIs
> specifically to clean old EAPIs.
> 
> I've already cleaned up some false positives (like svgalib).  If you
> know more, please let me know.
> 
> I have mixed feelings about games on the list.  On one hand, it's
> rather
> obvious that they're x86 binary games.  However, if somebody actually
> used them, they would have probably gained amd64 multilib compat by
> now.


> 
> ---
>
[snip list]
> 
> -- 
> Best regards,
> Michał Górny
> 
> 


-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgp66BNhk29KZ.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Michael Orlitzky
On 8/31/19 4:03 AM, Michał Górny wrote:
> 
> I've already cleaned up some false positives (like svgalib).  If you
> know more, please let me know.
> 
> ...
> dev-libs/gnulib

This one has only prefix keywords and is maintained by prefix@. It has a
recentish EAPI=6 version.



Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Nils Freydank
Hi,

most of my points were just said. Two additional notes:

- dev-embedded/jtag says upstream is dead anyway and it
recommends an alternative we have inside our tree,
dev-embedded/urjtag.

- games-strategy/netpanzer got a rewrite called
  version 2.something, which looks active/used.

Please reflect these in the masking message(s).


However, thanks for the housekeeping!

Kind regards,
Nils

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson





[gentoo-dev] Last rites: www-apache/mod_pcgi2, www-apps/pcgi

2019-08-31 Thread Michał Górny
# Michał Górny  (2019-08-31)
# Unmaintained.  EAPI 0 ebuilds with multiple QA issues.  Last release
# added in 2003.  Upstream removed all traces of it.
# Removal in 30 days.  Bug #693186.
www-apache/mod_pcgi2
www-apps/pcgi

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
On 8/30/19 11:11 PM, Michał Górny wrote:
> On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:

>> +altivec - Use the AltiVec instruction set
>> +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
>> +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and 
>> later)
> 
> Do all those flags have real use cases in ::gentoo?  I'd really prefer
> not having more 'unused flag' warnings ;-).
> 

yeah, I have mentioned possible users above and there are plenty I
haven't identified yet. patches to ebuilds will follow, I promise =)

for example x264 if built with proper flags gives a noticeable boost,
(at least 2x at encoding), totally worth it.

ppc will not have a lot of flags like on arm or x86, maybe a couple
more, but that's it for now.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
On 8/30/19 11:29 PM, Michał Górny wrote:
> On Sat, 2019-08-31 at 00:19 -0700, Georgy Yakovlev wrote:
>> On 8/30/19 11:11 PM, Michał Górny wrote:
>>> On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:
>> 
 +altivec - Use the AltiVec instruction set
 +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
 +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and 
 later)
>>>
>>> Do all those flags have real use cases in ::gentoo?  I'd really prefer
>>> not having more 'unused flag' warnings ;-).
>>>
>>
>> yeah, I have mentioned possible users above and there are plenty I
>> haven't identified yet. patches to ebuilds will follow, I promise =)
>>
>> for example x264 if built with proper flags gives a noticeable boost,
>> (at least 2x at encoding), totally worth it.
>>
>> ppc will not have a lot of flags like on arm or x86, maybe a couple
>> more, but that's it for now.
>>
> 
> Just to be clear: we're not talking about -m compiler flags, are we? 
> 'cause those should be handled via CFLAGS.
> 

of course not just compiler flags, that's clear.

for example libpng has --enable-powerpc-vsx ./configure flag, and build
system will do it's black magic with intrinsics if it's passed.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Michał Górny
Hello,

We still have a lot of packages that are keyworded ~x86/x86 but were
never keyworded ~amd64.  While I suppose there might be exceptions to
that, in most cases it means that simply nobody has been using it for
years.

Many of them are still at EAPI 0; some were ported to newer EAPIs
specifically to clean old EAPIs.

I've already cleaned up some false positives (like svgalib).  If you
know more, please let me know.

I have mixed feelings about games on the list.  On one hand, it's rather
obvious that they're x86 binary games.  However, if somebody actually
used them, they would have probably gained amd64 multilib compat by now.

---

app-admin/consolehm
app-admin/longrun
app-emulation/vov
app-misc/hatools
app-misc/tprint
app-shells/shish
app-text/fdftk
app-text/freepwing
dev-db/vbisam
dev-embedded/jtag
dev-embedded/powersoftplus-libftdi
dev-games/flinker
dev-games/gtkradiant
dev-games/hlsdk
dev-lang/gwydion-dylan-bin
dev-lang/mozart
dev-lang/mozart-stdlib
dev-lang/tinycobol
dev-libs/asyncresolv
dev-libs/cpl-stratego
dev-libs/gnulib
dev-libs/libsqlora8
dev-libs/libtrain
dev-libs/libvolume_id
dev-libs/mps
dev-lisp/cmucl
dev-scheme/kawa
dev-util/ald
games-action/battalion
games-action/fakk2
games-action/postalplus
games-arcade/epiar
games-arcade/gunocide2ex
games-emulation/mekanix
games-fps/aaut
games-fps/industri
games-fps/red-blue-quake2
games-fps/tenebrae
games-fps/tribes2
games-fps/unreal-tournament-strikeforce
games-fps/ut2003-bonuspack-cm
games-fps/ut2003-bonuspack-de
games-fps/ut2003-bonuspack-epic
games-fps/wolfgl
games-misc/c++robots
games-roguelike/hengband
games-server/bf1942-lnxded
games-server/mtavc
games-strategy/mindrover-demo
games-strategy/netpanzer
media-gfx/zgv
media-plugins/vdr-bgprocess
media-plugins/vdr-pilot
media-plugins/vdr-proxy
media-plugins/vdr-quicktimer
media-plugins/vdr-radiolist
media-sound/cmix
media-sound/hearnet
media-sound/imp3sh
media-video/maven-poke
media-video/recmpeg
media-video/xanim-export
net-analyzer/mrtg-ping-probe
net-analyzer/nagios-sap-ccms-plugin
net-analyzer/ndsad
net-analyzer/neti
net-analyzer/quidscor
net-analyzer/rrdcollect
net-analyzer/sguil-sensor
net-dialup/cistronradius
net-dialup/dgcmodem
net-dialup/tkvoice
net-dns/tinystats
net-firewall/pftop
net-irc/ptlink-ircd
net-irc/ptlink-opm
net-libs/roadrunner
net-libs/vanessa-mcast
net-mail/fastforward
net-mail/gensig
net-mail/qmail-lint
net-mail/qmail-qsanity
net-misc/blinkperl
net-misc/dcetest
net-misc/hlfl
net-misc/ip-sentinel
net-misc/lambdamoo
net-misc/netprofiles-ims
net-misc/selfdhcp
net-misc/shout
net-misc/smbc
net-p2p/gnut
net-p2p/mktorrent-borg
net-p2p/myster
net-p2p/smet2html
net-p2p/xnap
net-wireless/orinoco-fwutils
sys-apps/byld
sys-apps/checkservice
sys-apps/fwcrv
sys-apps/hardened-shadow
sys-apps/lcdsplash
sys-apps/lcdutils
sys-apps/netboot-base
sys-auth/icmpdn
sys-auth/pam_smb
sys-boot/cromwell
sys-boot/cromwell-bin
sys-boot/psoload
sys-boot/raincoat
sys-cluster/feedbackd-agent
sys-cluster/feedbackd-master
sys-cluster/ocfs
sys-fs/atari-fdisk
sys-fs/davl
sys-fs/fuse4bsd
sys-fs/hfsplusutils
sys-fs/scan-ffs
sys-kernel/xbox-sources
sys-libs/lrmi
sys-power/athcool
sys-process/fuser-bsd
www-apache/mod_diagnostics
www-apache/mod_pcgi2
www-apache/mod_vdbh
www-apps/browser-config
www-apps/metadot
www-apps/pcgi
www-client/ck4up
x11-drivers/xf86-video-geode
x11-misc/bblaunch
x11-misc/i855crt
x11-misc/xhkeys
x11-plugins/gkrellm-plugins
x11-plugins/wmXName
x11-plugins/wmacpimon
x11-plugins/wmbatteries
x11-plugins/wmlongrun
x11-plugins/wmrecord
x11-wm/treewm

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Mart Raudsepp
Ühel kenal päeval, L, 31.08.2019 kell 10:03, kirjutas Michał Górny:
> x11-drivers/xf86-video-geode

This one is a required driver for Geode LX hardware, which is 32bit.


Mart


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


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Michał Górny
On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:
> Signed-off-by: Georgy Yakovlev 
> ---
>  profiles/desc/cpu_flags_ppc.desc | 6 ++
>  1 file changed, 6 insertions(+)
>  create mode 100644 profiles/desc/cpu_flags_ppc.desc
> 
> diff --git a/profiles/desc/cpu_flags_ppc.desc 
> b/profiles/desc/cpu_flags_ppc.desc
> new file mode 100644
> index 000..abd2434c4f5
> --- /dev/null
> +++ b/profiles/desc/cpu_flags_ppc.desc
> @@ -0,0 +1,6 @@
> +# Copyright 2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +altivec - Use the AltiVec instruction set
> +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
> +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and later)

Do all those flags have real use cases in ::gentoo?  I'd really prefer
not having more 'unused flag' warnings ;-).

-- 
Best regards,
Michał Górny



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


[gentoo-dev] acct-{user,group}/i2p request for 493

2019-08-31 Thread Tharrvik .
Hello,

`net-vpn/i2p` currently adds a "i2p" user and group with a random
uid/gid; it needs to run a daemon. I'm the proxy-maint for it so I
created acct-{user,group}/i2p and assigned 493:493 which are free
according to https://api.gentoo.org/uid-gid.txt

If that's good for you, the PR waiting validation is there
https://github.com/gentoo/gentoo/pull/12785

Thanks.
--
Valérian Rousset



[gentoo-dev] [PATCH] acct-group/plugdev: Introduce new group (GID 272)

2019-08-31 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 acct-group/plugdev/metadata.xml | 8 
 acct-group/plugdev/plugdev-0.ebuild | 9 +
 2 files changed, 17 insertions(+)
 create mode 100644 acct-group/plugdev/metadata.xml
 create mode 100644 acct-group/plugdev/plugdev-0.ebuild

diff --git a/acct-group/plugdev/metadata.xml b/acct-group/plugdev/metadata.xml
new file mode 100644
index ..0319eec4c8be
--- /dev/null
+++ b/acct-group/plugdev/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   mgo...@gentoo.org
+   Michał Górny
+   
+
diff --git a/acct-group/plugdev/plugdev-0.ebuild 
b/acct-group/plugdev/plugdev-0.ebuild
new file mode 100644
index ..14c2c876eedf
--- /dev/null
+++ b/acct-group/plugdev/plugdev-0.ebuild
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+DESCRIPTION="Group controlling access to removable media"
+ACCT_GROUP_ID=272
-- 
2.23.0




Re: [gentoo-dev] acct-{user,group}/i2p request for 493

2019-08-31 Thread Ulrich Mueller
> On Sat, 31 Aug 2019, Tharrvik  wrote:

> `net-vpn/i2p` currently adds a "i2p" user and group with a random
> uid/gid; it needs to run a daemon. I'm the proxy-maint for it so I
> created acct-{user,group}/i2p and assigned 493:493 which are free
> according to https://api.gentoo.org/uid-gid.txt

We had skipped 493 and 492 previously, because Archlinux uses them for
oidentd and oprofile (which we also have as packages, so they'll have
to be converted to the new scheme).

AFAICS, 484 would be the next free number (when counting down from 499).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] acct-{user,group}/i2p request for 493

2019-08-31 Thread Ulrich Mueller
> On Sat, 31 Aug 2019, Ulrich Mueller wrote:

> AFAICS, 484 would be the next free number (when counting down from 499).

I just see that i2pd has 470, maybe take the adjacent 471?


signature.asc
Description: PGP signature


[gentoo-portage-dev] [PATCH] _backtrack_depgraph: fix premature backtracking termination (bug 693242)

2019-08-31 Thread Zac Medico
Make backtracking continue as long as the backtracker has remaining
nodes to explore. This fixes a case where it would terminate prematurely
when the depgraph.need_restart() method returned False, even though the
backtracker had remaining nodes to explore.

Bug: https://bugs.gentoo.org/693242
Signed-off-by: Zac Medico 
---
 lib/_emerge/depgraph.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/_emerge/depgraph.py b/lib/_emerge/depgraph.py
index 3e99ac077..08240af67 100644
--- a/lib/_emerge/depgraph.py
+++ b/lib/_emerge/depgraph.py
@@ -9794,8 +9794,8 @@ def _backtrack_depgraph(settings, trees, myopts, 
myparams, myaction, myfiles, sp
elif mydepgraph.need_restart():
backtracked += 1
backtracker.feedback(mydepgraph.get_backtrack_infos())
-   else:
-   break
+   elif backtracker:
+   backtracked += 1
 
if not (success or mydepgraph.need_config_change()) and backtracked:
 
-- 
2.21.0




[gentoo-portage-dev] [PATCH] _slot_confict_backtrack: consider masking a package matched by all parent atoms (bug 692746)

2019-08-31 Thread Zac Medico
When a slot conflict occurs involving a package that is matched by all
involved parent atoms, consider masking the package in order to avoid
a possible missed update. The included unit test demonstrates the case
fixed by this patch. There are 2 previously existing unit tests that
require larger backtracking values in order to succeed with this patch,
since more possible solutions are now considered.

Bug: https://bugs.gentoo.org/692746
Signed-off-by: Zac Medico 
---
 lib/_emerge/depgraph.py   |  5 ++
 lib/_emerge/resolver/backtracking.py  |  9 +++
 .../test_slot_conflict_update_virt.py | 79 +++
 .../test_slot_operator_complete_graph.py  |  2 +-
 .../test_slot_operator_runtime_pkg_mask.py|  2 +-
 5 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 lib/portage/tests/resolver/test_slot_conflict_update_virt.py

diff --git a/lib/_emerge/depgraph.py b/lib/_emerge/depgraph.py
index 08240af67..6be1b3ec7 100644
--- a/lib/_emerge/depgraph.py
+++ b/lib/_emerge/depgraph.py
@@ -1768,6 +1768,11 @@ class depgraph(object):
debug = "--debug" in self._frozen_config.myopts
existing_node = 
next(self._dynamic_config._package_tracker.match(
root, slot_atom, installed=False))
+   if existing_node not in conflict_pkgs:
+   # Even though all parent atoms match existing_node,
+   # consider masking it in order to avoid a missed update
+   # as in bug 692746.
+   conflict_pkgs.append(existing_node)
# In order to avoid a missed update, first mask lower versions
# that conflict with higher versions (the backtracker visits
# these in reverse order).
diff --git a/lib/_emerge/resolver/backtracking.py 
b/lib/_emerge/resolver/backtracking.py
index c29b9d42a..99e4565c8 100644
--- a/lib/_emerge/resolver/backtracking.py
+++ b/lib/_emerge/resolver/backtracking.py
@@ -135,11 +135,20 @@ class Backtracker(object):
continue
 
entry_is_valid = False
+   any_conflict_parents = False
 
for ppkg, patom in runtime_pkg_mask[pkg].get("slot 
conflict", set()):
+   any_conflict_parents = True
if ppkg not in runtime_pkg_mask:
entry_is_valid = True
break
+   else:
+   if not any_conflict_parents:
+   # Even though pkg was involved in a 
slot conflict
+   # where it was matched by all involved 
parent atoms,
+   # consider masking it in order to avoid 
a missed
+   # update as in bug 692746.
+   entry_is_valid = True
 
if not entry_is_valid:
return False
diff --git a/lib/portage/tests/resolver/test_slot_conflict_update_virt.py 
b/lib/portage/tests/resolver/test_slot_conflict_update_virt.py
new file mode 100644
index 0..ce89925ba
--- /dev/null
+++ b/lib/portage/tests/resolver/test_slot_conflict_update_virt.py
@@ -0,0 +1,79 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+from portage.tests import TestCase
+from portage.tests.resolver.ResolverPlayground import (ResolverPlayground,
+   ResolverPlaygroundTestCase)
+
+class SlotConflictUpdateVirtTestCase(TestCase):
+
+   def testSlotConflictUpdateVirt(self):
+
+   ebuilds = {
+   "dev-db/mysql-connector-c-6.1.11-r2" : {
+   "EAPI": "7",
+   "SLOT" : "0/18"
+   },
+
+   "dev-db/mysql-connector-c-8.0.17-r3" : {
+   "EAPI": "7",
+   "SLOT" : "0/21"
+   },
+
+   "virtual/libmysqlclient-18-r1" : {
+   "EAPI": "7",
+   "SLOT" : "0/18",
+   "RDEPEND": "dev-db/mysql-connector-c:0/18",
+   },
+
+   "virtual/libmysqlclient-21" : {
+   "EAPI": "7",
+   "SLOT" : "0/21",
+   "RDEPEND": "dev-db/mysql-connector-c:0/21",
+   },
+
+   "dev-perl/DBD-mysql-4.44.0" : {
+   "EAPI": "7",
+   "RDEPEND": "virtual/libmysqlclient:=",
+   },
+   }
+
+   installed = {
+   

[gentoo-portage-dev] [PATCH] glsa-check: fix truncated CVE ids in listmode (bug 692134)

2019-08-31 Thread Zac Medico
Use a regular expression to search for CVE ids in GLSA references.
Import unicode_literals from __future__ since portage's Glsa class
returns unicode strings for all python versions.

Reported-by: Georg Weiss 
Bug: https://bugs.gentoo.org/692134
Signed-off-by: Zac Medico 
---
 bin/glsa-check | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/bin/glsa-check b/bin/glsa-check
index 95ef16fde..6bb2ee21e 100755
--- a/bin/glsa-check
+++ b/bin/glsa-check
@@ -2,9 +2,10 @@
 # Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-from __future__ import print_function
+from __future__ import print_function, unicode_literals
 
 import argparse
+import re
 import sys
 import codecs
 from functools import reduce
@@ -204,7 +205,13 @@ def summarylist(myglsalist, fd1=sys.stdout, 
fd2=sys.stderr, encoding="utf-8"):
 
fd1.write(")")
if list_cve:
-   fd1.write(" "+(",".join([r[:13] for r in 
myglsa.references if r[:4] in ["CAN-", "CVE-"]])))
+   cve_ids = []
+   for r in myglsa.references:
+   m = re.search(r'(CAN|CVE)-[\d-]+', r)
+   if m is not None:
+   cve_ids.append(m.group(0))
+   if cve_ids:
+   fd1.write(" "+(",".join(cve_ids)))
fd1.write("\n")
return 0
 
-- 
2.21.0




[gentoo-portage-dev] [PATCH] glsa-check: add --reverse option (bug 235970)

2019-08-31 Thread Zac Medico
Add --reverse option which causes GLSAs to be listed in reverse order,
so that the most recent GLSAs are listed earlier.

Suggested-by: Pavel Sanda 
Bug: https://bugs.gentoo.org/235970
Signed-off-by: Zac Medico 
---
 bin/glsa-check | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bin/glsa-check b/bin/glsa-check
index 95ef16fde..6dbb7513c 100755
--- a/bin/glsa-check
+++ b/bin/glsa-check
@@ -67,6 +67,8 @@ parser.add_argument("-e", "--emergelike", 
action="store_false", dest="least_chan
help="Upgrade to latest version (not least-change)")
 parser.add_argument("-c", "--cve", action="store_true", dest="list_cve",
help="Show CVE IDs in listing mode")
+parser.add_argument("-r", "--reverse", action="store_true", dest="reverse",
+   help="List GLSAs in reverse order")
 
 options, params = parser.parse_known_args()
 
@@ -162,8 +164,7 @@ def summarylist(myglsalist, fd1=sys.stdout, fd2=sys.stderr, 
encoding="utf-8"):
fd2.write(green("[U]")+" means the system is not affected 
and\n")
fd2.write(red("[N]")+" indicates that the system might be 
affected.\n\n")
 
-   myglsalist.sort()
-   for myid in myglsalist:
+   for myid in sorted(myglsalist, reverse=options.reverse):
try:
myglsa = Glsa(myid, portage.settings, vardb, portdb)
except (GlsaTypeException, GlsaFormatException) as e:
-- 
2.21.0




Re: [gentoo-dev] [PATCH 3/5] www-apps/gitea: Use acct-{group,user}/git

2019-08-31 Thread Michał Górny
On Sat, 2019-08-17 at 17:29 -0400, Michael Orlitzky wrote:
> On 8/17/19 4:43 PM, Michał Górny wrote:
> > > I realize we'd have to tell people how to rename the account to support
> > > upgrades -- but is there some other reason to keep the shared "git" name?
> > 
> > The argument I've been told is that users expect 'git@...' to work
> > as remote URI on their boxes.  They don't want users to bind the URI to
> > specific implementation.
> > 
> 
> It's not really a URI... it's a username on a remote machine. And these
> "users" are programmers =P
> 
> But, I can understand not wanting to tell a bunch of strangers to edit
> all of their ~/.git/config files at this point.
> 
> Instead of configuring both packages to use different users, could we
> configure them to share a working directory? If we give the "git" user a
> home directory of /var/lib/git [0], then as far as I can tell, both
> gitolite and gitea will be happy with that. They use different
> configuration file names and repository locations, and wouldn't need to
> block each other.

It is an interesting concept.  However, it assumes that all existing
installations need to be migrated to the new directory, and I don't
think it's safe to try to do it automatically.

So it really sounds like we're a. adding extra work on sysadmins,
and b. breaking stuff on upgrade, on the vast majority of production
systems that only care about having one of them installed.

> 
> 
> [0] This doesn't violate the guidelines that I posted since real humans
> log in as this account to clone repos out of $HOME. Moreover, I don't
> think that either gitolite or gitea references this path itself -- it
> really belongs to the user.
> 
> 

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Matt Turner
On Sat, Aug 31, 2019 at 1:04 AM Michał Górny  wrote:
> sys-fs/hfsplusutils

Your script should probably check for other keywords as well. This
package is almost entirely for use on ppc/ppc64 machines. For whatever
reason it has an x86 keyword as well, so the lack of an amd64 keyword
doesn't indicate that it should be removed.



Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Michał Górny
On Sat, 2019-08-31 at 13:14 -0700, Matt Turner wrote:
> On Sat, Aug 31, 2019 at 1:04 AM Michał Górny  wrote:
> > sys-fs/hfsplusutils
> 
> Your script should probably check for other keywords as well. This
> package is almost entirely for use on ppc/ppc64 machines. For whatever
> reason it has an x86 keyword as well, so the lack of an amd64 keyword
> doesn't indicate that it should be removed.
> 

I've already removed it from the list, along with other packages that
have revdeps.

However, I don't think that's a really good argument.  Many ancient
packages have x86 and ppc keywords which doesn't make them any less
dead.

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread James Le Cuirot
On Sat, 31 Aug 2019 10:03:47 +0200
Michał Górny  wrote:

> dev-games/flinker

This builds and starts on amd64 but I'm dubious about whether it would
work correctly in practise. I don't imagine anyone will want to use it.
Best just let it die.

> dev-games/gtkradiant

This has been superseded a few times over and the current fork is
NetRadiant-custom. There is an open bug about the older NetRadiant but
I only dabbled in Quake mapping so never cared enough.

https://bugs.gentoo.org/352981

> dev-games/hlsdk

This is a remnant of the Half-Life server stuff that vapier removed in
2005 with the message "valve sucks at linux". I could say more about it
but nobody cares.

> games-action/battalion
> games-action/fakk2
> games-action/postalplus
> games-arcade/epiar
> games-arcade/gunocide2ex
> games-emulation/mekanix
> games-fps/aaut
> games-fps/industri
> games-fps/red-blue-quake2
> games-fps/tenebrae
> games-fps/tribes2
> games-fps/unreal-tournament-strikeforce
> games-fps/ut2003-bonuspack-cm
> games-fps/ut2003-bonuspack-de
> games-fps/ut2003-bonuspack-epic
> games-fps/wolfgl
> games-misc/c++robots
> games-roguelike/hengband
> games-server/bf1942-lnxded
> games-server/mtavc
> games-strategy/mindrover-demo
> games-strategy/netpanzer

I'll try to look through some of these. I still care about UT and even
worked on (but didn't finish) a new UT99 ebuild not so long ago.
Unfortunately it's never been a top priority.

> sys-fs/atari-fdisk

This is still usable on m68k, which is the Atari's own architecture.
The code assumes 32-bit longs so it won't work on 64-bit but it
probably wouldn't be that hard to fix if someone cared enough. I'm
interested in m68k but for the Amiga rather than the Atari. I'm not
sure how useful this is in practise. On the Amiga, I would still use
the AmigaOS partitioning tool over something like this. There is no
replacement for the Atari on Linux as far as I can see though so I
think it should stay.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp9QsRuUlfe4.pgp
Description: OpenPGP digital signature