[gentoo-dev] Last-rites: dev-php/PEAR-Config

2021-03-08 Thread Brian Evans

# Brian Evans  (2021-03-08)
# No longer consistently maintained, severely broken with PHP 8
# No reverse dependencies, fails tests
# Removal in 30 days.
dev-php/PEAR-Config



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-02 Thread Brian Evans

On 3/2/2021 2:36 PM, Alessandro Barbieri wrote:
Il Mar 2 Mar 2021, 20:03 Matt Turner > ha scritto:


On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky mailto:m...@gentoo.org>> wrote:
 >                                 why don't we just enforce putting
each
 > keyword on a separate line instead, so that we don't have this
problem
 > in the first place?

Why don't we change 30 thousand ebuilds rather than use this script?


IMO before this the keyword mechanism should be reworked to be three-state:
1 Arch known working
2 Arch known not working
3 Arch untested/status unknown

And let the user choose to use packages from 3 or not

This is how it already is.  1 and 3 are common but 2 is uncommon except 
for binary only packages.


Brian



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread Brian Evans

On 2/8/2021 12:53 PM, Brian Evans wrote:

On 2/8/2021 6:19 AM, Michał Górny wrote:

Hi,

FYI the developers of dev-python/cryptography decided that Rust is going
to be mandatory for 1.5+ versions.  It's unlikely that they're going to
provide LTS support or security fixes for the old versions.

Since cryptography is a very important package in the Python ecosystem,
and it is an indirect dependency of Portage, this means that we will
probably have to entirely drop support for architectures that are not
supported by Rust.



For the portage indirect dependency, can it be swapped for pycurl?

AFAICT, it is just used to pull GPG sigs in gemato via dev-python/requests.

This at least would at least keep the arches in question with some 
support but not necessarily all of python world until a clearer plan can 
be made.


Brian



After discussion in #gentoo-dev and simple chroot testing, it seems like 
dev-python/requests nor dev-python/urlllib3 needs 
dev-python/cryptography at all (when run with stable Python, tested with 
3.8).   So unless there's a really good reason outside of gemato sync, 
this looks to be a non-issue for portage and more of a dependency fix.


Brian



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread Brian Evans

On 2/8/2021 6:19 AM, Michał Górny wrote:

Hi,

FYI the developers of dev-python/cryptography decided that Rust is going
to be mandatory for 1.5+ versions.  It's unlikely that they're going to
provide LTS support or security fixes for the old versions.

Since cryptography is a very important package in the Python ecosystem,
and it is an indirect dependency of Portage, this means that we will
probably have to entirely drop support for architectures that are not
supported by Rust.



For the portage indirect dependency, can it be swapped for pycurl?

AFAICT, it is just used to pull GPG sigs in gemato via dev-python/requests.

This at least would at least keep the arches in question with some 
support but not necessarily all of python world until a clearer plan can 
be made.


Brian



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: net-analyzer/jffnms

2021-01-25 Thread Brian Evans

# Brian Evans  (2021-01-25)
# Dead upstream. Relies on soon to be removed wddx support in PHP.
# wddx in general failed overall as a protocol. No real maintainer.
# Removal in 30 days. Bug #688066
net-analyzer/jffnms



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] profiles: Reorder AMD64 profile list to place 17.1 on top

2020-10-22 Thread Brian Evans
Users frequently are choosing the wrong profile versions in new installs
and accidentally downgrading to 17.0 with some saying they see it first.

A simple reordering could help new installs.

Since we do not guarantee ordering, any automated tooling concerns should not
be an issue because the full profile name can always be used.

Signed-off-by: Brian Evans 
---
 profiles/profiles.desc | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index b45e918984a..aa1770a7840 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -14,24 +14,6 @@ alphadefault/linux/alpha/17.0/desktop/gnome  
stable
 alpha  default/linux/alpha/17.0/desktop/gnome/systemd  stable
 alpha  default/linux/alpha/17.0/developer  stable
 
-# AMD64 Profiles
-# @MAINTAINER: am...@gentoo.org
-amd64  default/linux/amd64/17.0stable
-amd64  default/linux/amd64/17.0/selinuxstable
-amd64  default/linux/amd64/17.0/hardened   stable
-amd64  default/linux/amd64/17.0/hardened/selinux   stable
-amd64  default/linux/amd64/17.0/desktopstable
-amd64  default/linux/amd64/17.0/desktop/gnome  stable
-amd64  default/linux/amd64/17.0/desktop/gnome/systemd  stable
-amd64  default/linux/amd64/17.0/desktop/plasma stable
-amd64  default/linux/amd64/17.0/desktop/plasma/systemd stable
-amd64  default/linux/amd64/17.0/developer  stable
-amd64  default/linux/amd64/17.0/no-multilibstable
-amd64  default/linux/amd64/17.0/no-multilib/hardened   stable
-amd64  default/linux/amd64/17.0/no-multilib/hardened/selinux   stable
-amd64  default/linux/amd64/17.0/systemdstable
-amd64  default/linux/amd64/17.0/x32dev
-
 # SYMLINK_LIB=no profiles
 # Run app-portage/unsymlink-lib *before* switching the profile.
 # @MAINTAINER: mgo...@gentoo.org
@@ -50,6 +32,24 @@ amd64
default/linux/amd64/17.1/no-multilib/hardened   stable
 amd64  default/linux/amd64/17.1/no-multilib/hardened/selinux   stable
 amd64  default/linux/amd64/17.1/systemdstable
 
+# AMD64 Profiles
+# @MAINTAINER: am...@gentoo.org
+amd64  default/linux/amd64/17.0stable
+amd64  default/linux/amd64/17.0/selinuxstable
+amd64  default/linux/amd64/17.0/hardened   stable
+amd64  default/linux/amd64/17.0/hardened/selinux   stable
+amd64  default/linux/amd64/17.0/desktopstable
+amd64  default/linux/amd64/17.0/desktop/gnome  stable
+amd64  default/linux/amd64/17.0/desktop/gnome/systemd  stable
+amd64  default/linux/amd64/17.0/desktop/plasma stable
+amd64  default/linux/amd64/17.0/desktop/plasma/systemd stable
+amd64  default/linux/amd64/17.0/developer  stable
+amd64  default/linux/amd64/17.0/no-multilibstable
+amd64  default/linux/amd64/17.0/no-multilib/hardened   stable
+amd64  default/linux/amd64/17.0/no-multilib/hardened/selinux   stable
+amd64  default/linux/amd64/17.0/systemdstable
+amd64  default/linux/amd64/17.0/x32dev
+
 # ARM Profiles
 # @MAINTAINER: a...@gentoo.org
 armdefault/linux/arm/17.0  stable
-- 
2.29.0




Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua

2020-10-06 Thread Brian Evans

On 10/6/2020 8:45 AM, Azamat Hackimov wrote:

вт, 6 окт. 2020 г. в 15:04, Marek Szuba :


On 2020-10-05 23:17, Azamat Hackimov wrote:


Is there a slotmove that can be applied?


I am afraid I do not understand the question. What do you want to move,
and why?


Currently portage is mostly lua:5.1 aware and the first thing is move
dev-lang/lua:0 to 5.1 slot by slotmove in profiles/updates:

slotmove dev-lang/lua 0 5.1


The file structure of dev-lang/lua:0 differs from dev-lang/lua:5.x,
meaning that introducing such a slot move would require Lua eclasses to
treat lua5-1 differently from other targets. In other words, we would
*still* need lua0 support but without a clearly distinct name.


So there will be a new stabilized lua:5.1 version as I proposed.
Again, here is a quick todo list:

1. slotmove dev-lang/lua
2. Change all dependencies to change from lua:0 to lua:5.1
3. Stabilize & unmask slotted version 5.1.5-r103
4. Release news & rebuild with emerge -a --oneshot $(equery depends
dev-lang/lua | awk '{print " ="$1}')


Please don't use 'equery depends' for such things.  It shows what *can* 
depend and not what *actually* depends on a given system because of 
metadata shortcuts. (It won't consider USE for example.)


If a library name is moving, the best tool is revdep-rebuild with the 
--library option with the old soname to look for.


Brian


OpenPGP_0x4E15E2F167C78E1D.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] systems-246 changes tmpfs default size from 50% to 10% of RAM

2020-07-28 Thread Brian Evans
On 7/28/20 2:50 PM, Zoltan Puskas wrote:
> Hi,
> 
> I've upgraded to and running systemd-246_rc2 on one of my systems and
> noticed that tmpfs mounted directories are significantly smaller.
> 
> This is because with commit
> https://github.com/systemd/systemd/commit/7d85383edbab73274dc81cc888d884bb01070bc2
> they have changed them to be 10% of the physical memory instead of the
> default of 50%.
> 
> This is a potentially breaking, or at least an unexpected behaviour
> change, especially for people using tmpfs on /tmp for compiling.

This could also affect any Gentoo admin running a MySQL/MariaDB database
with the default settings as it will sometimes write temporary tables to
${EPREFIX}/tmp.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs app-text/groonga{,-normalizer-mysql}

2020-06-11 Thread Brian Evans
I have no further interest in the following packages which are now
maintainer-needed:

app-text/groonga
app-text/groonga-normalizer-mysql


Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last standing Python 2.7 dependency

2020-05-03 Thread Brian Evans
On 5/3/20 2:58 AM, Fabian Groffen wrote:
> On 02-05-2020 23:24:42 -0700, Brian Dolbec wrote:
>> On Sun, 3 May 2020 07:28:50 +0200
>> Viktar Patotski  wrote:
>>
>>> Hi all,
>>>
>>> I'd also like to clean my system and have it Python 2.7 free. Are
>>> there any guidelines to check which packages are still using pyton2_7
>>> in my system?
>>>
>>> Thanks,
>>> Viktar
>>>
>>
>> There are both equery and enalyze commands in gentoolkit that can give
>> you reports about what pkgs are installed.
>>
>> equery hasuse
>> enalyze analyze [use|pkguse]
>>
>> for help on them:
>> equery -h
>> equery hasuse -h
>> enalyze -h
>> enalyze a -h
> 
> In addition to these great tools, portage-utils' quse might also be
> useful:
> 
> % quse python2_7
> ...
> 
> 
> Thanks,
> Fabian
> 

All of the mentioned tools will show if packages have the flag but not
necessarily have it active.

eix has an option to search the active flag:

eix --installed-with-use 

However, this still skips build-time dependencies that may keep python
2.7 around.

The most accurate way to see what's tied to python 2.7 is to pretend to
remove it:
emerge -pvc dev-lang/python:2.7

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

2020-04-11 Thread Brian Evans
On 4/11/20 9:37 AM, Marek Szuba wrote:
> Does this look okay to you, guys? The date is preliminary and dependent
> on how quickly we can get nvidia-drivers migrated to the new approach,
> hopefully we can get this to happen sooner.
> 
> * * *
> 
> Title: Manual steps required during upgrade to an eselect-free OpenCL set-up
> Author: Marek Szuba 
> Posted: 2020-05-01
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: app-eselect/eselect-opencl
> 
> We are now in the process of migrating OpenCL in Gentoo to having all
> implementations operate through an ICD loader (dev-libs/ocl-icd or
> dev-libs/opencl-icd-loader) installed directly into /usr instead of
> using eselect-opencl to switch between implementations. eselect-free
> versions
> of loader packages have just been released to the public.
> 
> Unfortunately although the upgrade to those versions will automatically
> uninstall app-eselect/eselect-opencl, it will not remove the symbolic
> links to
> libOpenCL.so created by this tool in library directories because those links
> are not owned by the package in question. If your system is configured for
> full collision protection (FEATURES=collision-protect), it will be necessary
> to manually remove those links
> 
> rm -i /usr/lib{,64}/libOpenCL.so*
> 
> before running the upgrade.
> 
> Systems whose collision protection either allows overwriting orphaned files
> (FEATURES='-collision-protect protect-owned') or which do not use collision
> protection at all (not recommended) should be unaffected.
> 
> 
> 

I would mention that FEATURES='-collision-protect protect-owned' is the
default so most people won't have any action to take at all.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: PHP 7.1 and required packages

2019-12-19 Thread Brian Evans
# Brian Evans  (2019-12-19)
# PHP 7.1 is end of life and has security issues Bug 703326
# Associated packages are not ready for new versions tracked in bug 702110
# Removal in 30 days
dev-lang/php:7.1
dev-php/pecl-cassandra


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] packages up for grabs

2019-11-19 Thread Brian Evans
On 11/18/2019 7:47 PM, Tim Harder wrote:
> The following list of packages are up for grabs that I dropped myself as
> as a direct maintainer from. There are probably a significantly larger
> number that I've indirectly maintained hiding under the guise of older
> projects that mostly act likes herds (e.g. graphics, sound, and vim to
> name a few) so interested parties should feel free to directly add
> themselves as maintainers for such packages.
> 
> Note that some of the packages in this list already have maintainers,
> but I'm sure most of them wouldn't mind co-maintainers.
> 
> sys-apps/ack

I will take this as I use ack frequently.

Brian



Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

2019-11-18 Thread Brian Evans
On 11/16/2019 3:14 PM, Matt Turner wrote:
> On Sat, Nov 16, 2019 at 9:08 AM Michael 'veremitz' Everitt
>  wrote:
>>
>> On 16/11/19 16:59, Matt Turner wrote:
>>> On Sat, Nov 16, 2019 at 1:06 AM Jaco Kroon  wrote:
 Hi,

 On 2019/11/15 21:35, Matt Turner wrote:
> On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller  wrote:
>> The package is somewhat redundant, because sys-kernel/linux-firmware
>> installs the same files. (Same for all other sys-firmware/iwl*-ucode
>> packages.)
> Should last-rite all of them, IMO.
>
 I both agree and disagree with this.  It's the simpler solution and
 therefore I agree.

 I disagree because in some cases I really only want specific firmware
 for specific sets of hardware (especially where space constraints are an
 issue, read: embedded type systems).

 The current linux-firmware package is getting quite big in terms of 
 install.
>>> USE=savedconfig allows you to choose exactly which files to install :)
>>>
>> I've never found a good way (yet...) to figure out how to write a fresh new
>> 'savedconfig' if you haven't ever previously emerged the package in
>> question. Does anyone have a good method for this, that doesn't require
>> unpacking the whole nine yards (Megs, Gigs...) first?
> 
> You could look at the upstream git repo and make a list based on that.
> 
> Or, since you have to download the tarball anyway, ebuild ... unpack
> it and inspect.
> 
> Or, use the live ebuild to avoid downloading the same data multiple
> times per tarball.
> 
> Or, if you want maximal bandwidth savings don't bother with any of
> this and install the files you want manually since the files aren't
> going to change.
> 
This last point is not true wrt iwlwifi.  Its filename(s) change with
every other kernel release.  They accept new versions and ban old ones
within the driver.

Brian



Re: [gentoo-dev] [RFC] News Item: Desktop profile switching USE default to elogind

2019-10-28 Thread Brian Evans
On 10/27/2019 10:19 PM, Andreas Sturmlechner wrote:
> Rebuild all affected consumers and remove sys-auth/consolekit:
> 
> # emerge --ask --changed-use --deep world
> # emerge --unmerge consolekit
> 

Can we please avoid using --unmerge when it is not necessary?  This
should be 'emerge --depclean consolekit' (or optionally use -c) instead
to ensure nothing is broken.  It is just a good practice to teach users
how to remove things properly.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-php/PEAR-MDB2/

2019-10-07 Thread Brian Evans
On 10/7/2019 4:03 PM, Michał Górny wrote:
> On Mon, 2019-09-30 at 20:39 +0000, Brian Evans wrote:
>> commit: 36fc30fda1d8d8c3ac725c18cc74bc39bf2d98c2
>> Author: Brian Evans  gentoo  org>
>> AuthorDate: Mon Sep 30 19:01:12 2019 +0000
>> Commit: Brian Evans  gentoo  org>
>> CommitDate: Mon Sep 30 20:38:59 2019 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36fc30fd
>>
>> dev-php/PEAR-MDB2: Mark stable on all arches
>>
>> No code changes.  Pure dependency change
>>
>> Package-Manager: Portage-2.3.76, Repoman-2.3.17
>> RepoMan-Options: --force
> 
> Why did you use '--force' here?  This doesn't seem the kind of change
> that would require using it.

Because of other changes in the same series which caused it to fail and
this was step 1 of the fix.

Cleaning the old rev removed the need for force.

Brian




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: PHP extensions which no longer work with supported versions

2019-10-01 Thread Brian Evans
# Brian Evans  (2019-10-01)
# Old extensions which only work with PHP <7
# pecl-memcache is replaced by pecl-memcached (with code changes)
# pecl-mongo is replaced by pecl-monogodb
# Removal in 90 days. Bug 651784
dev-php/PEAR-MDB2_Driver_mysql
dev-php/magickwand
dev-php/pecl-bbcode
dev-php/pecl-cairo
dev-php/pecl-dbx
dev-php/haru
dev-php/pecl-htscanner
dev-php/pecl-libevent
dev-php/pecl-memcache
dev-php/pecl-mongo
dev-php/pecl-mysqlnd_ms
dev-php/pecl-mysqlnd_qc
dev-php/pecl-sphinx
dev-php/pecl-spl_types
dev-php/pecl-svn
dev-php/pecl-xrange
dev-php/suhosin
dev-php/xcache
dev-php/xhprof



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] sys-libs/db: Remove --default-symver usage.

2019-09-27 Thread Brian Evans
On 9/27/2019 3:31 PM, Manoj Gupta wrote:
> sys-libs/db-18.1.32 can builds without "--default-symver"
> linker flag. This fixes the build issue when using LLD linker
> which does not support this flag.
> 
> Given that sys-libs/db is the only Gentoo package using
> "--default-symver" linker, it is probably not a terrible idea to
> drop use of "--default-symver" flag.
> 

But won't this change how *other* packages can be confused with multiple
slots of sys-libs/db installed at the same time?

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] eclass update for php-ext-source-r3

2019-09-17 Thread Brian Evans
This diff is required to get proper support for PHP 7.4 and newer.

Upstream has discontinued acinclude.m4 and this has been breaking our
call to eautoreconf.  Instead, we are now simulating their ./buildconf
script with our own toolchain functions to ensure cross-build compatibility.

diff --git a/eclass/php-ext-source-r3.eclass
b/eclass/php-ext-source-r3.eclass
index 5ef879a2be2..385bdb9dae0 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -15,7 +15,8 @@ inherit autotools
 EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test

 case ${EAPI:-0} in
-   6|7) ;;
+   6) inherit eapi7-ver ;;
+   7) ;;
*)
die "${ECLASS} is not compatible with EAPI=${EAPI}"
 esac
@@ -183,10 +184,18 @@ php-ext-source-r3_phpize() {
# WANT_AUTOMAKE (see bugs #329071 and #549268).
autotools_run_tool "${PHPIZE}"

-   # Force libtoolize to run and regenerate autotools files (bug
-   # #220519).
-   rm aclocal.m4 || die "failed to remove aclocal.m4"
-   eautoreconf
+   # PHP >=7.4 no longer works with eautoreconf
+   if ver_test $PHP_CURRENTSLOT -ge 7.4 ; then
+   rm -fr aclocal.m4 autom4te.cache config.cache \
+   configure main/php_config.h.in || die
+   eautoconf --force
+   eautoheader
+   else
+   # Force libtoolize to run and regenerate autotools 
files (bug
+   # #220519).
+   rm aclocal.m4 || die "failed to remove aclocal.m4"
+   eautoreconf
+   fi
fi
 }




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] News Item: Deprecation and removal of PHP 5.6

2019-08-27 Thread Brian Evans
Title: Deprecation and removal of PHP 5.6
Author: Brian Evans 
Posted: 2019-08-27
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: dev-lang/php:5.6
Display-If-Installed: dev-php/haru
Display-If-Installed: dev-php/magickwand
Display-If-Installed: dev-php/pecl-bbcode
Display-If-Installed: dev-php/pecl-cairo
Display-If-Installed: dev-php/pecl-dbx
Display-If-Installed: dev-php/pecl-htscanner
Display-If-Installed: dev-php/pecl-libevent
Display-If-Installed: dev-php/pecl-memcache
Display-If-Installed: dev-php/pecl-mongo
Display-If-Installed: dev-php/pecl-mysqlnd_ms
Display-If-Installed: dev-php/pecl-mysqlnd_qc
Display-If-Installed: dev-php/pecl-sphinx
Display-If-Installed: dev-php/pecl-spl_types
Display-If-Installed: dev-php/pecl-svn
Display-If-Installed: dev-php/pecl-xrange
Display-If-Installed: dev-php/suhosin
Display-If-Installed: dev-php/xcache
Display-If-Installed: dev-php/xhprof
Display-If-Installed: dev-php/pecl-apcu:0
Display-If-Installed: dev-php/pecl-dbase:0
Display-If-Installed: dev-php/pecl-http:2
Display-If-Installed: dev-php/pecl-mailparse:0
Display-If-Installed: dev-php/pecl-memcached:0
Display-If-Installed: dev-php/pecl-oauth:0
Display-If-Installed: dev-php/pecl-propro:0
Display-If-Installed: dev-php/pecl-ps:0
Display-If-Installed: dev-php/pecl-raphf:0
Display-If-Installed: dev-php/pecl-rrd:0
Display-If-Installed: dev-php/pecl-ssh2:0
Display-If-Installed: dev-php/pecl-stomp:0
Display-If-Installed: dev-php/pecl-xdiff:0
Display-If-Installed: dev-php/pecl-yaml:0
Display-If-Installed: dev-php/twig[extension]
Display-If-Installed: dev-php/PEAR-MDB2_Driver_mysql
Display-If-Installed: media-gfx/exact-image[php]
Display-If-Installed: sci-geosciences/mapserver[php,php_targets_php5-6]
Display-If-Installed: www-apps/postfixadmin
Display-If-Installed: www-apps/rutorrent:3.4-r1
Display-If-Installed: www-server/nginx-unit[php56]

The Gentoo PHP Team is announcing the deprecation and future removal of
PHP 5.6. As of October 1, 2019, PHP 5.6 will be masked for removal.
Since some may consider this a critical package, we have decided on a
longer than normal 90 day removal period.

Other distributions will or already have moved to PHP 7.2 by the end of
the year.  Currently, we are using a backport repository to keep
security updates in line with the main releases.  However, we feel this
is the right time to remove this branch as maintenance burden will
likely only increase.

To that end, the long list of PHP 5 only extensions must accompany its
removal. Many of which are long ignored by their upstream maintainers
and have no replacements.  Some packages listed here have PHP 5 only
slots which are included as reminders to upgrade.

Some packages do have replacements:
dev-php/pecl-memcache can be replaced by dev-php/pecl-memcached with
  some small code modifications
dev-php/pecl-mongo has been superceded by dev-php/mongodb
dev-php/pecl-libevent should be replaced by dev-php/pecl-event
  with code changes
dev-php/PEAR-MDB2_Driver_mysql should be easily replaced by
  dev-php/PEAR-MDB2_Driver_mysqli with minor configuration changes



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: virtual/libmysqlclient

2019-08-26 Thread Brian Evans
# Brian Evans  (2019-08-26)
# Deprecated virtual as it cannot solve the issue of ABI incompatibility
# and rebuild consumers when provider changes
# No revdeps. Removal in 30 days.
virtual/libmysqlclient



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: www-apps/{groupoffice,phpwebsite,sitebar}

2019-08-23 Thread Brian Evans
# Brian Evans  (2019-08-23)
# These packages are incompatible with current versions of PHP (7 or higher)
# They need a maintainer but no one has volunteered.
# Removal in 30 days if no one picks them up.
# Bugs 615472 651166 and 651180 respectively
www-apps/groupoffice
www-apps/phpwebsite
www-apps/sitebar



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering

2019-08-07 Thread Brian Evans
On 8/7/19 11:20 AM, Mikle Kolyada wrote:
> Signed-off-by: Mikle Kolyada 
> ---
> As discussed with mgorny at #gentoo-qa
>  glep-0081.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/glep-0081.rst b/glep-0081.rst
> index 082e705..e5a4db2 100644
> --- a/glep-0081.rst
> +++ b/glep-0081.rst
> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used.  If 
> the user is
>  needed at install and/or run time, a run time dependency (``RDEPEND``)
>  must be used.
>  
> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS``
> +variable predefined, keywords must not be altered locally via ebuilds.
> +
>  
>  Maintaining users/groups
>  
> 

Maybe I'm not making myself clear (A bad habit of mine).

I want to keep this out such that maintainers can decide the best
keywords and when it is inappropriate to include a keyword.

For example with my acct-{group,user}/mysql ebuilds, I want to remove
the prefix keywords and only have those which match the virtual and
server implementations.  The rare occasion when a keyword is added is no
more a maintenance task like changing the virtual.  Having other ebuilds
outside the project use this package is not the right thing to do.

The packages in question treat prefix differently so why shouldn't it be
reflected here?

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering

2019-08-07 Thread Brian Evans
On 8/7/2019 11:20 AM, Mikle Kolyada wrote:
> Signed-off-by: Mikle Kolyada 
> ---
> As discussed with mgorny at #gentoo-qa
>  glep-0081.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/glep-0081.rst b/glep-0081.rst
> index 082e705..e5a4db2 100644
> --- a/glep-0081.rst
> +++ b/glep-0081.rst
> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used.  If 
> the user is
>  needed at install and/or run time, a run time dependency (``RDEPEND``)
>  must be used.
>  
> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS``
> +variable predefined, keywords must not be altered locally via ebuilds.
> +
>  
>  Maintaining users/groups
>  
> 

I object to this as I feel they can incorrect such as on prefix.

Also, this goes against the established practice of committing directly
to stable.  These are exactly the same as virtuals as "they install
nothing" and "just run a script" (to verify dependencies).

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] ruby-ng.eclass: drop support for jruby

2019-07-18 Thread Brian Evans
On 7/18/2019 3:41 AM, gra...@gentoo.org wrote:
> From: Hans de Graaff 
> 
> jruby has been removed from the tree for quite some time and is not
> used at all anymore in ebuilds. This also drops an inherit of
> java-utils-2 which blocks updating to EAPI 7.

While I get it is no longer needed, java-utils-2 has had EAPI 7 enabled
since December 2018.  Just saying.

Brian




Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-20 Thread Brian Evans
On 6/9/2019 7:39 AM, Michał Górny wrote:
> +Specification
> +=
> +
> +Policy
> +--
> +
> +Following the acceptance of this GLEP, all new users and groups must
> +be created via user/group packages as defined in this GLEP.  The old
> +method may still be used for existing users/groups, in existing
> +packages.
> +
> +All new users and groups must have unique UIDs/GIDs assigned
> +by developers.  The developer adding them is responsible for checking
> +for collisions.

What significance will such numbers have when a daemon uses a new
UID/GID and really doesn't care what it is?  Why do we have to go
through the effort of assigning fixed IDs at random?

> +
> +Before adding a new user and/or group, the developer must send a RFC
> +to the ``gentoo-dev`` mailing list.

This paragraph should go away.  It is a complete waste of time.


> +
> +
> +Logical structure
> +-
> +
> +In this proposal, system users and groups are represented by regular
> +packages.  Those packages logically represent the ownership of
> +the respective users and group, and technically implement their
> +creation.
> +
> +User packages are placed in ``acct-user`` category.  Each user package
> +defines the properties of the particular user, and must be named after
> +the user it creates.  It must depend at build and run time on the groups
> +the user belongs to.
> +
> +Group packages are placed in ``acct-group`` category.  Each group
> +package defines the properties of the particular group, and must be
> +named after the group it creates.
> +
> +All user and group packages must define preferred fixed UIDs/GIDs,
> +and they must be unique within the repository.  The packages should
> +indicate whether the value needs to be strictly enforced, or whether
> +another UID/GID is acceptable when the user exists already or requested
> +UID/GID is taken.
> +
> +Packages needing a specific user or group use dependencies to pull
> +the required user/group packages.  If the user is needed at build time,
> +a build time dependency (``DEPEND``) must be used.  If the user is
> +needed at install and/or run time, a run time dependency (``RDEPEND``)
> +must be used.

Sounds like extra upgrade dependency time in an already crowded
resolution tree.

> +
> +Rationale
> +=
> +
> +Requiring mailing list RFC
> +--
> +
> +The policy explicitly requires RFC-es for new users and groups, as they
> +have global scopes and effects of mistakes while adding them are hard
> +to fix.  Wider review should decrease the risk of major design mistakes.
> +
> +To provide one example, right now we have two different packages
> +creating ``git`` user and requiring a different home directory for
> +the user.  As a result, the first package being installed defines
> +the actual home directory, and both technically can not be installed
> +at the same time.

This section should go away.  It is a complete waste of time.

> +
> +
> +Satisfied goals
> +---
> +
> +Tracking of user/group usage is done through dependencies.  As long
> +as any installed package depends on a specific user/group package,
> +the respective user/group is assumed to be used.  If no package
> +requiring the specific user/group is left, the package manager
> +automatically prunes the package clearly indicating it is no longer
> +used.

You cannot know when a name is "no longer used".  An administrator could
have adopted a username for other purposes.

> +
> +Each user and group has a single respective package creating it.
> +If multiple packages need it, they depend on the same package.  This
> +ensures that all properties are kept in a single location, and do not
> +need to be synced.
> +
> +Having a single location with all predefined user/group ranges makes it
> +possible to maintain fixed UID/GID definitions.  This GLEP makes
> +allocating them obligatory.  While this isn't enforced for existing
> +users, it provides a way forward for new installations.
> +
> +Local overrides can be trivially implemented via local repository,
> +through overriding the respective user/group ebuilds.  The proposal also
> +respects direct sysadmin modifications.
> +
> +Avoiding unnecessary user/group creation at build time is implemented
> +via correct dependency types.  While this was possible with the status
> +quo, the dependency model should be more natural to developers and cause
> +less mistakes.
> +
> +




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] User/group packages: the masterplan

2019-06-20 Thread Brian Evans
On 6/18/2019 7:31 AM, Michał Górny wrote:
> 
> 3. Give people some time for wider testing.
> 
> At this point, the new eclasses would be non-binding, i.e. you will
> still be able to commit new packages using user.eclass old style.
> The eclasses would be bound with usual eclass stability requirements,
> i.e. some API changes may happen if necessary.
> 
> 4. If no major issues arise, submit GLEP 81 for formal approval.
> 
> Once GLEP 81 is formally approved, using user.eclass directly becomes
> deprecated and new packages are expected to use acct-*/*.
> 


I object to this as some packages just need a user/group for a single
daemon that is not shared with another package.  The numbering does not
really matter in this case as it will never leave the machine.

user.eclass should exist for this purpose and the acct-{group/user}
should exist for static purposes which I find to be rather rare.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] PSA: 13.0 profiles will be removed in a week

2019-06-10 Thread Brian Evans
On 6/10/2019 4:18 AM, Sergei Trofimovich wrote:
> 
> 13.0 profiles are deleted as:
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d396d1941f8fb674218683e5fdbb248f2c713f36
> 

Partially reverted just the profiles/releases/13.0 files until
profiles/hardened/linux files can be cleaned up.

Gentoo still needs this at least for now.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-db/mariadb-galera

2019-05-13 Thread Brian Evans
# Brian Evans  (14 May 2019)
# MariaDB 10.0 has reached end of life and has security issues
# dev-db/mariadb-galera users should upgrade to mariadb-10.1 or greater
# Removal in 30 days
dev-db/mariadb-galera
=dev-db/mariadb-10.0*



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] State of elogind integration and the default +elogind local USE flag on xorg-server.

2019-03-22 Thread Brian Evans
On 3/22/2019 4:32 PM, Piotr Karbowski wrote:
> Hi,
> 
> I'd like to propose doing the following:
> 
> - Keywording elogind on missing archs
> - Making elogind a global USE flag
> - Switching desktop profiles to elogind from consolekit while still
> preserving -suid +elogind on xorg-server for those that does not use
> desktop profiles (systemd profiles users not affected)
> - Making pambase always install the configuration for pam_elogind.so,
> the same way it does for pam_gnome_keyring.so at this very moment,
> effectively removing elogind USE flag from it.
> 
> What do you all think about?
> 
> -- Piotr.
> 

What are the implications, if any, of using DMs which are not aware of
{,e}logind?  Do they work without modification?

Afaik, only sddm or, now, gdm even have an elogind USE flag.

All other DMs have consolekit support but unknown elogind status.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] News Item wrt virtual/mysql -> dev-db/mysql-connector-c switch

2019-02-13 Thread Brian Evans
Title: MySQL server and library dependency shift
Author: Brian Evans 
Posted: 2019-02-13
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: virtual/mysql

Due to the complexity of supporting multiple client libraries,
the Gentoo MySQL maintainers have decided to drop dependencies on the
server installation where it is not absolutely necessary.

This will mean that packages might not automatically install the
server as a dependency since it does not have to exist on the local machine.

To ensure uninterrupted service, verify that the server package,
such as dev-db/mariadb, dev-db/mysql, etc, is included in the world file
where it is in operation. This can be accomplished by running emerge
with the --noreplace option.
Eg.: emerge --noreplace dev-db/mariadb



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-db/lib_mysqludf_{log,stem} dev-db/mysql-udf-{base64,http,ipv6}

2019-02-07 Thread Brian Evans
# Brian Evans  (7 Feb 2019)
# These packages will not build properly under the new split
# library package easily and have no maintainer.
# Cannot verify if they work with modern database versions either.
# Removal in 30 days. Bug 677450
dev-db/lib_mysqludf_log
dev-db/lib_mysqludf_stem
dev-db/mysql-udf-base64
dev-db/mysql-udf-http
dev-db/mysql-udf-ipv6



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: EAPI 7 changes for php-ext-source-r3.eclass

2019-01-19 Thread Brian Evans
On 1/17/19 8:14 PM, Brian Evans wrote:
> Here are the proposed changes (please excuse any mail client line wrapping):

Committed with ID c95baab3e63.

Brian


> 
> $ git diff -- php-ext-source-r3.eclass
> diff --git a/eclass/php-ext-source-r3.eclass
> b/eclass/php-ext-source-r3.eclass
> index 66d32d5c5eb..fd45317e63d 100644
> --- a/eclass/php-ext-source-r3.eclass
> +++ b/eclass/php-ext-source-r3.eclass
> @@ -1,10 +1,10 @@
> -# Copyright 1999-2018 Gentoo Foundation
> +# Copyright 1999-2019 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
> 
>  # @ECLASS: php-ext-source-r3.eclass
>  # @MAINTAINER:
>  # Gentoo PHP team 
> -# @SUPPORTED_EAPIS: 6
> +# @SUPPORTED_EAPIS: 6 7
>  # @BLURB: Compile and install standalone PHP extensions.
>  # @DESCRIPTION:
>  # A unified interface for compiling and installing standalone PHP
> @@ -14,8 +14,8 @@ inherit autotools
> 
>  EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
> 
> -case ${EAPI} in
> - 6) ;;
> +case ${EAPI:-0} in
> + 6|7) ;;
>   *)
>   die "${ECLASS} is not compatible with EAPI=${EAPI}"
>  esac
> @@ -106,6 +106,7 @@ esac
>  # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
>  # non-null. The option group "|| (..." is always started here.
>  REQUIRED_USE="${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }|| ( "
> +PHPDEPEND="${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( } "
>  for _php_target in ${USE_PHP}; do
>   # Now loop through each USE_PHP target and add the corresponding
>   # dev-lang/php slot to PHPDEPEND.
> @@ -125,19 +126,17 @@ unset _php_slot _php_target
>  # Finally, end the optional group that we started before the loop. Close
>  # the USE-conditional if PHP_EXT_OPTIONAL_USE is non-null.
>  REQUIRED_USE+=") ${PHP_EXT_OPTIONAL_USE:+ )}"
> +PHPDEPEND+=" ${PHP_EXT_OPTIONAL_USE:+ )}"
> +TOOLDEPS="sys-devel/m4 sys-devel/libtool"
> 
> -RDEPEND="${RDEPEND}
> - ${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }
> - ${PHPDEPEND}
> - ${PHP_EXT_OPTIONAL_USE:+ )}"
> -
> -DEPEND="${DEPEND}
> - sys-devel/m4
> - sys-devel/libtool
> - ${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }
> - ${PHPDEPEND}
> - ${PHP_EXT_OPTIONAL_USE:+ )}
> -"
> +RDEPEND="${PHPDEPEND}"
> +
> +case ${EAPI:-0} in
> + 6) DEPEND="${TOOLDEPS} ${PHPDEPEND}" ;;
> + 7) DEPEND="${PHPDEPEND}" ; BDEPEND="${TOOLDEPS} ${PHPDEPEND}" ;;
> +esac
> +
> +unset PHPDEPEND TOOLDEPS
> 
>  # @ECLASS-VARIABLE: PHP_EXT_SKIP_PHPIZE
>  # @DEFAULT_UNSET
> 




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] ant-tasks.eclass patch proposal

2019-01-18 Thread Brian Evans
On 1/18/2019 11:11 AM, Miroslav Šulc wrote:
> @@ -130,7 +112,11 @@ ant-tasks_src_unpack() {
>   cd "${S}"
>  
>   # replace build.xml with our modified for split 
> building
> - mv -f "${WORKDIR}"/build.xml .
> + if [ -e "${WORKDIR}"/${PV}-build.patch ] ; then
> + epatch "${WORKDIR}"/${PV}-build.patch

Adding epatch without 'inherit epatch'?  Sounds like gambling on faith.
Also limits to EAPI=6.

Brian

> + else
> + mv -f "${WORKDIR}"/build.xml .
> + fi
>  
>   cd lib
>   # remove bundled xerces



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] EAPI 7 changes for php-ext-source-r3.eclass

2019-01-17 Thread Brian Evans
Here are the proposed changes (please excuse any mail client line wrapping):

$ git diff -- php-ext-source-r3.eclass
diff --git a/eclass/php-ext-source-r3.eclass
b/eclass/php-ext-source-r3.eclass
index 66d32d5c5eb..fd45317e63d 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2

 # @ECLASS: php-ext-source-r3.eclass
 # @MAINTAINER:
 # Gentoo PHP team 
-# @SUPPORTED_EAPIS: 6
+# @SUPPORTED_EAPIS: 6 7
 # @BLURB: Compile and install standalone PHP extensions.
 # @DESCRIPTION:
 # A unified interface for compiling and installing standalone PHP
@@ -14,8 +14,8 @@ inherit autotools

 EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test

-case ${EAPI} in
-   6) ;;
+case ${EAPI:-0} in
+   6|7) ;;
*)
die "${ECLASS} is not compatible with EAPI=${EAPI}"
 esac
@@ -106,6 +106,7 @@ esac
 # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
 # non-null. The option group "|| (..." is always started here.
 REQUIRED_USE="${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }|| ( "
+PHPDEPEND="${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( } "
 for _php_target in ${USE_PHP}; do
# Now loop through each USE_PHP target and add the corresponding
# dev-lang/php slot to PHPDEPEND.
@@ -125,19 +126,17 @@ unset _php_slot _php_target
 # Finally, end the optional group that we started before the loop. Close
 # the USE-conditional if PHP_EXT_OPTIONAL_USE is non-null.
 REQUIRED_USE+=") ${PHP_EXT_OPTIONAL_USE:+ )}"
+PHPDEPEND+=" ${PHP_EXT_OPTIONAL_USE:+ )}"
+TOOLDEPS="sys-devel/m4 sys-devel/libtool"

-RDEPEND="${RDEPEND}
-   ${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }
-   ${PHPDEPEND}
-   ${PHP_EXT_OPTIONAL_USE:+ )}"
-
-DEPEND="${DEPEND}
-   sys-devel/m4
-   sys-devel/libtool
-   ${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }
-   ${PHPDEPEND}
-   ${PHP_EXT_OPTIONAL_USE:+ )}
-"
+RDEPEND="${PHPDEPEND}"
+
+case ${EAPI:-0} in
+   6) DEPEND="${TOOLDEPS} ${PHPDEPEND}" ;;
+   7) DEPEND="${PHPDEPEND}" ; BDEPEND="${TOOLDEPS} ${PHPDEPEND}" ;;
+esac
+
+unset PHPDEPEND TOOLDEPS

 # @ECLASS-VARIABLE: PHP_EXT_SKIP_PHPIZE
 # @DEFAULT_UNSET
$ git diff -- php-ext-source-r3.eclass
diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index 66d32d5c5eb..fd45317e63d 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: php-ext-source-r3.eclass
 # @MAINTAINER:
 # Gentoo PHP team 
-# @SUPPORTED_EAPIS: 6
+# @SUPPORTED_EAPIS: 6 7
 # @BLURB: Compile and install standalone PHP extensions.
 # @DESCRIPTION:
 # A unified interface for compiling and installing standalone PHP
@@ -14,8 +14,8 @@ inherit autotools
 
 EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
 
-case ${EAPI} in
-	6) ;;
+case ${EAPI:-0} in
+	6|7) ;;
 	*)
 		die "${ECLASS} is not compatible with EAPI=${EAPI}"
 esac
@@ -106,6 +106,7 @@ esac
 # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
 # non-null. The option group "|| (..." is always started here.
 REQUIRED_USE="${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }|| ( "
+PHPDEPEND="${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( } "
 for _php_target in ${USE_PHP}; do
 	# Now loop through each USE_PHP target and add the corresponding
 	# dev-lang/php slot to PHPDEPEND.
@@ -125,19 +126,17 @@ unset _php_slot _php_target
 # Finally, end the optional group that we started before the loop. Close
 # the USE-conditional if PHP_EXT_OPTIONAL_USE is non-null.
 REQUIRED_USE+=") ${PHP_EXT_OPTIONAL_USE:+ )}"
+PHPDEPEND+=" ${PHP_EXT_OPTIONAL_USE:+ )}"
+TOOLDEPS="sys-devel/m4 sys-devel/libtool"
 
-RDEPEND="${RDEPEND}
-	${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }
-	${PHPDEPEND}
-	${PHP_EXT_OPTIONAL_USE:+ )}"
-
-DEPEND="${DEPEND}
-	sys-devel/m4
-	sys-devel/libtool
-	${PHP_EXT_OPTIONAL_USE}${PHP_EXT_OPTIONAL_USE:+? ( }
-	${PHPDEPEND}
-	${PHP_EXT_OPTIONAL_USE:+ )}
-"
+RDEPEND="${PHPDEPEND}"
+
+case ${EAPI:-0} in
+	6) DEPEND="${TOOLDEPS} ${PHPDEPEND}" ;;
+	7) DEPEND="${PHPDEPEND}" ; BDEPEND="${TOOLDEPS} ${PHPDEPEND}" ;;
+esac
+
+unset PHPDEPEND TOOLDEPS
 
 # @ECLASS-VARIABLE: PHP_EXT_SKIP_PHPIZE
 # @DEFAULT_UNSET

signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Last rites: sys-process/vixie-cron

2018-09-20 Thread Brian Evans
On 9/20/2018 5:17 AM, Mikle Kolyada wrote:
> # Mikle Kolyada  (20 Sep 2018)
> # Dead upstream and unmaintained for a long time,
> # has multiple bugs open, use sys-process/cronie
> # instead (the fork). Removal in 30 days.
> sys-process/vixie-cron
> 

sys-process/cronie needs to be keyworded ~amd64-fbsd so that CI passes.

Thanks.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/2] Update libtool and autotools with EAPI7 dependencies

2018-09-10 Thread Brian Evans
On 9/7/2018 9:46 AM, Brian Evans wrote:
> Since these tools are run on a build host, they should be in BDEPENDS
> for new EAPIs.
> 
> I've also taken the liberty of declaring what EAPIs are supported as
> the lists will need to be adjusted in the future.
> 
> Comments welcome.
> 
> Brian
> 
> 
> 
Now committed..

commit 4a0b5227a8b85cc97fee1647587964e6576123ff
Author: Brian Evans 
Date:   Mon Sep 10 13:09:05 2018 -0400

eclass: libtool - Update to the latest stable elt-patches

As suggested by Chewi on the gentoo-dev ML

Signed-off-by: Brian Evans 

commit fda978185cde8189cfe7acf81079a163dcb78a40
Author: Brian Evans 
Date:   Fri Sep 7 09:37:17 2018 -0400

eclass: autotools - Mark compatible EAPIs and introduce BDEPEND

The autotools commands are run on the build host.
As such, their packages needs to be in BDEPEND for EAPI 7.

Also taking this opportunity to list compatible EAPIs to consider
future adjustments.

Signed-off-by: Brian Evans 

commit 5b58f83e6a23b001f6bdd5393e82cc6ab36072d2
Author: Brian Evans 
Date:   Fri Sep 7 09:33:55 2018 -0400

eclass: libtool - Mark compatible EAPIs and introduce BDEPEND

The eltpatch command is run on the build host.
As such, it needs to be in BDEPEND for EAPI 7.

Also taking this opportunity to list compatible EAPIs to consider
future adjustments.





signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 2/2] eclass: autotools - Mark compatible EAPIs and introduce BDEPEND

2018-09-07 Thread Brian Evans
The autotools commands are run on the build host.
As such, their packages needs to be in BDEPEND for EAPI 7.

Also taking this opportunity to list compatible EAPIs to consider
future adjustments.

Signed-off-by: Brian Evans 
---
 eclass/autotools.eclass | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 2bc70f7b3c0..9143aa454d0 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -4,6 +4,7 @@
 # @ECLASS: autotools.eclass
 # @MAINTAINER:
 # base-sys...@gentoo.org
+# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
 # @BLURB: Regenerates auto* build scripts
 # @DESCRIPTION:
 # This eclass is for safely handling autotooled software packages that need to
@@ -25,6 +26,11 @@ fi
 if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then
 _AUTOTOOLS_ECLASS=1
 
+case ${EAPI:-0} in
+   0|1|2|3|4|5|6|7) ;;
+   *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
+esac
+
 inherit libtool
 
 # @ECLASS-VARIABLE: WANT_AUTOCONF
@@ -118,7 +124,10 @@ RDEPEND=""
 # their own DEPEND string.
 : ${AUTOTOOLS_AUTO_DEPEND:=yes}
 if [[ ${AUTOTOOLS_AUTO_DEPEND} != "no" ]] ; then
-   DEPEND=${AUTOTOOLS_DEPEND}
+   case ${EAPI:-0} in
+   0|1|2|3|4|5|6) DEPEND=${AUTOTOOLS_DEPEND} ;;
+   7) BDEPEND=${AUTOTOOLS_DEPEND} ;;
+   esac
 fi
 __AUTOTOOLS_AUTO_DEPEND=${AUTOTOOLS_AUTO_DEPEND} # See top of eclass
 
-- 
2.18.0




[gentoo-dev] [PATCH 0/2] Update libtool and autotools with EAPI7 dependencies

2018-09-07 Thread Brian Evans


Since these tools are run on a build host, they should be in BDEPENDS
for new EAPIs.

I've also taken the liberty of declaring what EAPIs are supported as
the lists will need to be adjusted in the future.

Comments welcome.

Brian





[gentoo-dev] [PATCH 1/2] eclass: libtool - Mark compatible EAPIs and introduce BDEPEND

2018-09-07 Thread Brian Evans
The eltpatch command is run on the build host.
As such, it needs to be in BDEPEND for EAPI 7.

Also taking this opportunity to list compatible EAPIs to consider
future adjustments.
---
 eclass/libtool.eclass | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/eclass/libtool.eclass b/eclass/libtool.eclass
index 2e0f608d342..942bf34aa27 100644
--- a/eclass/libtool.eclass
+++ b/eclass/libtool.eclass
@@ -1,9 +1,10 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: libtool.eclass
 # @MAINTAINER:
 # base-sys...@gentoo.org
+# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
 # @BLURB: quickly update bundled libtool code
 # @DESCRIPTION:
 # This eclass patches ltmain.sh distributed with libtoolized packages with the
@@ -16,7 +17,11 @@
 if [[ -z ${_LIBTOOL_ECLASS} ]]; then
 _LIBTOOL_ECLASS=1
 
-DEPEND=">=app-portage/elt-patches-20170422"
+case ${EAPI:-0} in
+   0|1|2|3|4|5|6) DEPEND=">=app-portage/elt-patches-20170422" ;;
+   7) BDEPEND=">=app-portage/elt-patches-20170422" ;;
+   *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
+esac
 
 inherit toolchain-funcs
 
-- 
2.18.0




Re: [gentoo-dev] [PATCH] eclass: db-use - Update to eapi7-ver

2018-08-27 Thread Brian Evans
This is now committed with id 86416d2c4bf.

Brian

On 8/24/2018 1:28 PM, Brian Evans wrote:
> This is a very simple eclass which only calls these functions from eclasses:
> ver_cut (EAPI 0-6)
> get_libdir (EAPI 0-5)
> get_libname (ALL EAPI)
> 
> I see no little reason to place die statements for unknown EAPIs.
> Just changing the eclasses to better suit the latest EAPI should be OK.
> 
> Signed-off-by: Brian Evans 
> ---
>  eclass/db-use.eclass | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
> index 35f11df034a..83ae94799ca 100644
> --- a/eclass/db-use.eclass
> +++ b/eclass/db-use.eclass
> @@ -1,10 +1,14 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2018 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  # This is a common location for functions that aid the use of sys-libs/db
>  #
>  # Bugs: maintainer-nee...@gentoo.org
>  
> -inherit versionator multilib
> +# multilib is used for get_libname in all EAPI
> +case "${EAPI:-0}" in
> + 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
> + *) inherit multilib ;;
> +esac
>  
>  #Convert a version to a db slot
>  db_ver_to_slot() {
> @@ -38,7 +42,7 @@ db_findver() {
>   fi
>  
>   PKG="$(best_version $1)"
> - VER="$(get_version_component_range 1-2 "${PKG/*db-/}")"
> + VER="$(ver_cut 1-2 "${PKG/*db-/}")"
>   if [ -d "${EPREFIX}"/usr/include/db$(db_ver_to_slot "$VER") ]; then
>   #einfo "Found db version ${VER}" >&2
>   echo -n "$VER"
> 




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] eclass: db-use - Update to eapi7-ver

2018-08-24 Thread Brian Evans
This is a very simple eclass which only calls these functions from eclasses:
ver_cut (EAPI 0-6)
get_libdir (EAPI 0-5)
get_libname (ALL EAPI)

I see no little reason to place die statements for unknown EAPIs.
Just changing the eclasses to better suit the latest EAPI should be OK.

Signed-off-by: Brian Evans 
---
 eclass/db-use.eclass | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/eclass/db-use.eclass b/eclass/db-use.eclass
index 35f11df034a..83ae94799ca 100644
--- a/eclass/db-use.eclass
+++ b/eclass/db-use.eclass
@@ -1,10 +1,14 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # This is a common location for functions that aid the use of sys-libs/db
 #
 # Bugs: maintainer-nee...@gentoo.org
 
-inherit versionator multilib
+# multilib is used for get_libname in all EAPI
+case "${EAPI:-0}" in
+   0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
+   *) inherit multilib ;;
+esac
 
 #Convert a version to a db slot
 db_ver_to_slot() {
@@ -38,7 +42,7 @@ db_findver() {
fi
 
PKG="$(best_version $1)"
-   VER="$(get_version_component_range 1-2 "${PKG/*db-/}")"
+   VER="$(ver_cut 1-2 "${PKG/*db-/}")"
if [ -d "${EPREFIX}"/usr/include/db$(db_ver_to_slot "$VER") ]; then
#einfo "Found db version ${VER}" >&2
echo -n "$VER"
-- 
2.18.0




[gentoo-dev] autotools.eclass and EAPI 7

2018-08-16 Thread Brian Evans
There are currently a handful of ebuilds using EAPI 7 and the autotools
eclass.

I believe that this eclass should be reviewed for adding BDEPEND or
having BDEPEND replace the DEPEND statement as the default action of the
eclass.

Other items might be needed, but that's doubtful.

Someone please advise the best course of action and either do it or I
will propose a patch based on the discussion.

Thanks.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so

2018-07-24 Thread Brian Evans
On 7/24/2018 12:44 AM, David Seifert wrote:
> On Mon, 2018-07-23 at 14:18 -0400, Brian Evans wrote:
>> With the current state of the forks of MySQL diverging, the client
>> libraries are no longer compatible.
>>
>> Since virtual packages cannot handle rebuilds of subscribed packages
>> when a consumer changes, the following action is to be taken by all
>> developers:
>>
>> If you need libmysqlclient.so, please depend on dev-db/mysql-
>> connector-c.
>> If you need or can use libmariadb.so, please depend on
>> dev-db/mariadb-connector-c.
>>
>> (Yes the above packages coexist just fine.)
>>
>> Please remove references to virtual/libmysqlclient as it does not
>> work
>> as I intended (and explained above). This virtual will be last-rites
>> once nothing depends on it.
>>
>> Please remove all DEPEND on virtual/mysql where it is used for
>> libraries.
>> virtual/mysql is the client and server tools *only*.
>> It is not correct to rely on this for libraries any longer.
>> A good example for DEPEND is tests where the client/server binaries
>> are run.
>> RDEPEND for the purpose of running client/server is fine for
>> virtual/mysql.
>>
>> Almost all of the consumers of virtual/mysql have already been
>> updated
>> (save mysql-cluster).  Some are already stable.
>>
>> At a point in the future, likely in 2019, the compatibility DEPEND
>> that
>> exist in the consumers will be removed and may break packages which
>> are
>> not updated.
>>
>> In the coming months, I will try my best to test and report bugs on
>> packages which I can find.
>>
>> I welcome any discussion on the details, but this is the only sane
>> move
>> for Gentoo and the ABI incompatibilities that exist on the client
>> libraries.
>>
>> Thank you,
>>
>> Brian Evans
>>
> 
> How do you plan on dispatching against them at compile/link-time, i.e.
> USE=libav/graphicsmagick/libressl?
> 
> David
> 

If a maintainer wishes to have a USE flag to link to libmariadb, that's
up to them.

Use of mariadb-connector-c may need patching (for mariadb_config or
mariadb.pc) or build options to look at the other library.  This may be
beneficial for licensing purposes (GPL-2 vs LGPL-2.1)

If such a flag is popular enough, then a global description can be
agreed upon.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so

2018-07-23 Thread Brian Evans
With the current state of the forks of MySQL diverging, the client
libraries are no longer compatible.

Since virtual packages cannot handle rebuilds of subscribed packages
when a consumer changes, the following action is to be taken by all
developers:

If you need libmysqlclient.so, please depend on dev-db/mysql-connector-c.
If you need or can use libmariadb.so, please depend on
dev-db/mariadb-connector-c.

(Yes the above packages coexist just fine.)

Please remove references to virtual/libmysqlclient as it does not work
as I intended (and explained above). This virtual will be last-rites
once nothing depends on it.

Please remove all DEPEND on virtual/mysql where it is used for libraries.
virtual/mysql is the client and server tools *only*.
It is not correct to rely on this for libraries any longer.
A good example for DEPEND is tests where the client/server binaries are run.
RDEPEND for the purpose of running client/server is fine for virtual/mysql.

Almost all of the consumers of virtual/mysql have already been updated
(save mysql-cluster).  Some are already stable.

At a point in the future, likely in 2019, the compatibility DEPEND that
exist in the consumers will be removed and may break packages which are
not updated.

In the coming months, I will try my best to test and report bugs on
packages which I can find.

I welcome any discussion on the details, but this is the only sane move
for Gentoo and the ABI incompatibilities that exist on the client libraries.

Thank you,

Brian Evans



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: killing mediawiki

2018-07-03 Thread Brian Evans
On 7/3/2018 1:39 PM, William Hubbs wrote:
> All,
> 
> some of us have talked about this on IRC off and on, but I want to bring
> it up here as well.
> 
> I don't care that we have a wiki, but can we please look into killing
> mediawiki and look at something with a git backend? It would be very
> nice to be able to edit wiki pages in markdown or another similar format
> and use git to control the changes instead of editing in a browser.
> 

For what purpose? The Handbook? No objections to that as it is limited
access already. We just go back to what we were doing in CVS.

If there is to be a replacement, then it should be equal access to what
we have now.

Users can create and edit pages which are not protected  (currently by
namespaces).

This should continue IMO.

Brian




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Package up for grabs - www-plugin/freshplayerplugin

2018-05-05 Thread Brian Evans
I no longer use this package and cannot give it the attention it needs.

www-plugin/freshplayerplugin

It has dropped to maintainer-needed with 2 open bugs.

Anyone willing to take it may do so.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: php-pear-r1 eclass

2018-04-25 Thread Brian Evans
eclass: php-pear-r1 mark DEAD

This eclass is problematic as it creates a dependency database
which is quickly removed.  Also the PHP invocation may need
to addpredict for libsnmp.

Superseded by php-pear-r2 eclass

2 packages remain with new versions/revisions on php-pear-r2

Removal in 30 days or when the last consumer is stabled and old version
dropped, whichever is later.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: several dev-php/PEAR-* packages (Mar 2018)

2018-03-20 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org (20 Mar 2018)
# These PEAR packages are unmaintained upstream and
# are difficult to test or have no tests.
# PHP team no longer wants to maintain these for PHP7 and beyond
# Removal in 30 days. Bug 650988
dev-php/PEAR-File_Passwd
dev-php/PEAR-HTML_QuickForm
dev-php/PEAR-HTML_QuickForm_Controller
dev-php/PEAR-HTML_QuickForm_advmultiselect
dev-php/PEAR-HTML_Select
dev-php/PEAR-I18Nv2



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Changes for php-ext-source-r3 wrt bug 650324

2018-03-12 Thread Brian Evans
Bug 650324 noticed some inconsistencies with how user patches are applied.

Previously, it attempted to call default_src_prepare per target.
This, of course, would not reapply user patches for each target.

These patches bring this back into alignment and adjust packages which
would be negatively affected by this change.

Brian
From c0693eeafe8004ab698d2b46fa8a8c66aa1851a7 Mon Sep 17 00:00:00 2001
From: Brian Evans <grkni...@gentoo.org>
Date: Mon, 12 Mar 2018 20:19:36 -0400
Subject: [PATCH 1/7] eclass: php-ext-sources-r3 - Apply user patches to all
 targets

The original eclass copied sources as part of the exported src_unpack
and then attempted to apply default_src_prepare to every PHP_TARGET.

As the bug shows, this fails on eapply_user because that function will
only ever apply once.

Instead, eliminate the php-ext-sources-r3_src_unpack. Move the copy
function to src_prepare phase after patches were applied,
optionally disabled by PHP_EXT_SKIP_PATCHES=yes.

This eclass will only apply patches to PHP_EXT_S.

Fixes: https://bugs.gentoo.org/650324
---
 eclass/php-ext-source-r3.eclass | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index dfcec487685..22f07f8827b 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -11,7 +11,7 @@
 
 inherit autotools
 
-EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install src_test
+EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
 
 case ${EAPI} in
 	6) ;;
@@ -141,23 +141,16 @@ DEPEND="${DEPEND}
 # @ECLASS-VARIABLE: PHP_EXT_SKIP_PHPIZE
 # @DEFAULT_UNSET
 # @DESCRIPTION:
-# By default, we run "phpize" in php-ext-source-r3_src_unpack(). Set
+# By default, we run "phpize" in php-ext-source-r3_src_prepare(). Set
 # PHP_EXT_SKIP_PHPIZE="yes" in your ebuild if you do not want to run
 # phpize (and the autoreconf that becomes necessary afterwards).
 
-# @FUNCTION: php-ext-source-r3_src_unpack
+# @ECLASS-VARIABLE: PHP_EXT_SKIP_PATCHES
+# @DEFAULT_UNSET
 # @DESCRIPTION:
-# Runs the default src_unpack and then makes a copy for each PHP slot.
-php-ext-source-r3_src_unpack() {
-	default
-
-	local slot orig_s="${PHP_EXT_S}"
-	for slot in $(php_get_slots); do
-		cp --recursive --preserve "${orig_s}" "${WORKDIR}/${slot}" || \
-			die "failed to copy sources from ${orig_s} to ${WORKDIR}/${slot}"
-	done
-}
-
+# By default, we run default_src_prepare to PHP_EXT_S.
+# Set PHP_EXT_SKIP_PATCHES="yes" in your ebuild if you
+# want to apply patches yourself.
 
 # @FUNCTION: php-ext-source-r3_src_prepare
 # @DESCRIPTION:
@@ -165,9 +158,16 @@ php-ext-source-r3_src_unpack() {
 # src_prepare() for PATCHES/eapply_user support, and then call
 # php-ext-source-r3_phpize.
 php-ext-source-r3_src_prepare() {
+	local slot orig_s="${PHP_EXT_S}"
+	if [[ "${PHP_EXT_SKIP_PATCHES}" != 'yes' ]] ; then
+		pushd "${orig_s}" > /dev/null || die
+		default
+		popd > /dev/null || die
+	fi
 	for slot in $(php_get_slots); do
+		cp --recursive --preserve "${orig_s}" "${WORKDIR}/${slot}" || \
+			die "failed to copy sources from ${orig_s} to ${WORKDIR}/${slot}"
 		php_init_slot_env "${slot}"
-		default
 		php-ext-source-r3_phpize
 	done
 }
-- 
2.16.1

From 5f6b52cdbfa4458a7ea4940b01d115c4dc2bae4c Mon Sep 17 00:00:00 2001
From: Brian Evans <grkni...@gentoo.org>
Date: Mon, 12 Mar 2018 20:29:26 -0400
Subject: [PATCH 2/7] sci-geosciences/mapserver: Apply php-ext-source-r3
 changes to src_unpack

---
 sci-geosciences/mapserver/mapserver-7.0.5.ebuild | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sci-geosciences/mapserver/mapserver-7.0.5.ebuild b/sci-geosciences/mapserver/mapserver-7.0.5.ebuild
index 69fae655f2c..a412b4ed85e 100644
--- a/sci-geosciences/mapserver/mapserver-7.0.5.ebuild
+++ b/sci-geosciences/mapserver/mapserver-7.0.5.ebuild
@@ -83,12 +83,10 @@ pkg_setup() {
 }
 
 src_unpack() {
-	# unpack A and then copy the php thingies into workdir/php-slot
-	php-ext-source-r3_src_unpack
-	# HACK: and then remove it and replace by symlink
+	default
+	# HACK: Make symlinks for php targets
 	local slot
 	for slot in $(php_get_slots); do
-		rm -rf "${WORKDIR}/${slot}" || die
 		ln -s "${PHP_EXT_S}" "${WORKDIR}/${slot}" || die
 	done
 }
-- 
2.16.1

From 22aff5b20453f792966b8a3a6372bb7c3c39426e Mon Sep 17 00:00:00 2001
From: Brian Evans <grkni...@gentoo.org>
Date: Mon, 12 Mar 2018 20:31:23 -0400
Subject: [PATCH 3/7] dev-php/twig: Remove src_unpack as changes to eclass make
 it obsolete

---
 dev-php/twig/twig-1.31.0.ebuild | 9 -
 1 file changed, 9 deletions(-)

diff --git a/dev-php/twig/twig-1.31.0.ebuild b/dev-php/twig/twig-1.31.0.ebuild
index e62d3486a73..7e678f068e6 100644
--- a/dev-php/twi

Re: [gentoo-dev] dev-db/maxscale - Last rites

2018-03-06 Thread Brian Evans
On 03/06/2018 05:55 PM, Geaaru wrote:
> Hi,
> 
> I'm not sure that comment of the issue is yet correct with last version.
> I think that depends of mariadb libraries and maybe it works also with
> mysql but I will investigate on it.
> 
> Here (not last version but at least v.2.x):
> 
> https://github.com/geaaru/geaaru_overlay/blob/master/dev-db/maxscale/maxscale-2.1.5.ebuild
> 
> An error on my ebuild is that now license is BSL but I can fix fast this.
> 
> I try to check compilation with last gcc version and push a pr to gentoo
> upstream it you agree and try to get package as proxy mantainer.
> 
> My cent
> G.
> 
> On Mar 6, 2018 6:33 PM, "Brian Evans" <grkni...@gentoo.org
> <mailto:grkni...@gentoo.org>> wrote:
> 
> # Brian Evans <grkni...@gentoo.org <mailto:grkni...@gentoo.org>> (06
> Mar 2018)
> # MariaDB MaxScale 1.x depends on the deprecated libmysqld
> # Newer versions bundle software that require git access
> # and modify system libraries for their own purposes making
> # it extremely difficult to package.
> # Bug 649764 Removal in 30 days.
> dev-db/maxscale
> 

As it sits, Line 27 of your ebuild is not acceptable,
virtual/mysql[embedded] is going away.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] dev-db/maxscale - Last rites

2018-03-06 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org> (06 Mar 2018)
# MariaDB MaxScale 1.x depends on the deprecated libmysqld
# Newer versions bundle software that require git access
# and modify system libraries for their own purposes making
# it extremely difficult to package.
# Bug 649764 Removal in 30 days.
dev-db/maxscale



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-php/ZendFramework

2018-02-22 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org> (22 Feb 2018)
# Multiple vulnerablities, branch EOL upstream.
# Masked for removal in 30 days. Bug #604182
dev-php/ZendFramework



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] NonsolvableDepsInMisc

2018-02-17 Thread Brian Evans
On 02/16/2018 05:15 PM, Lucas Ramage wrote:
> Hello,
> 
> I submitted a pull request which adds new packages as dependencies for
> the package I am attempting to maintain and I am receiving the following
> errors,
> 
> https://qa-reports.gentoo.org/output/gentoo-ci/aca3f2128/output.html#dev-python/paho-mqtt
> 
> NonsolvableDepsInDev
> 
> NonsolvableDepsInStable
> 
> ​I have built the package in a container using FEATURE="test" and also
> ran `repoman -dx full` as instructed in the Gentoo Github Documentation
> and I had no problems.
> 

You have dev-python/paho-mqtt as KEYWORDS="~amd64 ~x86", but added new
packages  dev-python/pylama and dev-python/pydocstyle with just
KEYWORDS="~amd64".

That is an error.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: several dev-php/PEAR-* packages (Feb 2018)

2018-02-15 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org (15 Feb 2018)
# These PEAR packages are unmaintained upstream and
# are difficult to test or have no tests.
# PHP team no longer wants to maintain these for PHP7 and beyond
# Removal in 30 days - Bug 647768
dev-php/PEAR-Benchmark
dev-php/PEAR-Calendar
dev-php/PEAR-Console_Color
dev-php/PEAR-Crypt_Blowfish
dev-php/PEAR-Crypt_RC4
dev-php/PEAR-XML_Beautifier
dev-php/PEAR-XML_Feed_Parser
dev-php/PEAR-Structures_DataGrid
dev-php/PEAR-PHP_CompatInfo
dev-php/PEAR-Net_Server
dev-php/PEAR-Net_LMTP
dev-php/PEAR-Net_IMAP
dev-php/PEAR-Net_FTP
dev-php/PEAR-Net_DIME
dev-php/PEAR-Math_Stats



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

2018-02-14 Thread Brian Evans
On 2/14/2018 9:35 AM, Francesco Riosa wrote:
> 
> On 14/02/2018 05:37, Robin H. Johnson wrote:
>> On Tue, Feb 13, 2018 at 09:32:32PM -0500, Brian Evans wrote:
>>> I have a plan I would like some eyes on...
>>>
>>> I want to gradually *BAN* the use of virtual/mysql and
>>> virtual/libmysqlclient as dependencies.
>> Overall I agree, but there's some slight concerns I have.
>>
>>> To accomplish this, force dev-db/mysql-connector-c to be the only souce
>>> of libmysqlclient.so.
>>>
>>> Packages that choose to support  libmariadb.so instead can include a
>>> libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
>>> introduced (and they can live side-by-side).  The motivation for this
>>> could be licensing with libmariadb being LGPL instead of GPL.  This is
>>> similar to ffmpeg/libav, except the libraries can co-exist.
>> Have all the concerns about using slightly different libmysqlclient.so
>> builds been resolved? Esp for pre-built binaries (I don't know if there
>> are any left in the tree).
>>
>>> The current providers of virtual/mysql would get a new USE flag that is
>>> MASKED for all users for the transition period and pull in the lib
>>> package(s) when that USE is disabled.
>>>
>>> virtual/mysql would become a server reference for USERS only.  It would
>>> be a QA warning violation to depend directly on virtual/mysql as it can
>>> live anywhere.
>> This part worries me slightly. I do understand that mysql-embedded is
>> retired entirely, but apps that spun up their own local mysqld instance
>> would still be affected this this change.
> 
> Checked a random desktop install and found these packages depending on
> virtual/mysql:
> 
> vivo@Monfi ~ $ equery d virtual/mysql
>  * These packages depend on virtual/mysql:
> dev-db/mariadb-10.2.12 (server ? ~virtual/mysql-5.6[embedded=,static=])
> dev-libs/apr-util-1.6.1 (mysql ? =virtual/mysql-5*)
> dev-libs/cyrus-sasl-2.1.26-r11 (mysql ? virtual/mysql)
> dev-libs/redland-1.0.17-r1 (mysql ? virtual/mysql)
> kde-apps/akonadi-17.12.2 (mysql ? virtual/mysql)
> net-analyzer/net-snmp-5.7.3_p3 (mysql ? virtual/mysql)
> net-mail/mailutils-3.4 (mysql ? virtual/mysql)
> sci-mathematics/glpk-4.63 (mysql ? virtual/mysql)
dev-libs/apr-util-1.6.1 (mysql ? dev-db/mysql-connector-c:=)
dev-libs/cyrus-sasl-2.1.26-r11 (mysql ? dev-db/mysql-connector-c:=)
dev-libs/redland-1.0.17-r1 (mysql ? dev-db/mysql-connector-c:=)
kde-apps/akonadi-17.12.2 (mysql ? dev-db/mysql-connector-c:=)
net-analyzer/net-snmp-5.7.3_p3 (mysql ? dev-db/mysql-connector-c:=)
net-mail/mailutils-3.4 (mysql ? dev-db/mysql-connector-c:=)
sci-mathematics/glpk-4.63 (mysql ? dev-db/mysql-connector-c:=)


> 
> It would be interesting to know how their ${*DEPEND} should look after
> the change.
> 
> Honestly I'd also like to understand the rationale better, why this
> change is needed?
> Are the implementations of Oracle mysql and Mariadb so different that
> it's not possible anymore to consider those equivalent (for what
> packages see)?

This is needed for a few reasons:

1) Virtuals cannot rebuild dependencies when there are subslot changes
2) dev-db/mysql-5.7 and dev-db/percona-server-5.7 are prevented from
entering the tree simply due to the client library SOVERSION change.  It
is difficult for the user to swap between server versions.
3) libmariadb.so is a pthread_once library which many other packages are
not expecting.  So they may have to write things two different ways



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

2018-02-13 Thread Brian Evans
I have a plan I would like some eyes on...

I want to gradually *BAN* the use of virtual/mysql and
virtual/libmysqlclient as dependencies.

To accomplish this, force dev-db/mysql-connector-c to be the only souce
of libmysqlclient.so.

Packages that choose to support  libmariadb.so instead can include a
libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
introduced (and they can live side-by-side).  The motivation for this
could be licensing with libmariadb being LGPL instead of GPL.  This is
similar to ffmpeg/libav, except the libraries can co-exist.

The current providers of virtual/mysql would get a new USE flag that is
MASKED for all users for the transition period and pull in the lib
package(s) when that USE is disabled.

virtual/mysql would become a server reference for USERS only.  It would
be a QA warning violation to depend directly on virtual/mysql as it can
live anywhere.

virtual/libmysqlclient would be last-rite as it doesn't work as intended

That about sums it up.

Brian
MySQL team lead



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last Rites: Dead X11 packages

2018-02-08 Thread Brian Evans
On 2/8/2018 12:14 PM, James Le Cuirot wrote:
> On Thu, 8 Feb 2018 18:05:55 +0100
> Michael Lienhardt  wrote:
>> Thanks for the information and sorry for the noise.
>> I wasn't fully aware of the meaning of the --dynamics-deps and
>> --changed-deps option. I am still not entirely convinced that
>> changing a package after it is committed to the repository cannot do
>> harm: even as a user, I would like to know when and why a package's
>> dependencies changed. But I don't maintain packages so my opinion is
>> not very relevant, and the gentoo guidelines indeed allow to change
>> the dependencies inline.
> 
> It's not like this stuff is totally invisible as it is noted in the git
> log. We just don't want to tie up several minutes of CPU time for the
> majority of users for no tangible benefit.
> 

The benefit is that portage won't yell at you for having a masked
package installed and no obvious way to clean it up.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last Rites: Dead X11 packages

2018-02-08 Thread Brian Evans
On 2/7/2018 9:54 PM, Matt Turner wrote:
> # Matt Turner  (06 Feb 2018)
> # Dead and unused
> # Masked for removal in 30 days. Bug #646838
> x11-libs/libXCalibrate
> x11-libs/libXfontcache
> x11-misc/xtscal
> x11-proto/fontcacheproto
> x11-proto/xcalibrateproto
> x11-proto/xf86rushproto


> From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17 00:00:00 2001
> From: Matt Turner 
> Date: Tue, 6 Feb 2018 14:02:59 -0800
> Subject: x11-base/xorg-server: Remove dead x11-proto/xf86rushproto dependency
> 
> rushproto hasn't been required since upstream commit 8ec79e05feac (in
> 2005!), and even then it wasn't actually needed!
> 
> Package-Manager: Portage-2.3.19, Repoman-2.3.6
> ---
>  x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +--
>  x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +--
>  x11-base/xorg-server/xorg-server-.ebuild   | 3 +--
>  3 files changed, 3 insertions(+), 6 deletions(-)
> 

Please don't edit dependencies in-line like this.

This warranted a revbump as users will be asking how to remove
x11-proto/xf86rushproto. It won't come up for depclean because of
xorg-server not being scheduled for rebuild automatically until the next
time it is upgraded or --changed-deps option is used (uncommon).

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] php-ext-source-r3 eclass improvements

2018-01-29 Thread Brian Evans
On 1/26/2018 10:38 AM, Brian Evans wrote:
> The following patches improve the php-ext-source-r3 eclass by introducing
> two new variables.
> 
> The first allows the configration INI name to vary from a hard-coded default
> of the module name.
> 
> The second allows USE dependencies to be added to each implementation
> similar to python team's PYTHON_REQ_USE.
> 
> Comments are welcome
> 
> Brian
> 
> 

These are now committed.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 2/2] php-ext-source-r3.eclass: Introduce PHP_EXT_NEEDED_USE

2018-01-26 Thread Brian Evans
This simplifies the dependencies in an ebuild

@DESCRIPTION:
A list of USE flags to append to each PHP target selected
as a valid USE-dependency string.  The value should be valid
for all targets so USE defaults may be necessary.
Example:
PHP_EXT_NEEDED_USE="mysql?,pdo,pcre(+)"

The PHP dependencies will result in:
php_targets_php7-0? ( dev-lang/php:7.0[mysql?,pdo,pcre(+)] )
---
 eclass/php-ext-source-r3.eclass | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index 315ce32887f..96d55f97a55 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -84,6 +84,22 @@ esac
 # @CODE@
 : ${PHP_INI_NAME:=${PHP_EXT_NAME}}
 
+# @ECLASS-VARIABLE: PHP_EXT_NEEDED_USE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# A list of USE flags to append to each PHP target selected
+# as a valid USE-dependency string.  The value should be valid
+# for all targets so USE defaults may be necessary.
+# Example:
+# @CODE
+# PHP_EXT_NEEDED_USE="mysql?,pdo,pcre(+)"
+# @CODE
+#
+# The PHP dependencies will result in:
+# @CODE
+# php_targets_php7-0? ( dev-lang/php:7.0[mysql?,pdo,pcre(+)] )
+# @CODE
+
 
 # Make sure at least one target is installed. First, start a USE
 # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
@@ -96,6 +112,9 @@ for _php_target in ${USE_PHP}; do
REQUIRED_USE+="php_targets_${_php_target} "
_php_slot=${_php_target/php}
_php_slot=${_php_slot/-/.}
+   if [[ ${PHP_EXT_NEEDED_USE} ]] ; then
+   _php_slot+=[${PHP_EXT_NEEDED_USE}]
+   fi
PHPDEPEND+=" php_targets_${_php_target}? ( dev-lang/php:${_php_slot} )"
 done
 
-- 
2.16.1




[gentoo-dev] [PATCH 1/2] php-ext-source-r3.eclass: Introduce PHP_INI_NAME variable

2018-01-26 Thread Brian Evans
Currently php-ext-source-r3 saves the enabling ini file as
"${PHP_EXT_NAME}.ini".  This is problematic when foo module needs to be
loaded before bar module as things are read in directory order.

This patch introduces PHP_INI_NAME which defaults to PHP_EXT_NAME for
backwards-compatibility.
---
 eclass/php-ext-source-r3.eclass | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index bc6751562a5..315ce32887f 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2016 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: php-ext-source-r3.eclass
@@ -73,6 +73,17 @@ esac
 # the tree.
 [[ -z "${PHP_EXT_SAPIS}" ]] && PHP_EXT_SAPIS="apache2 cli cgi fpm embed phpdbg"
 
+# @ECLASS-VARIABLE: PHP_INI_NAME
+# @DESCRIPTION
+# An optional file name of the saved ini file minis the ini extension
+# This allows ordering of extensions such that one is loaded before
+# or after another.  Defaults to the PHP_EXT_NAME.
+# Example (produces 40-foo.ini file):
+# @CODE@
+# PHP_INI_NAME="40-foo"
+# @CODE@
+: ${PHP_INI_NAME:=${PHP_EXT_NAME}}
+
 
 # Make sure at least one target is installed. First, start a USE
 # conditional like "php?", but only when PHP_EXT_OPTIONAL_USE is
@@ -295,7 +306,7 @@ php_slot_ini_files() {
local x
for x in ${PHP_EXT_SAPIS} ; do
if [[ -f "${EPREFIX}/etc/php/${x}-${1}/php.ini" ]] ; then
-   slot_ini_files+=" 
etc/php/${x}-${1}/ext/${PHP_EXT_NAME}.ini"
+   slot_ini_files+=" 
etc/php/${x}-${1}/ext/${PHP_INI_NAME}.ini"
fi
done
 
@@ -324,7 +335,7 @@ php-ext-source-r3_createinifiles() {
einfo "Added contents of 
${FILESDIR}/${PHP_EXT_INIFILE}" \
  "to ${file}"
fi
-   inidir="${file/${PHP_EXT_NAME}.ini/}"
+   inidir="${file/${PHP_INI_NAME}.ini/}"
inidir="${inidir/ext/ext-active}"
dodir "/${inidir}"
dosym "/${file}" "/${file/ext/ext-active}"
-- 
2.16.1




[gentoo-dev] [RFC] php-ext-source-r3 eclass improvements

2018-01-26 Thread Brian Evans
The following patches improve the php-ext-source-r3 eclass by introducing
two new variables.

The first allows the configration INI name to vary from a hard-coded default
of the module name.

The second allows USE dependencies to be added to each implementation
similar to python team's PYTHON_REQ_USE.

Comments are welcome

Brian




[gentoo-dev] Last rites: mysql-multilib eclass

2018-01-18 Thread Brian Evans
The mysql-multilib eclass was only used for internal packages in the
mysql teams' packages.

Nothing should have depended on it outside of that and will be removed
in 30 days as it is no longer used.

Thank,

Brian Evans



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...

2017-12-27 Thread Brian Evans
> # Pacho Ramos  (27 Dec 2017)
> # All Ekiga set is dead and broken for years, it relies on obsolete
> # dead/libs that are also old and broken and upstream looks to not release
> # newer ekiga ever. To keep this please go ahead and take care of it *and
> # all the dependencies it also needs*. See bugs #626176, #460458, #589276,
> # #638122, #641990, #633670, #624578, #600398, #627868.
> # Removal in a month.
> net-libs/ptlib
> net-libs/opal
> net-voip/openmcu
> net-voip/ekiga
> 
> 

It seems you missed net-libs/h323plus which needs net-libs/ptlib.

h323plus is needed for net-voip/openmcu (already masked above) and
net-voip/yate[h323]



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] First (experimental) 17.1 profiles news item for review

2017-12-20 Thread Brian Evans
On 12/18/2017 1:51 PM, Michał Górny wrote:
> Hello, everyone.
> 
> The first news item I'd like to submit for 17.1 profiles follows.
> The item is aimed at ~amd64 users who'd like to test the new profiles.
> When they become stable, a separate news item for all our users will be
> published.
> 

I'm not sure if it is valid to put in the news item or modify the tool,
but users of PostgreSQL will need to either 'mv /usr/lib/postgresql
/usr/lib64' or, probably better, re-execute 'eselect postgresql'. The
symlink will not be moved by the unsymlink-lib tool and build failures
are likely to occur if libraries are searched for in this method

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] cmake + ninja vs autotools

2017-11-16 Thread Brian Evans
On 11/15/2017 10:27 PM, William L. Thomson Jr. wrote:
> It maybe worth considering switching the default generator in the
> cmake-utils.eclass from the default of emake to ninja.
> 
> - : ${CMAKE_MAKEFILE_GENERATOR:=emake}
> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
> 
> For those with cmake ebuilds you can test this out now via 
> 
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils
> 
> Working with both cmake and meson. It seems the real performance of
> meson comes from ninja. I am a bit more a fan of cmake than meson for
> cpack, generation of deb, rpm, and binary tarball, in addition to
> sources. That can be done with meson but not as elegantly at this time.
> 
> ninja is noticeably faster than make. I haven't seen any cases yet where
> cmake autotools works, and ninja does not. They seem pretty equal, so
> should be safe. Of course could use testing first.

There are still cases where ninja fails...

I have forcefully set emake in dev-db/{mysql,mysql-cluster} because they
fail to build with ninja (using the cmake generator) yet emake works
just fine.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] dev-php/PEAR-Services_W3C_HTMLValidator - Last rites

2017-11-07 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org> (07 Nov 2017)
# Remote service removed this method, dead upstream
# Masked for removal in 30 days.
# Bug 636796
dev-php/PEAR-Services_W3C_HTMLValidator



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] dev-php/PEAR-HTTP_Download

2017-11-06 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org (06 Nov 2017)
# Broken with new PHP, dead upstream, broken tests
# Masked for removal in 30 days.
# Bug 636742
dev-php/PEAR-HTTP_Download



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: php-ext-pecl-r2 eclass

2017-10-19 Thread Brian Evans
The php-ext-pecl-r2 eclass has no more consumers and is superseded by
php-ext-pecl-r3 eclass.

This eclass will be removed in 30 days.  Please update any overlays
still using this old eclass as the move to -r3 is rather trivial [1].

The php-ext-source-r2 eclass will follow once all consumers in the
Gentoo repository are updated and, potentially, marked stable.

Thank you,

Brian Evans

[1]
https://wiki.gentoo.org/wiki/Project:PHP/Php-ext-source-r3_migration_guide



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC v2: news item for the 17.0 profiles

2017-10-11 Thread Brian Evans
On 10/11/2017 04:33 PM, Walter Dnes wrote:
> On Wed, Oct 11, 2017 at 12:41:06AM -0400, Walter Dnes wrote
> 
>>   I'm on 6.3.0 on x86, which is currently unstable on *ALL* arches, and
>> "emerge -pv =sys-devel/gcc-6.3.0" shows "(-pie)".
> 
>And x86 32-bit gcc-6.4.0 shows (-pie) as well...
> 
> ==
> 
> [d531][waltdnes][~] ACCEPT_KEYWORDS="~x86" emerge -pv =sys-devel/gcc-6.4.0
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  NS] sys-devel/gcc-6.4.0:6.4.0::gentoo [6.3.0:6.3.0::gentoo] 
> USE="cxx fortran nptl openmp sanitize vtv (-altivec) (-awt) -cilk -debug -doc 
> (-fixed-point) (-gcj) -go -graphite (-hardened) (-jit) (-libssp) -mpx 
> (-multilib) -nls -objc -objc++ -objc-gc -pch -pgo (-pie) -regression-test 
> -ssp -vanilla" 74,379 KiB
> 

It gets forced on with the 17.0 profile.  Did you switch yet?

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs net-im/pyaim-t

2017-10-09 Thread Brian Evans
On 10/9/2017 3:49 PM, Jonas Stein wrote:
> Dear all,
> 
> The following packages are up for grabs:
> 
> net-im/pyaim-t
> 
> after retirement of the proxied maintainer.
> 

AOL Instant Messenger will be retired on Dec 15, 2017.  Last rite this
and any other package that is the sole consumer of that service.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal

2017-09-18 Thread Brian Evans
On 09/18/2017 08:03 PM, Aaron W. Swenson wrote:
> On 2017-09-18 15:09, Paul Varner wrote:
>> In order to upgrade to the new version of gentoolkit, you will need to 
>> resolve
>> the blocks. In many cases, removing app-portage/gentoolkit-dev from the world
>> set will allow Portage to automatically resolve the blockers and remove 
>> gentoolkit-dev. You can remove it from world using the following command.
>>
>> emerge --deselect app-portage/gentoolkit-dev
>>
>> If that fails to work, then unmerge the gentoolkit-dev package with
>>
>> emerge --unmerge app-portage/gentoolkit-dev
>>
> 
> Why not just instruct users to unmerge rather than attempt something
> that may or may not work as a first step?
> 
> The instructions would the be simplified to:
> In order to upgrade to the new version of app-portage/gentoolkit, first
> unmerge app-portage/gentoolkit-dev then emerge app-portage/gentoolkit:
> 
># emerge --unmerge app-portage/gentoolkit-dev
># emerge --ask app-portage/gentoolkit
> 

We shouldn't be telling people to use --unmerge unless it is a last resort.

The preferred way to remove something is with --depclean  so
they get in good habits and do not break their system.

I know this case is a leaf package, so the --deselect and matching
blocker should be good enough IMO.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Last rites: xfce-extra/xfce4-volumed

2017-08-28 Thread Brian Evans
On 08/28/2017 05:15 PM, Ulrich Mueller wrote:
>> On Mon, 28 Aug 2017, Duncan  wrote:
> 
>> Michał Górny posted on Mon, 28 Aug 2017 20:25:54 +0200 as excerpted:
>>> # Michał Górny  (28 Aug 2017)
>>> # Alike xfce4-mixer, relies on gstreamer:0.10 (gstreamer:1.0 removed
>>> # mixer wrappers). Last commit upstream in 2014. PulseAudio users
>>> # can switch to xfce-extra/xfce4-pulseaudio-plugin
>>> # or xfce-extra/xfce4-volumed-pulse.
>>> # Removal in 30 days. Bug #629212.
>>> xfce-extra/xfce4-volumed
> 
>> OK, you singled out pulseaudio users when you mentioned an alternative.
> 
>> What about non-pulseaudio users?
> 
> There are alternatives that seem to work well with xfce and alsa,
> for example media-sound/volumeicon or mediasound/pnmixer.
> 
> Ulrich
> 

There is also media-sound/tudor-volumed if you don't have a mixer with
built-in keybinds.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Revisions for USE flag changes

2017-08-11 Thread Brian Evans
On 08/11/2017 08:59 PM, Michael Orlitzky wrote:
> On 08/11/2017 08:45 PM, Brian Evans wrote:
>>
>> I disagree about removing --newuse and --changed-use from portage.
>> This is not their only use.
>>
>> If you happen to change the effective use system wide, USE= in make.conf
>> for portage, these options scan the entire system for such changes.
>>
> 
> Does --changed-use help there? I can see the argument for --newuse, but
> I thought --changed-use only applied to flags that were added or removed
> to installed packages (which becomes impossible, if we require new
> revisions).
> 

--changed-use (-U)
   Tells emerge to include installed packages where USE flags have
   changed   since  installation.  This  option  also  implies  the
   --selective option. Unlike --newuse,  the  --changed-use  option
   does not trigger reinstallation when flags that the user has not
   enabled are added or removed.

The option is the same as --newuse except it ignores functionality that
you suggest to remove.  You could certainly deprecate one option or the
other if they became the same.  But the core functionality of
system-wide USE changes (by profile or user), needs to be scanned somehow.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Revisions for USE flag changes

2017-08-11 Thread Brian Evans
On 08/11/2017 07:50 PM, Michael Orlitzky wrote:
> == New revisions for USE flag changes ==
> 
> I suggest that in hindsight, we can do better. Suppose we require a new
> revision for every change to IUSE. Then,
> 
>   * We can delete all of the PM code for --changed-use and --newuse and
> friends.
> 
>   * The documentation becomes much simpler: revbump if IUSE changes.
> 
>   * Users can omit --newuse and --changed-use from their lives.
> 
>   * All package managers now handle IUSE changes properly.
> 
>   * emerge runs a bit faster.
> 
> This has none of the downsides of the current approach. Of course, it
> lacks that one benefit -- that you don't have to rename the ebuild when
> you change IUSE. Now I'll try to convince you that the rename and
> associated rebuilds aren't that big of a deal.

I disagree about removing --newuse and --changed-use from portage.
This is not their only use.

If you happen to change the effective use system wide, USE= in make.conf
for portage, these options scan the entire system for such changes.

i.e. 'emerge --changed-use --deep @world'

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last Rites: Several obsolete, broken dev-php/PEAR-* packages

2017-08-08 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org) (08 Aug 2017)
# Old PEAR packages which are not maintained upstream or superseded
# They contain errors which are not easy to maintain with no upstream
# Many also do not have tests to easily find
# incompatibilies with latest versions.
# dev-php-Auth_HTTP has an upstream but relies on PEAR-Auth which does not
# Masked for removal in 30 days
dev-php/PEAR-Auth
dev-php/PEAR-Auth_HTTP
dev-php/PEAR-HTML_Template_IT
dev-php/PEAR-HTML_TreeMenu
dev-php/PEAR-HTTP_Client
dev-php/PEAR-HTTP_Request
dev-php/PEAR-Numbers_Roman
dev-php/PEAR-PEAR_Info
dev-php/PEAR-SOAP
dev-php/PEAR-Services_Amazon
dev-php/PEAR-Services_Weather
dev-php/PEAR-Testing_Selenium
dev-php/PEAR-Translation2



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

2017-07-26 Thread Brian Evans
On 7/25/2017 4:05 AM, Michał Górny wrote:
> Hi, everyone.
> 
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 
> The basic idea is that the GLEP provides basic guidelines for using git,
> and then we write a proper manual on top of it (right now, all the pages
> about it end up as a mix of requirements and a partial git manual).
> 
> What do you think about it? Is there anything else that needs being
> covered?
> 
> Copy of the markup for inline comments follows.

[cut]
> ===Commit messages===
> A standard git commit message consists of three parts, in order: a
> summary line, an optional body and an optional set of tags. The parts
> are separated by a single empty line.
> 
[cut]
> The tag part is included in the full commit log as an extension to the
> body. It consists of one or more lines consisting of key, followed by a
> colon and a space, followed by value. Git does not enforce any
> standardization of the keys, and the tag format is ''not'' meant for
> machine processing.
> 
> A few tags of common use are:
> * user-related tags:
> ** Acked-by: Full Name  — commit approved
> by another person (usually without detailed review),
> ** Reported-by: Full Name ,
> ** Reviewed-by: Full Name  — usually
> indicates full review,
> ** Signed-off-by: Full Name  — DCO
> approval (not used in Gentoo right now),
> ** Suggested-by: Full Name , 
> ** Tested-by: Full Name .
> * commit-related tags:
> ** Fixes: commit-id (commit message) — to indicate fixing a
> previous commit,
> ** Reverts: commit-id (commit message) — to indicate
> reverting a previous commit,
> * bug tracker-related tags:
> ** Bug: https://bugs.gentoo.org/NN; — to
> reference a bug,
> ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request,
> ** Fixes: https://bugs.gentoo.org/NN; —
> to indicate a fixed bug,
> * package manager tags:
> ** Package-Manager: … — used by repoman to indicate Portage
> version,
> ** RepoMan-Options: … — used by repoman to indicate repoman
> options.
> 
> The bug tracker-related tags can be used to extend the body message.
> However, they should be skipped if the bug number is already provided in
> the summary and there is no explicit body.
> 

My concern on these tags is that some evangelist will come along and
demand that they always be included with every commit since they exist
in a GLEP.  They add very little value, IMO, and I doubt they will ever
be parsed or ever read.

I would object less if the committing tool, i.e. repoman, would provide
easy switches for common cases for uniformity.  I foresee more work on
my part to remember such lines and would have to look up the "current
syntax" as it goes through debate many times over as it already has.
(Both in the past and in this thread again).

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Sets vs Meta ebuilds

2017-07-10 Thread Brian Evans
On 7/10/2017 2:59 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 00:43:11 -0400
> "William L. Thomson Jr."  wrote:
> I think portage should also warn on removing packages that came in from
> another. If you are removing any dependency of another package.
> 
> 

Portage will refuse to remove a package if it is a dependency, but you
have to change the invocation to be 'emerge -avc '.

Then it will be very verbose if something needs said package.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Sets vs Meta ebuilds

2017-07-07 Thread Brian Evans
On 7/7/2017 12:57 PM, Brian Evans wrote:
> On 7/7/2017 12:32 PM, William L. Thomson Jr. wrote:
> 
>> I think sets have benefits over meta packages. This was the most
>> comprehensive document on sets, benefits, uses, etc. Other than the
>> general docs on the wiki.
>> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
>>
>> I  would really like to be able to use package sets in profiles. I
>> think of use and benefit to others as well.
>>
> 
> Beware of sets.. if you put toolchain packages in a set and later do
> 'emerge --unmerge @custom-set' , emerge will happily destroy your toolchain.
> 
> Brian
> 

or worse dev-lang/python

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Sets vs Meta ebuilds

2017-07-07 Thread Brian Evans
On 7/7/2017 12:32 PM, William L. Thomson Jr. wrote:

> I think sets have benefits over meta packages. This was the most
> comprehensive document on sets, benefits, uses, etc. Other than the
> general docs on the wiki.
> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
> 
> I  would really like to be able to use package sets in profiles. I
> think of use and benefit to others as well.
> 

Beware of sets.. if you put toolchain packages in a set and later do
'emerge --unmerge @custom-set' , emerge will happily destroy your toolchain.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Removal of libmysqlclient_r.so

2017-05-30 Thread Brian Evans
My fellow developers,

I want to give fair warning that libmysqlclient_r.so will be
disappearing with MariaDB 10.2 and MySQL 5.7.

For the past few versions, the functionality that was in
libmysqlclient_r was merged into libmysqlclient.  For a few years now,
upstream kept a compatibility symlink in place but no longer.
This is not my choice, but an upstream decision.

Packages using mysql_config or mariadb_config to query the libs will be
fine.

Thank you.

Brian Evans
MySQL Lead



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] php-pear-lib-r1.eclass Deprecation and removal notice

2017-05-27 Thread Brian Evans
I have just marked php-pear-lib-r1 as DEAD in the Gentoo repository.

This eclass has a call in pkg_setup which many packages used ${FILESDIR}
to reference a file needed to add a channel to php's pear system.

Recently, changes in portage causes all packages depending on it in this
way to fail as ${FILESDIR} is not defined in pkg_setup.

I've moved all known in-repo packages to a new eclass and here by
announce this eclass to be removed in 30 days.

Thank you.





signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] USE flag name collision in use.local.desc "graphite"

2017-04-30 Thread Brian Evans
On 04/30/2017 06:36 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, L, 29.04.2017 kell 22:32, kirjutas Walter Dnes:
>>   Is it considered a reportable bug?
>>
>> [i660][waltdnes][~] grep :graphite /usr/portage/profiles/*.desc
>> /usr/portage/profiles/use.local.desc:dev-lang/gnat-gpl:graphite - Add
>> support for the framework for loop optimizations based on a
>> polyhedral intermediate representation
>> /usr/portage/profiles/use.local.desc:media-libs/harfbuzz:graphite -
>> Use graphite to render complex non-Roman writing systems
>> /usr/portage/profiles/use.local.desc:sys-devel/gcc:graphite - Add
>> support for the framework for loop optimizations based on a
>> polyhedral intermediate representation
>>
>>   The "graphite" USE flag means something entirely different for
>> harfbuzz, i.e. build media-libs/harfbuzz against media-gfx/graphite2
> 
> That's why they are local. You aren't supposed to go and enable those
> flags globally usually.

This statement is a big confusion for users and is a pet peeve of mine.

There is no such thing as calling a USE flag "local" or "global" except
for where the description lies.

If they want to enable a flag to apply system-wide, then it does not
matter where the description is. To users, a USE flag is a USE flag.

Brian




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New eclass php-pear-r2

2017-02-28 Thread Brian Evans
Revision 2 with comments taken into account
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: php-pear-r2.eclass
# @MAINTAINER:
# Gentoo PHP Team <php-b...@gentoo.org>
# @AUTHOR:
# Author: Brian Evans <grkni...@gentoo.org>
# @BLURB: Provides means for an easy installation of PEAR packages.
# @DESCRIPTION:
# This eclass provides means for an easy installation of PEAR packages.
# For more information on PEAR, see https://pear.php.net/
# Note that this eclass doesn't handle dependencies of PEAR packages
# on purpose; please use (R)DEPEND to define them correctly!

EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm

case "${EAPI:-0}" in
6)
;;
*)
die "Unsupported EAPI=${EAPI} for ${ECLASS}"
;;
esac

RDEPEND=">=dev-php/pear-1.8.1"

# @ECLASS-VARIABLE: PHP_PEAR_PKG_NAME
# @DESCRIPTION:
# Set this if the PEAR package name differs from ${PN/PEAR-/}
# (generally shouldn't be the case).
: ${PHP_PEAR_PKG_NAME:=${PN/PEAR-/}}

# @ECLASS-VARIABLE: PEAR_PV
# @DESCRIPTION:
# Set in ebuild if the ${PV} breaks SRC_URI for alpha/beta/rc versions
: ${PEAR_PV:=${PV}}

PEAR_P="${PHP_PEAR_PKG_NAME}-${PEAR_PV}"

# @ECLASS-VARIABLE: PHP_PEAR_DOMAIN
# @DESCRIPTION:
# Set in ebuild to the domain name of the channel if not pear.php.net
: ${PHP_PEAR_DOMAIN:=pear.php.net}

# @ECLASS-VARIABLE: PHP_PEAR_CHANNEL
# @DESCRIPTION:
# Set in ebuild to the path of channel.xml file which is necessary for
# 3rd party pear channels (besides pear.php.net) to be added to PEAR
# Default is unset to do nothing

# set default SRC_URI for pear.php.net packages
if [[ "${PHP_PEAR_DOMAIN}" == "pear.php.net" ]] ; then
SRC_URI="https://pear.php.net/get/${PEAR_P}.tgz;
fi

: ${HOMEPAGE:=https://${PHP_PEAR_DOMAIN}/package/${PHP_PEAR_PKG_NAME}}

S="${WORKDIR}/${PEAR_P}"

# @FUNCTION php-pear-r2_install_packagexml
# @DESCRIPTION:
# Copies the package2.xml or package.xml file and, optionally, the channel.xml
# file to a Gentoo-specific location so that pkg_postinst can install the 
package
# to the local PEAR database
php-pear-r2_install_packagexml() {
insinto /usr/share/php/.packagexml
if [[ -f "${WORKDIR}/package2.xml" ]] ; then
newins "${WORKDIR}/package2.xml" "${PEAR_P}.xml"
elif [[ -f "${WORKDIR}/package.xml" ]] ; then
newins "${WORKDIR}/package.xml" "${PEAR_P}.xml"
fi

if [[ -f "${PHP_PEAR_CHANNEL}" ]] ; then
newins "${PHP_PEAR_CHANNEL}" "${PEAR_P}-channel.xml"
fi
}

# @FUNCTION: php-pear-r2_src_install
# @DESCRIPTION:
# Takes care of standard install for PEAR packages.
# Override src_install if the package installs more than 
"${PHP_PEAR_PKG_NAME}.php"
# or "${PHP_PEAR_PKG_NAME%%_*}/" as a directory
php-pear-r2_src_install() {
insinto /usr/share/php
[[ -f "${PHP_PEAR_PKG_NAME}.php" ]] && doins "${PHP_PEAR_PKG_NAME}.php"
[[ -d "${PHP_PEAR_PKG_NAME%%_*}" ]] && doins -r 
"${PHP_PEAR_PKG_NAME%%_*}/"
php-pear-r2_install_packagexml
einstalldocs
}

# @FUNCTION: php-pear-r2_pkg_postinst
# @DESCRIPTION:
# Register package with the local PEAR database.
php-pear-r2_pkg_postinst() {
# Add unknown channels
if [[ -f "${EROOT}usr/share/php/.packagexml/${PEAR_P}-channel.xml" ]] ; 
then
if "${EROOT}usr/bin/peardev" channel-info "${PHP_PEAR_DOMAIN}" 
&> /dev/null; then
"${EROOT}usr/bin/peardev" channel-add \

"${EROOT}usr/share/php/.packagexml/${PEAR_PN}-channel.xml" \
|| einfo "Ignore any errors about existing 
channels"
fi
fi

# Register the package from the package{,2}.xml file
# It is not critical to complete so only warn on failure
if [[ -f "${EROOT}usr/share/php/.packagexml/${PEAR_P}.xml" ]] ; then
"${EROOT}usr/bin/peardev" install -nrO --force \
"${EROOT}usr/share/php/.packagexml/${PEAR_P}.xml" 2> 
/dev/null \
|| ewarn "Failed to insert package into local PEAR 
database"
fi
}

# @FUNCTION: php-pear-r2_pkg_postrm
# @DESCRIPTION:
# Deregister package from the local PEAR database
php-pear-r2_pkg_postrm() {
# Uninstall known dependency
"${EROOT}usr/bin/peardev" uninstall -nrO 
"${PHP_PEAR_DOMAIN}/${PHP_PEAR_PKG_NAME}"
}


signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] New eclass php-pear-r2

2017-02-28 Thread Brian Evans
Please find an updated PEAR eclass for consideration.
This is only meant to be used by the PHP team for packages installed by
PHP's PEAR system.

Thank you.

Brian
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

# @ECLASS: php-pear-r2.eclass
# @MAINTAINER:
# Gentoo PHP Team <php-b...@gentoo.org>
# @AUTHOR:
# Author: Brian Evans <grkni...@gentoo.org>
# @BLURB: Provides means for an easy installation of PEAR packages.
# @DESCRIPTION:
# This eclass provides means for an easy installation of PEAR packages.
# For more information on PEAR, see https://pear.php.net/
# Note that this eclass doesn't handle dependencies of PEAR packages
# on purpose; please use (R)DEPEND to define them correctly!

EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm

case "${EAPI:-0}" in
6)
;;
*)
die "Unsupported EAPI=${EAPI} for ${ECLASS}"
;;
esac

RDEPEND=">=dev-php/pear-1.8.1"

# @ECLASS-VARIABLE: PHP_PEAR_PKG_NAME
# @DESCRIPTION:
# Set this if the PEAR package name differs from ${PN/PEAR-/}
# (generally shouldn't be the case).
[[ -z "${PHP_PEAR_PKG_NAME}" ]] && PHP_PEAR_PKG_NAME="${PN/PEAR-/}"

# @ECLASS-VARIABLE: PEAR_PV
# @DESCRIPTION:
# Set in ebuild if the ${PV} breaks SRC_URI for alpha/beta/rc versions
: ${PEAR_PV:=${PV}}

PEAR_PN="${PHP_PEAR_PKG_NAME}-${PEAR_PV}"

# @ECLASS-VARIABLE: PHP_PEAR_URI
# @DESCRIPTION:
# Set in ebuild to the domain name of the channel if not pear.php.net
: ${PHP_PEAR_URI:=pear.php.net}

: ${SRC_URI:=https://${PHP_PEAR_URI}/get/${PEAR_PN}.tgz}
: ${HOMEPAGE:=https://${PHP_PEAR_URI}/package/${PHP_PEAR_PKG_NAME}}

S="${WORKDIR}/${PEAR_PN}"

# @FUNCTION php-pear-r2_install_packagexml
# @DESCRIPTION:
# Copies the package{,2}.xml file and, optionally, the channel.xml file
# to a hidden directory so that pkg_postinst can install the package
# to the local PEAR database
php-pear-r2_install_packagexml() {
insinto /usr/share/php/.packagexml
if [[ -f "${WORKDIR}/package2.xml" ]] ; then
newins "${WORKDIR}/package2.xml" "${PEAR_PN}.xml"
elif [[ -f "${WORKDIR}/package.xml" ]] ; then
newins "${WORKDIR}/package.xml" "${PEAR_PN}.xml"
fi

if [[ -f "${PHP_PEAR_CHANNEL}" ]] ; then
newins "${PHP_PEAR_CHANNEL}" "${PEAR_PN}-channel.xml"
fi
}

# @FUNCTION: php-pear-r2_src_install
# @DESCRIPTION:
# Takes care of standard install for PEAR packages.
# Override src_install if the package installs more than 
"${PHP_PEAR_PKG_NAME}.php"
# or "${PHP_PEAR_PKG_NAME%%_*}/" as a directory
php-pear-r2_src_install() {
insinto /usr/share/php
[[ -f "${PHP_PEAR_PKG_NAME}.php" ]] && doins "${PHP_PEAR_PKG_NAME}.php"
[[ -d "${PHP_PEAR_PKG_NAME%%_*}" ]] && doins -r 
"${PHP_PEAR_PKG_NAME%%_*}/"
php-pear-r2_install_packagexml
einstalldocs
}

# @FUNCTION: php-pear-r2_pkg_postinst
# @DESCRIPTION:
# Register package with the local PEAR database.
php-pear-r2_pkg_postinst() {
# Add unknown channels
if [[ -f "${EROOT}usr/share/php/.packagexml/${PEAR_PN}-channel.xml" ]] 
; then
"${EROOT}usr/bin/peardev" channel-info "${PHP_PEAR_URI}" &> 
/dev/null
if [[ "$?x" != "0x" ]] ; then
"${EROOT}usr/bin/peardev" channel-add \

"${EROOT}usr/share/php/.packagexml/${PEAR_PN}-channel.xml" \
|| einfo "Ignore any errors about existing 
channels"
fi
fi

# Register the package from the package{,2}.xml file
# It is not critical to complete so only warn on failure
if [[ -f "${EROOT}usr/share/php/.packagexml/${PEAR_PN}.xml" ]] ; then
"${EROOT}usr/bin/peardev" install -nrO --force \
"${EROOT}usr/share/php/.packagexml/${PEAR_PN}.xml" 2> 
/dev/null \
|| ewarn "Failed to insert package into local PEAR 
database"
fi
}

# @FUNCTION: php-pear-r2_pkg_postrm
# @DESCRIPTION:
# Deregister package from the local PEAR database
php-pear-r2_pkg_postrm() {
# Uninstall known dependency
"${EROOT}usr/bin/peardev" uninstall -nrO 
"${PHP_PEAR_URI}/${PHP_PEAR_PKG_NAME}"
}


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Suggested sync method/Portage config for devs on ~arch?

2017-02-28 Thread Brian Evans
On 2/28/2017 5:14 AM, Thomas Deutschmann wrote:
> On 2017-02-28 10:52, James Le Cuirot wrote:
>> I use hasufell's repo too. I'm surprised we haven't made it more
>> official.
> 
> The public Gentoo git mirror is
> 
>   https://github.com/gentoo-mirror/gentoo
> 
> This git mirror includes pre-generated metadata. No need for any
> hack/additional step.
> 
> Devs maybe want to switch branch from stable (default branch) to master
> branch (stable branch has CI coverage and will only sync if everything
> is fine).
> 
> 

People, developers and users, may want to consider some facts when
cloning from that repository. (Please read the entire explanation below
before commenting.)

Git does a very poor job of data deduplication by default in this
repository and repacks are necessary to keep it sane.  Unfortunately,
there doesn't seem to be a way to trigger GitHub to do so.

This is not any developer's fault.  Simply a limitation or possible flaw
in git itself.

Shallow clones (--depth=1) are just fine.

Full clones are ridiculous in size because of needing a full repack
periodically.  GitHub even hung up on me for a full clone after about a
GiB downloaded. Infra's copy has been/is being repacked so the sizes are
not so bad.

If you don't need the full history, then this is very quick and small
footprint.
End users typically won't care but developers may.

Brian

Evidence:

Github...
> grknight@akame ~ $ git clone --depth=1 
> https://github.com/gentoo-mirror/gentoo.git
> Cloning into 'gentoo'...
> remote: Counting objects: 155625, done.
> remote: Compressing objects: 100% (128104/128104), done.
> remote: Total 155625 (delta 31631), reused 75529 (delta 26281), pack-reused 0
> Receiving objects: 100% (155625/155625), 80.36 MiB | 2.35 MiB/s, done.
> Resolving deltas: 100% (31631/31631), done.
> Checking out files: 100% (141011/141011), done.
> grknight@akame ~ $ du -sh gentoo/.git
> 101Mgentoo/.git
> grknight@akame ~ $ rm -fr gentoo
> grknight@akame ~ $ git clone https://github.com/gentoo-mirror/gentoo.git
> Cloning into 'gentoo'...
> remote: Counting objects: 3668662, done.
> remote: Compressing objects: 100% (677/677), done.
> error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull 
> function.
> fatal: The remote end hung up unexpectedly
> fatal: early EOF
> fatal: index-pack failed
> grknight@akame ~ $ rm -fr gentoo
> grknight@akame ~ $ git clone https://github.com/gentoo-mirror/gentoo.git
> Cloning into 'gentoo'...
> remote: Counting objects: 3668680, done.
> remote: Compressing objects: 100% (694/694), done.
> Receiving objects: 100% (3668680/3668680), 1.27 GiB | 2.19 MiB/s, done.
> remote: Total 3668680 (delta 326), reused 0 (delta 0), pack-reused 3667973
> Resolving deltas: 100% (3144716/3144716), done.
> Checking out files: 100% (141015/141015), done.
> grknight@akame ~ $ du -sh gentoo/.git
> 1.4Ggentoo/.git


Infra..
> grknight@akame ~ $ git clone --depth=1 
> https://anongit.gentoo.org/git/repo/sync/gentoo.git
> Cloning into 'gentoo'...
> remote: Counting objects: 155630, done.
> remote: Compressing objects: 100% (138925/138925), done.
> remote: Total 155630 (delta 44790), reused 68200 (delta 15465)
> Receiving objects: 100% (155630/155630), 75.28 MiB | 1.88 MiB/s, done.
> Resolving deltas: 100% (44790/44790), done.
> Checking out files: 100% (141015/141015), done.
> grknight@akame ~ $ du -sh gentoo/.git
> 96M gentoo/.git
> grknight@akame ~ $ rm -fr gentoo
> grknight@akame ~ $ git clone 
> https://anongit.gentoo.org/git/repo/sync/gentoo.git
> Cloning into 'gentoo'...
> remote: Counting objects: 3259105, done.
> remote: Compressing objects: 100% (472991/472991), done.
> remote: Total 3259105 (delta 2818449), reused 3193051 (delta 2758678)
> Receiving objects: 100% (3259105/3259105), 556.04 MiB | 1.02 MiB/s, done.
> Resolving deltas: 100% (2818449/2818449), done.
> Checking out files: 100% (141015/141015), done.
> grknight@akame ~ $ du -sh gentoo/.git
> 659Mgentoo/.git




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs due to retirement

2017-01-02 Thread Brian Evans
On 01/01/2017 12:16 PM, Lars Wendler wrote:
> Hi Thomas,
> 
> On Sat, 31 Dec 2016 22:54:28 +0100 Thomas Kahle wrote:
> 
>> Hi,
>>
>> I will retire, so here are my remaining packages. 
> 
> Sad day seeing another dev leaving :-(
> 
>> net-misc/wicd
> 
> I can take this one if nobody else is interested in it.

IMO, this one should be given last-rites as upstream is dead and it
heavily depends on wireless-tools and WEXT.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-php/ffmpeg-php

2016-12-09 Thread Brian Evans
# Brian Evans <grkni...@gentoo.org> (09 Dec 2016)
# Masked for removal, wrt bug 602164.
# See https://github.com/PHP-FFMpeg/PHP-FFMpeg for a code based
# replacement
dev-php/ffmpeg-php



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rsync.gentoo.org rsync modules: ChangeLogs dropped from gentoo-portage

2016-11-16 Thread Brian Evans
On 11/16/2016 10:02 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 16 Nov 2016, Michael Mol wrote:
> 
>> On 10/30/2016, in message <3d0d574c-63b1-cf2d-633f-d18495202...@gentoo.org>, 
>> Brian Evans wrote:
> 
>>> We just had a user in #gentoo report that app-dicts/myspell-en had a
>>> mismatched ChangeLog size in Manifest that blocked him from installing
>>> software.
> 
>>> So this does not seem to be treated as a warning for a MISC type.
> 
> The question is if stable Portage of one year ago (that would be
> version 2.2.20, I believe) treats this correctly. If it doesn't,
> the upgrade path is broken.
> 
> Ulrich
> 

Non-existent MISC files are ignored.
But when they do exist, they are checked like every other file which may
be a misinterpretation of the GLEP.

Removing the ChangeLogs will not break portage even if they still exist
in the Manifest.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rsync.gentoo.org rsync modules: gentoo-repo-changelog added, gentoo-x86-portage & gentoo-sec discontinued.

2016-10-31 Thread Brian Evans
On 10/30/2016 4:39 PM, Robin H. Johnson wrote:
> On Sun, Oct 30, 2016 at 09:47:36PM +1300, Kent Fredric wrote:
>> On Sun, 30 Oct 2016 02:54:17 +
>> "Robin H. Johnson"  wrote:
>>
>>> They may or may not still be referenced
>>> by the thick Manifests.
>> Surely they should not continue to be referenced, as being referenced
>> but not present would cause the entire package to be deemed invalid due
>> to failing integrity checks.
> ChangeLogs are supposed to be of Manifest2 type MISC, for which the
> absence or mismatch should be non-fatal (if the file is present on disk,
> and in Manifest, but does not match, display a warning only).
> 

We just had a user in #gentoo report that app-dicts/myspell-en had a
mismatched ChangeLog size in Manifest that blocked him from installing
software.

So this does not seem to be treated as a warning for a MISC type.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package file name requirement for binary ebuilds

2016-10-17 Thread Brian Evans
On 10/14/2016 1:36 PM, Mike Gilbert wrote:
> On Fri, Oct 14, 2016 at 1:05 PM, William L. Thomson Jr.
>  wrote:
>> Problem
>> 1. There does not seem to be any file name requirement for binary packages.
>> 2. There are binary packages that end in -bin, which is good. However it is
>> not clear if that is an upstream 3rd party binary. Or a binary made by
>> compiling a large Gentoo package, by a Gentoo dev or contributor on a Gentoo
>> system. Like icedtea-bin for example, and likely some others.
>>
>> Suggested Solution
>> 1. Require 3rd party binary package names be suffixed with -bin. Many are
>> already named that thus require no change. A few package missing such may 
>> need
>> to be renamed to such.
>> 2. Require Gentoo made binaries have some other preffix, maybe -gbin. To
>> represent not only is it a bin, but it is a Gentoo self made binary. Much 
>> less
>> of these but would require some package renames.
>>
>> It is some what a moot problem, but I think it would be good to adopt such or
>> similar requirement, maybe in the PMS.
> 
> I see no reason to specify a file naming convention like this in PMS.
> This isn't really a technical problem, but rather a Gentoo policy
> issue. Other repos/distros should be free to call their ebuilds
> whatever they like.
> 
> Also, I don't think a file naming convention is the best way to
> implement this. I would suggest introducing a new piece of metadata:
> either an element in metadata.xml, or a global variable in ebuilds.
> 

+1 for metadata.xml

For anyone who cares, it is easily parsed.

Brian



[gentoo-dev] Changes coming to libmysqlclient.so providers

2016-09-28 Thread Brian Evans
My fellow developers,

I've previously asked that packages which link to libmysqlclient.so be
moved to virtual/libmysqlclient as a {,R}DEPEND.  There are some which
have done so but many have not.

There are major changes coming with MariaDB 10.2 and MySQL 5.7 so either
the devs will have to do it or users will have to rely on either
revdep-rebuild or @preserved-rebuild.

MySQL 5.7 is moving to libmysqlclient.so.20 and MariaDB is providing
libmariadbclient.so (LGPL).

For packages that still depend on virtual/mysql but really only need to
link to libmysqlclient.so, change to virtual/libmysqlclient:= to help
users with rebuilds.

A few packages, dev-db/myodbc comes to mind, will need certain slots of
virtual/libmysqlclient that I have yet to finalize.

In addition, some packages will break if they depend on private APIs
exposed in previous libmysqlclient.so's as upstreams are tightening down.

Thank you,

Brian
MySQL Team Lead




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Removal of depend.php eclass

2016-08-15 Thread Brian Evans
As was previously announced on 2015-06-24 [1], depend.php.eclass was
deprecated.

The tree is now clear of its use.

The eclass will be removed in 30 days.

All overlays are advised to update their ebuilds at this time.

Thank you,

Brian Evans

[1]
https://archives.gentoo.org/gentoo-dev-announce/message/cdf630c469a533e5f21c6df74b2de9cc



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-db/mysql/

2016-04-18 Thread Brian Evans
On 4/18/2016 1:38 PM, Michał Górny wrote:
> On Mon, 18 Apr 2016 13:31:08 -0400
> Brian Evans <grkni...@gentoo.org> wrote:
> 
>> The point of this entry is to assign bugs when a certain condition
>> exists.  The person/project is not responsible otherwise.
> 
> It's GLEP 68. restrict="" must be EAPI 0 which means no USE
> dependencies.
> 

This defeats the purpose of how a number packages were using this
field.. so we go backwards in time and remove all such maintainers.

Sounds like a wonderfully thought out plan.

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-db/mysql/

2016-04-18 Thread Brian Evans
On 4/18/2016 11:34 AM, Michał Górny wrote:
> On Mon, 18 Apr 2016 08:13:33 + (UTC)
> "Patrice Clement"  wrote:
> 
>> commit: 912a9f1e2ed5717a7669861b4978dfaf868c5ae7
>> Author: Patrice Clement  gentoo  org>
>> AuthorDate: Mon Apr 18 06:33:40 2016 +
>> Commit: Patrice Clement  gentoo  org>
>> CommitDate: Mon Apr 18 07:57:59 2016 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=912a9f1e
>>
>> dev-db/mysql: Fix metadata.xml file.
>>
>> Package-Manager: portage-2.2.26
>>
>>  dev-db/mysql/metadata.xml | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/dev-db/mysql/metadata.xml b/dev-db/mysql/metadata.xml
>> index 422ac80..538f21e 100644
>> --- a/dev-db/mysql/metadata.xml
>> +++ b/dev-db/mysql/metadata.xml
>> @@ -1,11 +1,11 @@
>>  
>>  http://www.gentoo.org/dtd/metadata.dtd;>
>>  
>> -

Why was the restrict removed?

GLEP 67 does not remove the restrictions either:

"The package metadata description is fully self-sufficient for bug
assignment. The order in which  elements occur (after
applying restrictions) indicates the chain of responsibility. A bug is
assigned to the first maintainer, while all the remaining maintainers
are CC-ed."

The point of this entry is to assign bugs when a certain condition
exists.  The person/project is not responsible otherwise.

Brian



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] MySQL virtuals

2016-03-11 Thread Brian Evans
The MySQL team has two virtuals now for 7 months, virtual/mysql and
virtual/libmysqlclient.

From now on, virtual/mysql is to be used for a local server install,
including embedded servers (libmysqld.so).  virtual/mysql-5.6-r8 begins
to enforce this.

virtual/libmysqlclient is for linking to the client libraries and will
track the library changes in a subslot.  Use this when you only need to
link to libmysqlclient.so and don't necessarily need the server install
to be local.

Please adjust any packages as you see fit while doing maintenance.

Brian Evans
MySQL Lead



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] New project: MySQL

2016-01-06 Thread Brian Evans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In preparation for the implementation of GLEP 67, I am announcing the
MySQL project [1], which will replace the old mysql herd.

[1] https://wiki.gentoo.org/wiki/Project:MySQL
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWjUIRAAoJENH3ge/59KO2QtoP/3ByHgy9cBR/6o+7VqfOWYQg
gOvMy6uCPOAT8YrQg06Q8PHs2unpzwpL0QQ+PJTtSHSegyU7MADn9vpVUYub4ntH
HXS9GcoLKT6b4V7ghsOdtAeC87Tg7A2wxEpkag9Jl7ZRLJTXhXu4ldL385YvpHmd
8Qd0E8TpaEqX2fdzTQUzSrl4PXLKkrV228t8TcRXp66D6IUZBUV7vKA1u90DTjhX
p2Pi1LeIHK01Crw67vCKnfa6FwOuTwuGjBnYlb35HIC+ELfPocLyKR/46ZK8wWOD
8BVng/MZ5QD9IiPUsZEcQyGcRu0PVYdBHCoIiBDXU5yVc4Fidzu57Ga8je6dxDNd
QExCZSPMRJyhAhe3xB8DoV6PeL/F4QaenBPEiMjD3jKmy0Hn6NwQfDuW8a8NhJwh
FIEGUWPKAlHDWBplVNHkvPKsXDj6qx4ZfhpHYeW/qmCfuHRatYvh1C5ArenJ2iTi
2cmqzLw4NJ3DRh1FeXuHTFSTZhZeymfhaUad3UofZRk/FF98elt4Uh1BG8i2YGHn
3Krmpo4PzhjMpvrsEgabuAD86Yv7oFa3N/3hD6GgUuTPfIFnpPCbhBIuDQhuR5jw
z3wlNnqu+7LjJxaU4+050V8DeDnhgCRjxxsn6Mihic9u1C/fySkF+/08xt8HQmwl
uvoyLs2PBf07NAHRloCv
=mf1n
-END PGP SIGNATURE-



Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Brian Evans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/4/2016 3:41 AM, Kristian Fiskerstrand wrote:
> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>> Hi!
> 
> 
>> Better late then never.  Posting 72 hours from now the earliest
>> as advised by GLEP 42.  Feedback welcome as usual.
> 
> Do you have any timeline in place for the change happening in tree
> (in particular for stable users).
> 
> 
>> Without updating APACHE2_OPTS, websites could end up serving PHP
>>  code (include configuration files with passwords) unprocessed to
>>  website visitors!
> 
> 
> Such a change should really be avoided if possible. Would it be 
> possible to have a conditional approach where either one can be
> used, or maybe set the new variable/defin if the old one is used?
> 
> 

The problem is really two-fold with the new eselect-php.

For future compatibility (to not have this happen again with say
PHP8), the PHP team changed the symlink created by eselect to be
libphp.so instead of the current libphp${MAJOR}.so.

The user must also reselect with `eselect php set X`, even for the
current PHP versions and not just 7.

mjo explored the option of "Define PHP" but
that is apache-2.4+ only.

If we wanted a "compatibility" layer, it would be the same section
repeated until 2.4 was the only version available.  That might confuse
users even more.

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWioraAAoJENH3ge/59KO2wNUQAKThJz1QBjOvOmi0ClluVxt8
Lt0fbibQXIgZScJy5zqeOwX3EAUDqBST8sonNhJ8uQT4qbU8gwdYK6vhoDbJS0sX
oNzbdwxumSwNBsi4UCl/D0Dj+XefgIyvmgGBZ0RA8t0x8Ls3uQB6DWI1f36Z3wAs
ULqJc38+d1e5pmNu3jpc5tvG2ybvaVVGbWmNiOI8rafFV12KIsRMDHdDCG4DpkQD
bmWLYTv44Nt5nSY2wmLQQAV57kB2PsaaT0qlQciVhKiqOUA+qlmI0dtM3LLSNitK
dqKWNj7WTQFBM1SLHXD0s4CQk9XhFB9E07zelcB5zuC9XeYj1mbrn9aEtfl5lfVs
hHHJQ97MG3u/XwPTHY04J6wfoaQW4dwaQd74Pz48qJ2DqSW9HV8UTS2enF5cuZok
mFfd+xexHvcz45jyz83BtXM4mRWdHBDdy/3fYEvN12wVgU4hQcjDTKKPwpO3Btsb
uyCar+SgoHoRIEQhfDytnT0Idte2GifCysPq7hG12j+efwT7pt0XXk+TZQaH/opZ
FWRzOvjXZXd41M3RQ7H5D+KXrKV3uY4mE41rceEUXrw9PQrueg6Cw5ujK/opawrv
a8qonCtx7LZrEzYLagCYEBDPdgvxHWzIBb0vdgYoRVzSRwoJiAA66dbRuqC7s34G
JM84VqrtPsaCktCq6vw3
=/gh0
-END PGP SIGNATURE-



Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

2016-01-04 Thread Brian Evans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/4/2016 11:43 AM, Michael Orlitzky wrote:
> On 01/04/2016 11:11 AM, Peter Stuge wrote:
>> 
>> So pkg_postinst for >=eselect-php-0.8.1 should say something,
>> but ideally also the invocation - but I don't know if eselect-php
>> is also code or only data managed by eselect?
> 
> The pkg_postinst is already there. The eselect-php routines are
> bash code so theoretically we can do anything we want. How do
> people feel about making eselect-php spit out a warning every time
> the apache2 module is messed with?

Perhaps grep for -DPHP5 or if -DPHP is missing in the conf.d and shout
then as part of the "eselect php set apache2 X"?

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWiqoTAAoJENH3ge/59KO2XRUP/RFybVPuCNtCDEPclsKWp5AI
rvejArURHwk8hu+OjITLb/0UxYM5VwXN9fOrSkxJ3lsVErNlxfeaLc0UYYh/1qnd
WeofmCq7yx0enOe0+szcY877reca5yfPzPs3ChB+a4+PpVAIuD7quL0lcuhs/NMJ
S9Hoex5mOmmd82jeXdZlvZZzLHxLhsnWwTjDQhmnCL9mkHbx2u1+07et7Wdxd8Gu
Td4O9tiAvp/5KQ3Dmw2P2BQPBbZc0EYqGG/Aghw02dDHp+jq5snVRXCdg/z1L61j
VXPblbNBRY9wA96k0vu6aqGRWGuj66rBHcF3DH8A9+o0LY/8eh9v56n7UGg2LfE8
5GEgfT4yY7d5DYEikWKLc56iOy754auh0UbXC+5IaAK8PfIOcMBFG1AgvEqZY+VU
pXBF7yh1QxaAtsYBjKX8X+DuCr9549vjSsMKtUFN+mCz1cLi1KX9OxtCvVQMJUnM
zx5mK8JNFoKlA/kINERsa//swICDgJ2aN4GX64YV+tnfsrZrM1YSJxHIjiEE7Q1m
Pd3v/0CFMra5snYEMdk8qoYQ7ITQdmsM0vM93OgqBYmaNrEZlNG5T+seMpPxv+lD
BhT8R7W2mDqKShljjm31nzp4FG/30z8DymeBn+JVWxHbdy5IqUlaYa5egpWk1vip
qw0h5uqKkkv6BKwXI8sp
=60JD
-END PGP SIGNATURE-



  1   2   >