> 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)"
> +
> 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
> 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
> 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
>>>>> 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
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
> 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
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:
> 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 ||
> 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
> 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
> 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}} !=
> 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
> 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
> 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:
>>
>>>>> 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
> 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
>>>>> 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
> 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
> 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
> 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,
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
> 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.
>
> 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 "
> 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
> 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}"
>
# 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
> 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
> 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
> 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
> 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 ...
>
>>>>> 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
>>>>> 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?
> 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
>
> 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
>>>>> 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
> 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
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
> 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
> 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
>
> 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 [[
> 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
>>>>> 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
> 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
>>>>> 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
> 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
> 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
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
> 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
>>>>> 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
> 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
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
|
> 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
> 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
> 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 $@"
> 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
> 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
> 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
> 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.
>
> 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
> 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
> 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
> 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
> +
> 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
> 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
> 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
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]
> 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
> 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
> 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
> 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,
> 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,
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
>>>>> 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,
>>
> 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
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
> 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
> 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
>>>>> 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
> 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,
>>>>> 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
> 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
> 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)
> 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.
> 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.
>>
> 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
>>>>> 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
> 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=(
> +
> 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"
> +
>>>>> 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
> 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
> 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
> 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
> 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,
>>>>> 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
>>>>> 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
>
> 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.
>
> 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
> 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.
>
> 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 - 100 of 1997 matches
Mail list logo
