[gentoo-dev] Output of ANSI escape sequences in ebuilds
Some ebuilds output SGR control sequences (formerly known as ANSI escape
sequences) to the terminal, i.e., they do things like:
echo -e "\033[1m${@}\033[0m"
einfo "Fetching \e[1m${r}\e[22m ..."
ewarn "\033[1;33m**\033[00m"
echo -ne "\a" # (not actually an ANSI escape sequence)
These prevent NOCOLOR in make.conf or emerge --color=n from working
correctly, and I guess they are also problematic from an accessibility
point of view.
Are there any objections against removing these sequences from strings?
AFAICS, they are used by less than ten packages, and one eclass.
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
> On Fri, 13 Dec 2019, Mike Gilbert wrote:
>> > It also triggers pointless bug reports. Please remove this.
>>
>> I don't like that eqawarn either (see above).
>>
>> OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES,
>> so they won't see the warning?
> Here's a bug report filed by a user, which is what prompted me to
> reply on this thread in the first place.
> https://bugs.gentoo.org/702608
Well then, trivial patch included below.
From 81000b32d330a1cc41a4541f7e4264918eb7e6c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
Date: Fri, 13 Dec 2019 23:41:23 +0100
Subject: [PATCH] eapply: Drop QA warning for fuzz factor.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This didn't add any information beyond what is already present in the
output of patch. Developers will know how to interpret its output, and
users won't see the warning anyway with the standard configuration.
Signed-off-by: Ulrich Müller
---
bin/phase-helpers.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index b5691bd70..020862ba0 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -1004,8 +1004,6 @@ if ___eapi_has_eapply; then
if ${patch_cmd} "${all_opts[@]}" --dry-run -s -F0 \
< "${f}" &>/dev/null; then
all_opts+=( -s -F0 )
- else
- eqawarn "${f}: patch failed to apply
without a fuzz factor, please rebase"
fi
${patch_cmd} "${all_opts[@]}" < "${f}"
--
2.24.0
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, Dec 13, 2019 at 4:42 PM Michał Górny wrote: > > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: > > On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: > > > Just like 'many of the proposals lately', developers are going to be > > > the ones disabling it (because they don't care), and users will be the > > > ones enabling it (because they do care), just to learn that developers > > > don't care and go complaining to the mailing lists that users dare > > > report issues they don't care about. > > > > I care if the patch is actually broken, which the warning doesn't > > really tell me. It's just not a very reliable indicator, and will > > produce false-positives frequently. > > > > You can also take less context into the patch and use -F0. Then you'll > have the same effect, no warnings to bother you and no pretending that > the patch applies when it doesn't. That really doesn't help me. My point is that I don't want to touch the patch unless it is actually necessary to do so.
[gentoo-portage-dev] RFC: [QA] notice with 'failed' seds [was PATCH: eapply drop -s option]
On 13/12/19 20:36, Michał Górny wrote [excerpted]: > > Is this really an argument for or *against* it? Developers are entirely > capable of keeping seds that do nothing for years, as well as patches > that -- while apparently applying correctly -- are entirely meaningless. I think there is some merit in some kind of feedback when sed's are doing nothing, although how feasible it is to generate any useful feedback I can't say. I wouldn't say it needs to explicitly fail or make lots of noise, just an info message that could prompt some further investigation. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 13/12/19 21:59, Michał Górny wrote: > On Fri, 2019-12-13 at 21:56 +, Michael 'veremitz' Everitt wrote: >> On 13/12/19 21:42, Michał Górny wrote: >>> On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: > Just like 'many of the proposals lately', developers are going to be > the ones disabling it (because they don't care), and users will be the > ones enabling it (because they do care), just to learn that developers > don't care and go complaining to the mailing lists that users dare > report issues they don't care about. I care if the patch is actually broken, which the warning doesn't really tell me. It's just not a very reliable indicator, and will produce false-positives frequently. >>> You can also take less context into the patch and use -F0. Then you'll >>> have the same effect, no warnings to bother you and no pretending that >>> the patch applies when it doesn't. >>> >> Is there any mileage in having a similar scheme to which we already apply >> '-p' increments to the -F variable? >> eg. >> 1) attempt patch with -F0 >> 2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice > That is precisely what my patch does and what people are complaining > about. Ah, apologies for the failure to grok. Tangentially, but also brought up on the thread, I'm actually even moderately concerned about the ghost seds that may never apply. Topic for another thread though I feel. >> 3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning >> and QA notice > That makes no sense as it exceeds context provided in most patches. > Fair .. hadn't thought of that - depends very much if you're using unified diffs, which I believe we largely are. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, 2019-12-13 at 21:56 +, Michael 'veremitz' Everitt wrote: > On 13/12/19 21:42, Michał Górny wrote: > > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: > > > On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: > > > > Just like 'many of the proposals lately', developers are going to be > > > > the ones disabling it (because they don't care), and users will be the > > > > ones enabling it (because they do care), just to learn that developers > > > > don't care and go complaining to the mailing lists that users dare > > > > report issues they don't care about. > > > I care if the patch is actually broken, which the warning doesn't > > > really tell me. It's just not a very reliable indicator, and will > > > produce false-positives frequently. > > > > > You can also take less context into the patch and use -F0. Then you'll > > have the same effect, no warnings to bother you and no pretending that > > the patch applies when it doesn't. > > > Is there any mileage in having a similar scheme to which we already apply > '-p' increments to the -F variable? > eg. > 1) attempt patch with -F0 > 2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice That is precisely what my patch does and what people are complaining about. > 3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning > and QA notice That makes no sense as it exceeds context provided in most patches. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 13/12/19 21:42, Michał Górny wrote: > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: >> On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: >>> Just like 'many of the proposals lately', developers are going to be >>> the ones disabling it (because they don't care), and users will be the >>> ones enabling it (because they do care), just to learn that developers >>> don't care and go complaining to the mailing lists that users dare >>> report issues they don't care about. >> I care if the patch is actually broken, which the warning doesn't >> really tell me. It's just not a very reliable indicator, and will >> produce false-positives frequently. >> > You can also take less context into the patch and use -F0. Then you'll > have the same effect, no warnings to bother you and no pretending that > the patch applies when it doesn't. > Is there any mileage in having a similar scheme to which we already apply '-p' increments to the -F variable? eg. 1) attempt patch with -F0 2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice 3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning and QA notice 4) Fail and abort Regards, veremitz/Michael. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: > On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: > > Just like 'many of the proposals lately', developers are going to be > > the ones disabling it (because they don't care), and users will be the > > ones enabling it (because they do care), just to learn that developers > > don't care and go complaining to the mailing lists that users dare > > report issues they don't care about. > > I care if the patch is actually broken, which the warning doesn't > really tell me. It's just not a very reliable indicator, and will > produce false-positives frequently. > You can also take less context into the patch and use -F0. Then you'll have the same effect, no warnings to bother you and no pretending that the patch applies when it doesn't. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: > Just like 'many of the proposals lately', developers are going to be > the ones disabling it (because they don't care), and users will be the > ones enabling it (because they do care), just to learn that developers > don't care and go complaining to the mailing lists that users dare > report issues they don't care about. I care if the patch is actually broken, which the warning doesn't really tell me. It's just not a very reliable indicator, and will produce false-positives frequently.
[gentoo-dev] RFC: acct-{user,group} for milter (438)
The mail-filter/milter-regex ebuild already uses user/group 'milter', and for the currently open bump to version 2.7 I'd like to claim GID/UID 438. I have checked the assignment list[1] and used Notmuch for a full text search of previous mentions of GID/UID 438. From what I can tell, 438 has not been requested before. -Ralph
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, 2019-12-13 at 21:31 +0100, Fabian Groffen wrote: > On 13-12-2019 14:24:33 -0500, Michael Orlitzky wrote: > > On 12/13/19 9:28 AM, Fabian Groffen wrote: > > > We are providing those patches, maybe. In reality very often the > > > patches originate from somewhere else though. And you don't want to > > > have to respin all of those just because. At least that's what I feel. > > > > > > > Just because... the context changed? A new "!" in a line of context can > > be the difference between letting someone log in with the right password > > and letting them log in with the wrong password. You should at least > > have to stop and verify that the patch does what you think it does when > > it "gains" fuzz. And at that point, git diff will give you a clean > > version of it. > > Counter argument is that we've been doing this for decades, and always > relied on maintainers to check the contents of their patches, without > problems. We didn't introduce a predictable random number generator or > something. Is this really an argument for or *against* it? Developers are entirely capable of keeping seds that do nothing for years, as well as patches that -- while apparently applying correctly -- are entirely meaningless. Should I remind you that epatch was entirely capable of creating meaningless files by randomly applying the wrong patch level? > Your very specific example just illustrates the niche this proposal is > targetting. > > As with many of the proposals lately, they just seem to aim at more work > for individual maintainers, with a very low gain ratio. > Better, allow this to be a FEATURE, or whatever, that devs should enable, > but don't spit this in the user's face by default. > Just like 'many of the proposals lately', developers are going to be the ones disabling it (because they don't care), and users will be the ones enabling it (because they do care), just to learn that developers don't care and go complaining to the mailing lists that users dare report issues they don't care about. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 13-12-2019 14:24:33 -0500, Michael Orlitzky wrote: > On 12/13/19 9:28 AM, Fabian Groffen wrote: > > > > We are providing those patches, maybe. In reality very often the > > patches originate from somewhere else though. And you don't want to > > have to respin all of those just because. At least that's what I feel. > > > > Just because... the context changed? A new "!" in a line of context can > be the difference between letting someone log in with the right password > and letting them log in with the wrong password. You should at least > have to stop and verify that the patch does what you think it does when > it "gains" fuzz. And at that point, git diff will give you a clean > version of it. Counter argument is that we've been doing this for decades, and always relied on maintainers to check the contents of their patches, without problems. We didn't introduce a predictable random number generator or something. Your very specific example just illustrates the niche this proposal is targetting. As with many of the proposals lately, they just seem to aim at more work for individual maintainers, with a very low gain ratio. Better, allow this to be a FEATURE, or whatever, that devs should enable, but don't spit this in the user's face by default. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: dev-python/*
On Fri, 2019-12-13 at 13:56 -0500, Aaron Bauman wrote: > # Aaron Bauman (2019-12-13) > # These are (mostly) leaf packages with only py2.7 > # Please review commit msg. Removal in 30 days > dev-python/python-daap > dev-python/dbutils > dev-python/pychecker > dev-python/pyosd > dev-python/python-digest > dev-python/ed2551911 > dev-python/quixote It's last rited already. > dev-python/shm > dev-python/fpconst > dev-python/pysctp > dev-python/pyamazon > dev-python/rackspace-monitoring-cli > dev-python/pyptlib > dev-python/librharris > dev-python/simples3 > dev-python/pyxenstore > dev-python/yolk > dev-python/yolk-portage > dev-python/reconfigure > dev-python/flask-evolution > dev-python/carrot > dev-python/python-biggles > dev-python/py-xmlrpc > dev-python/sampy > dev-python/pychart > dev-python/bjoern > dev-python/arrayterator > dev-python/mocker > dev-python/cfgparse > dev-python/pyutmp > dev-python/dingus > dev-python/functest Sort them, please. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: sci-electronics/oregano
On Fri, 2019-12-13 at 13:09 -0500, Aaron Bauman wrote: > # Aaron Bauman (2019-12-13) > # Dead upstream. Fork is available at https://github.com/drahnr/oregano > # Removal in 30 days > sci-electronics/oregano > I suppose it would be more helpful to users to tell them that it's packaged as sci-electronics/drahnr-oregano. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 12/13/19 6:28 AM, Fabian Groffen wrote: > On 13-12-2019 15:24:40 +0100, Michał Górny wrote: ...and why do we consider it correct to apply patches when the context doesn't match? If our only goal is to make things 'easier' for 'everyone', then we could just pass -F and ignore all the context. Though I don't understand why include any context in the first place if you don't care about it matching. Sounds like a waste of space to me! >>> >>> The patch command defaults to -F2. If that makes no sense, why is it >>> the upstream default? >>> >> >> You should ask upstream, not me. But if I were to guess, the answer >> would be because patch(1) is used by random people trying to apply >> random patches they've found somewhere. We on the other hand are >> applying patches that *we* are supposed to provide. > > We are providing those patches, maybe. In reality very often the > patches originate from somewhere else though. And you don't want to > have to respin all of those just because. At least that's what I feel. Yeah, the QA Notice is apparently intended for downstream patches that require frequent rebase, while it doesn't make much sense for patches that are cherry-picked from upstream. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 12/13/19 9:28 AM, Fabian Groffen wrote: > > We are providing those patches, maybe. In reality very often the > patches originate from somewhere else though. And you don't want to > have to respin all of those just because. At least that's what I feel. > Just because... the context changed? A new "!" in a line of context can be the difference between letting someone log in with the right password and letting them log in with the wrong password. You should at least have to stop and verify that the patch does what you think it does when it "gains" fuzz. And at that point, git diff will give you a clean version of it.
[gentoo-dev] Last rites: dev-python/*
# Aaron Bauman (2019-12-13) # These are (mostly) leaf packages with only py2.7 # Please review commit msg. Removal in 30 days dev-python/python-daap dev-python/dbutils dev-python/pychecker dev-python/pyosd dev-python/python-digest dev-python/ed2551911 dev-python/quixote dev-python/shm dev-python/fpconst dev-python/pysctp dev-python/pyamazon dev-python/rackspace-monitoring-cli dev-python/pyptlib dev-python/librharris dev-python/simples3 dev-python/pyxenstore dev-python/yolk dev-python/yolk-portage dev-python/reconfigure dev-python/flask-evolution dev-python/carrot dev-python/python-biggles dev-python/py-xmlrpc dev-python/sampy dev-python/pychart dev-python/bjoern dev-python/arrayterator dev-python/mocker dev-python/cfgparse dev-python/pyutmp dev-python/dingus dev-python/functest -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: sci-electronics/oregano
On Fri, Dec 13, 2019 at 01:09:46PM -0500, Aaron Bauman wrote: > # Aaron Bauman (2019-12-13) > # Dead upstream. Fork is available at https://github.com/drahnr/oregano > # Removal in 30 days > sci-electronics/oregano > > -- > Cheers, > Aaron My apologies. The package is forked as sci-electronics/drahnr-oregano -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: sci-electronics/oregano
# Aaron Bauman (2019-12-13) # Dead upstream. Fork is available at https://github.com/drahnr/oregano # Removal in 30 days sci-electronics/oregano -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: bsdmk.eclass
# @DEAD # All consumers are gone. Removal in 14 days signature.asc Description: This is a digitally signed message part
[gentoo-dev] Eclasses up for grabs: findlib.eclass, oasis.eclass, opam.eclass
Hello, The following eclasses are looking for a new maintainer: findlib.eclass oasis.eclass opam.eclass The first one hasn't been touched since 2011. The other two are a little newer but all need cleanup/modernization. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 13-12-2019 15:24:40 +0100, Michał Górny wrote: > > > ...and why do we consider it correct to apply patches when the context > > > doesn't match? If our only goal is to make things 'easier' for > > > 'everyone', then we could just pass -F and ignore all the context. > > > > > > Though I don't understand why include any context in the first place if > > > you don't care about it matching. Sounds like a waste of space to me! > > > > The patch command defaults to -F2. If that makes no sense, why is it > > the upstream default? > > > > You should ask upstream, not me. But if I were to guess, the answer > would be because patch(1) is used by random people trying to apply > random patches they've found somewhere. We on the other hand are > applying patches that *we* are supposed to provide. We are providing those patches, maybe. In reality very often the patches originate from somewhere else though. And you don't want to have to respin all of those just because. At least that's what I feel. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, 2019-12-13 at 09:06 -0500, Mike Gilbert wrote: > On Fri, Dec 13, 2019 at 8:52 AM Michał Górny wrote: > > On Fri, 2019-12-13 at 08:47 -0500, Mike Gilbert wrote: > > > On Thu, Dec 12, 2019 at 3:15 PM Ulrich Mueller wrote: > > > > > > > > > On Thu, 12 Dec 2019, Mike Gilbert wrote: > > > > > I think this should be reverted. It causes too much noise, and > > > > > "solves" a problem only very rarely. > > > > > > > > Now, how many lines of output does this typically produce, compared > > > > to the total size of a typical build log? Especially with mgorny's > > > > subsequent modification, which suppresses the output unless the patch > > > > doesn't apply cleanly. > > > > > > In most cases, I would be inclined to simply ignore the patch output > > > since there's really no need for me to take any action on it. > > > > > > On the other hand, it makes it more difficult to quickly identify the > > > list of patches being applied if there is junk output in the middle of > > > the list. > > > > > > > It was also suggested that we add -F0 in EAPI 8, but that would break > > > > the build in those cases that are producing extra output now. I don't > > > > think that would be preferable. > > > > > > I am opposed to including such a change in EAPI 8. It would make > > > ebuild maintenance more difficult for everyone, and I don't think the > > > potential benefit is worth it. > > > > ...and why do we consider it correct to apply patches when the context > > doesn't match? If our only goal is to make things 'easier' for > > 'everyone', then we could just pass -F and ignore all the context. > > > > Though I don't understand why include any context in the first place if > > you don't care about it matching. Sounds like a waste of space to me! > > The patch command defaults to -F2. If that makes no sense, why is it > the upstream default? > You should ask upstream, not me. But if I were to guess, the answer would be because patch(1) is used by random people trying to apply random patches they've found somewhere. We on the other hand are applying patches that *we* are supposed to provide. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs after ML project being disbanded
Hello, Following my earlier RFC, the ML project is being disbanded. I've already last rited some of its packages. Besides those, the following packages are in need of a new maintainer: app-eselect/eselect-unison app-misc/ledit app-text/htmlc dev-lang/mlton dev-lang/ocaml dev-lang/polyml dev-lang/smlnj dev-ml/alcotest dev-ml/astring dev-ml/async dev-ml/async_extra dev-ml/async_kernel dev-ml/async_rpc_kernel dev-ml/async_ssl dev-ml/async_unix dev-ml/base dev-ml/batteries dev-ml/biniou dev-ml/bin-prot dev-ml/bos dev-ml/calendar dev-ml/camlbz2 dev-ml/camldbm dev-ml/camlidl dev-ml/camlp4 dev-ml/camlp5 dev-ml/camlzip dev-ml/camomile dev-ml/cmdliner dev-ml/configurator dev-ml/core dev-ml/core_extended dev-ml/core_kernel dev-ml/cppo dev-ml/cryptokit dev-ml/csv dev-ml/cudf dev-ml/deriving dev-ml/dns dev-ml/dose3 dev-ml/dune dev-ml/easy-format dev-ml/eliom dev-ml/extlib dev-ml/fieldslib dev-ml/findlib dev-ml/fmt dev-ml/fpath dev-ml/gen dev-ml/integers dev-ml/iTeML dev-ml/jane-street-headers dev-ml/jbuilder dev-ml/js_of_ocaml dev-ml/jsonm dev-ml/lablgl dev-ml/lablgtk dev-ml/labltk dev-ml/logs dev-ml/lwt dev-ml/lwt_react dev-ml/lwt_ssl dev-ml/macaque dev-ml/markup dev-ml/menhir dev-ml/merlin-extend dev-ml/mtime dev-ml/oasis dev-ml/ocaml-autoconf dev-ml/ocaml-base64 dev-ml/ocamlbuild dev-ml/ocaml-cohttp dev-ml/ocaml-compiler-libs dev-ml/ocaml-conduit dev-ml/ocaml-cstruct dev-ml/ocaml-ctypes dev-ml/ocaml-data-notation dev-ml/ocaml-dispatch dev-ml/ocaml-doc dev-ml/ocaml-expat dev-ml/ocaml-expect dev-ml/ocaml-fileutils dev-ml/ocaml-gettext dev-ml/ocamlgraph dev-ml/ocaml-hashcons dev-ml/ocamlify dev-ml/ocaml-ipaddr dev-ml/ocaml-magic-mime dev-ml/ocaml-migrate-parsetree dev-ml/ocamlmod dev-ml/ocamlnet dev-ml/ocaml-re dev-ml/ocamlsdl dev-ml/ocaml-sqlite3 dev-ml/ocaml-ssl dev-ml/ocaml-uri dev-ml/ocamlweb dev-ml/ocplib-endian dev-ml/octavius dev-ml/ocurl dev-ml/opam dev-ml/optcomp dev-ml/ounit dev-ml/parmap dev-ml/patience_diff dev-ml/pcre-ocaml dev-ml/pgocaml dev-ml/ppx_assert dev-ml/ppx_ast dev-ml/ppx_base dev-ml/ppx_bench dev-ml/ppx_bin_prot dev-ml/ppx_compare dev-ml/ppx_core dev-ml/ppx_custom_printf dev-ml/ppx_derivers dev-ml/ppx_deriving dev-ml/ppx_driver dev-ml/ppx_enumerate dev-ml/ppx_expect dev-ml/ppx_fail dev-ml/ppx_fields_conv dev-ml/ppx_hash dev-ml/ppx_here dev-ml/ppx_inline_test dev-ml/ppx_jane dev-ml/ppx_js_style dev-ml/ppx_let dev-ml/ppx_metaquot dev-ml/ppx_optcomp dev-ml/ppx_optional dev-ml/ppx_pipebang dev-ml/ppx_sexp_conv dev-ml/ppx_sexp_message dev-ml/ppx_sexp_value dev-ml/ppx_tools dev-ml/ppx_tools_versioned dev-ml/ppx_traverse dev-ml/ppx_traverse_builtins dev-ml/ppx_type_conv dev-ml/ppx_typerep_conv dev-ml/ppx_variants_conv dev-ml/qcheck dev-ml/re2 dev-ml/react dev-ml/reactiveData dev-ml/result dev-ml/rresult dev-ml/sexplib dev-ml/spawn dev-ml/stdio dev-ml/stringext dev-ml/textutils dev-ml/topkg dev-ml/type-conv dev-ml/typerep dev-ml/tyxml dev-ml/uchar dev-ml/uutf dev-ml/variantslib dev-ml/yojson dev-ml/zarith dev-util/coccinelle dev-util/omake dev-util/patdiff net-misc/unison net-p2p/mldonkey www-servers/ocsigenserver Please note that if nobody takes them, I will probably run a second round of last rites for those that lose all revdeps after the first round. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites (also up for grabs): a long list of dev-ml/* packages with no revdeps
(to reduce duplication, I won't send a separate 'up for grabs' for those packages) # Michał Górny (2019-12-13) # The first part of cleanup post the dead ML project. Those packages # have no reverse dependencies (except one another, in some cases). # Due to lack of interest, we are limiting the Gentoo ML packages # to those that are needed by programs packages for Gentoo. # Many of those packages are outdated and/or buggy. # Removal in 30 days. Bug #695782. dev-ml/ANSITerminal dev-ml/OCaml-ImageMagick dev-ml/angstrom dev-ml/angstrom-async dev-ml/angstrom-lwt-unix dev-ml/angstrom-unix dev-ml/async_js dev-ml/atd dev-ml/atdgen dev-ml/bignum dev-ml/bolt dev-ml/bson dev-ml/camlimages dev-ml/capnp-ocaml dev-ml/core_bench dev-ml/core_profiler dev-ml/dns-async dev-ml/dns-lwt dev-ml/dns-lwt-unix dev-ml/enumerate dev-ml/flow_parser dev-ml/fort dev-ml/gd4o dev-ml/gen_js_api dev-ml/herelib dev-ml/incremental dev-ml/incremental_kernel dev-ml/io-page dev-ml/js-build-tools dev-ml/kaputt dev-ml/lambda-term dev-ml/lwt_glib dev-ml/mccs dev-ml/merlin dev-ml/mirage-profile dev-ml/mongo dev-ml/ocaml-bigstring dev-ml/ocaml-cairo dev-ml/ocaml-containers dev-ml/ocamldap dev-ml/ocamldsort dev-ml/ocaml-extunix dev-ml/ocaml-make dev-ml/ocaml-mysql dev-ml/ocamlpam dev-ml/ocaml-pcap dev-ml/ocaml-redis dev-ml/ocaml-redis-lwt dev-ml/ocaml-redis-sync dev-ml/ocaml-safepass dev-ml/ocaml-sha dev-ml/ocaml-snappy dev-ml/ocaml-stdint dev-ml/ocaml-text dev-ml/ocaml-uint dev-ml/ocaml-webmachine dev-ml/ocaml-websocket dev-ml/ocsigen-i18n dev-ml/ocsigen-start dev-ml/ocsigen-toolkit dev-ml/odns dev-ml/ojquery dev-ml/onanomsg dev-ml/opam-file-format dev-ml/pa_bench dev-ml/pa_ounit dev-ml/pa_sexp_conv dev-ml/pa_structural_sexp dev-ml/pipebang dev-ml/pomap dev-ml/postgresql-ocaml dev-ml/ppx_deriving_yojson dev-ml/ppx_import dev-ml/pxp dev-ml/reason dev-ml/reason-parser dev-ml/res dev-ml/sedlex dev-ml/sequence dev-ml/typerep_extended dev-ml/ulex dev-ml/utop dev-ml/uuidm dev-ml/xmlm dev-ml/xstr dev-ml/zed -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, Dec 13, 2019 at 8:52 AM Michał Górny wrote: > > On Fri, 2019-12-13 at 08:47 -0500, Mike Gilbert wrote: > > On Thu, Dec 12, 2019 at 3:15 PM Ulrich Mueller wrote: > > > > > > > > On Thu, 12 Dec 2019, Mike Gilbert wrote: > > > > I think this should be reverted. It causes too much noise, and > > > > "solves" a problem only very rarely. > > > > > > Now, how many lines of output does this typically produce, compared > > > to the total size of a typical build log? Especially with mgorny's > > > subsequent modification, which suppresses the output unless the patch > > > doesn't apply cleanly. > > > > In most cases, I would be inclined to simply ignore the patch output > > since there's really no need for me to take any action on it. > > > > On the other hand, it makes it more difficult to quickly identify the > > list of patches being applied if there is junk output in the middle of > > the list. > > > > > It was also suggested that we add -F0 in EAPI 8, but that would break > > > the build in those cases that are producing extra output now. I don't > > > think that would be preferable. > > > > I am opposed to including such a change in EAPI 8. It would make > > ebuild maintenance more difficult for everyone, and I don't think the > > potential benefit is worth it. > > ...and why do we consider it correct to apply patches when the context > doesn't match? If our only goal is to make things 'easier' for > 'everyone', then we could just pass -F and ignore all the context. > > Though I don't understand why include any context in the first place if > you don't care about it matching. Sounds like a waste of space to me! The patch command defaults to -F2. If that makes no sense, why is it the upstream default?
Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0
On Thu, Dec 12, 2019 at 4:15 PM Ulrich Mueller wrote: > > > On Thu, 12 Dec 2019, Mike Gilbert wrote: > > > On Wed, Nov 27, 2019 at 11:14 PM Michał Górny wrote: > >> On Wed, 2019-11-27 at 23:49 +0100, Ulrich Mueller wrote: > > >> > The difference is that there is now a QA warning for something that > >> > is perfectly within the spec. Maybe the extra verboseness would be > >> > enough, but the eqawarn line should be omitted? It doesn't provide > >> > any info that isn't already present in the output of patch itself. > >> > >> It helps people understand why some patches throw a wall of text > >> while others don't. > > > It also triggers pointless bug reports. Please remove this. > > I don't like that eqawarn either (see above). > > OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES, > so they won't see the warning? Here's a bug report filed by a user, which is what prompted me to reply on this thread in the first place. https://bugs.gentoo.org/702608
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Fri, 2019-12-13 at 08:47 -0500, Mike Gilbert wrote: > On Thu, Dec 12, 2019 at 3:15 PM Ulrich Mueller wrote: > > > > > > > On Thu, 12 Dec 2019, Mike Gilbert wrote: > > > I think this should be reverted. It causes too much noise, and > > > "solves" a problem only very rarely. > > > > Now, how many lines of output does this typically produce, compared > > to the total size of a typical build log? Especially with mgorny's > > subsequent modification, which suppresses the output unless the patch > > doesn't apply cleanly. > > In most cases, I would be inclined to simply ignore the patch output > since there's really no need for me to take any action on it. > > On the other hand, it makes it more difficult to quickly identify the > list of patches being applied if there is junk output in the middle of > the list. > > > It was also suggested that we add -F0 in EAPI 8, but that would break > > the build in those cases that are producing extra output now. I don't > > think that would be preferable. > > I am opposed to including such a change in EAPI 8. It would make > ebuild maintenance more difficult for everyone, and I don't think the > potential benefit is worth it. ...and why do we consider it correct to apply patches when the context doesn't match? If our only goal is to make things 'easier' for 'everyone', then we could just pass -F and ignore all the context. Though I don't understand why include any context in the first place if you don't care about it matching. Sounds like a waste of space to me! -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On Thu, Dec 12, 2019 at 3:15 PM Ulrich Mueller wrote: > > > On Thu, 12 Dec 2019, Mike Gilbert wrote: > > > I think this should be reverted. It causes too much noise, and > > "solves" a problem only very rarely. > > Now, how many lines of output does this typically produce, compared > to the total size of a typical build log? Especially with mgorny's > subsequent modification, which suppresses the output unless the patch > doesn't apply cleanly. In most cases, I would be inclined to simply ignore the patch output since there's really no need for me to take any action on it. On the other hand, it makes it more difficult to quickly identify the list of patches being applied if there is junk output in the middle of the list. > It was also suggested that we add -F0 in EAPI 8, but that would break > the build in those cases that are producing extra output now. I don't > think that would be preferable. I am opposed to including such a change in EAPI 8. It would make ebuild maintenance more difficult for everyone, and I don't think the potential benefit is worth it.
Re: [gentoo-dev] [PATCH] virtualx.eclass: Append RESTRICT="!test? ( test )" by default
On Thu, 2019-12-12 at 12:14 -0500, Mike Gilbert wrote:
> On Thu, Dec 12, 2019 at 12:02 PM NP-Hardass
> wrote:
> > On 12/11/19 9:58 AM, Michał Górny wrote:
> > > Append RESTRICT="!test? ( test )" in the default case when
> > > virtualx
> > > is conditional to USE=test. This fixes 440 MissingTestRestrict
> > > warnings.
> > >
> > > Signed-off-by: Michał Górny
> > > ---
> > > eclass/virtualx.eclass | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> > > index 40eeea5463bc..6aba6bf488dd 100644
> > > --- a/eclass/virtualx.eclass
> > > +++ b/eclass/virtualx.eclass
> > > @@ -89,6 +89,8 @@ case ${VIRTUALX_REQUIRED} in
> > > fi
> > > RDEPEND=""
> > > IUSE="${VIRTUALX_REQUIRED}"
> > > + [[ ${VIRTUALX_REQUIRED} == test ]] &&
> > > + RESTRICT+=" !test? ( test )"
> > > ;;
> > > esac
> > >
> > >
> >
> > Is there a better way to address this than editing a ton of
> > eclasses
> > independently?
>
> Not really.
>
Seems a good candidate for a future EAPI
