As some of you may already know, I have worked on a new conversion
of the Gentoo ebuild repository (aka gentoo-x86 in CVS) to Git, using
cvs-fast-export. This is now available on Gentoo infrastructure:
https://gitweb.gentoo.org/archive/repo/gentoo-2.git/
A description of the conversion
> On Thu, 26 Aug 2021, Stephan Hartmann wrote:
> --- a/eclass/unpacker.eclass
> +++ b/eclass/unpacker.eclass
> @@ -4,7 +4,7 @@
> # @ECLASS: unpacker.eclass
> # @MAINTAINER:
> # base-sys...@gentoo.org
> -# @SUPPORTED_EAPIS: 5 6 7
> +# @SUPPORTED_EAPIS: 5 6 7 8
> # @BLURB: helpers for
> On Thu, 26 Aug 2021, Alice Ferrazzi wrote:
> As we are moving out to deprecate EAPI=6 from kernel-2.eclass
> start removing it from deblob function. Also clean code linked to old
> kernel versions. kernel sources that use deblob are already updated to
> EAPI=8
Somewhat unrelated, since I
> On Tue, 24 Aug 2021, WANG Xuerui wrote:
> According to their earlier reservation[1] and actual vendor system
> behavior, there are 3 possible values:
> - loongarch64
> - loongarch32
> - loongarchx32
> Only the LP64 ABI is fully supported by the current upstream submission.
> The
> On Tue, 24 Aug 2021, WANG Xuerui wrote:
> It seems the discussion has gone quiet for a while now, so I take that
> we choose ARCH=loong over ARCH=loongarch according to GLEP 53?
LGTM
> If that doesn't receive much objection, I'll prepare and send the
> first few eclass patches soon.
We
> On Mon, 23 Aug 2021, Anthony G Basile wrote:
>>> **WARNING**
>>>
>>> If you happen to have an INSTALL_MASK with a blanket "*systemd*"
>>> glob, you will inevitably break your system. sys-fs/udev contains
>>> "systemd" in some of its filenames, hence a blanket filter rule will
>>> likely
> On Mon, 16 Aug 2021, Mike Gilbert wrote:
> On Sun, Aug 15, 2021 at 6:55 AM Ulrich Müller wrote:
>> + ( # subshell to avoid pollution of calling environment
>> + docinto .
>> + dodoc "${T}"/README.gentoo
>> + )
> I believe the current handling "die"
> On Sat, 14 Aug 2021, Rolf Eike Beer wrote:
> Sadly the docs at
> https://devmanual.gentoo.org/function-reference/install-functions/
> do not show the defaults,
Hm, it says "mode 0755" for doexe, but nothing for doins and dodir.
This should be improved indeed.
> is there a better place to
> On Sat, 14 Aug 2021, Rolf Eike Beer wrote:
> The default owner is root:root anyway, so just make sure other settings do not
> leak outside from the places where it is actually used. This also fixes
> qmail_supervise_install_one() when called from outside of qmail_src_install().
Looking at
> On Fri, 13 Aug 2021, David Seifert wrote:
> On Mon, 2021-08-09 at 19:50 +0200, Thomas Deutschmann wrote:
>> Interesting. You don't even now my view on this but you already have
>> an opinion and are saying that I am the culprit. I think this is
>> called "prejudiced".
> To this day, we're
> On Fri, 13 Aug 2021, Rolf Eike Beer wrote:
> Am Donnerstag, 12. August 2021, 19:39:08 CEST schrieb Michael Orlitzky:
>> On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote:
>> > The default owner is root:root anyway.
>>
>> This is only true of you don't call insopts earlier with some
> On Thu, 12 Aug 2021, Rolf Eike Beer wrote:
> -# @FUNCTION: primes
> -# @USAGE:
> +# @FUNCTION: is_prime
> +# @USAGE:
> # @DESCRIPTION:
> -# Prints a list of primes between min and max inclusive
> -# Note: this functions gets very slow when used with large numbers.
> -primes() {
> -
> On Wed, 11 Aug 2021, Stephan Hartmann wrote:
> case ${EAPI} in
> - 7) ;;
> + 7|8) ;;
> *) die "EAPI=${EAPI:-0} is not supported" ;;
Nitpick: Add "${ECLASS}: " at the beginning of the die message.
> esac
signature.asc
Description: PGP signature
> On Thu, 12 Aug 2021, Rolf Eike Beer wrote:
> dospp() {
> insinto "${QMAIL_HOME}"/plugins/
> - insopts -o root -g "${GROUP_ROOT}" -m 0755
> + insopts -o root -g root -m 0755
install defaults to root anyway, so why are explicit -o and -g needed
here? (Same applies below, of
> On Thu, 12 Aug 2021, Michał Górny wrote:
> On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote:
>> I would say this is mostly aesthetic matter, because we have equally
>> long ARCH names like "microblaze" or "openrisc" too. From a user's
>> perspective I'd personally prefer "loong" to
> On Sun, 08 Aug 2021, Jason A Donenfeld wrote:
> Author: Jason A. Donenfeld
GLEP 42 says about the Author header:
| Author's name and email address, in the form Real Name .
| Mandatory; multiple author headers may be specified if appropriate.
signature.asc
Description: PGP signature
# Ulrich Müller (2021-08-06)
# Masked for removal in 30 days. Upstream has joined the
# manpages-l10n project, so 5.06 was their ultimate release
# as a separate package. Use app-i18n/man-pages-l10n[l10n_it]
# as replacement. Bug #769017.
app-i18n/man-pages-it
signature.asc
Description: PGP
>>>>> On Fri, 06 Aug 2021, Joakim Tjernlund wrote:
> On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote:
>> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote:
>> > I don't think that the ebuild can rely on any particular status of
>> > the
> On Wed, 04 Aug 2021, Andreas Sturmlechner wrote:
> +# Standard dependencies string that is automatically added to BDEPEND
> +# (in EAPI-6: DEPEND) unless VIRTUALX_REQUIRED is set to "manual".
> +# DEPRECATED: Pre-EAPI-8 you can specify the variable BEFORE inherit
> +# to add more
> On Sun, 01 Aug 2021, Joshua Kinard wrote:
> If EAPI support is really needed in the profiles, it seems like there
> has to be a better mechanism to codify it in a more central location
> versus scattering ~390 of the things across the base profiles
> directory.
I have filed
> On Sun, 01 Aug 2021, Joshua Kinard wrote:
> So it looks like Section 2.3, "Reserved EAPIs" is more relevant here:
> 2.3 Reserved EAPIs
> EAPIs whose value consists purely of an integer are reserved
> for future versions of this specification.
> EAPIs whose
> On Sun, 01 Aug 2021, Michał Górny wrote:
>> +3.0) [[ ${EAPI} == 7 ]] \
>> + || die "GTK 2 no longer supported in EAPI
>> ${EAPI}" ;;
> Let's make it:
> [[ ${EAPI} != 7 ]] && die ...
> to keep the logic more straightforward (and consistent with 'if
> On Sun, 01 Aug 2021, Joshua Kinard wrote:
> Let's go one further, though, and also add a mention of eapi, borrowing some
> of the lingo from PMS, since the file is so prolific. See the attached
> patch and let me know how the language looks.
> diff --git a/profiles/eapi/text.xml
> On Sun, 01 Aug 2021, Joshua Kinard wrote:
> I can't find much documentation on the 'eapi' file found in many of the
> profile directories. Several of the ones in
> profiles/arch/{amd64,sparc,mips} all report '5', and this aligns with the
> mips 17.0 profile under default/linux. Since EAPI
>>>>> On Wed, 28 Jul 2021, Thomas Deutschmann wrote:
> On 2021-07-27 16:07, Ulrich Mueller wrote:
>>> +Display-If-Installed: net-analyzer/argus-clients
>> IIUC this won't affect users who have already disabled the flag,
>> so maybe add a [tcpd] use depen
> On Tue, 27 Jul 2021, David Seifert wrote:
> +Display-If-Installed: net-analyzer/argus-clients
IIUC this won't affect users who have already disabled the flag,
so maybe add a [tcpd] use dependency here (and to all other
Display-If-Installed lines below)?
> +for an adhoc firewall based on
> On Tue, 27 Jul 2021, Conrad Kostecki wrote:
> No ebuilds remaining to call directly prune_libtool_files,
> so we could drop the ltprune inherit in eutils.
I see very little benefit, because a) the indirect inherit is limited to
EAPIs 5 and 6, and b) eutils is deprecated. OTOH, there's some
> On Sun, 25 Jul 2021, Roy Bamford wrote:
> I'm in the "if it's not broken don't fix it" school.
+1
I don't see a strong argument to remove SHA512, so leave things as they
are for now.
We can reiterate when there are indications that SHA512 would be broken.
(Then again, the same applies to
>>>>> On Sat, 24 Jul 2021, alicef wrote:
> On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller wrote:
>>>>>>> On Fri, 23 Jul 2021, Alice wrote:
>>
>>>> GNU FSDG-compliance require not only removing non-free code but also
>
> On Fri, 23 Jul 2021, Alice wrote:
>> GNU FSDG-compliance require not only removing non-free code but also
>> to disable loading of known non-free firmware.
So they actually remove code that by itself is free software. I had
suspected that. (By what logic does removing an option add to the
>>>>> On Fri, 23 Jul 2021, Alice wrote:
> On 7/23/21 9:52 PM, Ulrich Mueller wrote:
>> My point is, when we changed the ACCEPT_LICENSE default to @FREE in
>> 2019, there was a discussion if we could remove LICENSE="linux-firmware"
>> from kernel pa
> On Fri, 23 Jul 2021, Alice wrote:
> Gentoo is about choice. if there are users that want to use deblob I
> don't see why we don't have to add the option.
Sure, choice is good.
My point is, when we changed the ACCEPT_LICENSE default to @FREE in
2019, there was a discussion if we could
This will break backwards compatibility for user configuration.
Not sure if it merits a news item (probably not, as it would be
addressed only at users who know what they're doing :) but maybe
respect both variables for some transition time?
signature.asc
Description: PGP signature
>>>>> On Fri, 23 Jul 2021, Alice wrote:
> On 7/23/21 6:04 AM, Ulrich Mueller wrote:
>> Maybe this is a stupid question, but what is USE=deblob doing these days
>> anyway? I thought that all nonfree firmware had been removed from the
>> kernel tree (with versi
Maybe this is a stupid question, but what is USE=deblob doing these days
anyway? I thought that all nonfree firmware had been removed from the
kernel tree (with version 4.14) and was provided separately by the
sys-kernel/linux-firmware package?
Also, if I grep for K_DEBLOB_AVAILABLE in
> On Wed, 21 Jul 2021, Patrice Clement wrote:
> + if [[ -n "${VIM_PLUGIN_HELPFILES}" ]]; then
Quotation marks are not necessary here (and three more times below,
in the elif lines).
signature.asc
Description: PGP signature
> On Wed, 21 Jul 2021, Florian Schmaus wrote:
> case "${EAPI:-0}" in
This could be simplified to ${EAPI} (and no quotation marks).
> 4|5|6|7)
> - EXPORT_FUNCTIONS src_prepare pkg_preinst pkg_postinst pkg_postrm
> + # src_prepare is only exported in EAPI < 8.
> On Tue, 20 Jul 2021, Sam James wrote:
> -Revision: 1
> +Revision: 2
Is this supposed to be read again by users? Then it should be a new news
item (with updated date in filename) and the old item should be deleted.
> +Please note that if you last changed your password before ~2008,
> +it
> On Mon, 19 Jul 2021, Marco Scardovi wrote:
> That's the complete list of packages up for grab after my p-m resignation:
> [...]
> app-i18n/man-pages-it
This won't see any new releases since upstream has joined the
manpages-l10n project:
> On Sun, 18 Jul 2021, Andreas Sturmlechner wrote:
> case ${EAPI:-0} in
This could be just ${EAPI} now (same for check-reqs.eclass).
> - [0-5]) die "virtualx.eclass: EAPI ${EAPI} is too old." ;;
> - 6|7) ;;
> - *) die "virtualx.eclass: EAPI ${EAPI} is not supported yet." ;;
>
> On Fri, 16 Jul 2021, Michał Górny wrote:
> case ${EAPI:-0} in
This could be simplified to ${EAPI}.
> - 0|1|2|3|4|5|6|7) ;;
> - *) die "EAPI ${EAPI} unsupported (yet)."
> + 5|6|7|8) ;;
> + *) die "EAPI ${EAPI} unsupported."
> esac
Add the eclass name to the message?
> On Thu, 15 Jul 2021, Ionen Wolkens wrote:
> Old DEPEND should be kept as-is not to risk breaking packages with odd
> checks that need it present at build time. I'd rather no RDEPEND switch
> either as it'll just complicate things with revbumps and tools don't
> really need to be in RDEPEND
> On Thu, 15 Jul 2021, Florian Schmaus wrote:
> -DEPEND="
> +_XDG_DEPEND="
> dev-util/desktop-file-utils
> x11-misc/shared-mime-info
> "
> +
> +case "${EAPI:-0}" in
> + 4|5|6|7)
> + DEPEND="${_XDG_DEPEND}"
> + ;;
> + *)
> +
> On Thu, 15 Jul 2021, Marek Szuba wrote:
> case "${EAPI:-0}" in
> - 0|1|2|3|4)
> + [0-6])
> die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> ;;
> - 5|6|7)
> + 7|8)
> ;;
> *)
> die "Unsupported
> On Wed, 14 Jul 2021, Marek Szuba wrote:
> On the plus side, nothing in here that requires changing to work with
> the new EAPI. On the minus side, we still got many EAPI-5 and 6
> consumers of this eclass in the tree so no chance of dropping support
> for these two at this time.
Shouldn't
> On Tue, 13 Jul 2021, Michał Górny wrote:
>> Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
> The title is too long (50 chars max AFAIR)
Heh. :)
But yes, I say this every time, but either people don't read others'
news item reviews, or they forget them very
> On Tue, 13 Jul 2021, Marek Szuba wrote:
> Title: PipeWire versions of PulseEffects are now media-sound/easyeffects
Too long.
https://www.gentoo.org/glep/glep-0042.html#news-item-headers
"Title: A short (maximum 50 characters) descriptive title."
> Author: Marek Szuba
> Posted:
> On Fri, 09 Jul 2021, Michael Orlitzky wrote:
>> So if we agree that e.g. zlib should be on by default, then this
>> belongs in profiles.
> We don't agree that it belongs on by default.
Well, that doesn't change the conclusion that it doesn't belong in IUSE
defaults. If anything, it
> On Fri, 09 Jul 2021, Georgy Yakovlev wrote:
> Already pushed as is.
So as far as I can see, you've posted it for review at 02:38:05 today,
and pushed it at 08:25:55?
That is less than the 72 hours mandated by GLEP 42, so definitely
not OK. That pr@ wasn't CCed isn't helpful either.
> On Fri, 09 Jul 2021, Georgy Yakovlev wrote:
> +Title: systemd-tmpfiles replaces opentmpfiles due to security issues
Title is way too long, maximum of 50 characters is allowed.
signature.asc
Description: PGP signature
> On Thu, 08 Jul 2021, Michael Orlitzky wrote:
> Why? This list should be getting smaller, not larger.
> Polluting the base profiles makes running a minimal system that much
> harder, and only "adds no dependencies" because people omit the
> corresponding dependencies -- a situation that has
> On Tue, 06 Jul 2021, William Hubbs wrote:
> -_LUA_SINGLE_R0=1
> +_LUA_SINGLE_ECLASS=1
> fi
These should be assigned immediately after the test near the top of the
eclass, before any inherit statement. Otherwise, circular inheritance
won't be prevented.
Ulrich
signature.asc
>>>>> On Mon, 05 Jul 2021, Haelwenn (lanodan) Monnier wrote:
> [2021-07-05 13:43:27+0200] Ulrich Mueller:
>> Also, the eclass should set PROPERTIES+=" interactive" in the "ext"
>> case, because IIUC it will interactively call SSH_ASKPASS.
> On Mon, 05 Jul 2021, Haelwenn (lanodan) Monnier wrote:
> if [[ ${ECVS_AUTH} == "ext" ]] ; then
> - #default to ssh
> - [[ -z ${CVS_RSH} ]] && export CVS_RSH="ssh"
> - if [[ ${CVS_RSH} != "ssh" ]] ; then
> - die "Support for ext auth with clients other than ssh has
> On Mon, 05 Jul 2021, Haelwenn (lanodan) Monnier wrote:
> -# @SUPPORTED_EAPIS: 4 5 6 7
> +# @SUPPORTED_EAPIS: 5 6 7
Support EAPI 8 while at it? AFAICS it's a trivial update.
> case ${EAPI:-0} in
Just ${EAPI} here.
> - 4|5|6) ;;
> + 5|6) ;;
> 7) BDEPEND="${DEPEND}";
# @DEAD
# Use plocale.eclass as drop-in replacement.
# Functions should be replaced as follows:
# l10n_for_each_locale_do → plocale_for_each_locale
# plocale_for_each_disabled_locale → l10n_for_each_disabled_locale_do
# plocale_find_changes → l10n_find_plocales_changes
# plocale_get_locales →
> On Fri, 02 Jul 2021, William Hubbs wrote:
> case ${EAPI:-0} in
This could be just ${EAPI}.
> - 0|1|2|3|4|5|6)
> - die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
> - ;;
> 7|8)
> ;;
> *)
> - die "Unsupported
> On Fri, 02 Jul 2021, Sergei Trofimovich wrote:
> dev-vcs/cvs-fast-export
I take this one.
signature.asc
Description: PGP signature
> On Fri, 02 Jul 2021, William Hubbs wrote:
> # Go packages should not be stripped with strip(1).
> -RESTRICT+=" strip"
> +if [[ ${EAPI} == 7 ]]; then
> + RESTRICT+=" strip"
> +else
> + RESTRICT=" strip"
> +fi
There was a previous discussion in the QA team that we shouldn't do such
> On Tue, 29 Jun 2021, William Hubbs wrote:
> Is portage stable already supporting eapi 8? if so when did that
> happen?
portage-3.0.20 was the first version supporting EAPI 8, and 3.0.20-r6
is currently being stabilised. [1]
> If not we can't support it in eclasses yet.
I don't think that
> On Mon, 28 Jun 2021, Michał Górny wrote:
> That said, it might be more consistent to change Portage behavior to use
> some visible distinction between output types (not just color), e.g.
> have it output:
> * [QA] ...
> * [WA] ...
> * [ER] ...
+1
Not sure if it's any standard that
> On Mon, 28 Jun 2021, Martin Dummer wrote:
>>> --- a/eclass/vdr-plugin-2.eclass
>>> +++ b/eclass/vdr-plugin-2.eclass
>>> @@ -76,7 +76,7 @@
>>> inherit flag-o-matic toolchain-funcs unpacker
>> This should also inherit strip-linguas.eclass, because strip-linguas is
>> called in
> On Sun, 27 Jun 2021, Martin Dummer wrote:
[Either your mailer or something on the way has mangled whitespace in
your patch, which makes it somewhat hard to read.]
> --- a/eclass/vdr-plugin-2.eclass
> +++ b/eclass/vdr-plugin-2.eclass
> @@ -76,7 +76,7 @@
> inherit flag-o-matic
> On Fri, 25 Jun 2021, Michał Górny wrote:
> + local dosym=dosym
> + [[ ${EAPI} == [67] ]] && dosym=dosym8
> + "${dosym}" -r /usr/lib/python-exec/python-exec2 \
> + "${bindir#${EPREFIX}}/${basename}"
> On Thu, 24 Jun 2021, Conrad Kostecki wrote:
> -if [[ ${EAPI:-0} == 7 ]]; then
> +if [[ ${EAPI:-0} -ge 7 ]]; then
EAPI is a string, not a number. I'd suggest using a string comparison,
e.g.:
if [[ ${EAPI} != [56] ]]; then
(Negative logic, so there won't be any need to update it again
> On Thu, 24 Jun 2021, David Michael wrote:
> if [[ -z ${_MESON_ECLASS} ]]; then
Here would be a good place to assign _MESON_ECLASS=1. It should go
_before_ any inherit commands, otherwise it won't prevent circular
inherits.
>
> +[[ ${EAPI} == 6 ]] && inherit eapi7-ver
> inherit
https://qa-reports.gentoo.org/output/eapi-per-eclass/darcs.eclass/
says that there are no consumers left.
So, could the eclass be removed?
signature.asc
Description: PGP signature
>>>>> On Wed, 23 Jun 2021, Fabian Groffen wrote:
> On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote:
>> It's somewhat hidden, but it's there:
>> https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10
>>
>> 9.1.10 pkg_preinst
>> ... im
> On Mon, 21 Jun 2021, Sam James wrote:
> I'm happy with the whole series. Thanks for working on this.
Merged.
signature.asc
Description: PGP signature
> On Wed, 23 Jun 2021, Michał Górny wrote:
>> It's just not available for everyone for free/without registration
>> anymore. But it is still a thing in Gentoo.
> Your comment makes it sounds like 'just registering' is an option.
> The website seems to disagree with that, pretty clearly
> On Wed, 23 Jun 2021, Joakim Tjernlund wrote:
> In PMS 9.2 is says:
> The call order for upgrading, downgrading or reinstalling a package is:
> pkg_pretend (only for EAPIs listed in table 9.2), which is called outside
> of the normal call order process.
> pkg_setup
> src_unpack
> On Tue, 22 Jun 2021, David Michael wrote:
> -# Then you add appropriate dependency to your package. The dependency
> -# type(s) should be:
> -# - DEPEND (+ RDEPEND) if the group is already needed at build time,
> -# - RDEPEND if it is needed at install time (e.g. you 'fowners' files
> -#
> On Tue, 22 Jun 2021, David Michael wrote:
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -5,7 +5,7 @@
> # @MAINTAINER:
> # base-sys...@gentoo.org (Linux)
> # Michał Górny (NetBSD)
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
> +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7 8
EAPIs 0 to 4
> On Tue, 22 Jun 2021, Marek Szuba wrote:
> Seeing as in the end this USE flag is not going anywhere in spite of
> Gentoo no longer providing PaX-capable kernel sources, could we please
> rename it (e.g. to 'pax-kernel') so that it no longer contains a
> disallowed character. I understand
> On Mon, 21 Jun 2021, Joshua Kinard wrote:
>>> I am inclined to go with "Copyright 1999-2021 Gentoo Authors" across
>>> the board,
>>
>> Why would you move the starting year back in time? Please don't.
>>
>>> but given that copyright is always a touchy subject, figured I'd ask.
> Again,
> On Mon, 21 Jun 2021, Joshua Kinard wrote:
> Doing some review/cleanups in the MIPS profiles and there's some
> degree of variability going on with the top copyright header, mainly
> in the beginning year. I'm wanting to fix all of those up, but what is
> the appropriate beginning year here?
> On Sun, 20 Jun 2021, Michał Górny wrote:
> @@ -712,8 +714,13 @@ python_newexe() {
> )
>
> # install the wrapper
> - _python_ln_rel "${ED%/}"/usr/lib/python-exec/python-exec2 \
> - "${ED%/}/${wrapd}/${newfn}" || die
> + if [[ ${EAPI} != [67] ]]; then
> +
See my posting 4 days ago:
https://archives.gentoo.org/gentoo-dev/message/c71621ccc96873d98697fb35c98c55b1
Merged now.
signature.asc
Description: PGP signature
> On Fri, 18 Jun 2021, Michał Górny wrote:
>> +Post-History: 2021-05-19 2021-06-18
> Sorry for failing to notice it earlier but you've missed a comma between
> the dates.
Thanks. Updated locally.
signature.asc
Description: PGP signature
> On Thu, 17 Jun 2021, Guilherme Amadio wrote:
> There's actually a much simpler solution to this:
> $ is_prime() { test $(factor $1 | cut -d: -f2 | wc -w) == 1; }
> $ for n in $(seq 0 10); do is_prime $n && echo $n is prime; done
> 2 is prime
> 3 is prime
> 5 is prime
> 7 is prime
> $ time
>>>>> On Thu, 17 Jun 2021, Michał Górny wrote:
> On Thu, 2021-06-17 at 12:10 +0200, Ulrich Mueller wrote:
>> > > > > > On Thu, 17 Jun 2021, David Michael wrote:
>>
>> > @@ -33,15 +34,12 @@ _FCAPS_ECLASS=1
>> >
>> > IUSE
> On Thu, 17 Jun 2021, Sam James wrote:
> EAPI 8 is here! In fact, it arrived a few days ago on Sunday:
> [...]
> Things you need to know:
> * You can read the full specification in PMS as above.
> * It's fully implemented in Portage 3.0.20, pkgcore 0.12.0, and
> pkgcheck 0.10.0.
IIUC,
> On Thu, 17 Jun 2021, David Michael wrote:
> @@ -33,15 +34,12 @@ _FCAPS_ECLASS=1
>
> IUSE="+filecaps"
>
> -# Since it is needed in pkg_postinst() it must be in RDEPEND
> +# Since it is needed in pkg_postinst() it must be in IDEPEND
> case "${EAPI:-0}" in
> - [0-6])
> -
> On Wed, 16 Jun 2021, Thomas Deutschmann wrote:
> On 2021-06-16 13:28, Michal Prívozník wrote:
>> Why should we mangle with packages this way? I mean, to me Gentoo was
>> one of the few distros that allowed real choice for users (systemd vs
>> openrc, selinux or !selinux, etc.). We shouldn't
> On Wed, 16 Jun 2021, Michal Prívozník wrote:
>>> 1. Should we be proactively changing the default network in IRC clients
>>> (provided they have one) from Freenode to Libera.chat
>>
>> Yes. IMHO Freenode is no longer a reasonable default.
> Why should we mangle with packages this way? I
> On Wed, 16 Jun 2021, Michał Górny wrote:
> We've moved our official support channels from Freenode to Libera.chat.
> All that's happened afterwards pretty much proves that this was
> the right decision. Maybe even to the point of saying that staying
> on Freenode would be dangerous to our
> On Sat, 29 May 2021, Toralf Förster wrote:
>> Please don't forget to update your IRC handle in LDAP.
> I'm curious where I dan see this information ?
$ ssh dev.gentoo.org
$ perl_ldap -s ${USER}
signature.asc
Description: PGP signature
Please don't forget to update your IRC handle in LDAP. For example, if
you have moved from Freenode to Libera.Chat:
$ perl_ldap -b user -E gentooIM irc://irc.freenode.net/ ${USER}
$ perl_ldap -b user -C gentooIM ircs://irc.libera.chat/ ${USER}
Ulrich
signature.asc
Description: PGP signature
The first draft of EAPI 8 has been posted to the gentoo-pms mailing
list for review:
https://archives.gentoo.org/gentoo-pms/message/e3a7c931ea369e84d81ee70d2fe9802c
> Here is the series of EAPI 8 patches for review. They include the
> pre-approved items from the 2020-11-08 Council meeting, with
> On Fri, 14 May 2021, Marek Szuba wrote:
> Title: >=net-p2p/syncthing-1.17.0 to only allow TLS 1.3 for sync connections
Too long, GLEP 42 allows 50 chars max after "Title: ".
> Author: Marek Szuba
> Posted: 2021-05-18
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed:
> On Sun, 02 May 2021, Fabian Groffen wrote:
> Title: Exim >=4.94 disallows tainted variables in transport configurations
Title is too long (GLEP 42 allows 50 chars max).
> Author: Fabian Groffen
> Posted: 2021-05-??
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed:
> On Thu, 29 Apr 2021, mpagano wrote:
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1241,8 +1241,32 @@ unipatch() {
> local GCC_MAJOR_VER=$(gcc-major-version)
> local GCC_MINOR_VER=$(gcc-minor-version)
>
> -
> On Thu, 29 Apr 2021, Michał Górny wrote:
> +Title: Python 3.9 to become the default target on 2021-06-01
Title is longer than the maximum allowed by GLEP 42 (50 chars).
> [...]
> +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared
> +in make.conf, it is strongly recommended to
> On Mon, 12 Apr 2021, Florian Schmaus wrote:
> -# @RETURN: full path with EPREFIX to a Erlang package/project on success,
> -# code 1 when dependency is not found and code 2 if multiple versions of
> -# dependency are found.
> +# @RETURN: full path with EPREFIX to Erlang package/project on
> On Wed, 07 Apr 2021, Michael Orlitzky wrote:
> 5) There are no clear rules about what @system packages can be left
> out of *DEPEND and when, so their presence is wildly inconsistent.
The rules are pretty clear for BDEPEND and bootstrap packages, which is
what we're talking about here.
> On Tue, 06 Apr 2021, Sam James wrote:
> 1) @system varies between profiles anyway which makes it hard to fully
> rely on;
That's exactly the reason why you _don't_* add GNU grep as a dependency,
because e.g. on Prefix grep may be provided by another package.
grep is a POSIX tool and a
> On Mon, 05 Apr 2021, Sam James wrote:
> + 4|5|6)
> + DEPEND="
> + sys-apps/grep
> + sys-devel/gnuconfig
> + "
> + ;;
> + 7)
> + BDEPEND="
> + sys-apps/grep
We usually don't
> On Thu, 01 Apr 2021, Andreas Sturmlechner wrote:
> +# @FUNCTION: test-flag-PROG
> +# @USAGE:
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if is supported by given ,
> +# else returns shell false.
> test-flag-PROG() {
> + [[ ${EAPI} == [5-7] ]] ||
> + die
> On Wed, 31 Mar 2021, Andreas Sturmlechner wrote:
> setup-allowed-flags() {
> + [[ ${EAPI} == [0-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in
> >=EAPI-8."
> + _setup-allowed-flags
> +}
Strictly speaking, EAPIs are strings, so numeric comparison
> On Mon, 29 Mar 2021, Tim Harder wrote:
> One reason is EAPI development often moves relatively slowly and many
> potential repo spec features are probably simple enough to
> discuss/implement at a quicker pace, at least initially.
"Relatively slowly" is an understatement when it comes to
301 - 400 of 2165 matches
Mail list logo
