Re: [gentoo-dev] [PATCH 1/5] gnome2-utils.eclass: phase out emktemp

2021-12-26 Thread Marek Szuba



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

2021-12-25 Thread Marek Szuba



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

2021-12-25 Thread Marek Szuba



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

2021-12-13 Thread Marek Szuba

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

2021-12-09 Thread Marek Szuba
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

2021-12-09 Thread Marek Szuba
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

2021-12-09 Thread Marek Szuba
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

2021-12-09 Thread Marek Szuba
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

2021-12-09 Thread Marek Szuba
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

2021-12-09 Thread Marek Szuba
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

2021-11-27 Thread Marek Szuba

# 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

2021-11-27 Thread Marek Szuba

# 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

2021-11-27 Thread Marek Szuba

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

2021-11-27 Thread Marek Szuba

# 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

2021-11-27 Thread Marek Szuba

# 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

2021-11-27 Thread Marek Szuba

# 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

2021-11-26 Thread Marek Szuba

# 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

2021-11-25 Thread Marek Szuba

# 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

2021-11-25 Thread Marek Szuba

# 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

2021-11-25 Thread Marek Szuba

# 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

2021-11-25 Thread Marek Szuba

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

2021-11-24 Thread Marek Szuba

# 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

2021-11-23 Thread Marek Szuba

# 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

2021-11-23 Thread Marek Szuba

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

2021-11-22 Thread Marek Szuba

# 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

2021-11-22 Thread Marek Szuba

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

2021-11-04 Thread Marek Szuba
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

2021-10-14 Thread Marek Szuba

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@

2021-10-05 Thread Marek Szuba

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

2021-09-27 Thread Marek Szuba

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

2021-09-02 Thread Marek Szuba

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

2021-08-16 Thread Marek Szuba

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

2021-08-16 Thread Marek Szuba

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

2021-08-16 Thread Marek Szuba

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

2021-08-16 Thread Marek Szuba

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

2021-08-16 Thread Marek Szuba
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

2021-08-16 Thread Marek Szuba
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

2021-08-16 Thread Marek Szuba

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

2021-08-16 Thread Marek Szuba

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

2021-08-16 Thread Marek Szuba

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

2021-08-11 Thread Marek Szuba

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

2021-07-26 Thread Marek Szuba

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()

2021-07-23 Thread Marek Szuba
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

2021-07-23 Thread Marek Szuba
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

2021-07-23 Thread Marek Szuba
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

2021-07-16 Thread Marek Szuba

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+

2021-07-16 Thread Marek Szuba
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]

2021-07-16 Thread Marek Szuba
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

2021-07-15 Thread Marek Szuba

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

2021-07-14 Thread Marek Szuba
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

2021-07-14 Thread Marek Szuba
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

2021-07-14 Thread Marek Szuba

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"

2021-07-14 Thread Marek Szuba

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

2021-07-14 Thread Marek Szuba

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

2021-07-14 Thread Marek Szuba
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

2021-07-14 Thread Marek Szuba
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"

2021-07-13 Thread Marek Szuba
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"

2021-07-13 Thread Marek Szuba
New version incorporating suggestions from mgorny and ulm, thank you for
your feedback.

-- 
Marecki





Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"

2021-07-13 Thread Marek Szuba

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"

2021-07-12 Thread Marek Szuba

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"

2021-07-12 Thread Marek Szuba
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

2021-07-12 Thread Marek Szuba

# 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

2021-07-12 Thread Marek Szuba

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

2021-07-12 Thread Marek Szuba

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

2021-07-12 Thread Marek Szuba

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

2021-07-09 Thread Marek Szuba

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

2021-07-09 Thread Marek Szuba

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

2021-07-07 Thread Marek Szuba

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

2021-07-02 Thread Marek Szuba

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)

2021-07-02 Thread Marek Szuba

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

2021-07-01 Thread Marek Szuba

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

2021-06-25 Thread Marek Szuba
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


[gentoo-dev] Last rites: dev-lang/lua:0 (i.e. unslotted Lua)

2021-06-25 Thread Marek Szuba

# Marek Szuba  (2021-06-25)
# Unslotted version conflicting with lua eclasses.
# No revdeps left. EAPI 5. Removal in 30 days (Bug #798693)
dev-lang/lua:0

--
MS



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] 'pax_kernel' USE flag

2021-06-23 Thread Marek Szuba

On 2021-06-22 19:01, Sergei Trofimovich wrote:


One of the steps forward for libffi would be to add extra USE=pax-kernel
with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent.


Sounds like a good idea to me, that way people who don't pay attention 
to news items will notice.


--
Marecki



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] 'pax_kernel' USE flag

2021-06-22 Thread Marek Szuba

Dear everyone,

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 the main reason this hasn't been done 
yet is that we expected it might disappear altogether.


--
Marecki



Re: [gentoo-dev] Up for grabs: various base-system@ packages

2021-06-17 Thread Marek Szuba

On 2021-06-16 19:18, Sam James wrote:


- app-editors/hexcurse


I'll take this one.

--
Marecki



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Should we switch IRC client defaults off Freenode?

2021-06-16 Thread Marek Szuba

On 2021-06-16 11:22, Michał Górny wrote:


IMO it makes most sense to just switch the default to irc.gentoo.org if
we are going to change defaults anyway.


We can't really do that as ircs://irc.gentoo.org causes certificate
hostname mismatch.


On a somewhat tangential note, could we add a TLSA RR for this service? 
I mean, it is rather likely that most IRC clients out there do not 
support DANE yet - but at least it would help those who do.


--
Marecki



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 3/3] lua-single.eclass: support EAPI 8

2021-06-16 Thread Marek Szuba
Signed-off-by: Marek Szuba 
---
 eclass/lua-single.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index 11c2790dac2..7abe1eb6674 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.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: lua-single.eclass
@@ -8,7 +8,7 @@
 # @AUTHOR:
 # Marek Szuba 
 # Based on python-single-r1.eclass by Michał Górny  et al.
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: An eclass for Lua packages not installed for multiple 
implementations.
 # @DESCRIPTION:
 # An extension of lua.eclass suite for packages which don't support being
@@ -34,7 +34,7 @@
 #
 # @EXAMPLE:
 # @CODE
-# EAPI=7
+# EAPI=8
 #
 # LUA_COMPAT=( lua5-{1..3} )
 #
@@ -66,7 +66,7 @@ case ${EAPI:-0} in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
;;
-   7)
+   7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-- 
2.31.1




[gentoo-dev] [PATCH 2/3] lua.eclass: support EAPI 8

2021-06-16 Thread Marek Szuba
Signed-off-by: Marek Szuba 
---
 eclass/lua.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index 46d9e848c87..e3a25c5d184 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.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: lua.eclass
@@ -8,7 +8,7 @@
 # @AUTHOR:
 # Marek Szuba 
 # Based on python-r1.eclass by Michał Górny  et al.
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: A common eclass for Lua packages
 # @DESCRIPTION:
 # A common eclass providing helper functions to build and install
@@ -27,7 +27,7 @@
 #
 # @EXAMPLE:
 # @CODE
-# EAPI=7
+# EAPI=8
 #
 # LUA_COMPAT=( lua5-{1..3} )
 #
@@ -54,7 +54,7 @@ case ${EAPI:-0} in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
;;
-   7)
+   7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-- 
2.31.1




[gentoo-dev] [PATCH 1/3] lua-utils.eclass: support EAPI 8

2021-06-16 Thread Marek Szuba
Signed-off-by: Marek Szuba 
---
 eclass/lua-utils.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index ddf44f354e1..59959eaf9c0 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -8,7 +8,7 @@
 # @AUTHOR:
 # Marek Szuba 
 # Based on python-utils-r1.eclass by Michał Górny  et al.
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: Utility functions for packages with Lua parts
 # @DESCRIPTION:
 # A utility eclass providing functions to query Lua implementations,
@@ -21,7 +21,7 @@ case ${EAPI:-0} in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
;;
-   7)
+   7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-- 
2.31.1




[gentoo-dev] Lua eclasses: support EAPI 8

2021-06-16 Thread Marek Szuba
Nothing special here. RESTRICT manipulation in lua-utils still uses +=
on purpose, for consistency with how other variables are handled there
as well as in order to avoid wasting CPU cycles on an EAPI version
check for something that ultimately achieves the same.





[gentoo-dev] [PATCH] sword-module.eclass: support EAPI 8

2021-06-16 Thread Marek Szuba
Signed-off-by: Marek Szuba 
---
 eclass/sword-module.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/sword-module.eclass b/eclass/sword-module.eclass
index 2ae58d1e51b..f8ae83c9f05 100644
--- a/eclass/sword-module.eclass
+++ b/eclass/sword-module.eclass
@@ -1,16 +1,16 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: sword-module.eclass
 # @MAINTAINER:
 # Marek Szuba 
-# @SUPPORTED_EAPIS: 7
+# @SUPPORTED_EAPIS: 7 8
 # @BLURB: Simplify installation of SWORD modules
 # @DESCRIPTION:
 # This eclass provides dependencies, ebuild environment and the src_install
 # function common to all app-text/sword modules published by the SWORD Project.
 #
-# Note that as of 2020-07-26 module archives published by SWORD are still
+# Note that as of 2021-06-16 module archives published by SWORD are still
 # not versioned and it is necessary to look at respective module pages in
 # order to see what versions the currently available files are. Once
 # a module file has been replicated to the Gentoo mirror network it will be
@@ -23,7 +23,7 @@
 # sword-Personal-1.0.ebuild, a typical ebuild using sword-module.eclass:
 #
 # @CODE
-# EAPI=7
+# EAPI=8
 #
 # SWORD_MINIMUM_VERSION="1.5.1a"
 #
@@ -40,7 +40,7 @@ case ${EAPI:-0} in
0|1|2|3|4|5|6)
die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
;;
-   7)
+   7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
-- 
2.31.1




Re: [gentoo-dev] Packages up for grabs

2021-06-13 Thread Marek Szuba

On 2021-06-13 10:01, David Seifert wrote:


   dev-vcs/git-flow


I'll take this one.

--
Marecki



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] News item: >=net-p2p/syncthing-1.17.0 incompatibility with

2021-05-14 Thread Marek Szuba

On 2021-05-14 19:25, Ulrich Mueller wrote:


Too long, GLEP 42 allows 50 chars max after "Title: ".


OK, will change this to

Title: >=net-p2p/syncthing-1.17.0 incompatibility warning

--
MS



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Changing the order of ICD loaders in virtual/opencl

2021-05-14 Thread Marek Szuba

Dear all,

Seeing as it has been around year since we added 
dev-libs/opencl-icd-loader to the tree, I wonder whether it would 
perhaps make sense to make it, rather than dev-libs/ocl-icd, the 
preferred OpenCL ICD loader for new installations.


Advantages (that I can see) of opencl-icd-loader:
 - official OpenCL ICD loader of the Khronos Group
 - as a consequence of the above, is kept in good sync with official 
Khronos Group OpenCL headers (dev-util/opencl-headers)
 - pure C with a fairly minimal set of dependencies, in particular does 
not does not bdepend on Ruby


Advantages (that I can see) of ocl-icd:
 - has been around for longer

WDYT?

PS. Thank you ionen for reminding me of this.

--
Marecki



[gentoo-dev] News item: >=net-p2p/syncthing-1.17.0 incompatibility with

2021-05-14 Thread Marek Szuba
Nb. 1.17.0 has not come out yet but given 1.17.0-rc.3 came out 3 days 
ago and Syncthing upstream normally only has 3 release candidates before 
an actual release, we can expect it to come out quite soon.


 * * *

Title: >=net-p2p/syncthing-1.17.0 to only allow TLS 1.3 for sync connections
Author: Marek Szuba 
Posted: 2021-05-18
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-p2p/syncthing

Starting with version 1.17.0, net-p2p/syncthing by default only allows
TLS 1.3 for sync connections - making it impossible to sync with devices
not supporting, i.e. running Syncthing versions older than 1.3.0.

If you do require your Syncthing cluster to support TLS 1.2, you will 
have to explicitly allow it by enabling the option 
"insecureAllowOldTLSVersions". For details see:


https://docs.syncthing.net/advanced/option-insecure-allow-old-tls-versions.html


--
Marecki



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: games-action/minetest and dependencies

2021-05-12 Thread Marek Szuba

On 2021-05-12 09:53, William Breathitt Gray wrote:


The following packages are up for grabs:

games-action/minetest
acct-group/minetest
acct-user/minetest
dev-cpp/benchmark
dev-cpp/prometheus-cpp


I'll take them.

--
MS



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] News item: dropping x86 support from media-gfx/darktable

2021-05-11 Thread Marek Szuba

Title: x86 support to be dropped from media-gfx/darktable
Author: Marek Szuba 
Posted: 2021-05-15
Revision: 1
News-Item-Format: 2.0
Display-If-Keyword: x86
Display-If-Installed: =media-gfx/darktable-2.6.2

Since version 3.0.0 media-gfx/darktable officially only supports 64-bit
architectures, and we have observed errors while attempting to build
these versions on x86 - making media-gfx/darktable-2.6.2 the last
version to support this architecture. However the 2.6.x branch of
Darktable has not seen any activity since October 2019 and we have just
confirmed with upstream that all but the latest release branch (3.4.x at
the time of writing this) are not supported.

In light of the above we have decided to remove
media-gfx/darktable-2.6.2 from the tree, thus effectively dropping x86 
support from that package, by 2021-06-15.



--
Marecki



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-04-22 Thread Marek Szuba

On 2021-03-27 23:40, Joshua Kinard wrote:


The MIPS machine has functioning local disk drives, and currently, it
boots fine by just pulling a kernel off my TFTP server and booting
from the local drive, no initramfs needed because I compiled
everything into it.


Out of curiosity, if your kernel images already come from the TFTP 
servers why not simply put separate initramfs files there too?



I wonder if there's a small C program out there that can call
whatever the kernel functions are to mount a disk partition that
could be embedded into a tiny initramfs, then pivot_root to
$REAL_ROOT and run /bin/init?


You might be interested in this FOSDEM 2020 talk:

https://archive.fosdem.org/2020/schedule/event/ema_boot_linux_only/

Not exactly what you have asked for but the problem they are trying to 
solve is the same as yours - boot Linux on a system whose first-stage 
bootloader impose considerable size constraints. And since it uses kexec 
at its core, it's essentially what Rich has suggested - except it's 
already been (at least partially) done :-)


--
MS



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-04-22 Thread Marek Szuba

On 2021-03-29 10:06, James Le Cuirot wrote:


Have you seen CONFIG_CMDLINE? It lets you bake command line args into
the kernel image itself.


And since 5.6, there is also bootconfig:

https://www.kernel.org/doc/html/latest/admin-guide/bootconfig.html

--
MS



OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] Last rites: mail-mta/protonmail-bridge-bin

2021-03-19 Thread Marek Szuba



# Depends on bundled out-of-date Qt5 libraries, and even with those
# installed recent upstream versions fail to run. Moreover, we have now
# got a source variant in the tree which, while still CLI-only for now,
# is up to date and actually works.
# Removal in 30 days. Bug #768228.
mail-mta/protonmail-bridge-bin


--
Marecki



Re: [gentoo-dev] Packages up for grabs: app-emulation/fuse app-emulation/fuse-utils app-emulation/libspectrum

2021-03-15 Thread Marek Szuba

On 05/03/2021 19:37, Sam James wrote:


Following the retirement of a proxy maintainer, as their request, we have the 
following packages up for grabs:
app-emulation/fuse
app-emulation/fuse-utils
app-emulation/libspectrum


I'll take them.

--
Marecki



Re: [gentoo-dev] Stabilisation of the slotted-Lua ecosystem

2021-02-23 Thread Marek Szuba

On 22/01/2021 14:38, Marek Szuba wrote:

The time has come for the final big push towards widespread deployment 
on slotted Lua - this monstrosity: https://bugs.gentoo.org/766528 . Many 
thanks in advance to all the arch testers who will deal with this. Nb. I 
am happy with this bug being split into several if that makes the tests 
easier to manage for those who will run them, just keep in mind that the 
stabilisation commits for an arch should be pushed to the repo over as 
short a time span as possible - the more spread this is the more annoyed 
our users might get by the dependency conflicts between slotted and 
unslotted and dev-lang/lua.


Somewhat belatedly, I am happy to say that the aforementioned 
monstrosity has been taken care of much faster than I thought it would 
be and since the 15th of February ALL the (unmasked) packages in the 
tree which previously depended directly on dev-lang/lua have had at 
least one stable ebuild migrated to Lua eclasses. Package maintainers, 
if you haven't done so yet (quite a few people already have) go ahead 
and remove old versions so that we can finally bid farewell to 
dev-lang/lua:0.


And to think that this all has happened simply because I wanted to 
finally enable Lua support in media-gfx/darktable :-)


Thank you SO much, everyone who has taken part in the effort of making 
Lua in Gentoo great again (sorry, couldn't help myself)! We had this on 
the agenda for way too long, and in my personal opinion the fact that we 
are now one of the few Linux (Unix?) distributions which allows the 
users to freely mix and match Lua versions is an important statement.


--
Marecki



[gentoo-dev] Stabilisation of the slotted-Lua ecosystem

2021-01-22 Thread Marek Szuba

Ladies and germs,

The time has come for the final big push towards widespread deployment 
on slotted Lua - this monstrosity: https://bugs.gentoo.org/766528 . Many 
thanks in advance to all the arch testers who will deal with this. Nb. I 
am happy with this bug being split into several if that makes the tests 
easier to manage for those who will run them, just keep in mind that the 
stabilisation commits for an arch should be pushed to the repo over as 
short a time span as possible - the more spread this is the more annoyed 
our users might get by the dependency conflicts between slotted and 
unslotted and dev-lang/lua.


--
Marecki



Re: [gentoo-dev] Packages up for grabs

2021-01-17 Thread Marek Szuba

On 17/01/2021 09:26, Michał Górny wrote:


[bv] x11-plugins/vicious
[B ] x11-wm/awesome


I'll take these two.

--
MS



Re: [gentoo-dev] [News review] LibreSSL support discontinued

2021-01-04 Thread Marek Szuba



On January 4, 2021 8:25:21 AM UTC, Stefan Strogin  wrote:

>Doesn't work for me.

Have you got libressl in your world file, perchance?

-- 
Marecki



Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Marek Szuba



On December 23, 2020 2:56:05 AM UTC, Michael Orlitzky  wrote:

>One last design issue that I ran into during the migration.
>
>The slotted lua ebuilds install the headers into subdirectories like 
>/usr/include/lua5.2, but otherwise with their upstream names. The 
>libraries, on the other hand, all get installed directly to $libdir.. 
>but with NON-standard names like liblua5.2.a (as opposed to simply 
>liblua.a).
>
>This makes it impossible to build against a specific version of Lua 
>without using pkg-config. The usual way would be to add 
>/usr/include/lua5.2 to the compiler's include path, and $libdir/lua5.2 
>to its library path (via -I and -L)... but there's no way to tell the 
>build system to look for a library of an entirely different name.
>Things 
>like AC_SEARCH_LIBS are going to try -llua, and that's it.

I think what you are looking for is lua_get_shared_lib() from lua-utils.eclass. 
We have already got ebuilds in the tree which use it.

-- 
MS



[gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-22 Thread Marek Szuba
Dear all,

As of right now, the blocking slotted-lua tracker depends on 5 (FIVE) open 
bugs. The still-to-be migrated packages are:

app-metrics/collectd - ebuild under review of the maintainer
games-strategy/megaglest - no response from maintainers (games@g.o)
mail-filter/opendkim - committed ebuild needs one extra fix
sci-geosciences/osm2pgsql - no response from maintainers (sci-geo@g.o)
www-apps/cgit - to be migrated by bman

Therefore, the unmasking of slotted Lua + all the ebuilds migrated to Lua 
eclasses will take place on Christmas Eve, i.e. this Thursday, around noon UTC.

-- 
Marecki

[gentoo-dev] [PATCH] waf-utils.eclass: support EAPI-7

2020-12-21 Thread Marek Szuba
Trivial bump. Tested with a modified media-video/mpv ebuild (which package 
requires this change before it can be migrated to Lua eclasses), seems to work 
fine.

--- a/eclass/waf-utils.eclass
+++ b/eclass/waf-utils.eclass
@@ -8,7 +8,7 @@
 # Original Author: Gilles Dartiguelongue 
 # Various improvements based on cmake-utils.eclass: Tomáš Chvátal 

 # Proper prefix support: Jonathan Callen 
-# @SUPPORTED_EAPIS: 4 5 6
+# @SUPPORTED_EAPIS: 4 5 6 7
 # @BLURB: common ebuild functions for waf-based packages
 # @DESCRIPTION:
 # The waf-utils eclass contains functions that make creating ebuild for
@@ -19,7 +19,7 @@
 inherit multilib toolchain-funcs multiprocessing
 
 case ${EAPI:-0} in
-   4|5|6) EXPORT_FUNCTIONS src_configure src_compile src_install ;;
+   4|5|6|7) EXPORT_FUNCTIONS src_configure src_compile src_install ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac
 

-- 
Marecki

Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update

2020-12-09 Thread Marek Szuba

On 2020-12-09 16:21, Michael Orlitzky wrote:


LUA_DEPS itself will not but the change of LUA_SINGLE_TARGET in the
package in question will, same way other packages can be rebuilt on
USE-flag changes.
So lua has inherited the python approach of requiring everyone to use 
portage? =/


I don't know about requiring everyone to use Portage but Lua eclasses 
*are* indeed strongly based on Python ones - as openly admitted both in 
eclassdoc of the three Lua eclasses and during their public review on 
this mailing list.


--
MS



OpenPGP_signature
Description: OpenPGP digital signature


  1   2   3   >