Re: [gentoo-portage-dev] [PATCH 2/2] Add caching to _slot_operator_check_reverse_dependencies

2022-11-25 Thread Matt Turner
On Thu, Nov 24, 2022 at 10:36 PM Pin-yen Lin  wrote:
>
> Add lru_cache to speed up the running time of "Calculating
> dependencies".
>
> In a ChromeOS use case, this patch decreases the running time from
> 311s to 197s with almost no memory usage increase.
>
> Signed-off-by: Pin-yen Lin 

Thank you!

With recent subslot rebuilds (icu, boost, poppler), I measure an
improvement of 19%!

Benchmark 1: emerge @world -vuNDp
  Time (mean ± σ): 42.668 s ±  0.555 s[User: 42.095 s, System: 0.315 s]
  Range (min … max):   41.572 s … 43.342 s10 runs

Benchmark 2: emerge @world -vuNDp
  Time (mean ± σ): 35.991 s ±  0.154 s[User: 35.409 s, System: 0.332 s]
  Range (min … max):   35.831 s … 36.306 s10 runs

Summary
  'emerge @world -vuNDp' ran
1.19 ± 0.02 times faster than 'emerge @world -vuNDp'



[gentoo-dev] Packages up for grabs: telepathy related packages

2022-11-24 Thread Matt Turner

GNOME 43 will no longer need these packages. They seem to be in varying
states of decay upstream.

- net-im/telepathy-connection-managers
- net-libs/farstream
- net-libs/sofia-sip
- net-libs/telepathy-farstream
- net-voip/telepathy-gabble
- net-voip/telepathy-rakia
- net-voip/telepathy-salut

These are maintained upstream, but GNOME 43 doesn't need them.
gstreamer@ was a backup (and is now the primary) maintainer of
media-plugins/gst-plugins-libnice, so it should probably take over
net-libs/libnice as well.

- media-plugins/gst-plugins-libnice
- net-libs/libnice

I've dropped gnome@ as a maintainer of all of these packages.


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] targets: Drop /etc/asound.state creation

2022-11-14 Thread Matt Turner
alsa creates this file at runtime at /var/lib/alsa/asound.state in
modern times.

Signed-off-by: Matt Turner 
---
 targets/support/livecdfs-update.sh | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/targets/support/livecdfs-update.sh 
b/targets/support/livecdfs-update.sh
index e750e785..251a6887 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -125,9 +125,6 @@ then
http://www.linux-usb.org/usb.ids
 fi
 
-# touch /etc/asound.state
-touch /etc/asound.state
-
 # Tweak the MOTD for Gentoo releases
 case ${clst_livecd_type} in
gentoo-release-universal)
-- 
2.37.4




[gentoo-dev] [PATCH 5/5] catalyst: Drop livecd/{xinitrc,xsession,xdm}

2022-11-14 Thread Matt Turner
This is functionality better implemented in fsscripts outside of
catalyst.

Signed-off-by: Matt Turner 
---
 catalyst/targets/livecd_stage2.py|  3 --
 doc/catalyst-spec.5.txt  | 20 -
 examples/livecd-stage2_template.spec | 24 ---
 examples/stage4_template.spec| 10 -
 livecd/files/livecd.motd.txt |  3 --
 targets/livecd-stage2/controller.sh  |  9 
 targets/stage4/controller.sh |  8 
 targets/support/livecdfs-update.sh   | 63 +---
 8 files changed, 1 insertion(+), 139 deletions(-)

diff --git a/catalyst/targets/livecd_stage2.py 
b/catalyst/targets/livecd_stage2.py
index 832e0998..1a798a1e 100644
--- a/catalyst/targets/livecd_stage2.py
+++ b/catalyst/targets/livecd_stage2.py
@@ -39,9 +39,6 @@ class livecd_stage2(StageBase):
 "livecd/users",
 "livecd/verify",
 "livecd/volid",
-"livecd/xdm",
-"livecd/xinitrc",
-"livecd/xsession",
 "repos",
 ])
 
diff --git a/doc/catalyst-spec.5.txt b/doc/catalyst-spec.5.txt
index f6251597..1abf9efb 100644
--- a/doc/catalyst-spec.5.txt
+++ b/doc/catalyst-spec.5.txt
@@ -395,26 +395,6 @@ This is typically used for adding the documentation, 
distfiles,
 snapshots, and stages to the official media.  These files will not be
 available if `docache` is enabled, as they are outside the loop.
 
-*/xinitrc*::
-This is used by catalyst to copy the specified file to
-`/etc/X11/xinit/xinitrc` and is used by the */type*
-`generic-livecd`.  While the file will still be copied for any
-*/type*, catalyst will only create the necessary `/etc/startx`
-for those types, so X will not be automatically started.  This is
-useful also for setting up X on a CD where you do not wish X to start
-automatically.  We do not use this on the release media.  This setting
-is supported by the `stage4` and `livecd` targets.
-
-*livecd/xdm*::
-This is used by catalyst to determine which display manager you wish
-to become the default (example: `gdm`).  This is used on the official
-Gentoo LiveCD and is valid for any `livecd/type`.
-
-*livecd/xsession*::
-This is used by catalyst to determine which X session should be
-started by default by the display manager (example: `gnome`).  This is
-used on the official Gentoo LiveCD and is valid for any livecd/type.
-
 */users*::
 This option is used to create non-root users on your target.  It takes
 a space separated list of user names.  These users will be added to
diff --git a/examples/livecd-stage2_template.spec 
b/examples/livecd-stage2_template.spec
index 8e179b73..efbc6d82 100644
--- a/examples/livecd-stage2_template.spec
+++ b/examples/livecd-stage2_template.spec
@@ -202,30 +202,6 @@ livecd/overlay:
 # livecd/root_overlay:
 livecd/root_overlay:
 
-# This is used by catalyst to copy the specified file to /etc/X11/xinit/xinitrc
-# and is used by the livecd/type and generic-livecd.  While the file will still
-# be copied for any livecd/type, catalyst will only create the necessary
-# /etc/startx for those types, so X will not be automatically started.  This is
-# useful also for setting up X on a CD where you do not wish X to start
-# automatically.  We do not use this on the release media, so it is left blank.
-# example:
-# livecd/xinitrc:
-livecd/xinitrc:
-
-# This is used by catalyst to determine which display manager you wish to
-# become the default.  This is used on the official Gentoo LiveCD and is valid
-# for any livecd/type.
-# example:
-# livecd/xdm: gdm
-livecd/xdm:
-
-# This is used by catalyst to determine which X session should be started by
-# default by the display manager.  This is used on the official Gentoo LiveCD
-# and is valid for any livecd/type.
-# example:
-# livecd/xsession: gnome
-livecd/xsession:
-
 # This option is used to create non-root users on your CD.  It takes a space
 # separated list of user names.  These users will be added to the following
 # groups: users,wheel,audio,games,cdrom,usb
diff --git a/examples/stage4_template.spec b/examples/stage4_template.spec
index 5d9a390c..a7a3e766 100644
--- a/examples/stage4_template.spec
+++ b/examples/stage4_template.spec
@@ -161,16 +161,6 @@ stage4/rcdel:
 # stage4/root_overlay:
 stage4/root_overlay:
 
-# This is used by catalyst to copy the specified file to /etc/X11/xinit/xinitrc
-# and is used by the stage4/type generic-livecd.  While the file will still be
-# copied for any stage4/type, catalyst will only create the necessary
-# /etc/startx for those types, so X will not be automatically started.  This is
-# useful also for setting up X on a CD where you do not wish X to start
-# automatically.  We do not use this on the release media, so it is left blank.
-# example:
-# stage4/xinitrc:
-stage4/xinitrc:
-
 # This option is used to create groups. It takes a carriage-return separated
 # list of group names. For instance:
 # stage4/groups:
diff --git a/livecd/files/l

[gentoo-dev] [PATCH 4/5] targets: Remove openglify usage

2022-11-14 Thread Matt Turner
This script was removed from livecd-tools in commit 8e2a9c0 ("remove
openglify") in 2011.

Signed-off-by: Matt Turner 
---
 targets/support/livecdfs-update.sh | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/targets/support/livecdfs-update.sh 
b/targets/support/livecdfs-update.sh
index b7548347..64a9e4b2 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -131,9 +131,6 @@ then
http://www.linux-usb.org/usb.ids
 fi
 
-# Setup opengl in /etc (if configured)
-[ -x /usr/sbin/openglify ] && /usr/sbin/openglify
-
 # Setup configured display manager
 if [ -n "${clst_livecd_xdm}" ]
 then
-- 
2.37.4




[gentoo-dev] [PATCH 3/5] targets: Remove gconf usage

2022-11-14 Thread Matt Turner
Bug: https://bugs.gentoo.org/873841
Signed-off-by: Matt Turner 
---
 livecd/files/livecd-local.start|  5 -
 targets/support/livecdfs-update.sh | 24 
 2 files changed, 29 deletions(-)

diff --git a/livecd/files/livecd-local.start b/livecd/files/livecd-local.start
index 3615569c..a7bb2bef 100644
--- a/livecd/files/livecd-local.start
+++ b/livecd/files/livecd-local.start
@@ -4,11 +4,6 @@
 # This is a good place to load any misc.
 # programs on startup ( 1>&2 )
 
-#if [ -d /usr/livecd/gconf ]
-#then
-#  ln -sf /usr/livecd/gconf /etc/gconf
-#fi
-
 #if [ -d /usr/livecd/db ]
 #then
 #  ln -sf /usr/livecd/db /var/db
diff --git a/targets/support/livecdfs-update.sh 
b/targets/support/livecdfs-update.sh
index cf2cf62f..b7548347 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -178,19 +178,6 @@ rm -f /etc/generic.motd.txt /etc/universal.motd.txt 
/etc/minimal.motd.txt /etc/l
 # Post configuration
 case ${clst_livecd_type} in
gentoo-release-live*)
-   # Setup Gnome theme
-   if [ "${clst_livecd_xsession}" == "gnome" ]
-   then
-   gconftool-2 --direct \
-   --config-source 
xml:readwrite:/etc/gconf/gconf.xml.defaults \
-   --type string --set 
/desktop/gnome/interface/font_name "Sans 9"
-   fi
-
-   # Remove locking on screensaver
-   gconftool-2 --direct \
-   
--config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s \
-   -t bool /apps/gnome-screensaver/lock_enabled false 
>/dev/null
-
# Setup GDM
if [ "${clst_livecd_xdm}" == "gdm" ]
then
@@ -232,8 +219,6 @@ case ${clst_livecd_type} in
mkdir -p /usr/livecd
cp -r ${clst_repo_basedir}/${clst_repo_name}/{profiles,eclass} 
/usr/livecd
rm -rf 
/usr/livecd/profiles/{co*,default-{1*,a*,b*,d*,h*,i*,m*,p*,s*,x*},g*,hardened-*,n*,x*}
-   mv -f /etc/gconf /usr/livecd
-   ln -sf /usr/livecd/gconf /etc/gconf
mv -f /var/db /usr/livecd
ln -sf /usr/livecd/db /var/db
 
@@ -274,15 +259,6 @@ case ${clst_livecd_type} in
fi
;;
generic-livecd )
-   # This is my hack to reduce tmpfs usage
-   mkdir -p /usr/livecd
-
-   if [ -d /etc/gconf ]
-   then
-   mv -f /etc/gconf /usr/livecd
-   ln -sf /usr/livecd/gconf /etc/gconf
-   fi
-
touch /etc/startx
;;
 esac
-- 
2.37.4




[gentoo-dev] [PATCH 2/5] targets: Remove remnants of support for the installer

2022-11-14 Thread Matt Turner
Signed-off-by: Matt Turner 
---
 livecd/files/livecd.motd.txt   |  2 --
 targets/support/livecdfs-update.sh | 16 +---
 2 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/livecd/files/livecd.motd.txt b/livecd/files/livecd.motd.txt
index fe4c0918..9f8e2396 100644
--- a/livecd/files/livecd.motd.txt
+++ b/livecd/files/livecd.motd.txt
@@ -1,8 +1,6 @@
 To (re)start X Windows, please type "##DISPLAY_MANAGER" at the prompt below.
 There is also a rescue session for X using twm if you simply use "startx".
 
-You can start the installer by typing "installer" at the prompt below.
-
 Please report any bugs you find to https://bugs.gentoo.org. Be sure to include
 detailed information about how to reproduce the bug you are reporting.
 
diff --git a/targets/support/livecdfs-update.sh 
b/targets/support/livecdfs-update.sh
index 3f47012b..cf2cf62f 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -228,12 +228,8 @@ case ${clst_livecd_type} in
fi
fi
 
-   # This gives us our list of system packages for the installer
-   mkdir -p /usr/livecd
-   ### XXX: Andrew says we don't need this anymore
-   USE="-* $(cat /var/db/pkg/sys-libs/glibc*/USE)" emerge -eqp 
@system | grep -e '^\[ebuild' | sed -e 's:^\[ebuild .\+\] ::' -e 's: .\+$::' > 
/usr/livecd/systempkgs.txt
-
# This is my hack to reduce tmpfs usage
+   mkdir -p /usr/livecd
cp -r ${clst_repo_basedir}/${clst_repo_name}/{profiles,eclass} 
/usr/livecd
rm -rf 
/usr/livecd/profiles/{co*,default-{1*,a*,b*,d*,h*,i*,m*,p*,s*,x*},g*,hardened-*,n*,x*}
mv -f /etc/gconf /usr/livecd
@@ -273,16 +269,6 @@ case ${clst_livecd_type} in
[ -e 
/usr/share/applications/gentoo-handbook.desktop ] && \
cp -f 
/usr/share/applications/gentoo-handbook.desktop \
/home/${username}/Desktop
-   # Copy our installer icons
-   if [ -e 
/usr/share/applications/installer-gtk.desktop ]
-   then
-   cp -f 
/usr/share/applications/installer-{gtk,dialog}.desktop /home/${username}/Desktop
-   sed -i -e \
-   
's:Exec=installer-dialog:Exec=sudo installer-dialog:' \
-   
/home/${username}/Desktop/installer-dialog.desktop
-   sed -i -e 
's:Exec=installer-gtk:Exec=installer:' \
-   
/home/${username}/Desktop/installer-gtk.desktop
-   fi
chown -R ${username}:100 /home/${username}
done
fi
-- 
2.37.4




[gentoo-dev] [PATCH 1/5] targets: Fix enabling PermitRootLogin

2022-11-14 Thread Matt Turner
The default changed to "prohibit-password" many moons ago, so our ISOs
would not have allowed root logins if not for net-misc/openssh's
IUSE=livecd, which handles this in the ebuild.

Let's go ahead and fix it, so that we can consider removing openssh's
livecd USE flag which would allow us to avoid rebuilding the package for
the ISO.

Signed-off-by: Matt Turner 
---
 targets/support/livecdfs-update.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/targets/support/livecdfs-update.sh 
b/targets/support/livecdfs-update.sh
index b7ead552..3f47012b 100755
--- a/targets/support/livecdfs-update.sh
+++ b/targets/support/livecdfs-update.sh
@@ -7,7 +7,8 @@ source /tmp/chroot-functions.sh
 # Allow root logins to our CD by default
 if [ -e /etc/ssh/sshd_config ]
 then
-   sed -i 's:^#PermitRootLogin\ yes:PermitRootLogin\ yes:' \
+   sed -i \
+   -e '/^#PermitRootLogin/c# Allow root login with password on 
livecds.\nPermitRootLogin Yes' \
/etc/ssh/sshd_config
 fi
 
-- 
2.37.4




[gentoo-dev] Last Rites: x11-misc/xnee

2022-11-14 Thread Matt Turner
# Matt Turner  (2022-11-14)
# Unmaintained in Gentoo since at least the transition to git. Last release in
# 2014. Depends on x11-libs/gtk+:2 and gnome-base/gconf. Fails to build with
# (1) clang-16, (2) with LTO, (3) with -fno-common.
# Bugs #812137, #864763, #871405, #873886
# Removal on 2022-12-14
x11-misc/xnee


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code

2022-11-08 Thread Matt Turner
On Mon, Nov 7, 2022 at 11:11 PM Sam James  wrote:
>
>
>
> > On 8 Nov 2022, at 01:10, Matt Turner  wrote:
> >
> > Noticed on ChromeOS when installing a large number of font packages in
> > parallel:
> >
> > /usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (--r--) 
> > to 2440 (r--r-S---)
> > * ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
> > *   failed to fix font files perms
> >
> > The "#new" filename is the hint. Portage uses "#new" suffixes when
> > copying files to the system, and then renames them to their final
> > filenames.
> >
> > This code was executing while another font was in the process of being
> > copied to the system. Font packages should just ensure that they install
> > files with correct permissions to begin with, and all except
> > media-fonts/x11fonts-jmk already use 0644 permissions.
> > media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
> > previous commit which changes its installed files to 0644.
> >
> > Bug: https://bugs.gentoo.org/187774
> > Signed-off-by: Matt Turner 
> > ---
> > eclass/font.eclass | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/eclass/font.eclass b/eclass/font.eclass
> > index 4970c959f7c..0196755ce3e 100644
> > --- a/eclass/font.eclass
> > +++ b/eclass/font.eclass
> > @@ -186,12 +186,6 @@ font_src_install() {
> > # @DESCRIPTION:
> > # Updates fontcache if !prefix and media-libs/fontconfig installed
> > _update_fontcache() {
> > - if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
> > - # unreadable font files = fontconfig segfaults
> > - find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
> > - -exec chmod -v 0644 2>/dev/null {} + || die "failed to fix font files 
> > perms"
> > - fi
> > -
> > if [[ -z ${ROOT} ]] ; then
> > if has_version media-libs/fontconfig ; then
> > ebegin "Updating global fontcache"
> > --
>
> Can we put an fperms call in src_install just in case (like the eclass 
> originally had
> before moved to pkg_postinst)?

We can if you think it's necessary, but to be honest I think that the
original bug should have been WONTFIX. The user was manually
installing fonts into their system and then complained that things
didn't work when they configured the fonts with the wrong permissions.

I don't think fonts getting installed with unreadable permissions is a
real problem.



[gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code

2022-11-07 Thread Matt Turner
Noticed on ChromeOS when installing a large number of font packages in
parallel:

/usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (--r--) to 
2440 (r--r-S---)
* ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
*   failed to fix font files perms

The "#new" filename is the hint. Portage uses "#new" suffixes when
copying files to the system, and then renames them to their final
filenames.

This code was executing while another font was in the process of being
copied to the system. Font packages should just ensure that they install
files with correct permissions to begin with, and all except
media-fonts/x11fonts-jmk already use 0644 permissions.
media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
previous commit which changes its installed files to 0644.

Bug: https://bugs.gentoo.org/187774
Signed-off-by: Matt Turner 
---
 eclass/font.eclass | 6 --
 1 file changed, 6 deletions(-)

diff --git a/eclass/font.eclass b/eclass/font.eclass
index 4970c959f7c..0196755ce3e 100644
--- a/eclass/font.eclass
+++ b/eclass/font.eclass
@@ -186,12 +186,6 @@ font_src_install() {
 # @DESCRIPTION:
 # Updates fontcache if !prefix and media-libs/fontconfig installed
 _update_fontcache() {
-   if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
-   # unreadable font files = fontconfig segfaults
-   find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
-   -exec chmod -v 0644 2>/dev/null {} + || die "failed to 
fix font files perms"
-   fi
-
if [[ -z ${ROOT} ]] ; then
if has_version media-libs/fontconfig ; then
ebegin "Updating global fontcache"
-- 
2.37.4




[gentoo-dev] [PATCH 1/2] media-fonts/x11fonts-jmk: Install files with 0644 permissions

2022-11-07 Thread Matt Turner
font.eclass has some racy code in pkg_postinst() that changes
permissions of already-installed files. I want to remove that to avoid
the race. This is the only package that installs fonts with permissions
other than 0644, so override that in src_install().

The claim in font.eclass is that fontconfig segfaults if fonts are
unreadable, but that claim dates to 2007 (bug #187774). Additionally,
0444 is readable, but who knows. Let's just keep things working how they
have been since 2007.

Bug: https://bugs.gentoo.org/187774
Signed-off-by: Matt Turner 
---
 media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild 
b/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
index 70ad93064b5..f24d067c412 100644
--- a/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
+++ b/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
@@ -32,6 +32,6 @@ src_configure() {
 }
 
 src_install() {
-   emake install INSTALL_DIR="${ED}/usr/share/fonts/jmk"
+   emake install INSTDATFLAGS="-m 0644" 
INSTALL_DIR="${ED}/usr/share/fonts/jmk"
einstalldocs
 }
-- 
2.37.4




[gentoo-dev] Looking for dedicated ModemManager maintainer

2022-11-06 Thread Matt Turner
The following packages are currently maintained by GNOME for no real
reason other than they're a dependency of networkmanager:

net-misc/modemmanager
net-libs/libmbim
net-libs/libqmi
net-libs/libqrtr-glib

But I don't have any ability to test them. I'd really appreciate a
dedicated maintainer take them over—someone who can actually test the
packages.

The packages appear to be in good shape. Recently-released versions
have switched to meson, and I've made a PR here [0] for libmbim and
libqmi.

(In the same vein I wouldn't mind someone taking over NetworkManager...)

Someone lighten my load, please?

[0] https://github.com/gentoo/gentoo/pull/28163



[gentoo-dev] Last Rites: sci-electronics/drahnr-oregano

2022-11-01 Thread Matt Turner

# Matt Turner  (2022-11-01)
# Added by a proxied maintainer in 2018 who then never touched it again before
# disappearing. Doesn't build with Python 3.9. Depends on gnome-base/gconf.
# Bugs #846233, #873877
# Removal on 2022-12-01
sci-electronics/drahnr-oregano


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: x11-libs/vte:0

2022-10-31 Thread Matt Turner

# Matt Turner  (2022-11-01)
# Dead slot. No reverse dependencies that are not masked for removal.
# Removal on 2022-12-01
x11-libs/gnome-pty-helper
x11-libs/vte:0


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: ruby-gnome packages without consumers

2022-10-31 Thread Matt Turner

# Matt Turner  (2022-11-01)
# No reverse dependencies. Depends on deprecated and unmaintained packages:
#  - media-libs/clutter
#  - media-libs/clutter-gst
#  - media-libs/clutter-gtk
#  - x11-libs/gtksourceview:2.0
#  - x11-libs/gtksourceview:3.0
#  - x11-libs/gtksourceview:4
#  - x11-libs/vte:0
# Bug #877153
# Removal on 2022-12-01
dev-ruby/ruby-clutter
dev-ruby/ruby-clutter-gdk
dev-ruby/ruby-clutter-gstreamer
dev-ruby/ruby-clutter-gtk
dev-ruby/ruby-gdk3
dev-ruby/ruby-gegl
dev-ruby/ruby-gnome2
dev-ruby/ruby-gnumeric
dev-ruby/ruby-gsf
dev-ruby/ruby-gstreamer
dev-ruby/ruby-gtk3
dev-ruby/ruby-gtksourceview
dev-ruby/ruby-gtksourceview3
dev-ruby/ruby-gtksourceview4
dev-ruby/ruby-libsecret
dev-ruby/ruby-rsvg
dev-ruby/ruby-vte
dev-ruby/ruby-vte3
dev-ruby/ruby-webkit2-gtk
dev-ruby/ruby-wnck3


signature.asc
Description: PGP signature


Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

2022-10-29 Thread Matt Turner
On Sat, Oct 29, 2022 at 12:53 PM Piotr Karbowski  wrote:
>
> On 29/10/2022 18.22, Matt Turner wrote:
> > Have you seen these commits?
>
> I did not, thanks. Seems like the solution. Is there a reason why llvm:N
> do not pull in lld:N in that case?

lld isn't a dependency of llvm; it's the same reason why llvm:N
doesn't depend on clang:N.



Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

2022-10-29 Thread Matt Turner
On Sat, Oct 29, 2022 at 12:01 PM Piotr Karbowski  wrote:
> The state for this very moment is that we can have many versions of llvm
> around, however we can at most have only one ld.lld installed. Usually
> matching the lowest version of clang installed.

Have you seen these commits?

commit 15aad9556ba01ff38a14775dedd8ee088c27c30f
Author: Michał Górny 
Date:   Fri Oct 14 19:47:20 2022 +0200

sys-devel/lld: Enable slotting on 13.0.1

Signed-off-by: Michał Górny 

commit f1a40a736023a8f1be25e478ef657cf4c772306b
Author: Michał Górny 
Date:   Fri Oct 14 17:37:47 2022 +0200

sys-devel/lld: Enable slotting on 14.0.6

Signed-off-by: Michał Górny 

commit ea9e70d251dd711b91ac3d6da48ab09ce564f3ea
Author: Michał Górny 
Date:   Fri Oct 14 14:58:56 2022 +0200

sys-devel/lld: Enable slotting on LLD 15+

Signed-off-by: Michał Górny 



[gentoo-dev] Last Rites: x11-terms/lilyterm

2022-10-14 Thread Matt Turner
# Matt Turner  (2022-10-14)
# Last upstream release in 2013. Last upstream commit in 2019. No maintainer in
# Gentoo. No reverse dependencies. EAPI=6.
# Depends on unmaintained packages:
#  - x11-libs/vte:0
# Bug #811540.
# Removal on 2022-11-14
x11-terms/lilyterm


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: x11-misc/gtkdialog

2022-10-14 Thread Matt Turner
# Matt Turner  (2022-10-14)
# Unmaintained upstream with last commit in 2013. No reverse dependencies.
# Depends on unmaintained packages:
#  - x11-libs/gtk+:2
#  - x11-libs/vte:0
# Bugs #769131, #875704.
# Removal on 2022-11-14
x11-misc/gtkdialog


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: net-libs/gnet

2022-10-14 Thread Matt Turner
# Matt Turner  (2022-10-14)
# Unmaintained upstream. Last release in 2008. Only reverse dependency is
# gnome-mud, which is masked for removal.
# Bugs #349301, #713152, #802723, #808435, #870730, #877079.
# Removal on 2022-11-14
net-libs/gnet


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: games-mud/gnome-mud

2022-10-14 Thread Matt Turner
# Matt Turner  (2022-10-14)
# Needs upstream work to modernize codebase. Depends on lots of unmaintained
# packages:
#  - app-text/rarian
#  - gnome-base/gconf
#  - gnome-base/libglade
#  - net-libs/gnet:2
#  - x11-libs/gtk+:2
#  - x11-libs/vte:0
# Bugs #670904, #873859
# Removal on 2022-11-14
games-mud/gnome-mud


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: net-im/empathy

2022-10-12 Thread Matt Turner
# Matt Turner  (2022-10-12)
# Unmaintained and archived upstream. Last release in 2017.
# Bug #597960.
# Removal on 2022-11-12
net-im/empathy


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: x11-libs/libva-vdpau-driver

2022-10-05 Thread Matt Turner
# Matt Turner  (2022-10-01)
# Unmaintained upstream. Last commit was 10 years ago today.
# Unclear if it does anything useful. Many open bugs: #584352, #833102,
# #852728, #866557, #875278.
# Removal on 2022-11-05
x11-libs/libva-vdpau-driver


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: media-sound/gmpc and associated plugins

2022-10-01 Thread Matt Turner
# Matt Turner  (2022-10-01)
# Depends on lots of unmaintained packages:
#  - app-text/gnome-doc-utils
#  - dev-libs/libunique:1
#  - dev-util/gob
#  - x11-libs/gtk+:2
# Last commit to upstream repository in 2015. Most plugins saw their last
# upstream commit 10+ years ago. Unmaintained in Gentoo since 2016. Many open
# bugs: #582138, #686800, #689364, #721246, #799263, #808447, #808450, #808456,
# #831024.
# Removal on 2022-11-01
media-sound/gmpc
media-plugins/gmpc-alarm
media-plugins/gmpc-albumview
media-plugins/gmpc-avahi
media-plugins/gmpc-awn
media-plugins/gmpc-discogs
media-plugins/gmpc-extraplaylist
media-plugins/gmpc-jamendo
media-plugins/gmpc-last-fm
media-plugins/gmpc-libnotify
media-plugins/gmpc-lyrics
media-plugins/gmpc-lyricwiki
media-plugins/gmpc-magnatune
media-plugins/gmpc-mdcover
media-plugins/gmpc-mmkeys
media-plugins/gmpc-mserver
media-plugins/gmpc-playlistsort
media-plugins/gmpc-shout
media-plugins/gmpc-tagedit


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: x11-base/xorg-x11

2022-10-01 Thread Matt Turner
# Matt Turner  (2022-10-01)
# Metapackage that has outlived its purpose. Made some sense in the immediate
# aftermath of X.Org modularization 15 years ago.
# Removal on 2022-11-01. Bugs #755233, #872119.
x11-base/xorg-x11


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH data/xml-schema 1/2] metadata.xsd: Add gnome remote-id

2022-09-13 Thread Matt Turner
On Tue, Sep 13, 2022 at 12:00 PM Michał Górny  wrote:
>
> On Tue, 2022-09-13 at 10:36 -0400, Matt Turner wrote:
> > On Tue, Sep 13, 2022 at 2:38 AM Michał Górny  wrote:
> > >
> > > On Mon, 2022-09-12 at 20:58 -0400, Matt Turner wrote:
> > > > Signed-off-by: Matt Turner 
> > > > ---
> > > >  metadata.xsd | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/metadata.xsd b/metadata.xsd
> > > > index 87972cb..cced33d 100644
> > > > --- a/metadata.xsd
> > > > +++ b/metadata.xsd
> > > > @@ -279,6 +279,7 @@
> > > >   
> > > >   
> > > >   
> > > > + 
> > > >   
> > > >   
> > > >   
> > >
> > > Some examples, please.  Are these somehow "global" identifiers or
> > > specific to their GitLab instances?
> >
> > This would be for gitlab.gnome.org. E.g. for x11-terms/gnome-terminal
> > whose git repo is located at
> > https://gitlab.gnome.org/GNOME/gnome-terminal.git, we'd have
> >
> > GNOME/gnome-terminal
> >
> > Similar situation for 'freedesktop' in patch 2/2, for 
> > gitlab.freedesktop.org.
> >
>
> Well, then I guess I'd prefer if these were "gnome-gitlab"
> and "freedesktop-gitlab" to make it clear which services the names
> correspond to.

Sure, will do.



Re: [gentoo-dev] [PATCH data/xml-schema 2/2] metadata.xsd: Add freedestkop remote-id

2022-09-13 Thread Matt Turner
On Tue, Sep 13, 2022 at 11:09 AM Ulrich Mueller  wrote:
>
> >>>>> On Tue, 13 Sep 2022, Matt Turner wrote:
>
> >   
> >   
> >   
> > + 
> >   
> >   
> >   
>
> Alphabetical order?

Oops, sorry. Yes!



Re: [gentoo-dev] [PATCH data/xml-schema 1/2] metadata.xsd: Add gnome remote-id

2022-09-13 Thread Matt Turner
On Tue, Sep 13, 2022 at 2:38 AM Michał Górny  wrote:
>
> On Mon, 2022-09-12 at 20:58 -0400, Matt Turner wrote:
> > Signed-off-by: Matt Turner 
> > ---
> >  metadata.xsd | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/metadata.xsd b/metadata.xsd
> > index 87972cb..cced33d 100644
> > --- a/metadata.xsd
> > +++ b/metadata.xsd
> > @@ -279,6 +279,7 @@
> >   
> >   
> >   
> > + 
> >   
> >   
> >   
>
> Some examples, please.  Are these somehow "global" identifiers or
> specific to their GitLab instances?

This would be for gitlab.gnome.org. E.g. for x11-terms/gnome-terminal
whose git repo is located at
https://gitlab.gnome.org/GNOME/gnome-terminal.git, we'd have

GNOME/gnome-terminal

Similar situation for 'freedesktop' in patch 2/2, for gitlab.freedesktop.org.



[gentoo-dev] [PATCH data/xml-schema 2/2] metadata.xsd: Add freedestkop remote-id

2022-09-12 Thread Matt Turner
Signed-off-by: Matt Turner 
---
 metadata.xsd | 1 +
 1 file changed, 1 insertion(+)

diff --git a/metadata.xsd b/metadata.xsd
index cced33d..a8a1467 100644
--- a/metadata.xsd
+++ b/metadata.xsd
@@ -281,6 +281,7 @@



+   



-- 
2.35.1




[gentoo-dev] [PATCH data/xml-schema 1/2] metadata.xsd: Add gnome remote-id

2022-09-12 Thread Matt Turner
Signed-off-by: Matt Turner 
---
 metadata.xsd | 1 +
 1 file changed, 1 insertion(+)

diff --git a/metadata.xsd b/metadata.xsd
index 87972cb..cced33d 100644
--- a/metadata.xsd
+++ b/metadata.xsd
@@ -279,6 +279,7 @@



+   



-- 
2.35.1




[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"

2022-07-22 Thread Matt Turner
On Fri, Jul 22, 2022 at 7:57 AM Joonas Niilola  wrote:
>
> Cross-posting to gentoo-dev and -project lists due to technical and
> non-technical nature. Reply-to is set to -project.
>
> Once again new council has been elected: congratulations to the chosen
> members! And once again many nominees expressed their wishes to see more
> non-developer contributors to become official developers. Yet, only very
> few people (if any) are interested in mentoring them. I get it, the
> relationship between a mentor and their mentee is very intimate, and
> mentoring takes a lot of time. While the Github PRs are helping us
> increase the user contributions merged, perhaps it's distancing us from
> creating stronger bonds with the contributors? But more about this topic
> later.
>
>
> 1st RFC: "Trusted contributor model"
>
> I'm proposing us to giving special commit access to our well-reputable
> contributors (mostly proxied maintainers). They'd have access _only_ to
> their maintained package in git-tree. To understand what I mean, check
>   git shortlog -s -n net-im/telegram-desktop-bin/
>   git shortlog -s -n net-im/signal-desktop-bin/
>
> There are few packages like these where I'd already trust the core
> proxied maintainer to commit at their will. It's as ajak said during the
> council election; _We_ are the bottleneck currently reviewing and
> _testing_ contributions, and with these two examples above, 99 % of time
> everything's in condition and we just need to merge. Obviously if these
> trusted contributors had to touch another package, or anything in
> profiles/ (just basically anything outside their dedicated package
> directory) they'd have to do a PR or .patch file to be merged by
> official developers. And they'd still need a proxy Gentoo
> developer/project listed in metadata, at least for now, to take
> responsibility.
>
> On the technical side I'm not sure how to achieve this, but I know it
> can be done. For example the sync-repos are compiled like this all the
> time. If this proposal gains support, I'm willing to start figuring it
> out more in-depth.
>
> AFAIK Fedora and Arch have somewhat similar systems in place already.

How would you suggest we track who has commit access, etc? The same
way we do with developers, via a developer bug?

I ask because I've noticed a lot of inactive proxied maintainers—one
of which had been listed in metadata.xml for 6 years but had never
committed to ::gentoo.



[gentoo-dev] [PATCH] vala.eclass: Raise minimum supported version to 0.50

2022-07-21 Thread Matt Turner
And remove the 0.42 special case while we're here.

Signed-off-by: Matt Turner 
---
 eclass/vala.eclass | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/eclass/vala.eclass b/eclass/vala.eclass
index 076ef906606..4e668d939fa 100644
--- a/eclass/vala.eclass
+++ b/eclass/vala.eclass
@@ -49,11 +49,10 @@ vala_api_versions() {
local minimal_supported_minor_version minor_version
 
# Dependency atoms are not generated for Vala versions older than 
0.${minimal_supported_minor_version}.
-   minimal_supported_minor_version="46"
+   minimal_supported_minor_version="50"
 
for ((minor_version = ${VALA_MAX_API_VERSION#*.}; minor_version >= 
${VALA_MIN_API_VERSION#*.}; minor_version = minor_version - 2)); do
-   # 0.42 is EOL and removed from tree; remove special case once 
minimal_support_minor_version >= 44
-   if ((minor_version >= minimal_supported_minor_version)) && 
((minor_version != 42)); then
+   if ((minor_version >= minimal_supported_minor_version)); then
echo "0.${minor_version}"
fi
done
-- 
2.35.1




Re: [gentoo-dev] Re: Introduce a pandoc virtual

2022-06-03 Thread Matt Turner
On Fri, Jun 3, 2022 at 12:35 PM Maciej Barć  wrote:
>
> > But you'll have to match KEYWORDS for both options first.
>
> Afaik KEYWORDS of virtuals are a union of KEYWORDS of it's dependencies.
> pandoc has "~amd64 ~x86", pandoc-bin has "~amd64" now, with possibility
> of "~arm64" (only those 2 arches are precompiled by upstream).
>
>  From Devmanual:
> > the developer can immediately set the KEYWORDS of a virtual to the union of 
> > KEYWORDS of its providers.

I agree with you.



[gentoo-dev] Last Rites: gnome-extra/gnome-documents

2022-05-23 Thread Matt Turner

# Matt Turner  (2022-05-23)
# Dead package upstream. Depends on dead app-misc/tracker:0.
# Removal on 2022-06-23. Bug #846605
gnome-extra/gnome-documents


signature.asc
Description: PGP signature


[gentoo-dev] dev-cpp/gconfmm: Last Rites

2022-05-19 Thread Matt Turner
# Matt Turner  (2022-05-19)
# Dead package upstream for more than 7 years.
# Removal on 2022-06-19.
dev-cpp/gconfmm


signature.asc
Description: PGP signature


[gentoo-dev] dev-cpp/libglademm: Last Rites

2022-05-19 Thread Matt Turner
# Matt Turner  (2022-05-19)
# Dead package upstream for more than 10 years.
# Removal on 2022-06-19. Bug #808237
dev-cpp/libglademm


signature.asc
Description: PGP signature


[gentoo-dev] dev-cpp/libgnomecanvasmm: Last Rites

2022-05-19 Thread Matt Turner
# Matt Turner  (2022-05-19)
# Dead package upstream for more than 10 years.
# Removal on 2022-06-19. Bug #808375
dev-cpp/libgnomecanvasmm


signature.asc
Description: PGP signature


[gentoo-dev] games-board/ascal: Last Rites

2022-05-19 Thread Matt Turner
# Matt Turner  (2022-05-19)
# Last release in 2006. Last upstream commit in 2007. One of two remaining
# reverse dependencies of dev-cpp/libglademm, which is dead. Last remaining
# reverse dependency of dev-cpp/libgnomecanvasmm, which is dead.
# Removal on 2022-06-19. Bug #845228
games-board/ascal


signature.asc
Description: PGP signature


[gentoo-dev] app-pda/barry: Last Rites

2022-05-19 Thread Matt Turner
# Matt Turner  (2022-05-19)
# Last release in 2013. Last upstream commit in 2015. One of two remaining
# reverse dependencies of dev-cpp/libglademm, which is dead.
# Removal on 2022-06-19. Bug #845231
app-pda/barry


signature.asc
Description: PGP signature


[gentoo-dev] games-board/ccgo: Last Rites

2022-05-19 Thread Matt Turner
# Matt Turner  (2022-05-19)
# Last release in 2010. Only one commit upstream since 2010 (in 2015). Only
# remaining reverse dependency of dev-cpp/gconfmm, which is dead.
# Removal on 2022-06-19. Bug #845234
games-board/ccgo


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: dev-perl/Gtk2-{SourceView2,Unique}

2022-05-17 Thread Matt Turner

# Matt Turner  (2022-05-17)
# Dead packages. No reverse dependencies.
# Removal on 2022-06-17
dev-perl/Gtk2-SourceView2
dev-perl/Gtk2-Unique


signature.asc
Description: PGP signature


[gentoo-dev] alpha profiles demoted to experimental

2022-05-17 Thread Matt Turner

To avoid gumming up the works for python@, I've dropped alpha profiles
to experimental. I hope to restore them to stable/dev in the future, but
if I don't, it won't be the worst thing in the world.

In any case, feel free to drop alpha keywords if you need to.



signature.asc
Description: PGP signature


Re: [gentoo-dev-announce] [gentoo-dev] Last Rites: app-pda/gtkpod

2022-04-26 Thread Matt Turner
On Mon, Apr 25, 2022 at 12:35 AM James Le Cuirot  wrote:
>
> On 24 April 2022 23:48:34 BST, Matt Turner  wrote:
> >On Sun, Apr 24, 2022 at 3:14 PM James Le Cuirot  wrote:
> >>
> >> On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote:
> >> > # Matt Turner  (2022-03-27)
> >> > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at
> >> > # least 6 years.
> >> > # Removal on 2022-05-02
> >> > app-pda/gtkpod
> >>
> >> Last rites has been cancelled. I'm taking over as maintainer.
> >
> >Okay, but are you doing the thing I asked?
> >
> >> If you can break the dependence on anjuta (which I didn't
> >> investigate), I'd have no problem keeping it. Would be nice to have an
> >> actual maintainer as well.
> >
> >No, you didn't:
> >
> >https://qa-reports.gentoo.org/output/gentoo-ci/d347eab546/output.html#app-pda/gtkpod
> >
> >:(
>
> Sorry, it was last thing at night and I hadn't noticed the keyword situation. 
> I think Anjuta is a key dependency and can't be dropped. I'll take it if 
> necessary. Maybe I'll strip it down.

I don't think this is going to be a workable solution. Maybe you
should take gtkpod into your overlay instead.

What's so frustrating is that these are the kinds of things you had
time to investigate in the weeks before you unmasked the package. This
is really not how this is supposed to work.



Re: [gentoo-dev-announce] [gentoo-dev] Last Rites: app-pda/gtkpod

2022-04-24 Thread Matt Turner
On Sun, Apr 24, 2022 at 3:14 PM James Le Cuirot  wrote:
>
> On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote:
> > # Matt Turner  (2022-03-27)
> > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at
> > # least 6 years.
> > # Removal on 2022-05-02
> > app-pda/gtkpod
>
> Last rites has been cancelled. I'm taking over as maintainer.

Okay, but are you doing the thing I asked?

> If you can break the dependence on anjuta (which I didn't
> investigate), I'd have no problem keeping it. Would be nice to have an
> actual maintainer as well.

No, you didn't:

https://qa-reports.gentoo.org/output/gentoo-ci/d347eab546/output.html#app-pda/gtkpod

:(



Re: [gentoo-dev] Last Rites: app-pda/gtkpod

2022-04-24 Thread Matt Turner
On Sun, Apr 3, 2022 at 1:56 PM Matt Turner  wrote:
>
> On Sun, Apr 3, 2022 at 1:53 AM James Le Cuirot  wrote:
> >
> > On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote:
> > > # Matt Turner  (2022-03-27)
> > > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at
> > > # least 6 years.
> > > # Removal on 2022-05-02
> > > app-pda/gtkpod
> >
> > I do still use this on rare occasions. It's not my favourite program but 
> > there
> > are no good alternatives, short of using Rhythmbox, which does more than I
> > want. I'm not aware that it's actually broken, aside from a couple of minor
> > warts in the package. Does it have to go?
>
> No, if you want to keep it -- feel free. I just saw it because it's
> the only reverse dependency of dev-util/anjuta which looks pretty dead
> itself, and then I saw how much more dead gtkpod looks.
>
> If you can break the dependence on anjuta (which I didn't
> investigate), I'd have no problem keeping it. Would be nice to have an
> actual maintainer as well.


Removal date is approaching. Are you planning to take this?



[gentoo-dev] Last Rites: x11-misc/gcolor2

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead package upstream. Uses GTK+ 2. No reverse dependencies.
# Removal on 2022-05-10
x11-misc/gcolor2


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: net-misc/vinagre and net-misc/vino

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead package upstream. No reverse dependencies.
# Removal on 2022-05-10
net-misc/vinagre
net-misc/vino


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: net-misc/grdesktop

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead package upstream (last release in 2004). No reverse dependencies.
# Removal on 2022-05-10
net-misc/grdesktop


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: gnome-extra/gnome-search-tool

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead package upstream. EAPI 5. Only reverse dependency is 
gnome-extra/gnome-utils.
# Removal on 2022-05-10
gnome-extra/gnome-search-tool


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: gnome-extra/filemanager-actions

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead package upstream. No reverse dependencies.
# Removal on 2022-05-10
gnome-extra/filemanager-actions


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: app-office/pinpoint

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead package upstream. No reverse dependencies.
# Removal on 2022-05-10
app-office/pinpoint


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: app-admin/gnome-system-log

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead package upstream. Only reverse dependency is gnome-extra/gnome-utils.
# Removal on 2022-05-10
app-admin/gnome-system-log


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: gnome-extra/gnome-utils

2022-04-10 Thread Matt Turner
# Matt Turner  (2022-04-10)
# Dead (meta)package upstream. No reverse dependencies.
# Removal on 2022-05-10
gnome-extra/gnome-utils


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] Add EAPI=8 support

2022-04-10 Thread Matt Turner
Subject should be prefixed with "cdrom.eclass:"



Re: [gentoo-dev] net-vpn/networkmanager-{openconnect,openvpn,pptp,vpnc} up for grabs

2022-04-08 Thread Matt Turner
On Sun, Apr 3, 2022 at 9:22 PM Matt Turner  wrote:
>
> These are all assigned to gnome@, but I don't use any of these, so I can't
> really test them. Please take them if you use them.
>
> They all need minor version bumps, and some have outstanding bugs and GitHub
> pull requests.
>
> acct-group/nm-openconnect
> acct-group/nm-openvpn
> acct-user/nm-openconnect
> acct-user/nm-openvpn
> net-vpn/networkmanager-openconnect
> net-vpn/networkmanager-openvpn
> net-vpn/networkmanager-pptp
> net-vpn/networkmanager-vpnc

I've bumped all these, pulled all the PRs, and fixed all the actionable bugs.

Still, it'd be great for someone to take them over.



Re: [gentoo-dev] [RFC] Moving s outta metadata.xml, into a consistent mapping

2022-04-07 Thread Matt Turner
On Thu, Apr 7, 2022 at 11:42 AM Michał Górny  wrote:
>
> Hello,
>
> Right now we're keeping both email addresses (obligatory) and names
> (optional) for downstream maintainers in metadata.xml.  The way I see
> it, there are three problems with that:
>
> 1. As noticed on IRC lately, a few devs haven't been listing their names
> at all, resulting in these names being missing from packages.g.o.
>
> 2. Not all names are listed consistently.  This is especially the case
> for projects.  When you want to group everything by maintainer, which
> name should be used?
>
> 3. In the end, listing the same names all over the place is a lot of
> redundancy.
>
>
> I'd like to propose that we deprecate  for downstream
> maintainers, and instead work towards using an additional mapping from
> maintainer email addresses to their names.
>
> a. For projects, we can simply use projects.xml.  We already require
> that all type="project" maintainers correspond to entries
> in projects.xml, so we should be good here.
>
> b. For human maintainers, I think we can use metadata/AUTHORS.  This is
> pretty much killing two birds with one stone -- we could finally getting
> the file more complete, and at the same time use it to provide names for
> maintainers.
>
> While keeping names in metadata.xml has the advantage that they are
> immediately available (provided that they are actually listed there),
> I don't think this is really a show-stopper.

Sounds like a good plan to me.



[gentoo-dev] Last Rites: dev-util/nemiver

2022-04-06 Thread Matt Turner

# Matt Turner  (2022-04-06)
# Dead package upstream. No reverse dependencies.
# Removal on 2022-05-06
dev-util/nemiver


signature.asc
Description: PGP signature


Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-05 Thread Matt Turner
On Tue, Apr 5, 2022 at 12:30 PM Jason A. Donenfeld  wrote:
> By the way, we're not currently _checking_ two hash functions during
> src_prepare(), are we?

I don't know, but the hash-checking is definitely checked before src_prepare().



Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-05 Thread Matt Turner
On Tue, Apr 5, 2022 at 11:47 AM Jason A. Donenfeld  wrote:
>
> Hi Michal,
>
> On Tue, Apr 05, 2022 at 02:49:12PM +, Michał Górny wrote:
> > > I don't really care which one we use, so long as it's not already
> > > broken or too obscure/new. So in other words, any one of SHA2-256,
> > > SHA2-512, SHA3, BLAKE2b, BLAKE2s would be fine with me. Can we just
> > > pick one and roll with it?
> >
> > Back when we added BLAKE2b, the idea was to eventually remove SHA512
> > (the previous hash).  However, this was rejected afterwards.
>
> Maybe we should pick that back up? Do you remember the ultimate
> rationale for rejecting it? Do you suppose those are still valid?

(Somehow you broke threading)

This was a topic in June 2021's Council meeting:

https://gitweb.gentoo.org/sites/projects/council.git/tree/meeting-logs/20210613-summary.txt#n33
https://gitweb.gentoo.org/sites/projects/council.git/tree/meeting-logs/20210613.txt#n137

Basically there was no great reason presented for making the change
and some (IMO specious) reasons for keeping multiple hashes. I don't
think anyone felt strongly enough about removing one hash to fight for
it.



[gentoo-dev] net-vpn/networkmanager-{openconnect,openvpn,pptp,vpnc} up for grabs

2022-04-03 Thread Matt Turner
These are all assigned to gnome@, but I don't use any of these, so I can't
really test them. Please take them if you use them.

They all need minor version bumps, and some have outstanding bugs and GitHub
pull requests.

acct-group/nm-openconnect
acct-group/nm-openvpn
acct-user/nm-openconnect
acct-user/nm-openvpn
net-vpn/networkmanager-openconnect
net-vpn/networkmanager-openvpn
net-vpn/networkmanager-pptp
net-vpn/networkmanager-vpnc 


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last Rites: app-pda/gtkpod

2022-04-03 Thread Matt Turner
On Sun, Apr 3, 2022 at 1:53 AM James Le Cuirot  wrote:
>
> On Sat, 2022-04-02 at 21:35 -0700, Matt Turner wrote:
> > # Matt Turner  (2022-03-27)
> > # Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at
> > # least 6 years.
> > # Removal on 2022-05-02
> > app-pda/gtkpod
>
> I do still use this on rare occasions. It's not my favourite program but there
> are no good alternatives, short of using Rhythmbox, which does more than I
> want. I'm not aware that it's actually broken, aside from a couple of minor
> warts in the package. Does it have to go?

No, if you want to keep it -- feel free. I just saw it because it's
the only reverse dependency of dev-util/anjuta which looks pretty dead
itself, and then I saw how much more dead gtkpod looks.

If you can break the dependence on anjuta (which I didn't
investigate), I'd have no problem keeping it. Would be nice to have an
actual maintainer as well.



[gentoo-dev] Last Rites: app-pda/gtkpod

2022-04-02 Thread Matt Turner
# Matt Turner  (2022-03-27)
# Dead package. Homepage doesn't resolve. Unmaintained in Gentoo for at
# least 6 years.
# Removal on 2022-05-02
app-pda/gtkpod


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: dev-util/fix-la-relink-command

2022-03-27 Thread Matt Turner
# Matt Turner  (2022-03-27)
# Dead package. No reverse dependencies.
# Removal on 2022-04-27
dev-util/fix-la-relink-command


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: dev-libs/gtx

2022-03-27 Thread Matt Turner
# Matt Turner  (2022-03-27)
# Dead package. No reverse dependencies since 2017.
# Removal on 2022-04-27
dev-libs/gtx


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: dev-util/appdata-tools

2022-03-27 Thread Matt Turner
# Matt Turner  (2022-03-27)
# Dead package. See 
https://blogs.gnome.org/hughsie/2014/10/30/appdata-tools-is-dead/
# Bug #680552
# Removal on 2022-04-27
dev-util/appdata-tools


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: Some dev-perl/ GNOME2/Gtk2 packages

2022-03-27 Thread Matt Turner
# Matt Turner  (2022-03-27)
# GNOME 2 era packages. No reverse dependencies.
# Removal on 2022-04-27
dev-perl/gnome2-canvas
dev-perl/Gtk2-Ex-PodViewer
dev-perl/Gtk2-Ex-PrintDialog
dev-perl/Gtk2-Ex-Simple-List
dev-perl/Gtk2-ImageView


signature.asc
Description: PGP signature


[gentoo-portage-dev] Changing the VDB format

2022-03-13 Thread Matt Turner
The VDB uses a one-file-per-variable format. This has some
inefficiencies, with many file systems. For example the 'EAPI' file
that contains a single character will consume a 4K block on disk.

$ cd /var/db/pkg/sys-apps/portage-3.0.30-r1/
$ ls -lh --block-size=1 | awk 'BEGIN { sum = 0; } { sum += $5; } END {
print sum }'
418517
$ du -sh --apparent-size .
413K.
$ du -sh .
556K.

During normal operations, portage has to read each of these 35+
files/package individually.

I suggest that we change the VDB format to a commonly used format that
can be quickly read by portage and any other tools. Combining these
35+ files into a single file with a commonly used format should:

- speed up vdb access
- improve disk usage
- allow external tools to access VDB data more easily

I've attached a program that prints the VDB contents of a specified
package in different formats: json, toml, and yaml (and also Python
PrettyPrinter, just because). I think it's important to keep the VDB
format as plain-text for ease of manipulation, so I have not
considered anything like sqlite.

I expected to prefer toml, but I actually find it to be rather gross looking.

$ ~/vdb.py --toml /var/db/pkg/sys-apps/portage-3.0.30-r1/ | wc -c
444663
$ ~/vdb.py --yaml /var/db/pkg/sys-apps/portage-3.0.30-r1/ | wc -c
385112
$ ~/vdb.py --json /var/db/pkg/sys-apps/portage-3.0.30-r1/ | wc -c
273428

toml and yaml are formatted in a human-readable manner, but json is
not. Pipe the json output to app-misc/jq to get a better sense of its
structure:

$ ~/vdb.py --json /var/db/pkg/sys-apps/portage-3.0.30-r1/ | jq
...

Compare with the raw contents of the files:

$ ls -lh --block-size=1 | grep -v
'\(environment.bz2\|repository\|\.ebuild\)' | awk 'BEGIN { sum = 0; }
{ sum += $5; } END { print sum }'
378658

Yes, the json is actually smaller because it does not contain large
amounts of duplicated path strings in CONTENTS (which is 375320 bytes
by itself, or 89% of the total size).

I recommend json and think it is the best choice because:

- json provides the smallest on-disk footprint
- json is part of Python's standard library (so is yaml, and toml will
be in Python 3.11)
- Every programming language has multiple json parsers
-- lots of effort has been spent making them extremely fast.

I think we would have a significant time period for the transition. I
think I would include support for the new format in Portage, and ship
a tool with portage to switch back and forth between old and new
formats on-disk. Maybe after a year, drop the code from Portage to
support the old format?

Thoughts?
#!/usr/bin/env python

import argparse
import json
import pprint
import sys
import toml
import yaml

from pathlib import Path


def main(argv):
pp = pprint.PrettyPrinter(indent=2)

parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group(required=True)
group.add_argument('--json', action='store_true')
group.add_argument('--toml', action='store_true')
group.add_argument('--yaml', action='store_true')
group.add_argument('--pprint', action='store_true')
parser.add_argument('vdbdir', type=str)

opts = parser.parse_args(argv[1:])

vdb = Path(opts.vdbdir)
if not vdb.is_dir():
print(f'{vdb} is not a directory')
sys.exit(-1)

d = {}

for file in (x for x in vdb.iterdir()):
if not file.name.isupper():
# print(f"Ignoring file {file.name}")
continue

value = file.read_text().rstrip('\n')

if file.name == "CONTENTS":
contents = {}

for line in value.splitlines(keepends=False):
(type, *rest) = line.split(sep=' ')
parts = rest[0].split(sep='/')
p = contents

if type == 'dir':
assert(len(rest) == 1)

for part in parts[1:]:
p = p.setdefault(part, {})
else:
for part in parts[1:-1]:
p = p.get(part)

if type == 'obj':
assert(len(rest) == 3)
p[parts[-1]] = {'hash': rest[1], 'size': rest[2]}
elif type == 'sym':
assert(len(rest) == 4)
p[parts[-1]] = {'target': rest[2], 'size': rest[3]}

d[file.name] = contents

elif file.name in ('DEFINED_PHASES', 'FEATURES', 'HOMEPAGE',
   'INHERITED', 'IUSE', 'IUSE_EFFECTIVE', 'LICENSE',
   'KEYWORDS', 'PKGUSE', 'RESTRICT', 'USE'):
d[file.name] = value.split(' ')
else:
d[file.name] = value

if opts.json:
json.dump(d, sys.stdout)
if opts.toml:
toml.dump(d, sys.stdout)
if opts.yaml:
yaml.dump(d, sys.stdout)
if opts.pprint:
pp.pprint(d)


if __name__ == '__main__':
main(sys.argv)


[gentoo-dev] Re: Deprecating repoman

2022-03-13 Thread Matt Turner
On Sat, Mar 12, 2022 at 12:26 PM Matt Turner  wrote:
> I've filed a Council bug to approve the plan for deprecating repoman.
> See https://bugs.gentoo.org/835013

With a vote of 6-0, the Council approved the following motion:

> pkgcheck is now considered the primary Gentoo tool for ebuild QA.  repoman is
> no longer considered sufficient. Council condones the deprecation and removal
> of repoman by the portage team.

There was resistance to the idea of making repoman print a deprecation
warning when executed, so I will drop that idea from the plan.



[gentoo-dev] Re: Deprecating repoman

2022-03-12 Thread Matt Turner
I've filed a Council bug to approve the plan for deprecating repoman.
See https://bugs.gentoo.org/835013

The proposed plan, as copied from the bug is:

> The devmanual has already been updated to contain information about pkgdev, 
> in March 2021. See 
> https://gitweb.gentoo.org/proj/devmanual.git/log/?qt=grep=pkgdev
>
> I have opened a devmanual pull request to remove references to repoman that 
> might suggest that it is still an appropriate tool to use. See 
> https://github.com/gentoo/devmanual/pull/274
>
> The next steps once the devmanual change is committed, I think, are
>
> - Give the wiki similar treatment as the devmanual, replacing and removing 
> references to repoman that would suggest it is an appropriate tool to use.
>
> - Modify repoman to emit a warning informing users of its deprecation
>
> - After some period of time, maybe 6 months, give last rites to repoman
>
> - Delete repoman from portage.git
>
> (and of course adding any features/behaviors we find lacking in pkgdev, et al)



Re: [gentoo-dev] Deprecating repoman

2022-03-11 Thread Matt Turner
On Fri, Mar 11, 2022 at 4:43 PM Francesco Riosa  wrote:
>
> Il giorno mer 9 mar 2022 alle ore 22:01 Matt Turner  ha 
> scritto:
>>
>> I'd like to deprecate and ultimately remove repoman. I believe that
>> dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts)
>
>
> Hi using  `repoman manifest` in scripts here, what would be the correct 
> replacement for that?

pkgdev manifest



[gentoo-dev] Re: Deprecating repoman

2022-03-11 Thread Matt Turner
I've filed a PR against devmanual.git to remove references to repoman
and replace them with references to pkgdev where appropriate. Most
everywhere already had pkgdev/pkgcheck text in place so there wasn't
much to do. See: https://github.com/gentoo/devmanual/pull/274



Re: [gentoo-dev] Deprecating repoman

2022-03-10 Thread Matt Turner
On Wed, Mar 9, 2022 at 11:09 PM Joonas Niilola  wrote:
>
> On 9.3.2022 23.00, Matt Turner wrote:
> > I'd like to deprecate and ultimately remove repoman. I believe that
> > dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts)
> > are far superior replacements, and it makes sense to have people using
> > the same tool and seeing the same warnings as in the CI.
> >
> > Are there any useful checks or behaviors of repoman that are missing
> > from pkgcheck and pkgcommit?
> >
> > Thanks,
> > Matt
> >
>
> I still fail to see the "why" in here. Repoman is better than pure 'git
> commit' that I know some people still like to use, and as long as it's
> kept maintained.

repoman is inferior to other tooling mentioned. The other tooling is
actually run in CI. Developers should get the same warnings locally as
in CI. Restated another way: I'm tired of telling people to stop using
repoman or "pkgcheck would have caught that".

> My only worry is: are pkgcheck and pkgdev _really_ maintained anymore?
> More than repoman is?

More than repoman is, definitely.



Re: [gentoo-dev] Deprecating repoman

2022-03-09 Thread Matt Turner
On Wed, Mar 9, 2022 at 4:18 PM Matthias Maier  wrote:
>
>
> On Wed, Mar  9, 2022, at 17:32 CST, Matt Turner  wrote:
>
> > I think you just made that number up :)
>
> Nah. My sample was just bad (ago just made a sizable number of commits.
>
> I would estimate the current usage of repoman to be about 20-25%, down
> from well over 80-90% back when we just switched to git:
>
>   https://tamiko.43-1.org/temp/repoman-usage.pdf

Very interesting. Thanks!



Re: [gentoo-dev] Deprecating repoman

2022-03-09 Thread Matt Turner
On Wed, Mar 9, 2022 at 2:34 PM Matthias Maier  wrote:
>
> On Wed, Mar  9, 2022, at 15:47 CST, Matt Turner  wrote:
>
> > [...]
> >
> > I wouldn't block anyone from doing this, but it's not something I'm
> > personally interested in pursuing. I see very little value here.
>
> I did not intend to imply that you should do anything.
>
> I just want to point out that we had been educating developers for using
> "repoman" to commit for a long time and looking at the "git log" history
> shows that repoman is still used by a sizable number of developers
> (around 50%-ish).

I think you just made that number up :)

> So, it would be very nice to have a somewhat official "blessed"
> alternative in place.
>
>
> For example, dev-util/pkgdev was suggested as an alternative, but I
> cannot assess whether this is indeed a viable alternative.

Why not? Give it a try.



Re: [gentoo-dev] Deprecating repoman

2022-03-09 Thread Matt Turner
On Wed, Mar 9, 2022 at 1:37 PM Matthias Maier  wrote:
>
>
> Just a quick though:
>
> Looking at the man page of repoman it doesn't look to difficult to
> replicate the behavior with pkgcheck. Meaning, we could think of
> creating a drop-in replacement for "repoman [full]" (which would just
> call pkgcheck) and "repoman commit" which actually does much more than
> just prepending the git commit summary line: repoman commit does
>
>- update the manifest
>- bail out if files are not correctly "git add"ed
>- add the output of [pkgcheck] as a comment to the git commit
>  description

I wouldn't block anyone from doing this, but it's not something I'm
personally interested in pursuing. I see very little value here.



Re: [gentoo-dev] Deprecating repoman

2022-03-09 Thread Matt Turner
On Wed, Mar 9, 2022 at 1:32 PM Brian Evans  wrote:
>
> On 3/9/2022 4:28 PM, Matt Turner wrote:
> > On Wed, Mar 9, 2022 at 1:27 PM Maciej Barć  wrote:
> >>
> >>> Are there any useful checks or behaviors of repoman that are missing
> >>> from pkgcheck and pkgcommit?
> >>
> >> Fixing ebuild copyright date is the first one that comes to mind.
> >
> > pkgcommit does this.
> >
> I highly doubt it as it sits in the github repo
> https://github.com/mgorny/mgorny-dev-scripts/blob/master/pkgcommit
> basically sets up $EDITOR with "cat/pkg:" with an optional message in
> front then passes to 'git commit'

Ah, sorry. copybump (called by pkgbump) is actually what updates the copyright:

https://github.com/mgorny/mgorny-dev-scripts/blob/master/copybump



Re: [gentoo-dev] Deprecating repoman

2022-03-09 Thread Matt Turner
On Wed, Mar 9, 2022 at 1:27 PM Maciej Barć  wrote:
>
> > Are there any useful checks or behaviors of repoman that are missing
> > from pkgcheck and pkgcommit?
>
> Fixing ebuild copyright date is the first one that comes to mind.

pkgcommit does this.



Re: [gentoo-dev] Deprecating repoman

2022-03-09 Thread Matt Turner
On Wed, Mar 9, 2022 at 1:15 PM Rich Freeman  wrote:
>
> On Wed, Mar 9, 2022 at 4:00 PM Matt Turner  wrote:
> >
> > Are there any useful checks or behaviors of repoman that are missing
> > from pkgcheck and pkgcommit?
>
> Would it make sense to package pkgcommit or otherwise stick it
> somewhere official?  I know there is a copy on mgorny's github
> repo/blog, but if this is going to become the recommended way to do
> commits we might want to stick it someplace a bit more canonical, and
> having it in a package would ensure that if there are any changes they
> get distributed.

I agree, this would be nice. (And it's already in a package,
app-portage/mgorny-dev-scripts as I mentioned)

> Obviously there are other ways to set it, but it lacks obtaining the
> gpg key to use from make.conf.  I'm not sure that is really the best
> place to put it in any case.  Just figured I'd point it out.

I think some bit of this message was lost? Looks like you're asking
about where we should set the GPG key used for signing commits. IMO
.git/config is the right place. Configuring it in make.conf was not a
good idea, and as a follow-on I'd like to remove that.



[gentoo-dev] Deprecating repoman

2022-03-09 Thread Matt Turner
I'd like to deprecate and ultimately remove repoman. I believe that
dev-util/pkgcheck and pkgcommit (from app-portage/mgorny-dev-scripts)
are far superior replacements, and it makes sense to have people using
the same tool and seeing the same warnings as in the CI.

Are there any useful checks or behaviors of repoman that are missing
from pkgcheck and pkgcommit?

Thanks,
Matt



[gentoo-portage-dev] [PATCH 4/4] portage.eapi: use functools @lru_cache decorator instead of custom implementation

2022-02-23 Thread Matt Turner
From: "Wolfgang E. Sanyer" 

Reviewed-by: Matt Turner 
Signed-off-by: Wolfgang E. Sanyer 
---
 lib/portage/eapi.py | 155 
 1 file changed, 72 insertions(+), 83 deletions(-)

diff --git a/lib/portage/eapi.py b/lib/portage/eapi.py
index 56e64620a..efcc6c2a0 100644
--- a/lib/portage/eapi.py
+++ b/lib/portage/eapi.py
@@ -2,12 +2,10 @@
 # Distributed under the terms of the GNU General Public License v2
 
 import collections
-import operator
-import types
-
-from portage import eapi_is_supported
+from functools import lru_cache
 
 
+@lru_cache(None)
 def eapi_has_iuse_defaults(eapi):
 if eapi is None:
 return True
@@ -15,6 +13,7 @@ def eapi_has_iuse_defaults(eapi):
 return eapi != "0"
 
 
+@lru_cache(None)
 def eapi_has_iuse_effective(eapi):
 if eapi is None:
 return False
@@ -22,6 +21,7 @@ def eapi_has_iuse_effective(eapi):
 return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
 
 
+@lru_cache(None)
 def eapi_has_slot_deps(eapi):
 if eapi is None:
 return True
@@ -29,6 +29,7 @@ def eapi_has_slot_deps(eapi):
 return eapi != "0"
 
 
+@lru_cache(None)
 def eapi_has_slot_operator(eapi):
 if eapi is None:
 return True
@@ -36,6 +37,7 @@ def eapi_has_slot_operator(eapi):
 return eapi not in ("0", "1", "2", "3", "4", "4-python")
 
 
+@lru_cache(None)
 def eapi_has_src_uri_arrows(eapi):
 if eapi is None:
 return True
@@ -43,6 +45,7 @@ def eapi_has_src_uri_arrows(eapi):
 return eapi not in ("0", "1")
 
 
+@lru_cache(None)
 def eapi_has_selective_src_uri_restriction(eapi):
 if eapi is None:
 return True
@@ -62,6 +65,7 @@ def eapi_has_selective_src_uri_restriction(eapi):
 )
 
 
+@lru_cache(None)
 def eapi_has_use_deps(eapi):
 if eapi is None:
 return True
@@ -69,6 +73,7 @@ def eapi_has_use_deps(eapi):
 return eapi not in ("0", "1")
 
 
+@lru_cache(None)
 def eapi_has_strong_blocks(eapi):
 if eapi is None:
 return True
@@ -76,10 +81,12 @@ def eapi_has_strong_blocks(eapi):
 return eapi not in ("0", "1")
 
 
+@lru_cache(None)
 def eapi_has_src_prepare_and_src_configure(eapi):
 return eapi not in ("0", "1")
 
 
+@lru_cache(None)
 def eapi_supports_prefix(eapi):
 if eapi is None:
 return True
@@ -87,6 +94,7 @@ def eapi_supports_prefix(eapi):
 return eapi not in ("0", "1", "2")
 
 
+@lru_cache(None)
 def eapi_exports_AA(eapi):
 if eapi is None:
 return False
@@ -94,6 +102,7 @@ def eapi_exports_AA(eapi):
 return eapi in ("0", "1", "2", "3")
 
 
+@lru_cache(None)
 def eapi_exports_KV(eapi):
 if eapi is None:
 return False
@@ -101,6 +110,7 @@ def eapi_exports_KV(eapi):
 return eapi in ("0", "1", "2", "3")
 
 
+@lru_cache(None)
 def eapi_exports_merge_type(eapi):
 if eapi is None:
 return True
@@ -108,6 +118,7 @@ def eapi_exports_merge_type(eapi):
 return eapi not in ("0", "1", "2", "3")
 
 
+@lru_cache(None)
 def eapi_exports_replace_vars(eapi):
 if eapi is None:
 return True
@@ -115,6 +126,7 @@ def eapi_exports_replace_vars(eapi):
 return eapi not in ("0", "1", "2", "3")
 
 
+@lru_cache(None)
 def eapi_exports_EBUILD_PHASE_FUNC(eapi):
 if eapi is None:
 return True
@@ -122,6 +134,7 @@ def eapi_exports_EBUILD_PHASE_FUNC(eapi):
 return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
 
 
+@lru_cache(None)
 def eapi_exports_PORTDIR(eapi):
 if eapi is None:
 return True
@@ -140,6 +153,7 @@ def eapi_exports_PORTDIR(eapi):
 )
 
 
+@lru_cache(None)
 def eapi_exports_ECLASSDIR(eapi):
 if eapi is None:
 return False
@@ -158,22 +172,27 @@ def eapi_exports_ECLASSDIR(eapi):
 )
 
 
+@lru_cache(None)
 def eapi_exports_REPOSITORY(eapi):
 return eapi in ("4-python", "5-progress")
 
 
+@lru_cache(None)
 def eapi_has_pkg_pretend(eapi):
 return eapi not in ("0", "1", "2", "3")
 
 
+@lru_cache(None)
 def eapi_has_implicit_rdepend(eapi):
 return eapi in ("0", "1", "2", "3")
 
 
+@lru_cache(None)
 def eapi_has_dosed_dohard(eapi):
 return eapi in ("0", "1", "2", "3")
 
 
+@lru_cache(None)
 def eapi_has_required_use(eapi):
 if eapi is None:
 return True
@@ -181,6 +200,7 @@ def eapi_has_required_use(eapi):
 return eapi not in ("0", "1", "2&q

[gentoo-portage-dev] [PATCH 3/4] portage.eapi: move None check to helper functions

2022-02-23 Thread Matt Turner
From: "Wolfgang E. Sanyer" 

Reviewed-by: Matt Turner 
Signed-off-by: Wolfgang E. Sanyer 
---
 lib/portage/eapi.py | 162 +---
 1 file changed, 121 insertions(+), 41 deletions(-)

diff --git a/lib/portage/eapi.py b/lib/portage/eapi.py
index 18069b04b..56e64620a 100644
--- a/lib/portage/eapi.py
+++ b/lib/portage/eapi.py
@@ -9,26 +9,44 @@ from portage import eapi_is_supported
 
 
 def eapi_has_iuse_defaults(eapi):
+if eapi is None:
+return True
+
 return eapi != "0"
 
 
 def eapi_has_iuse_effective(eapi):
+if eapi is None:
+return False
+
 return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
 
 
 def eapi_has_slot_deps(eapi):
+if eapi is None:
+return True
+
 return eapi != "0"
 
 
 def eapi_has_slot_operator(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2", "3", "4", "4-python")
 
 
 def eapi_has_src_uri_arrows(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1")
 
 
 def eapi_has_selective_src_uri_restriction(eapi):
+if eapi is None:
+return True
+
 return eapi not in (
 "0",
 "1",
@@ -45,10 +63,16 @@ def eapi_has_selective_src_uri_restriction(eapi):
 
 
 def eapi_has_use_deps(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1")
 
 
 def eapi_has_strong_blocks(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1")
 
 
@@ -57,30 +81,51 @@ def eapi_has_src_prepare_and_src_configure(eapi):
 
 
 def eapi_supports_prefix(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2")
 
 
 def eapi_exports_AA(eapi):
+if eapi is None:
+return False
+
 return eapi in ("0", "1", "2", "3")
 
 
 def eapi_exports_KV(eapi):
+if eapi is None:
+return False
+
 return eapi in ("0", "1", "2", "3")
 
 
 def eapi_exports_merge_type(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2", "3")
 
 
 def eapi_exports_replace_vars(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2", "3")
 
 
 def eapi_exports_EBUILD_PHASE_FUNC(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
 
 
 def eapi_exports_PORTDIR(eapi):
+if eapi is None:
+return True
+
 return eapi in (
 "0",
 "1",
@@ -96,6 +141,9 @@ def eapi_exports_PORTDIR(eapi):
 
 
 def eapi_exports_ECLASSDIR(eapi):
+if eapi is None:
+return False
+
 return eapi in (
 "0",
 "1",
@@ -127,18 +175,30 @@ def eapi_has_dosed_dohard(eapi):
 
 
 def eapi_has_required_use(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2", "3")
 
 
 def eapi_has_required_use_at_most_one_of(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
 
 
 def eapi_has_use_dep_defaults(eapi):
+if eapi is None:
+return True
+
 return eapi not in ("0", "1", "2", "3")
 
 
 def eapi_requires_posixish_locale(eapi):
+if eapi is None:
+return False
+
 return eapi not in (
 "0",
 "1",
@@ -153,14 +213,23 @@ def eapi_requires_posixish_locale(eapi):
 
 
 def eapi_has_repo_deps(eapi):
+if eapi is None:
+return True
+
 return eapi in ("4-python", "5-progress")
 
 
 def eapi_allows_dots_in_PN(eapi):
+if eapi is None:
+return True
+
 return eapi in ("4-python", "5-progress")
 
 
 def eapi_allows_dots_in_use_flags(eapi):
+if eapi is None:
+return True
+
 return eapi in ("4-python", "5-progress")
 
 
@@ -181,6 +250,9 @@ def eapi_has_automatic_unpack_dependencies(eapi):
 
 
 def eapi_allows_package_provided(eapi):
+if eapi is None:
+return True
+
 return eapi in (
 "0",
 "1",
@@ -196,6 +268,9 @@ def eapi_allows_package_provided(eapi):
 
 
 def eapi_has_bdepend(eapi):
+if eapi is None:
+return False
+
 return eapi not in (
 "0",
 "1

[gentoo-portage-dev] [PATCH 2/4] portage.eapi: use tuple instead of str for namedtuple definition

2022-02-23 Thread Matt Turner
From: "Wolfgang E. Sanyer" 

Reviewed-by: Matt Turner 
Signed-off-by: Wolfgang E. Sanyer 
---
 lib/portage/eapi.py | 52 -
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/lib/portage/eapi.py b/lib/portage/eapi.py
index adee87d00..18069b04b 100644
--- a/lib/portage/eapi.py
+++ b/lib/portage/eapi.py
@@ -288,25 +288,39 @@ def eapi_has_sysroot(eapi):
 
 _eapi_attrs = collections.namedtuple(
 "_eapi_attrs",
-"allows_package_provided "
-"bdepend "
-"broot "
-"dots_in_PN dots_in_use_flags "
-"exports_AA "
-"exports_EBUILD_PHASE_FUNC "
-"exports_ECLASSDIR "
-"exports_KV "
-"exports_merge_type "
-"exports_PORTDIR "
-"exports_replace_vars "
-"feature_flag_test "
-"idepend iuse_defaults iuse_effective posixish_locale "
-"path_variables_end_with_trailing_slash "
-"prefix "
-"repo_deps required_use required_use_at_most_one_of "
-"selective_src_uri_restriction slot_operator slot_deps "
-"src_uri_arrows strong_blocks use_deps use_dep_defaults "
-"empty_groups_always_true sysroot",
+(
+"allows_package_provided",
+"bdepend",
+"broot",
+"dots_in_PN",
+"dots_in_use_flags",
+"exports_AA",
+"exports_EBUILD_PHASE_FUNC",
+"exports_ECLASSDIR",
+"exports_KV",
+"exports_merge_type",
+"exports_PORTDIR",
+"exports_replace_vars",
+"feature_flag_test",
+"idepend",
+"iuse_defaults",
+"iuse_effective",
+"posixish_locale",
+"path_variables_end_with_trailing_slash",
+"prefix",
+"repo_deps",
+"required_use",
+"required_use_at_most_one_of",
+"selective_src_uri_restriction",
+"slot_operator",
+"slot_deps",
+"src_uri_arrows",
+"strong_blocks",
+"use_deps",
+"use_dep_defaults",
+"empty_groups_always_true",
+"sysroot",
+),
 )
 
 
-- 
2.34.1




[gentoo-portage-dev] [PATCH 1/4] portage.dep.Atom: Clean up __new__ parameters

2022-02-23 Thread Matt Turner
From: "Wolfgang E. Sanyer" 

Reviewed-by: Matt Turner 
Signed-off-by: Wolfgang E. Sanyer 
---
 lib/portage/dep/__init__.py | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/lib/portage/dep/__init__.py b/lib/portage/dep/__init__.py
index 3b3577025..13c0f4ef7 100644
--- a/lib/portage/dep/__init__.py
+++ b/lib/portage/dep/__init__.py
@@ -1489,17 +1489,7 @@ class Atom(str):
 def __init__(self, forbid_overlap=False):
 self.overlap = self._overlap(forbid=forbid_overlap)
 
-def __new__(
-cls,
-s,
-unevaluated_atom=None,
-allow_wildcard=False,
-allow_repo=None,
-_use=None,
-eapi=None,
-is_valid_flag=None,
-allow_build_id=None,
-):
+def __new__(cls, s, *args, **kwargs):
 return str.__new__(cls, s)
 
 def __init__(
-- 
2.34.1




[gentoo-portage-dev] [PATCH 2/2] Eliminate now-dead code from EAPIs 4-python and 5-progress

2022-02-21 Thread Matt Turner
Signed-off-by: Matt Turner 
---
 bin/eapi.sh   |  32 
 bin/ebuild.sh |   9 -
 bin/phase-helpers.sh  | 166 --
 bin/portageq  |   5 +-
 bin/save-ebuild-env.sh|   7 -
 lib/_emerge/EbuildMetadataPhase.py|  17 --
 lib/_emerge/Package.py|  15 +-
 lib/portage/dep/__init__.py   | 138 +++
 lib/portage/eapi.py   |  29 +--
 .../package/ebuild/_config/UseManager.py  |   3 +-
 .../ebuild/_config/unpack_dependencies.py |  55 --
 .../package/ebuild/_ipc/QueryCommand.py   |   6 +-
 lib/portage/package/ebuild/config.py  |   8 -
 lib/portage/package/ebuild/doebuild.py|   9 -
 lib/portage/repository/config.py  |   4 -
 .../tests/resolver/ResolverPlayground.py  |   1 -
 lib/portage/versions.py   |  66 ++-
 17 files changed, 50 insertions(+), 520 deletions(-)
 delete mode 100644 lib/portage/package/ebuild/_config/unpack_dependencies.py

diff --git a/bin/eapi.sh b/bin/eapi.sh
index b6d2e07f1..a39513b1c 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -144,34 +144,6 @@ ___eapi_has_useq() {
[[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6|7)$ ]]
 }
 
-___eapi_has_master_repositories() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
-___eapi_has_repository_path() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
-___eapi_has_available_eclasses() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
-___eapi_has_eclass_path() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
-___eapi_has_license_path() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
-___eapi_has_package_manager_build_user() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
-___eapi_has_package_manager_build_group() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
 # HELPERS BEHAVIOR
 
 ___eapi_best_version_and_has_version_support_--host-root() {
@@ -296,10 +268,6 @@ ___eapi_enables_failglob_in_global_scope() {
[[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5)$ ]]
 }
 
-___eapi_enables_globstar() {
-   [[ ${1-${EAPI-0}} =~ ^$ ]]
-}
-
 ___eapi_bash_3_2() {
[[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5)$ ]]
 }
diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 5b0b79585..628d7eb80 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -73,11 +73,6 @@ else
# These functions die because calls to them during the "depend" phase
# are considered to be severe QA violations.
funcs+=" best_version has_version portageq"
-   ___eapi_has_master_repositories && funcs+=" master_repositories"
-   ___eapi_has_repository_path && funcs+=" repository_path"
-   ___eapi_has_available_eclasses && funcs+=" available_eclasses"
-   ___eapi_has_eclass_path && funcs+=" eclass_path"
-   ___eapi_has_license_path && funcs+=" license_path"
for x in ${funcs} ; do
eval "${x}() { die \"\${FUNCNAME}() calls are not allowed in 
global scope\"; }"
done
@@ -573,10 +568,6 @@ if ! has "$EBUILD_PHASE" clean cleanrm depend && \
[[ -n $EAPI ]] || EAPI=0
 fi
 
-if ___eapi_enables_globstar; then
-   shopt -s globstar
-fi
-
 # Convert quoted paths to array.
 eval "PORTAGE_ECLASS_LOCATIONS=(${PORTAGE_ECLASS_LOCATIONS})"
 
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index a6aaa7926..0a3bc5cb7 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -1210,169 +1210,3 @@ if ___eapi_has_in_iuse; then
has "${use}" "${liuse[@]#[+-]}"
}
 fi
-
-if ___eapi_has_master_repositories; then
-   master_repositories() {
-   local output repository=$1 retval
-   shift
-   [[ $# -gt 0 ]] && die "${FUNCNAME[0]}: unused argument(s): $*"
-
-   if [[ -n ${PORTAGE_IPC_DAEMON} ]]; then
-   "${PORTAGE_BIN_PATH}/ebuild-ipc" master_repositories 
"${EROOT}" "${repository}"
-   else
-   output=$("${PORTAGE_BIN_PATH}/ebuild-helpers/portageq" 
master_repositories "${EROOT}" "${repository}")
-   fi
-   retval=$?
-   [[ -n ${output} ]] && echo "${output}"
-   case "${retval}" in
-   0|1)
-   return ${retval}
-   ;;
-   2)
-   die "${FUNCNAME[0]}: invalid repository: 
${repository}"
-   ;;
-   *)
-   if [[ -n ${PORTAGE_IPC_DAEMON} ]]; then
-   die "${FUNCN

[gentoo-portage-dev] [PATCH 1/2] Remove support for EAPIs "4-python" and "5-progress"

2022-02-21 Thread Matt Turner
Signed-off-by: Matt Turner 
---
GitHub PR: https://github.com/gentoo/portage/pull/789

 bin/dohtml.py |   2 -
 bin/eapi.sh   | 116 
 bin/phase-functions.sh|   4 +-
 bin/phase-helpers.sh  |   2 +-
 doc/package/ebuild/eapi/4-python.docbook  | 160 
 doc/package/ebuild/eapi/5-progress.docbook| 247 --
 doc/portage.docbook   |   2 -
 lib/portage/__init__.py   |   2 -
 lib/portage/eapi.py   |  44 +---
 lib/portage/tests/dep/test_isvalidatom.py |   9 -
 .../tests/update/test_update_dbentry.py   |  32 +--
 repoman/cnf/repository/linechecks.yaml|   3 -
 .../modules/linechecks/patches/patches.py |   2 -
 13 files changed, 75 insertions(+), 550 deletions(-)
 delete mode 100644 doc/package/ebuild/eapi/4-python.docbook
 delete mode 100644 doc/package/ebuild/eapi/5-progress.docbook

diff --git a/bin/dohtml.py b/bin/dohtml.py
index e7cfa591e..ae0abeb64 100755
--- a/bin/dohtml.py
+++ b/bin/dohtml.py
@@ -161,8 +161,6 @@ class OptionsClass:
 self.DOCDESTTREE = normalize_path(self.DOCDESTTREE)
 
 self.allowed_exts = ["css", "gif", "htm", "html", "jpeg", "jpg", "js", 
"png"]
-if os.environ.get("EAPI", "0") in ("4-python", "5-progress"):
-self.allowed_exts += ["ico", "svg", "xhtml", "xml"]
 self.allowed_files = []
 self.disallowed_dirs = ["CVS"]
 self.recurse = False
diff --git a/bin/eapi.sh b/bin/eapi.sh
index 362cc07c0..b6d2e07f1 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -17,7 +17,7 @@ ___eapi_has_src_configure() {
 }
 
 ___eapi_default_src_test_disables_parallel_jobs() {
-   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi)$ ]]
+   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi)$ ]]
 }
 
 ___eapi_has_S_WORKDIR_fallback() {
@@ -31,19 +31,19 @@ ___eapi_has_prefix_variables() {
 }
 
 ___eapi_has_BROOT() {
-   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6)$ ]]
 }
 
 ___eapi_has_SYSROOT() {
-   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6)$ ]]
 }
 
 ___eapi_has_BDEPEND() {
-   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6)$ ]]
 }
 
 ___eapi_has_IDEPEND() {
-   [[ ! ${1-${EAPI-0}} =~ 
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress|6|7)$ ]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|5-hdepend|6|7)$ ]]
 }
 
 ___eapi_has_RDEPEND_DEPEND_fallback() {
@@ -51,15 +51,15 @@ ___eapi_has_RDEPEND_DEPEND_fallback() {
 }
 
 ___eapi_has_PORTDIR_ECLASSDIR() {
-   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ ]]
+   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6)$ ]]
 }
 
 ___eapi_has_accumulated_PROPERTIES() {
-   [[ ! ${1-${EAPI-0}} =~ 
^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6|7)$ ]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6|7)$ ]]
 }
 
 ___eapi_has_accumulated_RESTRICT() {
-   [[ ! ${1-${EAPI-0}} =~ 
^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6|7)$ ]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6|7)$ ]]
 }
 
 # HELPERS PRESENCE
@@ -73,11 +73,11 @@ ___eapi_has_dosed() {
 }
 
 ___eapi_has_einstall() {
-   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress)$ ]]
+   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5)$ ]]
 }
 
 ___eapi_has_dohtml() {
-   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ ]]
+   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6)$ ]]
 }
 
 ___eapi_has_dohtml_deprecated() {
@@ -85,7 +85,7 @@ ___eapi_has_dohtml_deprecated() {
 }
 
 ___eapi_has_dolib_libopts() {
-   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ ]]
+   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6)$ ]]
 }
 
 ___eapi_has_docompress() {
@@ -93,7 +93,7 @@ ___eapi_has_docompress() {
 }
 
 ___eapi_has_dostrip() {
-   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi|5|6)$ ]]
 }
 
 ___eapi_has_nonfatal() {
@@ -101,85 +101,85 @@ ___eapi_has_nonfatal() {
 }
 
 ___eapi_has_doheader() {
-   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi)$ ]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi)$ ]]
 }
 
 ___eapi_has_usex() {
-   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi)$ ]]
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-slot-abi)$ ]]
 }
 
 ___eapi_has_get_libdir() {
-   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python

Re: [gentoo-dev] [PATCH v2 2/3] distutils-r1.eclass: Use python_has_version in ...enable_sphinx

2022-02-10 Thread Matt Turner
On Thu, Feb 10, 2022 at 6:45 AM Michał Górny  wrote:
>
> Signed-off-by: Michał Górny 


Looks good to me. I noticed that this implementation takes only a
single -b/-d/-r as the initial argument and then a list of packages.
I'd suggested pairs of -b/-d/-r  but I think you're right not to
implement that. I doubt that it's common to need to mix -b/-d/-r.

Thanks!



Re: [gentoo-dev] [PATCH 29/30] dev-libs/libwacom: Use python_has_version for verbose output

2022-02-08 Thread Matt Turner
On Tue, Feb 8, 2022 at 3:00 PM Matt Turner  wrote:
>
> On Sun, Feb 6, 2022 at 4:57 AM Michał Górny  wrote:
> >
> > Signed-off-by: Michał Górny 
> > ---
> >  dev-libs/libwacom/libwacom-1.11.ebuild | 6 +++---
> >  dev-libs/libwacom/libwacom-1.12.ebuild | 6 +++---
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/dev-libs/libwacom/libwacom-1.11.ebuild 
> > b/dev-libs/libwacom/libwacom-1.11.ebuild
> > index acfda32d8405..3e406d573b91 100644
> > --- a/dev-libs/libwacom/libwacom-1.11.ebuild
> > +++ b/dev-libs/libwacom/libwacom-1.11.ebuild
> > @@ -35,9 +35,9 @@ BDEPEND="
> >  "
> >
> >  python_check_deps() {
> > -   has_version -b "dev-python/python-libevdev[${PYTHON_USEDEP}]" &&
> > -   has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> > -   has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
> > +   python_has_version -b 
> > "dev-python/python-libevdev[${PYTHON_USEDEP}]" &&
> > +   python_has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> > +   python_has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
> >  }
> >
> >  pkg_setup() {
> > diff --git a/dev-libs/libwacom/libwacom-1.12.ebuild 
> > b/dev-libs/libwacom/libwacom-1.12.ebuild
> > index acfda32d8405..3e406d573b91 100644
> > --- a/dev-libs/libwacom/libwacom-1.12.ebuild
> > +++ b/dev-libs/libwacom/libwacom-1.12.ebuild
> > @@ -35,9 +35,9 @@ BDEPEND="
> >  "
> >
> >  python_check_deps() {
> > -   has_version -b "dev-python/python-libevdev[${PYTHON_USEDEP}]" &&
> > -   has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> > -   has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
> > +   python_has_version -b 
> > "dev-python/python-libevdev[${PYTHON_USEDEP}]" &&
> > +   python_has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> > +   python_has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
> >  }
> >
>
> I like this, but just a question -- is this patch just an example of
> how we can transition other ebuilds, or are you planning a
> larger-scale replacement?
>
> Also, I've always felt a little uncomfortable with the
> python_check_deps() functions because of how easy it is to mess them
> up. E.g., app-emulation/spice/spice-0.15.0.ebuild contains:
>
> python_check_deps() {
> has_version -b ">=dev-python/pyparsing-1.5.6-r2[${PYTHON_USEDEP}]"
> has_version -b "dev-python/six[${PYTHON_USEDEP}]"
> }
>
> It should have a &&, right? There are many more instances of this in ::gentoo.

Hm, maybe it's less common than I thought. The only other instance I
could find in a quick scan was
dev-python/dbus-python/dbus-python-1.2.18.ebuild.



Re: [gentoo-dev] [PATCH 29/30] dev-libs/libwacom: Use python_has_version for verbose output

2022-02-08 Thread Matt Turner
On Sun, Feb 6, 2022 at 4:57 AM Michał Górny  wrote:
>
> Signed-off-by: Michał Górny 
> ---
>  dev-libs/libwacom/libwacom-1.11.ebuild | 6 +++---
>  dev-libs/libwacom/libwacom-1.12.ebuild | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/dev-libs/libwacom/libwacom-1.11.ebuild 
> b/dev-libs/libwacom/libwacom-1.11.ebuild
> index acfda32d8405..3e406d573b91 100644
> --- a/dev-libs/libwacom/libwacom-1.11.ebuild
> +++ b/dev-libs/libwacom/libwacom-1.11.ebuild
> @@ -35,9 +35,9 @@ BDEPEND="
>  "
>
>  python_check_deps() {
> -   has_version -b "dev-python/python-libevdev[${PYTHON_USEDEP}]" &&
> -   has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> -   has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
> +   python_has_version -b "dev-python/python-libevdev[${PYTHON_USEDEP}]" 
> &&
> +   python_has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> +   python_has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
>  }
>
>  pkg_setup() {
> diff --git a/dev-libs/libwacom/libwacom-1.12.ebuild 
> b/dev-libs/libwacom/libwacom-1.12.ebuild
> index acfda32d8405..3e406d573b91 100644
> --- a/dev-libs/libwacom/libwacom-1.12.ebuild
> +++ b/dev-libs/libwacom/libwacom-1.12.ebuild
> @@ -35,9 +35,9 @@ BDEPEND="
>  "
>
>  python_check_deps() {
> -   has_version -b "dev-python/python-libevdev[${PYTHON_USEDEP}]" &&
> -   has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> -   has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
> +   python_has_version -b "dev-python/python-libevdev[${PYTHON_USEDEP}]" 
> &&
> +   python_has_version -b "dev-python/pyudev[${PYTHON_USEDEP}]" &&
> +   python_has_version -b "dev-python/pytest[${PYTHON_USEDEP}]"
>  }
>

I like this, but just a question -- is this patch just an example of
how we can transition other ebuilds, or are you planning a
larger-scale replacement?

Also, I've always felt a little uncomfortable with the
python_check_deps() functions because of how easy it is to mess them
up. E.g., app-emulation/spice/spice-0.15.0.ebuild contains:

python_check_deps() {
has_version -b ">=dev-python/pyparsing-1.5.6-r2[${PYTHON_USEDEP}]"
has_version -b "dev-python/six[${PYTHON_USEDEP}]"
}

It should have a &&, right? There are many more instances of this in ::gentoo.

I wonder if this wouldn't be a good opportunity to change the API a
little. Could we make python_has_version take multiple arguments and
return true iff all are satisfied? Maybe like this?

python_check_deps() {
has_version \
-b ">=dev-python/pyparsing-1.5.6-r2[${PYTHON_USEDEP}]" \
-b "dev-python/six[${PYTHON_USEDEP}]"
}

What do you think?



[gentoo-dev] net-proxy/redsocks up for grabs

2022-01-30 Thread Matt Turner
I don't have any need for redsocks anymore. It's basically zero
maintenance, so if you use it, please feel free to replace me as the
maintainer in metadata.xml.

acct-group/redsocks
acct-user/redsocks
net-proxy/redsocks

Thanks,
Matt



Re: [gentoo-dev] [PATCH] profiles/targets/desktop: disable USE=xvid by default

2022-01-12 Thread Matt Turner
On Tue, Jan 11, 2022 at 9:45 PM Georgy Yakovlev  wrote:
>
> it's an ancient codec that is barely used nowadays
> so let's disable it by default.
> Users are free to re-enable if required.
>
> Bug: https://bugs.gentoo.org/831044

Heh, looks like you want to leave it disabled by default because it
fails to compile on arm? :)

I don't have a preference. I would note that a few packages depend on
it being enabled in ffmpeg:

media-gfx/blender
media-libs/libopenshot
media-plugins/mythplugins



Re: [gentoo-dev] USE-flag gnome-keyring isn't accurate anymore

2021-12-23 Thread Matt Turner
On Thu, Dec 23, 2021 at 4:36 PM tastytea  wrote:
> I think “secret” may be too generic and “libsecret” is not ideal in case
> an implemention comes along that is named differently. How about
> “secret-service”?

I think this is a good idea.



Re: [gentoo-dev] Experimental binary package hosting

2021-09-23 Thread Matt Turner
On Thu, Sep 23, 2021 at 7:12 AM Andreas K. Huettel  wrote:
>
> Hi Vadim,
>
> > Finally it happened!
> > I already planned to try to ask infra/council about sponsoring few
> > servers for build farm for "official gentoo binhosts" when I had
> > enough time, but fortunately, you've already did that.
> > It's very good news.
>
> Thanks! Nice to see that this is appreciated :)
>
> So far I'm only using "spare time" on the machine that builds the
> releng stages (amd64, x86, m68k, riscv). So no need for a big server
> farm.
>
> > Btw, do you need any help with that?
> > I'd be very happy to help with that project.
>
> Sure! Feel free to add yourself to the Project:Binhost wiki page. I'll
> ask for an alias and a channel soon.
>
> The most useful steps now are only half related to actual building. I
> barely know any python and am not very familiar with portage
> internals... this is what in my opinion we'd need next:
>
> 1) a tool to manage and manipulate a binpkg/ directory tree
> The main functions that I see needed are
> * delete packages/versions that are not in the gentoo repository
> anymore (xpak and in index file), maybe with some grace time
> * merge xpak files built elsewhere into the directory (also in the
> index file)

eclean packages from gentoolkit does this exactly.



[gentoo-dev] Re: [PATCH 1/5] profiles/default/linux: remove busybox from @system

2021-09-09 Thread Matt Turner
I support this.



[gentoo-dev] Re: [PATCH 1/3] meson.eclass: introduce meson_install helper function

2021-08-27 Thread Matt Turner
Thanks, all three patches LGTM.



Re: [gentoo-dev] Stabilization Detached from Security Bugs

2021-08-26 Thread Matt Turner
\o/



Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs

2021-08-12 Thread Matt Turner
On Thu, Aug 12, 2021 at 5:53 AM Michał Górny  wrote:
>
> Hello, everyone.
>
> TL;DR: I'd like to propose that stabilizations are done via blockers of
> security bugs instead of security bugs themselves, i.e. as any other
> stabilizations.
>
>
> Right now we're often performing security-related stabilizations via
> security bugs. This has a few problems, that are:
>
> 1. Stabilization-related activity causes unnecessary mail to the widely
> subscribed security alias. That is, subscribed people get notified of
> package list changes, NATTkA results, every arch doing its work.
> However, in reality the security team only cares about stabilization
> being started, stalled or finished -- and for that, getting the usual
> 'dependent bug added/closed' mail should be sufficient.
>
> 2. NATTkA has no good way of distinguishing irrelevant security bugs
> from security bugs where something went wrong (and NATTkA doesn't use
> persistent state by design). The most important problem is that --
> unlike regular stablereqs -- security bugs aren't supposed to be closed
> after stabilization. It can't really distinguish a security bug 'left
> open' from a security bug with incorrect package list.
>
> 3. Proxied maintainers without editbugs can't actually CC arches on
> security bugs since the bugs are assigned to security@.
>
>
> To resolve these problems going forward and establish consistent
> behavior in the future, I'd like to propose to disable 'package list'
> fields on security bugs and instead expect regular stabilization bugs to
> be used (and made block the security bugs) for stabilizations. While I
> understand that filing additional bugs might be cumbersome for some
> people, I don't think it's such a herculean effort to outweigh
> the problems solved.
>
> In the end, consistency is a good thing and we've introduced a dedicated
> stabilization category to reduce the spread of stabilization bugs all
> around the place.

I love this.

It sounds (from IRC) like you're on board with the idea of having
nattka add kw:security to appropriate stabilization bugs.

Could nattka also do something to the security@-assigned but itself to
indicate that all security-supported architecture have been handled?
Something like leaving a comment or fiddling with the security
whiteboard.

It would be nice to be able to resolve the security@-assigned but
before non-security-supported architectures are handled.

To do that, I think we'd want to change what's required for the "clean
up" step. Since today the "clean up" step is dropping the vulnerable
package versions from the tree, it is dependent on
non-security-supported architectures completing the stabilization bug.
I think we'd like to break that dependence.

I suggest that we redefine the "clean up" step to be: drop
security-supported architectures' keywords from vulnerable versions.
That would allow the security@-assigned bug to be resolved before
non-security-supported architectures are finished with stabilization.



[gentoo-dev] Packages up for co-maintenance

2021-08-10 Thread Matt Turner
The GNOME team maintains these mobile broadband packages, but I don't
think anyone has hardware that uses them.

net-misc/modemmanager
net-libs/libqmi
net-libs/libmbim

If you use them, feel free to add yourself as the primary maintainer
and maintain them. They have regular releases and the version bump
work is simple.

My purpose here is to attempt to lighten my load of GNOME-related
bumps. Please don't add yourself as a maintainer if it means
additional work for me.



Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check

2021-08-06 Thread Matt Turner
On Wed, Aug 4, 2021 at 5:35 AM Thomas Deutschmann  wrote:
>
> On 2021-08-04 04:56, Sam James wrote:
> > Sure, thanks for the clarification. It's deprecated in the sense of
> > ebuilds installing to it though, right?
>
> Well, it triggered me because saying it's deprecated implies two things
> for me:
>
> 1) It was OK for packages to do that in the past
>
> 2) Something has changed upstream
>
> Regarding 1)
> It was never OK for packages to install in that location. That will
> break the override mechanism systemd introduced. I.e. packages were and
> are still only allowed to install below /usr (/lib), to allow local
> system administrators to override installed unit/tmpfiles spec by
> placing a file with the same name in the corresponding directory in /etc.
>
>
> Regarding 2)
> Nothing has changed upstream regarding these locations.

Maybe next time, just explain that the first time around?

Your first email provides no actionable information and requires the
other party to expend effort (and wait for a reply) to understand what
you mean.



Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-08 Thread Matt Turner
On Thu, Jul 8, 2021 at 2:34 PM MSavoritias
 wrote:
> On July 8, 2021 8:50:39 PM UTC, Matt Turner  wrote:
> >On Thu, Jul 8, 2021 at 1:41 PM Peter Stuge  wrote:
> >>
> >> Matt Turner wrote:
> >> > If you can find a case where you wouldn't want to enable one of
> >these
> >> > USE flags, please let me know and I'll reconsider my position.
> >>
> >> My catalyst spec files all have  use: -* foo bar x y z
> >> specifically because the defaults are never what I want for any given
> >> system. I build desktops, servers, containers, VM appliance images
> >and
> >> embedded system, and I know what I want in each one. Especially the
> >> latter frequently have only very few USE flags set and I want zero
> >> extra dependencies.
> >
> >I think you're making a great argument that you'd be completely
> >unaffected by any of the suggestions in this thread.
> >
> >> I completely agree that the default USEs should rather be reduced,
> >> not increased. Isn't this what profile inheritance is for? It would
> >> be great if I didn't essentially have to create my own profile when I
> >> want a very minimal system.
> >>
> >>
> >> Matt Turner wrote:
> >> > I'd claim most of these packages' bzip2/lzma/zstd USE flags should
> >> > be removed in favor of statically enabling them
> >>
> >> That is the direct opposite of Gentoo's single most core value:
> >choice
> >
> >Choice makes sense when there's a legitimate trade-off to be made.
> >Choice isn't dogma.
>
> Well the legitimate trade-off is complexity as stated previously. Gentoo is 
> not supposed to be batteries included. It is supposed to be building blocks 
> for each persons own thing.
>
> Instead of adding the use flag what would ne more in Gentoo spirit would be 
> to add to handbook a guide for common use flags.
>
> Plus just because people disagree here with the proposal doesnt mean its 
> dogma. It may be just disagreement.

That's not my claim.

It's akin to defending what you said by saying "Well, we have free
speech so I can say whatever I want!". Of course you can, but that's
not the point. You're not defending the substance of the speech. It's
a lazy argument.

Similarly, people say "Well, Gentoo is about choice!" even when the
choice is absolutely meaningless. Of course Gentoo offers a lot of
choice, but that's not the point. You're not defending the value of
the choice. It's a lazy argument.

It's easy for people who don't respond to bug reports to discount the
overhead every configuration knob adds.



  1   2   3   4   5   6   7   >