Re: [gentoo-dev] [PATCH 1/3] readme.gentoo-r1.eclass: works just fine with EAPI=8

2021-06-19 Thread Ulrich Mueller
See my posting 4 days ago:
https://archives.gentoo.org/gentoo-dev/message/c71621ccc96873d98697fb35c98c55b1

Merged now.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] glep-0082: New key "eapis-testing"

2021-06-18 Thread Ulrich Mueller
> On Fri, 18 Jun 2021, Michał Górny wrote:

>> +Post-History: 2021-05-19 2021-06-18

> Sorry for failing to notice it earlier but you've missed a comma between
> the dates.

Thanks. Updated locally.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()

2021-06-18 Thread Ulrich Mueller
> On Thu, 17 Jun 2021, Guilherme Amadio wrote:

> There's actually a much simpler solution to this:

> $ is_prime() { test $(factor $1 | cut -d: -f2 | wc -w) == 1; }
> $ for n in $(seq 0 10); do is_prime $n && echo $n is prime; done
> 2 is prime
> 3 is prime
> 5 is prime
> 7 is prime
> $ time factor 20187319083467888113
> 20187319083467888113: 20187319083467888113
> 0.00

This depends on the actual domain of numbers. If the primes involved
have 20 digits as in your example, then factor should be used of course.

I suspect though that we're talking about small numbers (below 100?)
here, in which case a solution in pure bash would be preferable.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] fcaps.eclass: support EAPI 8

2021-06-17 Thread Ulrich Mueller
>>>>> On Thu, 17 Jun 2021, Michał Górny wrote:

> On Thu, 2021-06-17 at 12:10 +0200, Ulrich Mueller wrote:
>> > > > > > On Thu, 17 Jun 2021, David Michael wrote:
>> 
>> > @@ -33,15 +34,12 @@ _FCAPS_ECLASS=1
>> >  
>> >  IUSE="+filecaps"
>> >  
>> > -# Since it is needed in pkg_postinst() it must be in RDEPEND
>> > +# Since it is needed in pkg_postinst() it must be in IDEPEND
>> >  case "${EAPI:-0}" in
>> > -  [0-6])
>> > -  RDEPEND="filecaps? ( sys-libs/libcap )"
>> > -  ;;
>> > -  *)
>> > -  BDEPEND="filecaps? ( sys-libs/libcap )"
>> > -  RDEPEND="${BDEPEND}"
>> > -  ;;
>> > +  7) BDEPEND="filecaps? ( sys-libs/libcap )" ;&
>> 
>> This is ill-defined in old EAPIs (5 and before), so the case statement
>> may fail. You cannot use ;& in global scope of an eclass.
>> 
>> Why not just change * to 7, and add a new case for 8? It's one
>> additional line, and IMHO would be better readable than having a
>> fallthrough.

> I've already left a comment on the PR suggesting to split it into two
> cases: one to check for valid EAPI, the other for deps.  It would be
> cleaner IMO, as the second case would cover all future EAPIs via *,
> and the first one would prevent the syntax error from applying to old
> EAPIs (I've tested that).

That would work too. But please add a comment making it clear that there
is a fallthrough.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] EAPI 8 is here!

2021-06-17 Thread Ulrich Mueller
> On Thu, 17 Jun 2021, Sam James wrote:

> EAPI 8 is here! In fact, it arrived a few days ago on Sunday:

> [...]

> Things you need to know:
> * You can read the full specification in PMS as above.
> * It's fully implemented in Portage 3.0.20, pkgcore 0.12.0, and
> pkgcheck 0.10.0.

IIUC, implementation of EAPI 8 in pkgcore is still incomplete:
https://github.com/pkgcore/pkgcore/issues/313

In general, the PMS team tracks EAPI support in package managers on this
wiki page:
https://wiki.gentoo.org/wiki/Project:PMS#Implementation_in_package_managers

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] fcaps.eclass: support EAPI 8

2021-06-17 Thread Ulrich Mueller
> On Thu, 17 Jun 2021, David Michael wrote:

> @@ -33,15 +34,12 @@ _FCAPS_ECLASS=1
>  
>  IUSE="+filecaps"
>  
> -# Since it is needed in pkg_postinst() it must be in RDEPEND
> +# Since it is needed in pkg_postinst() it must be in IDEPEND
>  case "${EAPI:-0}" in
> - [0-6])
> - RDEPEND="filecaps? ( sys-libs/libcap )"
> - ;;
> - *)
> - BDEPEND="filecaps? ( sys-libs/libcap )"
> - RDEPEND="${BDEPEND}"
> - ;;
> + 7) BDEPEND="filecaps? ( sys-libs/libcap )" ;&

This is ill-defined in old EAPIs (5 and before), so the case statement
may fail. You cannot use ;& in global scope of an eclass.

Why not just change * to 7, and add a new case for 8? It's one
additional line, and IMHO would be better readable than having a
fallthrough.

> + 6) RDEPEND="filecaps? ( sys-libs/libcap )" ;;
> + 8) IDEPEND="filecaps? ( sys-libs/libcap )" ;;
> + *) die "EAPI ${EAPI:-0} is unsupported" ;;
>  esac
>  
>  # @ECLASS-VARIABLE: FILECAPS

Ulrich


signature.asc
Description: PGP signature


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

2021-06-16 Thread Ulrich Mueller
> On Wed, 16 Jun 2021, Thomas Deutschmann wrote:

> On 2021-06-16 13:28, Michal Prívozník wrote:
>> Why should we mangle with packages this way? I mean, to me Gentoo was
>> one of the few distros that allowed real choice for users (systemd vs
>> openrc, selinux or !selinux, etc.). We shouldn't be making choices on
>> behalf of users. The best we can do is to open issues for whatever IRC
>> client we have in portage to switch from freenode to something different.
>> BTW: not everybody is switching from freenode to libera.chat.

> I second that.

> Adding *our* network is one thing, like adding branding, but removing
> stuff we don't like is going to far.

*sigh* Please read my answer again. I haven't suggested that Freenode
should be removed, but my answer was misrepresented in the message
you're replying to.

Ulrich


signature.asc
Description: PGP signature


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

2021-06-16 Thread Ulrich Mueller
> On Wed, 16 Jun 2021, Michal Prívozník wrote:

>>> 1. Should we be proactively changing the default network in IRC clients
>>> (provided they have one) from Freenode to Libera.chat
>> 
>> Yes. IMHO Freenode is no longer a reasonable default.

> Why should we mangle with packages this way? I mean, to me Gentoo was
> one of the few distros that allowed real choice for users (systemd vs
> openrc, selinux or !selinux, etc.). We shouldn't be making choices on
> behalf of users. The best we can do is to open issues for whatever IRC
> client we have in portage to switch from freenode to something
> different.

This is merely about the _default_ network, not about taking away any
choices from users.

See my answer to question 2 (which you've conveniently omitted,
therefore restoring it here):

>>> 2. Should we be proactively *removing* Freenode from the network list
>>> in IRC clients (provided they have one)?
>> 
>> No (but also don't re-add it if upstream decided to remove it).

> BTW: not everybody is switching from freenode to libera.chat.

A default is never about everybody, but about providing a good
configuration for the majority of users.

Ulrich


signature.asc
Description: PGP signature


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

2021-06-16 Thread Ulrich Mueller
> On Wed, 16 Jun 2021, Michał Górny wrote:

> We've moved our official support channels from Freenode to Libera.chat.
> All that's happened afterwards pretty much proves that this was
> the right decision.  Maybe even to the point of saying that staying
> on Freenode would be dangerous to our users (e.g. because of the late
> NickServ impersonations, ops with bad reputation etc.).

> However, there are still IRC clients in Gentoo that default to Freenode.
> I think the next questions we need to answer are:

> 1. Should we be proactively changing the default network in IRC clients
> (provided they have one) from Freenode to Libera.chat?

Yes. IMHO Freenode is no longer a reasonable default.

> 1a. If yes, then should we also make a change if clients default to
> network other than Freenode?

No.

> 2. Should we be proactively *removing* Freenode from the network list
> in IRC clients (provided they have one)?

No (but also don't re-add it if upstream decided to remove it).

> 2a. Should we be adding Libera.chat to the list even if we do not remove
> Freenode?

Yes. We have our channels there, so it is reasonable to have the network
in the list.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Update your IRC handle in LDAP

2021-05-29 Thread Ulrich Mueller
> On Sat, 29 May 2021, Toralf Förster wrote:

>> Please don't forget to update your IRC handle in LDAP.
> I'm curious where I dan see this information ?

$ ssh dev.gentoo.org
$ perl_ldap -s ${USER}


signature.asc
Description: PGP signature


[gentoo-dev] Update your IRC handle in LDAP

2021-05-29 Thread Ulrich Mueller
Please don't forget to update your IRC handle in LDAP. For example, if
you have moved from Freenode to Libera.Chat:

$ perl_ldap -b user -E gentooIM irc://irc.freenode.net/ ${USER}
$ perl_ldap -b user -C gentooIM ircs://irc.libera.chat/ ${USER}

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] EAPI 8 draft for review

2021-05-27 Thread Ulrich Mueller
The first draft of EAPI 8 has been posted to the gentoo-pms mailing
list for review:
https://archives.gentoo.org/gentoo-pms/message/e3a7c931ea369e84d81ee70d2fe9802c

> Here is the series of EAPI 8 patches for review. They include the
> pre-approved items from the 2020-11-08 Council meeting, with two
> modifications:

> - "Empty working directory in pkg_* phase functions" added
> - "Variant of || ( ) with defined runtime behaviour" dropped,
>   because the implementation is not ready

> The complete list of features is:

> - Less strict naming rules for files in updates directory
> - Bash version is 5.0
> - Selective fetch/mirror restriction
> - IDEPEND
> - Empty working directory in pkg_* phase functions
> - Different src_prepare implementation
> - PROPERTIES and RESTRICT accumulated across eclasses
> - useq banned
> - hasv and hasq banned
> - econf adds --datarootdir
> - econf adds --disable-static
> - dosym can create relative paths
> - insopts no longer affects doconfd, doenvd and doheader
> - exeopts no longer affects doinitd
> - usev supports an optional second argument
> - unpack no longer supports .7z, .rar, .lha

> The rendered version of the spec can be found:
> PDF:  https://dev.gentoo.org/~ulm/pms/8-draft/pms.pdf
> HTML: https://dev.gentoo.org/~ulm/pms/8-draft/pms.html

> Status of implementation in Portage and Pkgcore can be traced here:
> https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_8_tentative_features

> Thanks to Michał Górny for contributing patches for some of the more
> complicated features.

> Ulrich




signature.asc
Description: PGP signature


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

2021-05-14 Thread Ulrich Mueller
> On Fri, 14 May 2021, Marek Szuba wrote:

> Title: >=net-p2p/syncthing-1.17.0 to only allow TLS 1.3 for sync connections

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

> Author: Marek Szuba 
> Posted: 2021-05-18
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: net-p2p/syncthing

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

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

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


signature.asc
Description: PGP signature


Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted

2021-05-02 Thread Ulrich Mueller
> On Sun, 02 May 2021, Fabian Groffen wrote:

> Title: Exim >=4.94 disallows tainted variables in transport configurations

Title is too long (GLEP 42 allows 50 chars max).

> Author: Fabian Groffen 
> Posted: 2021-05-??
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: mail-mta/exim

> Since the release of Exim-4.94, transports refuse to use tainted data in
> constructing a delivery location.  If you use this in your transports,
> your configuration will break, causing errors and possible downtime.

> Particularly, the use of $local_part in any transport, should likely be
> updated with $local_part_data.  Check your local_delivery transport,
> which historically used $local_part.

> Unfortunately there is not much documentation on "tainted" data for
> Exim[1], and to resolve this, non-official sources need to be used, such
> as [2] and [3].

I have no idea what this news item is trying to tell me. But I don't use
Exim, so probably that's the reason. :) Maybe mention at least that Exim
is a mailer?

Ulrich

> [1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html
> [2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/
> [3] 
> https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] Transitional changes to the kernel-2 eclass to support future CPU OPT

2021-04-29 Thread Ulrich Mueller
> On Thu, 29 Apr 2021, mpagano  wrote:

> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1241,8 +1241,32 @@ unipatch() {
>   local GCC_MAJOR_VER=$(gcc-major-version)
>   local GCC_MINOR_VER=$(gcc-minor-version)
>  
> - # optimization patch for gcc < 8.X and kernel > 4.13
> - if kernel_is ge 4 13 ; then 
> + # this section should be the target state to handle the 
> cpu opt
> + # patch for kernels > 4.19.189, 5.4.115, 5.10.33 and 
> 5.11.17,
> + # 5.12.0 and gcc >= 9  The patch now handles the
> + # gcc version enabled on the system through the Kconfig 
> file as
> + # 'depends'. The legacy section can hopefully be 
> retired in the future
> + # Note the patch for 4.19-5.8 version are the same and 
> the patch for 
> + # 5.8+ version is the same
> + # eventually we can remove everything except the gcc 
> ver <9 check
> + # based on stablization, time, kernel removals or a 
> combo of all three
> + if ((kernel_is eq 4 19 && kernel_is gt 4 19 189) ||
> + (kernel_is eq 5 4 && kernel_is gt 5 4 115) ||
> + (kernel_is eq 5 10 && kernel_is gt 5 10 33) ||
> + (kernel_is eq 5 11 && kernel_is gt 5 11 17) ||
> + (kernel_is eq 5 12 && kernel_is gt 5 12 0)); 
> then

Looks like the outermost pair of parentheses ( ) isn't needed here.

Also, when writing nested parentheses without a space, bash may
sometimes (but not always!) interpret them as an arithmetic expression.
This can cause unexpected results:

   $ ((true) && (true)); echo $?
   0
   $ ( (true && true) ); echo $?
   0
   $ ((true && true)); echo $?
   1
   $ true=42
   $ ((true && true)); echo $?
   0

> [...]


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item

2021-04-29 Thread Ulrich Mueller
> On Thu, 29 Apr 2021, Michał Górny wrote:

> +Title: Python 3.9 to become the default target on 2021-06-01

Title is longer than the maximum allowed by GLEP 42 (50 chars).

> [...]

> +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared
> +in make.conf, it is strongly recommended to remove the declarations
> +and use package.use as presented above.  Use of make.conf to set flags
> +is strongly discouraged as it does not respect package defaults.

These sentences are somewhat redundant with each other, at least the
"strongly recommended" / "strongly discouraged" part.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] rebar.eclass: fix @RETURN argument

2021-04-12 Thread Ulrich Mueller
> On Mon, 12 Apr 2021, Florian Schmaus wrote:

> -# @RETURN: full path with EPREFIX to a Erlang package/project on success,
> -# code 1 when dependency is not found and code 2 if multiple versions of
> -# dependency are found.
> +# @RETURN: full path with EPREFIX to Erlang package/project on success, code 
> 1 when dependency is not found and code 2 if multiple versions of dependency 
> are found.

I think the cure is worse than the disease here.

That @RETURN is supposed to be in one line means that it should be short
(otherwise it would be read as a paragraph). Any lenghty description
belongs in @DESCRIPTION instead.

Also, the "full path" is the function's output, not its return value.

So, suggestion:
# @RETURN: 0 success, 1 dependency not found, 2 multiple versions found

(and the rest can go into @DESCRIPTION).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-07 Thread Ulrich Mueller
> On Wed, 07 Apr 2021, Michael Orlitzky wrote:

> 5) There are no clear rules about what @system packages can be left
> out of *DEPEND and when, so their presence is wildly inconsistent.

The rules are pretty clear for BDEPEND and bootstrap packages, which is
what we're talking about here.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-07 Thread Ulrich Mueller
> On Tue, 06 Apr 2021, Sam James wrote:

> 1) @system varies between profiles anyway which makes it hard to fully
> rely on;

That's exactly the reason why you _don't_* add GNU grep as a dependency,
because e.g. on Prefix grep may be provided by another package.

grep is a POSIX tool and a bootstrap package, so we can be certain that
will be available everywhere. (And the single grep instance in the
eclass doesn't use any GNUisms.)

> 2) As a few of us have discussed in #gentoo-portage in the past,
> continuing this trend of not explicitly stating dependencies makes
> parallelism in Portage difficult. You can try this with
> —implicit-system-deps=n, but we really need to be stating what we use
> explicitly.

This would mean that we'd end up with lots of system dependencies in
every ebuild. The current policy is in place for good reasons.

You may have a point for adding library dependencies explicitly, but
certainly not for common build tools (aka bootstrap packages). They will
be available from the very beginning of the bootstrap process.

> The benefit is enhanced parallelism and the downside is being
> _slightly_ more verbose in some ebuilds;

s/slightly/much/;s/some/all/

We'd end up having a significant subset of profiles/base/packages in
_every_ ebuild. Or even worse, a bunch of any-of-many dependencies or
virtuals, in order to account for different systems. Personally, I
wouldn't be willing to maintain such dependencies for my ebuilds.

More importantly, if you want such a policy change, then you should
discuss it first and have it approved. Until then, the current policy
[1] applies.

> 3) Implicit dependencies make it hard for us to ever actually swap
> implementations;

> 4) This helps when creating minimal systems without Portage in it.

[1] 
https://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-05 Thread Ulrich Mueller
> On Mon, 05 Apr 2021, Sam James wrote:
 
> + 4|5|6)
> + DEPEND="
> + sys-apps/grep
> + sys-devel/gnuconfig
> + "
> + ;;
> + 7)
> + BDEPEND="
> + sys-apps/grep

We usually don't add basic tools like grep to dependencies.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 3/5] flag-o-matic.eclass: get rid of eutils in

2021-04-01 Thread Ulrich Mueller
> On Thu, 01 Apr 2021, Andreas Sturmlechner wrote:
 
> +# @FUNCTION: test-flag-PROG
> +# @USAGE:  
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Returns shell true if  is supported by given ,
> +# else returns shell false.
>  test-flag-PROG() {
> + [[ ${EAPI} == [5-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in 
> >=EAPI-8."
> + _test-flag-PROG
> +}

Any reason why this cannot say "... in EAPI ${EAPI}." as I had suggested
earlier?

(Same for the other patches in the series.)


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: get rid of eutils in

2021-03-31 Thread Ulrich Mueller
> On Wed, 31 Mar 2021, Andreas Sturmlechner wrote:

>  setup-allowed-flags() {
> + [[ ${EAPI} == [0-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in 
> >=EAPI-8."
> + _setup-allowed-flags
> +}

Strictly speaking, EAPIs are strings, so numeric comparison is not
meaningful. Suggestion: "... is not available in EAPI ${EAPI}."

>  test-flag-PROG() {
> + [[ ${EAPI} == [0-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in 
> >=EAPI-8."
> + _test-flag-PROG
> +}

>  test-flags-PROG() {
> + [[ ${EAPI} == [0-7] ]] ||
> + die "Internal function ${FUNCNAME} is not available in 
> >=EAPI-8."
> + _test-flags-PROG
> +}

Same for these.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] developing a separate repo spec

2021-03-30 Thread Ulrich Mueller
> On Mon, 29 Mar 2021, Tim Harder wrote:

> One reason is EAPI development often moves relatively slowly and many
> potential repo spec features are probably simple enough to
> discuss/implement at a quicker pace, at least initially.

"Relatively slowly" is an understatement when it comes to repository
features. :) It is glacial for such changes, because we have to wait
for at least one year, in order not to break the upgrade path.

https://projects.gentoo.org/pms/7/pms.html#x1-320004.4 says:
"... a package manager must not attempt to use any repository whose
profiles directory requires an EAPI it does not support."

So yes, maybe we should have a separate spec for forward-compatible
repository features that are independent of EAPI. But I think that
incompatible changes won't be possible there and would have to reamin
in PMS. (For example, updating of package dependencies in profiles from
EAPI 0 to EAPI 5 was not forward compatible and required the one year
waiting period.)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] developing a separate repo spec

2021-03-29 Thread Ulrich Mueller
> On Mon, 29 Mar 2021, Tim Harder wrote:

> Is there any interest these days in developing and maintaining a
> separate repo spec [1]? Among other uses, it would help in describing
> standardized repo features related to metadata/layout.conf settings
> allowing devs to reference a single, canonical source in order to
> support repo/profiles features.

> The current spec doesn't define many repo specific features leading to
> people jamming all sorts of conditional features in metadata/layout.conf
> via profile-formats and other entries, none of which is defined in the
> current spec.

> Mostly I'm asking because I'm tired of trying to support a pseudo-spec
> and am quite close to dropping pkgcore's support for the few
> profile-formats features it tries to enable. 

Why not make it a chapter of PMS? A separate document would presumably
imply having a repository API (RAPI?) decoupled from EAPI?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

2021-03-28 Thread Ulrich Mueller
> On Sun, 28 Mar 2021, David Seifert wrote:

> This is just bringing it in line with the rest of the eclass. You know,
> consistency.

If that's the goal then the patch should update all occurences, though.
Especially those where usage is inconsistent within the same line.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs

2021-03-28 Thread Ulrich Mueller
> On Sat, 27 Mar 2021, Sam James wrote:
 
> -if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then
> +if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then

This just adds unnecessary noise to the git history. We don't have any
policy on whitespace before punctuation marks, but the examples in the
Bash manual don't have whitespace before semicolons. (Several more of
these changes in the reset of the commit.)

> - # Subdirs often share a common build dir #529404.  If so, we can't 
> safely
> + # Subdirs often share a common build dir, bug #529404.  If so, we can't 
> safely

Long line.
 
> - if [[ ${EBUILD_PHASE} != "unpack" && ${EBUILD_PHASE} != "prepare" ]]; 
> then
> - ewarn "QA Warning: running $1 in ${EBUILD_PHASE} phase"
> + if [[ ${EBUILD_PHASE_FUNC} != "src_unpack" && ${EBUILD_PHASE_FUNC} != 
> "src_prepare" ]] ; then
> + eqawarn "Running '${1}' in ${EBUILD_PHASE_FUNC} phase"

What is wrong with checking EBUILD_PHASE?

Ulrich


signature.asc
Description: PGP signature


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

2021-03-21 Thread Ulrich Mueller
> On Sun, 21 Mar 2021, Alec Warner wrote:

> https://bugs.gentoo.org/737914 seems to imply for some upstreams, it
> being a file is not a valid option anymore?

> (I'm ignoring the logic of that decision of course, but this was the
> original reason this was raised.)

Indeed, that's a strange design decision. It also violates the principle
of least surprise, because nobody will expect a symlink to behave any
different from a literal copy of the file (or even from a hardlink) when
reading it.

Ulrich


signature.asc
Description: PGP signature


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

2021-03-20 Thread Ulrich Mueller
> On Sun, 21 Mar 2021, Alec Warner wrote:

>> Which doesn't imply that we deliberately break things.

> Not sure I follow.. how is updating the handbook breaking anything?

Both configurations (regular file and symlink) work just fine, and
sys-libs/timezone-data supports them. I don't see a good reason why we
would suddenly declare the regular file to be an invalid option.

Ulrich


signature.asc
Description: PGP signature


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

2021-03-20 Thread Ulrich Mueller
> On Sat, 20 Mar 2021, William Hubbs wrote:

> /etc/localtime should definitely be a symlink to the proper file in
> /usr/share/zoneinfo.

> This works fine if /usr is on a separate partition *and* you are using
> an initramfs. The only time it doesn't work is if /usr is separate
> without using an initramfs.

> Council decided years ago that we don't support separate /usr without
> an initramfs, but we haven't completed that transition yet.

Which doesn't imply that we deliberately break things.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] aspell-dict-r1.eclass: add EAPI=7 support

2021-03-07 Thread Ulrich Mueller
> On Sun, 07 Mar 2021, conikost  wrote:
 
>  case ${EAPI:-0} in
> - [0-5])
> - die "aspell-dict-r1.eclass is banned in EAPI ${EAPI:-0}"
> + 0|1|2|3|4|5)
> + die "Unsupported EAPI=${EAPI} (obsolete) for ${ECLASS}"
>   ;;
> - 6)
> + 6|7)
>   ;;
>   *)
> - die "Unknown EAPI ${EAPI:-0}"
> + die "Unsupported EAPI=${EAPI} (obsolete) for ${ECLASS}"

Same message as above? Then the 0-5 case isn't needed.

>   ;;
>  esac


signature.asc
Description: PGP signature


Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-03 Thread Ulrich Mueller
> On Tue, 02 Mar 2021, Michael Orlitzky wrote:

>> Are you volunteering to fix all the tools to support the new format
>> correctly?

> The PMS says that KEYWORDS is whitespace-separated. Probably only
> repoman/pkgcheck would require trivial changes.

No, there are other tools as well, e.g. ekeyword and ebuild-mode.

As matter of fact, ebuild-mode accepts any ASCII whitespace characters
(horizontal tab, new line, vertical tab, form feed, carriage return,
and space) in KEYWORDS, but will change the line to its canonical format
whenever a keyword is updated. That is, in correct order and with single
spaces as separators.

BTW, do package managers allow any Unicode whitespace (like "​" ZERO
WIDTH SPACE or " " OGHAM SPACE MARK) in places where PMS says
"whitespace"?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] glep-0067: Add proxied="" attribute to distinguish proxied maints

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

> +If the attribute is not specified, the default value of ``no`` must
> +be assumed.  If at least one maintainer is listed as a proxied

Maybe "is assumed" instead of "must be assumed" here?

> +and everyone else is a proxied maintainer.  This does not account for
> +the developers without commit access that maintain packages via a proxy.

"the developers" -> "developers"


signature.asc
Description: PGP signature


Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages

2021-02-09 Thread Ulrich Mueller
> On Tue, 09 Feb 2021, Mike Gilbert wrote:

>> Mh - so the obvious first feature request for the script is to also
>> output Free UID+GID pairs. Counting them manually in your screenshot
>> I get 36.
>> 
>> That's not a whole lot; just 7% of 500.

> The output was abbreviated. Here is the full output for entries where
> both ids are FREE.

Still, it's not an infinite resource, and maybe we shouldn't waste a
pair if only one of UID or GID is needed?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving subslot-only virtuals to a separate category to reduce confusion

2021-01-31 Thread Ulrich Mueller
> On Sat, 30 Jan 2021, Michael Orlitzky wrote:

> On Sat, 2021-01-30 at 18:35 +0100, Michał Górny wrote:
>> 
>> To make this SOVERSION-virtual concept more visible and easily
>> distinguishable from regular virtuals, I'd like to propose that we
>> start
>> moving them into a dedicated category.  For example, 'lib-sover'
>> comes
>> to my mind.  While this ofc doesn't guarantee that people will do
>> things
>> right, it will at least make it clear that these packages are
>> somewhat
>> different from regular virtuals and hopefully avoid making wrong
>> assumptions.

> I would go all the way and move (say) the libjpeg provider to media-
> libs/libjpeg.

Either that, or the opposite of it, i.e. move it to something like
virtual/libjpeg-soname to make the intention clear. Whatever we would
choose, I don't think that we need a new category for this.

Also, moving these virtuals out of virtual/ would require updating
several tools. For example, tools must handle empty HOMEPAGE and
LICENSE.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 4/6] kernel-install.eclass: Improve failed install error messages

2021-01-14 Thread Ulrich Mueller
> On Wed, 13 Jan 2021, Michał Górny wrote:

>   # loop for the purpose of allowing error handling via 'break'

> Does that sound explanatory enough?

"Not an actual loop but allows error handling with 'break'"


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 4/6] kernel-install.eclass: Improve failed install error messages

2021-01-13 Thread Ulrich Mueller
> On Wed, 13 Jan 2021, Michał Górny wrote:

>> Looks like this loop can run only once, so it is redundant?

> It's the old C trick for convenient error handling.

Newfangled contraptions. What's wrong with goto? :)

> Do you have any other suggestion?  I suppose we could use a nested
> function if you think that's nicer.

No, it's fine. Maybe an explanatory comment would be helpful, because I
think that code isn't obvious.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 4/6] kernel-install.eclass: Improve failed install error messages

2021-01-13 Thread Ulrich Mueller
> On Wed, 13 Jan 2021, Michał Górny wrote:
> + local success=
> + while :; do
> + mount-boot_pkg_preinst
> +
> + local image_path=$(dist-kernel_get_image_path)
> + if use initramfs; then
> + # putting it alongside kernel image as 'initrd' makes
> + # kernel-install happier
> + nonfatal dist-kernel_build_initramfs \
> + 
> "${EROOT}/usr/src/linux-${ver}/${image_path%/*}/initrd" \
> + "${ver}" || break
> + fi
>  
> - dist-kernel_install_kernel "${ver}" \
> - "${EROOT}/usr/src/linux-${ver}/${image_path}" \
> - "${EROOT}/usr/src/linux-${ver}/System.map"
> + nonfatal dist-kernel_install_kernel "${ver}" \
> + "${EROOT}/usr/src/linux-${ver}/${image_path}" \
> + "${EROOT}/usr/src/linux-${ver}/System.map" || break
> +
> + success=1
> + break
> + done

Looks like this loop can run only once, so it is redundant?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] vala.eclass: make has_version aware of ROOT for EAPI 7

2021-01-06 Thread Ulrich Mueller
> On Thu, 07 Jan 2021, Matt Turner wrote:

> + has_version $([[ $EAPI == [1-6] ]] || echo -b) 
> "dev-lang/vala:${v}${u}" && echo "${v}" && return

> + has_version $([[ $EAPI == [1-6] ]] || echo -b) 
> "dev-lang/vala:${version}" || die "No installed vala:${version}"

Curly brackets please.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] acct-user.eclass: Support ACCT_USER_ID override

2021-01-06 Thread Ulrich Mueller
>>>>> On Wed, 06 Jan 2021, Michał Górny wrote:

> On Wed, 2021-01-06 at 14:25 +0100, Ulrich Mueller wrote:
>> I wonder about this line. Both hyphen and underscore are valid
>> characters in user names.
>> 
>> So, ACCT_USER_FOO_BAR_ID would override the id for both foo_bar and
>> foo-bar users.

> I don't think this is the problem we need to be worrying about.  I mean,
> if someone actually created user identifiers that differ only be non-
> alnum characters, I think that'd the problem to tackle.

It is legal to do that, and we already have examples for both hyphen and
underscore in acct-user package names. So the syntax should be able to
cope with it.

A simple mapping from user names (which can contain a hyphen) to
variable names (which cannot) doesn't work and IMHO also violates the
principle of least surprise.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] acct-user.eclass: Support ACCT_USER_ID override

2021-01-06 Thread Ulrich Mueller
> On Tue, 05 Jan 2021, Michał Górny wrote:

> + # check for the override
> + local override_name=${ACCT_USER_NAME^^}
> + local override_var=ACCT_USER_${override_name//-/_}_ID

I wonder about this line. Both hyphen and underscore are valid
characters in user names.

So, ACCT_USER_FOO_BAR_ID would override the id for both foo_bar and
foo-bar users.

Ulrich


signature.asc
Description: PGP signature


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

2021-01-04 Thread Ulrich Mueller
> On Mon, 04 Jan 2021, Michał Górny wrote:

> Starting 2021-02-01, Gentoo will discontinue supporting
> dev-libs/libressl as an alternative to dev-libs/openssl.  While it will

> [...]

> On 2021-02-01, we will mask the relevant USE flags and packages.  If
> you

> [...]

> necessary to use the user-maintained LibreSSL overlay [1].  As long-
> term

> [...]

> development gained speed and the original reasons for the fork no
> longer

> [...]

> problems were related to packages using old/insecure OpenSSL APIs,
> today

> [...]

> To the best of our knowledge, the only benefit LibreSSL has over
> OpenSSL

This has some strange line breaks now. Please fix.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] using markup language for eclassdoc tags

2021-01-04 Thread Ulrich Mueller
> On Mon, 04 Jan 2021, Tim Harder wrote:

> In terms of choice, I'd personally choose reStructuredText since that
> generally plugs into python easier via docutils/sphinx (currently used
> for pkgcore's man/html conversion), but am open to discussion of
> alternatives such as markdown.

About reStructuredText vs Markdown:
- ReST syntax is more complete and better standardised.
- Markdown uses HTML as extension language, which is fine when
  converting to HTML but makes conversion to other formats more
  difficult.
- Trailing whitespace as part of Markdown's syntax is problematic
  (and the current version of app-emacs/ebuild-mode removes it).
- We already use ReST for some of our documentation, like GLEPs.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] License of news items

2020-12-31 Thread Ulrich Mueller
>>>>> On Thu, 31 Dec 2020, Francisco Blas Izquierdo Riera (klondike) wrote:

> El 26/12/20 a las 10:20, Ulrich Mueller escribió:
>> This would apply retroactively since 2018-10-21 (when GLEP 76 was marked
>> as Active). I am going to file a bug for authors to acknowledge that
>> their news items can be distributed under CC-BY-SA-4.0.

> For all matters the news item I wrote in 2017 can be distributed under
> that license (and also under the GFDL if you prefer).

Thanks. Feel free to add your acknowledgment to bug 762820:
https://bugs.gentoo.org/762820

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: [gentoo-dev-announce] We are finally shutting down CVS

2020-12-27 Thread Ulrich Mueller
> On Sun, 27 Dec 2020, Max Magorsch wrote:

> To access the old repositories you can use gitweb.gentoo.org instead.
> We have migrated all old cvs repositories to git. All of them are
> available read-only now at [0].

I've just looked at
https://sources.gentoo.org/archive/cvs/gentoo.git/
and its commit history ends in 2004.

Can you please reinstate CVS until a more accurate conversion is
available?

Same applies to gentoo-x86 where the git repo misses whole categories.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] License of news items

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

> On Sat, 2020-12-26 at 10:20 +0100, Ulrich Mueller wrote:
>> Alternatively, we could add a new header line with license
>> information to the items themselves, but that would be more
>> complicated with (IMHO) little gain.

> For better consistency, we could also add a 'License' tag to the news
> items.

Yeah, but see what I had said above.

However, if the consensus is that we should have such a line, see
attached patch for GLEP 42.

Ulrich


From 51a81ad6b4d43ce9d79dbd9db4ef1ec864b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Sat, 26 Dec 2020 12:12:40 +0100
Subject: [PATCH] glep-0042: News item format 2.1 has a "License" header.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Ulrich Müller 
---
 glep-0042.rst | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/glep-0042.rst b/glep-0042.rst
index 0c40261..feb87ee 100644
--- a/glep-0042.rst
+++ b/glep-0042.rst
@@ -9,10 +9,10 @@ Type: Standards Track
 Status: Final
 Version: 4
 Created: 2005-10-31
-Last-Modified: 2019-11-07
+Last-Modified: 2020-12-26
 Post-History: 2005-11-01, 2005-11-05, 2005-11-07, 2005-12-11, 2005-12-13,
   2005-12-18, 2006-01-05, 2006-03-02, 2006-03-06, 2006-06-12,
-  2006-09-05, 2016-03-10, 2017-11-27
+  2006-09-05, 2016-03-10, 2017-11-27, 2020-12-26
 Content-Type: text/x-rst
 ---
 
@@ -231,6 +231,10 @@ The following headers describe the purpose and format of 
the news item:
 For translated news items, the translator's name and email address. 
Multiple
 translator headers may be specified if appropriate.
 
+``License:``
+Only in news item format ``2.1`` and later, where it is mandatory and must
+be ``CC-BY-SA-4.0``.
+
 ``Content-Type:``
 Only in news item format ``1.0``, where it is mandatory and must be
 ``text/plain``.
@@ -247,9 +251,9 @@ The following headers describe the purpose and format of 
the news item:
 item. Mandatory.
 
 ``News-Item-Format:``
-Known formats are ``1.0`` and ``2.0``.  Future revisions to the format
-may increment the minor number for forwards-compatible changes (i.e.,
-still allowing older tools to process the new format), or the major
+Known formats are ``1.0``, ``2.0`` and ``2.1``.  Future revisions to the
+format may increment the minor number for forwards-compatible changes
+(i.e., still allowing older tools to process the new format), or the major
 number for major changes.
 
 The following headers are used for filtering:
@@ -519,8 +523,8 @@ References
 Copyright
 =
 
-This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
-Unported License.  To view a copy of this license, visit
-https://creativecommons.org/licenses/by-sa/3.0/.
+This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+International License.  To view a copy of this license, visit
+https://creativecommons.org/licenses/by-sa/4.0/.
 
 .. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :
-- 
2.29.2


signature.asc
Description: PGP signature


[gentoo-dev] License of news items

2020-12-26 Thread Ulrich Mueller
The gentoo-news repository requires a Signed-off-by line in the commit,
while news items don't have any license information. So technically,
these commits aren't compliant with GLEP 76.

The simplest way to fix this would be adding a README file in the
top-level dir of the repository, see patch below.

This would apply retroactively since 2018-10-21 (when GLEP 76 was marked
as Active). I am going to file a bug for authors to acknowledge that
their news items can be distributed under CC-BY-SA-4.0.

Alternatively, we could add a new header line with license information
to the items themselves, but that would be more complicated with (IMHO)
little gain.

Ulrich


From 43a9e1d8c9e06bb35e7dd754bf211aa205f98dc9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Sat, 26 Dec 2020 09:59:44 +0100
Subject: [PATCH] Add README file with copyright and license information.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Ulrich Müller 
---
 README | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 README

diff --git a/README b/README
new file mode 100644
index 000..63cbead
--- /dev/null
+++ b/README
@@ -0,0 +1,7 @@
+Copyright of Gentoo news items is held by their respective authors
+and translators.
+
+All news items committed after 2018-10-21 are licensed under the
+Creative Commons Attribution-ShareAlike 4.0 International License.
+Visit https://creativecommons.org/licenses/by-sa/4.0/ to view a copy
+of this license.
-- 
2.29.2


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver

2020-12-17 Thread Ulrich Mueller
> On Thu, 17 Dec 2020, Mike Gilbert wrote:

> Doesn't the same restriction apply to relicensing it?

No, because the CC licenses have an explicit provision that allows it
when distributing a modified work (which they call an "Adaptation",
defined in section 1a).

For example, CC-BY-SA-3.0 says in section 4b:

   You may Distribute or Publicly Perform an Adaptation only under the
   terms of: (i) this License; (ii) a later version of this License with
   the same License Elements as this License; (iii) a Creative Commons
   jurisdiction license (either this or a later license version) that
   contains the same License Elements as this License (e.g.,
   Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible
   License. [...]

Item (ii) is what gives us the right to distribute under CC-BY-SA-4.0.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver

2020-12-17 Thread Ulrich Mueller
> On Thu, 17 Dec 2020, Mike Gilbert wrote:

> Should I also drop the explicit copyright notice?

>> Copyright (c) 2013-2019 by Robin Hugh Johnson, Andreas K. Hüttel,
>> Marissa Fischer, Michał Górny.

I think that a GLEP shouldn't have such a notice (after all, authors
are listed in the GLEP's header), but you cannot remove it without
permission of all authors.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] glep-0063: Add section about the Gentoo keyserver

2020-12-17 Thread Ulrich Mueller
Please also update the license of the GLEP to CC-BY-SA-4.0 [1].
See for example glep-0001.rst for the new footer.

[1] https://www.gentoo.org/glep/glep-0001.html#what-belongs-in-a-successful-glep
(item 8)


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] gnome2-utils: Drop EAPI < 5 support

2020-12-06 Thread Ulrich Mueller
> On Sun, 06 Dec 2020, Matt Turner wrote:

> -[[ ${EAPI:-0} == [012345] ]] && inherit multilib
> +[[ ${EAPI:-0} == [5] ]] && inherit multilib

Useless brackets. Also you could drop the :-0 here.

>  case "${EAPI:-0}" in

No quotes needed here.

> - 0|1|2|3|4|5|6|7) ;;
> - *) die "EAPI=${EAPI} is not supported" ;;
> + 5|6|7) ;;
> + 0|1|2|3|4) die "EAPI=${EAPI} is not supported" ;;
>  esac

This should have a * instead of an explicit list of unknown EAPIs.
 
>  case ${EAPI:-0} in
> -0|1|2|3|4|5|6)
> +5|6)
 
See above, :-0 could be dropped.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 3/4] distutils-r1.eclass: Accept distutils_enable_tests --install

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

> +# Additionally ,if --install is passed as the first parameter,

s/ ,/, /


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/4] distutils-r1.eclass: Introduce install_for_testing --via-root

2020-11-29 Thread Ulrich Mueller
> On Sun, 29 Nov 2020, Michał Górny wrote:
 
> + case ${install_method} in
> + home)
> + local add_args=(
> + install
> + --home="${TEST_DIR}"
> + --install-lib="${libdir}"
> + --install-scripts="${bindir}"
> + )
> + mkdir -p "${libdir}" || die
> + ;;
> + root)
> + local add_args=(
> + install
> + --root="${TEST_DIR}"
> + --install-lib=lib
> + --install-scripts=scripts
> + )
> + ;;
> + esac

Having the same "local add_args" declaration twice looks strange and may
be error prone. Can you move it outside of the case statement?

Also, why are the array elements at different indent levels?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] eapi8-dosym.eclass: New eclass.

2020-11-23 Thread Ulrich Mueller
> On Thu, 19 Nov 2020, Ulrich Müller wrote:

> This implements the dosym command proposed for EAPI 8 (called dosym8
> because we cannot use the same name as the package-manager builtin).

> "dosym -r  " will expand the (apparent) path of 
> relative to the (apparent) path of the directory containing .
> The main aim of this is to allow for an absolute path to be specified
> as the link target, and the function will count path components and
> convert it into a relative path.

> Since we're inside ED at this point but the image will finally be
> installed in EROOT, we don't try to resolve any pre-existing symlinks
> in  or . In other words, path expansion only looks at
> the specified apparent paths, without touching any actual files in ED
> or EROOT.

Pushed to master.

Some simple examples to demonstrate usage:

dosym8 -r /bin/foo /usr/bin/foo
- creates a relative symlink named ../../bin/foo

dosym8 -r /usr/share/doc/foo-1 "${TEXMF}"/doc/latex/foo
- creates a relative symlink named ../../../doc/foo-1
  (with TEXMF="/usr/share/texmf-site")

Enjoy!
Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] eapi8-dosym.eclass: New eclass.

2020-11-19 Thread Ulrich Mueller
> On Thu, 19 Nov 2020, Alec Warner wrote:

>> +_dosym8_canonicalize() {

> in dosym8() you save and restore IFS, but you don't here, is there a reason
> for that?

>> +   local path slash i prev out IFS=/

IFS is a local variable, so its scope ends when the function returns.
We also don't call any other function from it, so we can get away
without save/restore.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-09 Thread Ulrich Mueller
> On Mon, 09 Nov 2020, Jaco Kroon wrote:

> What is the actual "target" objective with the change?  I would have
> expected (not being one to follow this too closely):

> lib/ - arch independent stuff (eg, netifrc / dhclient etc scripts).
> lib32/ - 32-bit specific stuff (libs for 32-bit).
> lib64/ - 64-bit specific stuff (libs for 64-bit).

It is explained here:
https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout#Rationale


signature.asc
Description: PGP signature


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-11-08 23:59 UTC

2020-11-09 Thread Ulrich Mueller
> On Mon, 09 Nov 2020, Robin H Johnson wrote:

> The attached list notes all of the packages that were added or removed
> from the tree, for the week ending 2020-11-08 23:59 UTC.

> [...]

> app-editors/emacs
> 20150808-20:49 robbat2  56bd759df1d

Not really ...

This is broken for the second week in a row now. Could you suspend these
messages please, until the problem is fixed?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] selinux-policy-2.eclass: drop EAPI 5

2020-11-03 Thread Ulrich Mueller
>>>>> On Tue, 03 Nov 2020, Ulrich Mueller wrote:

> Presumably it would also be cleaner to test if POLICY_PATCH is an array,
> and use '"${POLICY_PATCH[@]}"' if it is but '${POLICY_PATCH}' if it is
> not.

In fact you could use the same code as in default src_prepare:
https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-90001r2

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] selinux-policy-2.eclass: drop EAPI 5

2020-11-03 Thread Ulrich Mueller
> On Mon, 02 Nov 2020, David Michael wrote:
 
>   for POLPATCH in ${POLICY_PATCH[@]};
>   do
> - if [[ ${EAPI:-0} == 5 ]]; then
> - epatch "${POLPATCH}"
> - else
> - eapply "${POLPATCH}"
> - fi
> + eapply "${POLPATCH}"
>   done

eapply can accept multiple parameters, so I think that a simple
'eapply ${POLICY_PATCH[@]}' would do the job.

Presumably it would also be cleaner to test if POLICY_PATCH is an array,
and use '"${POLICY_PATCH[@]}"' if it is but '${POLICY_PATCH}' if it is
not.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] selinux-policy-2.eclass: add EAPI 7

2020-11-02 Thread Ulrich Mueller
> On Mon, 02 Nov 2020, David Michael wrote:

> +if [[ ${EAPI:-0} == [56] ]]; then

Substituting 0 is not necessary here.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: [gentoo-dev-announce] Call for agenda items - Coucil meeting 2020-11-08

2020-10-26 Thread Ulrich Mueller
> On Mon, 26 Oct 2020, Georgy Yakovlev wrote:

> In 2 two weeks from now, the Council will meet again. This is
> the time to raise and prepare items that the Council should put on the
> agenda to discuss or vote on.

> Please respond to this message with agenda items. Do not hesitate to
> repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).

> The agenda for the meeting will be sent out on Sunday 2020-11-01.

> Please reply to the gentoo-project list.

Exceptionally following up also in gentoo-dev because it is a technical
topic and I think it might be of general interest. :) The list of EAPI 8
features is up for pre-approval by the Council:
https://archives.gentoo.org/gentoo-project/message/57a0eef028a9c573b367013e9898efe5

Please keep the discussion in the gentoo-project mailing list.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] eclass/waf-utils: Allow EAPI 7

2020-10-24 Thread Ulrich Mueller
> On Sat, 24 Oct 2020, Raul E Rangel wrote:

> I would like to upgrade the waf-utils.eclass to allow EAPI-7. I've
> audited the eclass code, and I didn't see anything that prevents the
> eclass from being used with EAPI-7.

> Here is the PR:
> https://github.com/gentoo/gentoo/pull/17995/commits/05d2852dc1d59f1226a463e147863c3438f337fc

I've reviewed the eclass changes in the PR.

Next time, please include the diff directly with your message to the
dev mailing list.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-23 Thread Ulrich Mueller
> On Fri, 23 Oct 2020, Aisha Tammy wrote:

> I could run these commands conditionally in postinst to make this
> an automatic upgrade for people who have 'xdm' currently installed and
> enabled in the default runlevel.

> But I really don't think that running these commands is that big an
> inconvenience.

It is more inconvenient than _not_ having to run them. IMHO that is
sufficient reason to stay away from renaming.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-23 Thread Ulrich Mueller
> On Thu, 22 Oct 2020, Aisha Tammy wrote:

> and remove 'xdm' from the default runlevel and add 'display-manager':

>   rc-update del xdm default
>   rc-update add display-manager default

So, no automatic upgrade path for users? I am asking again, what is the
rationale for renaming?

I agree that "display-manager" might be a slightly better name than
"xdm", but that's more than outweighted by the trouble that the renaming
would impose on users.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

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

> Do you really think a rename for the sake of renaming justifies
> requiring all users to rewrite their configuration?  While we're
> requiring the users to do that, wouldn't it be better to stop using
> the awful layout of 'one script to run them all', and switch to separate
> scripts for every DM?

Alternatively, don't rename the init script, in the first place.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init

2020-10-18 Thread Ulrich Mueller
> On Sun, 18 Oct 2020, Aisha Tammy wrote:

> This package provides the 'display-manager' startup script for 
> handling your chosen display manager, without being dependent on
> Xorg server.

There wasn't any consensus about renaming xdm to display-manager.

Ulrich



Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package

2020-10-10 Thread Ulrich Mueller
> On Sat, 10 Oct 2020, Aisha Tammy wrote:

> On 10/10/20 8:00 AM, Joonas Niilola wrote:
>>>  - xdm init.d is replaced by display-manager init.d script
>> 
>> Why this rename? I can't find a reason for that.
>> 
> The name change was to make it clear that its separate from xorg-server
> as it no longer has any ties to xdm.
> display-manager can be run without having xdm on your system.

Still sounds like a rename for the sake of renaming. /etc/init.d/xdm
is already now a generic init script and not tied to any specific
display manager.

Since this will affect users' systems (and maybe require manual
intervention), I think you'll need a better reason for renaming.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: EAPI conditional in eclasses (was: [PATCH v2 1/6] verify-sig.eclass: New eclass to verify OpenPGP sigs)

2020-10-07 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, William Hubbs wrote:

>> +case "${EAPI:-0}" in
>> +0|1|2|3|4|5|6)
>> +die "Unsupported EAPI=${EAPI} (obsolete) for ${ECLASS}"
>> +;;
>> +7)
>> +;;
>> +*)
>> +die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
>> +;;
>> +esac

> Does it really matter that an EAPI is unsupported because it is
> obsolete vs unknown? Can we simplify this case statement to the
> following or something similar for all of our eclasses?

> case "${EAPI:-0}" in
>   7)
>   ;;
>   *)
>   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
>   ;;
> esac

I am with you there, at least for a new eclass that never supported
these old EAPIs.

It may be somewhat useful when removing existing support for an EAPI,
but even there things should be clear from context?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-06 Thread Ulrich Mueller
>>>>> On Tue, 06 Oct 2020, Michał Górny wrote:

> On Tue, 2020-10-06 at 13:34 +0200, Ulrich Mueller wrote:
>> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
>> > On Tue, 2020-10-06 at 13:18 +0200, Ulrich Mueller wrote:
>> > > > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
>> > > > +IUSE="+verify-sig"
>> > > 
>> > > At least don't enable this by default. The feature increases
>> > > build time and has little (if any) benefits.
>> > Do you have any numbers to back this claim?
>> 
>> That's a strange question. Obviously build time can only increase if
>> you install an additional dependency and download an additional
>> distfile.

> But how significant is the increase? Can you actually measure it
> without trying hard to make things slow?

IMHO it has no benefit at all for users, because distfile integrity is
already guaranteed by digests. So this is a second and redundant method.
On the other hand, it causes download of additional distfiles which may
not be wanted by most users.

> If you are going to claim that it outweighs the 'little' benefit, you
> need to try harder than that.

No. You are the one who wants to introduce a new feature, so it's up to
you to motivate why (and how) adding a redundant method of distfile
verification would make things more secure on the users' side.

It is one thing to have this as a convenience eclass for developers
(though I still think it's over-engineered), but another thing to make
it the default for all users.

Ulrich



Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Frédéric Pierret wrote:

>> We've already discussed it in #-qa, and I still think that this is
>> over-engineered. Users can validate the distfile by the Manifest and
>> its signature, so exposing the feature to users is redundant.

> IMHO, manifest verification and distfile verification are two separate
> things. Before you validate and sign the Manifest, you need to fetch
> (new) source and to verify it. This is not redundant at all.

The eclass adds a second method of distfile verification on the user's
side. So unless the feature is intended to replace digest verification
on the long term (which I hope it isn't), it is redundant for users.

It may be fine as an opt-in feature for developers, but I believe that
enabling it by default for all users is wrong.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-06 Thread Ulrich Mueller
>>>>> On Tue, 06 Oct 2020, Michał Górny wrote:

> On Tue, 2020-10-06 at 13:18 +0200, Ulrich Mueller wrote:
>> > > > > > On Tue, 06 Oct 2020, Michał Górny wrote:
>> > +IUSE="+verify-sig"
>> 
>> At least don't enable this by default. The feature increases build time
>> and has little (if any) benefits.

> Do you have any numbers to back this claim?

That's a strange question. Obviously build time can only increase if you
install an additional dependency and download an additional distfile.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 3/5] app-crypt/openpgp-keys-miniupnp: Package keys used by miniupnp upst

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Michał Górny wrote:

> Signed-off-by: Michał Górny 
> ---
>  app-crypt/openpgp-keys-miniupnp/Manifest  |  2 ++
>  app-crypt/openpgp-keys-miniupnp/metadata.xml  |  9 
>  .../openpgp-keys-miniupnp-20201006.ebuild | 23 +++
>  3 files changed, 34 insertions(+)
>  create mode 100644 app-crypt/openpgp-keys-miniupnp/Manifest
>  create mode 100644 app-crypt/openpgp-keys-miniupnp/metadata.xml
>  create mode 100644 
> app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild

> diff --git a/app-crypt/openpgp-keys-miniupnp/Manifest 
> b/app-crypt/openpgp-keys-miniupnp/Manifest
> new file mode 100644
> index ..c8f82da42fa6
> --- /dev/null
> +++ b/app-crypt/openpgp-keys-miniupnp/Manifest
> @@ -0,0 +1,2 @@
> +DIST A31ACAAF.asc 3139 BLAKE2B 
> 4574c3f37965fafa4e2d703276a585d1f17b0da862042620681bac591062b3b70c52cbe5481da543d3c3193a640c06e9d86c3cef1568ae3a3f62901a6ad200ab
>  SHA512 
> ecad52850fdcc7c21bab81917b3cea85c48b751534427d3db5750c43cbce73916ec4879e4f5535d4b87b7eca927ad249e384c5597702a0052afa89c23c5719b9
> +DIST A5C0863C.asc 3098 BLAKE2B 
> fdbc8629fd462b9cc72c568b0af5607951055abc03a1e344e4c1b411fb87bfa285c2e29d2781f9e9b02ec0bc63eacf55e5dc19198056a417ba3358dba445cc0c
>  SHA512 
> adebff655374dbc8a045f9ab148f9fc343b043e80cb7e4e14c66aa56bfb2f0f5521e294c7600ca708893efc84679f788116d82ef5818370f1425f03dea0a77b9
> diff --git a/app-crypt/openpgp-keys-miniupnp/metadata.xml 
> b/app-crypt/openpgp-keys-miniupnp/metadata.xml
> new file mode 100644
> index ..5a5a3aaf4299
> --- /dev/null
> +++ b/app-crypt/openpgp-keys-miniupnp/metadata.xml
> @@ -0,0 +1,9 @@
> +
> +http://www.gentoo.org/dtd/metadata.dtd;>
> +
> + 
> + mgo...@gentoo.org
> + Michał Górny
> + 
> + 
> +
> diff --git 
> a/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild 
> b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> new file mode 100644
> index ..4b07eeca6024
> --- /dev/null
> +++ b/app-crypt/openpgp-keys-miniupnp/openpgp-keys-miniupnp-20201006.ebuild
> @@ -0,0 +1,23 @@
> +# Copyright 1999-2020 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +DESCRIPTION="OpenPGP keys used to sign miniupnp* packages"
> +HOMEPAGE="http://miniupnp.free.fr/files/;
> +SRC_URI="
> + http://miniupnp.free.fr/A31ACAAF.asc
> + http://miniupnp.free.fr/A5C0863C.asc
> +"
> +
> +LICENSE="public-domain"
> +SLOT="0"
> +KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv 
> s390 sparc x86"
> +
> +S=${WORKDIR}
> +
> +src_install() {
> + local files=( ${A} )
> + insinto /usr/share/openpgp-keys
> + newins - miniupnp.asc < <(cat "${files[@]/#/${DISTDIR}/}")
> +}
> -- 

> 2.28.0

This relies again on Manifest digests for the integrity of the key
distfiles themselves. What do we gain by this indirection, as compared
to validating the distfiles of the target package by their Manifest?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Michał Górny wrote:

> +IUSE="+verify-sig"

At least don't enable this by default. The feature increases build time
and has little (if any) benefits.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

2020-10-06 Thread Ulrich Mueller
> On Tue, 06 Oct 2020, Michał Górny wrote:

> verify-sig eclass provides a streamlined approach to verifying upstream
> signatures on distfiles.  Its primary purpose is to permit developers
> to easily verify signatures while bumping packages.  The eclass removes
> the risk of developer forgetting to perform the verification,
> or performing it incorrectly, e.g. due to additional keys in the local
> keyring.  It also permits users to verify the developer's work.

We've already discussed it in #-qa, and I still think that this is
over-engineered. Users can validate the distfile by the Manifest and its
signature, so exposing the feature to users is redundant.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua

2020-10-06 Thread Ulrich Mueller
> On Mon, 05 Oct 2020, Azamat Hackimov wrote:

> Currently portage is mostly lua:5.1 aware and the first thing is move
> dev-lang/lua:0 to 5.1 slot by slotmove in profiles/updates:

> slotmove dev-lang/lua 0 5.1

This would mean that slot 0 can never again be used for the package.
My advice would be to limit the version matching the slotmove, like
=dev-lang/lua-5.1* or similar.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] New acct-user/pgbouncer

2020-10-05 Thread Ulrich Mueller
> On Mon, 05 Oct 2020, Aaron W Swenson wrote:

> On 2020-10-05 10:51, Aaron W. Swenson wrote:
>> Currently we're just using -1 for pgbouncer. The user does own a
>> couple things, but that's managed by checkpath in the init script.
>> 
>> So, given that any UID will do, I'm proposing either 383 (I think
>> someone else is asking for 384) or 463.
>> 
>> Pgbouncer only needs a UID. It uses the postgres GID.
>> 
>> Which UID should we use: 383 or 463?

> And, I'm seeing my list was slightly out of date as 383 is now taken.
> So, which UID should we use: 379 or 463?

Either is fine. The guidelines recommend taking the next free one
available which would be 463.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] newsitem: k8s split packages returning

2020-10-04 Thread Ulrich Mueller
> On Sun, 04 Oct 2020, William Hubbs wrote:

>   filename="2020-10-06-kubernetes-split-packages-returning.en.txt"

GLEP 42 says: "While there is no hard restriction on the length of
short-name, limiting it to 20 characters is strongly recommended."
I don't think that "kubernetes-split-packages-returning" qualifies. :)

> display-if-installed: sys-cluster/kubernetes

Capital first letter for each word please, Display-If-Installed.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] xorg-3.eclass: Fix font IUSE=nls handling

2020-10-01 Thread Ulrich Mueller
> On Thu, 01 Oct 2020, Matt Turner wrote:

> - [[ ${PN} = font-misc-misc || ${PN} = font-schumacher-misc || ${PN##*-} 
> = 75dpi || ${PN##*-} = 100dpi || ${PN##*-} = cyrillic ]] && IUSE+=" nls"
> + case ${PN#font-} in
> + adobe-100dpi|adobe-utopia-100dpi|bh-100dpi|bh-lucidatypewriter-100dpi|\
> + adobe-75dpi |adobe-utopia-75dpi |bh-75dpi |bh-lucidatypewriter-75dpi|\
> + misc-misc|schumacher-misc)
> + IUSE+=" nls"
> + ;;
> + esac

This looks like the kind of logic that would better be moved to ebuilds.
Especially when it has just proven to be error prone.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [REVIEW v2 0/2] 2020-09-28-python-2-7-cleanup news item

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

> I've figured out a better solution than changing PYTHON_TARGETS and then
> revbumping the packages to have users upgrade (which may happen before
> they change PYTHON_TARGETS).  Instead, I'll revbump these few packages
> and remove Python 2 in new revisions.

> The majority of users will get the py2-less versions on next @world
> upgrade, and the few that need renpy, old mongodb, old kodi... will stay
> at current revision.  This involves some temporary duplication
> on version bumps but I don't think this will be major issue.

Do I understand this right, future version bumps will have two parallel
ebuild revisions (like r0 and r100) with only the lower revision
supporting Python 2.7? Tricky. :)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [REVIEW 1/2] 2020-09-28-python-2-7-cleanup: add a new news item

2020-09-27 Thread Ulrich Mueller
> On Sun, 27 Sep 2020, Michał Górny wrote:

> +Please note that the Python 2.7 interpreter (without additional Python
> +packages) remains necessary to build a few high profile packages,
> +in particular Chromium, Mozilla software and PyPy.  If you build either
> +of these packages from source, you will not be able to permanently
> +remove Python 2.7 from your software.

The last phrase sounds strange. Maybe "... from your system" instead?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] tagging deprecated eclasses internally

2020-09-26 Thread Ulrich Mueller
> On Thu, 24 Sep 2020, Tim Harder wrote:

> In short, pkgcheck (in git) now supports parsing the eclass doc format
> as specified at [1] for the gentoo repo. This enables extracting more
> info from various eclass doc annotations.

> Along those lines, pkgcheck recognizes the '@DEPRECATED:' tag for all
> eclass doc block types. At the global level, this allows deprecated
> eclasses to internally document their status inside the '@ECLASS:'
> block, note their replacement (if any), and add further information if
> necessary.  

> This allows for the hardcoded and poorly maintained eclass deprecation
> list in pkgcheck to be replaced by a dynamic version pulled from its
> eclass cache.

> If no one objects, I'd like to replace the deprecated-eclass section in
> metadata/qa-policy.conf with individual '@DEPRECATED:' annotations for
> the listed eclasses as well as adding info about the tag to the
> devmanual.

IIUC the authoritative document for eclass documentation is the
description of the format in the eclass-to-manpage.awk script, so this
would be a good start to add support for a new tag.

The devmanual only follows suit, and obviously cannot mention any tags
that aren't supported in man page conversion.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: GID assignment for gamemode

2020-09-20 Thread Ulrich Mueller
> On Sun, 20 Sep 2020, Kai Krakow wrote:

> I would like to reserve GID 37 for games-util/gamemode.

> As far as I can tell, GID 37 is free [1]

"UIDs and GIDs in range 0..100 are reserved for important system
accounts. New assignments in that range need to be explicitly approved
by the QA lead, in response to a justified request from the developer."
https://projects.gentoo.org/qa/policy-guide/user-group.html#pg0901

So please choose another GID, preferably the next free one from 499
downwards.

>>> Am Mo., 14. Okt. 2019 um 10:13 Uhr schrieb Kai Krakow 
>>> :
>>> >
>>> > I would like to reserve GID 405 for games-util/gamemode.
>>> >
>>> > As far as I can tell, GID 405 is free [1]

GID 405 is indeed free and would be a much better choice.

Ulrich



Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Ulrich Mueller
> On Wed, 16 Sep 2020, Michał Górny wrote:

> It has two advantages:

> 1. It reduces the risk of accidentally leaving it in the stable ebuild.

Huh, you mean you would remove the PROPERTIES token again, after the
version has been stabilised? Why?

Ebuilds could do conditionals like this (again, an example that would
work for app-editors/emacs):

[[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate"

> 2. It handles specifying multiple stabilization candidates on different
> branches.  I don't see how ebuilds would do that.

I don't understand. Why couldn't PROPERTIES be specified in different
slots?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] glep-0068: Add new element

2020-09-16 Thread Ulrich Mueller
> On Wed, 16 Sep 2020, Michał Górny wrote:
 
> +- one or more  elements, each containing a version
> +  constraint in the format matching EAPI 0 dependency specification
> +  with the package category and name parts omitted, e.g. ``<1.7``.

That's not a very powerful syntax, so unless I miss something,
metadata.xml would have to be updated for almost every stable candidate.

To give an example, released versions of app-editors/emacs have exactly
two numerical components, while prereleases and release candidates have
three components or are marked _rc. Both would be impossible to match
with the proposed syntax.

So IMHO this has no advantage over keeping the information in the ebuild
(e.g. as a PROPERTIES token).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/8] Split off remaining functions from eutils.eclass

2020-09-12 Thread Ulrich Mueller
> On Thu, 10 Sep 2020, Ulrich Müller wrote:

> Ulrich Müller (8):
>   eutils.eclass: Specify supported EAPIs.
>   edos2unix.eclass: New eclass, split off from eutils.
>   wrapper.eclass: New eclass, split off from eutils.
>   wrapper.eclass: Do not use emktemp.
>   l10n.eclass: Add conditional to prevent multiple inclusion.
>   l10n.eclass: strip-linguas() moved from eutils to here.
>   eutils.eclass: Deprecate emktemp().
>   eutils.eclass: Deprecate use_if_iuse().

Pushed to master, plus a deprecation warning in eutils.eclass.

There is no urgent action required, but please update your ebuilds if
they inherit eutils (especially in EAPI 7).

*** ATTENTION OVERLAY MAINTAINERS!!!11!!eleven!

eutils.eclass will eventually be removed, even though this will take
several years. So, start updating your ebuilds _now_ and don't complain
later. You have been warned.
:-)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Ulrich Mueller
> On Mon, 07 Sep 2020, Michael Orlitzky wrote:

> You're missing some context. In October of last year, a QA team member
> broke dependency resolution on a lot of systems by making the same sort
> of change that this patch proposes:

> https://archives.gentoo.org/gentoo-dev/message/64c42804eb4cf4bc7d1161a2e9222c6a

Which is very different from what this patch suggests. For example,
virtual/pam had been package masked at the time, while mgorny's patch
explicitly says that a virtual should _not_ be masked prior to its
removal.

> Last month, someone brought up that example and named the QA team as
> partly responsible for the --changed-deps requirement, which goes
> against the PMS and a council decision:

> https://archives.gentoo.org/gentoo-dev/message/dcebabbd6f13aed6622424d439f7becc

Again, very different case which had nothing to do with removal of a
virtual.

> Shortly thereafter, another QA member opened a pull request that would
> retroactively make what the first QA member did OK:

> https://github.com/gentoo/devmanual/pull/177

See my first paragraph above.

> And now, we are having a third QA team member in charge of approving
> that change to the devmanual, which will later be cited as "policy."

> Your problem is that you're not a member of the right gang.

Ad-hominem attacks won't help us here.

Ulrich



Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Ulrich Mueller
>>>>> On Mon, 07 Sep 2020, Alessandro Barbieri wrote:

> Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller  ha
> scritto:

>> We are talking about the second case here, because the dependency on the
>> virtual is being removed, while the dependency on its provider remains
>> in place (it only changes from an indirect to a direct dependency).

> That what's I've done here
> https://github.com/gentoo/gentoo/pull/13443#issuecomment-553764133 but
> you decided to make me do a revbump.
> Being consistent in decision is hard I see.

I still stand by what I said there:

| Exceptions are packages that take a long time to build, where you may
| want to use common sense and weigh the negative impact of not doing a
| revbump against build time on users' systems (and in those cases, it
| can sometimes be avoided, e.g., by delaying the change until the next
| version bump).

Also I don't see how this would be a contradiction. In your case it was
a revbump of a single ebuild with negligible build time. Here, we're
talking about removal of a virtual, which may require a rebuild of many
packages on users' systems if everything was revbumped.

Ulrich



Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Ulrich Mueller
>>>>> On Mon, 07 Sep 2020, Michael Orlitzky wrote:

> On 2020-09-07 08:10, Ulrich Mueller wrote:

>> The devmanual [1] says that a revbump should be done when a new
>> runtime dependency is added to an ebuild, but it doesn't say that for
>> removal of a dependency.

> One dependency is removed, and another is added. All completely
> besides the point that this breaks things.

Except that it doesn't, in this special case.

Ulrich



Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Ulrich Mueller
> On Mon, 07 Sep 2020, Michael Orlitzky wrote:

> On 2020-09-07 02:14, Michał Górny wrote:
>> +  
>> +Update all ebuilds not to reference the virtual. Since there is
>> +no urgent need to remove the virtual from user systems
>> +and the resulting rebuilds would be unnecessary, do not bump ebuilds
>> +when replacing the dependency.
>> +  

> This has caused dependency resolution problems in the past. The PMS
> implies a new revision,

PMS says nothing about new revisions or revision bumps:

   $ grep -i "new revision" pms/*.tex
   $ grep -i bump pms/*.tex
   $ 

> the council said make a new revision, and the devmanual already says
> make a new revision. [...]

The devmanual [1] says that a revbump should be done when a new runtime
dependency is added to an ebuild, but it doesn't say that for removal of
a dependency.

We are talking about the second case here, because the dependency on the
virtual is being removed, while the dependency on its provider remains
in place (it only changes from an indirect to a direct dependency).

Ulrich

[1] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html



Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

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

> +  
> +If the virtual is being removed along with its second to last
> +provider, include the virtual in the last-rites mail. However, please

Maybe write "any of its providers" instead of "its second to last
provider"? It is simpler and still has the same meaning.

> +do not include it in the package.mask entry as users do not need
> +to be forced to proactively unmerge it. Instead, add it
> +to package.deprecated to warn developers not to depend on it.
> +Wait the time appropriate for the last rites.
> +  


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] eutils.eclass: Use optfeature() from optfeature.eclass

2020-09-07 Thread Ulrich Mueller
>>>>> On Sun, 06 Sep 2020, David Seifert wrote:

> On Sun, 2020-09-06 at 21:49 +0200, Ulrich Mueller wrote:
>> Maybe just commit the new eclass, update ebuilds, then remove the
>> function from eutils?

> I'll get a lot of heat for breaking EAPI 2 ebuilds in some random
> abandoned overlay because we guarantee eclass API backwards
> compatibility for 20 years!

optfeature affects only elog output, so there won't be any real
breakage.

And of course, there should be some grace period (I'd suggest 30 days)
between steps 2 and 3.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] eutils.eclass: Use optfeature() from optfeature.eclass

2020-09-06 Thread Ulrich Mueller
> On Sun, 06 Sep 2020, David Seifert wrote:

> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>  # implicitly inherited (now split) eclasses
>  case ${EAPI:-0} in
>  0|1|2|3|4|5|6)
> - inherit desktop epatch estack ltprune multilib preserve-libs \
> + inherit desktop epatch estack ltprune multilib optfeature preserve-libs 
> \
>   toolchain-funcs vcs-clean
>   ;;
>  esac

I count 163 ebuilds calling optfeature in EAPI 7, but only 24 in older
EAPIs, which makes me wonder if the conditional inherit makes any sense.

Maybe just commit the new eclass, update ebuilds, then remove the
function from eutils?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH v2] env-update: create systemd env configuration if required

2020-09-03 Thread Ulrich Mueller
> On Thu, 03 Sep 2020, Florian Schmaus wrote:

> It's not really maintaining the information twice. The information is
> maintained at a single point: /etc/env.d
> And from there is is transformed by env-update already into two
> different formats:
> - /etc/profile.env
> - /etc/csh.env

> And with that change additionally into
> - /usr/lib/environment.d/gentoo-profile-env.conf

Sorry for another nitpick, but it's changing a file in /usr at runtime?
Also, does the file belong to any package, or is it an orphan?

Maybe it would be cleaner to generate the file in /etc like the others,
if necessary with a symlink in /usr/lib/environment.d? The symlink could
belong to some package, maybe even sys-apps/systemd itself.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH v2] env-update: create systemd env configuration if required

2020-09-03 Thread Ulrich Mueller
> On Thu, 03 Sep 2020, Florian Schmaus wrote:

> This commit changes env-update so that, after profile.env has was
> generated, a systemd user session environment configuration file named

> /usr/lib/environment.d/gentoo-profile-env.conf

> is created, if the directory /usr/lib/environment.d exists.

Maybe a stupid question, but can't this file just source /etc/profile?
Maintaining the same information twice doesn't look like the right thing
to do.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Enable "gui" flag in desktop profile

2020-08-27 Thread Ulrich Mueller
QA policy says that packages should use the "gui" USE flag for optional
GUI support:
https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802

IMHO this means that the "gui" flag should be enabled in desktop
profiles (similar to "X").

Any comments? If not, I'll enable it in two days from now.


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Ulrich Mueller
> On Tue, 18 Aug 2020, Michał Górny wrote:

> On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote:
>> I think this is a very good feature.
>> 
>> If I ever do become a proper Gentoo developer I will certainly not
>> spend any time on anything to do with GitHub, and in my current
>> position of occasional contributor I don't either. The workflow
>> imposed by GitHub isn't good and it's important to demonstrate other
>> methods.

> Read: it's important to slap users to satisfy developer's wannabes.

Of course anyone can use nonfree software or platforms (like Github)
to do their work, but we cannot force them to do so, neither users nor
developers.

So, if a developer rejects Github for moral or philosophical reasons
then we must accept the fact.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] profile masking

2020-08-14 Thread Ulrich Mueller
> On Fri, 14 Aug 2020, Zac Medico wrote:

> On 8/14/20 8:42 AM, Joakim Tjernlund wrote:
>> Yes, I know I can add that in profile/package.mask but I am looking
>> for the bigger picture here. This has to stop somehow, there need to
>> be something that limits the mask scope to the repo/overlay it is
>> defined.

> The scope is already limited, but this overlay inherits the mask because
> it has the gentoo repo as its master (either implicitly or via a masters
> setting in metadata/layout.conf).

> I suppose we could add an option to prevent this inheritance.

Like an option in repos.conf or layout.conf?

The problem I see with this is that preventing inheritance would disable
files like license_groups or thirdpartymirrors. So overlays would have
to maintain their own versions.

>> I think a good start would be to consider /etc/portage the top
>> profile and other subprofiles should be able to use the same features
>> as /etc/portage.
>> 
>> Portage could start supporting that now, but there would be a while
>> until one can use them in Gentoo profile.

> We've got this bug open for the ::repo atom support:

> https://bugs.gentoo.org/651208

I still believe that adding ::gentoo to every line in package.mask would
be the wrong approach to the problem.

Ulrich



Re: [gentoo-portage-dev] profile masking

2020-08-14 Thread Ulrich Mueller
> On Fri, 14 Aug 2020, Joakim Tjernlund wrote:

> When pkgs are masked in the profile, it affects all variants of that
> pkgs, even the ones that are in other overlays.
> Example:
> !!! The following installed packages are masked:
> - sys-auth/sssd-::transmode (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Matt Turner  (2020-08-13)
> # Masked for testing

> My sssd- is now masked.

> Could the profile syntax be extended to include syntax allowed in
> /etc/portage ? Then one could use the ::gentoo syntax (or so I hope)

The :: syntax is Portage specific and doesn't exist in EAPI 7.
So there's no chance to get it into the profile dir anytime soon
(because that would imply :: to be added to a future EAPI and the
top-level profile dir to be bumped to that EAPI).

You could override the mask in your overlay's profile/package.mask
instead, using an entry with the "-" operator.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Ulrich Mueller
> On Sun, 09 Aug 2020, William Hubbs wrote:

> There are roughly 100 commits in the udev master branch since the date
> of this sync:

> https://github.com/systemd/systemd/commits/master/src/udev

And what does this tell us? Commit count isn't very useful as a metric.

Do these commits fix any bugs that are still open in eudev? Do they add
any important features?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH 01/26] lib/portage/util/_desktop_entry.py: fix unused-import

2020-08-03 Thread Ulrich Mueller
> On Mon, 03 Aug 2020, Aaron Bauman wrote:

> --- a/lib/portage/util/_desktop_entry.py
> +++ b/lib/portage/util/_desktop_entry.py
> @@ -1,16 +1,13 @@
> -# Copyright 2012-2013 Gentoo Foundation
> +# Copyright 2020 Gentoo Authors

Please don't drop existing years from the range.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] media-fonts/font-misc-misc: upgrade to EAPI 7

2020-08-03 Thread Ulrich Mueller
> On Sun, 02 Aug 2020, Henrik Pihl wrote:

> +IUSE=""

> +DEPEND=""
> +RDEPEND="${DEPEND}"

These empty assignments are not necessary and should be dropped.

Ulrich


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >