Re: [gentoo-dev] Re: Last-rite: dev-libs/rapidxml
On 2.10.2021 20.22, Anna Vyalkova wrote: > On 2021-10-02 15:57, Joonas Niilola wrote: >> # A library without revdeps. Last upstream release in 2009, huge amount > There's a revdep in ::guru (app-accessibility/rhvoice) > What do I do: use bundled rapidxml or add dev-libs/rapidxml to ::guru? > >> # of open bugs not fixed has led the project being forked already. > Is that the fork you mean? > https://github.com/timniederhausen/rapidxml > Hey, I'd suggest you import this fork at its latest snapshot state to ::guru, see that it's compatible with rhvoice, and add to ::guru's local package.unmask if it works. The unmask can be cleaned, when the package is removed from the ::gentoo repo. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote: > Guess there's a lot of other options that could be considered as well. > > --- files > >>> text > * current, it wasn't aligned now that I look at it again > (relying only on color to convey type feels clearly wrong to me) > > --- files > text > [QA] new based on current PR > > >>> text > [QA] aligned 1 character further, maybe skipping changing >>> is fine? > (then again that it's further is what threw me off at first) > > >>> text > QA* similar to before, but aligned using only 3 chars > > >>> text > [Q] kinda more obscure but it can work > Guess should also add these: >>> text Q* Notice: E* Some error happened (closest to before by making use of the former leading space, thus no alignment changes) >>> text QA Notice: EE Some error happened (at least clearer than Q* Notice, but unsure about no separator.. guess it could work?) > text > QA* probably closest to how it was before alignment-wise, but meh at 4 > > > >>> message > QA> not convinced about this one, but throwing it here anyway > (other characters could be considered as well) > > Maybe a poll of some kind may help, personally undecided on what I > like better beside agreeing that a change is needed. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 02, 2021 at 06:04:36PM -0400, Ionen Wolkens wrote: > On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote: > > > 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. > > fwiw eqawarn is currently displayed for everyone in a similar manner > as einfo, just not post-emerge/elog without adding to ELOG classes. > > If users aren't hiding build logs entirely, they may notice those > done at the end (often shown after size report) -- and possibly > think it's a problem. > > Not to say whether [Q] vs [QA] would help with this much so I have > no strong opinion here. Guess there's a lot of other options that could be considered as well. --- files >>> text * current, it wasn't aligned now that I look at it again (relying only on color to convey type feels clearly wrong to me) --- files text [QA] new based on current PR >>> text [QA] aligned 1 character further, maybe skipping changing >>> is fine? (then again that it's further is what threw me off at first) >>> text QA* similar to before, but aligned using only 3 chars >>> text [Q] kinda more obscure but it can work text QA* probably closest to how it was before alignment-wise, but meh at 4 > >>> message QA> not convinced about this one, but throwing it here anyway (other characters could be considered as well) Maybe a poll of some kind may help, personally undecided on what I like better beside agreeing that a change is needed. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote: > > 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. fwiw eqawarn is currently displayed for everyone in a similar manner as einfo, just not post-emerge/elog without adding to ELOG classes. If users aren't hiding build logs entirely, they may notice those done at the end (often shown after size report) -- and possibly think it's a problem. Not to say whether [Q] vs [QA] would help with this much so I have no strong opinion here. -- ionen signature.asc Description: PGP signature
[gentoo-dev] Re: Last-rite: dev-libs/rapidxml
On 2021-10-02 15:57, Joonas Niilola wrote: > # A library without revdeps. Last upstream release in 2009, huge amount There's a revdep in ::guru (app-accessibility/rhvoice) What do I do: use bundled rapidxml or add dev-libs/rapidxml to ::guru? > # of open bugs not fixed has led the project being forked already. Is that the fork you mean? https://github.com/timniederhausen/rapidxml
[gentoo-portage-dev] [PATCH 1/1] bin/misc-function.sh: check scanelf return code
This is part of a series of fixes for the linked bug (failure
to preserve libraries in some situations).
We need to check if scanelf failed when calling it in the
installed-files QA check as we later use it to populate the VDB.
Silently continuing results in either blank e.g. PROVIDES,
NEEDED{,.ELF.2} or those files may be missing entirely,
resulting in a corrupt state both on the system and in
any generated binpkgs.
Adds an escape variable (PORTAGE_NO_SCANELF_CHECK) to allow
re-emerging pax-utils if it's broken.
Bug: https://bugs.gentoo.org/811462
Signed-off-by: Sam James
---
bin/misc-functions.sh | 64 +--
1 file changed, 50 insertions(+), 14 deletions(-)
diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index bd1fb7553..e4defa550 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -177,25 +177,61 @@ install_qa_check() {
if type -P scanelf > /dev/null ; then
# Save NEEDED information after removing self-contained
providers
rm -f "$PORTAGE_BUILDDIR"/build-info/NEEDED{,.ELF.2}
+
# We don't use scanelf -q, since that would omit libraries like
# musl's /usr/lib/libc.so which do not have any DT_NEEDED or
# DT_SONAME settings. Since we don't use scanelf -q, we have to
# handle the special rpath value " - " below.
- scanelf -yRBF '%a;%p;%S;%r;%n' "${D%/}/" | { while IFS= read -r
l; do
- arch=${l%%;*}; l=${l#*;}
- obj="/${l%%;*}"; l=${l#*;}
- soname=${l%%;*}; l=${l#*;}
- rpath=${l%%;*}; l=${l#*;}; [ "${rpath}" = " - " ] &&
rpath=""
- needed=${l%%;*}; l=${l#*;}
-
- # Infer implicit soname from basename (bug 715162).
- if [[ -z ${soname} && $(file "${D%/}${obj}") == *"SB
shared object"* ]]; then
- soname=${obj##*/}
- fi
+ scanelf_output=$(scanelf -yRBF '%a;%p;%S;%r;%n' "${D%/}/")
+
+ case $? in
+ 0)
+ # Proceed
+ ;;
+ 159)
+ # Unknown syscall
+ eerror "Failed to run scanelf (unknown syscall)"
+
+ if [[ -z ${PORTAGE_NO_SCANELF_CHECK} ]]; then
+ # Abort only if the special recovery
variable isn't set
+ eerror "Please upgrade pax-utils with:"
+ eerror " PORTAGE_NO_SCANELF_CHECK=1
emerge -v1 app-misc/pax-utils"
+ eerror "Aborting to avoid corrupting
metadata"
+ die "${0##*/}: Failed to run scanelf!
Update pax-utils?"
+ fi
+ ;;
+ *)
+ # Failed in another way
+ eerror "Failed to run scanelf (returned: $?)!"
+
+ if [[ -z ${PORTAGE_NO_SCANELF_CHECK} ]]; then
+ # Abort only if the special recovery
variable isn't set
+ eerror "Please report this bug at
https://bugs.gentoo.org/!;
+ eerror "It may be possible to re-emerge
pax-utils with:"
+ eerror " PORTAGE_NO_SCANELF_CHECK=1
emerge -v1 app-misc/pax-utils"
+ eerror "Aborting to avoid corrupting
metadata"
+ die "${0##*/}: Failed to run scanelf!"
+ fi
+ ;;
+ esac
+
+ if [[ -n ${scanelf_output} ]]; then
+ while IFS= read -r l; do
+ arch=${l%%;*}; l=${l#*;}
+ obj="/${l%%;*}"; l=${l#*;}
+ soname=${l%%;*}; l=${l#*;}
+ rpath=${l%%;*}; l=${l#*;}; [ "${rpath}" = " -
" ] && rpath=""
+ needed=${l%%;*}; l=${l#*;}
+
+ # Infer implicit soname from basename (bug
715162).
+ if [[ -z ${soname} && $(file "${D%/}${obj}") ==
*"SB shared object"* ]]; then
+ soname=${obj##*/}
+ fi
- echo "${obj} ${needed}" >>
"${PORTAGE_BUILDDIR}"/build-info/NEEDED
- echo "${arch#EM_};${obj};${soname};${rpath};${needed}"
>> "${PORTAGE_BUILDDIR}"/build-info/NEEDED.ELF.2
- done }
+ echo "${obj} ${needed}" >>
[gentoo-portage-dev] [PATCH 0/1] Check for errors in scanelf
Posted at https://github.com/gentoo/portage/pull/750 originally and merged in 3.0.24, but posting here for posterity. Related to the general preserve-libs issues I've been working on. Sam James (1): bin/misc-function.sh: check scanelf return code bin/misc-functions.sh | 64 +-- 1 file changed, 50 insertions(+), 14 deletions(-) -- 2.33.0
[gentoo-portage-dev] [PATCH 2/2] lib/_emerge/resolver/output_helpers.py: explicitly state 'all satisfied'
This makes things a bit less confusing and tries to avoid
users focusing on (soft) blocks which aren't actually
the problem they're hitting.
Signed-off-by: Sam James
---
lib/_emerge/resolver/output_helpers.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/_emerge/resolver/output_helpers.py
b/lib/_emerge/resolver/output_helpers.py
index f80b79ccf..6ce812189 100644
--- a/lib/_emerge/resolver/output_helpers.py
+++ b/lib/_emerge/resolver/output_helpers.py
@@ -163,6 +163,8 @@ class _PackageCounters:
myoutput.append(
bad(" (%s unsatisfied)") % (self.blocks -
self.blocks_satisfied)
)
+else:
+myoutput.append(" (all satisfied)")
return "".join(myoutput)
--
2.33.0
[gentoo-portage-dev] [PATCH 1/2] lib/_emerge/resolver/output.py: say 'soft blocking' explicitly
Before:
```
[blocks b ] >perl-core/Scalar-List-Utils-1.550.0-r999
(">perl-core/Scalar-List-Utils-1.550.0-r999" is blocking
virtual/perl-Scalar-List-Utils-1.550.0)
```
After:
```
[blocks b ] >perl-core/Scalar-List-Utils-1.550.0-r999
(">perl-core/Scalar-List-Utils-1.550.0-r999" is soft blocking
virtual/perl-Scalar-List-Utils-1.550.0)
```
This should make it a little bit clearer when a block matters,
especially given we already explicitly say 'hard blocking'
for the opposite case.
Signed-off-by: Sam James
---
lib/_emerge/resolver/output.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/_emerge/resolver/output.py b/lib/_emerge/resolver/output.py
index e891d84c0..7b5602a78 100644
--- a/lib/_emerge/resolver/output.py
+++ b/lib/_emerge/resolver/output.py
@@ -108,7 +108,7 @@ class Display:
if blocker.atom.blocker.overlap.forbid:
blocking_desc = "hard blocking"
else:
-blocking_desc = "blocking"
+blocking_desc = "soft blocking"
if self.resolved != blocker.atom:
addl += colorize(
self.blocker_style,
--
2.33.0
[gentoo-portage-dev] [PATCH 2/2] Binpkg.py: check for inconsistent PROVIDES/image when unpacking binpkg
This is part of a series of fixes for the linked bug (failure to preserve libraries in some situations). When unpacking a binpkg to be installed, we should check for the existence of PROVIDES if we're installing any dynamic libraries. If PROVIDES does not exist in that case, this suggests that e.g. scanelf malfunctioned or some corruption occurred. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James --- lib/_emerge/Binpkg.py | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/lib/_emerge/Binpkg.py b/lib/_emerge/Binpkg.py index c7dde69bd..9b876f354 100644 --- a/lib/_emerge/Binpkg.py +++ b/lib/_emerge/Binpkg.py @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 import functools - +import glob import _emerge.emergelog from _emerge.EbuildPhase import EbuildPhase from _emerge.BinpkgFetcher import BinpkgFetcher @@ -13,6 +13,7 @@ from _emerge.EbuildMerge import EbuildMerge from _emerge.EbuildBuildDir import EbuildBuildDir from _emerge.SpawnProcess import SpawnProcess from portage.eapi import eapi_exports_replace_vars +from portage.output import colorize from portage.util import ensure_dirs from portage.util._async.AsyncTaskFuture import AsyncTaskFuture import portage @@ -425,6 +426,31 @@ class Binpkg(CompositeTask): self._async_unlock_builddir(returncode=self.returncode) return +# Before anything else, let's do an integrity check. +(provides,) = self._bintree.dbapi.aux_get(self.pkg.cpv, ["PROVIDES"]) +if not provides: +# Let's check if we've got inconsistent results. +# If we're installing dynamic libraries (.so files), we should +# really have a PROVIDES. +# (This is a complementary check at the point of ingestion for the +# creation check in doebuild.py) +# Note: we could check a non-empty PROVIDES against the list of .sos, +# but this doesn't gain us anything. We're interested in failure +# to properly parse the installed files at all, which should really +# be a global problem (e.g. bug #811462) +installed_dynlibs = glob.glob( +self.settings["D"] + "/**/*.so", recursive=True +) +if installed_dynlibs: +self._writemsg_level( +colorize( +"BAD", +"!!! Error! Installing dynamic libraries (.so) with blank PROVIDES!", +), +noiselevel=-1, +level=logging.ERROR, +) + try: with io.open( _unicode_encode( -- 2.33.0
[gentoo-portage-dev] [PATCH 1/2] doebuild.py: check for inconsistent PROVIDES/image post-src_install
This is part of a series of fixes for the linked bug (failure to preserve libraries in some situations). At the point of installation (even if not merging), we need to detect inconsistent metadata: PROVIDES should be populated if we're installing any dynamic libraries. This suggests that e.g. scanelf malfunctioned or some corruption occurred. Bug: https://bugs.gentoo.org/811462 Signed-off-by: Sam James --- lib/portage/package/ebuild/doebuild.py | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/lib/portage/package/ebuild/doebuild.py b/lib/portage/package/ebuild/doebuild.py index 9650a8444..dc3fe3d97 100644 --- a/lib/portage/package/ebuild/doebuild.py +++ b/lib/portage/package/ebuild/doebuild.py @@ -3,6 +3,7 @@ __all__ = ["doebuild", "doebuild_environment", "spawn", "spawnebuild"] +import glob import grp import gzip import errno @@ -3079,7 +3080,7 @@ def _post_src_install_soname_symlinks(mysettings, out): ) as f: f.write(soname_deps.requires) -if soname_deps.provides is not None: +if soname_deps.provides: with io.open( _unicode_encode( os.path.join(build_info_dir, "PROVIDES"), @@ -3091,6 +3092,27 @@ def _post_src_install_soname_symlinks(mysettings, out): errors="strict", ) as f: f.write(soname_deps.provides) +else: +# Let's check if we've got inconsistent results. +# If we're installing dynamic libraries (.so files), we should +# really have a PROVIDES. +# (This is a complementary check at the point of creation for the +# ingestion check in Binpkg.py) +# Note: we could check a non-empty PROVIDES against the list of .sos, +# but this doesn't gain us anything. We're interested in failure +# to properly parse the installed files at all, which should really +# be a global problem (e.g. bug #811462) +installed_dynlibs = glob.glob(image_dir + "/**/*.so", recursive=True) + +if installed_dynlibs: +self._writemsg_level( +colorize( +"BAD", +"!!! Error! Installing dynamic libraries (.so) with blank PROVIDES!", +), +noiselevel=-1, +level=logging.ERROR, +) if unrecognized_elf_files: qa_msg = ["QA Notice: Unrecognized ELF file(s):"] -- 2.33.0
[gentoo-portage-dev] [PATCH 0/2] Detect broken VDB on merging/binpkg creation
Further fixes for when the VDB is corrupted by e.g. broken scanelf. Already posted on GH a while ago at https://github.com/gentoo/portage/pull/744. Sam James (2): doebuild.py: check for inconsistent PROVIDES/image post-src_install Binpkg.py: check for inconsistent PROVIDES/image when unpacking binpkg lib/_emerge/Binpkg.py | 28 +- lib/portage/package/ebuild/doebuild.py | 24 +- 2 files changed, 50 insertions(+), 2 deletions(-) -- 2.33.0
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 2, 2021 at 1:25 PM A Schenck wrote: > Further discussion belongs on a different list, but the link provided by > mgorny and repeated by you does not allow collaborating in compliance > with the Gentoo Social Contract. The patches were also posted for review on the gentoo-portage-dev mailing list.
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 10/1/21 11:32 AM, Alec Warner wrote: > On Fri, Oct 1, 2021 at 11:30 AM A Schenck wrote: >> On 9/29/21 11:44 PM, Michał Górny wrote: >>> On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote: Hi, Would it be possible to have some switch (e.g. --style=legacy) that controls this new vs. the old behaviour? Would perhaps allow applications that parse the output to work via setting this in the global opts. >>> Patches welcome. It shouldn't be hard, my commit shows which files need >>> to be edited to alter the prefixes and how to pass them into ebd. >> Would it be possible to get this patch in an format that it can be >> interacted with with open tools? Per the other branch of this thread, >> we'd be happy to make this an opt-in so as to not break existing people. > I'm not sure what you mean; you can download the PR... > > https://github.com/gentoo/portage/pull/759 > > -A This isn't really the place to rehash the whole discussion of free speech vs. free beer: http://www.gnu.org/philosophy/free-sw-en.html . Suffice to say the Gentoo Social Contract (https://www.gentoo.org/get-started/philosophy/social-contract.html#gentoo-is-and-will-remain-free-software) states: "Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative"; which GitHub does not conform to: https://www.gnu.org/software/repo-criteria-evaluation.html#GitHub . Further reading (linked from gnu.org) at https://sanctum.geek.nz/why-not-github.html , and of course we all know that Microsoft acquired GitHub, and of course Microsoft has a history of suing Free / Libre / Open Source Software creators and users. Further discussion belongs on a different list, but the link provided by mgorny and repeated by you does not allow collaborating in compliance with the Gentoo Social Contract. -A >> -A >> >> OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rite: dev-libs/rapidxml
# A library without revdeps. Last upstream release in 2009, huge amount # of open bugs not fixed has led the project being forked already. # Bug #776895. Removal in ~30 days. OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH 3/3] cvs.eclass: Fix eclass documentation
Signed-off-by: Ulrich Müller
---
eclass/cvs.eclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/eclass/cvs.eclass b/eclass/cvs.eclass
index 34c32a4a4190..99b90cec6b54 100644
--- a/eclass/cvs.eclass
+++ b/eclass/cvs.eclass
@@ -195,7 +195,9 @@ if [[ ${ECVS_AUTH} == "ext" ]] ; then
BDEPEND+=" net-misc/openssh"
fi
-# called from cvs_src_unpack
+# @FUNCTION: cvs_fetch
+# @DESCRIPTION:
+# Fetch sources from a CVS repository. Called from cvs_src_unpack.
cvs_fetch() {
# Make these options local variables so that the global values are
# not affected by modifications in this function.
--
2.33.0
[gentoo-dev] [PATCH 2/3] cvs.eclass: Don't rely on sandbox internals
Signed-off-by: Ulrich Müller
---
eclass/cvs.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/cvs.eclass b/eclass/cvs.eclass
index 2868cb31f317..34c32a4a4190 100644
--- a/eclass/cvs.eclass
+++ b/eclass/cvs.eclass
@@ -257,10 +257,10 @@ cvs_fetch() {
# just remove the last path element in the string)
debug-print "${FUNCNAME}: checkout mode. creating cvs directory"
- addwrite /foobar
- addwrite /
- mkdir -p "/${ECVS_TOP_DIR}"
- export SANDBOX_WRITE="${SANDBOX_WRITE//:\/foobar:\/}"
+ (
+ addwrite /
+ mkdir -p "${ECVS_TOP_DIR}" || die "mkdir
${ECVS_TOP_DIR} failed"
+ )
fi
# In case ECVS_TOP_DIR is a symlink to a dir, get the real path,
--
2.33.0
[gentoo-dev] [PATCH 1/3] cvs.eclass: Support EAPI 8, drop EAPI 6 and older
Signed-off-by: Ulrich Müller
---
eclass/cvs.eclass | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/eclass/cvs.eclass b/eclass/cvs.eclass
index a8e5ee4cc9a0..2868cb31f317 100644
--- a/eclass/cvs.eclass
+++ b/eclass/cvs.eclass
@@ -4,7 +4,7 @@
# @ECLASS: cvs.eclass
# @MAINTAINER:
# vap...@gentoo.org (and anyone who wants to help)
-# @SUPPORTED_EAPIS: 4 5 6 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: This eclass provides generic cvs fetching functions
# @DESCRIPTION:
# This eclass provides the generic cvs fetching functions. To use this from an
@@ -16,6 +16,11 @@
if [[ -z ${_CVS_ECLASS} ]]; then
_CVS_ECLASS=1
+case ${EAPI} in
+ 7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
# TODO:
# Implement more auth types (gserver?, kserver?)
@@ -179,7 +184,7 @@ PROPERTIES+=" live"
# add cvs to deps
# ssh is used for ext auth
-DEPEND="dev-vcs/cvs"
+BDEPEND="dev-vcs/cvs"
if [[ ${ECVS_AUTH} == "ext" ]] ; then
#default to ssh
@@ -187,15 +192,9 @@ if [[ ${ECVS_AUTH} == "ext" ]] ; then
if [[ ${CVS_RSH} != "ssh" ]] ; then
die "Support for ext auth with clients other than ssh has not
been implemented yet"
fi
- DEPEND+=" net-misc/openssh"
+ BDEPEND+=" net-misc/openssh"
fi
-case ${EAPI:-0} in
- 4|5|6) ;;
- 7) BDEPEND="${DEPEND}"; DEPEND="" ;;
- *) die "${ECLASS}: EAPI ${EAPI:-0} is not supported" ;;
-esac
-
# called from cvs_src_unpack
cvs_fetch() {
# Make these options local variables so that the global values are
--
2.33.0
[gentoo-dev] dune.eclass change to build release
This is for review the change i ndune.eclass
The reason is that the new ocaml-4.12 compiler raise some
warning that dune transform in fatal error
The following changes is to build with profile release.
That will change compiler warning to not raise fatal error during build
diff --git a/eclass/dune.eclass b/eclass/dune.eclass
index 5e2c1fa1f7c4..02a8a870ef43 100644
--- a/eclass/dune.eclass
+++ b/eclass/dune.eclass
@@ -30,31 +30,31 @@ QA_FLAGS_IGNORED='.*'
EXPORT_FUNCTIONS src_compile src_test src_install
RDEPEND=">=dev-lang/ocaml-4:=[ocamlopt?] dev-ml/dune:="
case ${EAPI:-0} in
5|6)
DEPEND="${RDEPEND} dev-ml/dune"
;;
*)
BDEPEND="dev-ml/dune dev-lang/ocaml"
DEPEND="${RDEPEND}"
;;
esac
dune_src_compile() {
- dune build @install || die
+ dune build @install --profile release || die
}
dune_src_test() {
dune runtest || die
}
# @FUNCTION: dune-install
# @USAGE:
# @DESCRIPTION:
# Installs the dune packages given as arguments. For each "${pkg}"
element in # that list, "${pkg}.install" must be readable from
"${PWD}/_build/default" dune-install() {
local pkg
for pkg ; do
dune install \
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
> 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
On Fri, 2021-10-01 at 18:00 -0400, Joshua Kinard wrote: > On 9/30/2021 02:40, Fabian Groffen wrote: > > Hi, > > > > Would it be possible to have some switch (e.g. --style=legacy) that > > controls this new vs. the old behaviour? Would perhaps allow > > applications that parse the output to work via setting this in the > > global opts. > > Perhaps this would be better as a FEATURE flag? E.g., 'legacy-output' or > something similar? > No. FEATURES is just a horrible historical mistake. Proper configuration uses separate keys for separate options. -- Best regards, Michał Górny
