Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 02-10-2021 23:03:56 -0400, Ionen Wolkens wrote: > 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) FWIW, I like this one. Perhaps even with lowercase make[4]: leaving directory src q* soname lacks version e* failed to die Fabian > > >>> 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 -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
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
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
