Re: [gentoo-dev] [PATCH 1/2] rocm.eclass: new eclass

2022-08-08 Thread Ulrich Mueller
> On Mon, 08 Aug 2022, Yiyang Wu wrote: > +case ${EAPI} in > + 0|1|2|3|4|5|6) > + die "${ECLASS}: unsupported EAPI=${EAPI:-0} (too old)" > + ;; > + 7|8) > + ;; > + *) > + die "${ECLASS}: unsupported EAPI=${EAPI} (unknown)" > +

Re: [gentoo-dev] PATCH 1/1] Remove deprecated eclass function after warning period expiration

2022-08-06 Thread Ulrich Mueller
> On Sat, 06 Aug 2022, Mike Pagano wrote: > Remove deprecated eclass function after warning period expiration > Signed-off-by: Mike Pagano Maybe mention bug https://bugs.gentoo.org/843686 in the commit message? signature.asc Description: PGP signature

Re: [gentoo-dev] GLEP 83 [v3]: EAPI deprecation

2022-08-01 Thread Ulrich Mueller
> On Tue, 02 Aug 2022, Sam James wrote: >> On 1 Aug 2022, at 22:24, Duncan <1i5t5.dun...@cox.net> wrote: >> >> The language point: >> >> Am I the only one for whom the omission of "from" makes the sentence read >> smoother? (Maybe it's a regional English thing?) >> >> ; this will prevent

Re: [gentoo-dev] Re: GLEP 83 [v3]: EAPI deprecation

2022-08-01 Thread Ulrich Mueller
> On Mon, 01 Aug 2022, Duncan wrote: > The first possible clarification fits here (I think). Something like: > This GLEP is intended as a policy reference guide for EAPI minimum effective > times. Despite the statistical qualifications listed here no EAPI > will be deprecated or banned

[gentoo-dev] Re: GLEP 83 [v3]: EAPI deprecation

2022-07-31 Thread Ulrich Mueller
>>>>> On Sun, 31 Jul 2022, Ulrich Mueller wrote: > A delay of 24 months between deprecation and ban will give ebuild > authors enough time to update. This is especially relevant for > overlays and downstream distributions. An additional requirement for > banning a

[gentoo-dev] GLEP 83 [v3]: EAPI deprecation

2022-07-31 Thread Ulrich Mueller
Update v3, thanks to Thomas Bracht Laumann Jespersen for grammatical corrections. --- GLEP: 83 Title: EAPI deprecation Author: Ulrich Müller Type: Informational Status: Draft Version: 1 Created: 2022-06-30 Last-Modified: 2022-07-31 Post-History: 2022-07-11, 2022-07-31 Content-Type: text/x-rst

Re: [gentoo-dev] GLEP 83: EAPI deprecation

2022-07-31 Thread Ulrich Mueller
> On Sun, 31 Jul 2022, Thomas Bracht Laumann Jespersen wrote: > Minor language things, on the whole an easy document to read! >> Motivation >> == >> >> So far, old EAPIs were deprecated by the Gentoo Council in an ad-hoc >> manner. No fixed criteria were used, resulting in very

Re: [gentoo-dev] GLEP 83: EAPI deprecation

2022-07-31 Thread Ulrich Mueller
New version, with following changes: - Use a list for the deprecation criteria - CSV table converted into simple table, for better readability of the source code - Updated EAPI 6 data, slightly different method for fitting it --- GLEP: 83 Title: EAPI deprecation Author: Ulrich Müller Type:

Re: [gentoo-dev] [PATCH 09/11] net-wireless/blueman: Invoke eautomake to fix py-compile script

2022-07-29 Thread Ulrich Mueller
> On Fri, 29 Jul 2022, Michał Górny wrote: > --- a/net-wireless/blueman/blueman-2.3.1.ebuild > +++ b/net-wireless/blueman/blueman-2.3.1.ebuild > @@ -97,7 +97,7 @@ pkg_setup() { > } > > src_prepare() { > - [[ ${PV} == ]] && eautoreconf > + [[ ${PV} == ]] && eautoreconf ||

Re: [gentoo-dev] [PATCH 1/6] virtualx.eclass: Add quoting to workaround vim syntax hl bug

2022-07-27 Thread Ulrich Mueller
> On Wed, 27 Jul 2022, Michał Górny wrote: > - [[ ${VIRTUALX_REQUIRED} == test ]] && > + [[ ${VIRTUALX_REQUIRED} == "test" ]] && Really? You should rather fix vim, or use Emacs. :) signature.asc Description: PGP signature

Re: [gentoo-dev] [PATCH] 2022-07-28-pipewire-sound-server: add item

2022-07-26 Thread Ulrich Mueller
> On Tue, 26 Jul 2022, Sam James wrote: > +2. To use PulseAudio's daemon for sound, users should disable > USE=sound-server for PipeWire, > + enable USE=daemon on media-sound/pulseaudio, and add > media-sound/pulseaudio-daemon to > + their world file: "The text body should be wrapped at

Re: [gentoo-portage-dev] [PATCH] doins: fix D check, add EPREFIX check

2022-07-25 Thread Ulrich Mueller
> On Mon, 25 Jul 2022, Fabian Groffen wrote: > @@ -50,6 +51,16 @@ if [[ ${_E_INSDESTTREE_#${ED}} != "${_E_INSDESTTREE_}" ]]; > then > __helpers_die "${helper} used with \${D} or \${ED}" > exit 1 > fi > +if [[ -n ${EPREFIX} && \ > + ${_E_INSDESTTREE_#${EPREFIX}} !=

Re: [gentoo-dev] [PATCH 1/2] opam.eclass: remove EAPI 5 and 6

2022-07-24 Thread Ulrich Mueller
> On Sun, 24 Jul 2022, David Seifert wrote: > --- a/eclass/opam.eclass > +++ b/eclass/opam.eclass > @@ -7,15 +7,15 @@ Update the copyright date to 2022? signature.asc Description: PGP signature

Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

2022-07-16 Thread Ulrich Mueller
> On Sat, 16 Jul 2022, William Hubbs wrote: > I could force this in the eclass with the following flow if I know how > to tell if the ebuild inheriting it is in the main tree or not: > # in_main_tree is a place holder for a test to see if the ebuld running > # this is in the tree > if

Re: [gentoo-dev] [PATCH data/dtd] metadata.dtd: Add nimble remote-id type

2022-07-15 Thread Ulrich Mueller
> On Wed, 13 Jul 2022, Ionen Wolkens wrote: >> > Please also submit a PR to pkgcore/pkgcheck that adds support for >> > verifying these ids. This should be pretty easy to add based >> > on existing entries. >> >> We also need to document the syntax in the wiki: >>

Re: [gentoo-dev] GLEP 83: EAPI deprecation

2022-07-13 Thread Ulrich Mueller
>>>>> On Mon, 11 Jul 2022, Ulrich Mueller wrote: > Please find below the first draft of GLEP 83 "EAPI deprecation". > This tries to define criteria for deprecation and for banning of EAPIs > by the Council. > I have tried to model it in a way that the actu

Re: [gentoo-dev] [PATCH data/dtd] metadata.dtd: Add nimble remote-id type

2022-07-13 Thread Ulrich Mueller
> On Wed, 13 Jul 2022, Michał Górny wrote: > On Wed, 2022-07-13 at 09:16 +0500, Anna Vyalkova wrote: >> Add remote-id for packages from the official Nim package list (can be >> accessed e.g. via https://nimble.directory), only packaged in ::guru at >> the time this was committed. > Please

Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name

2022-07-13 Thread Ulrich Mueller
>>>>> On Wed, 13 Jul 2022, Robin H Johnson wrote: > On Wed, Jul 13, 2022 at 02:26:43AM +0200, Ulrich Mueller wrote: >> The "natural person" part was lost in this change. It also doesn't >> reappear in the added section below. I think we don't want any

Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name

2022-07-12 Thread Ulrich Mueller
> On Tue, 12 Jul 2022, Robin H Johnson wrote: > -to the commit message as a separate line. The sign-off must contain > -the committer's legal name as a natural person, i.e., the name that > -would appear in a government issued document. > +to the commit message as a separate line. The Name

Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name

2022-07-12 Thread Ulrich Mueller
> On Tue, 12 Jul 2022, Mike Gilbert wrote: >> The snarkiness of Michał's comment left aside, in general "the name that >> you would use to present yourself to your colleagues" won't work. It is >> one of the examples in [1]: >> >> | 4. People have, at this point in time, one full name which

Re: [gentoo-dev] [PATCH] glep-0076: Require real name instead of legal name

2022-07-12 Thread Ulrich Mueller
> On Tue, 12 Jul 2022, Michał Górny wrote: >> to the commit message as a separate line. The sign-off must contain >> -the committer's legal name as a natural person, i.e., the name that >> -would appear in a government issued document. >> +the committer's real name as a natural person,

[gentoo-dev] GLEP 83: EAPI deprecation

2022-07-11 Thread Ulrich Mueller
Please find below the first draft of GLEP 83 "EAPI deprecation". This tries to define criteria for deprecation and for banning of EAPIs by the Council. I have tried to model it in a way that the actual dates for at least EAPIs 4 and 5 are reproduced within a few months. To this end, the criteria

Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Ulrich Mueller
> On Mon, 11 Jul 2022, Mike Gilbert wrote: >> Maybe leave ebegin/eend in place then, which was invented precisely for >> this use case? What's so bad about nesting it? > It leads to odd looking output. >

Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: avoid nested ebegin calls

2022-07-11 Thread Ulrich Mueller
> On Mon, 11 Jul 2022, Ionen Wolkens wrote: >> -ebegin " python_check_deps" >> -python_check_deps >> -eend ${?} >> +einfo " python_check_deps" >> +if python_check_deps; then >> +einfo " python_check_deps succeeded" >> +else >> +einfo "

Re: [gentoo-dev] GLEP-81 migration done

2022-07-10 Thread Ulrich Mueller
> On Sun, 10 Jul 2022, Anna wrote: > On 2022-07-09 23:37, Conrad Kostecki wrote: >> I would like to inform you all, that GLEP-81 migration has been >> finally done. All existing packages got migrated and no ones left. Great work, thank you! > What to do with user.eclass now? It's already

Re: [gentoo-dev] [PATCH] epatch.eclass: call ebegin to balance eend

2022-06-28 Thread Ulrich Mueller
> On Mon, 27 Jun 2022, Mike Gilbert wrote: > if [[ ${SINGLE_PATCH} == "yes" ]] ; then > if [[ -n ${EPATCH_SINGLE_MSG} ]] ; then > - einfo "${EPATCH_SINGLE_MSG}" > + ebegin "${EPATCH_SINGLE_MSG}" >

[gentoo-dev] Last rites: media-gfx/jpeg2ps

2022-06-16 Thread Ulrich Mueller
# Ulrich Müller (2022-06-16) # Last release in 2002. The distfile cannot be redistributed # and is no longer available upstream. Use media-gfx/imagemagick # ("convert" with eps2 or eps3 output format) as replacement. # Masked for removal in 30 days. Bug #851708. media-gfx/jpeg2ps signature.asc

Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

2022-06-13 Thread Ulrich Mueller
> On Mon, 13 Jun 2022, Florian Schmaus wrote: Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, where some voices where in agreement that EGO_SUM has its raison d'être, while there where no arguments in favor of eventually removing EGO_SUM, I hereby

Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

2022-06-13 Thread Ulrich Mueller
> On Mon, 13 Jun 2022, Michał Górny wrote: > On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote: >> Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, >> where some voices where in agreement that EGO_SUM has its raison d'être, >> while there where no arguments in

Re: [gentoo-dev] Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

2022-06-05 Thread Ulrich Mueller
> On Sun, 05 Jun 2022, Joonas Niilola wrote: > www-apps/nikola I'll take this one. Would be happy if someone wants to co-maintain it. Ulrich signature.asc Description: PGP signature

Re: [gentoo-dev] [PATCH 1/2] esed.eclass: new eclass

2022-06-03 Thread Ulrich Mueller
> On Tue, 31 May 2022, Ionen Wolkens wrote: > +# @FUNCTION: esed > +# @USAGE: ... > +# @DESCRIPTION: > +# sed(1) wrapper that dies if the expression(s) did not modify any files. > +# sed's -i/--in-place is forced, and so stdin/out cannot be used. This sounds like a simple enough task ... >

Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-25 Thread Ulrich Mueller
>>>>> On Sun, 22 May 2022, Ulrich Mueller wrote: >>>>> On Sun, 22 May 2022, Hanno Böck wrote: >> I'm not sure about Google code. >> While it's no longer an active site, it is still online in an >> archived state. We maintain plenty of pack

Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-23 Thread Ulrich Mueller
>>>>> On Sun, 22 May 2022, Ulrich Mueller wrote: > Some of them seem to be obsolete. Presumably freshmeat, gitorious, and > google-code should be removed? Any other removal candidates? > Looks like SourceForge-JP was renamed to OSDN, should the file reflect > that?

Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
> On Sun, 22 May 2022, Hanno Böck wrote: >> Some of them seem to be obsolete. Presumably freshmeat, gitorious, and >> google-code should be removed? Any other removal candidates? > I'm not sure about Google code. > While it's no longer an active site, it is still online in an archived >

Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
> On Sun, 22 May 2022, Alessandro Barbieri wrote: > How to propose new values? I'd say, file a bug with some rationale and the proposed syntax. Ulrich signature.asc Description: PGP signature

[gentoo-dev] Re: Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
>>>>> On Sun, 22 May 2022, Ulrich Mueller wrote: > According to the XML schema [1], the following remote-id types are > currently allowed: >bitbucket >cpan >cpan-module >cpe >cran >ctan >freecode >freshmeat >gi

Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
> On Sun, 22 May 2022, Michał Górny wrote: > I think we should start documenting these values somewhere. Perhaps > in the GLEP, or maybe on some wiki page — particularly linking > the provider in question Wiki page sounds good. Presumably, we don't want to update the GLEP for every change

[gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
According to the XML schema [1], the following remote-id types are currently allowed: bitbucket cpan cpan-module cpe cran ctan freecode freshmeat github gitlab gitorious google-code heptapod launchpad pear pecl pypi rubyforge rubygems

Re: [gentoo-dev] [PATCH 2/2] qmail.eclass: remove usage of egrep

2022-05-21 Thread Ulrich Mueller
> On Sat, 21 May 2022, Rolf Eike Beer wrote: > You can get the patches directly from git here: > https://github.com/DerDakon/gentoo/tree/qmail-eclass Thanks, merged. signature.asc Description: PGP signature

Re: [gentoo-dev] [PATCH 2/2] qmail.eclass: remove usage of egrep

2022-05-21 Thread Ulrich Mueller
> On Mon, 16 May 2022, Rolf Eike Beer wrote: > This does not use extended regular expressions in any way. While at it change > the way these matches are done: it's irrelevant if the entire expression is in > the file, if there is any rule for the given IP address then do not add the > new >

Re: [gentoo-dev] [PATCH] eclass/ruby-fakegem.eclass: depend on virtual/pkgconfig

2022-05-20 Thread Ulrich Mueller
> On Fri, 20 May 2022, Florian Schmaus wrote: >> +if [ ${#RUBY_FAKEGEM_EXTENSIONS[@]} -ge 1 ]; then >> +BDEPEND+=" virtual/pkgconfig " >> +fi > Not sure if we have a policy on this, We do. :) https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0101 "Use bash conditions [[

Re: [gentoo-dev] [PATCH] linux-info.eclass: Documentation updates

2022-05-16 Thread Ulrich Mueller
> On Mon, 16 May 2022, Thomas Bracht Laumann Jespersen wrote: >> +# @FUNCTION: qout >> +# @DESCRIPTION: >> +# qout is a quiet call when EBUILD_PHASE >> # should not have visible output. > The devmanual says that @USAGE is also required for eclass functions > [0]. This is applicable in a

Re: [gentoo-dev] [PATCH] linux-info.eclass: Documentation updates

2022-05-15 Thread Ulrich Mueller
>>>>> On Sun, 15 May 2022, Ulrich Mueller wrote: >>>>> On Sun, 15 May 2022, Mike Pagano wrote: >> +# @FUNCTION: check_zlibinflate >> +# @DESCRIPTION: >> +# helper function to make sure a ZLIB_INFLATE configuration >> +# has the requried symb

Re: [gentoo-dev] [PATCH] linux-info.eclass: Documentation updates

2022-05-15 Thread Ulrich Mueller
> On Sun, 15 May 2022, Mike Pagano wrote: > +# @FUNCTION: check_zlibinflate > +# @DESCRIPTION: > +# helper function to make sure a ZLIB_INFLATE configuration > +# has the requried symbols s/requried/required/ Also, eclass-to-manpage will format won't respect the line breaks but format

Re: [gentoo-dev] License of news items

2022-05-14 Thread Ulrich Mueller
>>>>> On Sun, 08 May 2022, Ulrich Mueller wrote: >>>> Alternatively, we could add a new header line with license >>>> information to the items themselves, but that would be more >>>> complicated with (IMHO) little gain. >>&g

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
> On Fri, 13 May 2022, Philip Webb wrote: >> Recently Debian has started to transition away from the "which" command. >> [1] > Do we take Debian as a role model ? No, but it is additional input. Note that our own activities [2,3] started earlier than that. >> 'which' is a non-POSIX command

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
> On Fri, 13 May 2022, Michael Orlitzky wrote: >> So, should we join the "which hunt", with the goal of removing >> sys-apps/which from the system set and from stage1? > Yes, although I would suggest "command -v" as a POSIX replacement that > can be sent upstream. The "type" utility is also

[gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
Recently Debian has started to transition away from the "which" command. [1] which is a non-POSIX command which prints out the location of specified executables that are in your path. Unfortunately, there are several versions of the program around which are not compatible with each other. We

Re: [gentoo-dev] [PATCH 7/7] cmake-utils.eclass: Drop @SEE which is not a documentation keyword

2022-05-10 Thread Ulrich Mueller
> On Tue, 10 May 2022, Ulrich Müller wrote: > eclass/cmake-utils.eclass | 1 - > 1 file changed, 1 deletion(-) I'm going to drop this commit, because cmake-utils is on its way out of the tree. The rest of the series doesn't change. Ulrich

Re: [gentoo-dev] License of news items

2022-05-07 Thread Ulrich Mueller
>>>>> On Sat, 26 Dec 2020, Ulrich Mueller wrote: >>>>> On Sat, 26 Dec 2020, Michał Górny wrote: >> On Sat, 2020-12-26 at 10:20 +0100, Ulrich Mueller wrote: >>> Alternatively, we could add a new header line with license >>> infor

Re: [gentoo-dev] [PATCH] java-pkg-simple.eclass: eqawarn if module-info.java is not compiled

2022-05-03 Thread Ulrich Mueller
> On Wed, 04 May 2022, Florian Schmaus wrote: > + 5|6) inherit eutils ;; # eutils for eqawarn Adding eutils in 2022 seems a little backwards. Maybe make the output command conditional instead? Something like this: # conditional needed in EAPIs 5 and 6 local eqawarn=eqawarn

[gentoo-dev] New QA policy: LICENSE must not contain variables

2022-04-24 Thread Ulrich Mueller
The QA team has approved a new policy [1], effective immediately: | LICENSE must not contain variables | | PG: 0106 | Source: QA | Reported: no | | The LICENSE variable in an ebuild must specify all the license names | verbatim, without referring to any variables. The only exception is |

Re: [gentoo-dev] [RFC] Change the stabilization request flows

2022-04-23 Thread Ulrich Mueller
> On Sat, 23 Apr 2022, Arthur Zamarin wrote: > The first flow I want to introduce is when nattka sees a bug with > CC-ARCHES in keyword, but not all maintainers were CC, nattka will CC > all maintainers, drop the CC-ARCHES, and comment something a long the > lines "wait for maintainers to ACK

[gentoo-dev] Re: [PATCH v3 1/1] edo.eclass: add new eclass

2022-04-17 Thread Ulrich Mueller
> On Sun, 17 Apr 2022, Sam James wrote: > --- /dev/null > +++ b/eclass/edo.eclass > @@ -0,0 +1,45 @@ > +# Copyright 2022 Gentoo Authors > +# Distributed under the terms of the GNU General Public License v2 > + > +# @ECLASS: edo.class > +# @MAINTAINER: > +# QA Team > +# @AUTHOR: > +# Sam

Re: [gentoo-dev] Re: [PATCH 1/1] edo.eclass: add new eclass

2022-04-16 Thread Ulrich Mueller
> On Sat, 16 Apr 2022, Florian Schmaus wrote: >> edobe() { > nit: I'd personally would use 'edob', as shorter is sometimes better > plus every begin needs an end, so no need to explicitly state that > there is an end. It's even more obscure as a name however. :) >> ebegin "Running $@"

[gentoo-dev] Re: [PATCH 1/1] edo.eclass: add new eclass

2022-04-16 Thread Ulrich Mueller
> On Sat, 16 Apr 2022, Sam James wrote: > +# @FUNCTION: edo Just a remark: A similar command existed a long time ago under the name "try". [1] It was executed under "env" [2], should we also do that? > +# @USAGE: command [arg1 [arg2 ...]] should be in angle brackets, if we follow the

Re: [gentoo-dev] [PATCH v5.5] vim-plugin.eclass: EAPI 8: add src_prepare

2022-04-13 Thread Ulrich Mueller
> On Thu, 14 Apr 2022, Anna Vyalkova wrote: > +fi > + > +EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm > + > +# src_prepare is only exported in EAPI >= 8 > +case ${EAPI} in > + 6|7) ;; > + *) EXPORT_FUNCTIONS src_prepare ;; > +esac > + > +if [[ ! ${_VIM_PLUGIN_ECLASS} ]]; then

Re: [gentoo-dev] Packages up for grabs

2022-04-13 Thread Ulrich Mueller
> On Wed, 13 Apr 2022, Dirkjan Ochtman wrote: > I'm retiring, please consider picking up these packages: > [...] > app-text/rnc2rng I can take this (presuming that you'll continue maintaining it upstream). Ulrich signature.asc Description: PGP signature

Re: [gentoo-dev] [PATCH] linux-info.eclass: Call ebegin, properly close with eend

2022-04-13 Thread Ulrich Mueller
> On Wed, 13 Apr 2022, Thomas Bracht Laumann Jespersen wrote: > - einfo "Checking for suitable kernel configuration options..." > + ebegin "Checking for suitable kernel configuration options..." ebegin outputs dots by itself, so the ones in the message should be removed. >

Re: [gentoo-dev] [PATCH v4 2/9] vim-plugin.eclass: support EAPI 8

2022-04-07 Thread Ulrich Mueller
> On Thu, 07 Apr 2022, Anna Vyalkova wrote: > case ${EAPI} in > - 6|7);; > - *) die "EAPI ${EAPI:-0} unsupported (too old)";; > + 6|7|8);; > + *) die "${ECLASS}: EAPI ${EAPI:-0} unsupported (too old)";; The "(too old)" part will look strange with EAPI 9. Just say that it's

Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-06 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote: > So I'll spell out the different possibilities: > 1) GPG uses SHA-512. Manifest uses SHA-512 and BLAKE2b. > 1a) Possibility: SHA-512 is broken. Result: system broken. > 1b) Possibility: BLAKE2b is broken. Result: nothing. > 2) GPG uses

Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-06 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote: > Why? Then we're dependent on two things, either of which could break, > rather than one. See? If either of these should happen, then we'll be happy that we still have both hashes in our Manifest files. OTOH, if that argument is not relavant

Re: [gentoo-dev] [PATCH 1/2] vim-doc.eclass: support EAPI 8

2022-04-06 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Thomas Bracht Laumann Jespersen wrote: > - find $d/doc -name \*.txt -type l | while read s; do > - [[ $(readlink "$s") = $vimfiles/* ]] && rm -f "$s" > + find ${d}/doc -name \*.txt -type l | while read s; do > +

Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-05 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote: > I think actually the argument I'm making this time might be subtly > different from the motions that folks went through last year. > Specifically, the idea last year was to switch to using BLAKE2b only. > I think what the arguments I'm making

Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-05 Thread Ulrich Mueller
> On Tue, 05 Apr 2022, Jason A Donenfeld wrote: > Huh. Something not brought up there or https://bugs.gentoo.org/784710 > is the fact that the _security_ of the system reduces to SHA-512 as > used by our GPG signatures. The hash algorithm would be the least of my concerns about the security

Re: [gentoo-dev] Re: proposal: use only one hash function in manifest files

2022-04-05 Thread Ulrich Mueller
> On Tue, 05 Apr 2022, Jason A Donenfeld wrote: > - GPG signatures are already over the SHA512 of the plain text, so > they security of the system already reduces to that. By choosing > SHA512, we don't add more risk, whilst choosing something else means > we're in trouble if either one has a

[gentoo-dev] Small update to eclass documentation

2022-03-23 Thread Ulrich Mueller
Just a heads up: The @ECLASS-VARIABLE documentation tag has been renamed to @ECLASS_VARIABLE, in order to be in line with tags like @USER_VARIABLE, @OUTPUT_VARIABLE, and a couple more that are all written with an underscore. Tools and documentation have been updated already, see bug 835396 [1]

Re: [gentoo-dev] Deprecating repoman

2022-03-19 Thread Ulrich Mueller
> On Sat, 19 Mar 2022, Zoltan Puskas wrote: [Please don't top-post.] > I've been using both repoman _and_ pkgcheck becasue I was not sure which > one covers all the checks I need to make. In fact [Pull Requests > wiki](https://wiki.gentoo.org/wiki/Project:GitHub/Pull_requests) has a > big

Re: [gentoo-dev] Deprecating repoman

2022-03-11 Thread Ulrich Mueller
> On Thu, 10 Mar 2022, Alec Warner wrote: > I'm not sure a news item is strictly necessary, we might just p.mask > repoman with a link to the guide that Matt will need to write about > how repoman is being replaced. We should distinguish between deprecating the repoman(-only) workflow and

Re: [gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go

2022-02-27 Thread Ulrich Mueller
> On Sun, 27 Feb 2022, Ionen Wolkens wrote: > On Sat, Feb 26, 2022 at 10:38:33PM -0600, William Hubbs wrote: >> +# eclass. If it doesn't, you need to also create a vendor tarball and > Unnecessary double space. No. It is a sentence end, so the double space is mandatory. (The reason is

Re: [gentoo-dev] [PATCH] db-use.eclass: add support for EAPI 8, die on unknown EAPI

2022-02-18 Thread Ulrich Mueller
> On Fri, 18 Feb 2022, Florian Schmaus wrote: > -case "${EAPI:-0}" in > - 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;; > - *) inherit multilib ;; > +case ${EAPI} in > + [56]) inherit eapi7-ver ;& # fallthrough > + [78]) inherit multilib ;; Please keep the 5|6) etc. syntax,

Re: [gentoo-dev] [PATCH] vala.eclass: Support EAPI 8

2022-02-16 Thread Ulrich Mueller
> On Wed, 16 Feb 2022, Mart Raudsepp wrote: > Ühel kenal päeval, K, 16.02.2022 kell 19:39, kirjutas Ulrich Müller: >> Function vala_src_prepare did not call eapply_user, so it could not >> be >> used as a stand-alone phase function but must be called explicitly. >> Rename it to vala_setup,

[gentoo-dev] Package up for grabs: dev-vcs/git-sizer

2022-02-13 Thread Ulrich Mueller
I am no longer interested in maintaining this package. It has no open bugs, but is one release behind upstream. Ulrich signature.asc Description: PGP signature

[gentoo-dev] Re: [gentoo-project] Call for agenda items - Council meeting on 2022-02-13

2022-02-08 Thread Ulrich Mueller
>>>>> On Wed, 09 Feb 2022, Sam James wrote: > On Wed, 09 Feb 2022 08:18:07 +0100 > Ulrich Mueller wrote: >> There is no special time period for making such proposals; future EAPI >> bugs can be filed at any time. Preferably, they should be filed early, >>

Re: [gentoo-dev] [PATCH] texlive-common.eclass: respect EPREFIX in symlink creation

2022-01-30 Thread Ulrich Mueller
> On Mon, 31 Jan 2022, Sam James wrote: > - dosym /etc/texmf/$(dirname ${f}).d/$(basename ${f}) > ${TEXMF_PATH}/${f} > + dosym "${EPREFIX}"/etc/texmf/$(dirname ${f}).d/$(basename ${f}) > ${TEXMF_PATH}/${f} Any reason why this cannot use dosym -r (or dosym8 -r in

[gentoo-dev] Closing the Lisp umbrella project

2022-01-16 Thread Ulrich Mueller
We have decided to close the Lisp umbrella project [1]. Its subprojects Common Lisp, Scheme, and Emacs already moved to the top level. We will keep the #gentoo-lisp IRC channel and the lisp overlay; ownership of the latter will be changed to Common Lisp and Scheme. (The Emacs project has always

Re: [gentoo-dev] [PATCH v2 1/5] multilib-minimal.eclass: remove EAPI 5

2022-01-12 Thread Ulrich Mueller
> On Tue, 11 Jan 2022, David Seifert wrote: > -case ${EAPI} in > - 5|6|7|8) ;; > +case ${EAPI:-0} in The :- substitution isn't necessary here. Same for the other eclasses in the patch series. > + 6|7|8) ;; > *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; > esac

Re: [gentoo-dev] [PATCH 1/2] multibuild.eclass: remove dead userland_BSD

2022-01-08 Thread Ulrich Mueller
> On Sat, 08 Jan 2022, David Seifert wrote: > + cp "${cp_args[@]}" "${src}"/. "${dest}"/ > + ret=${?} > + > if [[ ${ret} -ne 0 ]]; then > die "${MULTIBUILD_VARIANT:-(unknown)}: merging image failed." > fi This could be further simplified to "cp ... || die

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
>>>>> On Wed, 05 Jan 2022, Sam James wrote: >> On 5 Jan 2022, at 08:28, Ulrich Mueller wrote: >> >> Where does this number 2 GB come from? The amount of RAM strongly >> depends on the programming language and other factors, so I don't >> bel

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
> On Wed, 05 Jan 2022, Florian Schmaus wrote: >> That applies to all parallel builds though, not only to ebuilds >> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically >> telling the user that the --jobs setting in their make.conf is wrong, >> in the first place. > Yes,

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
>>>>> On Wed, 05 Jan 2022, Florian Schmaus wrote: > On 05/01/2022 09.28, Ulrich Mueller wrote: >>>>>>> On Tue, 04 Jan 2022, Sam James wrote: >>> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the >>> amount of RAM avai

Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
> On Tue, 04 Jan 2022, Sam James wrote: > Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the > amount of RAM available (uses amount declared as needed > in the ebuild). Typically should be ~2GB per job. Where does this number 2 GB come from? The amount of RAM strongly depends on

Re: [gentoo-dev] [RFC] New category: net-servers

2021-12-19 Thread Ulrich Mueller
> On Mon, 20 Dec 2021, Jonas Stein wrote: >> I've been packaging some Gemini protocol servers and clients in ::guru >> overlay, and they all go to net-misc category. I think it would be >> better to split browsers and servers for non-www protocols (like Finger, >> Ident, Gemini and Gopher)

Re: [gentoo-dev] Printer drivers and net-print

2021-12-19 Thread Ulrich Mueller
> On Sat, 18 Dec 2021, Joshua Kinard wrote: > Maybe consider three new top-level categories?: > - print-drivers > - print-filters > - print-misc net-print is already a small category with only 35 packages, so IMHO splitting it up into three tiny categories wouldn't make much sense.

Re: [gentoo-dev] Printer drivers and net-print

2021-12-17 Thread Ulrich Mueller
> On Fri, 17 Dec 2021, Andreas Sturmlechner wrote: > On Montag, 20. Februar 2017 22:47:17 CET Andreas K. Huettel wrote: >> 1) Putting printer drivers into "net-print" is silly. >> >> Something that converts format a to device-specific format b has absolutely >> nothing to do with network. >>

Re: [gentoo-dev] Package up for grabs: app-misc/pdfpc

2021-12-15 Thread Ulrich Mueller
> On Wed, 15 Dec 2021, Nils Freydank wrote: > pdfpc is a nice presentation tool to show PDFs and a presenter screen with > notes etc[1]. > With version 4.5.0 upstream startet to use webkit-gtk and has no intention > to make this optional[2]. I use a Qt-based desktop, have no interest to

Re: [gentoo-dev] [PATCH v3] eclass/dune.eclass: fix dune-install function

2021-12-09 Thread Ulrich Mueller
>>>>> On Fri, 10 Dec 2021, Ulrich Mueller wrote: > I'd write something like this: > local -a pkgs=("$@") > [[ ${#pkgs[@]} -eq 0 ]] && pkgs=(${DUNE_PKG_NAME}) Looks like I'm not immune against missing quotes either. :/ The line should read

Re: [gentoo-dev] [PATCH v3] eclass/dune.eclass: fix dune-install function

2021-12-09 Thread Ulrich Mueller
> On Thu, 09 Dec 2021, Maciej Barć wrote: > dune-install() { > + local pkgs > + if [[ -n "${@}" ]] ; then > + pkgs="${@}" Here pkgs is a scalar ... > + else > + pkgs=${DUNE_PKG_NAME} > + fi > + > + local myduneopts=( > +

Re: [gentoo-dev] [PATCH] eclass/dune.eclass: fixes

2021-12-08 Thread Ulrich Mueller
> On Thu, 09 Dec 2021, Maciej Barć wrote: > dune-install() { > + local pkgs > + if [[ -n "${@}" ]] ; then > + pkgs="${@}" > + else > + pkgs=${DUNE_PKG_NAME} > + fi > + > + local myduneopts=( > + --prefix="${ED%/}/usr" > +

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-30 Thread Ulrich Mueller
>>>>> On Tue, 30 Nov 2021, James Cloos wrote: >>>>> "UM" == Ulrich Mueller writes: UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine, UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999. > why do

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-29 Thread Ulrich Mueller
> On Mon, 29 Nov 2021, Alec Warner wrote: > - If Gentoo adds an acct-user/foo user, and that user already exists > on my system with the wrong UID: the eclass dies[0]. I don't think that's correct. The eclass will just use the already existing UID then (except for the very few acct-user

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread Ulrich Mueller
> On Sun, 28 Nov 2021, William Hubbs wrote: > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote: >> 1/ Static allocation does not really solve a problem. Not really not >> nowadays >> 2/ We cant keep adding new IDs to a distribution as new software gets >> added - one side is

Re: [gentoo-dev] [PATCHv3] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-26 Thread Ulrich Mueller
> On Fri, 26 Nov 2021, Joonas Niilola wrote: > v3 LGTM regardless of that addition. More comments, more acks to get > this merged even possibly tonight (UTC)? Anyone from PR? Ack. Looks good now. signature.asc Description: PGP signature

Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-25 Thread Ulrich Mueller
> On Thu, 25 Nov 2021, Mike Gilbert wrote: > On Wed, Nov 24, 2021 at 10:21 PM Thomas Deutschmann wrote: >> +On 2021-11-21, a member of the QA project accidentially de-keyworded >> +MariaDB 10.6 to address a file collision, users, who also had latest >> +dev-db/mariadb-connector-c installed,

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-14 Thread Ulrich Mueller
>>>>> On Sun, 14 Nov 2021, Thomas Deutschmann wrote: > On 2021-11-11 11:59, Ulrich Mueller wrote: >> We could: >> - Open some part of the range between 500 and 1000. For example, >> 500..799, which would leave 200 IDs for dynamic allocation. >> - Ope

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-14 Thread Ulrich Mueller
>>>>> On Thu, 11 Nov 2021, Ulrich Mueller wrote: > In any case, we have run out of GIDs: >Recommended GID only: none >Recommended UID only: 272 >Recommended UID+GID pair: none >Free UIDs: 15 >Free GIDs: 0 >Free UID+GID pairs: 0 >

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-13 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, James Cloos wrote: > gentoo definitely should not permit fixed use for installed packages > in the 500-600 range. > 500+ was for many, many years the start for users, and forcing anyone > to change decades-long use of particular uids or gods is not > acceptable. >

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-11 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, Mike Gilbert wrote: >> - Open part of the range 60001..65533. Not sure if all software will be >> happy with that. > systemd has some code that special-cases ids in the "system" range. > I'm not exactly sure what impact creating system users outside above > SYS_UID_MAX

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-11 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, Jaco Kroon wrote: > # getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3 > 37945 > 37946 > 65534 <-- this happens to be nobody. > 6 up to where?  65533? I'd say 60001..60999 for now, and increase by another 1000 when (and if) it will become necessary. >

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-11 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, Florian Schmaus wrote: >> We could: >> - Open some part of the range between 500 and 1000. For example, >> 500..799, which would leave 200 IDs for dynamic allocation. > +1, since I am not aware of any significant downsides doing so. > Could you elaborate why the range

  1   2   3   4   5   6   7   8   9   10   >