[gentoo-dev] Package up for grabs: net-misc/connman-gtk
Dear everyone, After over a decade of standing behind Connman, I have in recent months come to the conclusion that there are now better (or at least better-documented) network-management solutions available for all of my use cases. As a result, I no longer use net-misc/connman-gtk . This is essentially a zero-maintenance package - it has seen very, very few bugs since having been added to the tree, it continues to work fine for the time being, and I have just bumped it to EAPI 8. However, it has currently got no upstream (the relevant GitHub repository got archived in 2021) so if/when changes to its dependencies or to the toolchains eventually render it non-functional, the future maintainer will likely be on their own. Were I still there at that point in time I would probably just last-rite it, then again perhaps there is someone here able and willing to give this tool a fighting chance! -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 2024-02-27 14:45, Michał Górny wrote: In my opinion, at this point the only reasonable course of action would be to safely ban "AI"-backed contribution entirely. In other words, explicitly forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to create ebuilds, code, documentation, messages, bug reports and so on for use in Gentoo. I very much support this idea, for all the three reasons quoted. 2. Quality concerns. LLMs are really great at generating plausibly looking bullshit. I suppose they can provide good assistance if you are careful enough, but we can't really rely on all our contributors being aware of the risks. https://arxiv.org/abs/2211.03622 3. Ethical concerns. ...yeah. Seeing as we failed to condemn the Russian invasion of Ukraine in 2022, I would probably avoid quoting this as a reason for banning LLM-generated contributions. Even though I do, as mentioned above, very much agree with this point. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last rites: media-gfx/gmic
On 2023-10-26 04:41, Eli Schwartz wrote: This is of course either untrue or every kind of over-reaction, and users have commented there to the effect of being willing to help sort things out but there has been radio silence. ...which, sadly, has been my _overall_ experience with G'MIC upstream. I think this also offers some compelling arguments against maintainers being willing to deal with the challenges of this software -- this is a pretty steep social cost to investing time and effort into caring about, using, or maintaining such software. Given where this package has come from, I have got a nagging feeling that its maintainers suffer from a problem that is fairly common among computational scientists (and before anyone gets offended, a quick reminder that I myself am in fact a computational scientist... Plus just have a look at what many sci-* ebuilds have to look like) - namely that however brilliant they might be at devising algorithms, they are rather less adept at developing actual software. Consider some of the issues I have come up against while maintaining this package (disclaimer: I haven't checked if any of these have been fixed in Git since the release of 3.3.1: - the reason for the megapatch, i.e. features being enabled automagically depending on the presence/absence of dependencies at build time. Not that big of a problem for end-users but very much distro-unfriendly; - one of the alleged reasons for G'MIC upstream to have switched from CMake to a hand-crafted Makefile (and one which said Makefile still fails to fix), namely building without X11 support. Given all that is needed to address the issue is something along the lines of "if !X11 CFLAGS+=-Dcimg_display=0", I simply do not understand why this remains open; - the use of RPATH="." with shared libraries in spite of it being widely considered a security risk, and apparently without any actual reason (media-gfx/gmic appears to work perfectly well with the relevant linker flag patched out); - the use of backslash-whitespace construct in the hand-crafted Makefile causes build issues on systems with grep 3.8 or newer. For the record, GNU grep-3.8 was released over a year ago and Gentoo is now on 3.11; - downright broken target dependency chains, even with -j1 (that bit falls under "if anything, the handcrafted Makefile has got worse since its introduction"); - a rather quirky way of locating the GIMP plug-in directory, including attempting to write to that directory when it hasn't been located - or even when the GIMP plug-in is not to be built. I rest my case. Marecki -- is there any specific concern that it's likely to rot quickly if it lacks a maintainer? The megapatch has to be updated on a fairly regular basis so at the very least, we would end up without updates. On top of that we have got the usual problems cropping up every time we add a new gcc/clang version, having to support MUSL (let's be honest, even among the more mature projects testing against non-glibc is rare), slibtool... So yes, I consider media-gfx/gmic very likely to rot quickly without continuous maintenance. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Last rites: media-gfx/gmic
On 2023-10-26 02:29, Jonas Stein wrote: this is a very powerful package with many users. ...but sadly, very few maintainers. It was m-n when I took it over 3 years ago, as apparently no-one found it worth looking after following the disbanding of the Graphics project - and that was back when upstream still used CMake! Telling the truth I wasn't exactly interested either, it's just that it happened to be an optional dependency of media-gfx/darktable. Thank you for maintaining it till now. You're very welcome! Could you address the exact problems to upstream, so they are aware and can improve it? I think not only Gentoo, but also other distributions suffer if it does not build smooth. I used to do that. It seemed to have little to no effect so in the end I just gave up. Looks to me as if the package is not broken now, but there is a lack of manpower to update it. 30 days is the minimum for a removal. There are two outstanding QA issues (ignored LDFLAGS and pre-stripped binaries) in 3.3.1 pertaining to USE=gimp and USE=qt5. Prior to adding that version I tried to leverage qmake-utils.eclass in the Qt parts of the package, which hopefully would have got rid of these issues - but resulted in a wall of actual errors. This has been the last straw as far as me maintaining G'MIC is concerned. I suggest to keep it for a few more months. Fine by me if someone actually maintains it. I've just dropped media-gfx/gmic back to m-n to make it clear that I do not intend to block it from being reactivated. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: media-gfx/gmic
Currently last-rited but since it seems there is interest in keeping it in the tree, I have just returned it to the state in which it was before I took over its maintenance 3 years ago (i.e. m-n). To anyone willing to put up with the updates of the megapatch, the regularly emerging QA issues and the unresponsive upstream: good luck. You will need it. A request (and, to make it absolutely clear, nothing more than a request): PLEASE don't unmask gmic unless it gets a new maintainer. We've got enough junk packages as it is. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-gfx/gmic
Upstream uses a massive home-made Makefile which has since the beginning required massive amounts of patching to make it behave reasonably (as well as to fix the problems which ostensibly led upstream to abandoning CMake, and which they immediately re-introduced in their NIH solution) and which if anything have only got worse since then. One, optional, reverse dependency in the tree. Removal on 2023-11-26. Bug #916289. -- Marecki OpenPGP_signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] metadata: Add stabilisation group for Ansible
Signed-off-by: Marek Szuba --- metadata/stabilization-groups/ansible | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 metadata/stabilization-groups/ansible diff --git a/metadata/stabilization-groups/ansible b/metadata/stabilization-groups/ansible new file mode 100644 index 000..b259400a0fc --- /dev/null +++ b/metadata/stabilization-groups/ansible @@ -0,0 +1,2 @@ +app-admin/ansible +app-admin/ansible-core -- 2.41.0
[gentoo-dev] [RFC PATCH] Add Ansible package-stabilisation group
This is very much for future reference, seeing as stabilisation groups are still very much work in progress. Anyway, the point here is to make it easier to avoid in the future the fairly regular occurrence of Portage complaining about having to hold back newly stabilised Ansible Core owing to version restrictions set in Ansible ebuilds. -- Marecki
[gentoo-dev] Packages up for grabs: media-gfx/rawtherapee media-libs/libiptcdata
In light of the current (proxied) maintainer having stated they no longer have a Linux desktop and therefore expect difficulties in continuing to maintain their packages, media-gfx/rawtherapee and media-libs/libiptcdata are now up for grabs. Both are up to date in the tree. They have also got one open bug each - the former might need a dependency update, the latter appears to fail a documentation-consistency check when emerged with USE=doc. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Breaking changes in dev-libs/msgpack-5.0.0
On 2023-02-06 15:57, Michał Górny wrote: Given there's only a handful of revdeps, perhaps you could simply test them? I can and have in fact already begun, starting with packages affected by IUSE changes. Can't hurt to let maintainers know, though! -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Breaking changes in dev-libs/msgpack-5.0.0
Dear everyone, Having not been given any love for a long time, we have now got in the tree a version of dev-libs/msgpack newer than 3.3.0 - namely 5.0.0. Yes, we have managed to skip the entire major version 4 (yay?)! Anyway, the version in question introduces at least two breaking changes: - since 4.0.0, the (header-only) C++ library is no longer bundled with the C one. As a consequence, a new(ish) package dev-cpp/msgpack-cxx has been introduced and >=dev-libs/msgpack-5.0.0 no longer provide IUSE="boost cxx"; - since 5.0.0 CMake modules for both the C and the C++ variant of msgpack have different names, which might break cmake-based revdeps which have not been updated accordingly. In light of the above, both dev-cpp/msgpack-cxx and >=dev-libs/msgpack-5.0.0 are currently masked in order to give the maintainers of msgpack devreps ample time to test compatibility with the new versions. They will, however, be unmasked on the 3rd of March unless major problems are encountered with the revdep update. There is a tracker bug "msgpack-5" which can be used to group related issues. On behalf of the Vim project, -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-dicts/sword-* app-text/sword-modules
# Upstream keeps the module files unversioned so it is only the use of # mirroring that has prevented us from seeing regular hash mismatches # - and it is not clear for many of the modules whether we are allowed # to mirror them or not. A convoluted and fragile process has been # required to detect new modules and versions, and the request for a # Repology-friendly upstream endpoint appears to have stalled. # Please switch to managing SWORD modules on a per-user basis, using # tools bundled with app-text/sword (see e.g. # https://wiki.crosswire.org/SWORD_Module_Source_Discovery_and_Module_Updating) # or appropriate functionality in GUI front-end software. # Removal in 30 days. Bug #892069. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-editors/elvis
No releases since 2003 (!), upstream effectively dead, no Unicode support, EAPI 6. Removal in 30 days (#884429) -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Co-maintainer needed for app-admin/ansible-lint
Dear everyone, I really could use a hand with app-admin/ansible-lint. Not that it is exactly complicated to maintain, quite the opposite - it's just that upstream has adopted a rather rapid release cycle and now it feels that as soon as I have tested and pushed an ebuild for a version, another one pops up. And that's even without creating tarballs of Ansible Galaxy collections used by the test suite, which is something I would very much like to introduce at some point so that we no longer have to skip so many tests. All offers gratefully received! -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: virtual/dbus
On 2022-09-07 17:36, John Helmert III wrote: If you find a security issue, please file a security bug. I'm not really sure what the security impact of this is, though. I'm not sure if this is a security issue per se (which is why I described it as security-related), here - the default configuration IS the more secure one. > I'm not really sure what the security impact of this is, though. The impact is that systemd+dbus-daemon users currently have to disable DynamicUser functionality for units communicating over D-Bus in order for said communication to actually work. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: virtual/dbus
On 2022-09-07 17:29, Mike Gilbert wrote: A virtual seems a bit pointless for the following reasons: [...] > 2. dbus-broker[launcher] utilizes config files installed by dbus, and > actually RDEPENDs on sys-apps/dbus for that reason. Yeah, I failed at reading - even the README of dbus-broker clearly states "You still need the dbus reference implementation installed, since it provides tools used by many applications, as well as the dbus.socket unit file." If you can think of some way to encourage users to install/enable dbus-broker, that seems like a good idea to me. Makes sense, I'll think about it. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] RFC: virtual/dbus
Dear everyone, I wonder if we should create a virtual package to allow our users - or at least those who run systemd anyway - to choose between sys-apps/dbus and sys-apps/dbus-broken as D-Bus implementation for their systems. The usual "Gentoo is about choice" thing aside, there is now at least one, security-related, problem with the former which can be worked around by switching to the latter: https://github.com/systemd/systemd/issues/22737 WDYT? PS. Cc'ing maintainers of both packages to see what they might have got to say about this. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Add systemd/merged-usr profiles
On 2022-08-31 17:27, Mike Gilbert wrote:
The only pain point I see is for users with /usr on a separate
filesystem and that are not using an appropriate initramfs.
As mentioned on IRC earlier on today, another (although this would be
less of a pain point and more of a sneaky changes to run-time behaviour
of a system) might be ebuilds which rely on PATH precedence of /usr/bin
over /bin to override binaries installed in the latter by other
packages. Some examples:
- app-arch/lbzip2[symlink] - installs /usr/bin/b{,un}zip2 to override
/bin/b{,un}zip2 installed by app-arch/bzip2;
- app-arch/pigz[symlink] - ditto for g{,un}zip and app-arch/gzip;
- app-arch/gzip installs the symlink /bin/uncompress pointing to
gunzip, app-arch/ncompress installs /usr/bin/uncompress pointing to
compress.
There probably are more though, and I feel these will all need a
systemic change - eselect modules? shell aliases? - to how such
overrides are handled. Still, for the time being packages which have
such behaviour controlled by USE flags should me added to
package.use.force of relevant profiles.
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On 2022-07-25 15:35, Peter Stuge wrote: Mikhail Koliada wrote: This idea has been fluctuating in my head for quite a while given that the migration had happened a while ago [0] and some other major distributions have already adopted yescrypt as their default algo by now [1]. Please only do that based on proven merit and nothing else. https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/ , https://www.password-hashing.net/ , the fact we still us the default number of rounds (i.e. 5000) with SHA512 which is *ridiculously* weak for modern hardware, lack of Argon2 support in libxcrypt for the time being due to upstream having decided to wait for an official RFC. You can probably find more yourself if you look. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] gnome-extra/gtkhtml: last rites
A GNOME 2-era library with no consumers left in the tree, marked as deprecated since March 2022. Removal in 30 days (Bug #855299). -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
On 2022-06-29 08:35, Sam James wrote: dev-libs/libxmlb dev-libs/libjcat sys-apps/fwupd sys-apps/fwupd-efi sys-libs/libblockdev sys-libs/libsmbios This is the fwupd stack. I'm tempted for these but I only have one machine which uses them. I'll see if anyone else is a better set of hands first. Sorry, I'd assumed libjcat was here as it's AFAIK only useful really for fwupd, but it wasn't in the original list. But may still be relevant if interested in fwupd. Would need to speak to Marecki if you are interested though. A second pair of hands on the whole lot (I have always co-maintained dev-libs/libjcat with poly-c, and had already added myself to sys-apps/fwupd before the for-grabs call went out due to having observed my ticket for it having been dropped to m-n; will add myself to the rest shortly) will definitely be welcome! They have, sadly, been a bit neglected of late. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
On 2022-06-29 08:15, Joonas Niilola wrote: acct-group/lightdm acct-user/lightdm app-admin/keepassxc mail-mta/msmtp sys-apps/gptfdisk sys-apps/lm-sensors sys-fs/ddrescue x11-misc/lightdm x11-misc/lightdm-gtk-greeter I'll take these. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...
On 2022-06-05 09:28, Joonas Niilola wrote: sys-process/incron I'll take this one, with Infra as fallback maintainers. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] 2022-05-20-borgmatic-config-changes: new item
Signed-off-by: Marek Szuba --- .../2022-05-20-borgmatic-config-changes.en.txt | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt diff --git a/2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt b/2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt new file mode 100644 index 000..672a0fe --- /dev/null +++ b/2022-05-20-borgmatic-config-changes/2022-05-20-borgmatic-config-changes.en.txt @@ -0,0 +1,14 @@ +Title: Breaking configuration changes in borgmatic-1.6.0 +Author: Marek Szuba +Posted: 2022-05-20 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: app-backup/borgmatic + +Version 1.6.0 of app-backup/borgmatic has introduced some breaking +changes to the way Borgmatic handles the merging of its configuration +files and executes command hooks. If you use these features, please +review your Borgmatic config files to make sure they continue to work +correctly with >=app-backup/borgmatic-1.6.0. For details, see [1]. + +[1] https://github.com/borgmatic-collective/borgmatic/releases/tag/1.6.0 -- 2.35.1
[gentoo-dev] News item: breaking change to app-backup/borgmatic user-configuration handling
A couple of breaking changes have been introduced in borgmatic-1.6.0. Only some borgmatic users will be affected but seeing as it is a backup tool, I feel it does warrant a news item. -- Marecki
Re: [gentoo-dev] proposal: use only one hash function in manifest files
On 2022-04-06 19:34, Rich Freeman wrote: This is one of those low cost, low risk, high reward situations IMO. *puts on Council hat* The above pretty much covers my own opinion on the subject. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] Add 2022-03-01-singularity_to_apptainer
Signed-off-by: Marek Szuba --- ...2022-03-01-singularity_to_apptainer.en.txt | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt diff --git a/2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt b/2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt new file mode 100644 index 000..150c947 --- /dev/null +++ b/2022-03-01-singularity_to_apptainer/2022-03-01-singularity_to_apptainer.en.txt @@ -0,0 +1,27 @@ +Title: Transition from sys-cluster/singularity to app-containers/apptainer +Author: Marek Szuba +Posted: 2022-03-01 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-cluster/singularity + +In autumn 2021 the Singularity project joined the Linux Foundation +and changed its name to Apptainer [1]. The change has been reflected +in the renaming of executables/configuration files and environment +variables, as well as a reset of version numbers back to 1.0.0. + +Apptainer packages include compatibility symlinks to old Singularity +executables, continue to honour old environment variables and will upon +the first run import user data from Singularity directories. Therefore, +for most users it will be sufficient to deselect the old package and +install the new one, e.g.: + +emerge --deselect sys-cluster/singularity +emerge app-containers/apptainer + +However, customisations made to system-wide configuration +in /etc/singularity will have to be applied to /etc/apptainer by hand, +and since the bash-completion rule file has been renamed as well any and +all customisations here will have to be updated accordingly as well. + +[1] https://apptainer.org/news/community-announcement-20211130/ -- 2.34.1
[gentoo-dev] News item: migration from sys-cluster/singularity to app-containers/apptainer
Dear everyone, This should be a fairly straightforward thing for the users to do but since manual intervention IS necessary, let us have a news item about it! The date is a placeholder because apptainer upstream has not released 1.0.0 yet, that said I want to have the news item ready for publication as soon as they have (I've already got the ebuild ready). As usual, comments and suggestions are most welcome. -- Marecki
Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
On 13 December 2021 17:24:18 UTC, Mart Raudsepp wrote: >Actually I kind of preferred a static name over straight mktemp, >because emktemp supported other cases than a pure mktemp usage does. >But I don't know if it could ever clash things in some weird >situations. That last part is the message I tried to convey in my e-mail, sorry if I wasn't clear enough. Anyway, could anyone with more Postage/PMS experience weigh in on this? If it is indeed safe then the eclass could be modified further, e.g. to use static names with EAPI-8+ but stick with mktemp for older EAPIs just to be safe. -- Marecki
Re: [gentoo-dev] USE-flag gnome-keyring isn't accurate anymore
On 24 December 2021 08:48:08 UTC, Pacho Ramos wrote: >> > I think “secret” may be too generic and “libsecret” is not ideal in case >> > an implemention comes along that is named differently. How about >> > “secret-service”? >> >> I think this is a good idea. >> > >And "keyring"? I am not sure if users not familiar with "libsecret" will >understand what "secret*" means in this context Definitely a good idea. And I second "keyring", seeing as this term is also in use on other OSes. -- Marecki
Re: [gentoo-dev] USE-flag gnome-keyring isn't accurate anymore
On 24 December 2021 08:48:08 UTC, Pacho Ramos wrote: >> > I think “secret” may be too generic and “libsecret” is not ideal in case >> > an implemention comes along that is named differently. How about >> > “secret-service”? >> >> I think this is a good idea. >> > >And "keyring"? I am not sure if users not familiar with "libsecret" will >understand what "secret*" means in this context Definitely a good idea. And I second "keyring", seeing as this term is also in use on other OSes. -- Marecki
Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
On 2021-12-09 15:04, Michał Górny wrote: Why do you need to use random name in the first place? We have full control over T, so why not just hardcode a good name? Having discussed the matter with eclass maintainers on IRC, they are not entirely sure whether using a static name in this context is entirely safe. There were also concerns about making this change too aggressive given it affects all supported EAPIs. Therefore, we have decided to play it safe and stick as closely to old behaviour as possible, at least for now. Anyway, merged a moment ago. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH 5/5] gnome2.eclass: support EAPI 8
Signed-off-by: Marek Szuba
---
eclass/gnome2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index c6d93a46bfe..0414d5cd5f3 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -4,7 +4,7 @@
# @ECLASS: gnome2.eclass
# @MAINTAINER:
# gn...@gentoo.org
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @PROVIDES: gnome2-utils
# @BLURB: Provides phases for Gnome/Gtk+ based packages.
# @DESCRIPTION:
@@ -25,7 +25,7 @@ case ${EAPI} in
5)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_install pkg_preinst pkg_postinst pkg_postrm
;;
- 6|7)
+ 6|7|8)
EXPORT_FUNCTIONS src_prepare src_configure src_compile
src_install pkg_preinst pkg_postinst pkg_postrm
;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
--
2.32.0
[gentoo-dev] [PATCH 4/5] gnome2.eclass: standardise the EAPI guard
Signed-off-by: Marek Szuba
---
eclass/gnome2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 4b7c3acac06..c6d93a46bfe 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -21,14 +21,14 @@ GNOME2_EAUTORECONF=${GNOME2_EAUTORECONF:-""}
[[ ${EAPI} == [56] ]] && inherit eutils ltprune
inherit libtool gnome.org gnome2-utils xdg
-case ${EAPI:-0} in
+case ${EAPI} in
5)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_install pkg_preinst pkg_postinst pkg_postrm
;;
6|7)
EXPORT_FUNCTIONS src_prepare src_configure src_compile
src_install pkg_preinst pkg_postinst pkg_postrm
;;
- *) die "EAPI=${EAPI} is not supported" ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
# @ECLASS-VARIABLE: ELTCONF
--
2.32.0
[gentoo-dev] [PATCH 3/5] gnome2.eclass: do not call xdg_src_prepare
No longer available for EAPI-8+, and gnome2_src_prepare already calls
xdg_environment_reset via gnome2_environment_reset. All that function
did otherwise was call default src_prepare for EAPI-6+ so do just that
directly.
Signed-off-by: Marek Szuba
---
eclass/gnome2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 6fab55785be..4b7c3acac06 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: gnome2.eclass
@@ -96,7 +96,7 @@ gnome2_src_unpack() {
# Prepare environment for build, fix build of scrollkeeper documentation,
# run elibtoolize.
gnome2_src_prepare() {
- xdg_src_prepare
+ [[ ${EAPI} != 5 ]] && default
# Prevent assorted access violations and test failures
gnome2_environment_reset
--
2.32.0
[gentoo-dev] [PATCH 2/5] gnome2-utils.eclass: support EAPI 8
Trivial now that emktemp is gone.
While at it, include eclass name in the "EAPI x not supported" error
message.
Signed-off-by: Marek Szuba
---
eclass/gnome2-utils.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index 39c4797eedf..97b845c7b88 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -4,7 +4,7 @@
# @ECLASS: gnome2-utils.eclass
# @MAINTAINER:
# gn...@gentoo.org
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @PROVIDES: xdg-utils
# @BLURB: Auxiliary functions commonly used by Gnome packages.
# @DESCRIPTION:
@@ -21,8 +21,8 @@
inherit toolchain-funcs xdg-utils
case ${EAPI} in
- 5|6|7) ;;
- *) die "EAPI=${EAPI} is not supported" ;;
+ 5|6|7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
# @ECLASS-VARIABLE: GCONFTOOL_BIN
--
2.32.0
[gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp
Has been deprecated for quite a while now, comes from eutils.eclass
so it blocks EAPI 8+. Just call mktemp directly.
Signed-off-by: Marek Szuba
---
eclass/gnome2-utils.eclass | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index f7d45090f82..39c4797eedf 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: gnome2-utils.eclass
@@ -16,10 +16,9 @@
# * scrollkeeper (old Gnome help system) management
[[ ${EAPI} == 5 ]] && inherit multilib
-# eutils.eclass: emktemp
# toolchain-funs.eclass: tc-is-cross-compiler
# xdg-utils.eclass: xdg_environment_reset, xdg_icon_cache_update
-inherit eutils toolchain-funcs xdg-utils
+inherit toolchain-funcs xdg-utils
case ${EAPI} in
5|6|7) ;;
@@ -379,7 +378,7 @@ gnome2_gdk_pixbuf_update() {
fi
ebegin "Updating gdk-pixbuf loader cache"
- local tmp_file=$(emktemp)
+ local tmp_file=$(mktemp "${T}"/tmp.XX) || die "Failed to create
temporary file"
${updater} 1> "${tmp_file}" &&
chmod 0644 "${tmp_file}" &&
cp -f "${tmp_file}"
"${EROOT%/}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" &&
--
2.32.0
[gentoo-dev] [PATCH 0/5] EAPI-8 support in gnome2{,-utils}.eclass
EHLO, Unless I have messed something up these are all the changes required to make these two eclasses support EAPI 8. Comments welcome! Nb. I am not the official maintainer of these eclasses, that said I did discuss working on updating them for EAPI 8 with leio on IRC. -- Marecki
[gentoo-dev] Last rites: www-misc/xxv + revdeps
# Marek Szuba (2021-11-27) # XXV has been outdated and unmaintained in Gentoo for years. # EAPI 5, numerous QA violations. # Removal in 30 days. Bug #TBA (Bugzilla is down) www-misc/xxv x11-themes/xxv-skins -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apache/mod_vhost_ldap
# Marek Szuba (2021-11-27) # No activity in upstream GitHub repository since July 2013, # no official release tarballs, unmaintained in Gentoo, EAPI 5. # Removal in 30 days. Bug #TBA (Bugzilla is down) www-apache/mod_vhost_ldap -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Last rites: www-apache/mod_ldap_userdir
On 2021-11-27 15:32, Marek Szuba wrote: # Upstream Web site (including release tarballs) is gone, no activity # in their GitHub repository since June 2021. To avoid confusion, that should have said "2012". Oops. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apache/mod_ldap_userdir
# Marek Szuba (2021-11-27) # Upstream Web site (including release tarballs) is gone, no activity # in their GitHub repository since June 2021. Unmaintained in Gentoo # for years, EAPI 5. # Removal in 30 days. Bug #TBA (Bugzilla is down) www-apache/mod_ldap_userdir -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apache/mod_extract_forwarded
# Marek Szuba (2021-11-27) # Upstream is long gone, unmaintained in Gentoo for years, EAPI 5. # Removal in 30 days. Bug #TBA (Bugzilla is down) www-apache/mod_extract_forwarded -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-apache/mod_evasive
# No upstream activity since October 2005, release tarballs # not available any more. Unmaintained in Gentoo, EAPI 5. # Removal in 30 days. Bug #TBA (Bugzilla is down) www-apache/mod_evasive -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-biology/ApE
# Upstream discontinued Linux support over 10 years ago so we are now # one major version and countless known bugs behind. No source archives # published for current versions. Unmaintained in Gentoo for years, # EAPI 5. Removal in 30 days. Bug #827522 sci-biology/ApE -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-misc/netkit-routed
# Ancient, very few distributions still package it. Both upstream # and the Debian package we use in SRC_URI are now gone. EAPI 5, # unmaintained in Gentoo. # Removal in 30 days. Bug #827322 net-misc/netkit-routed -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-analyzer/nagios-check_pidfile
# Upstream is gone. Unmaintained in Gentoo, last updated # back in the CVS era, EAPI 5, open bugs. # Removal in 30 days. Bug #826790 net-analyzer/nagios-check_pidfile -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-analyzer/nagios-check_fail2ban
# Upstream is gone. Unmaintained in Gentoo, last updated # back in the CVS era, EAPI 5, open bugs. # Removal in 30 days. Bug #826786 net-analyzer/nagios-check_fail2ban -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item
On 2021-11-25 04:49, Mike Gilbert wrote: Also, I don't think it is relevant to call out the mistake by the QA team in a news item intended for end users. My sentiment exactly. No finger pointing in news items, please. I don't like the phrase "forcefully downgraded" here. This implies that something happened without the user's consent. emerge would have informed them of the downgrade before it happened. I would suggest removing the word "forcefully" from these paragraphs. Again, I very much second this suggestion. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-util/yuicompressor
# No new releases since July 2013, no commits to upstream Git repository # since May 2019, long list of known issues (including Bug #681520), # unmaintained in Gentoo, EAPI 5. Consider using dev-util/uglifyjs # instead. # Removal in 30 days. Bug #826470 dev-util/yuicompressor -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-text/pdf2oo
# Last release in 2009, dead upstream. Rendered obsolete by native PDF # importers provided by LibreOffice/OpenOffice, which actually read PDFs # instead of converting them to images. Unmaintained in Gentoo, EAPI 5. # Removal in 30 days. Bug #826382 app-text/pdf2oo -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-text/dbacl
No releases or repo activity upstream since 2013, both versions currently in the tree fail to build (for different reasons), unmaintained in Gentoo, stable ebuild uses EAPI 5. Removal in 30 days. Bug #756925 -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-doc/selfhtml
# Upstream switched from static documentation to the Wiki format # around 10 years ago, and the ebuild we've got in the tree was # massively outdated even then (our version: 812, last static # upstream version: 2001). No maintainer in Gentoo, EAPI 5. # Removal in 30 days. Bug #826454 app-doc/selfhtml -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-admin/psmon
Last release in 2008 at the latest, no maintainer in Gentoo for years, EAPI 5, upstream is gone, the only distros which still package it are Gentoo, Funtoo and LiGurOS. Removal in 30 days. Bug #826682 -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
Sorry about a long delay responding, I ended up being offline until the end of last week and I've had quite a lot of catching up. Anyway, let me begin by addressing a sentiment expressed independently in several responses and which could be summarised as "just come and help". A laudable idea in theory - except as a project run entirely by unpaid volunteers, we can neither hire more people nor demand that developers work on more things than they already do. It might sound harsh but if working in particle physics (which like most public-sector research suffers from chronic shortage of manpower comparing to the amount of things to do, and which is nowadays based primarily on large-scale collaborations whose leadership has only minimal authority over individual participants) has taught me anything, it's that it is better to do a good job at two things than a mediocre one at ten. Moving on to specific comments: On 18/10/2021 01:50, Sam James wrote: > - Most failures found via arch testing _aren't_ arch-specific, but they serve as a useful quality check. That is, > usually, we're not held back by some odd e.g. SIGBUS that nobody knows how to fix. Possibly true (I've got no evidence to make a definite statement either way) - but there is a point in testing, or in pretty much any technical activity, when the amount of work required to polish something further begins to strongly outweigh the benefits. Moreover, the above doesn't really sound to me like a case in defence of stabilisation on exotic arches; quite the opposite in fact. > - Encourage developers to run test suites on their packages. This is a modern part of Gentoo development > and isn't optional if a package has a functioning test suite which isn't hell to get running - i.e. you should really > _try_. People who do not do this yet should be taken behind the chemicals shed and sho... I mean, be very much ashamed of themselves. Not sure what that has got to do with arch testing though, given what kind of hardware most of us do Gentoo development on. > - We drop any large suites of packages at least to ~arch where they're problematic. In addition to the dependency-creep problem already mentioned by Michał, I am not convinced that arbitrarily declaring some package or other not worthy of stable status on arch X would make the user experience on this arch better than downgrading the whole arch to ~X. Furthermore, I am pretty sure arch testers would then have to keep track of which packages must not be stabilised where - meaning more work. On 18/10/2021 01:25, Thomas Deutschmann wrote: Could you please elaborate what you are expecting from this change? I.e. will this solve any problem (please name it)? Will it allow us to move forward where we are blocked at the moment (please name it)? One part of this has already been mentioned by the others, i.e. all too often low activity on these arches ends up delaying overall progress of things such security issues for ALL Gentoo users. Another is that IMHO there are way too few people active in these arch teams to keep up with the work load - even including sam's activity pretty much all over the place, which at this rate I fear will result in him burning out soon, things are far from great. On 15/10/2021 22:40, Rolf Eike Beer wrote: > My machines should actually do some useful stuff, like running my Nagios and a > bunch of nightly builds (CMake, libarchive, things like that). For that, I'd > like to have the actual system to work. Given the amount of breakage I find > when doing stabilizations I suspect this is not going to happen. Maybe, maybe not... If my experience with RISC-V keywording is anything to go by, a lot of breakage comes from unexpected interactions due to throwing everything but a kitchen sink on a single system - which having to deal with stabilisation makes more likely, especially on an arch which does not see many new keywording requests (on riscv, which is still quite active in this respect, I simply run all keywording tests with --oneshot and regularly distclean the system). On 14/10/2021 18:10, Michał Górny wrote: > While we're discussing it, maybe we should start by defining a clear > criteria for platform support tiers? Like: what are the requirements > for a platform to maintain stable keywords? Then the decisions could > look less arbitrary, and people would have a clear way of knowing what > they need to do if they wish the platform to continue having stable > keywords. Not a bad idea but I wonder how much effort we might want to throw at this, especially given we're not Red Hat or SUSE. -- MS
[gentoo-dev] [RFC] Moving more architectures to ~arch only
Dear everyone, Following some private discussions, I feel quite strongly now that it would both considerably improve certain processes and make our use of limited manpower more efficient were we to further reduce the number of stable arches in Gentoo Linux. Specifically, I propose to drop - hppa, - ppc, - sparc, - x86 to ~arch-only status. Note that this does NOT mean we intend to drop support for those arches altogether. There are IMHO several good reasons for this: - most of the arches from this list are quite dated and either aren't really developed upstream any more or got superseded by newer ones (for the record, it's been 18 years since the first amd64 CPUs came out) - we have got very few people actually supporting these arches, and in case of hppa there is also the hardware bottleneck. Subsequently, stabilisation requests often take a long time to resolve - feedback we receive, e.g. by Bugzilla, suggests that Gentoo on at least some of these arches have got very, very few users - last but by no means least, my personal experience from the last several years suggests that running ~arch is reasonably trouble-free these days WDYT? -- Marecki
Re: [gentoo-dev] Packages up for grabs: misc packages from chainsaw@
On 2021-10-05 05:04, Sam James wrote: Hi all, Chainsaw asked retirement@ to drop him to maintainer-needed on his packages, so here's the resultant packages with no maintainers left: app-admin/ansible-lint > dev-python/requests-credssp I'll take these. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Guidance on distributed patented software
On 2021-09-26 21:20, Rich Freeman wrote: Back in the PGP ITAR days I believe somebody went through some loopholes to publish the software outside the US, Yes, PGP 2.6 source code got published as an OCR-friendly book (https://dl.acm.org/doi/book/10./207390) which was then legally taken from the US abroad. and it is probably debatable whether that was legal under US law, I am no expert on US law but from what I have read (in many different sources, with me having begun using PGP in either late 1996 or early 1997 i.e. when it was still very much subject to US export restrictions) about this case, both the publishing of the source-code book and it having subsequently been taken out of the country has been legal - the former due to publishing the first amendment and the second due to the scope of ITAR as far as crypto software was concerned. but presumably the people who did it didn't care, and enforcement was unlikely at all, and especially unlikely if you didn't have plans to visit the US after bragging about distributing it. I don't know if Ståle Schumacher (the person who scanned the book and subsequently published "international" versions of PGP 2 in Norway) ever visited the US afterwards. On the other hand the source-code book itself, the purpose of which was rather clear given it even contained notes on how to OCR it, was written by a US person (Phil Zimmermann himself) and published by a US company (MIT Press) - so I am not quite convinced they either thought they would be our of reach of US law (indeed, wasn't PRZ still being persecuted by US Customs at the time?), or didn't care. Not that any of this changes the point you have tried to make regarding due diligence, mind you. -- Marecki
Re: [gentoo-dev] [PATCH 00/44] @PROVIDES for eclasses
On 2021-09-02 11:46, Michał Górny wrote: lua.eclass: Set @PROVIDES lua-single.eclass: Set @PROVIDES ACK on these two. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cmake.eclass: support EAPI 8
On 2021-08-16 18:31, Andreas Sturmlechner wrote: Feel free to pick up task no. 3 from the bug. Everything else is either done already or easy enough. OK, I'll see what I can do. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Package up for half-grabs: net-libs/nodejs
On 2021-08-16 17:50, Joonas Niilola wrote: It'd help if you described the caveats that are to be expected. I would say there are two: 1. Apart from from what comes out on the latest even branch (I would strongly advise against packaging odd branches if you value your sanity, except possibly right before the release of the next even branch to make sure all the Gentoo-specific patches apply and do what they're supposed to do - which is what we did with v15/v16) in its early days, almost all the new versions of Node.js are security releases. This implies quite a lot of stabilisation requests to keep track of, many of which will not even have been completely resolved when a new security release comes out. 2. The test suite is somewhat fragile. Some tests dislike the Portage sandbox, some of the more recent ones fail if executed in an unprivileged container, once in a while you will run into a failure caused by a combination of configure settings / build flags upstream has not thought about (at least said upstream is reasonably friendly and swift to respond to reported issues if you give them all the technical details), and once in a while there WILL be some user-reported test failure which you will never manage to reproduce until it has magically gone away for the user themselves come next release. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cmake.eclass: support EAPI 8
On 2021-08-16 18:06, Joonas Niilola wrote: What's the rush with 8 anyway? We still have eclasses that don't even support 7. And since 6 is now, sigh, deprecated, any bump to ebuilds depending on those eclasses will add to the evergrowing CI issue list right? I'd say it's more important to secure EAPI-7 support there first. ...or we could just skip supporting EAPI 7 support in such packages and go from 6 straight to 8. In my own experience with EAPI bumping, I would rank migration difficulty (with the more difficult cases listed first) as follows: 1. 5 to 6 - a lot of changes to take into account, all of them adding up to a massive pain in the neck - especially if patches have to be regenerated in order to work with eapply; 2. 6 to 7 - the trailing-slash-in-D-and-ED thing can be a nuisance but that's pretty much it, even moving packages from DEPEND to BDEPEND can be considered minor owing to how little breakage not doing it can cause (cross-building packages IS useful, that's how we initially bootstrapped dev-lang/go on riscv for instance, but it's not that widespread); 3. 7 to 8 - everything except the bash version bump can be handled quickly with grep and mgorny's checklist. In short, so far I've found the cost of adding EAPI 8 support minimal comparing to support for earlier versions. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cmake.eclass: support EAPI 8
On 2021-08-16 17:49, Sam James wrote: See https://bugs.gentoo.org/802786 and https://github.com/gentoo/kde/pull/903. There's some work to be done first. I see. Guess we'll have to stick with EAPI 7 for cmake revdeps in the foreseeable future, then. -- MS OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cmake.eclass: support EAPI 8
A word of explanation seeing as I forgot to use --compose to annotate
the patch itself. Looks like Project KDE has got their hands full with,
well, KDE, therefore here's my take on bumping EAPI support in
cmake.eclass. I am not a maintainer of this eclass so I've only made the
smallest possible changes to get it to work with EAPI 8 (i.e. no removal
of banned functions etc.) - and fortunately it seems extending the $EAPI
check is all that is needed.
Would be great if someone from kde@g.o. could give their blessing (or
lack thereof) to this patch.
On 2021-08-16 17:43, Marek Szuba wrote:
Signed-off-by: Marek Szuba
---
eclass/cmake.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea6..52bf65a463d 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -9,7 +9,7 @@
# Maciej Mrozowski
# (undisclosed contributors)
# Original author: Zephyrus (zephy...@mirach.it)
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: common ebuild functions for cmake-based packages
# @DESCRIPTION:
# The cmake eclass makes creating ebuilds for cmake-based packages much
easier.
@@ -98,7 +98,7 @@ _CMAKE_ECLASS=1
# Helps in improving QA of build systems that write to source tree.
case ${EAPI} in
- 7) ;;
+ 7|8) ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
--
Marecki
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] [PATCH] cmake.eclass: support EAPI 8
Signed-off-by: Marek Szuba
---
eclass/cmake.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea6..52bf65a463d 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -9,7 +9,7 @@
# Maciej Mrozowski
# (undisclosed contributors)
# Original author: Zephyrus (zephy...@mirach.it)
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: common ebuild functions for cmake-based packages
# @DESCRIPTION:
# The cmake eclass makes creating ebuilds for cmake-based packages much easier.
@@ -98,7 +98,7 @@ _CMAKE_ECLASS=1
# Helps in improving QA of build systems that write to source tree.
case ${EAPI} in
- 7) ;;
+ 7|8) ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
--
2.31.1
Re: [gentoo-dev] News item: breaking change to app-misc/mc user-configuration handling
On 2021-08-16 16:22, Lars Wendler wrote: thank you very much for wqriting this up. I highly appreciate this. Cheers! echo 'app-misc/mc' >> /etc/portage/package.use I suppose that should be: echo 'app-misc/mc xdg' >> /etc/portage/package.use Indeed. Fixed locally. and have every user on your system with ~/.mc present run mc at least run mc _and_ mcedit once Good call. Also fixed locally. No action is required of everyone currently using app-misc/mc s/of/for/ ? I think both are grammatically correct. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] News item: breaking change to app-misc/mc user-configuration handling
Title: >=app-misc/mc-4.8.27 to drop support for ~/.mc Author: Marek Szuba Posted: 2021-08-19 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-misc/mc app-misc/mc versions between 4.8.1 and 4.8.26, inclusive, would look for their user configuration in two possible places: * if built with USE=-xdg, only the legacy directory ~/.mc is used; * if built with USE=xdg, mc uses appropriate XDG user directories (e.g. ~/.config/mc, ~/.local/share/mc) if present and attempts to automatically migrate the contents of ~/.mc otherwise. However, starting with version 4.8.27 Midnight Commander will use _only XDG user directories_ for its configuration and no longer automatically migrate the contents of ~/.mc. For more information, see: https://midnight-commander.org/wiki/NEWS-4.8.27 https://midnight-commander.org/ticket/3682 For everyone who currently uses app-misc/mc[-xdg], or has not started mc for so long that it hasn't had a chance to migrate its configuration, upgrading to 4.8.27 or newer will result in Midnight Commander effectively reverting to default user configuration. In order to prevent this from happening, make sure automatic migration is available: echo 'app-misc/mc' >> /etc/portage/package.use emerge --oneshot
[gentoo-dev] Package up for half-grabs: net-libs/nodejs
Hi all, I'm taking a (hopefully temporary) break from maintaining net-libs/nodejs, as I expected when took it on it is a relatively high-intensity package and I fear that if I keep it up at this rate I'll end up burning out as a Gentoo developer. Anyone interested in stepping in? Node has still got another maintainer in Gentoo who to the best of my knowledge isn't going anywhere, but I do feel this package needs more than one pair of hands. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Multiple packages up for grabs
On 2021-08-10 06:17, Mikle Kolyada wrote: I will take those as yubikey is my daily use now And I'll co-maintain them, both for the same reason as zlogene and because I maintain two YubiKey-related packages (as well as one for SoloKeys which depends on fido2) already. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Guarantees of unstable architectures
Dear everyone, During the open-floor part of this month's Council meeting I asked whether there is any official policy regarding what is or is not guaranteed for hardware architectures we do not consider stable in Gentoo. For reference, according to the current version of profiles/arches.desc (commit 7bdebec50c44c0222bf76334c34926b593e94dd4, dated 2021-04-05) this means: alpha, ia64, m68k, mips, riscv, s390, and all Prefix arches. As it turns out, we do not in fact have any such policy. On the other hand, during my time as a Gentoo developer I have heard from other developers a fairly wide range of opinions on the subject - from insisting on clean QA results, passing tests etc. regardless of whether an arch is stable or not to assuming we guarantee nothing for unstable arches. Anyway, it has been decided that it makes sense to discuss this on the mailing list before making it a Council matter. Therefore - what do you all think here? -- Marecki
[gentoo-dev] [PATCH 2/2] lua-single.eclass: consider historical impls in _lua_verify_patterns()
This is so that lua_gen_foo() calls die on mentions of formerly
supported implementations, allowing for such mentions to be gradually
removed from ebuilds which contain them.
Signed-off-by: Marek Szuba
---
eclass/lua-single.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index ab4fdb3c75a..f55c3f80948 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -348,7 +348,7 @@ _lua_verify_patterns() {
local impl pattern
for pattern; do
- for impl in "${_LUA_ALL_IMPLS[@]}"; do
+ for impl in "${_LUA_ALL_IMPLS[@]}"
"${_LUA_HISTORICAL_IMPLS[@]}"; do
[[ ${impl} == ${pattern/./-} ]] && continue 2
done
--
2.31.1
[gentoo-dev] [PATCH 1/2] lua-utils.eclass: new eclass variable _LUA_HISTORICAL_IMPLS
Similarly to _PYTHON_HISTORICAL_IMPLS, it will hold names of Lua implementations which used to be supported but no longer are. Signed-off-by: Marek Szuba --- eclass/lua-utils.eclass | 7 +++ 1 file changed, 7 insertions(+) diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass index 278bbca58a3..12067928002 100644 --- a/eclass/lua-utils.eclass +++ b/eclass/lua-utils.eclass @@ -40,6 +40,13 @@ _LUA_ALL_IMPLS=( ) readonly _LUA_ALL_IMPLS +# @ECLASS-VARIABLE: _LUA_HISTORICAL_IMPLS +# @INTERNAL +# @DESCRIPTION: +# All historical Lua implementations that are no longer supported. +_LUA_HISTORICAL_IMPLS=() +readonly _LUA_HISTORICAL_IMPLS + # @FUNCTION: _lua_set_impls # @INTERNAL # @DESCRIPTION: -- 2.31.1
[gentoo-dev] [PATCH 0/2] Lua eclasses: prepare for dropping lua5-2 support
If memory serves me right there _are_ ebuilds which mention lua5-2 in lua_gen_cond_dep() calls. Let's steal another idea from Python eclasses and allow this implementation not to trip pattern validation in spite of no longer being supported by the eclasses, by be declaring it a historical implementation. For the time being the list of historical implementations is empty, will move lua5-2 to it on the scheduled date. -- Marecki
Re: [gentoo-dev] fortran-2.eclass EAPI-8 support
On 2021-07-16 22:50, Sam James wrote: But to introduce a fix, isn't it a _lot_ easier to do it at the point of a new EAPI? In general, IMHO only if we intend to preserve the old (incorrect) behaviour for older EAPIs - which in this particular case was not needed because I cannot think of someone having come to rely on the fact EAPI-7 ebuilds inheriting fortran-2 could not be cross-compiled. In this particular case, the patch I submitted for review earlier on today explicitly mentions neither EAPI 7 nor EAPI 8 - so not really, no. In fact, I would argue that in case of eclasses requiring more work to adapt to a new EAPI trying to fix old bugs at the same time could distract reviewers from the EAPI adaptation itself. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] fortran-2.eclass: use BDEPEND on EAPI 7+
For FORTRAN_NEEDED=test we need both the compiler and the test binaries
to run on the build host only, hence new EAPIs only set BDEPEND here;
For other modes (other than "no", of course), we need a Fortran compiler
running on the build host as well as the runtime libraries built for the
target arch, necessitating the use of both DEPEND and BDEPEND on newer
EAPIs.
Closes: https://bugs.gentoo.org/802153
Signed-off-by: Marek Szuba
---
eclass/fortran-2.eclass | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 9d0c71703e4..2409cfcda5b 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -69,6 +69,9 @@ if [[ ! ${_FORTRAN_2_CLASS} ]]; then
for _f_use in ${FORTRAN_NEEDED}; do
case ${_f_use} in
always)
+ if [[ ${EAPI} != [56] ]]; then
+ BDEPEND+=" virtual/fortran"
+ fi
DEPEND+=" virtual/fortran"
RDEPEND+=" virtual/fortran"
break
@@ -77,9 +80,16 @@ for _f_use in ${FORTRAN_NEEDED}; do
break
;;
test)
- DEPEND+=" ${_f_use}? ( virtual/fortran )"
+ if [[ ${EAPI} != [56] ]]; then
+ BDEPEND+=" ${_f_use}? ( virtual/fortran )"
+ else
+ DEPEND+=" ${_f_use}? ( virtual/fortran )"
+ fi
;;
*)
+ if [[ ${EAPI} != [56] ]]; then
+ BDEPEND+=" ${_f_use}? ( virtual/fortran )"
+ fi
DEPEND+=" ${_f_use}? ( virtual/fortran )"
RDEPEND+=" ${_f_use}? ( virtual/fortran )"
;;
--
2.31.1
[gentoo-dev]
With many thanks to ulm for having pointed this out. Not that while this patch does indeed change the eclass behaviour for the established EAPI 7 rather than for the new EAPI 8, it does so in a way I deem non-intrusive enough to allow this - the only case where something is actually removed from DEPEND is when Fortran is only required by tests. Not to mention that, ahem, there is considerable room for improvement as far as the uptake of EAPI 7+ among consumers of this eclass is concerned.
Re: [gentoo-dev] [PATCH] cuda.eclass: EAPI support: add 8, drop 5 and 6
On 2021-07-15 06:58, Ulrich Mueller wrote: In the latest bunch of updates, we have changed many eclasses to have only a single error case, and also standardized the die message. Maybe simplify this eclass as well? If anyone from Sci suggests/seconds this I shall not argue, that said I do in fact like having both the two cases separate and the eclass name in the die message - so between that and the fact we have already got EAPI 8-compatible eclasses in the tree which do it this way, I am leaving this part be at present. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] cuda.eclass: EAPI support: add 8, drop 5 and 6
Signed-off-by: Marek Szuba
---
eclass/cuda.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index b1da77c69dd..08d2302d55b 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -1,11 +1,11 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
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 EAPI=${EAPI} (unknown) for ${ECLASS}"
@@ -15,7 +15,7 @@ esac
# @ECLASS: cuda.eclass
# @MAINTAINER:
# Gentoo Science Project
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: Common functions for cuda packages
# @DESCRIPTION:
# This eclass contains functions to be used with cuda package. Currently it is
--
2.31.1
[gentoo-dev] cuda.eclass EAPI-support shuffle
Like fortran-2 adding support for EAPI 8 appears to be trivial, unlike fortran-2 we have no longer got any deprecated-EAPI ebuilds in the tree inheriting it.
Re: [gentoo-dev] fortran-2.eclass EAPI-8 support
On 2021-07-14 13:02, Ulrich Mueller wrote: Shouldn't virtual/fortran go into BDEPEND in EAPIs 7 and 8? Good point! I've created https://bugs.gentoo.org/802153 so that we do not lose track of this, that said it is beyond the scope of the issue at hand (the eclass will not behave any differently here under EAPI 8 than it does under EAPI 7) so I'll leave my current patch as it is. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] News item v2: media-sound/pulseeffects "renaming"
On 2021-07-13 18:54, Michał Górny wrote: +media-sound/easyeffects is already available in the tree, and the +remaining PipeWire-dependent ebuilds of media-sound/pulseeffects will s/ebuilds/versions/. Changed locally. +be removed in 7 days. Probably better to use an explicit date here. '7 days' sounds relative to 'now'. It was supposed to mean "7 days from the date of this news item having been published" - but you're right, an explicit date will be easier to parse. Changed locally to "on 2021-07-23". PS. Having thought about it some more, now that we do have instructions for users not wishing to switch to PipeWire in the news item I have locally removed the media-sound/pulseeffects version limit from Display-If-Installed. That way people who haven't thought about switching from plain PA to PW yet, or perhaps do not even know yet that PW can be used as a drop-in replacement for PA (I for one did not until just a few weeks ago; the fact the former resides in media-video doesn't help) will not be caught by surprise if/when they do decide to switch. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
On 2021-07-13 18:35, William Hubbs wrote: >> are there any non-cosmetic reasons for doing this? Consistency with the rest of the tree. If you do a "git grep _R0" on the eclass directory, the lua eclasses are the only ones that have this in the names of the guard variables, and the eclasses themselves aren't named lua-r0.eclass etc. What will break if I do this? Nothing should, given that eclass guard variables should have no interactions with anything other than respective eclasses themselves. Of course that means this change *is* purely cosmetic... especially considering that while _FOO_ECLASS is currently the most common format in the tree it is by no means the only one, and that revision 0 is technically speaking a real thing that we just happen to treat as default and omit from names for brevity. I've got no preference either way as long as guard variables can easily be searched for in eclass code, so if you haven't got anything more important to work on in Gentoo go ahead. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 8
Signed-off-by: Marek Szuba
---
eclass/fortran-2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 0bb00f475a2..9d0c71703e4 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -7,7 +7,7 @@
# @AUTHOR:
# Author Justin Lecher
# Test functions provided by Sebastien Fabbro and Kacper Kowalik
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Simplify fortran compiler management
# @DESCRIPTION:
# If you need a fortran compiler, then you should be inheriting this eclass.
@@ -31,7 +31,7 @@ inherit toolchain-funcs
case ${EAPI:-0} in
# not used in the eclass, but left for backward compatibility with
legacy users
5|6) inherit eutils ;;
- 7) ;;
+ 7|8) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
--
2.31.1
[gentoo-dev] fortran-2.eclass EAPI-8 support
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.
[gentoo-dev] [PATCH] News item v2: media-sound/pulseeffects "renaming"
Signed-off-by: Marek Szuba --- ...2021-07-16-pulseeffects-easyeffects.en.txt | 33 +++ 1 file changed, 33 insertions(+) create mode 100644 2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt diff --git a/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt b/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt new file mode 100644 index 000..70d1899 --- /dev/null +++ b/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt @@ -0,0 +1,33 @@ +Title: PulseEffects-5+ are now media-sound/easyeffects +Author: Marek Szuba +Posted: 2021-07-16 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: >=media-sound/pulseeffects-5.0.0 + +Since version 5.0.0, media-sound/pulseeffects have explicitly required +media-video/pipewire rather than just a PulseAudio client (i.e. either +PipeWire or plain media-sound/pulseaudio). Following up on this change, +upstream has decided to rename the project to EasyEffects starting with +version 6.0.0. + +Gentoo will follow the upstream renaming but in a slightly different +fashion: + - versions older than 5.0.0, i.e. ones not depending on + media-video/pipewire, will continue to use the name + media-sound/pulseeffects; + - versions: 5.0.0 and newer, i.e. all requiring media-video/pipewire, + will be available as media-sound/easyeffects. + +media-sound/easyeffects is already available in the tree, and the +remaining PipeWire-dependent ebuilds of media-sound/pulseeffects will +be removed in 7 days. Therefore, PipeWire users of +media-sound/pulseeffects should switch to the new package by +deselecting the old one and installing the new one, e.g. + +emerge --deselect media-sound/pulseeffects +emerge media-sound/easyeffects + +No action is required of media-sound/pulseeffects users who either use +PulseAudio exclusively or wish to retain the ability to use this +package with both PulseAudio and PipeWire. -- 2.31.1
[gentoo-dev] News item v2: media-sound/pulseeffects "renaming"
New version incorporating suggestions from mgorny and ulm, thank you for your feedback. -- Marecki
Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"
On 2021-07-13 07:20, Michał Górny wrote: Title: PipeWire versions of PulseEffects are now media-sound/easyeffects The title is too long (50 chars max AFAIR) Argh, and after all my attempts to keep this as short as possible while keeping this meaningful :-) Will think of something even shorter. Display-If-Installed: >=media-sound/pulseeffects-5.0.0 Why not display it to users of all versions? Only people using 5.0.0+ will have to take any action on this so it feels like displaying it for all versions would needlessly bother users who are happy with PulseAudio. I like short but here it seems that you're skipping some essential details and having users guess. > Maybe start by explaining the current state [...] Makes sense, thanks! I'll revise this along the lines of your suggestions. Finally, tell explicitly what PA and PW users should do, and provide an example emerge snippet (do they need to deselect pulseeffects?). Right, they do need to deselect pulseeffects given it will almost certainly be in the world file, won't they. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: News item: media-sound/pulseffects "renaming"
On 2021-07-13 01:01, Marek Szuba wrote: Title: PipeWire versions of PulseEffects are now media-sound/easyeffects Author: Marek Szuba Posted: 2021-07-16 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: >=media-sound/pulseeffects-5.0.0 In response to the upstream decision to rename PulseEffects to EasyEffects we have decided to adopt the new name for versions only supporting media-video/pipewire while retaining the old one for versions allowing the use of media-sound/pulseaudio. media-sound/easyeffects is already available in the tree, and all the PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are asked to emerge media-sound/easyeffects instead. Looks like Thunderbird's somehow cocked up the line breaks in the first paragraph :-/ For the record, _this_ is what the news item looks like (modulo quote marks of course) in my text file. -- MS OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] News item: media-sound/pulseffects "renaming"
Officially the new name has only been in effect since version 6.0.0 but having discussed this with prometheanfire on IRC, it makes sense to extend the new name to >=5.0.0 - that way people not interested in switching from plain PulseAudio to PipeWire can continue to use v4 (which according to upstream is now in maintenance mode, i.e. hasn't been EOLed yet) without having to mask v5 ebuilds. It 7 days feels like a reasonable time to wait before dropping media-sound/pulseeffects-5.0.4 from the tree because this news item will continue to display for affected users even after the ebuild is gone, won't it. * * * Title: PipeWire versions of PulseEffects are now media-sound/easyeffects Author: Marek Szuba Posted: 2021-07-16 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: >=media-sound/pulseeffects-5.0.0 In response to the upstream decision to rename PulseEffects to EasyEffects we have decided to adopt the new name for versions only supporting media-video/pipewire while retaining the old one for versions allowing the use of media-sound/pulseaudio. media-sound/easyeffects is already available in the tree, and all the PipeWire-dependent ebuilds of media-sound/pulseeffects will be removed in 7 days. Therefore, users of >=media-sound/pulseeffects-5.0.0 are asked to emerge media-sound/easyeffects instead. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-crypt/cardpeek
# Marek Szuba (2021-07-12) # No releases since March 2015, no upstream repo activity since November # 2019. Unmaintained in Gentoo. Depends on effectively EOLed Lua 5.2, # fails to build against any other version. Removal in 30 days # (Bug #801883) app-crypt/cardpeek -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping dev-lang/lua:5.2
On 2021-07-09 17:34, William Hubbs wrote: Actually upstream does say when they will stop supporting each version [1]. Um, where? Because I've looked at this page before, I've looked at it again just now and I all can see there is that there will be no further releases of Lua versions up to and including 5.2, and that there will *probably* be no more 5.3 releases. No official End of Life statements, no EOL timeline, and 5.3 is apparently both dead and alive at the same time - which is fine for cats but not so for software. I guess it is a matter of interpretation then, "there will be no further releases" means end of life, to me anyway. Okay, in that case everyone who interprets this as Lua 5.1 having officially been EOLed can substitute the relevant part of the first sentence of my RFC with "the Lua ecosystem is a bloody nightmare because new versions regularly introduce API incompatibilities and a lot of application developers have never bothered to update their Lua code for anything newer than 5.1 in spite of in part because dev-lang/luajit having never reached compatibility with even the 5.2 API". Not that it changes any of my conclusions, IMHO. Two, more importantly, making LuaJIT the only available implementation of the 5.1 API would severely cripple Lua support on alpha, hppa, ia64, riscv, s390 and sparc (which have all got keywords on dev-lang/lua:5.1 but are not supported by LuaJIT at all) as well as force arm64 and ppc64le users to use a 2.1-beta version. This I am afraid might be the deal breaker, as I honestly cannot imagine Gentoo suddenly implementing support for all those arches. Some of the arches you listed are not stable, so I don't think we have to worry about those arches (see arches.desc). If the arch isn't stable, we can't guarantee anything. I am pretty sure that the ~arch status does NOT give us the right to de-keyword packages en masse. There is activity in luajit upstream, so hopefully they will do a new release that supports the newer lua versions. I do agree that it is problematic that they only support lua 5.1. I really do hope Mike Pall (i.e. LuaJIT upstream) will eventually release stable 2.1 - but between how long it has been since the latest beta and that he responds with something between impatience and hostility to any requests for a new release, LuaJIT has to me been looking more and more like one of those artisanal projects (not necessarily software ones) whose creators chip at them in perpetuity without ever reaching the state worthy of being considered finished. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On 2021-07-11 21:54, Michał Górny wrote: My gut feeling is that having this distinction is useful. However, it has been pointed out that we've probably never really had to use it (i.e. use the "banned" argument to stop someone from using old EAPI) and that the switch from "deprecated" to "banned" state did not really affect porting away from old EAPI. For the benefit of those not interested in sifting through the logs of Council meetings, here is a quick reiteration of my take on this: 1. Maybe it's my professional bend speaking but it feels to me like we really should establish a clear, GLEP-documented EAPI life cycle with well-defined meaning of individual stages. I will work on preparing a suitable proposal; 2. Until the above has introduced a (hopefully) better system, I am all for removing step 2 because it makes the procedure less bureaucratic. On 2021-07-12 02:11, Aaron Bauman wrote: > Just officially ban it, send out a message, and use the best judgement > when enforcing it (should it even need to be enforced). And the point of establishing a policy doomed from start to be enforced weakly or not at all is? Other than making the Council look like we care more about theatrics than actual governance, that is. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
On 2021-07-10 22:55, William Hubbs wrote: Change the _R0 suffix on these variable names to _ECLASS. Since my question in response to the previous round of this has yet to be answered, I repeat: are there any non-cosmetic reasons for doing this? -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Dropping dev-lang/lua:5.2
On 2021-07-09 15:35, William Hubbs wrote: As many (if not most) of you know, the Lua ecosystem is somewhat awkward owing to the facts that on the one hand dev-lang/lua upstream has never officially declared end of life on older versions, Actually upstream does say when they will stop supporting each version [1]. Um, where? Because I've looked at this page before, I've looked at it again just now and I all can see there is that there will be no further releases of Lua versions up to and including 5.2, and that there will *probably* be no more 5.3 releases. No official End of Life statements, no EOL timeline, and 5.3 is apparently both dead and alive at the same time - which is fine for cats but not so for software. 5.1 can go because luajit would cover it Alas, not quite. One, we've got quite a few packages in the tree which currently declare compatibility with lua5-1 but not luajitt. This could probably be addressed quite easily, the worst I have seen so far after substituting luajit for lua5-1 is some memory leaks, but it will take some time and effort to test all such packages. Two, more importantly, making LuaJIT the only available implementation of the 5.1 API would severely cripple Lua support on alpha, hppa, ia64, riscv, s390 and sparc (which have all got keywords on dev-lang/lua:5.1 but are not supported by LuaJIT at all) as well as force arm64 and ppc64le users to use a 2.1-beta version. This I am afraid might be the deal breaker, as I honestly cannot imagine Gentoo suddenly implementing support for all those arches. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [RFC] Dropping dev-lang/lua:5.2
Dear everyone, As many (if not most) of you know, the Lua ecosystem is somewhat awkward owing to the facts that on the one hand dev-lang/lua upstream has never officially declared end of life on older versions, and on the other dev-lang/luajit has never moved beyond 5.1 with their API support. Still, this doesn't mean WE have to support all branches in perpetuity... Between 5.1 being effectively here to stay due to LuaJIT and 5.4 still being relatively new (meaning it cannot feasibly replace 5.3 at this point), I would like to start by getting rid of 5.2 first. Having just had a look on p.g.o. at the list of packages utilising the relevant USE_EXPAND flags (as well as at net-proxy/haproxy, which *still* hasn't been ported to Lua eclasses), it looks like it would in fact be quite easy to do - among both single- and multi-impl Lua revdeps, there are none which only support 5.2. PS. Another benefit here would be that we wouldn't have to deal with internal interpreter weirdness demonstrated by https://bugs.gentoo.org/768048 which upstream have long since fixed in 5.3+ but my experiments suggest would be non-trivial to address in 5.2 without risking serious breakage. WDYT? -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
On 2021-07-06 22:59, William Hubbs wrote: Change the _R0 suffix on these variable names to _ECLASS. Any non-cosmetic reasons for doing this? -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up to co-maintenance
On 2021-07-02 10:12, Sergei Trofimovich wrote: app-misc/mc dev-util/ltrace media-fonts/terminus-font media-libs/aalib Will attach myself to these four. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs (m-n batch)
On 2021-07-02 08:41, Sergei Trofimovich wrote: # fuzzer tools of sorts, very fun ones: app-forensics/honggfuzz sys-libs/blocksruntime app-forensics/radamsa app-forensics/zzuf I'll take the lot. # maybe retire? it somewhat worked a while ago x11-plugins/purple-mattermost Seconding retirement, maybe I kept doing something wrong but I had no luck getting this to work with recent versions of Mattermost within the last ~1.5 years. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] 'pax_kernel' USE flag
On 2021-06-22 10:35, 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. Done. Now the old name only persists in dev-libs/libffi owing to the compatibility guard proposed by slyfox, and I'd say it should be removed even from there in a month. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] News item: USE=pax_kernel renaming
I have attached this news item to hardened profiles, even though there is nothing in those profiles which enforces this USE flag any more. An alternative would be to attach it to all the packages with this flag in IUSE but it feels like it might generate too much noise. Regarding the USE-flag change itself, my plan is to temporarily add the REQUIRED_USE compatibility guard to libffi (as suggested by slyfox) and simply rename the flag everywhere else. * * * Title: USE flag 'pax_kernel' to be renamed to 'pax-kernel' Author: Marek Szuba Posted: 2021-06-28 Revision: 1 News-Item-Format: 2.0 Display-If-Profile: default/linux/amd64/17.0/hardened Display-If-Profile: default/linux/amd64/17.0/musl/hardened Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened Display-If-Profile: default/linux/amd64/17.0/uclibc/hardened Display-If-Profile: default/linux/amd64/17.1/hardened Display-If-Profile: default/linux/amd64/17.1/no-multilib/hardened Display-If-Profile: default/linux/arm/17.0/musl/armv6j/hardened Display-If-Profile: default/linux/arm/17.0/musl/armv7a/hardened Display-If-Profile: default/linux/arm/17.0/uclibc/armv6j/hardened Display-If-Profile: default/linux/arm/17.0/uclibc/armv7a/hardened Display-If-Profile: default/linux/arm64/17.0/musl/hardened Display-If-Profile: default/linux/powerpc/ppc32/17.0/musl/hardened Display-If-Profile: default/linux/powerpc/ppc32/17.0/uclibc/hardened Display-If-Profile: default/linux/ppc/17.0/musl/hardened Display-If-Profile: default/linux/ppc/17.0/uclibc/hardened Display-If-Profile: default/linux/ppc64/17.0/musl/hardened Display-If-Profile: default/linux/ppc64le/17.0/musl/hardened Display-If-Profile: default/linux/x86/17.0/hardened Display-If-Profile: default/linux/x86/17.0/uclibc/hardened On 2021-07-01 the USE flag 'pax_kernel' will be renamed to 'pax-kernel' in order to remove the disallowed underscore character. If you use a PaX-enabled kernel, update your package-manager configuration accordingly; failure to do so might result in affected packages no longer functioning on your system. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
