Re: [gentoo-dev] amd64 17.1 profiles ready for testing
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-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-12-10 23:59 UTC
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
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
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
-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
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
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
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)
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: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
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
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
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
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
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
# 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)
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 of what you provided
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
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ł Górny