> On Mon, 29 May 2023, Volkmar W Pogatzki wrote:
>> > -: "${JAVA_LAUNCHER_FILENAME:=${PN}-${SLOT}}"
>> > +if [[ ${SLOT} = 0 ]]; then
>> > + JAVA_LAUNCHER_FILENAME="${PN}"
>> > +else
>> > + JAVA_LAUNCHER_FILENAME="${PN}-${SLOT}"
>> > +fi
>>
>> This will no longer allow overriding the
> On Fri, 26 May 2023, Volkmar W Pogatzki wrote:
> -: "${JAVA_LAUNCHER_FILENAME:=${PN}-${SLOT}}"
> +if [[ ${SLOT} = 0 ]]; then
> + JAVA_LAUNCHER_FILENAME="${PN}"
> +else
> + JAVA_LAUNCHER_FILENAME="${PN}-${SLOT}"
> +fi
This will no longer allow overriding the variable in the ebuild
> On Mon, 22 May 2023, Andreas Sturmlechner wrote:
>> Should it be renamed to "skia" for libreoffice, because that's also the
>> name of the upstream flag? libreoffice will also output a warning with
>> USE="vulkan -clang".
> That would not be accurate. The (bundled) skia is always being
> On Mon, 22 May 2023, Ionen Wolkens wrote:
>> That's a non-sequitur. No reason to not have it on doesn't imply that
>> there is a reason to have it on.
>>
>> Also, shouldn't we avoid enabling local flags in profiles?
> I keep forgetting that this is still not global either, guess it'll
>
> On Sun, 21 May 2023, Sam James wrote:
> Ionen pointed this out again today and it made me look back at it;
> there's no reason to not have vulkan on by default for desktop
> profiles.
That's a non-sequitur. No reason to not have it on doesn't imply that
there is a reason to have it on.
> On Fri, 19 May 2023, David Seifert wrote:
> # David Seifert (2023-05-19)
> # Depends on app-portage/layman. Removal on 2023-06-18.
> app-portage/g-sorcery
> # David Seifert (2023-05-19)
> # Depends on obsolete app-portage/g-sorcery.
> # Removal on 2023-06-18.
> app-portage/gs-elpa
> On Tue, 16 May 2023, Andreas Sturmlechner wrote:
> Title: Plasma Profile to switch on PipeWire, Wayland support
011223344
12345678901234567890123456789012345678901234567890123
The title is slightly too long, GLEP 42 says 50
> On Mon, 08 May 2023, Matt Turner wrote:
>> > +++
>> > b/2023-05-08-openssh-configuration-changes/2023-05-08-openssh-configuration-changes.en.txt
>>
>> https://www.gentoo.org/glep/glep-0042.html#news-item-identities
>> "This identifier will be in the form -mm-dd-short-name [...].
>>
> On Mon, 08 May 2023, Sam James wrote:
> +++
> b/2023-05-08-openssh-configuration-changes/2023-05-08-openssh-configuration-changes.en.txt
https://www.gentoo.org/glep/glep-0042.html#news-item-identities
"This identifier will be in the form -mm-dd-short-name [...].
The short-name is a
>>>>> On Wed, 03 May 2023, Ulrich Mueller wrote:
> I wonder about the CONF_LIBDIR variable and the implementation of the
> dolib* commands in Portage. These commands normally use the ABI and
> LIBDIR_${ABI} variables from the profile to determine the library
> dire
> On Thu, 04 May 2023, James Le Cuirot wrote:
>> On May 4, 2023 6:38:32 PM UTC, Mike Gilbert wrote:
>> > # Out of date by several versions. Many unresolved security
>> > # vulnerabilities. Lack of manpower/interest in keeping it up to date.
>> > # Removal on 2023-06-03.
>> >
I wonder about the CONF_LIBDIR variable and the implementation of the
dolib* commands in Portage. These commands normally use the ABI and
LIBDIR_${ABI} variables from the profile to determine the library
directory (e.g. "lib" or "lib64").
However, if either ABI or LIBDIR_${ABI} happens to be
> On Wed, 03 May 2023, Michael Orlitzky wrote:
[Please keep this thread in -project.]
>> This is a friendly reminder that we're nearing (at the end of the day)
>> the half-period for this election voting.
> My options are "yes" and "no" but there's no indication of what I'm
> saying yes/no
> On Thu, 27 Apr 2023, Florian Schmaus wrote:
> Network traffic, while also being cheap, may be more of an issue.
> Currently, gentoo-latest.tar.xz is ~41 MiB. So on a conservative
> approximation ::gentoo compresses to 1/10. So, the 10 Go-packages
> cause 200 KiB of additional traffic. Even
> On Sat, 08 Apr 2023, Thomas Bracht Laumann Jespersen wrote:
> - [ -f "${mark}" ]
> + [[ -f "${mark}" ]]
The quotes are no longer needed in [[ ]].
> On Wed, 29 Mar 2023, Sam James wrote:
> - if ! has test "$IUSE"; then
> + if ! has test ${IUSE}; then
You cannot reliably test for a flag in IUSE with code like this.
PMS defines the function in_iuse() for this (unless the above is
in global scope, in which case you're out of
> On Fri, 24 Mar 2023, Adrian Schollmeyer wrote:
>> Then again, it doesn't even say that they represent 4 spaces.
> Is that really important? I don't think we should force a tab width
> for the user if we don't have a good reason to do so. The good thing
> about tabs is that the user can set
> On Fri, 24 Mar 2023, Florian Schmaus wrote:
>> Then it looks wrong, conceptually. Or would it be o.k. if I committed
>> ebuild-mode.el to the top-level directory of the Gentoo repository?
> I do not think the comparison with ebuild-mode.el is sound:
> ebuild-mode.el appears imperative,
> On Fri, 24 Mar 2023, Sam James wrote:
> The idea is to make other editors less-hostile when they don't have
> a dedicated mode (like I said in the commit message). The specific
> reason for doing this is because it's editor agnostic.
But is it? Emacs and Vim don't seem to natively support
> On Fri, 24 Mar 2023, Sam James wrote:
>> I'm slightly confused. What repository is this intended for?
> gentoo.git.
Then it looks wrong, conceptually. Or would it be o.k. if I committed
ebuild-mode.el to the top-level directory of the Gentoo repository?
Seriously, these are generic
> On Fri, 24 Mar 2023, Sam James wrote:
> This allows conveniently editing ebuilds and eclasses in editors which don't
> have a specific ebuild mode like Emacs and Vim do.
I'm slightly confused. What repository is this intended for?
signature.asc
Description: PGP signature
> On Wed, 15 Mar 2023, Emily wrote:
>> -# the jungle known as src_install() in cron ebuilds. Using these
>> +# the jungle known as src_install() in cron ebuilds. Using these
> Is this extra space added here intentionally, or is that a typo?
> On Tue, 14 Mar 2023, Matt Turner wrote:
> -SRC_URI="mirror://gnome/sources/${GNOME_ORG_MODULE}/${GNOME_ORG_PVP}/${GNOME_ORG_MODULE}-${PV}.tar.${GNOME_TARBALL_SUFFIX}"
>
How about using a new token in PROPERTIES instead?
signature.asc
Description: PGP signature
> On Sat, 28 Jan 2023, Andrew Ammerlaan wrote:
> Each of these is a different package. The package you usually want is
> GitPython, but if we would name it gitpython or git-python, things
> would get very confusing very quickly. In fact, this package was
> renamed precisely to avoid this
> On Sat, 28 Jan 2023, Michał Górny wrote:
> Based on existing remote-id entries, the following package names are
> mismatched (PN on left, PyPI name on right). Note that some of the IDs
> could be wrong, particularly because PyPI "autocorrects" - vs _.
Are there any rules by which upstream
> On Tue, 03 Jan 2023, Sam James wrote:
> - if [[ "$(file "${exe}")" == *"shell script
> text"* ]]
> + if [[ "$(file -S "${exe}")" == *"shell script
> text"* ]]
POSIX file doesn't know the -S option. Could that cause any problems,
> On Sun, 01 Jan 2023, Michał Górny wrote:
> +case ${EAPI} in
> + 6|7|8) ;;
> + *) die "${ECLASS}: EAPI ${EAPI} unsupported."
Are you sure that this will work without the final ;; terminator?
(Bash documentation says that a terminator is mandatory.)
Apart from that, I'd suggest to
>>>>> On Sun, 25 Dec 2022, Ulrich Mueller wrote:
> EAPI 7 should be kept for this one, in order not to break the Emacs
> overlay.
Never mind, overlay has been updated.
signature.asc
Description: PGP signature
EAPI 7 should be kept for this one, in order not to break the Emacs
overlay.
signature.asc
Description: PGP signature
> On Sun, 25 Dec 2022, Sam James wrote:
> + [[ ${KV_MAJOR} -eq 2 && ${KV_MINOR} -gt 5 && ${KV_PATCH} -gt 5 ]] && \
> return 0 || return 1
Ouch. :)
The "&& return 0 || return 1" can be omitted.
> }
signature.asc
Description: PGP signature
> On Sun, 25 Dec 2022, Sam James wrote:
> - [[ $# -gt 3 ]] && die "Error in kernel-2_kernel_is(): too many
> parameters"
> + [[ $# -gt 3 ]] && die "Error in ${ECLASS}_${FUNCNAME}(): too many
> parameters"
This might be somewhat misleading. The name of the function is just
> On Wed, 14 Dec 2022, Sam James wrote:
> *.lz)
> - d="|| ( app-arch/plzip app-arch/pdlzip app-arch/lzip )"
> ;;
> + d="
> + || (
> + >=app-arch/xz-utils-5.4.0
> +
>>>>> On Sat, 03 Dec 2022, Ulrich Mueller wrote:
> Some people found that not satisfactory, so NEW and ASSIGNED were
> replaced by CONFIRMED and IN_PROGRESS. (We also had status REOPENED
> which was removed with the same change.) Unfortunately, I cannot find
> the old d
> On Sat, 03 Dec 2022, Michał Górny wrote:
>> > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED
>> > bug states with a simple NEW state. Why?
>>
>> > 1. Only a handful of developers actually uses these two statuses
>> > in a meaningful way.
>>
>> > 2. Some users are
> On Sat, 03 Dec 2022, Sam James wrote:
> # Oz Tiram (2022-12-03)
> # Mate-desktop no longer supports gtk+:2, so there is
> # no need for this package. Removal on 2023-01-03.
> x11-themes/mate-themes-meta
Is x11-themes/mate-themes obsolete then? mate-base/mate[themes] no
longer depends on
> On Sat, 03 Dec 2022, Michał Górny wrote:
> I'd like to propose replacing the current UNCONFIRMED and CONFIRMED
> bug states with a simple NEW state. Why?
> 1. Only a handful of developers actually uses these two statuses
> in a meaningful way.
> 2. Some users are confused and demotivated
> On Sat, 03 Dec 2022, Michał Górny wrote:
> --- /dev/null
> +++ b/eclass/app-alternatives.eclass
> @@ -0,0 +1,84 @@
> +# Copyright 2022 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: app-alternatives.eclass
> +# @MAINTAINER:
> +# Michał
# Ulrich Müller (2022-11-30)
# SLOTs 23 and 24 of app-editors/emacs, corresponding to GNU Emacs
# versions 23.4 and 24.5. These versions were released in January 2012
# and April 2015, respectively, and have a non-trivial security issue
# with ctags. Please upgrade to >=app-editors/emacs-25 and
> On Wed, 23 Nov 2022, Michael Orlitzky wrote:
> The main reason the new category is distasteful to me is because it's
> *so close* to being a virtual. For one, having these packages be
> virtuals would make them somewhat self-explanatory to end users. If
> we're collectively willing to
> On Sat, 19 Nov 2022, David Seifert wrote:
> With this extensive analysis, I believe this patch to be safe.
Still looks like an incompatible change, so it will need an EAPI bump.
EAPI 9 feature bug is here: https://bugs.gentoo.org/815169
signature.asc
Description: PGP signature
> On Sun, 13 Nov 2022, Michał Górny wrote:
> +CC-PD = CC-PDDC
This one is the wrong way around.
> +Fair = fairuse
These are completely different.
> +LPPL-1.3a = LPPL-1.3
Different version (SPDX doesn't have 1.3, and we don't have 1.3a).
Looks like all versions of the FDL are missing?
>>>>> On Sat, 22 Oct 2022, Robin H Johnson wrote:
> On Sat, Oct 22, 2022 at 08:55:09AM +0200, Ulrich Mueller wrote:
>> I'd still prefer a single list of acknowledgements in alphabetical
>> order, without any of the authors included. (But I don't have a strong
>>
> On Sat, 22 Oct 2022, Michał Górny wrote:
> Hi,
> I'm sorry to be late to the party but...
> On Fri, 2022-10-21 at 19:50 +, Robin H. Johnson wrote:
>> +For the purposes of this policy, the Gentoo Foundation will not request
>> +any verification of the name until such time as required by
> On Fri, 21 Oct 2022, Robin H Johnson wrote:
>> So far we had followed the principle not to list authors in the
>> acknowledgements (which is worded "the authors would like to thank").
>> If we start adding them for revision 1.2, then we'd have to add more
>> names to the existing list.
>
> On Tue, 18 Oct 2022, David Seifert wrote:
> What if I want to build Gentoo on an old AMD Thunderbird which has
> neither SSE1 nor the more important SSE2?
The -mfpmath=sse option is a no-op if the CPU doesn't support SSE,
i.e. it will use 387 arithmetics nevertheless.
signature.asc
> On Tue, 18 Oct 2022, David Seifert wrote:
>> > -CFLAGS_x86="-m32"
>> > +CFLAGS_x86="-m32 -mfpmath=sse"
> -mfpmath=sse is already the default on amd64.
I see. This change makes sense then.
What about profiles/arch/x86 though? IIUC we'll end up with an
inconsistency between x86 and
> On Tue, 18 Oct 2022, Mike Gilbert wrote:
> Reference: https://gcc.gnu.org/wiki/x87note
Which says:
| ... the amount of worst-case error that could possibly happen using
| the x87 (with any amount of intermediate rounding) is at worst the
| same as true 64 or 32 bit arithmetic, and in
> On Sat, 15 Oct 2022, Sam James wrote:
> +convert-sfnt - Convert BDF and PCF bitmap fonts to OTB wrapper format
Sorry for the bikeshedding, but could we have a name that indicates what
this global flag is about? Maybe something starting with "font" which
would at least point to the general
> On Wed, 12 Oct 2022, Michał Górny wrote:
> (I mean, most of these files won't even use parallel compression
> because they're too small).
xz(1) says about the block size: "The default size is three times the
LZMA2 dictionary size or 1 MiB, whichever is more." The default (-6)
dictionary
What is the motivation for this? The typical kernel module on my system
has a size of about 20 KiB uncompressed, with the largest about 2 MiB.
Compression times are negligible for these, so is there a need to
optimize?
Ulrich
signature.asc
Description: PGP signature
> On Sat, 01 Oct 2022, Florian Schmaus wrote:
> Bug #719201 was triggered by dev-texlive/texlive-latexextra-2000. It
> appears that the ebuild had more than 6000 entries in SRC_URI [1],
That includes double counting and must be divided by the number of
developers in TEXLIVE_DEVS. AFAICS that
> On Wed, 28 Sep 2022, Florian Schmaus wrote:
> I would like to continue discussing whether we should entirely
> deprecate EGO_SUM without the desire to offend anyone.
> We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic
> is a very popular backup software written in Go.
> On Fri, 23 Sep 2022, Sheng Yu wrote:
> The hash does not need to be lowercase. It can be a quick fix in
> portage to accept any case.
That would break backwards compatibility. Also, having a uniquely
defined format helps when comparing hashes with the output of tools like
b2sum or
> On Wed, 21 Sep 2022, Michał Górny wrote:
> +filaname after stripping the ``.gpkg.tar`` suffix. However,
^
signature.asc
Description: PGP signature
> On Tue, 13 Sep 2022, Matt Turner wrote:
>
>
>
> +
>
>
>
Alphabetical order?
signature.asc
Description: PGP signature
> On Thu, 08 Sep 2022, Mike Gilbert wrote:
> @@ -18,7 +18,7 @@ case "${EAPI:-0}" in
> 0|1|2|3|4|5|6)
> die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> ;;
> - 7)
> + 7|8)
> ;;
> *)
> die "Unsupported
Please also update the license of the GLEP to CC-BY-SA-4.0 [1].
[1] https://www.gentoo.org/glep/glep-0001.html#what-belongs-in-a-successful-glep
(item 8)
> On Thu, 08 Sep 2022, Michał Górny wrote:
> -The Manifest files use UTF-8 encoding.
> +The Manifest files use UTF-8 encoding. Line feed (``U+000A``) character
> +is used to separate lines. For best compatibility, empty lines and any
> +additional whitespace, including the carriage return
> On Thu, 08 Sep 2022, Michał Górny wrote:
> -All files that are not ignored must be covered by at least one
> -of the Manifests.
> +The top-level Manifest is skipped implicitly and it is an error to list
> +it in Manifest files. All the remaining files that are not ignored must
> +be
> On Mon, 29 Aug 2022, Sam James wrote:
>> I think they should be called savannah and savannah-nongnu because gnu
>> isn't savannah. There are many GNU packages that are hosted elsewhere,
>> e.g. gcc, gdb, glibc, or binutils.
> It's a fair point and it's one I raised in #gentoo-qa, although
> On Mon, 29 Aug 2022, Sam James wrote:
> Both for their respective Savannah instances:
> - https://savannah.gnu.org/
> - https://savannah.nongnu.org/
I think they should be called savannah and savannah-nongnu because gnu
isn't savannah. There are many GNU packages that are hosted elsewhere,
> On Sun, 28 Aug 2022, Yiyang Wu wrote:
> - if has ${gpu_target} "${OFFICIAL_AMDGPU_TARGETS[*]}"; then
> + if has "${gpu_target}" ${OFFICIAL_AMDGPU_TARGETS[*]}; then
This still doesn't look right. It should be:
if has "${gpu_target}"
> On Thu, 18 Aug 2022, Sam James wrote:
> ${EMACS} ${EMACSFLAGS} \
> + --eval "(require 'autoload)" \
> --eval "(setq make-backup-files nil)" \
> --eval "(setq generated-autoload-file (expand-file-name
> \"${f}\"))" \
> -f
> On Wed, 17 Aug 2022, wuyy wrote:
> Also, I have some long sentences in code, for throwing information. How
> do I nicely wrap such long strings in bash? By incremental assigning it
> to variables I guess?
It's not an absolute rule. Avoid long lines where possible, but don't
jump through
> On Mon, 15 Aug 2022, Yiyang Wu wrote:
> +_rocm_set_globals() {
> + case ${ROCM_VERSION:-${PV}} in
> + 4*)
What will happen when there's a version 40 in the future?
signature.asc
Description: PGP signature
>>>>> On Tue, 16 Aug 2022, Ulrich Mueller wrote:
>> +IUSE+=" ${gpu_target/#/+amdgpu_targets_}"
> Why "+="? I don't see any previous assignment of IUSE.
Please ignore this. I had missed that it's inside a loop.
signature.asc
Description: PGP signature
> On Mon, 15 Aug 2022, Yiyang Wu wrote:
> diff --git a/eclass/rocm.eclass b/eclass/rocm.eclass
> new file mode 100644
> index ..8ca2c051ddce
> --- /dev/null
> +++ b/eclass/rocm.eclass
> @@ -0,0 +1,275 @@
> +# Copyright 2022 Gentoo Authors
> +# Distributed under the terms of the
> On Mon, 15 Aug 2022, John Helmert wrote:
> # John Helmert III (2022-08-14)
> # Many vulnerabilities (including code execution and root privilege
> # escalation), effectively unmaintained. Removal in 30 days, bugs
> # #631552, #790296, #842789
> sys-cluster/slurm
This will leave
> 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 ...
>
101 - 200 of 2165 matches
Mail list logo