[gentoo-dev] Last rites: media-gfx/jpeg2ps

2022-06-16 Thread Ulrich Mueller
# Ulrich Müller  (2022-06-16)
# Last release in 2002. The distfile cannot be redistributed
# and is no longer available upstream. Use media-gfx/imagemagick
# ("convert" with eps2 or eps3 output format) as replacement.
# Masked for removal in 30 days. Bug #851708.
media-gfx/jpeg2ps


signature.asc
Description: PGP signature


Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

2022-06-13 Thread Ulrich Mueller
> On Mon, 13 Jun 2022, Florian Schmaus wrote:

 Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
 where some voices where in agreement that EGO_SUM has its raison d'être,
 while there where no arguments in favor of eventually removing EGO_SUM,
 I hereby propose to undeprecate EGO_SUM.
 
 1: 
 https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa

>> Can this be done without requesting changes to package managers?

> What is 'this' here?

Undeprecating EGO_SUM.

> The patchset does not make changes to any package manager, just the
> go-module eclass.

> Note that this is not about finding about an alternative to dependency
> tarballs. It is just about re-allowing EGO_SUM in addition to
> dependency tarballs for packaging Go software in Gentoo.

OK. Thanks for the clarification.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Proposal to undeprecate EGO_SUM

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

> On Mon, 2022-06-13 at 09:44 +0200, Florian Schmaus wrote:
>> Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM,
>> where some voices where in agreement that EGO_SUM has its raison d'être,
>> while there where no arguments in favor of eventually removing EGO_SUM,
>> I hereby propose to undeprecate EGO_SUM.
>> 
>> 1: 
>> https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa

Can this be done without requesting changes to package managers?
Previous examples are unexporting variables because their size exceeds
the limit of the Linux kernel [2], or introduction of additional phase
functions that bypass Manifest validation [3].

> "We've been rehashing the discussion until all opposition got tired
> and stopped replying, then we claim everyone agrees".

[2] https://bugs.gentoo.org/721088
[3] https://bugs.gentoo.org/833567


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

2022-06-05 Thread Ulrich Mueller
> On Sun, 05 Jun 2022, Joonas Niilola wrote:

> www-apps/nikola

I'll take this one. Would be happy if someone wants to co-maintain it.

Ulrich


signature.asc
Description: PGP signature


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

2022-06-03 Thread Ulrich Mueller
> On Tue, 31 May 2022, Ionen Wolkens wrote:

> +# @FUNCTION: esed
> +# @USAGE: ...
> +# @DESCRIPTION:
> +# sed(1) wrapper that dies if the expression(s) did not modify any files.
> +# sed's -i/--in-place is forced, and so stdin/out cannot be used.

This sounds like a simple enough task ...

> +esed() {
> + local -i i
> +
> + if [[ ${esedexps@a} =~ a ]]; then
> + # expression must be before -- but after the rest for e.g. -E 
> to work
> + local -i pos
> + for ((pos=1; pos<=${#}; pos++)); do
> + [[ ${!pos} == -- ]] && break
> + done
> +
> + for ((i=0; i<${#esedexps[@]}; i++)); do
> + [[ ${esedexps[i]} ]] &&
> + esedexps= esed "${@:1:pos-1}" -e 
> "${esedexps[i]}" "${@:pos}"
> + done
> +
> + unset esedexps
> + return 0
> + fi
> +
> + # Roughly attempt to find files in arguments by checking if it's a
> + # readable file (aka s/// is not a file) and does not start with -
> + # (unless after --), then store contents for comparing after sed.
> + local contents=() endopts files=()
> + for ((i=1; i<=${#}; i++)); do
> + if [[ ${!i} == -- && ! -v endopts ]]; then
> + endopts=1
> + elif [[ ${!i} =~ ^(-i|--in-place)$ && ! -v endopts ]]; then
> + # detect rushed sed -i -> esed -i, -i also silently 
> breaks enewsed
> + die "passing ${!i} to ${FUNCNAME[0]} is invalid"
> + elif [[ ${!i} =~ ^(-f|--file)$ && ! -v endopts ]]; then
> + i+=1 # ignore script files
> + elif [[ ( ${!i} != -* || -v endopts ) && -f ${!i} && -r ${!i} 
> ]]; then
> + files+=( "${!i}" )
> +
> + # eval 2>/dev/null to silence \0 warnings if sed binary 
> files
> + eval 'contents+=( "$(<"${!i}")" )' 2>/dev/null \
> + || die "failed to read: ${!i}"
> + fi
> + done
> + (( ${#files[@]} )) || die "no readable files found from '${*}' 
> arguments"
> +
> + local verbose
> + [[ ${ESED_VERBOSE} ]] && type diff &>/dev/null && verbose=1
> +
> + local changed newcontents
> + if [[ -v _esed_output ]]; then
> + [[ -v verbose ]] &&
> + einfo "${FUNCNAME[0]}: sed ${*} > ${_esed_output} ..."
> +
> + sed "${@}" > "${_esed_output}" \
> + || die "failed to run: sed ${*} > ${_esed_output}"
> +
> + eval 'newcontents=$(<${_esed_output})' 2>/dev/null \
> + || die "failed to read: ${_esed_output}"
> +
> + local IFS=$'\n' # sed concats with newline even if none at EOF
> + contents=${contents[*]}
> + unset IFS
> +
> + [[ ${contents} != "${newcontents}" ]] && changed=1
> +
> + [[ -v verbose ]] &&
> + diff -u --color --label="${files[*]}" 
> --label="${_esed_output}" \
> + <(echo "${contents}") <(echo "${newcontents}")
> + else
> + [[ -v verbose ]] && einfo "${FUNCNAME[0]}: sed -i ${*} ..."
> +
> + sed -i "${@}" || die "failed to run: sed -i ${*}"
> +
> + for ((i=0; i<${#files[@]}; i++)); do
> + eval 'newcontents=$(<"${files[i]}")' 2>/dev/null \
> + || die "failed to read: ${files[i]}"
> +
> + if [[ ${contents[i]} != "${newcontents}" ]]; then
> + changed=1
> + [[ -v verbose ]] || break
> + fi
> +
> + [[ -v verbose ]] &&
> + diff -u --color --label="${files[i]}"{,} \
> + <(echo "${contents[i]}") <(echo 
> "${newcontents}")
> + done
> + fi
> +
> + [[ -v changed ]] \
> + || die "no-op: ${FUNCNAME[0]} ${*}${_esed_command:+ (from: 
> ${_esed_command})}"
> +}

... but then it's almost 100 lines of shell code, including very
convoluted parsing of parameters. The code for detection whether a
parameter is actually a file is a heuristic at best and looks rather
brittle. Also, don't use eval because it is evil.

So IMHO this isn't the right approach to the problem. If anything, make
it a simple function with well defined arguments, e.g. exactly one
expression and exactly one file, and call "sed -i" on it.

Then again, we had something similar in the past ("dosed" as a package
manager command) but later banned it for good reason.

Detection whether the file contents changed also seems complicated.
Why not compute a hash of the file before and after sed operated on it?
md5sum or even cksum should be good enough, since security isn't an
issue here.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-25 Thread Ulrich Mueller
>>>>> On Sun, 22 May 2022, Ulrich Mueller wrote:

>>>>> On Sun, 22 May 2022, Hanno Böck wrote:
>> I'm not sure about Google code.

>> While it's no longer an active site, it is still online in an
>> archived state. We maintain plenty of packages that have no active
>> upstream, and having a reference to an unmaintained previous upstream
>> which still allows downloading the code and the repo archive seems
>> like a good thing.

> The same is true for gitorious, but we have dropped those remote-ids
> from the tree nevertheless:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8fd6bd07efee4d36a1babf55d6e69c7cb4a93d4

> However, I think that your point is valid. So the basic question is
> whether we should keep dead upstreams in that list, for archival
> purposes? If the answer is yes, then consequently we should also keep
> gitorious (and maybe revert above commit?).

For gitorious, I went through all packages where that remote-id was
dropped in the above mentioned commit. These packages were either
last-rited, or moved to different hosting. So restoring gitorious in
package metadata makes no sense for either of them.

Also, https://gitorious.org/ has a security certificate that expired in
early 2019.

Unless I see any objections here, I'll drop gitorious from the XML
schema and the DTD tomorrow.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-23 Thread Ulrich Mueller
>>>>> On Sun, 22 May 2022, Ulrich Mueller wrote:

> Some of them seem to be obsolete. Presumably freshmeat, gitorious, and
> google-code should be removed? Any other removal candidates?

> Looks like SourceForge-JP was renamed to OSDN, should the file reflect
> that?

> Also, the "gentoo" remote-id was added the the DTD [2] but is missing
> from the XML schema. Presumably it should be added there, too?

Thanks for all your comments. Taking them into account, the plan is:

1. Remove all freecode and freshmeat remote-ids from the Gentoo repo:
   https://github.com/gentoo/gentoo/pull/25599 

2. Remove freecode, freshmeat, and rubyforge from the XML schema.
   We'll keep gitorious and google-code for now, because archived
   versions of them exist.

3. Add gentoo and osdn to the XML schema.

4. Update pkgcore (it bundles a local copy of metadata.xsd) and wait
   for a new release.

5. Rename all sourceforge-jp remote-ids to osdn in the Gentoo repo:
   https://github.com/ulm/gentoo/tree/remote-id-osdn
   (no PR yet because CI/pkgcheck would complain)

6. Remove sourceforce-jp from the XML schema. Sync pkgcore again.

7. Create a wiki page documenting remote-id types and their syntax.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
> On Sun, 22 May 2022, Hanno Böck wrote:

>> Some of them seem to be obsolete. Presumably freshmeat, gitorious, and
>> google-code should be removed? Any other removal candidates?

> I'm not sure about Google code.

> While it's no longer an active site, it is still online in an archived
> state. We maintain plenty of packages that have no active upstream,
> and having a reference to an unmaintained previous upstream which
> still allows downloading the code and the repo archive seems like a
> good thing.

The same is true for gitorious, but we have dropped those remote-ids
from the tree nevertheless:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f8fd6bd07efee4d36a1babf55d6e69c7cb4a93d4

However, I think that your point is valid. So the basic question is
whether we should keep dead upstreams in that list, for archival
purposes? If the answer is yes, then consequently we should also keep
gitorious (and maybe revert above commit?).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
> On Sun, 22 May 2022, Alessandro Barbieri wrote:

> How to propose new values?

I'd say, file a bug with some rationale and the proposed syntax.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
>>>>> On Sun, 22 May 2022, Ulrich Mueller wrote:

> According to the XML schema [1], the following remote-id types are
> currently allowed:

>bitbucket
>cpan
>cpan-module
>cpe
>cran
>ctan
>freecode
>freshmeat
>github
>gitlab
>gitorious
>google-code
>heptapod
>launchpad
>pear
>pecl
>pypi
>rubyforge
>rubygems
>sourceforge
>sourceforge-jp
>vim

> Some of them seem to be obsolete. Presumably freshmeat, gitorious, and
> google-code should be removed? Any other removal candidates?

I've created https://github.com/gentoo/gentoo/pull/25599 for the update
of the tree. For now, this removes freecode, freshmeat, and google.

Remote-ids gitorious and rubyforge are not (no longer?) used in the
Gentoo repository.

> Looks like SourceForge-JP was renamed to OSDN, should the file reflect
> that?

I'll push a commit for that later, but we'll have to update the XML
schema first (otherwise CI would fail).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
> On Sun, 22 May 2022, Michał Górny wrote:

> I think we should start documenting these values somewhere.  Perhaps
> in the GLEP, or maybe on some wiki page — particularly linking
> the provider in question

Wiki page sounds good. Presumably, we don't want to update the GLEP for
every change of the list.

> and documenting the value syntax.

Let's start with gentoo. :)

We have one (currently commented out) precedent in sys-kernel/genkernel
which has:
git://git.gentoo.org/proj/genkernel

This is a little verbose. I propose using github or gitlab as a
blueprint, so above would simply be "proj/genkernel".

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Upstream remote-id types in package metadata

2022-05-22 Thread Ulrich Mueller
According to the XML schema [1], the following remote-id types are
currently allowed:

   bitbucket
   cpan
   cpan-module
   cpe
   cran
   ctan
   freecode
   freshmeat
   github
   gitlab
   gitorious
   google-code
   heptapod
   launchpad
   pear
   pecl
   pypi
   rubyforge
   rubygems
   sourceforge
   sourceforge-jp
   vim

Some of them seem to be obsolete. Presumably freshmeat, gitorious, and
google-code should be removed? Any other removal candidates?

Looks like SourceForge-JP was renamed to OSDN, should the file reflect
that?

Also, the "gentoo" remote-id was added the the DTD [2] but is missing
from the XML schema. Presumably it should be added there, too?

Comments please.

Ulrich

[1] 
https://gitweb.gentoo.org/data/xml-schema.git/tree/metadata.xsd?id=e8495470d00cd9912f3d216eb576b72a0f1fc77f#n273
[2] 
https://gitweb.gentoo.org/data/dtd.git/commit/?id=f265dac730ca5299280186f1d2ec90c84aa2a848


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] qmail.eclass: remove usage of egrep

2022-05-21 Thread Ulrich Mueller
> On Sat, 21 May 2022, Rolf Eike Beer wrote:

> You can get the patches directly from git here:
> https://github.com/DerDakon/gentoo/tree/qmail-eclass

Thanks, merged.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 2/2] qmail.eclass: remove usage of egrep

2022-05-21 Thread Ulrich Mueller
> On Mon, 16 May 2022, Rolf Eike Beer wrote:

> This does not use extended regular expressions in any way. While at it change
> the way these matches are done: it's irrelevant if the entire expression is in
> the file, if there is any rule for the given IP address then do not add the 
> new
> expression.

Series LGTM. However, "git am" fails for the second patch because the
line breaks in your message are messed up:

   Applying: qmail.eclass: remove usage of egrep
   error: corrupt patch at line 17
   Patch failed at 0001 qmail.eclass: remove usage of egrep

(I believe the problem is not on my side, because I see the spurious
line breaks also in archives:
https://archives.gentoo.org/gentoo-dev/message/b34c3f96f9e4069516b1457e7b0b4904#L32
 )


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] eclass/ruby-fakegem.eclass: depend on virtual/pkgconfig

2022-05-20 Thread Ulrich Mueller
> On Fri, 20 May 2022, Florian Schmaus wrote:
>> +if [ ${#RUBY_FAKEGEM_EXTENSIONS[@]} -ge 1 ]; then
>> +BDEPEND+=" virtual/pkgconfig "
>> +fi

> Not sure if we have a policy on this,

We do. :)

https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0101
"Use bash conditions [[ ... ]] rather than POSIX-ish [ ... ] or test
builtin."

https://devmanual.gentoo.org/tools-reference/bash/index.html#single-versus-double-brackets-in-bash
"Important: The [[ ]] form is generally safer than [ ] and should be
used in all new code."

> but how about using bash's extended test syntax, i.e., [[ … ]] (which
> the eclass already uses in a few places).


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] linux-info.eclass: Documentation updates

2022-05-16 Thread Ulrich Mueller
> On Mon, 16 May 2022, Thomas Bracht Laumann Jespersen wrote:

>> +# @FUNCTION: qout
>> +# @DESCRIPTION:
>> +# qout   is a quiet call when EBUILD_PHASE
>> # should not have visible output.

> The devmanual says that @USAGE is also required for eclass functions
> [0]. This is applicable in a few cases, I'm just highlighting one
> here.

@USAGE is required if the function accepts any arguments. This is
similar to @RETURN, and is clear from the examples in [0]. For example,
jmake_src_compile at the bottom of the page doesn't have a @USAGE line.

> OTOH lots of eclass functions have left out @USAGE, and the tooling
> around html/man page generation also appears to treat it as optional.

Which is correct AFAICS.

> So it could be that the devmanual is wrong here.

> [0]: https://devmanual.gentoo.org/eclass-writing/index.html#eclass-functions


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] linux-info.eclass: Documentation updates

2022-05-15 Thread Ulrich Mueller
>>>>> On Sun, 15 May 2022, Ulrich Mueller wrote:

>>>>> On Sun, 15 May 2022, Mike Pagano wrote:
>> +# @FUNCTION: check_zlibinflate
>> +# @DESCRIPTION:
>> +# helper function to make sure a ZLIB_INFLATE configuration
>> +# has the requried symbols

> s/requried/required/

> Also, eclass-to-manpage will format won't respect the line breaks but
> format @DESCRIPTION as a paragraph,

Sorry, seems that I wasn't awake yet when writing this. The sentence
should read:

eclass-to-manpage won't respect the line breaks but will format
@DESCRIPTION as a paragraph,

> so there should be a full stop at the end of the sentence. 

>> +# See https://bugs.gentoo.org/27882
>> check_zlibinflate() {
>> if ! use kernel_linux; then
>> die "${FUNCNAME}() called on non-Linux system, please fix the ebuild"



Re: [gentoo-dev] [PATCH] linux-info.eclass: Documentation updates

2022-05-15 Thread Ulrich Mueller
> On Sun, 15 May 2022, Mike Pagano wrote:
  
> +# @FUNCTION: check_zlibinflate
> +# @DESCRIPTION:
> +# helper function to make sure a ZLIB_INFLATE configuration
> +# has the requried symbols

s/requried/required/

Also, eclass-to-manpage will format won't respect the line breaks but
format @DESCRIPTION as a paragraph, so there should be a full stop at
the end of the sentence. 

> +# See https://bugs.gentoo.org/27882
>   check_zlibinflate() {
>   if ! use kernel_linux; then
>   die "${FUNCNAME}() called on non-Linux system, please fix the 
> ebuild"


signature.asc
Description: PGP signature


Re: [gentoo-dev] License of news items

2022-05-14 Thread Ulrich Mueller
>>>>> On Sun, 08 May 2022, 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.

> Coming back to this old thread. There were no more replies, but I
> don't feel like merging this patch after such a long time, unless
> there would be more support for it.

> So, any further opinions?

No answer, therefore I am going to drop that patch.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
> On Fri, 13 May 2022, Philip Webb wrote:

>> Recently Debian has started to transition away from the "which" command.
>> [1]

> Do we take Debian as a role model ?

No, but it is additional input. Note that our own activities [2,3]
started earlier than that.

>> 'which' is a non-POSIX command which prints out the location of specified
>> executables that are in your path. Unfortunately, there are several
>> versions of the program around which are not compatible with each other.
>> We package the GNU version as sys-apps/which,
>> which is in the system set since 2004.

> If there is a GNU version, that would seem to be somewhat "official".
> Also, it's been around a long time.

It's been around at least since the 1980s but in spite of this it was
never standardised. The GNU version exists since 1999 and had its last
release in 2015.

>> Already in 2007, vapier asked developers to avoid which in ebuilds. [2]

> There well mb good reasons for the devs to do that,
> but users may have different needs or preferences.

Nobody is asking to drop the sys-apps/which package, so users can
install it if they like the command. Gentoo is about choice, so we
shouldn't force installation for everybody if the package isn't needed
in @system. (The same applies to sys-apps/less BTW, but that's a
different story.)

Ulrich

>> [1] https://lwn.net/Articles/874049/
>> [2] 
>> https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525
>> [3] https://bugs.gentoo.org/646588
>> [4] https://bugs.gentoo.org/502084


signature.asc
Description: PGP signature


Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
> On Fri, 13 May 2022, Michael Orlitzky wrote:

>> So, should we join the "which hunt", with the goal of removing
>> sys-apps/which from the system set and from stage1?

> Yes, although I would suggest "command -v" as a POSIX replacement that
> can be sent upstream. The "type" utility is also standard, but the "-p"
> flag is not, so "type -p" creates some pointless bashisms.

This depends on context. I think with bash "type -p" is the better
choice, because it simply prints the path which is machine readable
without any postprocessing.

In other posixly-correct contexts "command -v" may be the best
alternative available, indeed.

> Both are built-in to bash so there's no performance penalty in ebuilds
> either way.


signature.asc
Description: PGP signature


[gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
Recently Debian has started to transition away from the "which" command.
[1]

which is a non-POSIX command which prints out the location of specified
executables that are in your path. Unfortunately, there are several
versions of the program around which are not compatible with each other.
We package the GNU version as sys-apps/which, which is in the system set
since 2004.

Already in 2007, vapier asked developers to avoid which in ebuilds. [2]
The replacement in most circumstances is "type -p" which is a bash
builtin command.

So, should we join the "which hunt", with the goal of removing
sys-apps/which from the system set and from stage1? I think the first
step would be to identify which packages use which, and add it as an
explicit dependency. (Maybe the tinderbox could help there?) A bug for
this [3] has already been filed by mgorny some time ago.

Unfortunately, the command pops up in unexpected places, e.g. it appears
to be an (indirect) build-time dependency of systemd. [4]

Ulrich

[1] https://lwn.net/Articles/874049/
[2] 
https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525
[3] https://bugs.gentoo.org/646588
[4] https://bugs.gentoo.org/502084


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 7/7] cmake-utils.eclass: Drop @SEE which is not a documentation keyword

2022-05-10 Thread Ulrich Mueller
> On Tue, 10 May 2022, Ulrich Müller wrote:

>  eclass/cmake-utils.eclass | 1 -
>  1 file changed, 1 deletion(-)

I'm going to drop this commit, because cmake-utils is on its way out of
the tree. The rest of the series doesn't change.

Ulrich



Re: [gentoo-dev] License of news items

2022-05-07 Thread Ulrich Mueller
>>>>> On Sat, 26 Dec 2020, Ulrich Mueller wrote:

>>>>> 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.

Coming back to this old thread. There were no more replies, but I don't
feel like merging this patch after such a long time, unless there would
be more support for it.

So, any further opinions?

Note that the README file (mentioned previously in this thread) is in
place: https://gitweb.gentoo.org/data/gentoo-news.git/tree/README

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


Re: [gentoo-dev] [PATCH] java-pkg-simple.eclass: eqawarn if module-info.java is not compiled

2022-05-03 Thread Ulrich Mueller
> On Wed, 04 May 2022, Florian Schmaus wrote:
 
> + 5|6) inherit eutils ;; # eutils for eqawarn

Adding eutils in 2022 seems a little backwards. Maybe make the output
command conditional instead? Something like this:

# conditional needed in EAPIs 5 and 6
local eqawarn=eqawarn
declare -F eqawarn >/dev/null || eqawarn=ewarn
${eqawarn} ...

Alternatively, port the few remaining EAPI 5 and 6 consumers to a newer
EAPI. :)

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] New QA policy: LICENSE must not contain variables

2022-04-24 Thread Ulrich Mueller
The QA team has approved a new policy [1], effective immediately:

| LICENSE must not contain variables
|
|   PG: 0106
|   Source: QA
|   Reported: no
|
| The LICENSE variable in an ebuild must specify all the license names
| verbatim, without referring to any variables. The only exception is
| (implicit or explicit) use of LICENSE itself, i.e. appending is allowed.
|
| Rationale: since license names do not contain dynamic parts (such as
| package versions), using variables there has little advantage. On the
| other hand, variables reduce the usefulness of plain tools such as grep.

Thise policy change affects only 5 ebuilds in the Gentoo repository.
Bug 840565 [2] will be used as a tracker.

Ulrich

[1] https://projects.gentoo.org/qa/policy-guide/ebuild-format.html#pg0106
[2] https://bugs.gentoo.org/840565


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Change the stabilization request flows

2022-04-23 Thread Ulrich Mueller
> On Sat, 23 Apr 2022, Arthur Zamarin wrote:

> The first flow I want to introduce is when nattka sees a bug with
> CC-ARCHES in keyword, but not all maintainers were CC, nattka will CC
> all maintainers, drop the CC-ARCHES, and comment something a long the
> lines "wait for maintainers to ACK by adding CC-ARCHES keyword" (of
> course the text can improve).

That's not entirely fool-proof. Sometimes a maintainer's description
suggests that they shouldn't be CCed. (Maybe we need an additional tag
for this to make it machine readable?)

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: [PATCH v3 1/1] edo.eclass: add new eclass

2022-04-17 Thread Ulrich Mueller
> On Sun, 17 Apr 2022, Sam James wrote:

> --- /dev/null
> +++ b/eclass/edo.eclass
> @@ -0,0 +1,45 @@
> +# Copyright 2022 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: edo.class
> +# @MAINTAINER:
> +# QA Team 
> +# @AUTHOR:
> +# Sam James 
> +# @SUPPORTED_EAPIS: 7 8
> +# @BLURB: Convenience function to run commands verbosely and die on failure
> +# @DESCRIPTION:
> +# This eclass provides the 'edo' command, and an 'edob' variant for 
> ebegin/eend,
> +# which dies (exits) on failure and logs the command used verbosely.
> +#
> +
> +case ${EAPI:-0} in

Just ${EAPI} here, the fallback isn't necessary.

> + 7|8) ;;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
> +
> +if [[ -z ${_EDO_ECLASS} ]] ; then
> +_EDO_ECLASS=1
> +
> +# @FUNCTION: edo
> +# @USAGE:  [...]
> +# @DESCRIPTION:
> +# Executes a short 'command' with any given arguments and exits on failure 
> unless

Long line.

> +# called under 'nonfatal'.
> +edo() {
> + einfo "$@"
> + "$@" || die -n "Failed to run command: $@"
> +}
> +
> +# @FUNCTION: edob
> +# @USAGE:  [...]
> +# @DESCRIPTION:
> +# Executes 'command' with ebegin & eend with any given arguments and exits
> +# on failure unless called under 'nonfatal'.
> +edob() {
> + ebegin "Running $@"
> + "$@"
> + eend $? || die -n "Failed to run command: $@"
> +}
> +
> +fi


signature.asc
Description: PGP signature


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

2022-04-16 Thread Ulrich Mueller
> On Sat, 16 Apr 2022, Florian Schmaus wrote:

>> edobe() {

> nit: I'd personally would use 'edob', as shorter is sometimes better
> plus every begin needs an end, so no need to explicitly state that
> there is an end.

It's even more obscure as a name however. :)

>> ebegin "Running $@"
>> "$@"
>> eend $? || die -n "$@ failed"
>> return $?

> I think this return statement can be omitted since it will always be
> invoked with 0 as argument, and this is the default behavior of
> implicit function return (IIRC).

You're right, the return statement is redundant.

>> }

Ulrich


signature.asc
Description: PGP signature


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

2022-04-16 Thread Ulrich Mueller
> On Sat, 16 Apr 2022, Sam James wrote:

> +# @FUNCTION: edo

Just a remark: A similar command existed a long time ago under the
name "try". [1]

It was executed under "env" [2], should we also do that?

> +# @USAGE: command [arg1 [arg2 ...]]

 should be in angle brackets, if we follow the usual
convention. Maybe even " [arg]..."

> +# @DESCRIPTION:
> +# Executes 'command' with any given arguments and exits on failure unless
> +# called under 'nonfatal'.
> +edo() {
> + elog "$@"
> + "$@" || die -n "Failed to run command: $@ failed"
> +}

Maybe add an ebegin/eend variant?

edobe() {
ebegin "Running $@"
"$@"
eend $? || die -n "$@ failed"
return $?
}

Ulrich

[1] 
https://gitweb.gentoo.org/archive/proj/portage-cvs.git/tree/bin/ebuild.sh?id=b7c9c02ee04ae62068f8db775c1189fd796cd797#n85
[2] 
https://gitweb.gentoo.org/archive/repo/gentoo-2.git/commit/?id=e5168d05cad140ecd7e966bce3f771003e6d392b


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v5.5] vim-plugin.eclass: EAPI 8: add src_prepare

2022-04-13 Thread Ulrich Mueller
> On Thu, 14 Apr 2022, Anna Vyalkova wrote:
 
> +fi
> +
> +EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm
> +
> +# src_prepare is only exported in EAPI >= 8
> +case ${EAPI} in
> + 6|7) ;;
> + *) EXPORT_FUNCTIONS src_prepare ;;
> +esac
> +
> +if [[ ! ${_VIM_PLUGIN_ECLASS} ]]; then

> [...]
 
> -EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm

What is the rationale for moving EXPORT_FUNCTIONS? The standard nowadays
is to have it at the end of the eclass (so it's immediately clear that
inherit order will be as expected).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2022-04-13 Thread Ulrich Mueller
> On Wed, 13 Apr 2022, Dirkjan Ochtman wrote:

> I'm retiring, please consider picking up these packages:
> [...]
> app-text/rnc2rng

I can take this (presuming that you'll continue maintaining it
upstream).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] linux-info.eclass: Call ebegin, properly close with eend

2022-04-13 Thread Ulrich Mueller
> On Wed, 13 Apr 2022, Thomas Bracht Laumann Jespersen wrote:
 
> - einfo "Checking for suitable kernel configuration options..."
> + ebegin "Checking for suitable kernel configuration options..."

ebegin outputs dots by itself, so the ones in the message should be
removed.
 
>   elif [[ ${soft_errors_count} -gt 0 ]]; then
> + eend 0
>   ewarn "Please check to make sure these options are set 
> correctly."
>   ewarn "Failure to do so may cause unexpected problems."

Shouldn't this be eend 1, given that there are errors?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v4 2/9] vim-plugin.eclass: support EAPI 8

2022-04-07 Thread Ulrich Mueller
> On Thu, 07 Apr 2022, Anna Vyalkova wrote:
 
>  case ${EAPI} in
> - 6|7);;
> - *) die "EAPI ${EAPI:-0} unsupported (too old)";;
> + 6|7|8);;
> + *) die "${ECLASS}: EAPI ${EAPI:-0} unsupported (too old)";;

The "(too old)" part will look strange with EAPI 9. Just say that it's
not supported.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-06 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote:

> So I'll spell out the different possibilities:

> 1) GPG uses SHA-512. Manifest uses SHA-512 and BLAKE2b.
> 1a) Possibility: SHA-512 is broken. Result: system broken.
> 1b) Possibility: BLAKE2b is broken. Result: nothing.

> 2) GPG uses SHA-512. Manifest uses SHA-512.
> 2a) Possibility: SHA-512 is broken. Result: system broken.
> 2b) Possibility: BLAKE2b is broken. Result: nothing.

> 3) GPG uses SHA-512. Manifest uses BLAKE2b.
> 3a) Possibility: SHA-512 is broken. Result: system broken.
> 3b) Possibility: BLAKE2b is broken. Result: system broken.

> See how from a security perspective, (2) is not worse than (1), but
> (3) is worse than both (1) and (2)?

No it isn't. We can replace the top-level signature easily, but
replacing all Manifest hashes in the tree is hard (i.e. 1a and 3a are
trivial to fix, but 2a and 3b aren't).

I've said this multiple times now, so I'm out of here.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-06 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote:

> Why? Then we're dependent on two things, either of which could break,
> rather than one.

See? If either of these should happen, then we'll be happy that we still
have both hashes in our Manifest files.

OTOH, if that argument is not relavant because the probability of both
is close to zero, then (from a security POV) it doesn't matter which of
the two hashes we remove.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] vim-doc.eclass: support EAPI 8

2022-04-06 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Thomas Bracht Laumann Jespersen wrote:

> - find $d/doc -name \*.txt -type l | while read s; do
> - [[ $(readlink "$s") = $vimfiles/* ]] && rm -f "$s"
> + find ${d}/doc -name \*.txt -type l | while read s; do
> + [[ $(readlink "${s}") = $vimfiles/* ]] && rm -f "${s}"

This would profit from a "|| die" statement.

> - einfo "Removing $d"
> - rm -r "$d"
> + einfo "Removing ${d}"
> + rm -r "${d}"

Ditto.

> - if [[ -d $vimfiles/doc ]]; then
> - ln -s $vimfiles/doc/*.txt $d/doc 2>/dev/null
> + if [[ -d "${vimfiles}"/doc ]]; then
> + ln -s "${vimfiles}"/doc/*.txt "${d}/doc" 2>/dev/null

Ditto.

Ulrich



Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-05 Thread Ulrich Mueller
> On Wed, 06 Apr 2022, Jason A Donenfeld wrote:

> I think actually the argument I'm making this time might be subtly
> different from the motions that folks went through last year.
> Specifically, the idea last year was to switch to using BLAKE2b only.
> I think what the arguments I'm making now point to is switching to
> SHA2-512 only.

Still, I think that if we drop one of the hashes then we should proceed
with the original plan. That is, keep the more modern BLAKE2B (which was
a participant of the SHA-3 competition [1]) and drop the older SHA512.

Back then, we had the choice between adding SHA3_512 and BLAKE2B, and we
preferred BLAKE2B for performance reasons.

I also think that the argument about the OpenPGP signature isn't very
strong, because replacing that signature by another one using a
different hash is trivial. As I said before, replacing all Manifest
files in the tree isn't.

Ulrich

[1] https://en.wikipedia.org/wiki/NIST_hash_function_competition


signature.asc
Description: PGP signature


Re: [gentoo-dev] proposal: use only one hash function in manifest files

2022-04-05 Thread Ulrich Mueller
> On Tue, 05 Apr 2022, Jason A Donenfeld wrote:

> Huh. Something not brought up there or https://bugs.gentoo.org/784710
> is the fact that the _security_ of the system reduces to SHA-512 as
> used by our GPG signatures.

The hash algorithm would be the least of my concerns about the security
of these signatures.

IIUC, the secret signing key is stored on a machine that is connected to
the network (Infra, please correct me if I'm wrong). So there are other
more likely attack vectors than a preimage attack on a 512 bit hash
function.

Also: https://xkcd.com/538/ :)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: proposal: use only one hash function in manifest files

2022-04-05 Thread Ulrich Mueller
> On Tue, 05 Apr 2022, Jason A Donenfeld wrote:

> - GPG signatures are already over the SHA512 of the plain text, so
> they security of the system already reduces to that. By choosing
> SHA512, we don't add more risk, whilst choosing something else means
> we're in trouble if either one has a problem.

The OpenPGP signature is for the top-level Manifest only. In case there
was any trouble, it would be trivial to change the hash algorithm used
for this.

In constrast to that, updating the hashes in all Manifest files is a
huge pain in the neck. Basically, you must download all distfiles, which
is not trivial. For example, think of fetch-restricted files. (I've
helped twice with updating Manifest files, so I believe I know what I'm
talking about. :)

I think that be benefit of dropping one of the hashes would be close to
zero, especially if we would drop the faster one.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Small update to eclass documentation

2022-03-23 Thread Ulrich Mueller
Just a heads up: The @ECLASS-VARIABLE documentation tag has been renamed
to @ECLASS_VARIABLE, in order to be in line with tags like
@USER_VARIABLE, @OUTPUT_VARIABLE, and a couple more that are all written
with an underscore.

Tools and documentation have been updated already, see bug 835396 [1]
and linked pull requests for details. The current plan is to accept the
old syntax until end of the year.

See [2] for an update of eclasses in the Gentoo repository. I will merge
this as soon as the new pkgcore version is stable. (I am not attaching
the patch because it has more than 6000 lines.)

Ulrich

[1] https://bugs.gentoo.org/835396
[2] https://github.com/gentoo/gentoo/pull/24644


signature.asc
Description: PGP signature


Re: [gentoo-dev] Deprecating repoman

2022-03-19 Thread Ulrich Mueller
> On Sat, 19 Mar 2022, Zoltan Puskas wrote:

[Please don't top-post.]

> I've been using both repoman _and_ pkgcheck becasue I was not sure which
> one covers all the checks I need to make. In fact [Pull Requests
> wiki](https://wiki.gentoo.org/wiki/Project:GitHub/Pull_requests) has a
> big red warning box with the following message, and I quote:

> "CI is not an excuse not to run repoman full, at least for the packages
> being committed."

That warning box also says: "Furthermore, pkgcheck is imperfect (yet
very fast) and may fail to notice some subtle breakages (especially if
USE flag masking/forcing) is involved."

Looks like the warning was added by mgorny in 2016 [1]. Have these
issues with pkgcheck been fixed in the meantime?

Ulrich

[1] 
https://wiki.gentoo.org/index.php?title=Project%3AGitHub%2FPull_requests=revision=575482=575480


signature.asc
Description: PGP signature


Re: [gentoo-dev] Deprecating repoman

2022-03-11 Thread Ulrich Mueller
> On Thu, 10 Mar 2022, Alec Warner wrote:

> I'm not sure a news item is strictly necessary, we might just p.mask
> repoman with a link to the guide that Matt will need to write about
> how repoman is being replaced.

We should distinguish between deprecating the repoman(-only) workflow
and deprecating the repoman tool. Doing the former doesn't imply masking
and removing the repoman package, at least not while it's working and
being maintained as part of Portage.

Also, what would be the harm in having another QA tool available in
addition to pkgcheck? (Long time ago, we used to have three of them.
Does anyone remember qualudis? :)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] go-module.eclass: deprecate EGO_SUM and call ego instead of go

2022-02-27 Thread Ulrich Mueller
> On Sun, 27 Feb 2022, Ionen Wolkens wrote:

> On Sat, Feb 26, 2022 at 10:38:33PM -0600, William Hubbs wrote:
>> +# eclass.  If it doesn't, you need to also create a vendor tarball and

> Unnecessary double space.

No. It is a sentence end, so the double space is mandatory.

(The reason is that we generate manpages from eclass documentation,
so we should follow groff conventions for sentence ends.)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] db-use.eclass: add support for EAPI 8, die on unknown EAPI

2022-02-18 Thread Ulrich Mueller
> On Fri, 18 Feb 2022, Florian Schmaus wrote:

> -case "${EAPI:-0}" in
> - 0|1|2|3|4|5|6) inherit eapi7-ver multilib ;;
> - *) inherit multilib ;;
> +case ${EAPI} in
> + [56]) inherit eapi7-ver ;& # fallthrough
> + [78]) inherit multilib ;;

Please keep the 5|6) etc. syntax, because it is what is used in almost
all other eclasses. It is also more future proof, EAPI names aren't
limited to a single character.

> + *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;

Should be ${EAPI:-0} here.

>  esac

More generally, I notice that there is no eclass documentation for any
of the functions.

Also, error handling is a little strange. It outputs a lot of text, but
doesn't die on usage errors. For example:

db_ver_to_slot() {
if [ $# -ne 1 ]; then
eerror "Function db_ver_to_slot needs one argument" >&2
eerror "args given:" >&2
for f in $@
do
eerror " - \"$@\"" >&2
done
return 1
fi
...
}

Also, f isn't declared as a local variable. In fact, you won't find a
single "local" in the whole eclass.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] vala.eclass: Support EAPI 8

2022-02-16 Thread Ulrich Mueller
> On Wed, 16 Feb 2022, Mart Raudsepp wrote:

> Ühel kenal päeval, K, 16.02.2022 kell 19:39, kirjutas Ulrich Müller:
>> Function vala_src_prepare did not call eapply_user, so it could not
>> be
>> used as a stand-alone phase function but must be called explicitly.
>> Rename it to vala_setup, which can be called either from pkg_setup or
>> from src_prepare. 

> Just to clarify the reasons to drop the EXPORT - it's really about the
> fact that you can actually never use it automatically. Absolutely all
> packages that use vala.eclass need to define their own src_prepare in
> the ebuild anyways, in order to also call gnome_src_prepare,
> cmake_src_prepare, or xdg_src_prepare.
> So the exported phase had no value, as an ebuild author always needs to
> declare their own, so it's just confusing with the vala_src_prepare
> function naming from before.

I wonder if we should drop the export retroactively. EAPIs 6 and 7
require eapply_user, so if src_prepare is vala_src_prepare then it will
always result in an error.

Or am I missing something?

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Package up for grabs: dev-vcs/git-sizer

2022-02-13 Thread Ulrich Mueller
I am no longer interested in maintaining this package.
It has no open bugs, but is one release behind upstream.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Re: [gentoo-project] Call for agenda items - Council meeting on 2022-02-13

2022-02-08 Thread Ulrich Mueller
>>>>> On Wed, 09 Feb 2022, Sam James wrote:

> On Wed, 09 Feb 2022 08:18:07 +0100
> Ulrich Mueller  wrote:

>> There is no special time period for making such proposals; future EAPI
>> bugs can be filed at any time. Preferably, they should be filed early,
>> because we've had very bad experience with including last-minute
>> features. 

> Agreed on the latter point, but this doesn't mean a simple courtesy
> notice would be problematic.

> Not everyone will be aware EAPI 9 is in the works; in particular, it's
> useful for our downstreams to know and possibly suggest any improvements
> given they're not likely to be as aware of day-to-day developments in
> Gentoo, and it's useful as a final poke to notify people that if indeed
> they feel something should be in the next EAPI (or "soon"), they should
> file a bug and so on.

> I am not saying any such requests must be accepted for EAPI 9. But
> engaging with the community with a notice isn't a bad thing?

> Someone could easily think the next EAPI is years away and therefore
> feel no urgency to flesh out their (possibly very simple) idea or
> improvement.

*shrug* The item is in the Council meeting agenda which is sent to the
gentoo-dev-announce mailing list, so people should be aware?

Anyway, I am cross-posting this to -dev and I include my original
message [0] below. (Sorry for the noise; I still think this is sort of
redundant.)

Ulrich

[0] 
https://archives.gentoo.org/gentoo-project/message/7d63f1d8d52e876a9fa8374d816e7e7f

| As I had announced in the January meeting, I'd ask the Council to
| pre-approve the list of features for EAPI 9, as listed here:
|
| https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_9_tentative_features
|
| - Eclass revisions [1]
| - EAPI of profiles defaults to repository EAPI [2]
| - Allow comments in profile parent files [3]
| - econf: Ensure proper end of string in configure --help output [4]
|
| This will be an EAPI with few new features, and its motivation is mainly
| to have eclass revisions. The second and third feature will affect only
| profiles, and the fourth feature is effectively a bug fix.
|
| There were also ideas about no longer exporting A (or alternatively, any
| variables) to the ebuild environment [5], but nobody has come forward
| with a concrete proposal yet. So, IMHO it will need more discussion and
| won't be ready for EAPI 9; developers who have asked for the feature may
| consider leading that discussion. IIUC, these would be the TeX and Go
| maintainers.
|
| [1] https://bugs.gentoo.org/806592
| [2] https://bugs.gentoo.org/806181
| [3] https://bugs.gentoo.org/470094
| [4] https://bugs.gentoo.org/815169
| [5] https://bugs.gentoo.org/721088


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] texlive-common.eclass: respect EPREFIX in symlink creation

2022-01-30 Thread Ulrich Mueller
> On Mon, 31 Jan 2022, Sam James wrote:

> - dosym /etc/texmf/$(dirname ${f}).d/$(basename ${f}) 
> ${TEXMF_PATH}/${f}
> + dosym "${EPREFIX}"/etc/texmf/$(dirname ${f}).d/$(basename ${f}) 
> ${TEXMF_PATH}/${f}

Any reason why this cannot use dosym -r (or dosym8 -r in older EAPIs)?

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Closing the Lisp umbrella project

2022-01-16 Thread Ulrich Mueller
We have decided to close the Lisp umbrella project [1]. Its subprojects
Common Lisp, Scheme, and Emacs already moved to the top level.

We will keep the #gentoo-lisp IRC channel and the lisp overlay;
ownership of the latter will be changed to Common Lisp and Scheme.
(The Emacs project has always used its own overlay.)

Rationale: There is little value in having an umbrella project for Lisp
related things. The few common resources don't justify having a project.
The Lisp project neither has any members other than those inherited
from its subprojects, and there are no packages with l...@gentoo.org
as maintainer.

(As a general note, most umbrella projects seem to be a remnant of the
old CVS pages or even of GLEP 4 metaprojects [2], where projects were
organised as a hierarchical tree. In the wiki, the structure is mostly
flat, with the occasional subproject to provide additional structure.)

Ulrich

[1] https://bugs.gentoo.org/757789
[2] https://www.gentoo.org/glep/glep-0004.html#top-level-metaprojects


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 1/5] multilib-minimal.eclass: remove EAPI 5

2022-01-12 Thread Ulrich Mueller
> On Tue, 11 Jan 2022, David Seifert wrote:

> -case ${EAPI} in
> - 5|6|7|8) ;;
> +case ${EAPI:-0} in

The :- substitution isn't necessary here.
Same for the other eclasses in the patch series.

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



Re: [gentoo-dev] [PATCH 1/2] multibuild.eclass: remove dead userland_BSD

2022-01-08 Thread Ulrich Mueller
> On Sat, 08 Jan 2022, David Seifert wrote:
 
> + cp "${cp_args[@]}" "${src}"/. "${dest}"/
> + ret=${?}
> +
>   if [[ ${ret} -ne 0 ]]; then
>   die "${MULTIBUILD_VARIANT:-(unknown)}: merging image failed."
>   fi

This could be further simplified to "cp ... || die ..." (and no need to
declare ret above).


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
>>>>> On Wed, 05 Jan 2022, Sam James wrote:

>> On 5 Jan 2022, at 08:28, Ulrich Mueller  wrote:
>> 
>> Where does this number 2 GB come from? The amount of RAM strongly
>> depends on the programming language and other factors, so I don't
>> believe that there's one number that can be used for everything.
>> (If only considering C and C++ 2 GB seems to be excessive, i.e. it
>> will limit parallel build more than necessary. When linking, the number
>> may be _much_ larger.)

> This is essentially "common law" (or "common lore" if you like!) and
> is well-accepted as a good rule of thumb.

Well, if the 2 GiB was a universal constant then it would be valid for
_all_ builds, not just the random subset inheriting check-reqs.eclass.

> The number being larger doesn't really make any difference here;
> the point is to help in cases where we're pretty sure there's going
> to be a problem (only users of check-reqs.eclass, and we can
> Introduce a variable to give ~RAM per job too if needed).

Yeah, having the ebuild specify an estimate for the average memory usage
per job would be more correct.

These are all band-aids however. What we would really need are options
like GNU parallel's --memfree and --memsuspend.

> This is also about reducing the number of support queries about
> builds which failed for trivial reasons, as someone who has to handle
> quite a lot of those (until such a time as we can implement better
> detection, but this is also a generally nice UX improvement -- as
> per what Florian/flow said).

But it would defeat the YAFIYGI principle that we commonly apply. :)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
> On Wed, 05 Jan 2022, Florian Schmaus wrote:

>> That applies to all parallel builds though, not only to ebuilds
>> inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically
>> telling the user that the --jobs setting in their make.conf is wrong,
>> in the first place.

> Yes, exactly. And it is a bandaid solution. But I believe that it will
> do more good than evil. And it is probably only used until portage is 
> able to report to the user that the emerge failed due to OOM (which I
> believe to be non-trivial to implement, but I am happy to be proven 
> otherwise).

Obviously I disagree. Tweaking the value for a subset of packages isn't
a solution to the problem.

MAKEOPTS applies to all parallel builds, and users should set it to a
value suitable for their system (i.e. number of CPUs, available memory,
etc.). Maybe our documentation needs to be improved? I see that
make.conf.example says "The suggested number for parallel makes is
CPUs+1" which may not be the best possible advice.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
>>>>> On Wed, 05 Jan 2022, Florian Schmaus wrote:

> On 05/01/2022 09.28, Ulrich Mueller wrote:
>>>>>>> On Tue, 04 Jan 2022, Sam James wrote:
>>> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
>>> amount of RAM available (uses amount declared as needed
>>> in the ebuild). Typically should be ~2GB per job.
>> Where does this number 2 GB come from? The amount of RAM strongly
>> depends on the programming language and other factors, so I don't
>> believe that there's one number that can be used for everything.

> Surely not, but 2 GiB seems like a good start. I guess it could become
> an eclass variable that ebuilds could modify later (if the need
> emerges).

We already have an eclass variable, namely CHECKREQS_MEMORY. Do you want
to introduce another one that is counting memory per job? I doubt that
would be possible, because the amount of memory greatly varies within a
single build. For example, it is different for compiler vs linker vs
building the documentation.

> It appears to me that the motivation for this change is to prevent
> users from running into OOM situations when emerging a package. And I
> believe that many users, especially novices, are not directly able to
> determine that portage failed due to OOM, simply because there is no
> direct hint in the build log. Hence opt-out appears to be sensible to
> me here.

That applies to all parallel builds though, not only to ebuilds
inheriting check-reqs.eclass. By tweaking MAKEOPTS, we're basically
telling the user that the --jobs setting in their make.conf is wrong,
in the first place.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] check-reqs.eclass: clamp MAKEOPTS for memory/RAM usage

2022-01-05 Thread Ulrich Mueller
> On Tue, 04 Jan 2022, Sam James wrote:

> Crank down MAKEOPTS jobs if MAKEOPTS="-jN" is too high for the
> amount of RAM available (uses amount declared as needed
> in the ebuild). Typically should be ~2GB per job.

Where does this number 2 GB come from? The amount of RAM strongly
depends on the programming language and other factors, so I don't
believe that there's one number that can be used for everything.
(If only considering C and C++ 2 GB seems to be excessive, i.e. it
will limit parallel build more than necessary. When linking, the number
may be _much_ larger.)

Also not sure if I understand the arithmetic. Shouldn't it use
CHECKREQS_MEMORY as the basis of the calculation?

> +# @ECLASS-VARIABLE: CHECKREQS_MEMORY_MANGLE_JOBS
> +# @USER_VARIABLE
> +# @DESCRIPTION:
> +# Allow packages to reduce the number of multiprocessing (e.g. make, ninja) 
> jobs
> +# to lower memory usage.
> +: ${CHECKREQS_MEMORY_MANGLE_JOBS=yes}

If anything, the feature should be opt-in rather than opt-out.

Ulrich



Re: [gentoo-dev] [RFC] New category: net-servers

2021-12-19 Thread Ulrich Mueller
> On Mon, 20 Dec 2021, Jonas Stein wrote:

>> I've been packaging some Gemini protocol servers and clients in ::guru
>> overlay, and they all go to net-misc category. I think it would be
>> better to split browsers and servers for non-www protocols (like Finger,
>> Ident, Gemini and Gopher) into separate categories.

> all servers without www servers means, we should move
> ssh, imap, pop, mysql... there too

I tend to disagree. Anything specific should stay in its category, e.g.
FTP servers in net-ftp, IRC servers in net-irc.

> I think we need a more precise definition if we do not want this.

I wonder if "servers" is a good category, in the first place. A server
can be for anything.

Ulrich



Re: [gentoo-dev] Printer drivers and net-print

2021-12-19 Thread Ulrich Mueller
> On Sat, 18 Dec 2021, Joshua Kinard wrote:

> Maybe consider three new top-level categories?:
>   - print-drivers
>   - print-filters
>   - print-misc

net-print is already a small category with only 35 packages, so IMHO
splitting it up into three tiny categories wouldn't make much sense.

Also, splitting cups components between different categories looks a
little artificial.

> [...]

> Idea behind a new top-level print-* group of categories is that printing is
> a fairly large ecosystem, and lumping it all into something like media-print
> or sys-print seems to miss the mark a bit.  media-* seems more aligned to
> things like sound, video, and graphics (the digital kind), and less about
> print media.  sys-print implies the system-level connections that a printer
> has, and would be a good fit for all of the printer driver packages, but not
> as good a fit for things like net-print/poster.

Can we please keep things simple and just do a full category move [1]
from net-print to (e.g.) media-print?

Ulrich

[1] 
https://archives.gentoo.org/gentoo-dev/message/2479de62249646b84932ab2801914ccc



Re: [gentoo-dev] Printer drivers and net-print

2021-12-17 Thread Ulrich Mueller
> On Fri, 17 Dec 2021, Andreas Sturmlechner wrote:

> On Montag, 20. Februar 2017 22:47:17 CET Andreas K. Huettel wrote:
>> 1) Putting printer drivers into "net-print" is silly.
>> 
>> Something that converts format a to device-specific format b has absolutely
>> nothing to do with network.
>> So, a new category "sys-print", emphasizing that it's hardware drivers, (or
>> "cups-drv"?) (or maybe "media-print"?) might make sense.
>> 
>> 2) After introducing that, however, "net-print" becomes nearly empty.
>> 
>> On a quick glance, the only *network*-specific packages in there are cups
>> and lprng. Maybe one or two more which I dont recognize.

Historically these were the first two packages in the net-print
category. Looks like it has grown from there, with later packages not
really fitting the category's definition.

>> So move cups and lprng to "net-misc" and drop "net-print"?
>> Or move them to new "sys-print" as well?
>> 
>> What do you think?

> I would like to resume this discussion on the occasion of a new [shameless 
> plug] package PAPPL that is to be packaged, see also [1], from the point 
> before discussion went off on an X-Y categories tangent.

> Here's a list of suggestions made for a new category so far, ordered from 
> (seemingly) best- to least-liked:

> media-print
> sys-print
> app-print(ing)

media-print sounds good. media-gfx would be another possibility.
Scanning software like sane is already there.

Or we could find an umbrella term for printing and scanning, and move
both to that category.

> I agree net-print should not remain after such a move.

+1

> [1] https://bugs.gentoo.org/829351


signature.asc
Description: PGP signature


Re: [gentoo-dev] Package up for grabs: app-misc/pdfpc

2021-12-15 Thread Ulrich Mueller
> On Wed, 15 Dec 2021, Nils Freydank wrote:

> pdfpc is a nice presentation tool to show PDFs and a presenter screen with
> notes etc[1].

> With version 4.5.0 upstream startet to use webkit-gtk and has no intention
> to make this optional[2]. I use a Qt-based desktop, have no interest to build
> another browser engine for a single tool and didn't use pdfpc in over a year
> (only tested it to verify that it's still working). Therefor I step down as
> it's proxied maintainer.

> The only open bug right now is a stabilization request[3]. Releases are not
> often (in the order of one or two per year).

I am actively using this. So, I'll take it unless someone else wants to
maintain it. (Co-maintainers are also welcome.)

Ulrich

> [1] https://packages.gentoo.org/packages/app-misc/pdfpc
> [2] https://github.com/pdfpc/pdfpc/issues/62
> [3] https://bugs.gentoo.org/828333


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] eclass/dune.eclass: fix dune-install function

2021-12-09 Thread Ulrich Mueller
>>>>> On Fri, 10 Dec 2021, Ulrich Mueller wrote:

> I'd write something like this:

>   local -a pkgs=("$@")
>   [[ ${#pkgs[@]} -eq 0 ]] && pkgs=(${DUNE_PKG_NAME})

Looks like I'm not immune against missing quotes either. :/
The line should read:

[[ ${#pkgs[@]} -eq 0 ]] && pkgs=("${DUNE_PKG_NAME}")

> And the loop like this (note the double quotes to be whitespace-safe):

>   for pkg in "${pkgs[@]}"; do
>   ...
>   done


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] eclass/dune.eclass: fix dune-install function

2021-12-09 Thread Ulrich Mueller
> On Thu, 09 Dec 2021, Maciej Barć wrote:

>  dune-install() {
> + local pkgs
> + if [[ -n "${@}" ]] ; then
> + pkgs="${@}"

Here pkgs is a scalar ...

> + else
> + pkgs=${DUNE_PKG_NAME}
> + fi
> +
> + local myduneopts=(
> + --prefix="${ED%/}/usr"
> + --libdir="${D%/}$(ocamlc -where)"
> + --mandir="${ED%/}/usr/share/man"
> + )
>   local pkg
> - for pkg ; do
> - dune install \
> - --prefix="${ED%/}/usr" \
> - --libdir="${D%/}$(ocamlc -where)" \
> - --mandir="${ED%/}/usr/share/man" \
> - "${pkg}" || die
> + for pkg in ${pkgs[@]} ; do

... and here it's an array?

> + dune install ${myduneopts[@]} ${pkg} || die
> +
> + # Move docs to the appropriate place.
> + if [ -d "${ED%/}/usr/doc/${pkg}" ] ; then
> + mkdir -p "${ED%/}/usr/share/doc/${PF}/" || die
> + mv "${ED%/}/usr/doc/${pkg}" 
> "${ED%/}/usr/share/doc/${PF}/" || die
> + rm -rf "${ED%/}/usr/doc" || die
> + fi
>   done
>  }

I'd write something like this:

local -a pkgs=("$@")
[[ ${#pkgs[@]} -eq 0 ]] && pkgs=(${DUNE_PKG_NAME})

And the loop like this (note the double quotes to be whitespace-safe):

for pkg in "${pkgs[@]}"; do
...
done

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] eclass/dune.eclass: fixes

2021-12-08 Thread Ulrich Mueller
> On Thu, 09 Dec 2021, Maciej Barć wrote:

>  dune-install() {
> + local pkgs
> + if [[ -n "${@}" ]] ; then
> + pkgs="${@}"
> + else
> + pkgs=${DUNE_PKG_NAME}
> + fi
> +
> + local myduneopts=(
> + --prefix="${ED%/}/usr"
> + --libdir="${D%/}$(ocamlc -where)"
> + --mandir="${ED%/}/usr/share/man"
> + )
>   local pkg
> - for pkg ; do
> - dune install \
> - --prefix="${ED%/}/usr" \
> - --libdir="${D%/}$(ocamlc -where)" \
> - --mandir="${ED%/}/usr/share/man" \
> - "${pkg}" || die
> + for pkg in "${pkgs}" ; do
> + dune install ${myduneopts[@]} ${pkg} || die
>   done
>  }

Have you tested this?

IIUC, the space separated list of arguments is assigned to pkgs, with
a fallback to ${DUNE_PKG_NAME}. The 'for pkg in "${pkgs}"' loop isn't
actually a loop because ${pkgs} is inside double quotes, so it will be
executed only once with pkg being equal to pkgs.

The previous logic (simple 'for pkg' which will loop over $@) was
correct but of course without the fallback.

> +dune_src_install() {
> + dune-install ${1:-${DUNE_PKG_NAME}}
> +}

Do you even need the fallback in dune_install() if you have it here too?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-30 Thread Ulrich Mueller
>>>>> On Tue, 30 Nov 2021, James Cloos wrote:

>>>>> "UM" == Ulrich Mueller  writes:
UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.

> why do you thing gentoo is everyone's first or only dist on their
> network?

> or even on any given box?

I was specifically asking about Gentoo infra there.

> forcing existing boxen to change just because a new dist is added
> is also unacceptable.

> for me though, it would be enough if there is something i can add to
> make.conf to ensure that the acct-user and acct-group builds avoid the
> ranges i already use.

> that may also work for others.

UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always
used for dynamic allocation of system accounts. GLEP 81 hasn't really
changed anything there, except that the ebuild will now suggest an ID to
try first.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-29 Thread Ulrich Mueller
> On Mon, 29 Nov 2021, Alec Warner wrote:

> - If Gentoo adds an acct-user/foo user, and that user already exists
> on my system with the wrong UID: the eclass dies[0].

I don't think that's correct. The eclass will just use the already
existing UID then (except for the very few acct-user packages that
define ACCT_USER_ENFORCE_ID).

> - If Gentoo adds an acct-user/foo user, with uid=12345, and that uid
> is assigned to a user on my system already, the eclass dies.

Similar to above, the eclass will dynamically allocate another UID that
is free.

> - Some environments are very old, and so real users have unexpected
> uids; this includes Gentoo itself.
>- Gentoo (the community) used to allocate UIDs to devs in the
> 500-1000 range and we have 17 active developers with UIDs in that
> range. So for example if we allocate one of these UIDs to an acct-*
> package; that package will not be installable on woodpecker without
> modification because those UIDs are already taken.

See above.

Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.

Ulrich



Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread Ulrich Mueller
> On Sun, 28 Nov 2021, William Hubbs wrote:

> On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
>> 1/ Static allocation does not really solve a problem. Not really not
>> nowadays
>> 2/ We cant keep adding new IDs to a distribution as new software gets
>> added - one side is unbounded.  This is losing game.

Not sure. In practice, the number of packages is limited. (And if the
argument was valid, it would apply to dynamic alloction too.)

>> Switching back to dynamic allocation seems to be the best option.

> I realize I'm very late to this party, but +1 from me also.

> We should use dynamic uid/git assignment by default and maybe provide
> a way to force certain uids/gids to be constant if users want this.

While the rationale for static allocation that made it into GLEP 81 [1]
is rather weak, several people had argued in favour of it on the mailing
list [2].

In any case, let's cross that bridge when we reach it. For now, we're
good with 250 additional IDs.

Ulrich

[1] https://www.gentoo.org/glep/glep-0081.html#rationale
[2] 
https://archives.gentoo.org/gentoo-dev/message/33903763d46d193a25e4c03c4851bfc3


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCHv3] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-26 Thread Ulrich Mueller
> On Fri, 26 Nov 2021, Joonas Niilola wrote:

> v3 LGTM regardless of that addition. More comments, more acks to get
> this merged even possibly tonight (UTC)? Anyone from PR?

Ack. Looks good now.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-11-23-mariadb-database-restore-maybe-required: add item

2021-11-25 Thread Ulrich Mueller
> On Thu, 25 Nov 2021, Mike Gilbert wrote:

> On Wed, Nov 24, 2021 at 10:21 PM Thomas Deutschmann  wrote:
>> +On 2021-11-21, a member of the QA project accidentially de-keyworded
>> +MariaDB 10.6 to address a file collision, users, who also had latest
>> +dev-db/mariadb-connector-c installed, experienced (NOTE: The default
>> +MySQL connector in Gentoo Linux is provided by
>> +dev-db/mysql-connector-c) [Link 1].

> This sentence is very difficult to read. Also, I don't think it is
> relevant to call out the mistake by the QA team in a news item
> intended for end users. I would rewrite this as:

> On 2021-11-21, keywords for dev-db/mariadb-10.6 were removed to
> address a file collision with dev-db/mariadb-connector-c. This
> unintentionally triggered a version downgrade for users who had
> successfully upgraded to dev-db/mariadb-10.6 already.

+1

News item are to provide information to users, and the details about who
did what in the past aren't necessary here. At most, keep the link to
bug 825234 for reference (but not to any specific comment).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-14 Thread Ulrich Mueller
>>>>> On Sun, 14 Nov 2021, Thomas Deutschmann wrote:

> On 2021-11-11 11:59, Ulrich Mueller wrote:
>> We could:
>> - Open some part of the range between 500 and 1000. For example,
>>   500..799, which would leave 200 IDs for dynamic allocation.
>> - Open part of the range 60001..65533. Not sure if all software will
>>   be happy with that.
>> - Admit that the concept of static allocation has failed, and return
>>   to dynamic allocation.

> Only the third option is really possible.

> The first option (500-1000) would be technically possible but would
> clash with knowledge people gained in the past and would violate LPIC 
> (=making Gentoo even more special and unusable for companies relying
> on certifications).

Why would that be? We chose the original split point quite arbitrarily
to be 500. What is different about adjusting it upwards now?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-14 Thread Ulrich Mueller
>>>>> On Thu, 11 Nov 2021, Ulrich Mueller wrote:

> In any case, we have run out of GIDs:

>Recommended GID only: none
>Recommended UID only: 272
>Recommended UID+GID pair: none
>Free UIDs: 15
>Free GIDs: 0
>Free UID+GID pairs: 0

> The question is of course how we should move forward. Certainly, using
> IDs below 100 cannot be the solution, as we would run out of these very
> soon.

> We could:

> - Open some part of the range between 500 and 1000. For example,
>   500..799, which would leave 200 IDs for dynamic allocation.

> - Open part of the range 60001..65533. Not sure if all software will be
>   happy with that.

> - Admit that the concept of static allocation has failed, and return to
>   dynamic allocation.

By today's council decision, the whole range from 101 to 749 is now
available. The used_free_uidgids.sh script has been updated accordingly.

There seem to be some issues with system IDs above 6 especially with
systemd. We'll try to sort these out before we run out of IDs again.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-13 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, James Cloos wrote:

> gentoo definitely should not permit fixed use for installed packages
> in the 500-600 range.

> 500+ was for many, many years the start for users, and forcing anyone
> to change decades-long use of particular uids or gods is not
> acceptable.

> really all of 101-499,701-999,6-{nobody--} should be dynamic.

> and 500-700 never touched by the distribution.

I have a snapshot of a Gentoo system from 2004 (sys-apps/shadow-4.0.3-r9
and sys-apps/pam-login-3.14). Its login.defs has the following:

   #
   # Min/max values for automatic uid selection in useradd
   #
   UID_MIN  1000
   UID_MAX 6

I see the same values in sys-apps/shadow/files/login.defs for the first
version of shadow in the tree (sys-apps/shadow-19990827-r1, committed on
2000-08-02).

So, I would conclude that Gentoo always used 1000 as minimum UID.

We could of course leave a gap for now, and allocate only 600..799.
This would leave the 500s for compatibility with very old systems.
It would have the additional advantage that we get an earlier warning
once the new range will be almost full. Even if we then allow IDs in the
6s range, we presumably should keep some reserves of low IDs for
packages that really need them to be there.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-11 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, Mike Gilbert wrote:

>> - Open part of the range 60001..65533. Not sure if all software will be
>> happy with that.

> systemd has some code that special-cases ids in the "system" range.
> I'm not exactly sure what impact creating system users outside above
> SYS_UID_MAX (login.defs) will have.

We also have some IDs below SYS_UID_MIN (= 101) which technically is
outside the system account range of login.defs. Do these cause any
problems with systemd?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-11 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, Jaco Kroon wrote:

> # getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3
> 37945
> 37946
> 65534 <-- this happens to be nobody.

> 6 up to where?  65533?

I'd say 60001..60999 for now, and increase by another 1000 when (and if)
it will become necessary.

> I'll need to make a "hole" in our
> allocations but that's perfectly do-able.  Others may run into similar
> issues and be caught unawares (especially if UID/GID values are
> allocated from some other system which may not be aware of UID/GID
> values on specific servers).  Might be worth the trouble to head to
> >=2^31, but that will again fail on systems that still use 16-bit
> UID/GID values (I'm not aware that we still support kernels older than 2.4).

More than 16 bits may be problematic with containers. IIUC some of them
use a split scheme where the upper 16 bits are reserved.

> https://systemd.io/UIDS-GIDS/ basically says system users (which we're
> discussing here) is <1000.  systemd also already violates this statement
> itself just a few paragraphs down with special systemd UID and GID
> ranges.  And already >6 ranges listed here (most of 6 to 65533
> is reserved by systemd).

That's not a standard in any case, and it's dynamic allocation. So as
long as we don't fill up the whole range, things should be fine.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-11 Thread Ulrich Mueller
> On Thu, 11 Nov 2021, Florian Schmaus wrote:

>> We could:
>> - Open some part of the range between 500 and 1000. For example,
>> 500..799, which would leave 200 IDs for dynamic allocation.

> +1, since I am not aware of any significant downsides doing so.

> Could you elaborate why the range 500-799 only leaves us with 200 IDs?

We still need some range for dynamic allocation. Currently that is
500..999, and would be reduced to 800..999. That seems to be on the low
side already.

In any case, 300 additional IDs may not be future proof at the rate
we're currently allocating them. So I wonder if we shouldn't move to
above 6 immediately, or alternatively, give up the whole concept.

Ulrich


signature.asc
Description: PGP signature


[gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-11 Thread Ulrich Mueller
May I remind everybody that by QA policy allocation of UIDs and GIDs
in the range 0..100 needs explicit approval by the QA lead:
https://projects.gentoo.org/qa/policy-guide/user-group.html#pg0901

I have fixed the used_free_uidgids.sh script such that it will no longer
recommend any IDs below 101.

In any case, we have run out of GIDs:

   Recommended GID only: none
   Recommended UID only: 272
   Recommended UID+GID pair: none
   Free UIDs: 15
   Free GIDs: 0
   Free UID+GID pairs: 0

The question is of course how we should move forward. Certainly, using
IDs below 100 cannot be the solution, as we would run out of these very
soon.

We could:

- Open some part of the range between 500 and 1000. For example,
  500..799, which would leave 200 IDs for dynamic allocation.

- Open part of the range 60001..65533. Not sure if all software will be
  happy with that.

- Admit that the concept of static allocation has failed, and return to
  dynamic allocation.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread Ulrich Mueller
> On Wed, 03 Nov 2021, Andreas K Huettel wrote:

> The mistake was to allow the use of EAPI=8 too early. In the future,
> we should have a new EAPI supported by portage for at least some
> months before the EAPI is even used in the main tree. Not even
> speaking about stable here.

I tend to disagree. Adding an ebuild with a new EAPI cannot break
anything, because it will simply be invisible to old package managers.

There won't be a problem unless you _remove_ ebuilds that are part of
the upgrade path.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread Ulrich Mueller
> On Wed, 03 Nov 2021, Aaron Bauman wrote:

> I love digging through old council logs to find "policy"

> Not sure why others don't feel the same way.

Patches for the devmanual are welcome. 


signature.asc
Description: PGP signature


Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread Ulrich Mueller
> On Wed, 03 Nov 2021, John Helmert wrote:

>> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
>> |
>> | Upgrade path for old systems
>> | 
>> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
>> | stable system that hasn't been updated for one year.

> Does "upgrade path" imply a simple world upgrade is all that should be
> necessary to upgrade the system? I wouldn't interpret it this way.

That a "simple world upgrade" was meant is very clear from the full
meeting log, and from the log of the previous 2009-10-12 meeting (open
floor section).

Apparently the problem is neither new (see above, it existed in 2009)
nor is it uncommon. In fact, the Gentoo e.V. will have a workshop about
this topic on 2021-11-20 [1].

Ulrich

[1] https://gentoo-ev.org/news/online-workshops-2021/


signature.asc
Description: PGP signature


Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread Ulrich Mueller
> On Wed, 03 Nov 2021, Rich Freeman wrote:

> On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann  wrote:
>> 
>> This is not about finding solution to upgrade the system (in this case
>> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
>> about raising awareness that Gentoo is a rolling distribution and that
>> we guarantee users to be able to upgrade their system when they do world
>> upgrades just once a year (remember: in my case the last world upgrade
>> is just 4 months old!). If they cannot upgrade their system without
>> manual intervention, we failed to do our job.

> Do we have this "guarantee" documented somewhere?  I thought I've
> heard six months tossed around.  You say one year.  It seems
> reasonable to have some sort of guideline like this and try to stick
> with it, at least for @system.

We do. Summary of 2009-11-09 Council meeting:

| https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
|
| Upgrade path for old systems
| 
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.
|
| Action: leio will start a discussion on gentoo-dev on if and how to
| support upgrading systems that are outdated more than a year.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] dune.eclass: restrict strip

2021-10-11 Thread Ulrich Mueller
> On Mon, 11 Oct 2021, Sam James wrote:

> +# Breaks with ocamlopt
> +RESTRICT="strip"

Note that RESTRICT isn't accumulated across eclasses in EAPIs before 8.
So for older EAPIs you may want to use RESTRICT+=" strip".

Of course, this applies to the other two eclasses as well.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)

2021-10-07 Thread Ulrich Mueller
> On Thu, 07 Oct 2021, Matthew Marchese wrote:

> I also like the idea of markdown files or RST files living in
> gentoo::. I personally find RST to be a bit more challenging to write,
> but it's simple enough to learn and we 'already have RST to HTML
> conversion on www.g.o for GLEPs. GitHub will render either file format
> in browser. Not sure about all the other Git* sites.

> Apparently the MD and RST formats are somewhat interchangeable if one
> does not go too crazy on formatting: 
> https://gist.github.com/javiertejero/4585196

To add to this, here are two excellent articles comparing the two
formats:

https://www.zverovich.net/2016/06/16/rst-vs-markdown.html
https://eli.thegreenplace.net/2017/restructuredtext-vs-markdown-for-technical-d$

Given that we already use RST elsewhere and that it is well supported by
docutils (and our own docutils-glep), that's the format I'd personally
prefer.

Otherwise, the picture in the first article pretty much summarizes it.
:)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)

2021-10-06 Thread Ulrich Mueller
>>>>> On Wed, 06 Oct 2021, Alec Warner wrote:

> On Tue, Oct 5, 2021 at 10:37 PM Ulrich Mueller  wrote:
>> How would you deal with translations? One NOTES file for every language?

> The notes files are for devs, not for users. Do we have non-english
> speaking developers?

Sure, this is a legitimate point. But it's an explicit design decision,
not something that can be silently assumed.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)

2021-10-05 Thread Ulrich Mueller
> On Tue, 05 Oct 2021, Alec Warner wrote:

> I'd argue we can add NOTES.md to packages (e.g. allow those files.)
> Then we modify packages.gentoo.org to render the markdown; or users
> can render locally or read unrendered.

How would you deal with translations? One NOTES file for every language?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/1] glep-0068: Add notes element for package maintenance instructions

2021-10-05 Thread Ulrich Mueller
> On Tue, 05 Oct 2021, Sam James wrote:
 
> +Notes element
> +~
> +
> +The  element describes important information on how to maintain
> +a package.
> +
> +The  element has an obligatory ``type=""`` attribute whose value 
> is
> +can be either ``text`` or ``url``. If its value is ``text``, then the

Too many verbs ("is can be") in this sentence.

> + value is formed of multi-line text. If its value is ``url``, the
> + value should be a link to a page containing information on how
> +to correct maintain the package.

Since this is plain text, it presumably should have an optional "lang"
attribute for consistency with other elements.

Ulrich



Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)

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

> On Tue, 2021-10-05 at 19:27 +0100, Sam James wrote:
>> This is a preliminary version/draft of a proposed change to
>> GLEP 68.
>> 
>> I'd like to introduce a method for developers to signal anything
>> special about a package and how to correctly maintain it.
>> 
>> Sam James (1):
>> glep-0068: Add notes element for package maintenance instructions
>> 
>> glep-0068.rst | 26 +++---
>> 1 file changed, 23 insertions(+), 3 deletions(-)

> To be honest, I don't think adding it to metadata.xml is a good idea. 
> This is not something that's going to be machine-parseable,
> and expecting people to look into metadata.xml to see if it's even
> present is a bit much.

The same argument would apply to longdescription.

> Maybe we could just add README files to the package directories
> in question.  This would have the clear advantage that the files will be
> immediately visible.

Scattering a package's metadata across multiple files doesn't look like
a good idea to me.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] cvs.eclass: Support EAPI 8, drop EAPI 6 and older

2021-10-03 Thread Ulrich Mueller
> On Sun, 03 Oct 2021, David Seifert wrote:

> Those use cases don't necessitate keeping the eclass though?

I don't see why possible removal of the eclass at some unknown time in
the future should block improving it now.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/3] cvs.eclass: Support EAPI 8, drop EAPI 6 and older

2021-10-03 Thread Ulrich Mueller
> On Sun, 03 Oct 2021, Robin H Johnson wrote:

> If they are not, I think it would be reasonable to consider removing
> CVS from the tree on 2022/01/01.

I disagree. It is still useful as a package even if it hadn't any
reverse dependencies. For example, it is needed when doing conversions
of historical CVS repositories.

Also projects still use it; OpenBSD may be the most prominent example.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

2021-10-02 Thread Ulrich Mueller
> On Wed, 29 Sep 2021, A Schenck wrote:

> On 9/28/21 8:36 AM, Michał Górny wrote:
>> [WW] some message
>> [EE] other message
>> [QA] hell if i know what this is
>> 
>> I've also added more colors to explicitly distinguish einfo from elog,
>> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
>> used by Portage with four-character versions to keep messages aligned. 
>> The 'zings' used for merging files remain three-character, so now it's
>> easily possible to distinguish messages from installed file list.

> Didn't expect to be the only dissenting opinion on something like this
> but. . . Some applications parse portage output looking for these
> 'zings'. At very least app-portage/kuroo does it this way; there must be
> others, right? This is obviously not the ideal way to get information
> out of portage, but it's been stable for the 15 years Kuroo has existed.
> 10-ish years ago dol-sen started some work on building and API for
> portage, but then got sucked into core portage development to the point
> of abandoning their GTK+ portage GUI porthole, which was the original
> impetus for an API, and as far as we know, the API never made it to the
> point it could replace parsing the output.

If only the length of the >>> and !!! strings is a problem, then why not
leave them alone and go for single-letter tags instead? Like this:

   [.] einfo
   [I] elog
   [W] ewarn
   [E] eerror
   [Q] eqawarn

The only problematic one is [Q] instead of [QA] which is no longer
self-explanatory. Then again, only devs and experienced users should see
eqawarn messages.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

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

> On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote:
>> Markers: (--) probed, (**) from config file, (==) default setting,
>> (++) from command line, (!!) notice, (II) informational,
>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> 
>> So, maybe change einfo from [--] to [II]?

> Nah, the whole point is to avoid letters since it's not very important.
> Alternatively to '[--]' I could make it look down '[..]' or maybe even
> without eyes entirely '[  ]'.

Yeah, anything but [--]. The version with the dots is nice.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

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

> The proposed new format distinguished message types both using colors
> and strings.  This is roughly inspired by Xorg logs.

Using the same markers as Xorg (especially [--]) but with different
meaning may be confusing though. Xorg has these:

Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.

So, maybe change einfo from [--] to [II]?


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] bzr.eclass: Reinstate eclass

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

> You seem to be missing the fact that all of them hardcode "bzr".

Yes, and it is updated to "brz" in a followup commit. Would you prefer
leaving them as "bzr"? I guess that backwards compatibility link will
stay there for a long time.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] bzr.eclass: Reinstate eclass

2021-09-27 Thread Ulrich Mueller
> On Sat, 25 Sep 2021, Michał Górny wrote:

>> +EBZR="bzr.eclass"

> Why do we need this?  It seems as if someone is reinventing ${ECLASS}.

Replaced by ${ECLASS}.

>> +# @ECLASS-VARIABLE: EBZR_STORE_DIR

> @USER_VARIABLE?

Added.

>> +# @DESCRIPTION:
>> +# The directory to store all fetched Bazaar live sources.
>> +: ${EBZR_STORE_DIR:=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}/bzr-src}
>> +
>> +# @ECLASS-VARIABLE: EBZR_UNPACK_DIR
>> +# @DESCRIPTION:
>> +# The working directory where the sources are copied to.
>> +: ${EBZR_UNPACK_DIR:=${WORKDIR}/${P}}
>> +
>> +# @ECLASS-VARIABLE: EBZR_INIT_REPO_CMD
>> +# @DESCRIPTION:
>> +# The Bazaar command to initialise a shared repository.
>> +: ${EBZR_INIT_REPO_CMD:="bzr init-repository --no-trees"}
>> +
>> +# @ECLASS-VARIABLE: EBZR_FETCH_CMD
>> +# @DESCRIPTION:
>> +# The Bazaar command to fetch the sources.
>> +: ${EBZR_FETCH_CMD:="bzr branch --no-tree"}
>> +
>> +# @ECLASS-VARIABLE: EBZR_UPDATE_CMD
>> +# @DESCRIPTION:
>> +# The Bazaar command to update the sources.
>> +: ${EBZR_UPDATE_CMD:="bzr pull --overwrite-tags"}
>> +
>> +# @ECLASS-VARIABLE: EBZR_EXPORT_CMD
>> +# @DESCRIPTION:
>> +# The Bazaar command to export a branch.
>> +: ${EBZR_EXPORT_CMD:="bzr export"}
>> +
>> +# @ECLASS-VARIABLE: EBZR_CHECKOUT_CMD
>> +# @DESCRIPTION:
>> +# The Bazaar command to checkout a branch.
>> +: ${EBZR_CHECKOUT_CMD:="bzr checkout --lightweight -q"}
>> +
>> +# @ECLASS-VARIABLE: EBZR_REVNO_CMD
>> +# @DESCRIPTION:
>> +# The Bazaar command to list a revision number of the branch.
>> +: ${EBZR_REVNO_CMD:="bzr revno"}

> Are you sure that having these overrides is a good idea?

Yes. Ebuilds had used them in the past.

> Your followup patch pretty much proves that every ebuild redefining
> them would get broken by switch to breezy.

The only one where syntax has changed is EBZR_INIT_REPO_CMD (which has
init-shared-repository instead of init-repository).

>> +# @ECLASS-VARIABLE: EBZR_OPTIONS
>> +# @DEFAULT_UNSET
>> +# @DESCRIPTION:
>> +# The options passed to the fetch and update commands.

> Is this intended to be set by ebuild or by user?

Ebuild.

>> +# @ECLASS-VARIABLE: EBZR_OFFLINE

> @USER_VARIABLE?

>> +# @ECLASS-VARIABLE: EVCS_UMASK

> @USER_VARIABLE?

Both added.

>> +# @FUNCTION: bzr_initial_fetch

> @INTERNAL?

Added, and renamed to _bzr_initial_fetch.

>> +if [[ -n "${EBZR_OFFLINE}" ]]; then
>> +ewarn "EBZR_OFFLINE cannot be used when there is no local 
>> branch yet."

> I dare say this is incorrect.  If user says "no online operations", then
> the eclass should just fail, not ignore the user.

Fixed.

>> +${EBZR_FETCH_CMD} ${EBZR_OPTIONS} "${repo_uri}" "${branch_dir}" \
>> +|| die "${EBZR}: can't branch from ${repo_uri}"

> You can replace the backslash with '||'.

I think that splitting the line before the operator is clearer. (It is
also what GNU coding standards recommend for C.)

>> +# @FUNCTION: bzr_update

> @INTERNAL?

Added, and renamed to _bzr_update.

>> +bzr_fetch() {
>> +local repo_dir branch_dir
>> +local save_sandbox_write=${SANDBOX_WRITE} save_umask
>> +
>> +[[ -n ${EBZR_REPO_URI} ]] || die "${EBZR}: EBZR_REPO_URI is empty"
>> +
>> +if [[ ! -d ${EBZR_STORE_DIR} ]] ; then
>> +addwrite /
>> +mkdir -p "${EBZR_STORE_DIR}" \
>> +|| die "${EBZR}: can't mkdir ${EBZR_STORE_DIR}"
>> +SANDBOX_WRITE=${save_sandbox_write}

> Looks like abusing implementation details.

Replaced by subshell.

>> +if [[ -z ${EBZR_INITIAL_URI} ]]; then
>> +bzr_initial_fetch "${EBZR_REPO_URI}" "${branch_dir}"
>> +else
>> +# Workaround for faster initial download. This clones 
>> the
>> +# branch from a fast server (which may be out of date), 
>> and
>> +# subsequently pulls from the slow original repository.
>> +bzr_initial_fetch "${EBZR_INITIAL_URI}" "${branch_dir}"
>> +if [[ ${EBZR_REPO_URI} != "${EBZR_INITIAL_URI}" ]]; then
>> +EBZR_UPDATE_CMD="${EBZR_UPDATE_CMD} --remember 
>> --overwrite" \
>> +EBZR_OFFLINE="" \

> Why do you override EBZR_OFFLINE here?

The whole else clause is dropped in a followup commit.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH v2] eend: Output QA notice when called without argument

2021-09-27 Thread Ulrich Mueller
> On Sat, 04 Sep 2021, Ulrich Müller wrote:

> PMS says about eend: "Takes one fixed argument, which is a numeric
> return code, and an optional message in all subsequent arguments."

Pushed.


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH v3] Copy files/* into the work tree instead of symlinking it

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

> Symlinking FILESDIR into the work tree has the unintended consequence
> of preserving all original file metadata, including system-specific ACLs
> and so on.  When these files are installed, this could lead to
> unintentionally copying this metadata to the system and/or binary
> packages.

> Let's copy all files instead and drop metadata in the process.  Since
> FILESDIR is expected to be small by design, this shouldn't cause any
> major trouble.  It is also easier and less likely to cause regressions
> than making sure stuff is not preserved when installing.

> Unfortunately, a similar problem applies to DISTDIR.  However,
> installing files from DISTDIR is rarer than from FILESDIR, so I guess
> we'll cross that bridge when we get to it.

Sorry for the late reply, but this looks like the wrong solution to me.

Looking at the installation helpers (doins, doexe, etc.), they don't
preserve the normal permission bits, but reset them to a defined state.
So why would they preserve xattrs?

I don't see anything in PMS that would mandate that behaviour (on the
contrary, in section 13.3.1 there is "Other file attributes may be
discarded"). How do the other package managers handle this?

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] bzr.eclass: Reinstate eclass

2021-09-25 Thread Ulrich Mueller
> On Sat, 25 Sep 2021, Arthur Zamarin wrote:

> On 25/09/2021 12:36, Ulrich Müller wrote:
>> +if [[ -z ${EBZR_INITIAL_URI} ]]; then
>> +bzr_initial_fetch "${EBZR_REPO_URI}" "${branch_dir}"
>> +else
>> +# Workaround for faster initial download. This clones 
>> the
>> +# branch from a fast server (which may be out of date), 
>> and
>> +# subsequently pulls from the slow original repository.
>> +bzr_initial_fetch "${EBZR_INITIAL_URI}" "${branch_dir}"
>> +if [[ ${EBZR_REPO_URI} != "${EBZR_INITIAL_URI}" ]]; then
>> +EBZR_UPDATE_CMD="${EBZR_UPDATE_CMD} --remember 
>> --overwrite" \
>> +EBZR_OFFLINE="" \
>> +bzr_update "${EBZR_REPO_URI}" 
>> "${branch_dir}"
>> +fi

> This logic maybe can be improved and made easier, by defaulting
> EBZR_INITIAL_URI to be by default EBZR_REPO_URI (as a result, the
> first call to bzr_initial_fetch can be done outside the if), and if
> the ebuild writer changed it (check using the if here), then do the
> next bzr_update.

> Or another option, instead of setting by default, do the first fetch as:
> bzr_initial_fetch "${EBZR_INITIAL_URI:-${EBZR_REPO_URI}}" "${branch_dir}"
> But I think this one is less readable.

>> +fi

I am going to drop support for EBZR_INITIAL_URI altogether. This was a
special case used for GNU Emacs, which historically had a slow original
repository and a fast (but possibly out of date) mirror. It is unlikely
that we will need this again.

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [GLEP78] Updating specification r2

2021-09-23 Thread Ulrich Mueller
> On Thu, 23 Sep 2021, Sheng Yu wrote:

> Hi,
> I attached second revision of the new draft of GLEP78 "Gentoo Binary
> Package Container Format"

> Please feel free to give any comments and suggestions.

Since you haven't addressed my comments from the first round of review,
I repeat them here:

| Given that the outer archive is uncompressed tar, every file will be
| zero-padded to a full block which adds some amount of bloat. So, could
| the signature be inlined in the Manifest file? That's also what GLEP 74
| specifies.
|
| Also, IIRC one of the goals of the format was to allow partial download
| of metadata. That will only work if the Manifest file will be the first
| file in the archive (or at least appear before the image archive).

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-09-20-busybox-removal-from-system: add item

2021-09-20 Thread Ulrich Mueller
> On Mon, 20 Sep 2021, Mike Gilbert wrote:

> +The sys-apps/busybox package has been removed from @system for Linux

Maybe "from the system set" or "from the system set (@system)" would
make this even clearer.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Guidance on distributed patented software

2021-09-20 Thread Ulrich Mueller
> On Mon, 20 Sep 2021, Robin H Johnson wrote:

> RedHat's legal team clearly know something there that they aren't
> disclosing the details of publicly, because the patches said the
> patents expire in 2020, but when I asked off-list if EC could be
> re-enabled based on the expiry dates in the files, they claimed that
> patent issues were still present, without giving any detail.

If there are remaining patent issues then they should be able to support
their claim by facts, like a patent number. Why would this be difficult,
or what reason would they have not to disclose it?

> [1] 
> https://src.fedoraproject.org/rpms/openssl/c/347681c6b246d9b6a08c73bb40e5eefaf8596d71?branch=rawhide
> [2] https://www.spinics.net/linux/fedora/fedora-legal/msg03673.html


signature.asc
Description: PGP signature


[gentoo-dev] Re: Guidance on distributed patented software

2021-09-20 Thread Ulrich Mueller
> On Mon, 20 Sep 2021, Alec Warner wrote:

> The devmanual discusses licensing as a core concept
> (https://devmanual.gentoo.org/general-concepts/licenses/index.html)
> but does not cover patents. My understanding is that we:

>  - set RESTRICT=bindist when we are unable to redistribute binaries
> (e.g. due to a license or patent restriction.)
>  - set RESTRICT=mirror when we are unable to redistribute source code
> (e.g. due to a license of patent restriction.)

IANAL, but IIUC patents only apply to programs that can run on a
computer. This is the case for binaries but not for source code.

In other words, we don't need mirror restriction for source tarballs
because of patents.

>  - Sometimes, we remove patent encumbered source code from packages
> (e.g. with USE=bindist) so that we can build redistributable binaries
> with the patented features removed.

We do, but normally this doesn't prevent us from distributing the source
code.

> Could we add some text to the license concepts covering patents? It
> seems to have been omitted?
> Is my understanding of how we manage patented software correct?


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] ssl-cert.eclass: EAPI 8 support and add guard

2021-09-14 Thread Ulrich Mueller
> On Tue, 14 Sep 2021, Eray Aslan wrote:

> +if [[ ! ${_SSL_CERT_ECLASS} ]]; then
> +
>  # @ECLASS-VARIABLE: SSL_CERT_MANDATORY
>  # @PRE_INHERIT
>  # @DESCRIPTION:
> @@ -283,3 +285,6 @@ install_cert() {
>   ewarn "Some requested certificates were not generated"
>   fi
>  }
> +
> +_SSL_CERT_ECLASS=1

Please make this the first statement in the "if" block. (At the moment
it doesn't matter, but it's less error prone in case another eclass will
be inherited later.)


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >