[gentoo-dev] [PATCH 9/9] profiles: use.mask perl_features_debug
Signed-off-by: Andreas K. Hüttel --- profiles/base/use.mask | 5 + 1 file changed, 5 insertions(+) diff --git a/profiles/base/use.mask b/profiles/base/use.mask index f27ab3bcd0b8..392c76f40109 100644 --- a/profiles/base/use.mask +++ b/profiles/base/use.mask @@ -4,6 +4,11 @@ # This file is only for generic masks. For arch-specific masks (i.e. # mask everywhere, unmask on arch/*) use arch/base. +# Andreas K. Hüttel (2024-05-01) +# PERL_FEATURES=debug is not a setting that should be used lightly. +# If you really need it, then unmask it... +perl_features_debug + # Andreas Sturmlechner (2024-04-06) # Telepathy is dead and packages masked for removal. telepathy -- 2.43.2
[gentoo-dev] [PATCH 8/9] perl-module.eclass: Implement dependency on PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- eclass/perl-module.eclass | 47 ++- 1 file changed, 36 insertions(+), 11 deletions(-) diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass index 7bb02abed8c5..029fc78e4a85 100644 --- a/eclass/perl-module.eclass +++ b/eclass/perl-module.eclass @@ -44,6 +44,28 @@ esac # a use-conditional build time dependency on virtual/perl-Test-Simple, and # the required RESTRICT setting. +# @ECLASS_VARIABLE: PERL_USEDEP +# @OUTPUT_VARIABLE +# @DESCRIPTION: +# An eclass-generated USE-dependency string for the features of the +# installed Perl. While by far not as critical as for Python, this should +# be used to depend at least on Perl packages installing compiled +# (binary) files. +# +# Example use: +# @CODE +# RDEPEND=dev-perl/DBI[${PERL_USEDEP}] +# @CODE +# +# Example value: +# @CODE +# perl_features_debug=,perl_features_ithreads=,perl_features_quadmath= +# @CODE +PERL_USEDEP="perl_features_debug=,perl_features_ithreads=,perl_features_quadmath=" + +GENTOO_PERL_DEPSTRING=" || ( >=dev-lang/perl-5.38.2-r3[${PERL_USEDEP}] =virtual/perl-Test-Simple-1 )" - IUSE="test" + IUSE+=" test" RESTRICT="!test? ( test )" ;;& yes) - RDEPEND="dev-lang/perl:=" + RDEPEND="${GENTOO_PERL_DEPSTRING} dev-lang/perl:=" ;; noslotop) - RDEPEND="dev-lang/perl" + RDEPEND=${GENTOO_PERL_DEPSTRING} ;; esac -- 2.43.2
[gentoo-dev] [PATCH 7/9] www-apache/mod_perl: Port to PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- ...{mod_perl-2.0.13.ebuild => mod_perl-2.0.13-r1.ebuild} | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) rename www-apache/mod_perl/{mod_perl-2.0.13.ebuild => mod_perl-2.0.13-r1.ebuild} (89%) diff --git a/www-apache/mod_perl/mod_perl-2.0.13.ebuild b/www-apache/mod_perl/mod_perl-2.0.13-r1.ebuild similarity index 89% rename from www-apache/mod_perl/mod_perl-2.0.13.ebuild rename to www-apache/mod_perl/mod_perl-2.0.13-r1.ebuild index d2b6cb753c19..a0d8c495793b 100644 --- a/www-apache/mod_perl/mod_perl-2.0.13.ebuild +++ b/www-apache/mod_perl/mod_perl-2.0.13-r1.ebuild @@ -13,7 +13,7 @@ SRC_URI="mirror://apache/perl/${P}.tar.gz" LICENSE="Apache-2.0" SLOT="1" KEYWORDS="amd64 ~arm ppc ppc64 ~riscv x86" -IUSE="debug ithreads test" +IUSE="debug perl_features_ithreads test" RESTRICT="!test? ( test )" # Apache::Reload, Apache::SizeLimit, and Apache::Test are force-unbundled. @@ -25,11 +25,12 @@ RESTRICT="!test? ( test )" # default one, which will likely need threading. RDEPEND=" - dev-lang/perl[ithreads=] + perl_features_ithreads? ( || ( >=dev-lang/perl-5.38.2-r3[perl_features_ithreads] =dev-lang/perl-5.38.2-r3[-perl_features_ithreads] =dev-perl/Apache-Test-1.420.0 >=www-servers/apache-2.0.47 >=dev-libs/apr-util-1.4 - !ithreads? ( www-servers/apache[-apache2_mpms_event,-apache2_mpms_worker,apache2_mpms_prefork] ) + !perl_features_ithreads? ( www-servers/apache[-apache2_mpms_event,-apache2_mpms_worker,apache2_mpms_prefork] ) " DEPEND="${RDEPEND}" BDEPEND=" @@ -75,7 +76,7 @@ src_configure() { _init_apache2_late local debug=$(usex debug 1 0) - local nothreads=$(usex ithreads 0 1) + local nothreads=$(usex perl_features_ithreads 0 1) myconf=( MP_USE_DSO=1 MP_APXS=${APXS} -- 2.43.2
[gentoo-dev] [PATCH 6/9] virtual/perl-threads: Port to PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- ...-threads-2.360.0.ebuild => perl-threads-2.360.0-r1.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename virtual/perl-threads/{perl-threads-2.360.0.ebuild => perl-threads-2.360.0-r1.ebuild} (70%) diff --git a/virtual/perl-threads/perl-threads-2.360.0.ebuild b/virtual/perl-threads/perl-threads-2.360.0-r1.ebuild similarity index 70% rename from virtual/perl-threads/perl-threads-2.360.0.ebuild rename to virtual/perl-threads/perl-threads-2.360.0-r1.ebuild index b2dc86d96822..3671df6d6c57 100644 --- a/virtual/perl-threads/perl-threads-2.360.0.ebuild +++ b/virtual/perl-threads/perl-threads-2.360.0-r1.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=8 @@ -8,7 +8,7 @@ SLOT="0" KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~amd64-linux ~x86-linux ~arm64-macos ~ppc-macos ~x64-macos ~x64-solaris" RDEPEND=" - || ( =dev-lang/perl-5.38*[ithreads] ~perl-core/${PN#perl-}-${PV} ) + || ( >=dev-lang/perl-5.38.2-r3[perl_features_ithreads] =dev-lang/perl-5.38.2-r2[ithreads] ~perl-core/${PN#perl-}-${PV} ) dev-lang/perl:= !perl-core/${PN#perl-}-${PV}-r999 -- 2.43.2
[gentoo-dev] [PATCH 5/9] net-analyzer/snortalog: Port to PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- .../{snortalog-2.4.3-r1.ebuild => snortalog-2.4.3-r2.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename net-analyzer/snortalog/{snortalog-2.4.3-r1.ebuild => snortalog-2.4.3-r2.ebuild} (91%) diff --git a/net-analyzer/snortalog/snortalog-2.4.3-r1.ebuild b/net-analyzer/snortalog/snortalog-2.4.3-r2.ebuild similarity index 91% rename from net-analyzer/snortalog/snortalog-2.4.3-r1.ebuild rename to net-analyzer/snortalog/snortalog-2.4.3-r2.ebuild index 960612b2f88f..2063d0ad5aa0 100644 --- a/net-analyzer/snortalog/snortalog-2.4.3-r1.ebuild +++ b/net-analyzer/snortalog/snortalog-2.4.3-r2.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2021 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 @@ -18,7 +18,7 @@ KEYWORDS="~amd64 ~arm ~ppc ~sparc ~x86" IUSE="tk" RDEPEND=" - dev-lang/perl[ithreads] + || ( >=dev-lang/perl-5.38.2-r3[perl_features_ithreads]
[gentoo-dev] [PATCH 4/9] media-sound/cantata: Port to PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- .../{cantata-2.5.0-r1.ebuild => cantata-2.5.0-r2.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename media-sound/cantata/{cantata-2.5.0-r1.ebuild => cantata-2.5.0-r2.ebuild} (95%) diff --git a/media-sound/cantata/cantata-2.5.0-r1.ebuild b/media-sound/cantata/cantata-2.5.0-r2.ebuild similarity index 95% rename from media-sound/cantata/cantata-2.5.0-r1.ebuild rename to media-sound/cantata/cantata-2.5.0-r2.ebuild index 59af4a9d39c5..334a2e24c048 100644 --- a/media-sound/cantata/cantata-2.5.0-r1.ebuild +++ b/media-sound/cantata/cantata-2.5.0-r2.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=8 @@ -55,7 +55,7 @@ COMMON_DEPEND=" zeroconf? ( net-dns/avahi ) " RDEPEND="${COMMON_DEPEND} - dev-lang/perl[ithreads] + || ( >=dev-lang/perl-5.38.2-r3[perl_features_ithreads]
[gentoo-dev] [PATCH 3/9] app-metrics/collectd: Port to PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- .../{collectd-5.12.0-r9.ebuild => collectd-5.12.0-r10.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename app-metrics/collectd/{collectd-5.12.0-r9.ebuild => collectd-5.12.0-r10.ebuild} (98%) diff --git a/app-metrics/collectd/collectd-5.12.0-r9.ebuild b/app-metrics/collectd/collectd-5.12.0-r10.ebuild similarity index 98% rename from app-metrics/collectd/collectd-5.12.0-r9.ebuild rename to app-metrics/collectd/collectd-5.12.0-r10.ebuild index 8d1cbfe0d598..301e390ecd45 100644 --- a/app-metrics/collectd/collectd-5.12.0-r9.ebuild +++ b/app-metrics/collectd/collectd-5.12.0-r10.ebuild @@ -89,7 +89,7 @@ COMMON_DEPEND=" dev-libs/libgcrypt:= dev-libs/libltdl:0= sys-libs/libcap - perl? ( dev-lang/perl:=[ithreads] ) + perl? ( || ( >=dev-lang/perl-5.38.2-r3[perl_features_ithreads]
[gentoo-dev] [PATCH 2/9] app-editors/padre: Port to PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- .../{padre-1.0.0-r2.ebuild => padre-1.0.0-r3.ebuild} | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) rename app-editors/padre/{padre-1.0.0-r2.ebuild => padre-1.0.0-r3.ebuild} (94%) diff --git a/app-editors/padre/padre-1.0.0-r2.ebuild b/app-editors/padre/padre-1.0.0-r3.ebuild similarity index 94% rename from app-editors/padre/padre-1.0.0-r2.ebuild rename to app-editors/padre/padre-1.0.0-r3.ebuild index f583d1929264..00df896963fe 100644 --- a/app-editors/padre/padre-1.0.0-r2.ebuild +++ b/app-editors/padre/padre-1.0.0-r3.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2023 Gentoo Authors +# Copyright 1999-2024 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=8 @@ -13,10 +13,9 @@ HOMEPAGE="https://padre.perlide.org/"; SLOT="0" KEYWORDS="~amd64 ~riscv ~x86" -IUSE="" # Test Deps -TDEPEND=" +TESTDEPEND=" >=dev-perl/Test-MockObject-1.90.0 >=dev-perl/Test-Script-1.70.0 >=dev-perl/Test-Exception-0.270.0 @@ -26,7 +25,7 @@ TDEPEND=" " RDEPEND=" - dev-lang/perl[ithreads] + || ( >=dev-lang/perl-5.38.2-r3[perl_features_ithreads] =dev-lang/perl-5.10.1 >=dev-perl/Algorithm-Diff-1.190.0 >=dev-perl/Capture-Tiny-0.60.0 @@ -92,7 +91,7 @@ RDEPEND=" " BDEPEND="${RDEPEND} test? ( - ${TDEPEND} + ${TESTDEPEND} ) " -- 2.43.2
[gentoo-dev] [PATCH 1/9] dev-lang/perl: Migrate to PERL_FEATURES
Signed-off-by: Andreas K. Hüttel --- dev-lang/perl/perl-5.38.2-r3.ebuild | 864 profiles/base/make.defaults | 2 +- profiles/desc/perl_features.desc| 9 + 3 files changed, 874 insertions(+), 1 deletion(-) create mode 100644 dev-lang/perl/perl-5.38.2-r3.ebuild create mode 100644 profiles/desc/perl_features.desc diff --git a/dev-lang/perl/perl-5.38.2-r3.ebuild b/dev-lang/perl/perl-5.38.2-r3.ebuild new file mode 100644 index ..2aadb0bdd96a --- /dev/null +++ b/dev-lang/perl/perl-5.38.2-r3.ebuild @@ -0,0 +1,864 @@ +# Copyright 1999-2024 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit alternatives flag-o-matic toolchain-funcs multilib multiprocessing + +PATCH_VER=1 +CROSS_VER=1.5.2 +PATCH_BASE="perl-5.38.0-patches-${PATCH_VER}" +PATCH_DEV=dilfridge + +DIST_AUTHOR=PEVANS + +# Greatest first, don't include yourself +# Devel point-releases are not ABI-intercompatible, but stable point releases are +# BIN_OLDVERSEN contains only C-ABI-intercompatible versions +PERL_BIN_OLDVERSEN="" + +if [[ "${PV##*.}" == "" ]]; then + DIST_VERSION=5.30.0 +else + DIST_VERSION="${PV/_rc/-RC}" +fi +SHORT_PV="${DIST_VERSION%.*}" + +# Even numbered major versions are ABI intercompatible +# Odd numbered major versions are not +if [[ $(( ${SHORT_PV#*.} % 2 )) == 1 ]]; then + SUBSLOT="${DIST_VERSION%-RC*}" +else + SUBSLOT="${DIST_VERSION%.*}" +fi + +# Used only in tar paths +MY_P="perl-${DIST_VERSION}" +# Used in library paths +MY_PV="${DIST_VERSION%-RC*}" + +DESCRIPTION="Larry Wall's Practical Extraction and Report Language" + +HOMEPAGE="https://www.perl.org/"; + +SRC_URI=" + mirror://cpan/src/5.0/${MY_P}.tar.xz + mirror://cpan/authors/id/${DIST_AUTHOR:0:1}/${DIST_AUTHOR:0:2}/${DIST_AUTHOR}/${MY_P}.tar.xz + https://github.com/gentoo-perl/perl-patchset/archive/refs/tags/${PATCH_BASE}.tar.gz + https://dev.gentoo.org/~${PATCH_DEV}/distfiles/${PATCH_BASE}.tar.gz + https://github.com/arsv/perl-cross/releases/download/${CROSS_VER}/perl-cross-${CROSS_VER}.tar.gz +" + +S="${WORKDIR}/${MY_P}" + +LICENSE="|| ( Artistic GPL-1+ )" + +SLOT="0/${SUBSLOT}" + +if [[ "${PV##*.}" != "" ]] && [[ "${PV/rc//}" == "${PV}" ]] ; then + KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~amd64-linux ~x86-linux ~arm64-macos ~ppc-macos ~x64-macos ~x64-solaris" +fi + +IUSE="berkdb perl_features_debug doc gdbm perl_features_ithreads minimal perl_features_quadmath" + +RDEPEND=" + berkdb? ( sys-libs/db:= ) + gdbm? ( >=sys-libs/gdbm-1.8.3:= ) + app-arch/bzip2 + >=sys-libs/zlib-1.2.12 + virtual/libcrypt:= +" +DEPEND="${RDEPEND}" +BDEPEND="${RDEPEND}" + +PDEPEND=" + >=app-admin/perl-cleaner-2.30 + !minimal? ( + >=virtual/perl-CPAN-2.290.0 + >=virtual/perl-Encode-3.120.0 + >=virtual/perl-File-Temp-0.230.400-r2 + >=virtual/perl-Data-Dumper-2.154.0 + >=virtual/perl-Math-BigInt-1.999.842 + virtual/perl-Test-Harness + ) +" +# bug 390719, bug 523624 +# virtual/perl-Test-Harness is here for the bundled ExtUtils::MakeMaker + +dual_scripts() { + src_remove_dual perl-core/Archive-Tar2.400.0 ptar ptardiff ptargrep + src_remove_dual perl-core/CPAN 2.360.0 cpan + src_remove_dual perl-core/Digest-SHA 6.40.0shasum + src_remove_dual perl-core/Encode 3.190.0 enc2xs piconv + src_remove_dual perl-core/ExtUtils-MakeMaker 7.700.0 instmodsh + src_remove_dual perl-core/ExtUtils-ParseXS 3.510.0 xsubpp + src_remove_dual perl-core/IO-Compress2.204.0 zipdetails + src_remove_dual perl-core/JSON-PP4.160.0json_pp + src_remove_dual perl-core/Module-CoreList5.202.311.290 corelist + src_remove_dual perl-core/Pod-Checker1.750.0 podchecker + src_remove_dual perl-core/Pod-Perldoc3.280.100 perldoc + src_remove_dual perl-core/Pod-Usage 2.30.0 pod2usage + src_remove_dual perl-core/Test-Harness 3.440.0 prove + src_remove_dual perl-core/podlators 5.10.0 pod2man pod2text + src_remove_dual_man perl-core/podlators 5.10.0 /usr/share/man/man1/perlpodstyle.1 +} + +check_rebuild() { + # Fresh install + if [[ -z "${REPLACING_VERSIONS}" ]]; then +
Re: [gentoo-dev] New project: binhost
> Some ideas for portage enhancements: > > 1. Ability to fetch binary packages from some kind of repo. > 2. Ability to have multiple binary packages co-exist in a repo (local > or remote) with different build attributes (arch, USE, CFLAGS, > DEPENDS, whatever). > 3. Ability to pick the most appropriate binary packages to use based > on user preferences (with a mix of hard and soft preferences). The more definite answer should come from Zac, but I think a good part of this is already implemented. :) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] New project: binhost
Hi all, I'm announcing a new project here - "binhost" "The Gentoo Binhost project aims to provide readily installable, precompiled packages for a subset of configurations, via central binary package hosting. Currently we are still in the conceptual planning stage. " https://wiki.gentoo.org/wiki/Project:Binhost If you're interested in helping out, feel free to add yourself on the wiki page. Note that I see actually *building* the packages not as the central point of the project (that could be e.g. a side effect of a tinderbox). I'm more concerned about * what configurations should we use * what portage features are still needed or need improvements (e.g. binpkg signing and verification) * how should hosting look like * and how we can test this on a limited scale before it goes "into production" * ... Comments, ideas, flamebaits? :D Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?
Am Freitag, 8. Januar 2021, 14:26:32 EET schrieb Joonas Niilola: > # Now my question is, does anyone find any of these packages useful? > Should we go ahead and last-rite them, since it doesn't seem useful to > carry these in Gentoo? The ones broken are heading towards last-riting > nevertheless. We have done such cleanups in the past. Libraries without consumers in the Gentoo tree make in general only limited sense. That said, if they build and have an active maintainer, why not keep them for now. This is more or less a cost/benefit question. > > # So the final list of "useless" libs is: > dev-libs/atcore > dev-libs/bcm2835 > dev-libs/bitset > dev-libs/boost-mpl-cartesian_product > dev-libs/caliper > dev-libs/clhpp > dev-libs/distorm64 > dev-libs/editline > dev-libs/faxpp > dev-libs/go-usb > dev-libs/gtx > dev-libs/igraph > dev-libs/ilbc-rfc3951 > dev-libs/injeqt > dev-libs/jthread > dev-libs/kqoauth > dev-libs/libdivsufsort > dev-libs/libdnsres > dev-libs/libezV24 > dev-libs/libgcrypt-compat > dev-libs/libpcre-debian > dev-libs/libtomfloat > dev-libs/libtompoly > dev-libs/libtreadstone > dev-libs/log4sh > dev-libs/nss-pem > dev-libs/OpenSRF > dev-libs/pigpio > dev-libs/processor-trace > dev-libs/rapidxml > dev-libs/redland-bindings > dev-libs/rinutils > dev-libs/rocm-hostcall > dev-libs/smack > dev-libs/squareball > dev-libs/ustr > dev-libs/vc-intrinsics > dev-libs/xbyak > dev-libs/zookeeper-c > media-libs/cimg > media-libs/elles_icc_profiles > media-libs/esdl > media-libs/fluidsynth-dssi > media-libs/freeverb3 > media-libs/gmtk > media-libs/gnonlin > media-libs/guilib > media-libs/intel-mediasdk > media-libs/kodi-platform > media-libs/libggigcp > media-libs/libggimisc > media-libs/libgroove > media-libs/liblingoteach > media-libs/libyami > media-libs/memphis > media-libs/noise-suppression-for-voice > media-libs/raul > media-libs/sdl-terminal > media-libs/volpack > > > -- juippis -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Dissolving project desktop-misc
> > x11-misc/xsnow > And this one of course. There's a version bump available that works in modern window managers. :) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Dissolving project desktop-misc
> x11-misc/xosview > x11-misc/xteddy Taking these two. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Dissolving project desktop-misc
Am Donnerstag, 26. November 2020, 22:20:55 EET schrieb Jonas Stein: > Dear all, > > sorting packages in a group of "misc" packages was not useful. > We have to dissolve the project desktop-misc [snip] List of packages, please adopt: app-admin/usbview app-editors/beaver app-misc/banner app-misc/emelfm2 app-misc/gentoo app-misc/logitech-applet app-misc/oneko app-misc/remind app-text/xchm dev-util/regexxer gnome-extra/synapse sys-apps/mount-gtk sys-apps/pmount-gui www-client/dillo www-plugins/adobe-flash (last rited) x11-apps/amlc x11-libs/c++-gtk-utils x11-libs/fltk x11-misc/3ddesktop x11-misc/accessx x11-misc/apwal x11-misc/arandr x11-misc/autocutsel x11-misc/bbacpi x11-misc/cairo-clock x11-misc/cbatticon x11-misc/chgres x11-misc/dclock x11-misc/devilspie x11-misc/devilspie2 x11-misc/dunst x11-misc/dxpc x11-misc/dzen x11-misc/easystroke x11-misc/efax-gtk x11-misc/evolvotron x11-misc/fbpanel x11-misc/fireflies x11-misc/fracplanet x11-misc/fraqtive x11-misc/gbase x11-misc/gmrun x11-misc/grabc x11-misc/grun x11-misc/gtk2fontsel x11-misc/gtkdialog x11-misc/gxmessage x11-misc/habak x11-misc/hsetroot x11-misc/i3lock x11-misc/i3status x11-misc/i855crt x11-misc/iconbox x11-misc/idesk x11-misc/imwheel x11-misc/kapow x11-misc/lineak-defaultplugin x11-misc/lineak-xosdplugin x11-misc/lineakd x11-misc/macopix x11-misc/menulibre x11-misc/mgm x11-misc/nitrogen x11-misc/numlockx x11-misc/openbox-menu x11-misc/parcellite x11-misc/piedock x11-misc/read-edid x11-misc/rofi x11-misc/rss-glx x11-misc/simpleswitcher x11-misc/sisctrl x11-misc/skippy x11-misc/sselp x11-misc/superswitcher x11-misc/sux x11-misc/svkbd x11-misc/synergy x11-misc/trayer x11-misc/unclutter x11-misc/vnc2swf x11-misc/vym x11-misc/wayv x11-misc/wbar x11-misc/wdm x11-misc/wininfo x11-misc/x2vnc x11-misc/x2x x11-misc/xautolock x11-misc/xautomation x11-misc/xbatt x11-misc/xbattbar x11-misc/xbindkeys x11-misc/xcalendar x11-misc/xcave x11-misc/xcb x11-misc/xclip x11-misc/xdaliclock x11-misc/xdesktopwaves x11-misc/xdialog x11-misc/xdiskusage x11-misc/xdotool x11-misc/xearth x11-misc/xfe x11-misc/xfishtank x11-misc/xhkeys x11-misc/xkbd x11-misc/xkeycaps x11-misc/xlockmore x11-misc/xmountains x11-misc/xnee x11-misc/xnots x11-misc/xosview x11-misc/xpad x11-misc/xplanet x11-misc/xrestop x11-misc/xrootconsole x11-misc/xscreensaver x11-misc/xscreensaver-app x11-misc/xsel x11-misc/xsensors x11-misc/xsetleds x11-misc/xsnap x11-misc/xsnow x11-misc/xsri x11-misc/xstroke x11-misc/xteddy x11-misc/xtoolwait x11-misc/xtrlock x11-misc/xvkbd x11-misc/xwit x11-misc/xwrits x11-misc/xxkb x11-terms/guake x11-terms/lilyterm x11-terms/sakura x11-themes/blueglass-xcursors x11-themes/faenza-icon-theme x11-themes/flatsvg x11-themes/fvwm-themes-extra x11-themes/gargantuan-icon-theme x11-themes/gartoon x11-themes/gartoon-redux x11-themes/gnome-colors-common x11-themes/gnome-colors-themes x11-themes/golden-xcursors x11-themes/greybird x11-themes/gtk-engines-aurora x11-themes/gtk-engines-candido x11-themes/gtk-engines-rezlooks x11-themes/gtk-engines-ubuntulooks x11-themes/gtk-theme-switch x11-themes/haematite-xcursors x11-themes/human-icon-theme x11-themes/nimbus x11-themes/nou-icon-theme x11-themes/nuovo-icon-theme x11-themes/obsidian-xcursors x11-themes/pearlgrey-xcursors x11-themes/redhat-artwork x11-themes/shiki-colors x11-themes/silver-xcursors x11-themes/tactile x11-themes/tactile3 x11-themes/tangerine-icon-theme x11-themes/yasis-icon-theme x11-themes/zukini -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] A feedback about the CI bug reporting system
Am Samstag, 7. November 2020, 10:26:27 EET schrieb Agostino Sarubbo: > On sabato 7 novembre 2020 07:15:31 CET Robin H. Johnson wrote: > > Can you please tell us what you need to let others contribute to > > improving the quality of the reports from your CI system? > > Hello Robin, > > I don't understand why in general people focus on what is missing into a > simple script that merges packages instead of ask himself where this feature > should go. Ago, this whole thread started out about the quality of the bug reports. However... Seriously, with the insistence to keep your setup closed-source, you are not helping your case. If you want this to be an in any way official Gentoo project, you'll have to stick to the Gentoo social contract just like everyone else. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
For the record, > net-dns/libidn2 * added also toolchain (glibc dependency) > net-misc/chrony * added also base-system -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Deprecating AMD64 17.0 profiles?
Am Donnerstag, 22. Oktober 2020, 18:44:48 EEST schrieb Michał Górny: > On Thu, 2020-10-22 at 11:17 -0400, Brian Evans wrote: > > 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. Independent of this useful change, it's probably time to deprecate the amd64 17.0 profiles! -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] news item: riscv multilib profile is going away
[** Note 1: This only affects one specific profile. **] [** Note 2: I am still testing the migration process proposed here. **] Title: riscv multilib profile is going away Author: Andreas K. Hüttel Posted: 2020-09-06 Revision: 1 News-Item-Format: 2.0 Display-If-Profile: default/linux/riscv/17.0/rv64gc The Gentoo RISC-V team is discontinuing the riscv64 multilib stages and profile. The main reason for this is that with the upcoming introduction of riscv32 a multilib stage would contain both 32bit and 64bit binaries, and so far no hardware exists that is able to run both and thus update the stage or installation (unless you use qemu). Please switch to the rv64gc/lp64d profile. This is done by * selecting default/linux/riscv/17.0/rv64gc/lp64d with eselect profile * rebuilding gcc emerge -1 sys-devel/gcc * and then rebuilding your system emerge -ev @world The default/linux/riscv/17.0/rv64gc profile will stop functioning soon. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Fwd: [JuliaLang] Pkg downtime incident
email/unsubscribe/ 5dcc8fe0a5dab8380516e5d33481407163067880c0e37e4db5d9c1772dabf1d2). - -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: sys-kernel/genkernel-next
# Andreas K. Hüttel (2020-07-11) # Fails to build with recent glibc, bug 719968 # Removal in 30 days sys-kernel/genkernel-next -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last 24h for voting in council election
Hi all, the last 24 for voting in the council election start soon... GO VOTE :) Cheers -A -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Codec project
> 1. Should the project be focused on reference/most common > implementations, or maybe more of them? Say, giflib vs libnsgif. > I think the latter library is specific to a few programs right now but > if it gets more popular, it would fit. It's mostly a question of critical mass. To give an example from a different corner of Gentoo... Initially net-libs/libtirpc was more of an obscurity, a more feature-complete replacement for code within glibc. Back then it didn't matter so much who maintained it. In the meantime, the corresponding part of glibc has been phased out, and everyone is relying on libtirpc. So now it's important that it is well- maintained, and it's taken care of by base@. > 2. How many kinds of media should the project accept? Audio, graphics, > video seem pretty obvious. Containers too. libass makes sense as it is > specifically for video subtitles. Anything else? Again, critical mass should be the main criterion. Things that are used by many different packages, with many different maintainers. If a library is only used by LibreOffice, it makes more sence that it is maintained by office@. If a library is used exclusively via kde-frameworks, the same for kde@. I wouldn't be too restrictive regarding the type of media. > 3. What about libraries implementing media-specific streaming protocols? > E.g. libshout, live... I suppose the ones specific to voip would fall > into voip project's domain instead. Same arguments... > > > [1] > https://archives.gentoo.org/gentoo-dev/message/79073ab9c7cebd79fc12e897e110 > bc3c [2] https://wiki.gentoo.org/wiki/Project:Codec_project -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
Am Montag, 8. Juni 2020, 19:02:51 EEST schrieb Michał Górny: > Maybe it'd make sense to create a new project that is focused > on maintaining core libraries for gfx/audio/video formats (technical > name: codec project)? Right now, sound and video teams are also > suffering from similar problems. On one hand, it makes little sense to > create huge projects that maintain every single kind of gfx/sound/video- > related tool ever made, on the other it doesn't exactly make sense to > require every single core library to have an individual maintainer. Count me in. https://wiki.gentoo.org/wiki/Project:Codec_project Here's the page. I consider this started once 3 other people have joined... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
> Project Graphics was now deleted Inofficially a graphics@ maintainership of a package meant "fix the bugs yourself" for quite some time already. So I doubt the current state got worse via the removal of the project. That said, this is actually for a subset of the packages one of the cases where a project would really make sense. We have a lot of central libraries here that are used by many other software. libpng, jpeg, tiff, ... These are definitely worth a team of maintainers. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
> Now for the future, I wouldn't mind having a "last rite: XYV Project" or > similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is > taken, so the project members/lead has one final chance to stop it. Good plan. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
OK so if you really want to go through with this then I'll take these. > media-gfx/album > media-gfx/enblend > media-gfx/exiv2 > media-gfx/gphoto2 > media-gfx/hugin > media-gfx/imagemagick > media-gfx/jpeg2ps > media-gfx/jhead > media-gfx/luminance-hdr > media-gfx/pngquant > media-libs/lensfun > media-libs/libgphoto2 That said, I think the basic action is in this case pretty unproductive. We now have a large number of central libraries maintainer-needed (libpng, jpeg, tiff, ...) which would really merit a team... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
> Works great for whom? How many deployments are we talking about? To be > honest, I don't think I've stumbled upon a single instance. > On the other hand, GitLab deployments are pretty common -- GNOME, Xfce, > Debian come instantly to my mind. Then, there's Heptapod -- the GitLab > fork for Mercurial. KDE also just migrated to GitLab. > > > Gerrit is widely used for large projects and I'm not worried for ::gentoo > > and we have deployed gerrit and it seems to work fine. Gerrit doesn't have > > CI (we would need to deploy something) and it uses gitweb for repository > > browsing (which we use today.) > > Not to mention it's ugly and I found it cumbersome to use. Everytime I tried to use Gerrit I got so thouroughly confused that I gave up after a while. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
> This patch makes migrating mandatory by forcing ebuilds to die if they > have EGO_VENDOR set and are using go-module.eclass. You can't commit this as long as there is a single such ebuild in the tree. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [gentoostats continued] Collected data and justification for it
> > I think we shouldn't collect any data unless we have a good plan on how > we'd be able to use it. In this thread, I'd like to collect ideas > on what data to collect and how it could realistically be used. > 5) CFLAGS and possibly related variables 6) "active" version of slotted system packages (gcc, binutils, python, ???) I see this as interesting for the toolchain maintenance, but also interesting in general since we are a source-based distro. * How many users are running LTO? doing Profiling? building generic (- march=x86_64) packages? using -Os or -O3, -funroll-loop (just kidding) * How quick is gcc / binutils / ... adoption? * clang usage? -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] De-stabilizing and re-stabilizing (on amd64 only)
Hi all, quite some packages were un-stabilized across the tree recently. In general that is in my opinion a good thing if it helps us keep up, in particular where many arches are involved. What's the general opinion on re-stabilizing things on *amd64* only? I would say that maintaining a larger stable tree is comparatively easy there, since everyone of us devs is running (I guess) an amd64 machine and can stabilize own packages. Background, I tried to locally emulate www.g.o using jekyll, and ran into troubles because lots of dev-ruby/* lost stable keywords. Newest ~arch didn't do the job, so I needed to figure out the config of www.g.o (corresponding to former stable) first... Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
Hey all, our installation handbook is right now something of a mess (in particular regarding partitioning, bootloader, gpt/uefi, ...) I'm hereby volunteering to clean things up. But - I'll go the brutal way: * Legacy boot and MBR will get kicked out. * This is your chance to protest or support. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-tex/revtex
# Andreas K. Hüttel (2020-05-02) # Included in recent texlive versions. Please uninstall. # Removal in 30 days. dev-tex/revtex -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
Am Sonntag, 26. April 2020, 12:09:59 EEST schrieb Ulrich Mueller: > >>>>> On Sun, 26 Apr 2020, Michał Górny wrote: > > The other major problem is spam protection. The best semi-anonymous way > > I see is to use submitter's IPv4 addresses (can we support IPv6 then?). > > We could set a limit of, say, 10 submissions per IPv4 address per week. > > If some address would exceed that limit, we could require CAPTCHA > > authorization. > > Instead of using the IP address, you could generate a UUID when > installing the tool. This would also take care of clusters with machines > that are clones of each other. > TBH, for clusters I would insert a sentence like "If you are administering a cluster of many identical Gentoo machines, please see $WIKIPAGE before enabling submission" and there then have a few more instructions (like how to enable only for one machine, and additionally provide us with the cluster size). I guess in this case we can add this further step, since whoever is doing that will be both invested in Gentoo and able to read docs. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla
> let's > add a 'CC-ARCHES' keyword to Bugzilla. If a bug is marked with that > keyword and passes sanity check, NATTkA will automatically CC all > relevant arch teams (based on keyword list). > > What do you think? Sounds great. Do it! :) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states
> > [Maybe someone who actually does slow-arch work should speak up. Anyone > > out > > there still reading g-dev?] > > I'm lost. The original definition said that this state is for arches > that use stable only on subset of packages needed for stage building. > Why would people file streqs for other packages then? Shrug. I'm not going to fight here for anything. Just my experience after some arches lost stable status was that these arch people still wanted to get CC'ed in stabilization requests. If only to keep track. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states
> +Transitional architectures are generally listed after stable architectures, > +possibly mixed with testing. Developers are not expected to file > stabilization +requests. I'm still claiming that it would be more useful to have the stable requests for transitional arches, even if we explicitly state that they can't block anything. Otherwise these arches will never be able to get out of the transitional hole. [Maybe someone who actually does slow-arch work should speak up. Anyone out there still reading g-dev?] -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 03/10] glep-0072: Rename bad depgraph state to 'degraded'
Am Samstag, 11. April 2020, 14:23:48 EEST schrieb Michał Górny: > On Sat, 2020-04-11 at 12:08 +0200, Ulrich Mueller wrote: > > > > > > > On Sat, 11 Apr 2020, Michał Górny wrote: > > > Thinking about it, all these terms seem too generic. Would be nice to > > > find one that clearly suggests it's between testing and stable, and not > > > 'lenient' in ~arch. How about 'transitional' or 'incomplete-stable'? > > > > "interim"? > > half-ass-stable? ;-) transcendent ... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 00/10] GLEP 72 (arches.desc) revival
> > => Keep it simple: Stable should mean the same across all architectures OK, this is a definite statement, so stable remains stable, and we introduce no additionally different status. I'd recommend that you drop the "security-supported arches" list from the security team web page too. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 07/10] glep-0072: Combine and amend description of states
> > "Developers should file stabilization requests, however, pending > > stabilization on these arches alone cannot block any further steps (as, > > e.g., cleanup of old versions)." > > Isn't that implied by exp status, i.e. separate from this? Hmm... do all "degraded" profiles have to be "exp"? (Need to get the coffee first.) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 00/10] GLEP 72 (arches.desc) revival
Am Freitag, 10. April 2020, 09:58:37 EEST schrieb Michał Górny: > > 1. 'Broken' status was removed, as it is redundant to profile status. > > 2. State names were changed from 'testing' and 'unstable' to 'degraded' >(broken stable tree) and 'testing' (pure ~arch) to avoid confusion. > Back in time there was also the idea to use this file to indicate security support of an arch. The suggestion was to introduce another column, but I found that rather horrible. So a better idea would be to introduce an additional status "security", designating "stable with security support". (Acts in every other respect exactly like "stable".) What do you think? -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 07/10] glep-0072: Combine and amend description of states
Am Freitag, 10. April 2020, 09:58:44 EEST schrieb Michał Górny: > Developers are not expected to file > stabilization +requests. This kinda changed in usage in the meantime (for, say, stuff like sparc and s390). The request was to CC them in the stabilization bugs if relevant. How about "Developers should file stabilization requests, however, pending stabilization on these arches alone cannot block any further steps (as, e.g., cleanup of old versions)." -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] depend.apache.eclass rework, try 2
Here's a fresh attempt to improve depend.apache.eclass; this time some of the ideas from dwfreed's patch are implemented. The initialization of two variables is shifted from global scope to pkg_setup. We still remain with one eclass though (and what I haven't used is the new dependency/useflag code there, since it changes the interface). Impact... right now only 4 ebuilds in the tree use depend.apache.eclass with EAPI=6. Two of them use depend.apache.eclass directly, and none of the variables is present in the ebuild. Two use it via apache-module.eclass, but that eclass only uses the affected variables in phase functions.
[gentoo-dev] [PATCH 3/5] depend.apache.eclass: Add missing function want_apache2_4
--- eclass/depend.apache.eclass | 17 + 1 file changed, 17 insertions(+) diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass index e858a85..a51ec55 100644 --- a/eclass/depend.apache.eclass +++ b/eclass/depend.apache.eclass @@ -225,6 +225,23 @@ want_apache2_2() { RDEPEND="${RDEPEND} ${myiuse}? ( ${APACHE2_2_DEPEND} )" } +# @FUNCTION: want_apache2_4 +# @USAGE: [myiuse] +# @DESCRIPTION: +# An ebuild calls this to get the dependency information for optional +# apache-2.4.x support. If the myiuse parameter is not given it defaults to +# apache2. +# An ebuild should additionally call depend.apache_pkg_setup() in pkg_setup() +# with the same myiuse parameter. +want_apache2_4() { + debug-print-function $FUNCNAME $* + + local myiuse=${1:-apache2} + IUSE="${IUSE} ${myiuse}" + DEPEND="${DEPEND} ${myiuse}? ( ${APACHE2_4_DEPEND} )" + RDEPEND="${RDEPEND} ${myiuse}? ( ${APACHE2_4_DEPEND} )" +} + # @FUNCTION: need_apache # @DESCRIPTION: # An ebuild calls this to get the dependency information for apache. -- 2.11.0.rc2
[gentoo-dev] [PATCH 2/5] depend.apache.eclass: Disallow EAPI=1
--- eclass/depend.apache.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass index a7d206f..e858a85 100644 --- a/eclass/depend.apache.eclass +++ b/eclass/depend.apache.eclass @@ -43,7 +43,7 @@ inherit multilib case ${EAPI:-0} in - 0|1|2|3|4|5) + 0|2|3|4|5) ;; 6) ewarn -- 2.11.0.rc2
[gentoo-dev] [PATCH 5/5] depend.apache.eclass: Restructure pkg_setup so in_iuse is used from EAPI=6 on
--- eclass/depend.apache.eclass | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass index 8582396..2d7b062 100644 --- a/eclass/depend.apache.eclass +++ b/eclass/depend.apache.eclass @@ -176,21 +176,28 @@ depend.apache_pkg_setup() { fi local myiuse=${1:-apache2} - if has ${myiuse} ${IUSE}; then - if use ${myiuse}; then - case ${EAPI:-0} in - 0|2|3|4|5) + + case ${EAPI:-0} in + 0|2|3|4|5) + if has ${myiuse} ${IUSE}; then + if use ${myiuse}; then _init_apache2 - ;; - *) + else + _init_no_apache + fi + fi + ;; + *) + if in_iuse ${myiuse}; then + if use ${myiuse}; then _init_apache2 _init_apache2_late - ;; - esac - else - _init_no_apache - fi - fi + else + _init_no_apache + fi + fi + ;; + esac } # @FUNCTION: want_apache -- 2.11.0.rc2
[gentoo-dev] [PATCH 1/5] depend.apache.eclass: Replace build_with_use with has_version
From: Doug Freed --- eclass/depend.apache.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass index b69c2ec..a7d206f 100644 --- a/eclass/depend.apache.eclass +++ b/eclass/depend.apache.eclass @@ -290,7 +290,7 @@ has_apache() { has_apache_threads() { debug-print-function $FUNCNAME $* - if ! built_with_use www-servers/apache threads; then + if ! has_version 'www-servers/apache[threads]'; then return fi @@ -313,14 +313,14 @@ has_apache_threads() { has_apache_threads_in() { debug-print-function $FUNCNAME $* - if ! built_with_use www-servers/apache threads; then + if ! has_version 'www-servers/apache[threads]'; then return fi local myforeign="$1" local myflag="${2:-threads}" - if ! built_with_use ${myforeign} ${myflag}; then + if ! has_version "${myforeign}[${myflag}]"; then echo eerror "You need to enable USE flag '${myflag}' in ${myforeign} to" eerror "build a thread-safe version of ${CATEGORY}/${PN} for use" -- 2.11.0.rc2
[gentoo-dev] [PATCH 4/5] depend.apache.eclass: For EAPI=6, move initialization of APACHE_BASEDIR and APACHE_MODULESDIR into pkg_setup
--- eclass/depend.apache.eclass | 35 --- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass index a51ec55..8582396 100644 --- a/eclass/depend.apache.eclass +++ b/eclass/depend.apache.eclass @@ -40,17 +40,11 @@ # } # @CODE -inherit multilib - case ${EAPI:-0} in 0|2|3|4|5) + inherit multilib ;; 6) - ewarn - ewarn "EAPI=${EAPI} is not supported by depend.apache.eclass." - ewarn "This means that ${CATEGORY}/${PF} is most likely buggy." - ewarn "Please file a report on https://bugs.gentoo.org/"; - ewarn ;; *) die "EAPI=${EAPI} is not supported by depend.apache.eclass" @@ -84,7 +78,8 @@ esac # @ECLASS-VARIABLE: APACHE_BASEDIR # @DESCRIPTION: # Path to the server root directory. -# This variable is set by the want/need_apache functions. +# This variable is set by the want/need_apache functions (EAPI=0 through 5) +# or depend.apache_pkg_setup (EAPI=6 and later). # @ECLASS-VARIABLE: APACHE_CONFDIR # @DESCRIPTION: @@ -104,7 +99,8 @@ esac # @ECLASS-VARIABLE: APACHE_MODULESDIR # @DESCRIPTION: # Path where we install modules. -# This variable is set by the want/need_apache functions. +# This variable is set by the want/need_apache functions (EAPI=0 through 5) +# or depend.apache_pkg_setup (EAPI=6 and later). # @ECLASS-VARIABLE: APACHE_DEPEND # @DESCRIPTION: @@ -141,10 +137,19 @@ _init_apache2() { APACHE_BIN="/usr/sbin/apache2" APACHE_CTL="/usr/sbin/apache2ctl" APACHE_INCLUDEDIR="/usr/include/apache2" - APACHE_BASEDIR="/usr/$(get_libdir)/apache2" APACHE_CONFDIR="/etc/apache2" APACHE_MODULES_CONFDIR="${APACHE_CONFDIR}/modules.d" APACHE_VHOSTS_CONFDIR="${APACHE_CONFDIR}/vhosts.d" + + case ${EAPI:-0} in + 0|2|3|4|5) + _init_apache2_late + ;; + esac +} + +_init_apache2_late() { + APACHE_BASEDIR="/usr/$(get_libdir)/apache2" APACHE_MODULESDIR="${APACHE_BASEDIR}/modules" } @@ -173,7 +178,15 @@ depend.apache_pkg_setup() { local myiuse=${1:-apache2} if has ${myiuse} ${IUSE}; then if use ${myiuse}; then - _init_apache2 + case ${EAPI:-0} in + 0|2|3|4|5) + _init_apache2 + ;; + *) + _init_apache2 + _init_apache2_late + ;; + esac else _init_no_apache fi -- 2.11.0.rc2
Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Montag, 15. August 2016, 15:03:08 schrieb Kristian Fiskerstrand: > On 08/15/2016 02:49 PM, Dirkjan Ochtman wrote: > > On Mon, Aug 15, 2016 at 6:29 AM, Kent Fredric wrote: > >> This sort of stuff makes me feel bugzilla is entirely the wrong platform > >> for handling stabilizations and keywords :/ > > > > I very much agree; some kind of minimal web app/API would probably be > > better. > > Could you please elaborate a bit? In particular from perspective of (i) > integration into current workflow, (ii) complexity in application > maintenance/hosting (iii) cost/benefit considerations I agree that BZ is not the best platform for stabilizations (and keywording). (It's the one we have now, anything else creates maintenance.) Now, if we want to come up with radical solutions... 1) Stabilization is a simpler and much more formalized process compared to normal bug resolution. * There is one version to be stabilized. * Stabilization can be blocked by bugs of that version. * If there are no blocking bugs, stabilization can go ahead. Which means * No requirement for free-text fields * One precise package version Of course this does not handle the more complex cases like perl/gnome stable lists. 2) *If* we introduce a "Fixed-in" and maybe an "Introduced-in" field in Bugzilla, which gives a precise $CATEGORY/$PVR where a problem is resolved or introduced, the extraction of fixed or non-fixed bugs might even be automatized. - -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXshg9AAoJEHRrah2soMK+JawQAK7c2oizH6Vu4EgDpr05y1Fi BWFvJrqxdgyvUCxwaZMk90j88zlXvvXkbZR6xMxZytZPpXh5FVtadVmElqYJIXiD G71Gqf0dDMuH9sku7rU9Mmm5WIzJtG0WE2b/FIddG8C5BpuaiqhDKUZcnvW5r3BW CoLqYWfG5W5A0DiKuZbbTI4jIeHLd8BykitB8dGhT3Lvse52IAMY+9X/BCLfX0lh WjBh4LszaEIK11zD/EEqSpCd8q6t2A52h//Xpe4a8vrY4fyvxbnULYxm088UBMuV oOZ5cLKUSqx7BqaDoPaY5vYPBXbQkKsPFDkzEx2B115Ep9fPGpom+MrcLN3JCmL7 fk6R+K9eeACZPHqf2WiNICKnN/l6NQVrrPukDgDWZ9vGvSr1XjhnMdiKVuWOaJki 0vmYtaLJF0Aadwzwp93u/Ii1HIiy7nPU9om3LSOLMnrGbq4I9YzCiX0Az98zCPQw DABWDOPSdNnkqwexhmlhl9xkO0LDpjbMtWlKufZY9y1mOXUatAK38iD6mcErRuxI dSz/odmpwpmNvIx7yPc1TwRKkn7Hmr/DkHecMMnmEfqqFn2cy1FkQIMvntx5kLTY NfS8n90UqCPcZ66xgr5MhxQMV0GKfCwQ1uS4pr9spnVUXyT/gGTnPUs8dswcFA2e ZyTnnA+fS3uFot25Sl76 =OtNn -END PGP SIGNATURE-
Re: [gentoo-dev] New Working Group established to evaluate the stable tree
Am Sonntag, 14. August 2016, 23:57:31 schrieb Ciaran McCreesh: > > I'm not sure what a group is. Is it anything like a herd? It's a set with a binary operator, with following fulfilled: * closed with respect to the operation * the operation is associative * there is a neutral element for the operation * and there's an inverse for each element The neutral element can be shown to be unique. Oh, offtopic? Sorry -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] On banning merge commits
Am Sonntag, 8. Mai 2016, 01:52:22 schrieb Patrice Clement: > > What is the correct course of action? I would very much like it to be > worded in a document (GLEP and/or Wiki page) so that confusion is avoided > and we all are on the same page on this topic. > OK here's my 2ct: * I'm not opposed to merge commits in principle, and see a few cases where they have advantages. * Git has the provisions for nonlinear history, and just not liking spaghetti is no sufficient reason to castrate the entire version control system. * However... as the past months have shown, when using merges it is much easier to accidentally mess up the entire tree than using rebases alone. * So, in an ideal world we would use merges wisely and sparingly. * In the real world, we risk less and also lose less if we ban and technically prevent them. * The only alternative would be to come up with criteria for merges and actually enforce them (meaning, if you mess up the tree more than twice you lose your push access. Hello QA.). -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] On banning merge commits
Am Sonntag, 8. Mai 2016, 07:09:31 schrieb Michał Górny: > > What is the correct course of action? I would very much like it to be > > worded in a document (GLEP and/or Wiki page) so that confusion is > > avoided and we all are on the same page on this topic. > > You start by accepting my retirement. I think you should take a vacation for a while... Preferably somewhere tropical, with no internet access and lots of beach... -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Last rites x11-libs/libview
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Andreas K. Huettel (19 Mar 2016) # Dead upstream since 2010, new VMware uses new incompatible # proprietary libview. No other consumers. Removal in 30 days. # Bug 569930 x11-libs/libview - -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJW7ZA8AAoJEHRrah2soMK+m6oQAJjwn8HtkdnKSIE1R4BqbLUd 6oJ4GeOD8Pbae2VzLEMc4xe/NiV11xyh1n/bGVf5v3x0OS3E4gMZarBHTRxkuETk XzxXkY7ZhoD1tFZX0sTmbShLMccRNPjwjc7pgc/Uq+G9atAT/KsX4WtsygGm341m GcNpcdHro0XVcFa1cPUZjJ4DyBIIEvRBgNhuXBKWPE62TRveF4NUBraU0BLRUFDw zrgGnXAc8Q7UUTV6DoO4VEOPGKSo43fpnrRziSkYw/PE4RtNqffsBtO2udozpKh/ gpQT355kAG/U9cuhj46eDq3bJMsuUdhlBOhyfLkYFACzd3KdwkKzW8cjKVzffjfW z+1R5IRvFkeInUhKPDv+TVPJJ4tmL9tkESidIESRaLbRmLN1/t1MHypk/MUPZVmE QKzUvfYUYuz2V+gNPd8Vdc65Ee84VenHstGlhfmSvzGbrL8FptxKAxaXLBcW7j60 R9C6O/BfYAvPEfenIY8e9T9Lb0zPJZIiNQMwrn7RCWXjFIRxwGIiuFBW6An8jee5 fIqdt+ZYzRj1AmFvdrIIDTzgLvQ/irKuZa5oif91T2MlKjtdBW7ys7lcI8duUADG pWo0X3vJDkg9qOsj/4rj/Ckw/JUA8ytJ+J1+NTr+By255jZHvQxwWNPQDiTdf9nk 8+wBF1N58L1WHzZwjXz0 =XyFP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: games.eclass policy
Am Samstag, 20. Februar 2016, 02:25:08 schrieb Ryan Hill: > > > > Good for you. So... ignoring majority is fine as long as you can prove > > that they don't ignore one of their old fellows. Good. > > I have never had a problem talking to the games team, and I suspect the > same is true for anyone who isn't just communicating with them to push > their agenda. Sadly that seems to be the case only for a select few. I have never had any interest in games, but was in the past downright ignored with respect to sensible, useful, more and more urgent and while at first nice, polite, and respectful, later more and more forthright e-mails and other communication attempts regarding other aspects of gentoo. There's a certain overlap of persons with the games team involved. If you're part of a community you're expected to cooperate with the community (and stick to the rules of the community, but that's a different issue). If you try to ignore everyone with a differing opinion and push your will through by just doing whatever you want, at some point you'll be so much in the minority that your opinion doesnt count anymore. -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] games.eclass deprecation - repoman warning in next portage release
Dear all, while we have taken a lot of time and called for feedback repeatedly, in the December 2015 meeting the council has decided (among other things, see [1]) * that /usr/games and /etc/games should not be used anymore * that games.eclass should not be used anymore * that games.eclass may not provide support for EAPI=6 This is to announce that starting with the next portage release, repoman will consider games.eclass deprecated and issue a QA warning if it is used in an ebuild. For the council, Andreas [1] https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] libressl: proposing a new project and calling for help
On Sunday 14 February 2016 22:38:19 Anthony G. Basile wrote: > Hi everyone, > > We discussed the state of libressl today in the council. Proceeding > forward with that work, I'm going to propose a new project and getting > together a team. Much of the work has already done by hasufell and what > remain is just following through on his plan. > > Before I put up a project page, can I ask who is interested in this? I'd gladly take part, though sadly my Gentoo time is pretty much approaching zero these days. But maybe that will improve some day. -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Uncoordinated changes
On Sunday 14 February 2016 13:18:30 Rich Freeman wrote: > > Feel free to peruse the various list discussions and council logs. > Most of what you're bringing up has come up before. Thanks rich0, you seem to be reading my mind. This is turning into a severe case of "I didn't bother to speak up earlier or volunteer to improve something, and now I'm unhappy with what was decided and implemented." -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Gentoostats
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sunday 24 January 2016 16:50:46 Göktürk Yüksek wrote: > > I don't want to go off-topic here too much but this is more than a > missing tools issue. There are privacy concerns regarding the > collection of such information. I recall this proposed idea from > Google Summer of Code: > > https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Package_stati > stics_reporting_tool This has been debated to death. As long as noone is forced to use it, privacy concerns shouldnt be a problem. And it would be extremely useful how many of our maintainer-needed packages are actually still compiled once per year. (Or if any one single person even uses KDE on ppc64.) Gentoostats is a typical stillbirth of the Gentoo Google Summer of Soon- Obsolete Code. Would I be happy if someone were to revive and actually deploy it (the last point is important!)? YES! - -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJWpPT9AAoJEHRrah2soMK+WjoP/2zsgRV565keOQdPaya/j5ak 0ga6F4xjf+XdAg4soPG+c0guN/Qz3tZtuIdDnl7NDaWBUBWGvA6DuqcKxPj3g0EQ X9EZTCigAsO+0d1F4cLMqW7JsL5YqTL4wHftzjuCqqSTD7OtX6NtOBA1namIDCoz MpmSArjjBy31oiJgDRRBDwCRAMoSErKEnkeyXVyuFyD4yV9E8PMOFcrNkeO2MFHy /Ehy0v14F5pTiGNeDnt7EDXNf5rcOFGUYTUitNyrhotUuX7sobcS9RfX2B9VtWUF pgg3zRKGJdpeKwRx3MFZZA/O8f5bPT3ne1dMLZ/LOjxgvt/CglG5G4K+iL3lFC9v WEeHj4zejXQuKlX1olWOgZdAYlt9bUmg7YO2K+OOPfQrTmqbShlnPFiAXuMTIS0h elnKY8I5e1flHbFicQg6lnT+qBriy7afYhj7WkGypzC8DAhI1N4/eROavrALCkMW nqNbEM0x4RiNdpgmdoN4L8dFBygXW73O4G8Iu5xjE1hKA6xUCmYitP3AsI5rVx1A Jt6A2edk3Zk/g584nZ07GIt4W5AceFlFhBaYxKNgAo8MZUUE5gzvcblbPTF7Si4t gTkjyXy0qabpvDBlimWxFENxGSIUqM/8N0YB1xba/FXNLn4KmTmD8Tezvze2c5Al Htxql3SYp7YaY0HFrYdx =lclI -END PGP SIGNATURE-
Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Summarizing some (not all) points from Ian's mail: The proxy-maintainers project is nowadays very active on the channel #gentoo- proxy-maint. Several new and very promising contributors are showing up there, and generating a flurry of activity. Since the initial purpose of proxy-maintainers was to allow users to pick up orphaned packages, that team has volunteered also to look at maintainer-wanted bugs. Sorting them is something that can also be done by not-yet-devs under supervision. Right now the team is discussing criteria how to handle the old bugs, see [1]. [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Wanted ### ... and here's some personal remark from me: The proxy-maint project seems to have gotten a good start now, with an active but informal community of interested users forming on the channel, submitting e.g. pull requests and discussing ebuild topics. As dev, please consider helping out there; more eyes not just improve code quality, but also response times and community coherence. Cheers, Andreas - -- Andreas K. Hüttel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJWpPAoAAoJEHRrah2soMK+yj0QAMuNz82REqd2FofJ5OAWyMNI 8giKqlB5cOIz2I14jVa2WfizQ0EP/LpVGFpAD5bVNy4/gvgFUr6fDfJfF3onhpS8 sLika3JngeGgALYB131l0flavm1jsNdE67ysxcCsb4ilsVjHw5eEOCDonRR2fMIY RmuzyH2wimH1yM9DP7MvniRDqbAFvsMWz+7UZferZF9NCAnpLJJuYD+T/jgbZ/G4 M47mc0JEkNEcenz0f/ZHKNcyG37oXz3ZCG4IWhGl93tw449xF0VQXbyxk4HAqR6C oYZPRvIXVqaou8ONcxsIqxITSaxBfNbx49oHWXKdbnMTwhO66mflZ4TegCpLBBhA 9k1oYgE7wdUGB8lg2FDecNy0sSkmHH0BZS1eYJcn6uCXor6gF+jr/LkrHPpp9OD3 XfkZ3p1CGmUUQoA908cZ8KDEP66FPmxqud+HUDAHk64ah7ohlwv2Qhe7nvvSCFPA T34MfrPm2QfQ2HZq9PSj/uagwBixovnmED/tghosJaThlLkFdc5kVSp3qiSidbT1 y8e9pOWSCm4dax6EM/MXZdW9EDHqlCPmkfeHke9vrx9Im7U6nEVMZbF8xSegjkEk hfmR8gn6otf3dbmVl/wA6SLuyTF6yaXtZyTRp/2idEKwTeLvHttzDQJaUOAoI7y+ NwRuxVUA7cfEWUMp3g/a =xyEX -END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
Ack.. both makes definitely sense. > -- Přeposlaná zpráva -- > Od: Tomáš Chvátal > Datum: 5. září 2011 18:08 > Předmět: Re: [gentoo-dev-announce] Call for items for September 13 > council meeting > Komu: gentoo-dev@lists.gentoo.org > > > Start collecting ideas for EAPI5. > > I myself would like PATCHES array to be default in src_prepare phase > and some solution for runtime optional deps, Instead of elog in > postinst something like Recommended from rpm. > > Cheers > > Tom