[gentoo-dev] Last rites: app-portage/g-sorcery, app-portage/gs-elpa

2024-03-06 Thread Ulrich Mueller
# Ulrich Müller  (2024-03-06)
# Inactive upstream maintainer. Needs porting to PEP 517 (or better,
# from Python to Emacs Lisp) and from layman to repository.eselect.
# Removal on 2024-05-05. Bug #909887, #909890.
app-portage/g-sorcery
app-portage/gs-elpa


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/3] texlive-common.eclass: check exit status of texmf-update

2024-03-01 Thread Ulrich Mueller
>>>>> On Fri, 01 Mar 2024, Florian Schmaus wrote:

> On 29/02/2024 21.40, Ulrich Mueller wrote:
>>>>>>> On Thu, 29 Feb 2024, Florian Schmaus wrote:
>> 
>>> @@ -178,6 +178,10 @@ etexmf-update() {
>>> if has_version 'app-text/texlive-core' ; then
>>> if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/sbin/texmf-update ]] ; then
>>> "${EPREFIX}"/usr/sbin/texmf-update
>>> +   local res="${?}"
>>> +   if [[ "${?}" -ne 0 ]] && ver_test -ge 2023; then
>> This condition will always be false.

> Is it because assigning 'res' will set '$?'?

Yes, the local command will return success status. So you should check
for ${res} not $?.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/3] texlive-common.eclass: check exit status of texmf-update

2024-02-29 Thread Ulrich Mueller
> On Thu, 29 Feb 2024, Florian Schmaus wrote:

> @@ -178,6 +178,10 @@ etexmf-update() {
>   if has_version 'app-text/texlive-core' ; then
>   if [[ -z ${ROOT} && -x "${EPREFIX}"/usr/sbin/texmf-update ]] ; 
> then
>   "${EPREFIX}"/usr/sbin/texmf-update
> + local res="${?}"
> + if [[ "${?}" -ne 0 ]] && ver_test -ge 2023; then

This condition will always be false.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 3/3] texlive-common.eclass: Use nonfatal-respecting die for fmtutil-sys

2024-02-29 Thread Ulrich Mueller
> On Thu, 29 Feb 2024, Michał Górny wrote:

>> +"${EPREFIX}"/usr/bin/fmtutil-sys --all &> /dev/null \
>> +|| die -n "fmtutil-sys returned non-zero exit 
>> status ${res}"

> Put '||' at end of the line, then you won't need the redundant
> backslash.

I don't think we have such a policy, so || at end of line or beginning
of next line is really up to personal preference.

Independent of this, looks like ${res} is not defined?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

2024-02-28 Thread Ulrich Mueller
> On Wed, 28 Feb 2024, Michał Górny wrote:

> On Tue, 2024-02-27 at 21:05 -0600, Oskari Pirhonen wrote:
>> What about cases where someone, say, doesn't have an excellent grasp of
>> English and decides to use, for example, ChatGPT to aid in writing
>> documentation/comments (not code) and puts a note somewhere explicitly
>> mentioning what was AI-generated so that someone else can take a closer
>> look?
>> 
>> I'd personally not be the biggest fan of this if it wasn't in something
>> like a PR or ml post where it could be reviewed before being made final.
>> But the most impportant part IMO would be being up-front about it.

> I'm afraid that wouldn't help much.  From my experiences, it would be
> less effort for us to help writing it from scratch, than trying to
> untangle whatever verbose shit ChatGPT generates.  Especially that
> a person with poor grasp of the language could have trouble telling
> whether the generated text is actually meaningful.

But where do we draw the line? Are translation tools like DeepL allowed?
I don't see much of a copyright issue for these.

Ulrich

[1] https://www.deepl.com/translator


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

2024-02-27 Thread Ulrich Mueller
> On Tue, 27 Feb 2024, Rich Freeman wrote:

> On Tue, Feb 27, 2024 at 9:45 AM Michał Górny  wrote:
>> 
>> Given the recent spread of the "AI" bubble, I think we really need to
>> look into formally addressing the related concerns.

First of all, I fully support mgorny's proposal.

>> 1. Copyright concerns.

> I do think it makes sense to consider some of this.

> However, I feel like the proposal is redundant with the existing
> requirement to signoff on the DCO, which says:

 By making a contribution to this project, I certify that:

 1. The contribution was created in whole or in part by me, and
 I have the right to submit it under the free software license
 indicated in the file; or

 2. The contribution is based upon previous work that, to the best of
 my knowledge, is covered under an appropriate free software license,
 and I have the right under that license to submit that work with
 modifications, whether created in whole or in part by me, under the
 same free software license (unless I am permitted to submit under a
 different license), as indicated in the file; or

 3. The contribution is a license text (or a file of similar nature),
 and verbatim distribution is allowed; or

 4. The contribution was provided directly to me by some other person
 who certified 1., 2., 3., or 4., and I have not modified it.

I have been thinking about this aspect too. Certainly there is some
overlap with our GLEP 76 policy, but I don't think that it is redundant.

I'd rather see it as a (much needed) clarification how to deal with AI
generated code. All the better if the proposal happens to agree with
policies that are already in place.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] 2024-02-26-debianutils-drops-installkernel-dep: add news item

2024-02-26 Thread Ulrich Mueller
> On Mon, 26 Feb 2024, Andrew Nowa Ammerlaan wrote:

> Title: installkernel is no longer implicitly installed
> Author: Andrew Ammerlaan 
> Posted: 2024-02-26
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-kernel/installkernel
> Display-If-Installed: >=sys-apps/debianutils-5.14-r1
> Display-If-Installed: app-misc/ca-certificates

I have only some small remarks about spelling and style:

> /sbin/installkernel is a script called by the kernels 'make install' as well

s/kernels/kernel's/ (also occurs more times below)

> as by the distribution kernels post install phase. If you are reading this
> then chances are you use and rely on installkernel and what follows is
> essential for you.

> Previously sys-kernel/installkernel was implicitly installed on many systems
> via a dependency in sys-apps/debianutils. This dependency was toggled
> by the "installkernel" USE flag, and enabled by default.

Use either double quotes (which I'd prefer) or single quotes throughout.

> sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates,
> an essential package installed on many systems. However, this
> dependency was recently removed. As a result many users may find that
> sys-apps/debianutils and therefore sys-kernel/installkernel are no longer
> part of the dependency graph and will therefore be cleaned up by
> 'emerge --depclean'.

> Removing sys-kernel/installkernel from your system WILL change the
> way kernels are installed by 'make install'! Instead of the versioned
> /boot/vmlinuz-x.y.z that you are used to, 'make install' will simply
> copy bzImage (or equivalent for you arch) into /boot. This image

s/you/your/

> may not be picked up by your bootloader or its configuration tools.

> To avoid surprises from such implicit dependencies from happening
> again in the future, the dependency on sys-kernel/installkernel in
> sys-apps/debianutils is removed. And as such sys-kernel/installkernel

Comma after "such"?

> is only installed on the system if it is either explicitly selected or
> pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)).


> User Action Required (all users)
> 

> Users who currently have sys-kernel/installkernel installed, must
> ensure that it is explicitly selected by explicitly emerging it:

Avoid the double "explicitly".

> emerge --noreplace sys-kernel/installkernel

Put a # sign in front to make clear that it's a command? Alternatively,
indent the line (applies also for the three commands below).

> Users who find that sys-kernel/installkernel has already been
> cleaned from their systems and are therefore effected by
> the change in kernel installation described above should
> re-install sys-kernel/installkernel and then re-install their
> kernel.

Above you wrap lines at 75 chars, but here it's down to 60.

Please make it consistent. GLEP 42 suggests "The text body should be
wrapped at 72 characters."

> emerge sys-kernel/installkernel
> cd /usr/src/linux (or other location of the kernel sources)

bash: syntax error near unexpected token `('

But seriously, some users will copy and paste these commands, so making
it a bash comment starting with # may be better.

> make install

> Note that this re-installation is not required for users of the
> distribution kernels (e.g. gentoo-kernel(-bin)).


> See also: https://wiki.gentoo.org/wiki/Installkernel


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs due to developer inactivity

2024-02-14 Thread Ulrich Mueller
> On Wed, 14 Feb 2024, Michał Górny wrote:

> The following packages are now looking for a new maintainer, due to
> their prior maintainer being inactive:

> sys-firmware/iwl3160-7260-bt-ucode
> sys-firmware/iwl3160-ucode
> sys-firmware/iwl7260-ucode

These should be treecleaned, because sys-kernel/linux-firmware installs
newer versions of these files. See [1] for the first package and [2] for
the two others.

[1] https://bugs.gentoo.org/632402
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f9e0b9f3d138f7423dcb3b6c279ad63ea43d17ca


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs

2024-02-11 Thread Ulrich Mueller
> On Sat, 10 Feb 2024, Daniel Simionato wrote:

>  I'd like to start a discussion regarding setting HOME_MODE by default in
> the /etc/login.defs file (owned by sys-apps/shadow package).

> Upstream keeps HOME_MODE commented:
> https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207

> HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set,
> they will use the specified permission when creating a user home directory,
> otherwise the default UMASK will be used.
> Since the default umask is 022, keeping HOME_MODE unset will result in home
> readable home directories created by useradd, which goes against security
> best practices.

> The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH
> based distros, OpenSuse, ArchLinux all set it to 0700, Ubuntu has it at
> 0750. Debian and Gentoo are two exceptions, keeping the upstream value of
> HOME_MODE (although login.defs is changed in other ways).

> I previously made a PR on github where you can find more details (
> https://github.com/gentoo/gentoo/pull/35231), but as pointed in the
> comments this probably warrants some discussion beforehand.

> I can understand the argument against the change, which is keeping in sync
> with upstream and don't risk changing the historic default behaviour of
> tools some users might rely upon.

> I do believe though there's merit in providing safer and secure defaults,
> so I would like HOME_MODE to have a safe default value for Gentoo and
> Gentoo based distros.

I see no strong argument either way. However, changing the default is
somewhat intrusive, so I'd prefer staying with upstream. Also, are we
aware of any breakage caused by this?

As you've pointed out yourself, distros are inconsistent about it,
i.e. not much guidance from there. Maybe upstream would be a better
place for this discussion?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 7/7] eclass/dotnet-pkg.eclass: prepare for safely using Nuget

2024-02-03 Thread Ulrich Mueller
> On Sat, 03 Feb 2024, Maciej Barć wrote:

> + find "$(pwd)" -maxdepth 1 -iname "nuget.config" -delete ||

Is there any special reason for using "$(pwd)" instead of . here?

> + case "${1}" in

Quotes not needed.

> + if [[ -d "${1}" ]] ; then

Quotes not needed.



Re: [gentoo-dev] [PATCH 5/7] eclass/dotnet-pkg.eclass: add dotnet-pkg_force-compat

2024-02-03 Thread Ulrich Mueller
> On Sat, 03 Feb 2024, Maciej Barć wrote:

> +dotnet-pkg_force-compat() {
> + if [[ -z "${DOTNET_PKG_COMPAT}" ]] ; then

Quotes are not needed.



Re: [gentoo-dev] [PATCH 2/7] eclass/dotnet-pkg-base.eclass: deprecate wring-style names

2024-02-03 Thread Ulrich Mueller
> On Sat, 03 Feb 2024, Maciej Barć wrote:

> +# @FUNCTION: dotnet-pkg-base_restore_tools
> +# @USAGE: [config-file] [args] ...
> +# @DESCRIPTION:
> +# DEPRECATED, use "dotnet-pkg-base_restore_tools" instead.

Should be a hyphen here (...restore-tools), I guess?



Re: [gentoo-dev] [PATCH 1/7] eclass/dotnet-pkg-base.eclass: quotes and style tweaks for edge cases

2024-02-03 Thread Ulrich Mueller
> On Sat, 03 Feb 2024, Maciej Barć wrote:

> -if [[ ${CATEGORY}/${PN} != dev-dotnet/dotnet-runtime-nugets ]] ; then
> +if [[ "${CATEGORY}/${PN}" != dev-dotnet/dotnet-runtime-nugets ]] ; then

These quotes are not necessary.

> - if [[ ${CATEGORY}/${PN} != dev-dotnet/csharp-gentoodotnetinfo ]] ; then
> - DOTNET_PKG_BDEPS+=" dev-dotnet/csharp-gentoodotnetinfo "
> + if [[ "${CATEGORY}/${PN}" != dev-dotnet/csharp-gentoodotnetinfo ]] ; 
> then

Same.

> + DOTNET_PKG_BDEPS+="
> + dev-dotnet/csharp-gentoodotnetinfo
> + "



Re: [gentoo-dev] sys-devel/autoconf wrong dependency?

2024-01-31 Thread Ulrich Mueller
> On Wed, 31 Jan 2024, Andreas Fink wrote:

> With the move of sys-devel/autoconf to dev-build/autoconf the ebuild
> has some inconsistency, namely in the RDEPEND section, it is saying:

> RDEPEND="
> ${BDEPEND}
>> =dev-build/autoconf-wrapper-20231224
> sys-devel/gnuconfig
> !~sys-devel/${P}:2.5
> "

> This should probably be `!~dev-build/${P}:2.5`. [...]

No, it should be ${CATEGORY}/${P} when referring to the package itself.
That's what these variables are for.

Ulrich



[gentoo-dev] Last rites: app-editors/emacs slot 25

2024-01-30 Thread Ulrich Mueller
# Ulrich Müller  (2024-01-30)
# SLOT 25 of app-editors/emacs, corresponding to GNU Emacs version 25.3.
# This version was released in May 2018. Please upgrade to >=emacs-26
# and update your Emacs Lisp packages with emacs-updater.
# Removal on 2024-02-29. Bug #923329.
app-editors/emacs:25


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] texlive-{common,module}.eclass: update for TeX Live 2023

2024-01-16 Thread Ulrich Mueller
> On Tue, 16 Jan 2024, Florian Schmaus wrote:

>  case ${EAPI} in
> - 7) inherit eapi8-dosym ;;
> + 7)
> + inherit eapi8-dosym
> + dosym(){ dosym8 "$@"; }

For good reason, eapi-dosym.eclass doesn't override package manager
commands, and the texlive eclasses shouldn't do that either.

Does it even work? dosym8 calls dosym, so wouldn't redefining dosym in
terms of dosym8 cause an endless loop?

So, either add an EAPI conditional where dosym8 is currently used (I see
only one place), or define dosym8 as an alias for dosym in EAPI 8.

> + ;;
> + 8) ;;
>   *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
>  esac


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

2024-01-10 Thread Ulrich Mueller
>>>>> On Wed, 10 Jan 2024, Florian Schmaus wrote:

> On 10/01/2024 14.58, Ulrich Mueller wrote:
>> Looks like readme.gentoo-r1 already gives you control over this:
>> # If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
>> # value in your ebuild before this function is called.
>> # This can be useful when, for example, DOC_CONTENTS is modified, then, you 
>> can
>> # rely on specific REPLACING_VERSIONS handling in your ebuild to print 
>> messages
>> # when people update from versions still providing old message.

> It is easy to forget setting FORCE_PRINT_ELOG, just as it is easy to
> forget to unset it again.

> An automatism is always preferable over a manual solution.

Maybe I want manual control? For example, when I fix a typo in the
README file then I don't want to show it to users again.

>>> Just to clarify: you are agreeing that excluding the readme doc from
>>> being compressed is fine?
>> Please respect the user's compression settings there. IMHO
>> overriding
>> them with docompress -x is a big no-no.

> Then why does "docompress -x" exist at all?

Short answer, because some upstream programs access these directories
and cannot cope with compressed files there.

Long answer, see the previous discussion on this list [1] and in
bug 250077 [2].

> There seems to be a big win-win if we override the compression
> settingin this case.

I tend to disagree. We shouldn't override users' choices unless
absolutely necessary.

Ulrich

[1] 
https://archives.gentoo.org/gentoo-dev/message/2fd5f58132881ef69219c126a525bce3
[2] https://bugs.gentoo.org/250077


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] [RFC] greadme.eclass

2024-01-10 Thread Ulrich Mueller
> On Wed, 10 Jan 2024, Florian Schmaus wrote:

> On 10/01/2024 12.04, Sam James wrote:
>> 1) The name seems odd (why not readme.gentoo-r2)?
>> 2) Why can't the existing eclass be improved?

> Both points, the name of the eclass and the question if this should be
> added to the existing eclass or as a new eclass, are absolutely *no*
> hill I want to die on.

> What I *really* care about is having the functionality that there is a
> readme eclass that *also* shows the elog message if the README's
> content changed (and not just on the first installation of the
> package).

Looks like readme.gentoo-r1 already gives you control over this:

# If you want to show them always, please set FORCE_PRINT_ELOG to a non empty
# value in your ebuild before this function is called.
# This can be useful when, for example, DOC_CONTENTS is modified, then, you can
# rely on specific REPLACING_VERSIONS handling in your ebuild to print messages
# when people update from versions still providing old message.

>> 4) The compression deal seems not worth bothering with.

> Just to clarify: you are agreeing that excluding the readme doc from
> being compressed is fine?

Please respect the user's compression settings there. IMHO overriding
them with docompress -x is a big no-no.

> [...]

> It exports phase functions, which readme.gentoo-r1 does not.

Looking at the history, readme.gentoo[-r0] used to export phase
functions:
https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/readme.gentoo.eclass?id=1e7b2242de29ec60105df1ef31939aed85a8b0eb#n32
It turned out to be a bad design choice, so -r1 no longer does that.

> The readme.gentoo-r1 eclass always shoves the full content of the
> readme into an environment variable.

Why is this a problem?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] New category: dev-doc (?)

2024-01-07 Thread Ulrich Mueller
>>>>> On Sun, 07 Jan 2024, Michał Górny wrote:

> On Sun, 2024-01-07 at 17:58 +0100, Ulrich Mueller wrote:
>> I cannot really see a delineation between app-text and [dev]-doc.
>>
>> For example, packages like psmark, xmlto, or even texi2html are general
>> format manipulation/conversion tools and IMHO app-text is the right
>> category for them. Also, why would you keep pandoc and manpager in
>> app-text but move xmlto and mandoc out of it?

> It's a bit blurry.  My original idea was to keep app-text/ for general-
> purpose text tools (like text editors), while make dev-doc/ focused on
> formats specific to documentation (like code documentation, manpages).

We already have app-editors for text editors. For the rest, it seems
very blurry indeed and would leave us with (IMHO too many) borderline
cases.

You certainly have a point that document processing tools are misplaced
in app-doc. Maybe just move them to app-text, which would be a more
minimal change?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] New category: dev-doc (?)

2024-01-07 Thread Ulrich Mueller
>>>>> On Sun, 07 Jan 2024, Ulrich Mueller wrote:

> I cannot really see a delineation between app-text and app-doc.

Sorry, this should read "between app-text and dev-doc", of course.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] New category: dev-doc (?)

2024-01-07 Thread Ulrich Mueller
> On Sun, 07 Jan 2024, Michał Górny wrote:

> Here's another idea, a new dev-doc category (though I suppose we could
> try to find a better name), dedicated to:

>   Tools to generate, convert, view and process documentation.

> This is notably meant to move software out of app-doc/ which is
> specifically dedicated to "documentation collections".  Candidates:

> app-doc/NaturalDocs
> app-doc/doxygen
> app-doc/halibut
> app-doc/psmark
> app-doc/xmltoman
> app-doc/zeal
> app-text/mandoc
> app-text/texi2html
> app-text/xchm
> app-text/xml2rfc
> app-text/xmlto

I cannot really see a delineation between app-text and app-doc.

For example, packages like psmark, xmlto, or even texi2html are general
format manipulation/conversion tools and IMHO app-text is the right
category for them. Also, why would you keep pandoc and manpager in
app-text but move xmlto and mandoc out of it?

> dev-util/gi-docgen
> dev-util/gtk-doc
> dev-util/source-highlight
> sys-apps/man-db
> sys-apps/texinfo


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item

2024-01-02 Thread Ulrich Mueller
>> +++ 
>> b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt

> The short-name is rather long. [...]

In fact, the filename is also invalid by GLEP 42.

Sorry for missing this the first time.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item

2024-01-02 Thread Ulrich Mueller
> On Tue, 02 Jan 2024, Eli Schwartz wrote:

> +++ 
> b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt

The short-name is rather long. GLEP 42 strongly recommends to stay below
20 characters:
https://www.gentoo.org/glep/glep-0042.html#news-item-identities

> +Title: Separate /usr now requires an initramfs
> +Author: Eli Schwartz 
> +Content-Type: text/plain
> +Posted: 2024-01-02
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Installed: sys-apps/baselayout[split-usr]

This is not a valid header. (Format 2.0 doesn't have Content-Type.)

> +In 2013, Gentoo policy determined that separate /usr without an initramfs was
> +officially no longer supported:
> +
> +- https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202
> +- 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2013/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt?id=a79dd69b0cca439bc0c483c9193c79e0554819d0

The 2013-09-27-initramfs-required news item already said:

| Linux systems which have / and /usr on separate file systems but do not
| use an initramfs will not be supported starting on 01-Nov-2013.
|
| If you have / and /usr on separate file systems and you are not
| currently using an initramfs, you must set one up before this date.
| Otherwise, at some point on or after this date, upgrading packages
| will make your system unbootable.

It is also in the Handbook since 2014:
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs

What has changed that we would need another news item?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] global USE=gpg

2023-12-30 Thread Ulrich Mueller
> On Sat, 30 Dec 2023, Andreas K Huettel wrote:

>> > we have many local gpg useflags which basically just enable gpg.
>> > Should we merge these to one global useflag?
>> > 
>> > Additionally we have a few gpgme useflags.
>> > See also https://bugs.gentoo.org/679634
>> > 
>> > What are your ideas?
>> > 
>> 
>> We have also have a bunch of USE=pgp and USE=openpgp, both of which are
>> more correct than USE=gpg.

> Yeah, typical case of "formally correct thing being way more difficult to
> understand than colloquially practical thing" ...

So, how about using gpg as the flag's name and mentioning OpenPGP in its
description?


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] linux-mod-r1.eclass: Require the compression to succeed

2023-12-30 Thread Ulrich Mueller
> On Sat, 30 Dec 2023, Michał Górny wrote:

> - edob "${compress[@]}" -- "${@}"
> + edob "${compress[@]}" -- "${@}" || die

Doesn't edob already die by itself?


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] profiles/info_vars: Add PYTHONPATH

2023-12-29 Thread Ulrich Mueller
> On Fri, 29 Dec 2023, Michał Górny wrote:

> --- a/profiles/info_vars
> +++ b/profiles/info_vars
> @@ -60,6 +60,7 @@ PORTAGE_RSYNC_EXTRA_OPTS
>  PORTAGE_TMPDIR
>  PORTDIR
>  PORTDIR_OVERLAY
> +PYTHONPATH
>  RANLIB
>  READELF
>  RUSTFLAGS

Please also update the copyright year in the header.

This will bring the count of variables up to 67. Maybe it's time to
go through the list and check whether all of them are still needed?
(Of course, that isn't a blocker for your commit.)


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: games-fps/serious-sam-tse

2023-12-26 Thread Ulrich Mueller
# Ulrich Müller  (2023-12-26)
# Program errors out with a segmentation fault.
# Use games-fps/serioussam along with games-fps/serioussam-tfe-data
# and games-fps/serioussam-tse-data as replacement.
# Removal on 2024-01-09, bug #854567.
games-fps/serious-sam-tse


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Ulrich Mueller
> On Mon, 11 Dec 2023, Eli Schwartz wrote:

>> "Command-line software which adds ANSI color to its output by default
>> should check for a NO_COLOR environment variable that, when present
>> and not an empty string (regardless of its value), prevents the
>> addition of ANSI color." -- https://no-color.org/

> Again, not according to pytest itself. ;)

> Given the commit message says:

> """
> Adjust it to correctly check whether it is set at all rather than to a
> specific value, to match the behavior of pytest itself.
> """

The standard is defined by sno-color.org. If pytest does something
different then it is a bug.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: epytest, use NO_COLOR rather than NOCOLOR

2023-12-11 Thread Ulrich Mueller
> On Mon, 11 Dec 2023, Eli Schwartz wrote:

>> +local color=yes
>> +[[ ${NO_COLOR} ]] && color=no

> [[ -v NO_COLOR ]]

No, this would give the wrong result if NO_COLOR is set to an empty
value. [[ ${NO_COLOR} ]] or [[ -n ${NO_COLOR} ]] is the correct test:

   "Command-line software which adds ANSI color to its output by default
   should check for a NO_COLOR environment variable that, when present
   and not an empty string (regardless of its value), prevents the
   addition of ANSI color." -- https://no-color.org/


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH] Stop implicitly manipulating `NO_COLOR`/`NOCOLOR`

2023-11-26 Thread Ulrich Mueller
> On Sun, 26 Nov 2023, Michał Górny wrote:

> 3. Forcing `NO_COLOR=1` turns out to cause random test failures,
>and while fixing them is commendable, it is a pain for arch testing
>and it is currently blocking stabilization requests.

I'd argue that test suites that fail because of NO_COLOR are broken.
IIUC, these failures will show up for users who set NO_COLOR=1 in their
make.conf or in the environment?

> With the new approach, the color output in programs is consistent
> between using ``--jobs`` or ``--quiet-build``, and not.  Therefore,
> both cases generate uniform logs.  In order to obtain logs free of color
> codes, one can either filter them via `ansifilter(1)` (as the manpages
> already recommend) or explicitly set `NO_COLOR`.

Will this still guarantee that NO_COLOR=1 from the environment is always
passed on to the build system?

Otherwise, it would break ebuild-mode in some configurations.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] profiles/use.desc: Add `lzip` for lzip compression

2023-10-22 Thread Ulrich Mueller
> On Sun, 22 Oct 2023, Michał Górny wrote:

>  lzma - Support for LZMA (de)compression algorithm
>  lz4 - Enable support for lz4 compression (as implemented in app-arch/lz4)
> +lzip - Enable support for lzip compression

Alphabetic order?


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [DRAFT v2] GLEP 84: Standard format for package.mask files

2023-10-13 Thread Ulrich Mueller
> On Fri, 13 Oct 2023, Arthur Zamarin wrote:

>> Make this one either "[Bb]ugs? #\d+(,? #\d+)*" (which I'd prefer)
>> or "[Bb]ugs? +#\d+(,? +#\d+)*". That is, same number of spaces in both
>> locations.

> OK, would be hard to define it correctly in the BNF, but will just use
> {n} syntax to pass the intent, and explain in English what you said here
> (same amount of spaces between "things", with preferred n=1.

I think you've misunderstood me. I meant that the regex should either
match exactly one space, but then in both places (after "[Bb]ugs?" and
after the comma). Or, it should allow an arbitrary number of spaces
in both places.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [DRAFT v2] GLEP 84: Standard format for package.mask files

2023-10-13 Thread Ulrich Mueller
> On Fri, 13 Oct 2023, Arthur Zamarin wrote:

>>> PKGS_GROUP   ::= {ATOM}(\n{ATOM})*
>> 
>> Sorry, I had missed this when reading it the first time. Please avoid
>> the term "atom" because neither PMS nor the Devmanual calls them so.

> Oh, sorry, normal jargon from pkgcore work. How to call correctly here
> any package specification without use dep?

PMS calls them "package dependency specification".


signature.asc
Description: PGP signature


Re: [gentoo-dev] [DRAFT v2] GLEP 84: Standard format for package.mask files

2023-10-13 Thread Ulrich Mueller
> On Fri, 13 Oct 2023, Arthur Zamarin wrote:

> PKGS_GROUP   ::= {ATOM}(\n{ATOM})*

Sorry, I had missed this when reading it the first time. Please avoid
the term "atom" because neither PMS nor the Devmanual calls them so.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [DRAFT v2] GLEP 84: Standard format for package.mask files

2023-10-13 Thread Ulrich Mueller
> On Fri, 13 Oct 2023, Arthur Zamarin wrote:

>>> The paragraph should be of format ``Removal on ${DATE}. ${BUGS-LIST}``, 
>>> where
>>> the date is RFC-3339 full-date format, meaning ``-MM-DD``, and the bugs
>>> list is of the `bugs list`_ format. The listed bugs should include the
>>> last-rite bug opened, and potentially more relevant bugs which weren't 
>>> listed
>>> in the explanation paragraphs.
>> 
>> Does this mean that only the first of the following entries would be
>> valid?
>> 
>> # Removal on 2023-11-13. Bugs #678901, #890123
>> # Removal on 2023-11-13, bugs #678901, #890123.
>> # Removal on 2023-11-13. Bugs #678901 #890123
>> 
>> IMHO that would be too restrictive. Punctuation shouldn't be significant
>> there. (This doesn't preclude _recommending_ one of the variants.)

> Your current interpretation was correct. My main goal is to define a
> "precise" format, so it easy to parse for render of mask (i.e. soko). I
> also think we have nothing to gain from allowing "," instead of "."
> after removal date, but not that I care. Same for bugs-list, I'm fine
> with making the "," optional, but I want us to define a "precise regex"
> so we have consistent format for important bits of mask message. Does
> this seem good enough for you?

> BUGS-LIST::= [Bb]ugs? #\d+(,? +#\d+)*

Make this one either "[Bb]ugs? #\d+(,? #\d+)*" (which I'd prefer)
or "[Bb]ugs? +#\d+(,? +#\d+)*". That is, same number of spaces in both
locations.

> LAST-RITE::= Removal on {DATE}[.,]? +{BUGS-LIST}.?

Looks good. Adding " *" at the end won't harm, in case someone will
leave spurious whitespace at the end of the line.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: [DRAFT v2] GLEP 84: Standard format for package.mask files

2023-10-13 Thread Ulrich Mueller
> On Fri, 13 Oct 2023, Arthur Zamarin wrote:

> Comments Block
> --

> The comments block consists of 2 mandatory parts (`author line`_ and
> `explanation`_) and one optional part (`last-rite epilogue`_). A blank line to
> separate the parts is optional. Trailing whitespace should be dropped.

> The lines in the comment block are prefixed with a "#" symbol. The comments
> should be separated with single space from the "#", unless this is trailing
> whitespace, in which case it should be removed (meaning blank lines in 
> comments
> block are just "#\n").

Maybe flip these two paragraphs? Otherwise it is not entirely clear
whether the "blank line" mentioned in the first paragraph refers to a
true blank line, or to a line consisting of a single number sign.

> The paragraph should be of format ``Removal on ${DATE}. ${BUGS-LIST}``, where
> the date is RFC-3339 full-date format, meaning ``-MM-DD``, and the bugs
> list is of the `bugs list`_ format. The listed bugs should include the
> last-rite bug opened, and potentially more relevant bugs which weren't listed
> in the explanation paragraphs.

Does this mean that only the first of the following entries would be
valid?

# Removal on 2023-11-13. Bugs #678901, #890123
# Removal on 2023-11-13, bugs #678901, #890123.
# Removal on 2023-11-13. Bugs #678901 #890123

IMHO that would be too restrictive. Punctuation shouldn't be significant
there. (This doesn't preclude _recommending_ one of the variants.)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [DRAFT] GLEP 84: Standard format for package.mask files

2023-10-05 Thread Ulrich Mueller
> On Thu, 05 Oct 2023, Michał Górny wrote:

>> Entries Grouping
>> 
>> 
>> Each mask entry consists of 2 parts: `comments block`_ and `packages list`_,
>> which aren't separated by a blank line between the 2 parts. Between entries, 
>> a
>> mandatory blank line must appear.
>> 
>> New entries added to the file must be inserted at the beginning, after the 
>> file
>> header.
>> 
>> Packages List
>> -
>> 
>> Must conform to PMS sections 4.4 [#PMS-4.4]_ and 5.2.8 [#PMS-5.2.8]_. This 
>> GLEP
>> further limits the syntax to one item per line, without any leading or
>> proceeding whitespaces, no comments inside the packages list, and no blank
>> lines between items in the list.

> That kinda sucks.  For very long masks, it is useful to be able to split
> the entry into subgroups.  I suppose it's technically still doable via
> splitting the entry but that sounds a bit backwards.

I think it could say that blank lines between items are allowed, without
any other change to the spec. The fact that each entry must start with a
comments block will still guarantee that assigning of packages to an
entry will be well-defined.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [DRAFT] GLEP 84: Standard format for package.mask files

2023-10-05 Thread Ulrich Mueller
> On Thu, 05 Oct 2023, Arthur Zamarin wrote:

> On 05/10/2023 06.12, Michał Górny wrote:
>> This is inconsistent with the current usage, and confusing.  "After"
>> makes it unclear whether the list is inclusive (i.e. "remove on that day
>> or later") or exclusive ("remove the next day or later"),
>> and in the latter case it's quite backwards.

> Hmm, I don't really care what word we use here, but I do want us to
> agree on one word (cause I'll need to update `pkgdev mask`). Some of the
> considerations against "on" (currently used) is the fact: does it mean
> it isn't fine to remove after it?
> Does English has a nice word for ">= time"?

Make it "on", because the date specified is the intended removal date
when the entry is added.

That is, users cannot rely on the package still being present at any
later date.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: [DRAFT] GLEP 84: Standard format for package.mask files

2023-10-05 Thread Ulrich Mueller
> On Wed, 04 Oct 2023, Arthur Zamarin wrote:

> Files can decide to add some extra file documentation, in which case, the
> entries start after the line:

> #--- END OF EXAMPLES ---

This agrees with current package.mask, but seems rather specific.
Instead of reinventing the wheel, maybe a "scissors line" could be used,
i.e. a line consisting mainly of "-", ">8" and "8<", similar to the line
used by git-mailinfo?

I'm also wondering if we shouldn't have a similar marker for the end of
the mask entries, i.e. everything after it would be ignored. This isn't
currently needed for package.mask, but other files in profiles have an
Emacs local variables block or a Vim modeline at the end.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

2023-09-25 Thread Ulrich Mueller
> On Sun, 24 Sep 2023, Jonas Stein wrote:

>> # Removal on 2023-10-21.  Bug #667687, #667689.

> We should use "after" instead of "on":

> # Removal after T

I wonder if we even need to specify the wording in such detail. For any
tools parsing the file, it might be enough to say that the line must
contain, in this order:

- "Removal" (case insensitive?) as the first word,
- exactly one date in -MM-DD format,
- optionally, the word "bug" followed by one or more bug numbers.

Ulrich



Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

2023-09-23 Thread Ulrich Mueller
> On Sat, 23 Sep 2023, Alex Boag-Munroe wrote:

> I'm confused, you're against adding "massive header blocks" but you're
> fine with Arthur's 9 line entry but not my 8 line one.

Your 8 line entry was this (please correct me if you meant to refer to
an entry from a different message):

--- 8< ---
# [PREAMBLE]
# Timestamp: 2023-09-21 15:07:42+00:00
# Author: Arthur Zamarin 
# Justification: Very broken, no idea why packaged, need to drop ASAP.
# The project is done with supporting this package.
# Bugs: 667687, 667689
# Packages: dev-lang/python
dev-lang/python
--- >8 ---

And Arthur's was this:

--- 8< ---
# Arthur Zamarin  (2023-09-21)
# Very broken, no idea why packaged, need to drop ASAP. The project
# is done with supporting this package. See for history bug #667889.
#
# As a better plan, you should migrate to dev-lang/perl, which has
# better compatibility with dev-lang/ruby when used with dev-lang/lua
# bindings.
# Removal on 2023-10-21.  Bug #667687, #667689.
dev-lang/python
--- >8 ---

Of course it is longer when it contains 4 additional lines of
explanation.

> My idea was a stop gap to add something easily parsed once the
> comments are stripped but keeping the comments in place currently for
> backwards compatibility.

Yes, understood. I think we should keep the "simple line-based file"
format [1] with comments. If we would change it to something completely
different, we would also impose that format on users' (public or
private) overlays.

Also, we'd either have to change the files in /etc/portage (not sure how
popular that would be) or live with two different and incompatible
formats in profiles and user configuration.

Ulrich

[1] https://projects.gentoo.org/pms/8/pms.html#x1-480005.2.5


signature.asc
Description: PGP signature


Re: [gentoo-dev] Proposal for a Universal Remote-ID File

2023-09-23 Thread Ulrich Mueller
> On Fri, 22 Sep 2023, Siddhanth Rathod wrote:

> I'm writing to propose the creation of a universal remote-ID file
> within the api.git or gentoo.git in the metadata/ directory.
> Currently, we have eight different locations that require manual
> updates for any future changes, including my recent commit
> (https://gitweb.gentoo.org/proj/gentoolkit.git/commit/?id=5146d35eb97e2c1a8f7691e59c755ed14e858dd4)
> to gentoolkit and the rest seven as mentioned here
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types.

> By establishing a universal remote-ID file, we can streamline this
> process. Your thoughts and feedback on this proposal would be greatly
> appreciated.Also, Any preferences on format?

My preference would be a simple text file with a table, similar to
files/uid-gid.txt in api.git. Then we could just modify the existing
tooling to generate the wiki page form it, and wouldn't need any special
tools to create the other files.

Alternatively, it could be in XML. While I'm not a large fan of XML, it
seems a natural choice here, because metadata.xml, the DTD, and the XML
and Relax-NG schemas are all from the XML world.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

2023-09-23 Thread Ulrich Mueller
> On Fri, 22 Sep 2023, Alex Boag-Munroe wrote:

> Perhaps eventually it could/should be used for the whole file but as
> an interim/beginning there's no reason you couldn't start with
> comments:

> # [PREAMBLE]
> # Timestamp: 2023-09-21 15:07:42+00:00
> # Author: Arthur Zamarin 
> # Justification: Very broken, no idea why packaged, need to drop ASAP.
> # The project is done with supporting this package.
> # Bugs: 667687, 667689
> # Packages: dev-lang/python
> dev-lang/python

And I thought my suggestion to use XML was far-fetched and an obvious
joke. :(

This seems rather restrictive, adds unnecessary redundancy, and would
make it hard to type an entry without the aid of special tools.

Also, there are other files like use.mask which probably shouldn't have
a completely different format. Their entries often have the author/date
line plus a one line comment which says all that is needed. Adding
massive header blocks there would be excessive.

IMHO Arthur's original proposal was fine. Let's not over-complicate
things.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

2023-09-22 Thread Ulrich Mueller
>>>>> On Fri, 22 Sep 2023, Ulrich Mueller wrote:

>>>>> On Fri, 22 Sep 2023, Florian Schmaus wrote:
>> Some, including me, consider timestamps without timezone specifiers to
>> be in local time (either of the consumer or producer of the
>> timestamp). Hence, if you really must have UTC here, then at least
>> consider making it explicit my requiring the 'Z' timezone specifier
>> (which, if you want to be ISO compatible, probably means that the
>> timestamp must include HH:MM too).

> How about converting package.mask to XML? The xs:date type would allow
> a date followed by a time zone [1].

> /me hides

Seriously, this isn't a hill I am willing to die on. I still prefer UTC
there, but I'd be fine if the wording said "should" instead of "must".

Ulrich



Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

2023-09-22 Thread Ulrich Mueller
> On Fri, 22 Sep 2023, Florian Schmaus wrote:

> Some, including me, consider timestamps without timezone specifiers to
> be in local time (either of the consumer or producer of the
> timestamp). Hence, if you really must have UTC here, then at least
> consider making it explicit my requiring the 'Z' timezone specifier
> (which, if you want to be ISO compatible, probably means that the
> timestamp must include HH:MM too).

How about converting package.mask to XML? The xs:date type would allow
a date followed by a time zone [1].

/me hides

[1] https://www.w3.org/TR/xmlschema-2/#deviantformats


signature.asc
Description: PGP signature


Re: [gentoo-dev] Standard parsable format for profiles/package.mask file

2023-09-22 Thread Ulrich Mueller
> On Fri, 22 Sep 2023, Oskari Pirhonen wrote:

>> Each entry is composed of 2 parts: "#"-prefixed explanation block and
>> list of "${CATEGORY}/${PN}" packages. Entries are separated when a new
>> explanation block starts (meaning first "#"-prefixed line after packages
>> list). You may add newlines between packages in packages list.

> What about mandatory blank line(s) between entries? That way it ensures
> they are visually separated when skimming through the file. Plus, you
> can easily jump from entry to entry in editors that support
> paragraph-wise movement.

Yes, please. Mandatory blank lines between entries, and no blank lines
(or lines containing only whitespace) within entries. Especially, no
blank lines in the list of packages.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Standard parsable format for profiles/package.mask file

2023-09-21 Thread Ulrich Mueller
> On Thu, 21 Sep 2023, Florian Schmaus wrote:

>> The first line of the "#"-prefixed explanation block must be of the
>> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
>> format -MM-DD, in UTC timezone.
> 

> Can we drop this? Or, at least, relax this.

I think UTC makes a lot of sense in an international context like ours.
It also avoids flapping of the date between entries (i.e. a newer entry
having an older date than the previous one).

> I usually just enter my locale date here and like to avoid having to
> think about that UTC is potentially in a different date. I also can
> not remember any situation where the date being in UTC matters. Plus,
> if you want accurate timestamps, then the git commit/author date is
> here for you. :)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Standard parsable format for profiles/package.mask file

2023-09-21 Thread Ulrich Mueller
> On Thu, 21 Sep 2023, Arthur Zamarin wrote:

> = "Formal" format =

> Each entry is composed of 2 parts: "#"-prefixed explanation block and
> list of "${CATEGORY}/${PN}" packages. Entries are separated when a new
> explanation block starts (meaning first "#"-prefixed line after packages
> list). You may add newlines between packages in packages list.

"Must" rather than "may" here? You certainly cannot list several
packages in the same line.

> The first line of the "#"-prefixed explanation block must be of the
> format "${AUTHOR_NAME} <${EMAIL}> (${SINGLE_DATE})" when the date is of
> format -MM-DD, in UTC timezone.

> If this is a last-rite message, the last line must list the last-rite
> last date (removal date) and the last-rite bug number. You can also list
> other bugs relevant to the last-rite. So I think a format of: "Removal
> on ${REMOVAL_DATE}.  Bug #NN, #NN." Where the bug list is comma
> and space separated, we have at least one space (" +" regex) between the
> removal date and bug list, and the date is of -MM-DD format.
> I prefer this line is separate (and not continuous of prefix message text).

> The explanation block itself can reference bugs, by matching the regex
> "[Bb]ugs? #\d+(, +#\d+)*" (For example: "bug #713106, #753134"). I think
> this is quite a simple one, but powerful enough for most.

> Lines with single newline between them (so no blank line between them)
> are considered as single paragraph continuum. If you want to start new
> paragraph, leave a blank line (still prefixed with #) - think similar to
> markdown. A line matching the last-rite line is always it's own paragraph.

Is this rule about paragraphs needed? It is at odds with the rule that
the removal date and bug must be on their own line (i.e. that line is
_not_ part of a "paragraph continuum").

What about the introductory comment block in the file? Should there be a
defined syntax for a separator between it and the rest of the file? For
example, everything above the first line matching "^#[ \t]*---" could be
ignored by automatic tools, and they would insert new entries below that
separator.

> Should it be a GLEP, I don't think so? But I'm unsure about it. We do
> need to document it (for example header of that exact file).

It shouldn't be too difficult to wrap this up as a GLEP. OTOH, we don't
have a GLEP for eclassdoc either.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] last rites (kinda, long masked): sys-apps/opentmpfiles

2023-09-20 Thread Ulrich Mueller
> On Sun, 17 Sep 2023, Andreas K Huettel wrote:

> # Andreas K. Hüttel  (2021-07-06, 2023-09-15)

Please use only a single date. The current line breaks parsing of the
date on packages.gentoo.org, which shows 0001-01-01:
https://packages.gentoo.org/packages/sys-apps/opentmpfiles


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: app-emacs/crypt++

2023-09-20 Thread Ulrich Mueller
# Ulrich Müller  (2023-09-20)
# Unmaintained upstream: Last release (2.92) in 2003, last commit
# to XEmacs CVS repository in 2008. Broken with Emacs 29.
# Masked for removal on 2023-10-20, bug #914449.
app-emacs/crypt++


signature.asc
Description: PGP signature


Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers

2023-09-17 Thread Ulrich Mueller
> On Sun, 17 Sep 2023, Florian Schmaus wrote:

> 
>   
> 

> sounds perfectly fine.

Don't use an attribute if you can put the information in the (otherwise
empty) element. Especially, when other elements like  already do it
that way.

> It would require (minor) adjustments to the schema and DTD.

Also an update of GLEP 68, in the first place.


signature.asc
Description: PGP signature


Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers

2023-09-17 Thread Ulrich Mueller
> On Sun, 17 Sep 2023, Alexander Neuwirth wrote:

> Thanks. Instead of using the lang entry I can imagine these other
> approaches:

> 1. doi/arxiv/... links could also easily be plugged in custom upstream
> remote ids, but that also feels a bit wrong since all other [upstream
> remote
> ids](https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types)
> are repos/source code providers.

GLEP 68 rather abstractly says that the remote-id elements should point
to "package identification trackers", and its predecessor GLEP 46
explains that this means the upstream source. So this doesn't look like
a good fit.

> 2. Adding something specific to GLEP 68, like ` type="doi"> https...`. However that seems like a bit too much work for
> adding something that only a small subset of users (science) cares
> about. Also integration of parsing with existing tools is an extra
> overhead.

This would require maintenance of another list of types. Looks like the
semantic is implicit in the URL, so is a type really needed?

A simpler change would be to lift the uniqueness restriction for the
doc element, i.e. allow it multiple times for the same language.

> 3. Put them also into `HOMEPAGE` of the ebuilds. Again bit of a wrong
> place, but with the (minor) advantage of having possibly different/new
> references per version.

This wouldn't require any changes.

> Is any of these three superior/preferable?

It depends on how many packages in the Gentoo repository are expected to
use the feature.

If the answer is less than ten, then IMHO using HOMEPAGE is a reasonable
choice. If it would be at least an order of magnitude more, then we could
think about updating GLEP 68 (e.g. lift uniqueness of doc).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] metadata.xml upstream docs as reference to scientific publications/papers

2023-09-15 Thread Ulrich Mueller
> On Fri, 15 Sep 2023, Alexander Neuwirth wrote:

> I am looking for a way to link scientific publications to
> ebuilds/packages. The easiest, but hacky way right now is to use the 
> |https://doi.org/...|. Integration with
> |epkginfo|/|equery meta| works nicely out of the box. However,
> currently |pkgcheck| and/or the XML format complains about repeated
> |lang| entries and does not allow long |lang| attributes (i.e.
> |lang="inspirehep"| fails understandably).

Please don't do this. The lang attribute is of type xs:language [1]
so it must be a valid BCP 47 language tag.

As a matter of fact, "doi" happens to be a valid tag for the Dogri
language [2], but this isn't helpful either.

[1] 
https://gitweb.gentoo.org/data/xml-schema.git/tree/metadata.xsd?id=db829cfdb40ae0a0034848cce38ee741a7c8d68c#n257
[2] https://www.loc.gov/standards/iso639-2/php/langcodes_name.php?code_ID=117



Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options

2023-09-14 Thread Ulrich Mueller
> On Wed, 13 Sep 2023, Eli Schwartz wrote:

>> That's a rather bold statement. I can imagine a number of possible
>> failures, e.g. no space left on device, quota exceeded, or a low-level
>> I/O error of the filesystem. Also fork or exec of the cat command could
>> fail (e.g. out of memory).
>> 
>> While either of these may be unlikely here, best practice is to check
>> for errors of _all_ external commands.

> The implementation of `die` performs a fork+exec of the sed command,
> invokes eerror (many times!) which forks to pipe, invokes $() which
> forks, and could behave abnormally due to out of memory. It is not safe
> to treat `|| die` as error recovery for an out of memory condition.

> The implementation of `die` performs multiple writes to files inside of
> ${PORTAGE_BUILDDIR}, and could behave abnormally due to write failures.
> It is not safe to treat `|| die` as error recovery for a write failure
> of the ${PORTAGE_BUILDDIR} drive (whatever the reason for that write
> failure).

An eclass must not rely on implementation details of any specific
package manager.

"die [...] aborts the build process."
https://projects.gentoo.org/pms/8/pms.html#x1-12600012.3.6

So please report a Portage (or other package manager) bug if you can
reproduce a condition where die doesn't abort the build process.

> (And the `|| die` is added to the next revision of this patch either way.)

Thanks.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options

2023-09-13 Thread Ulrich Mueller
> On Wed, 13 Sep 2023, Eli Schwartz wrote:

>> "|| die" should also be added for the cat command.

> Redirecting output to a file in a directory you have just guaranteed
> to exist cannot fail.

That's a rather bold statement. I can imagine a number of possible
failures, e.g. no space left on device, quota exceeded, or a low-level
I/O error of the filesystem. Also fork or exec of the cat command could
fail (e.g. out of memory).

While either of these may be unlikely here, best practice is to check
for errors of _all_ external commands.



Re: [gentoo-dev] [PATCH 1/2] distutils-r1.eclass: teach setuptools to respect (some) build options

2023-09-12 Thread Ulrich Mueller
> On Tue, 12 Sep 2023, Eli Schwartz wrote:

> + mkdir -p "${BUILD_DIR}" || die
> + local -x 
> DIST_EXTRA_CONFIG="${BUILD_DIR}/extra-setup.cfg"
> + cat > "${DIST_EXTRA_CONFIG}" <<-EOF
> + [build]
> + build_base = ${BUILD_DIR}/build
> +
> + [build_ext]
> + parallel = ${jobs}
> + EOF

"|| die" should also be added for the cat command.



Re: [gentoo-dev] [PATCH 2/3] verify-sig.eclass: Support `openssl dgst` format checksums

2023-09-08 Thread Ulrich Mueller
> On Fri, 08 Sep 2023, Michał Górny wrote:

>> > +  ! has "${filename}" "${files[@]}" && continue
>> 
>> This might be clearer if it was written as:
>> 
>> has "${filename}" "${files[@]}" || continue

> Negative logic is never clearer.

Exactly. That's why we generally do "command || die" rather than
"! command && die".


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/3] verify-sig.eclass: Support `openssl dgst` format checksums

2023-09-04 Thread Ulrich Mueller
> On Mon, 04 Sep 2023, Michał Górny wrote:

> --- a/eclass/verify-sig.eclass
> +++ b/eclass/verify-sig.eclass
> @@ -214,12 +214,15 @@ verify-sig_verify_message() {
>  }
 
>  # @FUNCTION: verify-sig_verify_unsigned_checksums
> -# @USAGE:   
> +# @USAGE:   

Below, verify-sig_verify_signed_checksums() still says "algo", change
that too for consistency?

>  # @DESCRIPTION:
>  # Verify the checksums for all files listed in the space-separated list
> -#  (akin to ${A}) using a .   specifies
> -# the checksum algorithm (e.g. sha256).   can be "-"
> -# for stdin.
> +#  (akin to ${A}) using a .   specifies
> +# the checksum file format.   can be "-" for stdin.
> +#
> +# The following formats are supported:
> +# - sha256 -- sha256sum ( )
> +# - openssl-dgst -- openssl dgst (()=)

This won't be rendered as a list in the man page, but will be rewrapped
as a paragraph. (Putting a space before the "-" will help.)

The existing variable documentation of VERIFY_SIG_METHOD suffers from
the same problem, BTW.

>  #
>  # The function dies if one of the files does not match checksums or
>  # is missing from the checksum file.
> @@ -234,32 +237,46 @@ verify-sig_verify_unsigned_checksums() {
>   local algo=${2}

Maybe rename the variable to "format", when the documentation now says
that the second parameter specifies the format?

>   local files=()
>   read -r -d '' -a files <<<"${3}"
> - local chksum_prog chksum_len
> + local chksum_prog chksum_len format=coreutils

And rename this one too. (I don't find it intuitive for a checksum
format to be named "coreutils", when coreutils provides cksum, md5sum,
b2sum, etc.)

> 
>   case ${algo} in
>   sha256)
> - chksum_prog=sha256sum
>   chksum_len=64
>   ;;
> + openssl-dgst)
> + format=${algo}
> + ;;
>   *)
> - die "${FUNCNAME}: unknown checksum algo ${algo}"
> + die "${FUNCNAME}: unknown checksum format ${algo}"
>   ;;
>   esac
> 
>   [[ ${checksum_file} == - ]] && checksum_file=/dev/stdin
> - local checksum filename junk ret=0 count=0
> - while read -r checksum filename junk; do
> - if [[ ${checksum} == "-BEGIN" ]]; then
> + local line checksum filename junk ret=0 count=0
> + while read -r line; do
> + if [[ ${line} == "-BEGIN"* ]]; then
>   die "${FUNCNAME}: PGP armor found, use 
> verify-sig_verify_signed_checksums instead"
>   fi
> 
> - [[ ${#checksum} -eq ${chksum_len} ]] || continue
> - [[ -z ${checksum//[0-9a-f]} ]] || continue
> - has "${filename}" "${files[@]}" || continue
> - [[ -z ${junk} ]] || continue
> -
> - "${chksum_prog}" -c --strict - <<<"${checksum} ${filename}"
> - if [[ ${?} -eq 0 ]]; then
> + case ${format} in
> + coreutils)
> + read -r checksum filename junk <<<"${line}"
> + [[ ${#checksum} -ne ${chksum_len} ]] && continue
> + [[ -n ${checksum//[0-9a-f]} ]] && continue
> + [[ -n ${junk} ]] && continue
> + ;;
> + openssl-dgst)
> + [[ ${line} != *"("*")="* ]] && continue
> + checksum=${line##*)=}
> + algo=${line%%(*}
> + filename=${line#*(}
> + filename=${filename%)=*}
> + ;;
> + esac
> +
> + ! has "${filename}" "${files[@]}" && continue

This might be clearer if it was written as:

has "${filename}" "${files[@]}" || continue

> +
> + if "${algo,,}sum" -c --strict - <<<"${checksum} ${filename}"; 
> then
>   (( count++ ))
>   else
>   ret=1


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] eutils.eclass: Drop EAPI 7

2023-08-30 Thread Ulrich Mueller
In spite of the deprecation warning being in place for more than a year,
this seems to have caused errors with EAPI 7 ebuilds in some overlays.

Since we see some strange fixes, like downgrading of ebuilds to EAPI 6
(which is banned), here's a quick recipe for overlay maintainers how to
go for this:

1. From a quick scan of ebuilds in overlays, it looks like eutils can
   simply be dropped from inherit in the vast majority of cases.

2. After doing this, run "pkgcheck scan". It will report any eclasses
   that are missing.

Hint: If in the second step, pkgcheck doesn't report any of "edos2unix",
"strip-linguas" or "wrapper", then inheriting eutils was incorrect
before, and removal of EAPI 7 from eutils.eclass only exposes that
error.



Re: [gentoo-dev] Add Hooks to Eselect

2023-08-21 Thread Ulrich Mueller
> On Mon, 21 Aug 2023, konsolebox  wrote:

> This actually allows users to virtually extend an eselect module without
> needing to fork it.  The things people can do are endless.

This isn't what eselect modules were designed for. They are specialised
tools that are supposed to do one thing, and one thing only. It's like
suggesting that a command like cat or mv would need configuration or
some extension mechanism.

Also, given that eselect modules are normally run as root and the damage
that can result from bugs, I'd rather keep things simple, instead of
introducing "endless" possibilities. This approach has worked very well
during the last 18 years.

(If anything, a hook mechanism would look very different from what was
proposed here. First, changing a low-level function like check_do() is
really a no-no, because this function is documented in the eselect
developer guide and third-party modules may rely on it. Second, instead
of executing a separate script for every hook, there would be a file
defining shell functions for all subactions of a given module. But I
haven't thought about any details, because as I said, I don't see much
incentive for such a thing.)



Re: [gentoo-dev] Add Hooks to Eselect

2023-08-21 Thread Ulrich Mueller
> On Mon, 21 Aug 2023, Redjard  wrote:

> I did consider doing so, however with that approach my effective fork
> of the kernel.eselect module would get continually outdated, while a
> wrapper module requires a different command [...]

Not necessarily. It could use the same name as the original module,
after adjusting the modules path:

ESELECT_MODULES_PATH=( "${ESELECT_DEFAULT_MODULES_PATH}" )

Still, I'd not recommend using the same name when its behaviour is
different from the original module.



Re: [gentoo-dev] Add Hooks to Eselect

2023-08-21 Thread Ulrich Mueller
> On Mon, 21 Aug 2023, Redjard  wrote:

> To roughly summarize, I was asking for a method to hook into eselect,
> to modify the behavior of eselect kernel set.
> I was pointed in the direction of a user patch by konsolebox, and
> consequently wrote the patch.

In addition to user patches, you can also put your own modules in the
${HOME}/.eselect/modules/ directory.

For example, you could either copy kernel.eselect to there and modify
it. Or, you could have a mykernel.eselect module, along these lines:

do_set() {
... # execute "pre" stuff
do_action kernel set "$@"
... # execute "post" stuff
}

The unchanged subactions would be trivial functions like this:

do_list() { do_action kernel list "$@"; }

> I provided an example for using the patched hooks, which I will repeat
> below.

Sorry, but I don't see much incentive for adding such a hook mechanism.
If there was, it would have been suggested previously since eselect was
created in 2005. Also, by design, eselect itself doesn't rely on any
configuration in /etc so this would be a somewhat intrusive change.

As a side note, your previously posted patch wouldn't work as-is:

>>> -check_do() {
>>> +check_do() {
>>> local function=$1
>>> -   shift
>>> +   shift; params="$@"
>>> if is_function "${function}" ; then
>>> -   ${function} "$@"
>>> +   run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" pre
>>> +   ${function} "${params}"

Using a scalar variable instead of "$@" (which is an array) would break
quite a few modules.

>>> +   run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" post
>>> else
>>> die "No function ${function}"
>>> fi
>>>  }

Ulrich



Re: [gentoo-dev] are there any lisps in the default/linux/amd64/17.0/musl profile?

2023-07-23 Thread Ulrich Mueller
>>>>> On Sun, 23 Jul 2023, Ulrich Mueller wrote:

> I think what happens is this: sbcl is masked on musl, but it is the only
> version that is enabled in the ebuild by the IUSE="+sbcl" default.
> Therefore, none of the versions available on musl is enabled there,
> resulting in an unsatisfied REQUIRED_USE.

I meant "lisp engines" there, not "versions".


signature.asc
Description: PGP signature


Re: [gentoo-dev] are there any lisps in the default/linux/amd64/17.0/musl profile?

2023-07-23 Thread Ulrich Mueller
> On Sun, 23 Jul 2023, Andrey Grozin wrote:

> OK, sbcl is masked on musl. But why clisp, ecls, or gcl cannot be used
> in the amd64 musl profile?

> (I don't know if they actually work on amd64 musl systems, or if
> anybody ever tried to do so. I just ask a formal question about Gentoo
> profiles system.)

pkgcheck's mesage was this:

  RequiredUseDefaults: version 5.47.0: profile: 'default/linux/amd64/17.0/musl' 
(3 total) failed REQUIRED_USE: ( clisp || clozurecl || clozurecl64 || cmucl || 
ecls || gcl || sbcl )

I think what happens is this: sbcl is masked on musl, but it is the only
version that is enabled in the ebuild by the IUSE="+sbcl" default.
Therefore, none of the versions available on musl is enabled there,
resulting in an unsatisfied REQUIRED_USE.

Moving the + from sbcl to e.g. clisp would get rid of the message, but
maybe this is not an acceptable solution.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] are there any lisps in the default/linux/amd64/17.0/musl profile?

2023-07-23 Thread Ulrich Mueller
> On Sun, 23 Jul 2023, Andrey Grozin wrote:

> It seems that there are no lisps in this profile. This may be correct.
> But where are all lisps masked? I see only

> grozin@bilbo /home/gentoo/profiles $ find -name package.mask | xargs
> fgrep lisp
> ./arch/powerpc/ppc64/package.mask:dev-lisp/sbcl
> ./arch/powerpc/ppc64/32ul/package.mask:-dev-lisp/sbcl
> ./arch/powerpc/ppc64/64le/package.mask:-dev-lisp/sbcl
> ./arch/sparc/64ul/package.mask:dev-lisp/sbcl

The flags are masked in arch/base:

$ find . -name 'use.mask' -exec grep -E 
'^(clisp|clozurecl|clozurecl64|cmucl|ecls|gcl|sbcl)\b' {} +
./features/musl/use.mask:sbcl
./arch/base/use.mask:clisp
./arch/base/use.mask:clozurecl
./arch/base/use.mask:cmucl
./arch/base/use.mask:ecls
./arch/base/use.mask:gcl
./arch/base/use.mask:sbcl


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 4/6] kernel-install.eclass: kernel-install_get_qemu_arch: port to sparc

2023-07-21 Thread Ulrich Mueller
> On Fri, 21 Jul 2023, Michał Górny wrote:

> I suppose I originally didn't anticipate this many "matching" arches but
> perhaps it's time to add something like:

> arm|ppc|ppc64|riscv|sparc|sparc64)
>   echo ${ARCH}
>   ;;

Sounds good.

As a side note, eselect has a table with the (nearly) inverse mapping:
https://gitweb.gentoo.org/proj/eselect.git/tree/libs/package-manager.bash.in?h=eselect-1.4.25#n70


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 4/6] kernel-install.eclass: kernel-install_get_qemu_arch: port to sparc

2023-07-21 Thread Ulrich Mueller
> On Fri, 21 Jul 2023, Sam James wrote:

> @@ -162,6 +162,12 @@ kernel-install_get_qemu_arch() {
>   ppc64)
>   echo ppc64
>   ;;
> + sparc)
> + echo sparc
> + ;;
> + sparc64)
> + echo sparc64
> + ;;
>   riscv)
>   echo riscv
>   ;;

Looks like the case patterns are in alphabetical order everywhere else,
so why not here?


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] meson.eclass: allow disabling verbose compilation

2023-07-20 Thread Ulrich Mueller
> On Thu, 20 Jul 2023, Mike Gilbert wrote:

> On Thu, Jul 20, 2023 at 11:06 AM Florian Schmaus  wrote:
>> While the bash language has no boolean datatype, you can exploit the
>> fact that 'true' and 'false' are usually shell builtins:
>> 
>> : "${MESON_VERBOSE:=true}"
>> 
>> and then later
>> 
>> if $MESON_VERBOSE; then
>> mesoncompileargs+=( --verbose )
>> fi

> I think we generally try to avoid exploiting that behavior in ebuilds.
> It's usually much more obvious to check for a non-empty string, or for
> a specific value.

Testing for a non-empty variable is also faster than executing "true"
or "false" builtins from variable values. (Which doesn't play any role
here, but readability of the code does.)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: obsolete acct-* packages

2023-07-18 Thread Ulrich Mueller
> On Mon, 17 Jul 2023, Mike Gilbert wrote:

> On Mon, Jul 17, 2023 at 4:27 PM Sam James  wrote:
>> > Haven't we been keeping these because we still need to decide on a
>> > policy about what to do with dead acct-*/* packages?
>> 
>> Right. https://bugs.gentoo.org/781881 is still open. Flow could ping
>> the QA team and ask if it should be closed, given the opinion there
>> seems to be that there's no need to keep them, but I think it's wrong
>> to do this pre-empting a policy decision, given it essentially forces
>> the "don't keep them" path.

> The bug has been open for several months without comment. If a policy
> were going to materialize, I think it would have happened by now.

> Forcing the issue by sending this last rites notice seems acceptable
> to me.

I'd say we remove the packages, because system user and group ids are
a somewhat scarce resource.

The ids in uid-gid.txt (in data/api.git) need to be updated as well,
i.e. they should be kept for now but changed to historical.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch

2023-07-17 Thread Ulrich Mueller
> On Mon, 17 Jul 2023, konsolebox  wrote:

>> Maybe the commit message could shortly explain why this is needed,
>> or what problem is fixed by it?

> It silences the default branch warning.

Add this sentence to the commit message then?

> If that's unwanted, kindly just close the issue.

Huh?



Re: [gentoo-dev] [PATCH] git-r3.eclass: Use '__init__' as initial branch

2023-07-17 Thread Ulrich Mueller
> On Mon, 17 Jul 2023, Matt Turner wrote:

> From: konsolebox 
> Closes: https://bugs.gentoo.org/841392
> Signed-off-by: Matt Turner 

Maybe the commit message could shortly explain why this is needed,
or what problem is fixed by it?


signature.asc
Description: PGP signature


Re: [gentoo-dev] Package stabilization groups

2023-07-16 Thread Ulrich Mueller
> On Sun, 16 Jul 2023, Arthur Zamarin wrote:

> Let me list some things as advantages to each one (since I see an
> advantage to one as disadvantage to other).

> Advantages of field in metadata.xml:

> - local to package, easier to not miss. Easier to follow for the maintainer.

> - easier to find which group the current package relates to

> Advantages to group files:

> - easier to index (one file listing all children, instead of searching
> across repo who defines it)

> - easier to not repeat group. In the metadata field it might happen to
> repeat, less likely since it is easy to search, but similar group names
> might be created, merging them into one by mistake, or creating very
> similar names and mistaking them. When we have a single file, it is
> easier to see the whole picture and verify things.

> - since this is compressed information (special files instead of spread
> over repo), we could load all of them into app's cache, and make all
> computation easier.

> - enables an easier syntax as `pkgdev bugs @group1` to file a single bug
> for all of them. In Gnome's case as an example, we could have "gnome1",
> "gnome2", "gnome3", "gnome4", etc - groups standing for multiple
> "layers/stages" of stabilizing, and then you could just file `pkgdev
> bugs @gnome{1..4}` to file "at one click" the whole gnome stablereqs.

Can't we do the same that we do for local use flags? Namely, define them
in metadata.xml, but collect them in one central location?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/7] eclass/nuget.eclass: introduce new eclass

2023-07-16 Thread Ulrich Mueller
> On Sun, 16 Jul 2023, Maciej Barć wrote:

> +case "${EAPI}" in
> + 7 | 8 )
> + :
> + ;;
> + * )
> + die "${ECLASS}: EAPI ${EAPI} unsupported."
> + ;;
> +esac

The QA team has invested quite some work to unify that case block
between different eclasses. So, please stay with the standard style:

case ${EAPI} in
7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: Flow's Manifesto and questions for nominees

2023-07-14 Thread Ulrich Mueller
> On Fri, 14 Jul 2023, Florian Schmaus wrote:

> Posted to gentoo-dev@ since we are now entering a technical discussion
> again.

Please avoid crossposting, because that doesn't work well. (For example,
the posting will have different Reply-To headers in gentoo-project and
in gentoo-dev.)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 4/4] distutils-r1.eclass: Disable LTO when using cargo.eclass

2023-07-12 Thread Ulrich Mueller
> On Wed, 12 Jul 2023, Michał Górny wrote:

> + if [[ ${_CARGO_ECLASS} ]]; then
> + filter-lto
> + fi

Testing for an internal variable of another eclass seems less than
ideal. How about "has cargo ${INHERITED}" instead?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] sci-mathematics/fricas ebuild

2023-07-11 Thread Ulrich Mueller
> On Tue, 11 Jul 2023, Andrey Grozin wrote:

> Can somebody please edit the fricas-1.3.9.ebuild - replace the SRC_URI
> by .../${P}-full.tar.bz2 and commit it to the tree?

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4c6412ecf83a0465531c65b115b0e3ff8d875296


signature.asc
Description: PGP signature


Re: [gentoo-dev] Possible merge of myspell/hunspell dictionaries

2023-07-11 Thread Ulrich Mueller
> On Tue, 11 Jul 2023, Joonas Niilola wrote:

> it would be better than the current situation for sure, but my
> impression with myspell* packages is that they all have different
> version releases and different upstream source uris, so just wondering
> can it be done with a single package? In theory it'd be an improvement
> though if there is a single upstream holding all language options.

The latter isn't the case. I count 24 app-dicts/myspell-* packages with
SRC_URI pointing to libreoffice.org, and 26 packages pointing elsewhere.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Possible merge of myspell/hunspell dictionaries

2023-07-09 Thread Ulrich Mueller
> On Sun, 09 Jul 2023, Mart Raudsepp wrote:

> Ühel kenal päeval, P, 09.07.2023 kell 10:10, kirjutas Sam James:
>> 
>> zurabid2...@gmail.com writes:
>> 
>> > I am new here, so I'm sorry in advance for any stupid thing I may
>> > say. I want to adopt hunspell for various reasons and what I've
>> > noticed is a plethora of app-dicts/myspell-* packages (for each
>> > language there's one).
>> > 
>> > I suggest merging them into one big myspell-dicts package, which
>> > will certainly reduce maintenance burden (the similar thing is done
>> > with libreoffice-l10n, I think).
>> 
>> My only real question is why they're split in the first place and
>> if there's some good reason for that. I've no idea.

> I would guess that they are different packages because they all have a
> different SRC_URI. Many to some libreoffice assets download location,
> but not all.
> Maybe they could all come from the same source in an updated packaging
> though, I don't know the background.

These are different packages because they have different upstreams,
versioning schemes, and release cycles. Since we tend to follow
upstream packaging, I'm not sure if combining them would make sense.

I'm also not sure if it would reduce maintenance burden. I maintain
app-i18n/man-pages-l10n, which gets way more frequent releases than the
formerly separate man-pages-* packages, with each version bump requiring
build and test for all supported languages instead of just one.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] user-info.eclass: egetent: fix lookup by id when ROOT != /

2023-07-09 Thread Ulrich Mueller
LGTM except for a typo in the commit message:

> Adding a colon to the grep expression yeilds the desired result:


signature.asc
Description: PGP signature


Re: [gentoo-dev] EGO_SUM

2023-07-03 Thread Ulrich Mueller
> On Mon, 03 Jul 2023, Florian Schmaus wrote:

> So pkgcheck counting EGO_SUM entries would be sufficient for the
> purpose of having a static check that notices if the ebuild would
> likely run into the environment limit?

> To find a common compromise, I would possibly invest my time in
> developing such a test. Even though I do not deem such a check a
> strict prerequisite to reintroduce EGO_SUM.

The so-called "environment limit" is 32 pages, i.e. normally 128 KiB.
With the A variable anywhere near this, the size of the Manifest file
would be close to 1 MiB.

IMHO this is way too large to be used on a regular basis. I am aware
that we have some packages with large Manifests (71 packages above
50 KiB, 6 packages above 200 KiB, out of 18812 packages in total),
but these should really remain the exception.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] gradle.eclass: add new eclass

2023-06-28 Thread Ulrich Mueller
> On Wed, 28 Jun 2023, Florian Schmaus wrote:

> +# @FUNCTION: gradle-src_uri
> +# @DESCRIPTION:
> +# Generate SRC_URI data from EGRADLE_BUNDLED_VER.
> +gradle-src_uri() {

This is named gradle_src_uri (with two underscores) in the main eclass
documentation.

> +# @FUNCTION: gradle-src_unpack
> +# @DESCRIPTION:
> +# Unpack the "bundled" gradle version.  You must have
> +# EGRADLE_BUNDLED_VER set when calling this function.
> +gradle-src_unpack() {

Even if this isn't exported, is there any good reason for deviating from
the normal naming convention for eclass phase functions?

Ulrich



Re: [gentoo-dev] [PATCH] cmake.eclass: workaround S=${WORKDIR} creating builddir above ${WORKDIR}

2023-06-26 Thread Ulrich Mueller
> On Mon, 26 Jun 2023, Jaco Kroon wrote:

>> if [[ ${BUILD_DIR} != "${WORKDIR}"/* ]]; then

> BUILD_DIR="${WORKDIR}/../build"

Oh right, I hadn't thought about the case that the ebuild would override
it. (AFAICS cmake.eclass itself doesn't do .. in BUILD_DIR.)

> I know it's pathological ... but still.  readlink -f should be
> considered here unless it can be guaranteed that BUILD_DIR will not
> contain .. components at this stage.



Re: [gentoo-dev] [PATCH] cmake.eclass: workaround S=${WORKDIR} creating builddir above ${WORKDIR}

2023-06-26 Thread Ulrich Mueller
> On Mon, 26 Jun 2023, Sam James wrote:

> +
> + # Avoid creating ${WORKDIR}_build (which is above WORKDIR).
> + # TODO: For EAPI > 8, we should ban S=WORKDIR for CMake.
> + # See bug #889420.
> + if [[ ${S} == ${WORKDIR} && ${BUILD_DIR} == ${WORKDIR}_build ]] 
> ; then

I'd suggest adding quotes to the RHS of the expression, to prevent
globbing.

But I think what you really want is to check whether ${BUILD_DIR}
(whatever its name is) is a subdirectory of ${WORKDIR}? Maybe a test
like this would make that intent clearer:

if [[ ${BUILD_DIR} != "${WORKDIR}"/* ]]; then

> + eqawarn "QA notice: S=WORKDIR is deprecated for 
> cmake.eclass."
> + eqawarn "Please relocate the sources in src_unpack."
> + BUILD_DIR="${WORKDIR}"/${P}_build
> + fi



Re: [gentoo-dev] [PATCH 7/7] pypi.eclass: Avoid subshell for extglob setting

2023-06-13 Thread Ulrich Mueller
> On Tue, 13 Jun 2023, Michał Górny wrote:

>  _pypi_normalize_name() {
>   local name=${1}
> - local shopt_save=$(shopt -p extglob)
> - shopt -s extglob
> + local prev_extglob=-s
> + if ! shopt -p extglob >/dev/null; then
> + prev_extglob=-u
> + shopt -s extglob
> + fi
>   name=${name//+([._-])/_}
> - ${shopt_save}
> + shopt "${prev_extglob}" extglob
>   _PYPI_NORMALIZED_NAME="${name,,}"
>  }

In principle you could also do something like this:

if shopt -pq extglob; then
name=${name//+([._-])/_}
else
shopt -s extglob
name=${name//+([._-])/_}
shopt -u extglob
fi

It duplicates one line of code, but saves a variable and IMHO the code
would be easier to understand.

Also, with the -q option no output redirection is needed.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] java-pkg-simple.eclass: respect SLOT="0" in JAVA_LAUNCHER_FILENAME

2023-05-29 Thread Ulrich Mueller
> On Mon, 29 May 2023, Volkmar W Pogatzki wrote:

> +if [[ ${SLOT} = 0 ]]; then
> +: "${JAVA_LAUNCHER_FILENAME:=${PN}}"
> +else
>  : "${JAVA_LAUNCHER_FILENAME:=${PN}-${SLOT}}"
> +fi

Please indent the lines in the then and else blocks.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] java-pkg-simple.eclass: respect SLOT="0" in JAVA_LAUNCHER_FILENAME

2023-05-29 Thread Ulrich Mueller
> On Mon, 29 May 2023, Volkmar W Pogatzki wrote:

>> > -: "${JAVA_LAUNCHER_FILENAME:=${PN}-${SLOT}}"
>> > +if [[ ${SLOT} = 0 ]]; then
>> > +  JAVA_LAUNCHER_FILENAME="${PN}"
>> > +else
>> > +  JAVA_LAUNCHER_FILENAME="${PN}-${SLOT}"
>> > +fi
>> 
>> This will no longer allow overriding the variable in the ebuild
>> (at least not pre-inherit). Is this intentional?

> It exactly does what it's supposed to do.
> No clue about "not pre-inherit".

With the above, JAVA_LAUNCHER_FILENAME="foo" in the ebuild will work if
comes after the inherit line, but not if it is before it.

> How to sanitize?

As in your v2. :)


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] java-pkg-simple.eclass: respect SLOT="0" in JAVA_LAUNCHER_FILENAME

2023-05-26 Thread Ulrich Mueller
> On Fri, 26 May 2023, Volkmar W Pogatzki wrote:

> -: "${JAVA_LAUNCHER_FILENAME:=${PN}-${SLOT}}"
> +if [[ ${SLOT} = 0 ]]; then
> + JAVA_LAUNCHER_FILENAME="${PN}"
> +else
> + JAVA_LAUNCHER_FILENAME="${PN}-${SLOT}"
> +fi

This will no longer allow overriding the variable in the ebuild
(at least not pre-inherit). Is this intentional?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] profiles/targets/desktop: enable USE=vulkan by default

2023-05-22 Thread Ulrich Mueller
> On Mon, 22 May 2023, Andreas Sturmlechner wrote:

>> Should it be renamed to "skia" for libreoffice, because that's also the
>> name of the upstream flag? libreoffice will also output a warning with
>> USE="vulkan -clang".

> That would not be accurate. The (bundled) skia is always being built,
> it is just the component using vulkan. That detail does not need to be
> part of the description though, so a global would fit.

Why is it "$(use_enable vulkan skia)" in econf arguments then?

configure --help says:

  --disable-skia  Disable building Skia. Use --enable-skia=debug to
  build without optimizations.

Ulrich



Re: [gentoo-dev] [PATCH] profiles/targets/desktop: enable USE=vulkan by default

2023-05-22 Thread Ulrich Mueller
> On Mon, 22 May 2023, Ionen Wolkens wrote:

>> That's a non-sequitur. No reason to not have it on doesn't imply that
>> there is a reason to have it on.
>> 
>> Also, shouldn't we avoid enabling local flags in profiles?

> I keep forgetting that this is still not global either, guess it'll
> ideally need another step first.

I see vulkan 31 times in use.local.desc, with slightly different
descriptions. Most notable difference:

app-office/libreoffice:vulkan - Enable Vulkan usage via the skia library (clang 
recommended)

Should it be renamed to "skia" for libreoffice, because that's also the
name of the upstream flag? libreoffice will also output a warning with
USE="vulkan -clang".

> For often-used USE, that doesn't mean that every users should have to
> enable it manually when they try to emerge the package. It would
> notably be annoying if, e.g. opengl wasn't default either (if opengl
> can be a default, I don't see why vulkan can't be in 2023).

> I see this as a sane desktop default much like having png, jpeg, etc..
> enabled.

Right, this is a valid reason for enabling it.

> Steam, games, and similar applications also come from several sources
> not necessarily managed by portage all while expecting typical GPU
> features (and png/jpeg support!) to work without having to dig in
> USE flags on a desktop profile more than necessary. It's a better
> out-of-the-box user experience.

IMHO this isn't. It is at least debatable if unpackaged proprietary
software should have any influence on our default settings.

Ulrich



Re: [gentoo-dev] [PATCH] profiles/targets/desktop: enable USE=vulkan by default

2023-05-22 Thread Ulrich Mueller
> On Sun, 21 May 2023, Sam James wrote:

> Ionen pointed this out again today and it made me look back at it;
> there's no reason to not have vulkan on by default for desktop
> profiles.

That's a non-sequitur. No reason to not have it on doesn't imply that
there is a reason to have it on.

Also, shouldn't we avoid enabling local flags in profiles?

> In particular, Steam expects it for plenty of games to work,

That's what USE dependencies are for.

Ulrich



Re: [gentoo-dev] Last rites: app-portage/g-sorcery

2023-05-19 Thread Ulrich Mueller
> On Fri, 19 May 2023, David Seifert wrote:

> # David Seifert  (2023-05-19)
> # Depends on app-portage/layman. Removal on 2023-06-18.
> app-portage/g-sorcery

> # David Seifert  (2023-05-19)
> # Depends on obsolete app-portage/g-sorcery.
> # Removal on 2023-06-18.
> app-portage/gs-elpa

app-portage/layman has been removed from app-portage/g-sorcery's
PDEPEND, therefore last rites for g-sorcery and its gs-elpa backend have
been cancelled.

Users can either use g-sorcery in standalone mode, or unmask layman.
We'll try to find a better solution before the end of layman's
last-rites period (which has been extended to 90 days).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] News Item v2: Plasma Profile to switch on PipeWire, Wayland support

2023-05-16 Thread Ulrich Mueller
> On Tue, 16 May 2023, Andreas Sturmlechner wrote:

> Title: Plasma Profile to switch on PipeWire, Wayland support
 011223344
 12345678901234567890123456789012345678901234567890123

The title is slightly too long, GLEP 42 says 50 chars maximum.

The news item seems to combine two topics which are only loosely
related, and contains a lot of information. Did you consider splitting
it into two items?

Ulrich



Re: [gentoo-dev] [PATCH v2] 2023-05-08-openssh-configuration-changes: add item

2023-05-08 Thread Ulrich Mueller
> On Mon, 08 May 2023, Matt Turner wrote:

>> > +++ 
>> > b/2023-05-08-openssh-configuration-changes/2023-05-08-openssh-configuration-changes.en.txt
>> 
>> https://www.gentoo.org/glep/glep-0042.html#news-item-identities
>> "This identifier will be in the form -mm-dd-short-name [...].
>> The short-name is a very short name describing the news item
>> (e.g. yoursql-updates) [...]. While there is no hard restriction on
>> the length of short-name, limiting it to 20 characters is strongly
>> recommended."

> But why? We're not concerned about file system limits, are we?

No, the FS limit will kick in much later.

However, eselect news may truncate identifiers whose short name is
longer than 30 chars, in situations where the identifier is shown to
users (e.g. for removed news items).

So, it's not a hard limit and nothing will really break, but there's
some incentive to keep these names concise.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] 2023-05-08-openssh-configuration-changes: add item

2023-05-08 Thread Ulrich Mueller
> On Mon, 08 May 2023, Sam James wrote:

> +++ 
> b/2023-05-08-openssh-configuration-changes/2023-05-08-openssh-configuration-changes.en.txt

https://www.gentoo.org/glep/glep-0042.html#news-item-identities
"This identifier will be in the form -mm-dd-short-name [...].
The short-name is a very short name describing the news item
(e.g. yoursql-updates) [...]. While there is no hard restriction on
the length of short-name, limiting it to 20 characters is strongly
recommended."

(This is not addressed at your news item in particular, but I observe
a tendency for the short-names to becomer longer and longer. Here,
"2023-05-08-openssh-config" or "2023-05-08-openssh" would be perfectly
fine, as it is unlikely that we will have another news item about
openssh on the same day.)

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: Does anyone still rely on the CONF_LIBDIR variable?

2023-05-05 Thread Ulrich Mueller
>>>>> On Wed, 03 May 2023, Ulrich Mueller wrote:

> I wonder about the CONF_LIBDIR variable and the implementation of the
> dolib* commands in Portage. These commands normally use the ABI and
> LIBDIR_${ABI} variables from the profile to determine the library
> directory (e.g. "lib" or "lib64").

> However, if either ABI or LIBDIR_${ABI} happens to be unset, there is a
> two-stage fallback in place, first to the value of CONF_LIBDIR, then to
> literal "lib" [1]:

>LIBDIR_VAR="LIBDIR_${ABI}"
>if [[ -n ${ABI} && -n ${!LIBDIR_VAR} ]] ; then
>CONF_LIBDIR=${!LIBDIR_VAR}
>fi
>CONF_LIBDIR=${CONF_LIBDIR:-lib}

> AFAICS the CONF_LIBDIR variable had been introduced in the 2004.3
> profile [2], but was replaced already in 2005 by the present
> LIBDIR_${ABI} mechanism [3]. CONF_LIBDIR hasn't been assigned in
> profiles ever since.

> Presently there are some relics of CONF_LIBDIR in Portage's dolib* (see
> above) , but it is not used in its econf or get_libdir functions.
> Pkgcore doesn't use CONF_LIBDIR at all. PMS defines dolib in yet another
> way [4] with an additional CONF_LIBDIR_OVERRIDE variable, which isn't
> implemented in either of the two package managers.

> Clearly this situation is not ideal, because a) dolib* and get_libdir
> are not consistent with each other, and b) PMS, Portage, and Pkgcore
> don't agree with each other.

> Before we decide on possible ways to proceed with the issue, I want to
> ask whether anyone still relies on CONF_LIBDIR for any purpose?

> There is also bug 267159 [5] with some more details.

Nobody has spoken up, therefore I believe the best way forward is to
drop the variable, as suggested in bug 267159 [5] comment #4.

I have posted a patch for PMS to gentoo-pms (unfortunately, archives
still aren't working, but <20230505161017.7487-1-...@gentoo.org> is the
Message-Id). A patch for multilib.eclass will follow later.

Ulrich

> [1] 
> https://gitweb.gentoo.org/proj/portage.git/tree/bin/ebuild-helpers/dolib?h=portage-3.0.47#n25
> [2] 
> https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=1482b856ad2a301c8eb2245a7c7265350af2691d
> [3] 
> https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=054e484d8717a18622615e019e7cd62495365192
> [4] https://projects.gentoo.org/pms/8/pms.html#x1-129001r3
> [5] https://bugs.gentoo.org/267159


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last rites: www-client/chromium-bin

2023-05-04 Thread Ulrich Mueller
> On Thu, 04 May 2023, James Le Cuirot wrote:

>> On May 4, 2023 6:38:32 PM UTC, Mike Gilbert  wrote:
>> > # Out of date by several versions. Many unresolved security
>> > # vulnerabilities. Lack of manpower/interest in keeping it up to date.
>> > # Removal on 2023-06-03.
>> > www-client/chromium-bin
>> > 
>> On Thu, 2023-05-04 at 18:59 +, Maciej Barć wrote:
>> R.i.p. to a lot od desktop users on non-state-of-the-art HW.
>> But chromium source build was unusable for long time with big UI bugs.

> Those affected can try www-client/vivaldi instead. If you're unaware, it's
> based on Chromium. It's also a binary package, I keep it well-maintained, and
> if you ask me, it's just better all round. :)

Could the mask message mention it as possible alternative?

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Does anyone still rely on the CONF_LIBDIR variable?

2023-05-03 Thread Ulrich Mueller
I wonder about the CONF_LIBDIR variable and the implementation of the
dolib* commands in Portage. These commands normally use the ABI and
LIBDIR_${ABI} variables from the profile to determine the library
directory (e.g. "lib" or "lib64").

However, if either ABI or LIBDIR_${ABI} happens to be unset, there is a
two-stage fallback in place, first to the value of CONF_LIBDIR, then to
literal "lib" [1]:

   LIBDIR_VAR="LIBDIR_${ABI}"
   if [[ -n ${ABI} && -n ${!LIBDIR_VAR} ]] ; then
   CONF_LIBDIR=${!LIBDIR_VAR}
   fi
   CONF_LIBDIR=${CONF_LIBDIR:-lib}

AFAICS the CONF_LIBDIR variable had been introduced in the 2004.3
profile [2], but was replaced already in 2005 by the present
LIBDIR_${ABI} mechanism [3]. CONF_LIBDIR hasn't been assigned in
profiles ever since.

Presently there are some relics of CONF_LIBDIR in Portage's dolib* (see
above) , but it is not used in its econf or get_libdir functions.
Pkgcore doesn't use CONF_LIBDIR at all. PMS defines dolib in yet another
way [4] with an additional CONF_LIBDIR_OVERRIDE variable, which isn't
implemented in either of the two package managers.

Clearly this situation is not ideal, because a) dolib* and get_libdir
are not consistent with each other, and b) PMS, Portage, and Pkgcore
don't agree with each other.

Before we decide on possible ways to proceed with the issue, I want to
ask whether anyone still relies on CONF_LIBDIR for any purpose?

There is also bug 267159 [5] with some more details.

Ulrich

[1] 
https://gitweb.gentoo.org/proj/portage.git/tree/bin/ebuild-helpers/dolib?h=portage-3.0.47#n25
[2] 
https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=1482b856ad2a301c8eb2245a7c7265350af2691d
[3] 
https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=054e484d8717a18622615e019e7cd62495365192
[4] https://projects.gentoo.org/pms/8/pms.html#x1-129001r3
[5] https://bugs.gentoo.org/267159


signature.asc
Description: PGP signature


[gentoo-dev] Re: [gentoo-dev-announce] Gentoo metastructure update (GLEP 39) voting now open - 7 days left

2023-05-03 Thread Ulrich Mueller
> On Wed, 03 May 2023, Michael Orlitzky wrote:

[Please keep this thread in -project.]

>> This is a friendly reminder that we're nearing (at the end of the day) 
>> the half-period for this election voting.

> My options are "yes" and "no" but there's no indication of what I'm
> saying yes/no to.

> I'd wager that "yes" means update the GLEP but I'd really rather have
> it in writing before voting.

Quoting from my original posting, Message-ID: 
(you can see it on marc.info [1], our own archives are currently down):

| Voting for the update of the Gentoo metastructure document (GLEP 39)
| is now open. The election is named "metastructure-2023".

Not sure why you think they wouldn't be clear, but the options mean:

- "yes" means that you vote for the update of the Gentoo metastructure
  document (GLEP 39).

- "no" means that you vote against it.

- "blank" means blank ballot. (And let's not start a discussion whether
  a ballot with the word "blank" on it is blank. :)

Ulrich

[1] https://marc.info/?l=gentoo-project=168232784705569=2


signature.asc
Description: PGP signature


[gentoo-dev] Re: EGO_SUM

2023-04-27 Thread Ulrich Mueller
> On Thu, 27 Apr 2023, Florian Schmaus wrote:

> Network traffic, while also being cheap, may be more of an issue.
> Currently, gentoo-latest.tar.xz is ~41 MiB. So on a conservative
> approximation ::gentoo compresses to 1/10. So, the 10 Go-packages
> cause 200 KiB of additional traffic. Even when using a low-bandwidth
> connection, say 12 KiB/s, this only adds 17 extra seconds to the
> transfer duration.

Manifest files contain binary hashes which don't compress to 1/10.
A factor of 1/2 may be more realistic (since a byte is represented by
two hex digits).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] texlive-common.eclass: add EAPI 8

2023-04-08 Thread Ulrich Mueller
> On Sat, 08 Apr 2023, Thomas Bracht Laumann Jespersen wrote:

> - [ -f "${mark}" ]
> + [[ -f "${mark}" ]]

The quotes are no longer needed in [[ ]].



  1   2   3   4   5   6   7   8   9   10   >