Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Xavier Miller 

Le 2017-12-10 23:24, Michał Górny a écrit :

I suspect you mean python-exec scripts, because Python modules still
land in /usr/lib64. In which case, everything's fine.


Could be.

Glad to hear the migration is OK.

My systems are migrated, and stable.

Just a last dummy question : why is lib64 migrated to lib64 and lib32 to 
lib, and not the reverse?
We have /lib and /lib64 that were before merged, and /lib32 that was an 
exception and prone to disapear the day blobs will decide to finally go 
64 bits.


Anyway, thank you for the job done!

Xavier.

[gentoo-portage-dev] [PATCH] Handle binary package IUSE_IMPLICIT divergence (bug 640318)

2017-12-10 Thread Zac Medico 
Since profile IUSE_IMPLICIT settings may diverge from those
that a binary package was built with, consider members of
built USE settings to be members of IUSE_EFFECTIVE. Only do
this for EAPIs that support IUSE_EFFECTIVE, since built USE
settings for earlier EAPIs may contain a large number of
irrelevant flags.

Note that the binary package may be remote, so it's only
possible to rely on metadata that is available in the remote
Packages file, and the IUSE_IMPLICIT header in the Packages
file is vulnerable to mutation.

Bug: https://bugs.gentoo.org/640318
---
 pym/_emerge/Package.py| 32 +++
 pym/portage/dbapi/__init__.py |  5 +
 pym/portage/package/ebuild/config.py  |  6 ++
 pym/portage/tests/dbapi/test_fakedbapi.py | 20 +++
 4 files changed, 63 insertions(+)

diff --git a/pym/_emerge/Package.py b/pym/_emerge/Package.py
index 2c1a116ea..e1943175d 100644
--- a/pym/_emerge/Package.py
+++ b/pym/_emerge/Package.py
@@ -3,6 +3,7 @@
 
 from __future__ import unicode_literals
 
+import functools
 import sys
 from itertools import chain
 import warnings
@@ -82,6 +83,10 @@ class Package(Task):
 
if eapi_attrs.iuse_effective:
implicit_match = 
self.root_config.settings._iuse_effective_match
+   if self.built:
+   implicit_match = functools.partial(
+   self._built_iuse_effective_match,
+   implicit_match, 
frozenset(self._metadata['USE'].split()))
else:
implicit_match = 
self.root_config.settings._iuse_implicit_match
usealiases = 
self.root_config.settings._use_manager.getUseAliases(self)
@@ -109,6 +114,33 @@ class Package(Task):
type_name=self.type_name)
self._hash_value = hash(self._hash_key)
 
+   @staticmethod
+   def _built_iuse_effective_match(prof_effective_match, built_use, flag):
+   """
+   For built packages, it is desirable for the built USE setting 
to be
+   independent of the profile's current IUSE_IMPLICIT state, since 
the
+   profile's IUSE_IMPLICT setting may have diverged. Therefore, any
+   member the built USE is setting considered to be a valid member 
of
+   IUSE_EFFECTIVE. Note that the binary package may be remote, so 
it's
+   only possible to rely on metadata that is available in the 
remote
+   Packages file, and the IUSE_IMPLICIT header in the Packages 
file is
+   vulnerable to mutation (see bug 640318).
+
+   This function is only used for EAPIs that support 
IUSE_EFFECTIVE,
+   since built USE settings for earlier EAPIs may contain a large
+   number of irrelevant flags.
+
+   @param prof_effective_match: function to match IUSE_EFFECTIVE
+   values for the current profile
+   @type prof_effective_match: callable
+   @param built_use: built USE setting
+   @type built_use: frozenset
+   @return: True if flag is a valid USE value which may
+   be specified in USE dependencies, False otherwise.
+   @rtype: bool
+   """
+   return flag in built_use or prof_effective_match(flag)
+
@property
def eapi(self):
return self._metadata["EAPI"]
diff --git a/pym/portage/dbapi/__init__.py b/pym/portage/dbapi/__init__.py
index 95053840d..2574b63df 100644
--- a/pym/portage/dbapi/__init__.py
+++ b/pym/portage/dbapi/__init__.py
@@ -5,6 +5,7 @@ from __future__ import unicode_literals
 
 __all__ = ["dbapi"]
 
+import functools
 import re
 
 import portage
@@ -219,6 +220,10 @@ class dbapi(object):
eapi_attrs = _get_eapi_attrs(metadata["EAPI"])
if eapi_attrs.iuse_effective:
iuse_implicit_match = 
self.settings._iuse_effective_match
+   if not self._use_mutable:
+   iuse_implicit_match = functools.partial(
+   Package._built_iuse_effective_match,
+   iuse_implicit_match, 
frozenset(metadata["USE"].split()))
else:
iuse_implicit_match = self.settings._iuse_implicit_match
usealiases = self.settings._use_manager.getUseAliases(pkg)
diff --git a/pym/portage/package/ebuild/config.py 
b/pym/portage/package/ebuild/config.py
index cd2b009aa..d0225a311 100644
--- a/pym/portage/package/ebuild/config.py
+++ b/pym/portage/package/ebuild/config.py
@@ -1693,6 +1693,12 @@ class config(object):
iuse_implicit_match = self._iuse_effective_match
portage_iuse = set(self._iuse_effective)

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-12-10 23:59 UTC

2017-12-10 Thread Robin H. Johnson 
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2017-12-10 23:59 UTC.

Removals:
app-text/jmupdf  20171206-21:42 chewi  1f77848d5e6
app-vim/html520171204-20:04 monsieurp  5f77ef6bb31
dev-tex/texmfind 20171205-10:12 jstein f053dac223f

Additions:
app-backup/cachedir  20171210-16:34 jlec   8392a9c9466
app-portage/unsymlink-lib20171206-08:39 mgorny c2a444eb704
dev-libs/libite  20171203-12:49 kensington 5799c21d2de
dev-libs/libuev  20171203-14:12 kensington 6ee0574f47c
dev-perl/Crypt-OpenSSL-EC20171205-02:19 kentnl e3fec03b93d
dev-perl/Crypt-OpenSSL-ECDSA 20171205-02:26 kentnl 1503f1a20c0
dev-perl/Net-LibIDN2 20171204-01:36 kentnl bea5329b924
dev-python/slackclient   20171205-12:28 mrueg  c9ed21226f5
media-gfx/frogr  20171201-16:18 sobhan a7a73768311
media-libs/openmoiv  20171206-21:50 dilfridge  1a99bc412b0
sys-block/perccli20171206-21:39 zmedico0d76bb0641f
sys-power/uhubctl20171207-16:37 zerochaos  b6e92d84d0b

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
app-text/jmupdf,removed,chewi,20171206-21:42,1f77848d5e6
dev-tex/texmfind,removed,jstein,20171205-10:12,f053dac223f
app-vim/html5,removed,monsieurp,20171204-20:04,5f77ef6bb31
Added Packages:
app-backup/cachedir,added,jlec,20171210-16:34,8392a9c9466
app-portage/unsymlink-lib,added,mgorny,20171206-08:39,c2a444eb704
sys-power/uhubctl,added,zerochaos,20171207-16:37,b6e92d84d0b
dev-libs/libite,added,kensington,20171203-12:49,5799c21d2de
dev-libs/libuev,added,kensington,20171203-14:12,6ee0574f47c
media-libs/openmoiv,added,dilfridge,20171206-21:50,1a99bc412b0
sys-block/perccli,added,zmedico,20171206-21:39,0d76bb0641f
dev-perl/Crypt-OpenSSL-ECDSA,added,kentnl,20171205-02:26,1503f1a20c0
dev-perl/Crypt-OpenSSL-EC,added,kentnl,20171205-02:19,e3fec03b93d
dev-python/slackclient,added,mrueg,20171205-12:28,c9ed21226f5
media-gfx/frogr,added,sobhan,20171201-16:18,a7a73768311
dev-perl/Net-LibIDN2,added,kentnl,20171204-01:36,bea5329b924

Done.

[gentoo-dev] Last rites: app-arch/defluff

2017-12-10 Thread Jonas Stein 
profiles: Last rite app-arch/defluff

Last rite app-arch/defluff, because the download
site blocks certain IP blocks from downloading files, while the package
may not be mirrored.
Masked for removal on 2018-01-12

Bug: https://bugs.gentoo.org/640508

--
Best regards,
Jonas Stein



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Michał Górny 
W dniu nie, 10.12.2017 o godzinie 22∶30 +0100, użytkownik Xavier Miller
napisał:
> 
> Le 10/12/17 à 22:26, Xavier Miller a écrit :
> > Hi,
> > 
> > Le 10/12/17 à 22:13, Mike Gilbert a écrit :
> > > On Sun, Dec 10, 2017 at 3:33 PM, Michał Górny 
> > > wrote:
> > > > > And the list of other ebuilds (cd /var/db/pkg ; grep -l
> > > > > '/lib/' */*/CONTENTS)
> > 
> > ...
> > 
> > ...
> > > > 
> > > > I would need more specific details (some example files at
> > > > least) but the list looks too long. Are you sure you aren't
> > > > seeing some confusion due to old symlinks?
> > > 
> > > He's probably seeing all the systemd units, which live in
> > > [/usr]/lib/systemd.
> > > 
> > 
> > Hi,
> > 
> > Indeed, my list seems too long, the real hits are udev/systemd/rc
> > rules
> > 
> 
> And in /usr/lib, there are the "modules" of python, mono, perl, clang, .
> ..
> 

I suspect you mean python-exec scripts, because Python modules still
land in /usr/lib64. In which case, everything's fine.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Xavier Miller 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Le 10/12/17 à 22:26, Xavier Miller a écrit :
> Hi,
> 
> Le 10/12/17 à 22:13, Mike Gilbert a écrit :
>> On Sun, Dec 10, 2017 at 3:33 PM, Michał Górny 
>> wrote:
 And the list of other ebuilds (cd /var/db/pkg ; grep -l
 '/lib/' */*/CONTENTS)
> ...
> 
> ...
>>> 
>>> I would need more specific details (some example files at
>>> least) but the list looks too long. Are you sure you aren't
>>> seeing some confusion due to old symlinks?
>> 
>> He's probably seeing all the systemd units, which live in
>> [/usr]/lib/systemd.
>> 
> 
> Hi,
> 
> Indeed, my list seems too long, the real hits are udev/systemd/rc
> rules
> 

And in /usr/lib, there are the "modules" of python, mono, perl, clang, .
..

-BEGIN PGP SIGNATURE-

iQFMBAEBCAA2FiEE8zSywsiVAsPFQ0+h4Px2T41mMKgFAlotp18YHHhhdmllcm1p
bGxlckBnZW50b28ub3JnAAoJEOD8dk+NZjCoUO4IAM1V9GfeVPzWDh6xrCDKjNW/
OXrrfUoDE9clyTaErSy9R8UIuY4+EuenYx23v4lw4RO05Pa1EUJ/A+8P/q7lXlwx
Js+lusYhY+ShrUYQNJwiCCXJ45J2Z3QMDwWZIgCTfyVu0kLtyLs62pTDnzSWek2b
YG4mZKcwnCYvWPdkLuP6yVNY5RwQJ/G/u0gKBtMcEsaDfHvGYFRXa4J2Ic54Bks3
X+/HDuSqQwjZWkvPjgk5iaIHwZFm0dQ1j8SqUXu2jLiSaCDQ4nb/EY1Sp1Xn23Y7
hxU5W9/+6R7VWxC0tV9LkvMv+Jf72Sl3lV6DWQKPDwqKNoAn9TVQQpib+yqR3vA=
=oxk3
-END PGP SIGNATURE-

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Xavier Miller 
Hi,

Le 10/12/17 à 22:13, Mike Gilbert a écrit :
> On Sun, Dec 10, 2017 at 3:33 PM, Michał Górny  wrote:
>>> And the list of other ebuilds (cd /var/db/pkg ; grep -l '/lib/'
>>> */*/CONTENTS)
...

...
>>
>> I would need more specific details (some example files at least) but
>> the list looks too long. Are you sure you aren't seeing some confusion
>> due to old symlinks?
> 
> He's probably seeing all the systemd units, which live in [/usr]/lib/systemd.
> 

Hi,

Indeed, my list seems too long, the real hits are udev/systemd/rc rules

dev-libs/libinput
/lib/udev/rules.d/80-libinput-device-groups.rules
/lib/udev/rules.d/90-libinput-model-quirks.rules
/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb
/lib/udev/libinput-device-group
/lib/udev/libinput-model-quirks
net-wireless/crda
/lib/udev/rules.d/85-regulatory.rules
sys-libs/glibc
app-crypt/acr38u
/lib/udev/rules.d/92-pcscd-acr38u.rules
media-sound/alsa-utils
/lib/udev/rules.d/90-alsa-restore.rules
net-misc/netifrc
/lib/netifrc/net/dhclient.sh
/lib/netifrc/net/dhcpcd.sh
/lib/netifrc/net/ifconfig.sh
/lib/netifrc/net/macchanger.sh
/lib/netifrc/net/macnet.sh
/lib/netifrc/net/ssidnet.sh
/lib/netifrc/net/system.sh
/lib/netifrc/net/wpa_supplicant.sh
/lib/netifrc/net/adsl.sh
/lib/netifrc/net/apipa.sh
/lib/netifrc/net/arping.sh
/lib/netifrc/net/bonding.sh
/lib/netifrc/net/br2684ctl.sh
/lib/netifrc/net/bridge.sh
/lib/netifrc/net/ccwgroup.sh
/lib/netifrc/net/clip.sh
/lib/netifrc/net/ethtool.sh
/lib/netifrc/net/iproute2.sh
/lib/netifrc/net/ifplugd.sh
/lib/netifrc/net/ip6to4.sh
/lib/netifrc/net/ipppd.sh
/lib/netifrc/net/iwconfig.sh
/lib/netifrc/net/netplugd.sh
/lib/netifrc/net/pppd.sh
/lib/netifrc/net/pump.sh
/lib/netifrc/net/tuntap.sh
/lib/netifrc/net/udhcpc.sh
/lib/netifrc/net/vlan.sh
/lib/netifrc/net/macvlan.sh
/lib/netifrc/net/ip6rd.sh
/lib/netifrc/net/firewalld.sh
/lib/netifrc/net/dummy.sh
/lib/netifrc/net/hsr.sh
/lib/netifrc/net/l2tp.sh
/lib/netifrc/net/iw.sh
/lib/netifrc/sh/udhcpc-hook.sh
/lib/netifrc/sh/functions.sh
/lib/netifrc/sh/systemd-wrapper.sh
/lib/netifrc/version
/lib/udev/net.sh
/lib/udev/rules.d/90-network.rules
net-misc/dhcpcd
/lib/dhcpcd/dhcpcd-run-hooks
/lib/dhcpcd/dhcpcd-hooks/01-test
/lib/dhcpcd/dhcpcd-hooks/02-dump
/lib/dhcpcd/dhcpcd-hooks/20-resolv.conf
/lib/dhcpcd/dhcpcd-hooks/30-hostname
/lib/dhcpcd/dhcpcd-hooks/50-ntp.conf
/lib/dhcpcd/dhcpcd-hooks/50-yp.conf
net-print/hplip
/lib/udev/rules.d/56-hpmud.rules
games-util/xboxdrv
/lib/udev/rules.d/99-xbox-controller.rules
sys-fs/ntfs3g
/lib/udev/rules.d/99-ntfs3g.rules
sys-fs/fuse
/lib/udev/rules.d/99-fuse.rules
sys-fs/eudev
/lib/udev/rules.d/50-udev-default.rules
/lib/udev/rules.d/60-block.rules
/lib/udev/rules.d/60-cdrom_id.rules
/lib/udev/rules.d/60-drm.rules
/lib/udev/rules.d/60-evdev.rules
/lib/udev/rules.d/60-persistent-alsa.rules
/lib/udev/rules.d/60-persistent-input.rules
/lib/udev/rules.d/60-persistent-storage-tape.rules
/lib/udev/rules.d/60-persistent-v4l.rules
/lib/udev/rules.d/60-sensor.rules
/lib/udev/rules.d/60-serial.rules
/lib/udev/rules.d/64-btrfs.rules
/lib/udev/rules.d/70-mouse.rules
/lib/udev/rules.d/70-touchpad.rules
/lib/udev/rules.d/75-net-description.rules
/lib/udev/rules.d/78-sound-card.rules
/lib/udev/rules.d/80-net-name-slot.rules
/lib/udev/rules.d/60-persistent-storage.rules
/lib/udev/rules.d/80-drivers.rules
/lib/udev/rules.d/75-probe_mtd.rules
/lib/udev/rules.d/40-gentoo.rules
/lib/udev/cdrom_id
/lib/udev/ata_id
/lib/udev/mtd_probe
/lib/udev/v4l_id
/lib/udev/scsi_id
/lib/udev/collect
sys-apps/uam
/lib/udev/uam/array.awk
/lib/udev/uam/mounts.awk
/lib/udev/uam/uam-common.sh
/lib/udev/uam/uam-mount.sh
/lib/udev/uam/uam-umount.sh
/lib/udev/uam/find-helper.sh
/lib/udev/rules.d/80-uam.rules
sys-apps/hwids
/lib/udev/hwdb.d/20-OUI.hwdb
/lib/udev/hwdb.d/20-acpi-vendor.hwdb
/lib/udev/hwdb.d/20-bluetooth-vendor-product.hwdb
/lib/udev/hwdb.d/20-net-ifname.hwdb
/lib/udev/hwdb.d/20-pci-classes.hwdb
/lib/udev/hwdb.d/20-pci-vendor-model.hwdb
/lib/udev/hwdb.d/20-sdio-classes.hwdb
/lib/udev/hwdb.d/20-sdio-vendor-model.hwdb
/lib/udev/hwdb.d/20-usb-classes.hwdb
/lib/udev/hwdb.d/20-usb-vendor-model.hwdb
/lib/udev/hwdb.d/60-evdev.hwdb
/lib/udev/hwdb.d/60-keyboard.hwdb
/lib/udev/hwdb.d/60-sensor.hwdb
/lib/udev/hwdb.d/70-joystick.hwdb
/lib/udev/hwdb.d/70-mouse.hwdb
/lib/udev/hwdb.d/70-pointingstick.hwdb
/lib/udev/hwdb.d/70-touchpad.hwdb
sys-apps/kmod
/lib/modprobe.d/usb-load-ehci-first.conf
sys-apps/gentoo-functions
/lib/gentoo/functions.sh
sys-apps/pcsc-lite
/lib/udev/rules.d/99-pcscd-hotplug.rules
media-gfx/sane-backends
/lib/udev/rules.d/41-libsane.rules



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Mike Gilbert 
On Sun, Dec 10, 2017 at 3:33 PM, Michał Górny  wrote:
> W dniu nie, 10.12.2017 o godzinie 14∶56 +0100, użytkownik Xavier Miller
> napisał:
>> Hi,
>>
>> I did emerge -e @world on a no-multilib chroot, and I have a lot of
>> ebuilds that install libs on /{,usr/}/lib/ in place of lib64
>>
>> First are kernel-related ebuilds:
>> - kernel's make install
>> - linux-firmware
>
> That's actually normal and valid.
>
>> And the list of other ebuilds (cd /var/db/pkg ; grep -l '/lib/'
>> */*/CONTENTS)
>>
>> app-accessibility/at-spi2-core-2.24.1
>> app-admin/eselect-1.4.9
>> app-admin/logrotate-3.13.0
>> app-admin/syslog-ng-3.7.3
>> app-crypt/acr38u-1.7.11-r3
>> app-crypt/gnupg-2.2.3
>> app-eselect/eselect-wxwidgets-20140423
>> app-portage/eix-0.33.0-r1
>> app-portage/elogv-0.7.6.6
>> app-portage/gentoolkit-0.4.0
>> app-portage/layman-2.4.2
>> app-portage/unsymlink-lib-3
>> app-text/docbook-xsl-stylesheets-1.79.1-r2
>> app-text/ghostscript-gpl-9.21
>> app-text/gnome-doc-utils-0.20.10-r1
>> app-text/texi2html-5.0-r1
>> dev-java/ant-core-1.9.2
>> dev-java/icedtea-3.6.0
>> dev-java/java-config-2.2.0-r3
>> dev-java/javatoolkit-0.3.0-r9
>> dev-lang/mono-4.8.0.524
>> dev-lang/perl-5.26.1-r1
>> dev-lang/python-2.7.14-r1
>> dev-lang/python-3.5.4-r1
>> dev-lang/python-exec-2.4.5
>> dev-lang/rust-1.19.0
>> dev-libs/libinput-1.9.3
>> dev-python/Babel-2.5.0
>> dev-python/chardet-3.0.4
>> dev-python/docutils-0.14
>> dev-python/ndg-httpsclient-0.4.2-r1
>> dev-python/numpy-1.13.3
>> dev-python/pillow-4.3.0
>> dev-python/pygments-2.2.0
>> dev-python/pygobject-2.28.6-r55
>> dev-python/PyQt5-5.9.2
>> dev-python/rdflib-4.2.2
>> dev-python/reportlab-3.4.0
>> dev-python/setuptools-36.7.2
>> dev-python/sphinx-1.6.3-r2
>> dev-ruby/did_you_mean-1.1.2
>> dev-ruby/ffi-1.9.18
>> dev-ruby/json-2.1.0
>> dev-ruby/kpeg-1.1.0
>> dev-ruby/listen-1.3.1-r4
>> dev-ruby/minitest-5.10.3
>> dev-ruby/net-telnet-0.1.1-r1
>> dev-ruby/power_assert-1.1.1
>> dev-ruby/racc-1.4.14
>> dev-ruby/rake-12.3.0
>> dev-ruby/rb-inotify-0.9.10
>> dev-ruby/rdoc-6.0.0
>> dev-ruby/rubygems-2.6.14
>> dev-ruby/sass-3.5.3
>> dev-ruby/sass-listen-4.0.0
>> dev-ruby/test-unit-3.2.6
>> dev-ruby/xmlrpc-0.3.0
>> dev-util/gdbus-codegen-2.52.3
>> dev-util/meson-0.43.0
>> dev-util/scons-2.5.1
>> dev-vcs/git-2.15.1
>> games-util/xboxdrv-0.8.8
>> mail-mta/nullmailer-2.0-r2
>> media-gfx/sane-backends-1.0.27
>> media-libs/libcanberra-0.30-r5
>> media-sound/alsa-utils-1.1.5
>> media-sound/timidity++-2.14.0-r2
>> net-analyzer/net-snmp-5.7.3_p3
>> net-fs/nfs-utils-2.2.2_rc1_p20171107
>> net-libs/glib-networking-2.50.0
>> net-misc/dhcpcd-7.0.0_rc4
>> net-misc/netifrc-0.6.0
>> net-misc/ntp-4.2.8_p10-r1
>> net-misc/openssh-7.6_p1-r1
>> net-misc/rsync-3.1.2-r1
>> net-misc/youtube-dl-2017.12.02
>> net-nds/openldap-2.4.45
>> net-nds/rpcbind-0.2.4-r1
>> net-print/cups-filters-1.17.9
>> net-print/hplip-3.17.10-r1
>> net-wireless/crda-3.18-r1
>> net-wireless/wireless-regdb-20170307
>> net-wireless/wpa_supplicant-2.6-r4
>> sys-apps/dbus-1.12.2
>> sys-apps/gentoo-functions-0.12
>> sys-apps/hwids-20171003
>> sys-apps/iproute2-4.14.1-r1
>> sys-apps/kmod-24
>> sys-apps/man-db-2.7.6.1-r2
>> sys-apps/pcsc-lite-1.8.22
>> sys-apps/portage-2.3.17
>> sys-apps/smartmontools-6.6
>> sys-apps/uam-0.3.2
>> sys-block/partimage-0.6.9
>> sys-devel/clang-5.0.0
>> sys-devel/distcc-3.2_rc1-r5
>> sys-devel/gcc-7.2.0
>> sys-devel/llvm-5.0.0
>> sys-firmware/intel-microcode-20171117
>> sys-firmware/midisport-firmware-1.2
>> sys-fs/eudev-3.2.5
>> sys-fs/fuse-2.9.7
>> sys-fs/lvm2-2.02.166-r2
>> sys-fs/ntfs3g-2017.3.23
>> sys-kernel/gentoo-sources-4.14.4
>> sys-kernel/linux-firmware-20171206
>> sys-libs/compiler-rt-5.0.0
>> sys-libs/compiler-rt-sanitizers-5.0.0
>> sys-libs/gpm-1.20.7-r2
>> sys-power/acpid-2.0.28
>> sys-process/cronie-1.5.1
>> x11-base/xorg-server-1.19.5
>> x11-misc/arandr-0.1.9
>> x11-misc/slim-1.3.6-r5
>> xfce-extra/xfce4-notifyd-0.4.0
>
> I would need more specific details (some example files at least) but
> the list looks too long. Are you sure you aren't seeing some confusion
> due to old symlinks?

He's probably seeing all the systemd units, which live in [/usr]/lib/systemd.

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Michał Górny 
W dniu nie, 10.12.2017 o godzinie 14∶56 +0100, użytkownik Xavier Miller
napisał:
> Hi,
> 
> I did emerge -e @world on a no-multilib chroot, and I have a lot of
> ebuilds that install libs on /{,usr/}/lib/ in place of lib64
> 
> First are kernel-related ebuilds:
> - kernel's make install
> - linux-firmware

That's actually normal and valid.

> And the list of other ebuilds (cd /var/db/pkg ; grep -l '/lib/'
> */*/CONTENTS)
> 
> app-accessibility/at-spi2-core-2.24.1
> app-admin/eselect-1.4.9
> app-admin/logrotate-3.13.0
> app-admin/syslog-ng-3.7.3
> app-crypt/acr38u-1.7.11-r3
> app-crypt/gnupg-2.2.3
> app-eselect/eselect-wxwidgets-20140423
> app-portage/eix-0.33.0-r1
> app-portage/elogv-0.7.6.6
> app-portage/gentoolkit-0.4.0
> app-portage/layman-2.4.2
> app-portage/unsymlink-lib-3
> app-text/docbook-xsl-stylesheets-1.79.1-r2
> app-text/ghostscript-gpl-9.21
> app-text/gnome-doc-utils-0.20.10-r1
> app-text/texi2html-5.0-r1
> dev-java/ant-core-1.9.2
> dev-java/icedtea-3.6.0
> dev-java/java-config-2.2.0-r3
> dev-java/javatoolkit-0.3.0-r9
> dev-lang/mono-4.8.0.524
> dev-lang/perl-5.26.1-r1
> dev-lang/python-2.7.14-r1
> dev-lang/python-3.5.4-r1
> dev-lang/python-exec-2.4.5
> dev-lang/rust-1.19.0
> dev-libs/libinput-1.9.3
> dev-python/Babel-2.5.0
> dev-python/chardet-3.0.4
> dev-python/docutils-0.14
> dev-python/ndg-httpsclient-0.4.2-r1
> dev-python/numpy-1.13.3
> dev-python/pillow-4.3.0
> dev-python/pygments-2.2.0
> dev-python/pygobject-2.28.6-r55
> dev-python/PyQt5-5.9.2
> dev-python/rdflib-4.2.2
> dev-python/reportlab-3.4.0
> dev-python/setuptools-36.7.2
> dev-python/sphinx-1.6.3-r2
> dev-ruby/did_you_mean-1.1.2
> dev-ruby/ffi-1.9.18
> dev-ruby/json-2.1.0
> dev-ruby/kpeg-1.1.0
> dev-ruby/listen-1.3.1-r4
> dev-ruby/minitest-5.10.3
> dev-ruby/net-telnet-0.1.1-r1
> dev-ruby/power_assert-1.1.1
> dev-ruby/racc-1.4.14
> dev-ruby/rake-12.3.0
> dev-ruby/rb-inotify-0.9.10
> dev-ruby/rdoc-6.0.0
> dev-ruby/rubygems-2.6.14
> dev-ruby/sass-3.5.3
> dev-ruby/sass-listen-4.0.0
> dev-ruby/test-unit-3.2.6
> dev-ruby/xmlrpc-0.3.0
> dev-util/gdbus-codegen-2.52.3
> dev-util/meson-0.43.0
> dev-util/scons-2.5.1
> dev-vcs/git-2.15.1
> games-util/xboxdrv-0.8.8
> mail-mta/nullmailer-2.0-r2
> media-gfx/sane-backends-1.0.27
> media-libs/libcanberra-0.30-r5
> media-sound/alsa-utils-1.1.5
> media-sound/timidity++-2.14.0-r2
> net-analyzer/net-snmp-5.7.3_p3
> net-fs/nfs-utils-2.2.2_rc1_p20171107
> net-libs/glib-networking-2.50.0
> net-misc/dhcpcd-7.0.0_rc4
> net-misc/netifrc-0.6.0
> net-misc/ntp-4.2.8_p10-r1
> net-misc/openssh-7.6_p1-r1
> net-misc/rsync-3.1.2-r1
> net-misc/youtube-dl-2017.12.02
> net-nds/openldap-2.4.45
> net-nds/rpcbind-0.2.4-r1
> net-print/cups-filters-1.17.9
> net-print/hplip-3.17.10-r1
> net-wireless/crda-3.18-r1
> net-wireless/wireless-regdb-20170307
> net-wireless/wpa_supplicant-2.6-r4
> sys-apps/dbus-1.12.2
> sys-apps/gentoo-functions-0.12
> sys-apps/hwids-20171003
> sys-apps/iproute2-4.14.1-r1
> sys-apps/kmod-24
> sys-apps/man-db-2.7.6.1-r2
> sys-apps/pcsc-lite-1.8.22
> sys-apps/portage-2.3.17
> sys-apps/smartmontools-6.6
> sys-apps/uam-0.3.2
> sys-block/partimage-0.6.9
> sys-devel/clang-5.0.0
> sys-devel/distcc-3.2_rc1-r5
> sys-devel/gcc-7.2.0
> sys-devel/llvm-5.0.0
> sys-firmware/intel-microcode-20171117
> sys-firmware/midisport-firmware-1.2
> sys-fs/eudev-3.2.5
> sys-fs/fuse-2.9.7
> sys-fs/lvm2-2.02.166-r2
> sys-fs/ntfs3g-2017.3.23
> sys-kernel/gentoo-sources-4.14.4
> sys-kernel/linux-firmware-20171206
> sys-libs/compiler-rt-5.0.0
> sys-libs/compiler-rt-sanitizers-5.0.0
> sys-libs/gpm-1.20.7-r2
> sys-power/acpid-2.0.28
> sys-process/cronie-1.5.1
> x11-base/xorg-server-1.19.5
> x11-misc/arandr-0.1.9
> x11-misc/slim-1.3.6-r5
> xfce-extra/xfce4-notifyd-0.4.0

I would need more specific details (some example files at least) but
the list looks too long. Are you sure you aren't seeing some confusion
due to old symlinks?

-- 
Best regards,
Michał Górny

Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-10 Thread kuzetsa 
On 12/10/2017 03:21 AM, Michał Górny wrote:

> Your attack on me is fully unfounded and completely inappropriate. FYI,
> just let me correct a few facts here:
--- pruned ---
> 3. The agenda item wasn't expressing 'feelings of one developer', as you
> know it. It was written by me because I found the time to prepare
> a rationale of *facts* to support it. Don't shoot the messenger.

Yes.

I'm a fan of transparency, but there are many people
with passionate views, so sometimes it's harder to
have a calm discussion about social matters.

If / when these discussions happen, remarks about
various actions by specific people tends to escalate
hostility. On the other hand, generalizations about
how gentoo-related communication should occur isn't
a "shots fired" or "touchy subject" situation.

TL;DR - Public fighting doesn't help gentoo.

-kuzetsa

P.S. I'm trying to stay out of these contentious topics.
Also, your composure / tone seems fine to me, mgorny.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Constraint-Based Dependency Solver for Portage: a prototype

2017-12-10 Thread Alexander Berntsen 
Unfortunately I am way too busy to even entertain looking into this in
any detail. A few years ago I was hoping to work on something like this,
though in Agda (or possibly in Haskell or Coq), and do work on making
Portage much more modular so that you could actually pick whatever
dependency resolver you wanted -- even going as far as "Don't like the
resolution you were presented now? Try using another resolver" messages.
But alas that job ended before I got very far.

However, I wanted to take the time to drop you a tiny note of
encouragement. I think this looks really great, and I hope someone on
the team finds the time to look into it in more detail than me.
-- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander



signature.asc
Description: OpenPGP digital signature

Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-10 Thread Rich Freeman 
On Sat, Dec 9, 2017 at 11:31 PM, Daniel Campbell  wrote:
>
> Well, let's consider the order of events here:
> ...
> This looks awfully clear to me.
>...
> I'm not focused on the ban, or whether it was deserved.

That's exactly what you've done here.  You've connected a bunch of
dots that you can see, and don't consider that there may be dots that
you don't see.

>>
>> And the only item recently submitted that is relevant is the item for
>> the splitting of the mailing list, and the Council hasn't even met to
>> make any decisions one way or another.  You're exasperated over
>> something the Council hasn't even done.
>
> Again, the Council approves most things that come down the line,
> especially if it's from mgorny.
>

You've read this situation fairly poorly, IMO.

Certainly many of mgorny's proposals have been approved by the council
over the last few years, but go back and review them.  They're mostly
technical proposals, and I think you would agree that his proposals
tend to be technically strong.  I realize that isn't what you're
arguing, but you can't extrapolate from a history of approving
technical proposals to an assumption that the Council would approve
literally any controversial social proposal he makes.

I have had no access to any internal/private deliberations any members
of the council have had over this issue, and the same access as you to
any public statements they have made over the last few weeks.  I would
estimate the likely possible outcomes and their probabilities as:

0% - Splitting of gentoo-dev into two lists as proposed.
20% - no resolutions accepted this meeting
10% - A statement encouraging the moderation of the gentoo-dev list
once infra can enable this.
50% - A general statement indicating that so far there hasn't actually
been much significant ban evasion going on, and that for the time
being asking community members to respect any bans should continue.
Community members should try to abide by the comrel process, and not
take matters into their own hands by participating in flame wars.
Gentoo-dev should be focused on technical matters, non-technical
matters ought to go to gentoo-project, and comrel is encouraged to
remind individuals of when they're off-topic even if well-intentioned.
20% - No formal proposal, but an intention communicated to revive
something like the proctors project to allow comrel to focus on bigger
issues (harassment, ongoing patterns, etc).  The proctors would be
much more proactive in reaching out to community members who are
abusing lists/irc/etc, and likely empowered to hand out temporary
bans/etc of fairly short duration, enforced either voluntarily or
using technical means (though presumably ban evasion would be viewed
as a more serious offense).

Knowing most of the council members reasonably well I think it is
pretty unlikely that anything drastic will be done, and a few have
already gone on the record publicly as not being in favor of splitting
the list.

>
> You told me a few paragraphs ago that it wouldn't be worth it anyway,
> and now you're telling me to run for the Council? Which is it?

Both, these statements are not contradictory.

If you feel that strongly that the Council is out of line you should
run.  Then you will be able to see firsthand how the rest of the
community feels about your approach.  I could be wrong but I think
you'd be soundly defeated assuming most of the incumbents haven't left
by then.

>From the standpoint of getting your way it wouldn't be worth it.  From
the standpoint of giving everybody a chance to vote on your opinions
it would be.  IMO there really isn't anything you can do to get your
way, because it is opposed by most of the community, albeit silently.

That said, I do have to acknowledge that my email was indirect.  That
tends to be my style - I usually try to leave conclusions unsaid.  On
a list whose participants vary greatly in language skills, technical
proficiency, general intelligence, value/culture, etc perhaps it
really isn't the best way to communicate.  (There I go again being
indirect...)  I need to work on that...

-- 
Rich

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Xavier Miller 
Hi,

I did emerge -e @world on a no-multilib chroot, and I have a lot of
ebuilds that install libs on /{,usr/}/lib/ in place of lib64

First are kernel-related ebuilds:
- kernel's make install
- linux-firmware

And the list of other ebuilds (cd /var/db/pkg ; grep -l '/lib/'
*/*/CONTENTS)

app-accessibility/at-spi2-core-2.24.1
app-admin/eselect-1.4.9
app-admin/logrotate-3.13.0
app-admin/syslog-ng-3.7.3
app-crypt/acr38u-1.7.11-r3
app-crypt/gnupg-2.2.3
app-eselect/eselect-wxwidgets-20140423
app-portage/eix-0.33.0-r1
app-portage/elogv-0.7.6.6
app-portage/gentoolkit-0.4.0
app-portage/layman-2.4.2
app-portage/unsymlink-lib-3
app-text/docbook-xsl-stylesheets-1.79.1-r2
app-text/ghostscript-gpl-9.21
app-text/gnome-doc-utils-0.20.10-r1
app-text/texi2html-5.0-r1
dev-java/ant-core-1.9.2
dev-java/icedtea-3.6.0
dev-java/java-config-2.2.0-r3
dev-java/javatoolkit-0.3.0-r9
dev-lang/mono-4.8.0.524
dev-lang/perl-5.26.1-r1
dev-lang/python-2.7.14-r1
dev-lang/python-3.5.4-r1
dev-lang/python-exec-2.4.5
dev-lang/rust-1.19.0
dev-libs/libinput-1.9.3
dev-python/Babel-2.5.0
dev-python/chardet-3.0.4
dev-python/docutils-0.14
dev-python/ndg-httpsclient-0.4.2-r1
dev-python/numpy-1.13.3
dev-python/pillow-4.3.0
dev-python/pygments-2.2.0
dev-python/pygobject-2.28.6-r55
dev-python/PyQt5-5.9.2
dev-python/rdflib-4.2.2
dev-python/reportlab-3.4.0
dev-python/setuptools-36.7.2
dev-python/sphinx-1.6.3-r2
dev-ruby/did_you_mean-1.1.2
dev-ruby/ffi-1.9.18
dev-ruby/json-2.1.0
dev-ruby/kpeg-1.1.0
dev-ruby/listen-1.3.1-r4
dev-ruby/minitest-5.10.3
dev-ruby/net-telnet-0.1.1-r1
dev-ruby/power_assert-1.1.1
dev-ruby/racc-1.4.14
dev-ruby/rake-12.3.0
dev-ruby/rb-inotify-0.9.10
dev-ruby/rdoc-6.0.0
dev-ruby/rubygems-2.6.14
dev-ruby/sass-3.5.3
dev-ruby/sass-listen-4.0.0
dev-ruby/test-unit-3.2.6
dev-ruby/xmlrpc-0.3.0
dev-util/gdbus-codegen-2.52.3
dev-util/meson-0.43.0
dev-util/scons-2.5.1
dev-vcs/git-2.15.1
games-util/xboxdrv-0.8.8
mail-mta/nullmailer-2.0-r2
media-gfx/sane-backends-1.0.27
media-libs/libcanberra-0.30-r5
media-sound/alsa-utils-1.1.5
media-sound/timidity++-2.14.0-r2
net-analyzer/net-snmp-5.7.3_p3
net-fs/nfs-utils-2.2.2_rc1_p20171107
net-libs/glib-networking-2.50.0
net-misc/dhcpcd-7.0.0_rc4
net-misc/netifrc-0.6.0
net-misc/ntp-4.2.8_p10-r1
net-misc/openssh-7.6_p1-r1
net-misc/rsync-3.1.2-r1
net-misc/youtube-dl-2017.12.02
net-nds/openldap-2.4.45
net-nds/rpcbind-0.2.4-r1
net-print/cups-filters-1.17.9
net-print/hplip-3.17.10-r1
net-wireless/crda-3.18-r1
net-wireless/wireless-regdb-20170307
net-wireless/wpa_supplicant-2.6-r4
sys-apps/dbus-1.12.2
sys-apps/gentoo-functions-0.12
sys-apps/hwids-20171003
sys-apps/iproute2-4.14.1-r1
sys-apps/kmod-24
sys-apps/man-db-2.7.6.1-r2
sys-apps/pcsc-lite-1.8.22
sys-apps/portage-2.3.17
sys-apps/smartmontools-6.6
sys-apps/uam-0.3.2
sys-block/partimage-0.6.9
sys-devel/clang-5.0.0
sys-devel/distcc-3.2_rc1-r5
sys-devel/gcc-7.2.0
sys-devel/llvm-5.0.0
sys-firmware/intel-microcode-20171117
sys-firmware/midisport-firmware-1.2
sys-fs/eudev-3.2.5
sys-fs/fuse-2.9.7
sys-fs/lvm2-2.02.166-r2
sys-fs/ntfs3g-2017.3.23
sys-kernel/gentoo-sources-4.14.4
sys-kernel/linux-firmware-20171206
sys-libs/compiler-rt-5.0.0
sys-libs/compiler-rt-sanitizers-5.0.0
sys-libs/gpm-1.20.7-r2
sys-power/acpid-2.0.28
sys-process/cronie-1.5.1
x11-base/xorg-server-1.19.5
x11-misc/arandr-0.1.9
x11-misc/slim-1.3.6-r5
xfce-extra/xfce4-notifyd-0.4.0

Xavier.


Le 10/12/17 à 12:45, Michał Górny a écrit :
> W dniu nie, 10.12.2017 o godzinie 10∶59 +, użytkownik Justin Lecher
> napisał:
>> Hi
>>
>> Is the baselayout ready for this? I get following error
>>
>>  * You need to merge /lib32 into /lib
>>  * ERROR: sys-apps/baselayout-2.4.1-r2::gentoo failed (setup phase):
>>  *   non-empty dir found where there should be none: /lib32
>>
>> Which hints that the baselayout might not be happy with this setup?
>>
>> What are you thoughts?
>>
> 
> Indeed it seems to dislike lib32 symlink. I'll try to fix that.
> In the meantime, you can skip baselayout for now and return to it once
> all multilib packages are rebuilt (and lib32 is gone).
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Justin Lecher 
On 10/12/2017 11:45, Michał Górny wrote:
> Indeed it seems to dislike lib32 symlink. I'll try to fix that.
> In the meantime, you can skip baselayout for now and return to it once
> all multilib packages are rebuilt (and lib32 is gone).
> 

The rest worked fine. At the end also baselayout behave well once the
symlink is gone.

Thanks for the work.

Justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Michał Górny 
W dniu nie, 10.12.2017 o godzinie 10∶59 +, użytkownik Justin Lecher
napisał:
> Hi
> 
> Is the baselayout ready for this? I get following error
> 
>  * You need to merge /lib32 into /lib
>  * ERROR: sys-apps/baselayout-2.4.1-r2::gentoo failed (setup phase):
>  *   non-empty dir found where there should be none: /lib32
> 
> Which hints that the baselayout might not be happy with this setup?
> 
> What are you thoughts?
> 

Indeed it seems to dislike lib32 symlink. I'll try to fix that.
In the meantime, you can skip baselayout for now and return to it once
all multilib packages are rebuilt (and lib32 is gone).

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

2017-12-10 Thread Justin Lecher 
Hi

Is the baselayout ready for this? I get following error

 * You need to merge /lib32 into /lib
 * ERROR: sys-apps/baselayout-2.4.1-r2::gentoo failed (setup phase):
 *   non-empty dir found where there should be none: /lib32

Which hints that the baselayout might not be happy with this setup?

What are you thoughts?

Justin





signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: media-radio/wspr

2017-12-10 Thread tomjbe 
# Thomas Beierlein  (10 Dec 2017)
# Development stopped, nasty build system.
# Functionality superseded by media-radio/wsjtx.
# Masked for removal in 30 days.
media-radio/wspr

Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-10 Thread R0b0t1 
On Sun, Dec 10, 2017 at 2:21 AM, Michał Górny  wrote:
> W dniu sob, 09.12.2017 o godzinie 16∶29 -0800, użytkownik Daniel
> Campbell napisał:
>> On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote:
>> > Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson 
>> > Jr.:
>> > >
>> > > The day everyone wanted has come, after this message. I will
>> > > unsubscribe not to return. You all won in 2008, and again in 2017.
>> > > Though this time I will not be back. I tried more than most anyone else
>> > > would for a very long time. Gentoo wins I lose, I am fine with that.
>> > >
>> > > Please do not contact me off list in IRC or at all. I am done with the
>> > > Gentoo community!
>> >
>> > 
>> > Independent of whether William now unsubscribed or not, he's now enjoying a
>> > lengthy (1 year until review) vacation from all Gentoo communication 
>> > channels.
>> > 
>> >
>> > --
>> > Andreas K. Hüttel
>> > dilfri...@gentoo.org
>> > Gentoo Linux developer (council, perl, libreoffice)
>>
>> So, mgorny threatened to leave if something wasn't done, right? I saw
>> the IRC conversation about unsubscribing from gentoo-dev, as well. IRC
>> is not private, for the record. Other developers are required to
>> subscribe to -dev, and are expected to follow it so they stay informed.
>> If they missed something covered on the list, they are directed to the
>> archives and (usually) laughed at. I see no reason for this expectation
>> to be waived for any single developer. Do I get a free pass if I don't
>> like what someone says?
>>
>> It's not enough to let wltjr leave on his own; you had to create a ban
>> and add a smug, tongue-in-cheek mail to it to maintain the image of
>> doing something. Quite hypocritical of comrel's attitude of secrecy to
>> suddenly announce a ban. It seems to me that secrecy is only adopted
>> when it suits those who stand to benefit from it.
>>
>> Great things coming from Gentoo "leadership" here. What will you do when
>> mgorny starts targeting developers and pitching tantrums over them, too?
>> Are we going to stratify developership further, too? It seems rather
>> clear to me that a few individuals see themselves as the owners of this
>> distro and bend it to suit their whims, using bureacracy to obscure
>> their actions and motivations, segment the community, and block those
>> less experienced. This is precisely why we have unmotivated developers
>> and a bevy of unmaintained packages; nobody wants to contribute to a
>> distro that treats its users (and developers) so poorly.
>>
>> A distro should never bend its entire social structure to protect the
>> feelings of one surly developer (or his/her entourage), but naturally
>> since every council member is friends with mgorny and comrel is afraid
>> to take any action against him, they'll make exceptions to established
>> procedures and ignore any complaints about the way he treats others.
>>
>> Software cannot fix wetware. Plenty of developers get to deal with
>> mgorny's aggressive and insulting tone, yet nothing happens. Gee... I
>> wonder why.  Maybe because the upper parts of Gentoo are riddled with
>> cronyism.
>>
>>   "Rules for thee, not for me."
>>
>> It's clear to anyone with eyeballs that there is preferential treatment
>> and inconsistent enforcement of rules in this community, and the people
>> in a position to fix it, won't, because they in fact benefit from this.
>>
>> Unfortunately, GLEP 39 does not have a section on recalling or
>> impeachment... This whole situation highlights why the Council has no
>> business sticking its head into non-technical matters. It's clearly not
>> up to the task. It's no surprise, since technical skill does not
>> guarantee or even imply social skill. (or vice-versa)
>>
>> I'm tired of people beating around the bush and the facile attempts of
>> tact: why do you give special treatment to certain members of this
>> community? Would you have done anything different if it were me or some
>> other developer who was proposing this change?
>>
>> It wouldn't have made it to the Council agenda if he didn't write it,
>> period. Everyone else would've been told to suck it up and deal with it.
>> And knowing how the Council is, in a few days we'll all get to deal with
>> the churn of mailing lists to protect one person's ego. Sad.
>>
>
> Your attack on me is fully unfounded and completely inappropriate. FYI,
> just let me correct a few facts here:
>
> 1. ComRel made its decision long before the discussion was even started
> (and I was unaware of it as well), and -- unless you presume they have
> time travellers there -- had nothing to do with it.
>
> 2. I disagree with the way of announcing the ban as well. I had nothing
> to do with that.
>
> 3. The agenda item wasn't expressing 'feelings of one developer', as you
> know it. It was written by me because I found the time to prepare
> a rationale of *facts* to support it. Don't shoot the messenger.
>

Most

Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-10 Thread Michał Górny 
W dniu sob, 09.12.2017 o godzinie 16∶29 -0800, użytkownik Daniel
Campbell napisał:
> On Fri, Dec 08, 2017 at 09:22:32PM +0100, Andreas K. Huettel wrote:
> > Am Donnerstag, 7. Dezember 2017, 19:06:36 CET schrieb William L. Thomson 
> > Jr.:
> > > 
> > > The day everyone wanted has come, after this message. I will
> > > unsubscribe not to return. You all won in 2008, and again in 2017.
> > > Though this time I will not be back. I tried more than most anyone else
> > > would for a very long time. Gentoo wins I lose, I am fine with that.
> > > 
> > > Please do not contact me off list in IRC or at all. I am done with the
> > > Gentoo community!
> > 
> > 
> > Independent of whether William now unsubscribed or not, he's now enjoying a 
> > lengthy (1 year until review) vacation from all Gentoo communication 
> > channels.
> > 
> > 
> > -- 
> > Andreas K. Hüttel
> > dilfri...@gentoo.org
> > Gentoo Linux developer (council, perl, libreoffice)
> 
> So, mgorny threatened to leave if something wasn't done, right? I saw
> the IRC conversation about unsubscribing from gentoo-dev, as well. IRC
> is not private, for the record. Other developers are required to
> subscribe to -dev, and are expected to follow it so they stay informed.
> If they missed something covered on the list, they are directed to the
> archives and (usually) laughed at. I see no reason for this expectation
> to be waived for any single developer. Do I get a free pass if I don't
> like what someone says?
> 
> It's not enough to let wltjr leave on his own; you had to create a ban
> and add a smug, tongue-in-cheek mail to it to maintain the image of
> doing something. Quite hypocritical of comrel's attitude of secrecy to
> suddenly announce a ban. It seems to me that secrecy is only adopted
> when it suits those who stand to benefit from it.
> 
> Great things coming from Gentoo "leadership" here. What will you do when
> mgorny starts targeting developers and pitching tantrums over them, too?
> Are we going to stratify developership further, too? It seems rather
> clear to me that a few individuals see themselves as the owners of this
> distro and bend it to suit their whims, using bureacracy to obscure
> their actions and motivations, segment the community, and block those
> less experienced. This is precisely why we have unmotivated developers
> and a bevy of unmaintained packages; nobody wants to contribute to a
> distro that treats its users (and developers) so poorly.
> 
> A distro should never bend its entire social structure to protect the
> feelings of one surly developer (or his/her entourage), but naturally
> since every council member is friends with mgorny and comrel is afraid
> to take any action against him, they'll make exceptions to established
> procedures and ignore any complaints about the way he treats others.
> 
> Software cannot fix wetware. Plenty of developers get to deal with
> mgorny's aggressive and insulting tone, yet nothing happens. Gee... I
> wonder why.  Maybe because the upper parts of Gentoo are riddled with
> cronyism.
> 
>   "Rules for thee, not for me."
> 
> It's clear to anyone with eyeballs that there is preferential treatment
> and inconsistent enforcement of rules in this community, and the people
> in a position to fix it, won't, because they in fact benefit from this.
> 
> Unfortunately, GLEP 39 does not have a section on recalling or
> impeachment... This whole situation highlights why the Council has no
> business sticking its head into non-technical matters. It's clearly not
> up to the task. It's no surprise, since technical skill does not
> guarantee or even imply social skill. (or vice-versa)
> 
> I'm tired of people beating around the bush and the facile attempts of
> tact: why do you give special treatment to certain members of this
> community? Would you have done anything different if it were me or some
> other developer who was proposing this change?
> 
> It wouldn't have made it to the Council agenda if he didn't write it,
> period. Everyone else would've been told to suck it up and deal with it.
> And knowing how the Council is, in a few days we'll all get to deal with
> the churn of mailing lists to protect one person's ego. Sad.
> 

Your attack on me is fully unfounded and completely inappropriate. FYI,
just let me correct a few facts here:

1. ComRel made its decision long before the discussion was even started
(and I was unaware of it as well), and -- unless you presume they have
time travellers there -- had nothing to do with it.

2. I disagree with the way of announcing the ban as well. I had nothing
to do with that.

3. The agenda item wasn't expressing 'feelings of one developer', as you
know it. It was written by me because I found the time to prepare
a rationale of *facts* to support it. Don't shoot the messenger.

4. Finally, if you really hate me so much, you could at least bother to
check the facts instead of publicly insulting me based purely on lies.

-- 
Best regards,
Michał