>>>>> 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 pack
>>>>> 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?
> 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
>
> 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
>>>>> 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
>gi
> 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
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
> 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
> 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
>
> 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 [[
> 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
>>>>> 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 symb
> 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
>>>>> 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.
>>&g
> 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
> 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
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
> 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
>>>>> 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
>>> infor
> 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
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
|
> 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
> 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
> 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 $@"
> 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
> 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
> 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
> 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.
>
> 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
> 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
> 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
> 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
> +
> 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
> 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
> 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
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]
> 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
> 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
> 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
> 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,
> 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,
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
>>>>> 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,
>>
> 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
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
> 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
> 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
>>>>> 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
>> bel
> 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,
>>>>> 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 avai
> 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
> 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)
> 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.
> 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.
>>
> 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
>>>>> 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
> 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=(
> +
> 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"
> +
>>>>> 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
> 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
> 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
> 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
> 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,
>>>>> 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.
>> - Ope
>>>>> 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
>
> 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.
>
> 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
> 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.
>
> 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
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.
> 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
> 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
> 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
> 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
> 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
> 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
>>>>> 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
&
> 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
> 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
> 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
> 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
> 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
> 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
>>>>> 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) warni
> 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:
> 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.
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> }
> +
> On Mon, 13 Sep 2021, Sheng Yu wrote:
> -The archive contains a number of files, stored in a single directory
> -whose name should match the basename of the package file. However,
> -the implementation must be able to process an archive where
> -the directory name is mismatched. There
> On Fri, 03 Sep 2021, Mike wrote:
> - if [ ! -s "${KV_DIR}/Makefile" ]
> + get_makefile
> +
> + if [[ ! -s "${KERNEL_MAKEFILE}" ]]
No quotation marks needed in [[ ]].
+ [[ -s "${KV_DIR}"/GNUMakefile ]] &&
> KERNEL_MAKEFILE="${KV_DIR}/GNUMakefile"
> + [[ -s
Quite a while ago, bug 520528 was filed, asking for a ban of
has_version, best_version, and possibly other commands in global scope.
Since most ebuild commands cannot be used in global scope anyway,
I think that a positive list of commands _allowed_ there would make more
sense; all other commands
> On Sun, 29 Aug 2021, Michał Górny wrote:
> On Sun, 2021-08-29 at 22:06 +0200, Ulrich Müller wrote:
>> -eqawarn "For compatibility with <=portage-2.1.6.7, only
>> call EXPORT_FUNCTIONS"
>> -eqawarn "after inherit(s)."
>> +eqawarn
> On Sat, 28 Aug 2021, Michał Górny wrote:
> I've been informed of a slight inconsistency in package manager behavior
> that affects combining EXPORT_FUNCTIONS with inherit (by ionic, thanks
> for the report!). Please consider the three following snippets:
> xdg.eclass:
>
201 - 300 of 2165 matches
Mail list logo
