[gentoo-dev] [PATCH 3/3] ruby-fakegem.eclass: drop support for old EAPIs
From: Hans de Graaff
Drop support for EAPI 0, 1, 2, 3.
Signed-off-by: Hans de Graaff
---
eclass/ruby-fakegem.eclass | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index 915c10b986c3..1e8620c166d4 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -8,7 +8,7 @@
# Author: Diego E. Pettenò
# Author: Alex Legler
# Author: Hans de Graaff
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
+# @SUPPORTED_EAPIS: 4 5 6
# @BLURB: An eclass for installing Ruby packages to behave like RubyGems.
# @DESCRIPTION:
# This eclass allows to install arbitrary Ruby libraries (including Gems),
@@ -107,11 +107,13 @@ RUBY_FAKEGEM_BINDIR="${RUBY_FAKEGEM_BINDIR-bin}"
# Rails generators, or data that needs to be installed as well.
case "${EAPI:-0}" in
- 0|1|2|3|4|5|6)
- ;;
- *)
- die "Unsupported EAPI=${EAPI} (unknown) for
${ECLASS}"
- ;;
+ 0|1|2|3)
+ die "Unsupported EAPI=${EAPI} (too old) for
ruby-fakegem.eclass" ;;
+ 4|5|6)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
esac
@@ -178,8 +180,6 @@ ruby_add_rdepend virtual/rubygems
# This function returns the gems data directory for the ruby
# implementation in question.
ruby_fakegem_gemsdir() {
- has "${EAPI}" 2 && ! use prefix && EPREFIX=
-
local _gemsitedir=$(ruby_rbconfig_value 'sitelibdir')
_gemsitedir=${_gemsitedir//site_ruby/gems}
_gemsitedir=${_gemsitedir#${EPREFIX}}
--
2.21.0
[gentoo-dev] [PATCH 2/3] ruby-fakegem.eclass: List myself as author
From: Hans de Graaff Signed-off-by: Hans de Graaff --- eclass/ruby-fakegem.eclass | 1 + 1 file changed, 1 insertion(+) diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass index a6077a386b9d..915c10b986c3 100644 --- a/eclass/ruby-fakegem.eclass +++ b/eclass/ruby-fakegem.eclass @@ -7,6 +7,7 @@ # @AUTHOR: # Author: Diego E. Pettenò # Author: Alex Legler +# Author: Hans de Graaff # @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 # @BLURB: An eclass for installing Ruby packages to behave like RubyGems. # @DESCRIPTION: -- 2.21.0
[gentoo-dev] [PATCH 1/3] ruby-fakegem.eclass: remove obsolete jruby support
From: Hans de Graaff
Signed-off-by: Hans de Graaff
---
eclass/ruby-fakegem.eclass | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index e2c333a5e7f4..a6077a386b9d 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Authors
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: ruby-fakegem.eclass
@@ -39,7 +39,7 @@ RUBY_FAKEGEM_TASK_DOC="${RUBY_FAKEGEM_TASK_DOC-rdoc}"
# - rspec (calls ruby-ng_rspec, adds dev-ruby/rspec:2 to the dependencies)
# - rspec3 (calls ruby-ng_rspec, adds dev-ruby/rspec:3 to the dependencies)
# - cucumber (calls ruby-ng_cucumber, adds dev-util/cucumber to the
-#dependencies; does not work on JRuby).
+#dependencies)
# - none
RUBY_FAKEGEM_RECIPE_TEST="${RUBY_FAKEGEM_RECIPE_TEST-rake}"
@@ -159,10 +159,7 @@ case ${RUBY_FAKEGEM_RECIPE_TEST} in
;;
cucumber)
IUSE+=" test"
- # Unfortunately as of August 2012, cucumber is not supported on
- # JRuby. We work it around here to avoid repeating the same
- # code over and over again.
- USE_RUBY="${USE_RUBY/jruby/}" ruby_add_bdepend "test? (
dev-util/cucumber )"
+ ruby_add_bdepend "test? ( dev-util/cucumber )"
;;
*)
RUBY_FAKEGEM_RECIPE_TEST="none"
@@ -266,14 +263,7 @@ ruby_fakegem_gemspec_gemspec() {
# the metadata distributed by the gem itself. This is similar to how
# rubygems creates an installation from a .gem file.
ruby_fakegem_metadata_gemspec() {
- case ${RUBY} in
- *jruby)
- ${RUBY} -r yaml -e "puts
Gem::Specification.from_yaml(File::open('$1').read).to_ruby" > $2
- ;;
- *)
- ${RUBY} -r yaml -e "puts
Gem::Specification.from_yaml(File::open('$1', :encoding =>
'UTF-8').read).to_ruby" > $2
- ;;
- esac
+ ${RUBY} -r yaml -e "puts Gem::Specification.from_yaml(File::open('$1',
:encoding => 'UTF-8').read).to_ruby" > $2
}
# @FUNCTION: ruby_fakegem_genspec
@@ -332,8 +322,7 @@ ruby_fakegem_binwrapper() {
# one or multiple implementations; if we're installing for a
# *single* implementation, no need to use “/usr/bin/env ruby”
# in the shebang, and we can actually avoid errors when
- # calling the script by default (see for instance the
- # JRuby-specific commands).
+ # calling the script by default.
local rubycmd=
for implementation in $(_ruby_get_all_impls); do
# ignore non-enabled implementations
--
2.21.0
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, Jul 20, 2019 at 1:22 PM Michał Górny wrote: > > On Sat, 2019-07-20 at 23:04 +0300, Andrew Savchenko wrote: > > On Sat, 20 Jul 2019 20:28:39 +0200 Michał Górny wrote: > > > On Sat, 2019-07-20 at 20:50 +0300, Andrew Savchenko wrote: > > > > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote: > > > > > Hello, > > > > > > > > > > The QA team would like to introduce the following policy: > > > > > > > > > > """ > > > > > Packages must not disable installing manpages via USE flags (e.g. > > > > > USE=man or USE=doc). If upstream does not ship prebuilt manpages > > > > > and building them requires additional dependencies, the maintainer > > > > > should build them and ship along with the package. > > > > > """ > > > > > > > > > > > > > > > Explanatory note: > > > > > > > > > > This applies to having USE flags that specifically control building > > > > > manpages. It obviously does not affect: > > > > > > > > > > a. USE flags that disable building both a program and its manpage > > > > > (e.g. > > > > > if USE=gui disables building gfrobnicate, not installing > > > > > gfrobnicate(1) > > > > > is correct), > > > > > > > > > > b. use of LINGUAS to control installed manpages. > > > > > > > > > > > > > > > Rationale: > > > > > > > > > > Manpages are the basic form of user documentation on Gentoo Linux. > > > > > Not > > > > > installing them is harmful to our users. On the other hand, requiring > > > > > additional dependencies is inconvenient. Therefore, packaging > > > > > prebuilt > > > > > manpages (whenever upstream doesn't do that already) is a good > > > > > compromise that provides user with documentation without additional > > > > > dependencies. > > > > > > > > > > > > > > > What are your comments? > > > > > > > > The basic foundation of Gentoo is freedom of choise for our users. > > > > If installing man pages means no additional dependencies, than > > > > proposed rule is ok. However if such dependencies are required it is > > > > up to users to decide if they wan them or not. > > > > > > > > Having USE=man (or USE=doc) for such purposes is fine. Having > > > > USE=man enabled by default in user profile is also fine. Forcing > > > > users to install unnecessary dependencies on minimal systems in a > > > > no go and turns Gentoo into something else. > > > > > > > > > > Could you please read the proposed policy? It explicitly says you are > > > *not* supposed to force extra deps on users but build manpages for them. > > > > Could you please what the other developers have already replied to > > you on this matter? This will be a significant increase in > > maintenance burden for both developers and advanced users without > > much to gain. > > > > Yes, I get it. User experience is not important if it would mean > developers would actually do anything but the bare minimum to get > from one paycheck to another. The usual Gentoo attitude. I don't understand your reaction, but it's very common with predictable steps to generate it: 1) You make a proposal 2) People offer feedback and ask questions 3) You respond combatively (or not at all), as if you are upset that people perhaps are not 100% aligned with your view. ... which honestly shouldn't be at all unexpected and is precisely why requesting comments on a proposal is valuable. My question earlier in the thread is relevant and still unaddressed.
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sun, 21 Jul 2019 00:33:00 +0200 Michał Górny wrote: > On Sat, 2019-07-20 at 18:16 -0400, Rich Freeman wrote: > > On Sat, Jul 20, 2019 at 4:22 PM Michał Górny wrote: > > > > > > Yes, I get it. User experience is not important if it would mean > > > developers would actually do anything but the bare minimum to get > > > from one paycheck to another. The usual Gentoo attitude. > > > > > > > Not sure where I go to sign up for those paychecks. However, even > > employers have to accept that policies have a resource cost to them. > > > > Requiring people to do more than the bare minimum often just ensures > > that they won't even bother to do the bare minimum. I'm all for > > finding ways to standardize things so that everybody benefits at a > > very low cost. This doesn't seem that, and honestly requiring > > packages to bundle pre-built manpages seems a bit non-Gentooish to > > begin with. > > > > Then you should go and strip all those pregenerated autotools files, > and require eautoreconf from every single package. This might be a good idea, actually. Version mismatch between shipped pregenerated files and system autotools occasionally causes some problems. Best regards, Andrew Savchenko pgpcJaILmwY2y.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, 2019-07-20 at 18:16 -0400, Rich Freeman wrote: > On Sat, Jul 20, 2019 at 4:22 PM Michał Górny wrote: > > > > Yes, I get it. User experience is not important if it would mean > > developers would actually do anything but the bare minimum to get > > from one paycheck to another. The usual Gentoo attitude. > > > > Not sure where I go to sign up for those paychecks. However, even > employers have to accept that policies have a resource cost to them. > > Requiring people to do more than the bare minimum often just ensures > that they won't even bother to do the bare minimum. I'm all for > finding ways to standardize things so that everybody benefits at a > very low cost. This doesn't seem that, and honestly requiring > packages to bundle pre-built manpages seems a bit non-Gentooish to > begin with. > Then you should go and strip all those pregenerated autotools files, and require eautoreconf from every single package. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, Jul 20, 2019 at 4:22 PM Michał Górny wrote: > > > Yes, I get it. User experience is not important if it would mean > developers would actually do anything but the bare minimum to get > from one paycheck to another. The usual Gentoo attitude. > Not sure where I go to sign up for those paychecks. However, even employers have to accept that policies have a resource cost to them. Requiring people to do more than the bare minimum often just ensures that they won't even bother to do the bare minimum. I'm all for finding ways to standardize things so that everybody benefits at a very low cost. This doesn't seem that, and honestly requiring packages to bundle pre-built manpages seems a bit non-Gentooish to begin with. -- Rich
[gentoo-dev] CI now reports Python usage issues, so please fix your packages!
Hi, guys. The forwarded list contains a large number of errors in python-r1 suite usage. Please look through the list for your packages, and fix them. I'll look into reporting stuff directly once we're past the initial slew. Forwarded Message From: repomirro...@gentoo.org To: gentoo-automated-test...@lists.gentoo.org Subject: [gentoo-automated-testing] WARNING: repository still has warnings! Date: Sat, 20 Jul 2019 20:46:46 + (UTC) Message-Id: <20190720204646.bed3580...@jacamar.gentoo.org> Looks like the warning list has just changed! New warnings (84): https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-antivirus/clamtk https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-crypt/acmebot https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-crypt/yubikey-manager-qt https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-editors/atom https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-emulation/crossover-bin https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-emulation/virtualbox https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-misc/gcalcli https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-misc/pip3line https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-mobilephone/adb-sync https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-office/gnumeric https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-office/moneyguru https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-portage/gverify https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-text/referencer https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-vim/jedi https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#app-vim/vimoutliner https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-ada/gnatcoll-db https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-ada/gps https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-db/mongodb https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-lang/python-exec https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-libs/hyperscan https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-libs/libbytesize https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-libs/libcharon https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-libs/volume_key https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-python/brython https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-python/pyilmbase https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-python/pyotherside https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-python/python-caja https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-ros/costmap_2d https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-ruby/rbst https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-util/android-tools https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-util/cutter https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#dev-util/redo https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#games-arcade/commandergenius https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#games-fps/doomsday https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#games-strategy/freeorion https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#games-strategy/lightyears https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#mate-extra/caja-dropbox https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-fonts/terminus-font https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-libs/vigra https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-plugins/gimp-resynthesizer https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-sound/csound https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-sound/guitarix https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-sound/lollypop https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-sound/pithos https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#media-sound/pulseeffects https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#net-analyzer/wireshark https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#net-dns/avahi https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#net-im/spectrum2 https://qa-reports.gentoo.org/output/gentoo-ci/437ba0c/output.html#net-libs/grpc
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, 2019-07-20 at 23:04 +0300, Andrew Savchenko wrote: > On Sat, 20 Jul 2019 20:28:39 +0200 Michał Górny wrote: > > On Sat, 2019-07-20 at 20:50 +0300, Andrew Savchenko wrote: > > > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote: > > > > Hello, > > > > > > > > The QA team would like to introduce the following policy: > > > > > > > > """ > > > > Packages must not disable installing manpages via USE flags (e.g. > > > > USE=man or USE=doc). If upstream does not ship prebuilt manpages > > > > and building them requires additional dependencies, the maintainer > > > > should build them and ship along with the package. > > > > """ > > > > > > > > > > > > Explanatory note: > > > > > > > > This applies to having USE flags that specifically control building > > > > manpages. It obviously does not affect: > > > > > > > > a. USE flags that disable building both a program and its manpage (e.g. > > > > if USE=gui disables building gfrobnicate, not installing gfrobnicate(1) > > > > is correct), > > > > > > > > b. use of LINGUAS to control installed manpages. > > > > > > > > > > > > Rationale: > > > > > > > > Manpages are the basic form of user documentation on Gentoo Linux. Not > > > > installing them is harmful to our users. On the other hand, requiring > > > > additional dependencies is inconvenient. Therefore, packaging prebuilt > > > > manpages (whenever upstream doesn't do that already) is a good > > > > compromise that provides user with documentation without additional > > > > dependencies. > > > > > > > > > > > > What are your comments? > > > > > > The basic foundation of Gentoo is freedom of choise for our users. > > > If installing man pages means no additional dependencies, than > > > proposed rule is ok. However if such dependencies are required it is > > > up to users to decide if they wan them or not. > > > > > > Having USE=man (or USE=doc) for such purposes is fine. Having > > > USE=man enabled by default in user profile is also fine. Forcing > > > users to install unnecessary dependencies on minimal systems in a > > > no go and turns Gentoo into something else. > > > > > > > Could you please read the proposed policy? It explicitly says you are > > *not* supposed to force extra deps on users but build manpages for them. > > Could you please what the other developers have already replied to > you on this matter? This will be a significant increase in > maintenance burden for both developers and advanced users without > much to gain. > Yes, I get it. User experience is not important if it would mean developers would actually do anything but the bare minimum to get from one paycheck to another. The usual Gentoo attitude. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, 20 Jul 2019 20:28:39 +0200 Michał Górny wrote: > On Sat, 2019-07-20 at 20:50 +0300, Andrew Savchenko wrote: > > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote: > > > Hello, > > > > > > The QA team would like to introduce the following policy: > > > > > > """ > > > Packages must not disable installing manpages via USE flags (e.g. > > > USE=man or USE=doc). If upstream does not ship prebuilt manpages > > > and building them requires additional dependencies, the maintainer > > > should build them and ship along with the package. > > > """ > > > > > > > > > Explanatory note: > > > > > > This applies to having USE flags that specifically control building > > > manpages. It obviously does not affect: > > > > > > a. USE flags that disable building both a program and its manpage (e.g. > > > if USE=gui disables building gfrobnicate, not installing gfrobnicate(1) > > > is correct), > > > > > > b. use of LINGUAS to control installed manpages. > > > > > > > > > Rationale: > > > > > > Manpages are the basic form of user documentation on Gentoo Linux. Not > > > installing them is harmful to our users. On the other hand, requiring > > > additional dependencies is inconvenient. Therefore, packaging prebuilt > > > manpages (whenever upstream doesn't do that already) is a good > > > compromise that provides user with documentation without additional > > > dependencies. > > > > > > > > > What are your comments? > > > > The basic foundation of Gentoo is freedom of choise for our users. > > If installing man pages means no additional dependencies, than > > proposed rule is ok. However if such dependencies are required it is > > up to users to decide if they wan them or not. > > > > Having USE=man (or USE=doc) for such purposes is fine. Having > > USE=man enabled by default in user profile is also fine. Forcing > > users to install unnecessary dependencies on minimal systems in a > > no go and turns Gentoo into something else. > > > > Could you please read the proposed policy? It explicitly says you are > *not* supposed to force extra deps on users but build manpages for them. Could you please what the other developers have already replied to you on this matter? This will be a significant increase in maintenance burden for both developers and advanced users without much to gain. Best regards, Andrew Savchenko pgpAo_KyxAOs3.pgp Description: PGP signature
[gentoo-dev] Last rites: x11-themes/korilla, x11-themes/noia, x11-themes/oxygen-molecule
# Andreas Sturmlechner (2019-07-20) # Ancient theme for KDE SC 4.4, useless for Plasma 5 # Removal in 15 days x11-themes/korilla x11-themes/noia x11-themes/oxygen-molecule
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, Jul 20, 2019 at 2:28 PM Michał Górny wrote: > > Could you please read the proposed policy? It explicitly says you are > *not* supposed to force extra deps on users but build manpages for them. > This seems like a significant increase in maintainer effort compared to just leaving things as they are for very little benefit. Simple revbumps turn into needing to do a separate build just to build the manpages, then package those up, host them somewhere, then fetch and install that from the ebuild. It would be easier to just make the whole package a binary package since then all the logic happens outside the ebuild, and all the ebuild does is fetch/install a tarball, which it would have to do anyway just for the manpages. Most packages with stable build systems take almost no effort to revbump, and this would add a fair bit of complexity. I suspect that you'll find far more maintainers stop going to the trouble to strip out the dependencies needed for building manpages vs maintaining two build systems in parallel, with one having no place to host it. Then whenever a maintainer disappears the package goes to maintainer-needed, and anybody who wants to touch it has to figure out how to build the manpages likely without the benefit of any scripts the original maintainer had lying around. If we REALLY wanted to do something like this it seems like it would be better to build some tooling around it. Maybe an eclass combined with a special USE flag like "man-build". A daemon would check for packages that have this IUSE and would build the package using it, which will generate the manpages. It would then store those pages using a standardized naming convention. The ebuild would inherit the eclass which would check if man-build was set, and if not it would automatically fetch and install the manpages built by the build server from the mirrors. Then ebuilds that currently have IUSE=man would just inherit the eclass and change to the man-build flag. That flag would only be used by the build servers and not by end users, unless they wanted to build their own manpages from scratch, which would work fine, as the flag would not suppress building the rest of the package. Really though I don't see THAT much benefit from doing either. -- Rich
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, 2019-07-20 at 20:50 +0300, Andrew Savchenko wrote: > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote: > > Hello, > > > > The QA team would like to introduce the following policy: > > > > """ > > Packages must not disable installing manpages via USE flags (e.g. > > USE=man or USE=doc). If upstream does not ship prebuilt manpages > > and building them requires additional dependencies, the maintainer > > should build them and ship along with the package. > > """ > > > > > > Explanatory note: > > > > This applies to having USE flags that specifically control building > > manpages. It obviously does not affect: > > > > a. USE flags that disable building both a program and its manpage (e.g. > > if USE=gui disables building gfrobnicate, not installing gfrobnicate(1) > > is correct), > > > > b. use of LINGUAS to control installed manpages. > > > > > > Rationale: > > > > Manpages are the basic form of user documentation on Gentoo Linux. Not > > installing them is harmful to our users. On the other hand, requiring > > additional dependencies is inconvenient. Therefore, packaging prebuilt > > manpages (whenever upstream doesn't do that already) is a good > > compromise that provides user with documentation without additional > > dependencies. > > > > > > What are your comments? > > The basic foundation of Gentoo is freedom of choise for our users. > If installing man pages means no additional dependencies, than > proposed rule is ok. However if such dependencies are required it is > up to users to decide if they wan them or not. > > Having USE=man (or USE=doc) for such purposes is fine. Having > USE=man enabled by default in user profile is also fine. Forcing > users to install unnecessary dependencies on minimal systems in a > no go and turns Gentoo into something else. > Could you please read the proposed policy? It explicitly says you are *not* supposed to force extra deps on users but build manpages for them. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote: > Hello, > > The QA team would like to introduce the following policy: > > """ > Packages must not disable installing manpages via USE flags (e.g. > USE=man or USE=doc). If upstream does not ship prebuilt manpages > and building them requires additional dependencies, the maintainer > should build them and ship along with the package. > """ > > > Explanatory note: > > This applies to having USE flags that specifically control building > manpages. It obviously does not affect: > > a. USE flags that disable building both a program and its manpage (e.g. > if USE=gui disables building gfrobnicate, not installing gfrobnicate(1) > is correct), > > b. use of LINGUAS to control installed manpages. > > > Rationale: > > Manpages are the basic form of user documentation on Gentoo Linux. Not > installing them is harmful to our users. On the other hand, requiring > additional dependencies is inconvenient. Therefore, packaging prebuilt > manpages (whenever upstream doesn't do that already) is a good > compromise that provides user with documentation without additional > dependencies. > > > What are your comments? The basic foundation of Gentoo is freedom of choise for our users. If installing man pages means no additional dependencies, than proposed rule is ok. However if such dependencies are required it is up to users to decide if they wan them or not. Having USE=man (or USE=doc) for such purposes is fine. Having USE=man enabled by default in user profile is also fine. Forcing users to install unnecessary dependencies on minimal systems in a no go and turns Gentoo into something else. Best regards, Andrew Savchenko pgpCavgJUlohO.pgp Description: PGP signature
Re: [gentoo-dev] tracker for usr merge fixes
On Sat, Jul 20, 2019 at 12:17:16PM -0400, Mike Gilbert wrote: > On Sat, Jul 20, 2019 at 11:40 AM Haelwenn (lanodan) Monnier > wrote: > > > > [2019-07-20 10:27:53-0500] William Hubbs: > > > I saw that someone in another thread asked about a tracker for usr merge > > > related fixes. > > > > > > There wasn't one, so I opened one. > > > > > > https://bugs.gentoo.org/usrmerge-fixes > > > > Looks like there is yet another bugzilla's bug or weird behaviour as > > it returns a 404 even when logged in. > > > > Works with https://bugs.gentoo.org/show_bug.cgi?id=usrmerge-fixes > > > > It's not really that weird; the redirect rule probably matches [0-9]+. ok folks, sorry about that, using the alias works in pybugz. Here's the short link: https://bugs.gentoo.org/690294 Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] tracker for usr merge fixes
On Sat, Jul 20, 2019 at 11:40 AM Haelwenn (lanodan) Monnier wrote: > > [2019-07-20 10:27:53-0500] William Hubbs: > > I saw that someone in another thread asked about a tracker for usr merge > > related fixes. > > > > There wasn't one, so I opened one. > > > > https://bugs.gentoo.org/usrmerge-fixes > > Looks like there is yet another bugzilla's bug or weird behaviour as > it returns a 404 even when logged in. > > Works with https://bugs.gentoo.org/show_bug.cgi?id=usrmerge-fixes > It's not really that weird; the redirect rule probably matches [0-9]+.
Re: [gentoo-dev] tracker for usr merge fixes
[2019-07-20 10:27:53-0500] William Hubbs: > I saw that someone in another thread asked about a tracker for usr merge > related fixes. > > There wasn't one, so I opened one. > > https://bugs.gentoo.org/usrmerge-fixes Looks like there is yet another bugzilla's bug or weird behaviour as it returns a 404 even when logged in. Works with https://bugs.gentoo.org/show_bug.cgi?id=usrmerge-fixes
[gentoo-dev] tracker for usr merge fixes
All, I saw that someone in another thread asked about a tracker for usr merge related fixes. There wasn't one, so I opened one. https://bugs.gentoo.org/usrmerge-fixes Thanks, William signature.asc Description: Digital signature
[gentoo-dev] Re: [PATCH 1/2] ruby-ng.eclass: add missing 'estack' inherit to EAPI=6
On Sat, 20 Jul 2019 10:38:09 +0200
Hans de Graaff wrote:
> On Sat, 2019-07-20 at 09:24 +0100, Sergei Trofimovich wrote:
> > Noticed when ran egencache:
> > $ PORTAGE_ELOG_CLASSES="qa" egencache --repo=gentoo --update --
> > update-use-local-desc --jobs=$(nproc)
> > * Call stack:
> > *ruby-ng.eclass, line 142: Called command_not_found_handle
> > 'eshopts_push' '-o' 'noglob'
> > * ebuild.sh, line 325: Called __qa_source '/gentoo-
> > ebuilds/gentoo/eclass/ruby-fakegem.eclass'
> > * ebuild.sh, line 624: Called source '/gentoo-
> > ebuilds/gentoo/dev-ruby/moneta/moneta-1.1.0.ebuild'
> > * ebuild.sh, line 89: Called die
> >
> > Signed-off-by: Sergei Trofimovich
> > ---
> > eclass/ruby-ng.eclass | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
> > index a6c4c3396b3..0b0ee696d50 100644
> > --- a/eclass/ruby-ng.eclass
> > +++ b/eclass/ruby-ng.eclass
> > @@ -71,6 +71,9 @@ case ${EAPI} in
> > 2|3|4|5)
> > inherits="eutils"
> > ;;
> > + 6)
> > + inherits="estack"
> > + ;;
> > esac
> >
> > inherit ${inherits} multilib toolchain-funcs ruby-utils
>
> Ack on this change. It seems this got broken when adding EAPI=6 support
> but this was never noticed because java-utils-2 also inherits eutils
> (and versionator).
>
> Can you commit and push these ASAP? It currently breaks QA. I can also
> commit them if you want.
Pushed just now.
--
Sergei
pgpDLO3HFf0gG.pgp
Description: Цифровая подпись OpenPGP
[gentoo-dev] Re: [PATCH 1/2] ruby-ng.eclass: add missing 'estack' inherit to EAPI=6
On Sat, 2019-07-20 at 09:24 +0100, Sergei Trofimovich wrote:
> Noticed when ran egencache:
> $ PORTAGE_ELOG_CLASSES="qa" egencache --repo=gentoo --update --
> update-use-local-desc --jobs=$(nproc)
> * Call stack:
> *ruby-ng.eclass, line 142: Called command_not_found_handle
> 'eshopts_push' '-o' 'noglob'
> * ebuild.sh, line 325: Called __qa_source '/gentoo-
> ebuilds/gentoo/eclass/ruby-fakegem.eclass'
> * ebuild.sh, line 624: Called source '/gentoo-
> ebuilds/gentoo/dev-ruby/moneta/moneta-1.1.0.ebuild'
> * ebuild.sh, line 89: Called die
>
> Signed-off-by: Sergei Trofimovich
> ---
> eclass/ruby-ng.eclass | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
> index a6c4c3396b3..0b0ee696d50 100644
> --- a/eclass/ruby-ng.eclass
> +++ b/eclass/ruby-ng.eclass
> @@ -71,6 +71,9 @@ case ${EAPI} in
> 2|3|4|5)
> inherits="eutils"
> ;;
> + 6)
> + inherits="estack"
> + ;;
> esac
>
> inherit ${inherits} multilib toolchain-funcs ruby-utils
Ack on this change. It seems this got broken when adding EAPI=6 support
but this was never noticed because java-utils-2 also inherits eutils
(and versionator).
Can you commit and push these ASAP? It currently breaks QA. I can also
commit them if you want.
Hans
signature.asc
Description: This is a digitally signed message part
