[gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
Tom Wijsman posted on Tue, 03 Sep 2013 23:16:11 +0200 as excerpted: > Currently the logs aren't > search and grep compatible because you have no indication where the last > error is and which process has output that Quite apart from the ansi-color discussion, I've had reasonable luck simply searching/grepping for "error" here. Sure, a lot of packages build *error* files of some sort and they're normally false-positives, but it does cut down the search space considerably, and there's usually only a couple such false-positives to worry about per-package. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On 4 September 2013 08:11, Tom Wijsman wrote: > And then I asked the questions that I'd like to see answered: > > > Why do they not belong there? What do people have to do who want them? > If anyone needs a poster child for the sort of escape sequence outputs that most definitely are of no value to somebody reading the log after the fact, the output from vims' test suite is a good example. Granted, it uses a very wide variety of terminal escape codes, which include, but are not limited to, window resizing control characters. I think given that context, it may be sane to restrict log control characters to a specific subset of control characters, specifically basic colour/highlighting control characters, which are at least somewhat standardized and not too device specific ( not all devices support all colour control characters, or bold/italic/underline control characters, but the negative side effect of not supporting a given control character in this case is minimal ) You could perhaps have an ENV var that controls the manner in which log files are written, say: PORTAGE_LOG_ESCAPES="all" # no stripping of control characters PORTAGE_LOG_ESCAPES="color" # strips all but color control characters PORTAGE_LOG_ESCAPES="color style" # strips all but color/bold/italic/underline/reverse/conceal control characters PORTAGE_LOG_ESCAPES="none" # strip all control characters Somewhere in these control modes somebody needs to define how "\r" and "\b" are treated, simply removing those characters could conceivably make log files worse, not better, because it would reintroduce messages/characters that were not seen by the end user. Perhaps something like PORTAGE_LOG_ESCAPES="erasures:strip" # remove erasure characters PORTAGE_LOG_ESCAPES="erasures:apply" # Apply the logical effect of erasures, deleting characters from the output log to mimic how it would be displayed PORTAGE_LOG_ESCAPES="erasures:keep" # keep \r and \b Either way, if you were to introduce such a variable, you could have a standard defined value that Gentoo agree upon, which I'd imagine might be "none erasures:apply" or something like that, and end users can turn them back on if they want, with a caveat that users should apply a standard stripping to these logs before submitting them to bugzilla, with a tool that comes standard with portage to facilitate stripping logs for submission to bugzilla. This gives users the control they want, the features they want if they need them, and still gives gentoo staff an easier time if it is determined escape codes are not useful for bug reports. -- Kent
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dialup/sendpage: sendpage-1.1.0-r2.ebuild ChangeLog sendpage-1.1.0-r1.ebuild
02.09.2013 19:29, Ian Delaney (idella4) пишет:
> idella4 13/09/02 15:29:57
>
> Modified: ChangeLog
> Added:sendpage-1.1.0-r2.ebuild
> Removed: sendpage-1.1.0-r1.ebuild
> Log:
> revbump -> EAPI 5, remove old
>
> (Portage version: 2.2.0/cvs/Linux x86_64, signed Manifest commit with key
> 0xB8072B0D)
>
> Revision ChangesPath
> 1.13 net-dialup/sendpage/ChangeLog
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?rev=1.13&content-type=text/plain
> diff :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/ChangeLog?r1=1.12&r2=1.13
>
> Index: ChangeLog
> ===
> RCS file: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -r1.12 -r1.13
> --- ChangeLog 14 Jun 2012 01:50:05 - 1.12
> +++ ChangeLog 2 Sep 2013 15:29:57 - 1.13
> @@ -1,6 +1,12 @@
> # ChangeLog for net-dialup/sendpage
> -# Copyright 2000-2012 Gentoo Foundation; Distributed under the GPL v2
> -# $Header: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.12
> 2012/06/14 01:50:05 zmedico Exp $
> +# Copyright 2000-2013 Gentoo Foundation; Distributed under the GPL v2
> +# $Header: /var/cvsroot/gentoo-x86/net-dialup/sendpage/ChangeLog,v 1.13
> 2013/09/02 15:29:57 idella4 Exp $
> +
> +*sendpage-1.1.0-r2 (02 Sep 2013)
> +
> + 02 Sep 2013; Ian Delaney +sendpage-1.1.0-r2.ebuild,
> + -sendpage-1.1.0-r1.ebuild:
> + revbump -> EAPI 5, remove old
>
>14 Jun 2012; Zac Medico sendpage-1.1.0-r1.ebuild:
>inherit user for enewgroup and enewuser
>
>
>
> 1.1 net-dialup/sendpage/sendpage-1.1.0-r2.ebuild
>
> file :
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild?rev=1.1&content-type=text/plain
>
> Index: sendpage-1.1.0-r2.ebuild
> ===
> # Copyright 1999-2013 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header:
> /var/cvsroot/gentoo-x86/net-dialup/sendpage/sendpage-1.1.0-r2.ebuild,v 1.1
> 2013/09/02 15:29:57 idella4 Exp $
>
> EAPI=5
>
> inherit perl-module eutils user
>
> MY_P=${PN}-1.001
> DESCRIPTION="Dialup alphapaging software."
> HOMEPAGE="http://www.sendpage.org/";
> SRC_URI="http://www.sendpage.org/download/${MY_P}.tar.gz";
> S="${WORKDIR}/${MY_P}"
>
> LICENSE="GPL-2"
> SLOT="0"
> KEYWORDS="~amd64 ~ppc ~x86"
> # This package warrants IUSE doc
> IUSE=""
>
> DEPEND="!net-misc/hylafax
> >=dev-perl/Device-SerialPort-0.13
> >=dev-perl/MailTools-1.44
> >=virtual/perl-libnet-1.11
> >=dev-perl/Net-SNPP-1.13
> dev-perl/DBI"
>
> mydoc="FEATURES email2page.conf sendpage.cf snpp.conf"
>
> pkg_setup() {
> enewgroup sms
> enewuser sendpage -1 -1 /var/spool/sendpage sms
> }
>
> PATCHES=( "${FILESDIR}"/${PV}-makefile.patch )
>
> src_install() {
> perl-module_src_install
> insinto /etc
> doins sendpage.cf
> newinitd "${FILESDIR}"/sendpage.initd sendpage
> diropts -o sendpage -g sms -m0770
> keepdir /var/spool/sendpage
> # Separate docs/ content from ${mydoc[@]}
> docompress -x /usr/share/doc/${PF}/text/
> docinto text/
> dodoc docs/*
> }
>
>
>
>
EAPI=5 has no implicit RDEPEND="${DEPEND}". Does this package really has
no run-time dependendies?
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, Sep 03, 2013 at 11:44:45PM +0200, Tom Wijsman wrote > +1 I am still not convinced we are experiencing an actual practical > problem for the majority of the build logs that are attached; we've > been doing this for years, why is it so suddenly considered a problem? As I pointed out in a message to the previous thread... == WARN: prepare It seems that you need to set USE_PYTHON to make sure that legacy packages will be built with respect to PYTHON_TARGETS correctly: USE_PYTHON='.[35;1m2.7.[0m' == See https://bugs.gentoo.org/show_bug.cgi?id=463954 -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
On Tue, Sep 03, 2013 at 01:37:25PM +0200, Michał Górny wrote: > Dnia 2013-09-03, o godz. 12:24:49 > Markos Chandras napisał(a): > > > On 3 September 2013 12:17, Michał Górny wrote: > > > Dnia 2013-09-03, o godz. 11:53:22 > > > Markos Chandras napisał(a): > > > > > >> On 3 September 2013 11:45, Michał Górny wrote: > > >> > Hello, all. > > >> > > > >> > > > >> > I'm attaching git-r3.eclass and a patch to git-2.eclass that adds > > >> > ability to use git-r3 internally via make.conf switch. > > >> > > >> I am a bit skeptical about this. Why would someone want to do this > > >> apart from testing the git-r3 eclass without touching > > >> the existing git-r2 compatible ebuilds? And why do you want to do that in > > >> the first place? If the maintainer is happy with how git-r2 works with > > >> his ebuilds > > >> I see no reason to allow users to silently override that eclass. > > > > > > The goal is to give git-r3 most testing it could get before it gets > > > widely used. I'd prefer catching corner cases sooner than later. > > > > > > -- > > > Best regards, > > > Michał Górny > > > > Ok but I don't think allowing users to override eclasses like this is > > a good thing. > > Maintainers expect the existing ebuilds to work with git-r2. If they > > start getting bugs > > because a user silently overrode the eclass the this is not going to > > be pleasant. > > It is not done silently. It comes with big fat warning at the top: > > + ewarn "Using git-r3 backend in git-2. Not everything is supported." > + ewarn "Expect random failures and have fun testing." I tend also to want to err on the side of caution here. I don't think users should be able to change something in make.conf that affects which eclass an ebuild uses. I would suggest putting a warning in the git-2.eclass that starts encouraging maintainers to migrate their ebuilds to git-r3. William signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
(I think I forgot to mention when I wrote about keeping git-2 around for a while that I like the plan for git-3; that should have been explicit.) It looks good. I haven't worked out what the storage names under EGIT3_STORE_DIR will be for submodules, though. If multiple parent gits want the same submodule, and/or if a package exists for it in its own right, will the same store clone be used for all of them? Including when some use git://, others https://, et al? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] new eclass proposal, perl-mb-tiny.eclass
Please eliminate the call to perl_delete_module_manpages.
perl-module.eclass's malicious abuse of that should not propagate.
The man pages are as valuable as the modules themselves.
I wonder about:
if [[ -z ${mytargets} ]] ; then
case "${CATEGORY}" in
dev-perl|perl-core) mytargets="install" ;;
*) mytargets="install" ;;
esac
fi
Did the case block originally have different results for different CATEGORYs?
Otherwise it looks good. And useful.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On Tue, Sep 03, 2013 at 10:15:39PM +0200, Tom Wijsman wrote > That is not what this is about, this is about having escape sequences > in build logs obtained from Bugzilla; because, they aid in skimming > through logs (until we implement the feature I asked for in subject). "The road to binary syslog files is paved with good intentions", or something like that. Question... why does it have to be escape sequences? Can't it be readable plain text? E.g. something like... //STDERR.OUT.START foo bar blah blah blah //STDERR.OUT.END This would be easy to grep and/or parse in bash. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, 03 Sep 2013 23:10:38 +0200 Alan McKinnon wrote: > On 03/09/2013 23:00, Magnus Granberg wrote: > > tisdag 03 september 2013 22.41.14 skrev Alan McKinnon: > > > >> I *do* like colorized text on my terminal, but I do believe we > >> ought to keep defaults sane - the minimum that could possibly > >> work. Everything extra should be optional > > > > What about NOCOLOR="false" in make.conf see man make.conf for more > > info. /Magnus > > That affects terminal output too. > > It does not seem desirable to force terminal and logs to always have > the same setting. To my mind the sane approach would be individual > config settings for both with sane defaults. This discussion should not be about our users; we should not change user behavior or introduce unnecessary config settings based on a discussion that intends to deal with the build logs that we download from Bugzilla. > But, and here's the catch, that then means one can't simply tee output > to two places. There would have to be two output threads. This seems > like a LOT of work to implement Yes, I believe Zac stated that in another sub thread. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, 3 Sep 2013 17:03:39 -0400 Rich Freeman wrote: > Log files are about capturing information. Escapes are about the > presentation of information - a reporting feature not unlike > pagination/etc. It wouldn't make sense to embed page numbers in a log > file - if they are desired they should be added at the time the > information is presented, just like escape sequences. Exactly, and the only way to add them when you present them is by adding more information to the build log (eg. see subject for a start) such that at presentation time a viewer can use this information to color it; that way, you don't need the escape sequences anymore, because you've made the build log more useful. Or in other words, that allows people to search and filter it much more efficiently; why try to match what might be an error if we can get the stderr output of the last process instead? > It seems to me that the cleaner situation would be to capture > information in the logs, and use a pretty-printer of some kind to make > it look nice. That is the idea I try to from with this new subject; either I would like to see more information that allows me to more efficiently deal with the build log, if not stick with the escape sequences if people object; but if we end up with neither of both it is going to be a step backward that bothers all the people who rely on this feature. > Terminate output should be made to look nice when > directed at a terminal. +1 Please don't make us go back to scrolling through black and white. > Of course, the ultimate result of the whole logs-are-information > concept is something like the systemd journal, but I won't go there. It's a prime example; though, we probably might want to write our own format and tools because we have quite a different goal. > I'm not sure that would really help here - the challenge is more about > the actual content and not the metadata. It really is about both, not just content; reconsider metadata, that's the key to log parsing and from there on we get more efficient searching (last error lines), indexing (tinderbox) and so on ... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, 3 Sep 2013 17:17:49 -0400 Rich Freeman wrote: > On Tue, Sep 3, 2013 at 5:12 PM, Michał Górny > wrote: > > How would you handle progress reporting with this? Something like > > 'capture one thousand lines of updated percentages and merge them > > with a magical pretty printer'? I don't see real gain compared to > > what we have now. > > There is no value of sending incremental progress reporting to the log > in the first place. > > However, as Alan already pointed out, implementing this isn't trivial. > You could have a variation on tee that just strips out the junk, but > it isn't really the same as having fit-for-purpose output streams, > perhaps taking as input a highly structured raw log format like xml. > You'll never get that from a diverse set of build systems. Starting lines with something like STDERR:NAME:PID: would be a good start; xml would indeed be overkill, let's keep it a textual file with a minimal amount of currently missing information we need to add. I'm not asking for magically discovering missing details; what I am asking for, is that details that are known but not currently inserted in the build log be made available in the build log so we can use them. Currently, there is no indication which process outputs what on which stream; so, this often leaves us wonder "is this an actual error" and "which process did output this" (for less common build utilities). On top of that, inserting lines for processes that return a non-zero code would also be neat to have; because then you can obtain which process fails (NAME:PID pair) and output its last stderr lines. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, Sep 3, 2013 at 5:22 PM, Alan McKinnon wrote: > On 03/09/2013 23:03, Rich Freeman wrote: >> It seems to me that the cleaner situation would be to capture >> information in the logs, and use a pretty-printer of some kind to make >> it look nice. Terminate output should be made to look nice when >> directed at a terminal. > > This implies that the log can only then be viewed with a pretty-printer. The log would just contain the information - you could view it with cat. If you wanted to view it with colorized escape codes then you'd use the pretty-printer. The pretty-printer wouldn't strip out escape codes - it would add them. Of course, this means that the printer would need to be able to parse the log output. The alternative is something like journal where you load up the log with metadata and have to use a formatting program to display it. Arguably that is what directing escape codes to a log does - it just isn't fielded like journal, but also somewhat easier to view without special software. I do agree that none of this seems terribly practical. I think the furthest I'd take this is just optionally stripping escape codes when dumping to a log (tee on steroids), and leave it at that. Rich
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, 03 Sep 2013 23:22:21 +0200 Alan McKinnon wrote: > So do what we've always done in Unix-land: leave the decision up to > the user. Build logs can always be regenerated (run emerge again) if > the ANSI sequences truly are vital whilst troubleshooting a specific > log. And we already do this for localized logs if the dev can't make > sense of non-English messages. It only becomes a problem if the log > is for one of that small number of loong builds (libreoffice, > kdelibs etc) +1 I am still not convinced we are experiencing an actual practical problem for the majority of the build logs that are attached; we've been doing this for years, why is it so suddenly considered a problem? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On 03/09/2013 23:03, Rich Freeman wrote:
> On Tue, Sep 3, 2013 at 4:41 PM, Alan McKinnon wrote:
>> The solution is obvious - default to writing plain text to log files and
>> give the user an option to enable escapes in the log if {s,}he chooses
>> to have it. This does mean you can't use tricks with tee.
>
> Not sure it is so obvious.
>
> Log files are about capturing information. Escapes are about the
> presentation of information - a reporting feature not unlike
> pagination/etc. It wouldn't make sense to embed page numbers in a log
> file - if they are desired they should be added at the time the
> information is presented, just like escape sequences.
>
> It seems to me that the cleaner situation would be to capture
> information in the logs, and use a pretty-printer of some kind to make
> it look nice. Terminate output should be made to look nice when
> directed at a terminal.
This implies that the log can only then be viewed with a pretty-printer.
I wouldn't want to be the maintainer that has to deal with outraged
users if that becomes the case.
> Of course, the ultimate result of the whole logs-are-information
> concept is something like the systemd journal, but I won't go there.
> I'm not sure that would really help here - the challenge is more about
> the actual content and not the metadata.
So do what we've always done in Unix-land: leave the decision up to the
user. Build logs can always be regenerated (run emerge again) if the
ANSI sequences truly are vital whilst troubleshooting a specific log.
And we already do this for localized logs if the dev can't make sense of
non-English messages. It only becomes a problem if the log is for one of
that small number of loong builds (libreoffice, kdelibs etc)
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, Sep 3, 2013 at 5:12 PM, Michał Górny wrote: > How would you handle progress reporting with this? Something like > 'capture one thousand lines of updated percentages and merge them with > a magical pretty printer'? I don't see real gain compared to what we > have now. There is no value of sending incremental progress reporting to the log in the first place. However, as Alan already pointed out, implementing this isn't trivial. You could have a variation on tee that just strips out the junk, but it isn't really the same as having fit-for-purpose output streams, perhaps taking as input a highly structured raw log format like xml. You'll never get that from a diverse set of build systems. Rich
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, 03 Sep 2013 22:41:14 +0200
Alan McKinnon wrote:
> escape sequences in logs (any kind of logs) are basically noise, they
> make search and grep hard to use.
But then why not implement matters that actually make search and grep
easier to use, see the new subject for example. Currently the logs
aren't search and grep compatible because you have no indication where
the last error is and which process has output that; and changing
escape sequences won't do anything about that, this isn't an argument.
> They also make the log impossible to
> read properly if your terminal type is not the same as what was in
> effect when the log was created.
Haven't experienced this, can you give me two attachments from
Bugzilla where at least one of both will display incorrectly for me?
It's easy to say, but I bet it is extremely hard to find; if I can't
find them, they must be very rare. Can you find them?
> And they are essentially candy. A log
> without escapes that you wish had them is still usable.
Since I have to deal with logs a lot, I'd rather work with the most
usable logs; until subject is implemented, escape codes do help me.
> A log with escapes you wish were absent is impossible to use sanely.
Then why do I never have problems with this? Why not strip them?
> The solution is obvious - default to writing plain text to log files
> and give the user an option to enable escapes in the log if {s,}he
> chooses to have it. This does mean you can't use tricks with tee.
What are you trying to solve here? This is not about the users; from
their perspective, I can only hope that the functionality will stay the
same as they don't have a problem with it, some maintainers do...
> I *do* like colorized text on my terminal, but I do believe we ought
> to keep defaults sane - the minimum that could possibly work.
> Everything extra should be optional
Sorry, but I'd rather get the most out of build logs; by being
restricted to minimum output, it takes more time to find the relevant
details from the build log.
If you're trying to more efficiently parse logs; consider adding more
information instead, because dropping information does not really gain.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On 03/09/2013 23:00, Magnus Granberg wrote: > tisdag 03 september 2013 22.41.14 skrev Alan McKinnon: > >> I *do* like colorized text on my terminal, but I do believe we ought to >> keep defaults sane - the minimum that could possibly work. Everything >> extra should be optional > > What about NOCOLOR="false" in make.conf see man make.conf for more info. > /Magnus That affects terminal output too. It does not seem desirable to force terminal and logs to always have the same setting. To my mind the sane approach would be individual config settings for both with sane defaults. But, and here's the catch, that then means one can't simply tee output to two places. There would have to be two output threads. This seems like a LOT of work to implement -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On Tue, Sep 3, 2013 at 4:41 PM, Alan McKinnon wrote:
> The solution is obvious - default to writing plain text to log files and
> give the user an option to enable escapes in the log if {s,}he chooses
> to have it. This does mean you can't use tricks with tee.
Not sure it is so obvious.
Log files are about capturing information. Escapes are about the
presentation of information - a reporting feature not unlike
pagination/etc. It wouldn't make sense to embed page numbers in a log
file - if they are desired they should be added at the time the
information is presented, just like escape sequences.
It seems to me that the cleaner situation would be to capture
information in the logs, and use a pretty-printer of some kind to make
it look nice. Terminate output should be made to look nice when
directed at a terminal.
Of course, the ultimate result of the whole logs-are-information
concept is something like the systemd journal, but I won't go there.
I'm not sure that would really help here - the challenge is more about
the actual content and not the metadata.
Rich
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
tisdag 03 september 2013 22.41.14 skrev Alan McKinnon: > I *do* like colorized text on my terminal, but I do believe we ought to > keep defaults sane - the minimum that could possibly work. Everything > extra should be optional What about NOCOLOR="false" in make.conf see man make.conf for more info. /Magnus
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
Dnia 2013-09-03, o godz. 17:03:39
Rich Freeman napisał(a):
> On Tue, Sep 3, 2013 at 4:41 PM, Alan McKinnon wrote:
> > The solution is obvious - default to writing plain text to log files and
> > give the user an option to enable escapes in the log if {s,}he chooses
> > to have it. This does mean you can't use tricks with tee.
>
> Not sure it is so obvious.
>
> Log files are about capturing information. Escapes are about the
> presentation of information - a reporting feature not unlike
> pagination/etc. It wouldn't make sense to embed page numbers in a log
> file - if they are desired they should be added at the time the
> information is presented, just like escape sequences.
>
> It seems to me that the cleaner situation would be to capture
> information in the logs, and use a pretty-printer of some kind to make
> it look nice. Terminate output should be made to look nice when
> directed at a terminal.
How would you handle progress reporting with this? Something like
'capture one thousand lines of updated percentages and merge them with
a magical pretty printer'? I don't see real gain compared to what we
have now.
Except that now escape sequences cause that thousand lines to be just
one ultimately long line with escapes in the editor.
You can't strip logs out of information and then magically inject it
back without having it somewhere. It just can't work.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
On 03/09/2013 22:11, Tom Wijsman wrote:
> On Tue, 3 Sep 2013 14:03:14 -0500
> William Hubbs wrote:
>
>> On Tue, Sep 03, 2013 at 10:25:19AM +0200, Ulrich Mueller wrote:
On Tue, 3 Sep 2013, Tom Wijsman wrote:
>>>
On Mon, 2 Sep 2013 14:21:52 -0500
William Hubbs wrote:
>>>
> I can see why someone might want to use escape codes for color
> displays, etc. However, imo, escape codes do not belong in log
> files.
>>>
They belong there so future display can remain colorful.
>>>
Why do they not belong there? What do people have to do who want
them?
>>>
>>> Escape sequences have been designed for communication with
>>> peripheral devices, not for markup or as a storage format.
>>>
>>> Also "future colorful display" generally won't be portabe because
>>> escape sequences depend on the setting of the TERM variable. (And
>>> again, software that emits them with TERM=dumb or TERM unset is
>>> broken.)
>>
>> Ulrich has summed this up well here. The bottom line is that escape
>> sequences are for communicating with the user's peripheral devices.
>
> Nice summary. But, it is also communicating with my peripheral device.
>
>> Since yours may not be the same as the user's who created the log, you
>> don't even know that yours will respond the same way.
>
> Sounds like something we need to standardize. Although, from the many
> build logs I have came across; it does respond fairly well in most of
> the cases, I am yet to come across a build log that displays bad.
>
> And for that occasional build log, stripping isn't a hard thing to do.
>
>> I don't care what goes to the user's terminal, but these escape
>> sequences do not belong in log files.
>
> And then I asked the questions that I'd like to see answered:
>
> Why do they not belong there? What do people have to do who want them?
>
escape sequences in logs (any kind of logs) are basically noise, they
make search and grep hard to use. They also make the log impossible to
read properly if your terminal type is not the same as what was in
effect when the log was created. And they are essentially candy. A log
without escapes that you wish had them is still usable. A log with
escapes you wish were absent is impossible to use sanely.
The solution is obvious - default to writing plain text to log files and
give the user an option to enable escapes in the log if {s,}he chooses
to have it. This does mean you can't use tricks with tee.
I *do* like colorized text on my terminal, but I do believe we ought to
keep defaults sane - the minimum that could possibly work. Everything
extra should be optional
--
Alan McKinnon
alan.mckin...@gmail.com
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On Tue, 3 Sep 2013 15:43:44 -0400
"Walter Dnes" wrote:
> Similar to...
>
> USE="foo bar" emerge blah blah blah
>
> ...can the average user do something like...
>
> TERM="dumb" emerge blah blah blah
That sounds like a very rare occasion, from all the bugs I have dealt
with I have not seen any dumb terminal escape codes so far. And if
there would be one, it wouldn't be hard to strip them for that one...
> I don't believe very many users or admins babysit an entire 2 hour
> "emerge --deep --update @world" session, hitting {CTRL-S} when some
> colour pops up.
That is not what this is about, this is about having escape sequences
in build logs obtained from Bugzilla; because, they aid in skimming
through logs (until we implement the feature I asked for in subject).
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On Tue, 3 Sep 2013 14:03:14 -0500 William Hubbs wrote: > On Tue, Sep 03, 2013 at 10:25:19AM +0200, Ulrich Mueller wrote: > > > On Tue, 3 Sep 2013, Tom Wijsman wrote: > > > > > On Mon, 2 Sep 2013 14:21:52 -0500 > > > William Hubbs wrote: > > > > >> I can see why someone might want to use escape codes for color > > >> displays, etc. However, imo, escape codes do not belong in log > > >> files. > > > > > They belong there so future display can remain colorful. > > > > > Why do they not belong there? What do people have to do who want > > > them? > > > > Escape sequences have been designed for communication with > > peripheral devices, not for markup or as a storage format. > > > > Also "future colorful display" generally won't be portabe because > > escape sequences depend on the setting of the TERM variable. (And > > again, software that emits them with TERM=dumb or TERM unset is > > broken.) > > Ulrich has summed this up well here. The bottom line is that escape > sequences are for communicating with the user's peripheral devices. Nice summary. But, it is also communicating with my peripheral device. > Since yours may not be the same as the user's who created the log, you > don't even know that yours will respond the same way. Sounds like something we need to standardize. Although, from the many build logs I have came across; it does respond fairly well in most of the cases, I am yet to come across a build log that displays bad. And for that occasional build log, stripping isn't a hard thing to do. > I don't care what goes to the user's terminal, but these escape > sequences do not belong in log files. And then I asked the questions that I'd like to see answered: Why do they not belong there? What do people have to do who want them? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On Tue, Sep 03, 2013 at 10:25:19AM +0200, Ulrich Mueller wrote
> Escape sequences have been designed for communication with peripheral
> devices, not for markup or as a storage format.
>
> Also "future colorful display" generally won't be portabe because
> escape sequences depend on the setting of the TERM variable. (And
> again, software that emits them with TERM=dumb or TERM unset is
> broken.)
Similar to...
USE="foo bar" emerge blah blah blah
...can the average user do something like...
TERM="dumb" emerge blah blah blah
I don't believe very many users or admins babysit an entire 2 hour
"emerge --deep --update @world" session, hitting {CTRL-S} when some
colour pops up. In my case, I examine /var/log/portage/elog after the
emerge finishes, successfully or unsuccessfully. And I don't use an
"editor" to view log files. I use mc (Midnight Commander) which views
plain text, but doesn't decode ANSI. A nice feature of mc is that I can
sort the file list by various options. When looking at emerge output in
/var/log/portage/elog, I want to sort by file-modify-time, so I can
easily see which files were output in the most recent emerge run.
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] git-r3: initial draft for review [v2]
On Mon, Sep 02, 2013 at 01:33:19PM +0200, Micha?? Górny wrote > Dnia 2013-09-01, o godz. 16:49:34 > William Hubbs napisa??(a): > > > Please don't. I also do not want escape sequences in log files. > > Ok, '--color' removed. However, I think we should work something out to > get both parties satisfied. Maybe portage feature or a tool to 'uncruft' > logs from escape sequences since many people actually benefit from them. As per my bug https://bugs.gentoo.org/show_bug.cgi?id=463954 it is a pain. Try figuring out the following as viewed in mc (Midnight Commander)... > WARN: prepare > It seems that you need to set USE_PYTHON to make sure that legacy > packages will be built with respect to PYTHON_TARGETS correctly: > > USE_PYTHON='.[35;1m2.7.[0m' Note that... grep foo bar.txt ...returns colour-highlighted text, while... grep foo bar.txt > output.txt ...returns plain text. So it can be done properly for everybody. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
On Tue, Sep 03, 2013 at 10:25:19AM +0200, Ulrich Mueller wrote: > > On Tue, 3 Sep 2013, Tom Wijsman wrote: > > > On Mon, 2 Sep 2013 14:21:52 -0500 > > William Hubbs wrote: > > >> I can see why someone might want to use escape codes for color > >> displays, etc. However, imo, escape codes do not belong in log files. > > > They belong there so future display can remain colorful. > > > Why do they not belong there? What do people have to do who want > > them? > > Escape sequences have been designed for communication with peripheral > devices, not for markup or as a storage format. > > Also "future colorful display" generally won't be portabe because > escape sequences depend on the setting of the TERM variable. (And > again, software that emits them with TERM=dumb or TERM unset is > broken.) Ulrich has summed this up well here. The bottom line is that escape sequences are for communicating with the user's peripheral devices. Since yours may not be the same as the user's who created the log, you don't even know that yours will respond the same way. I don't care what goes to the user's terminal, but these escape sequences do not belong in log files. William signature.asc Description: Digital signature
[gentoo-dev] Re: rfc: escape sequences in logs
Ulrich Mueller posted on Tue, 03 Sep 2013 15:01:28 +0200 as excerpted: > [Please check your e-mail agent. The "References:" header in your > posting was broken.] Thanks. Upstream is aware of the bug but hasn't patched it yet. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: rfc: escape sequences in logs
> On Tue, 3 Sep 2013, Duncan wrote: [Please check your e-mail agent. The "References:" header in your posting was broken.] > Zac mentioned in a different subthread that portage's logger is > single-threaded ATM, and could become a bottleneck if it had to do > too much output processing. > How feasible might it be to make something like this a (possibly > optional but presumably enabled by default) portage dep, and set > portage's default logging to use it when writing the log file (as > opposed to the screen output)? Presumably that would pipe to another > app to do the actual logfile filtering and writing, so the threading > issue would disappear. > Actually, presuming there's already a python implementation to > parallel that perl one, it's possible the only thing that would need > changed would be portage's default logging command. Pythonistas? Isn't it just a matter of regexp matching? For example, Emacs' ansi-color.el discards any string that matches \[\([ABCDsuK]\|2J\|=[0-9]+[hI]\|[0-9;]*[Hfm]\) and it seems to work in the common cases. Ulrich
[gentoo-dev] Re: rfc: escape sequences in logs
Kent Fredric posted on Tue, 03 Sep 2013 11:59:13 +1200 as excerpted: > And it is quite simple to remove escape sequences from log files if I > desire it. > > using: app-text/ansifilter > > zcat > /var/log/portage/build/app-accessibility/at-spi2- core-2.6.3:20130825-143158.log.gz > | ansifilter > > using perl and Term::ANSIColor ( standard issue with Perl itself ) > > zcat > /var/log/portage/build/app-accessibility/at-spi2- core-2.6.3:20130825-143158.log.gz > | perl -MTerm::ANSIColor=colorstrip -ple '$_ = colorstrip($_)' This has long bothered me, but not enough to be worth investigating myself... Zac mentioned in a different subthread that portage's logger is single- threaded ATM, and could become a bottleneck if it had to do too much output processing. How feasible might it be to make something like this a (possibly optional but presumably enabled by default) portage dep, and set portage's default logging to use it when writing the log file (as opposed to the screen output)? Presumably that would pipe to another app to do the actual logfile filtering and writing, so the threading issue would disappear. Actually, presuming there's already a python implementation to parallel that perl one, it's possible the only thing that would need changed would be portage's default logging command. Pythonistas? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: git-r3: initial draft for review [v2]
Michał Górny posted on Mon, 02 Sep 2013 13:33:19 +0200 as excerpted: >> Please don't. I also do not want escape sequences in log files. > > Ok, '--color' removed. However, I think we should work something out to > get both parties satisfied. Maybe portage feature or a tool to 'uncruft' > logs from escape sequences since many people actually benefit from them. ++ -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
Dnia 2013-09-03, o godz. 12:24:49 Markos Chandras napisał(a): > On 3 September 2013 12:17, Michał Górny wrote: > > Dnia 2013-09-03, o godz. 11:53:22 > > Markos Chandras napisał(a): > > > >> On 3 September 2013 11:45, Michał Górny wrote: > >> > Hello, all. > >> > > >> > > >> > I'm attaching git-r3.eclass and a patch to git-2.eclass that adds > >> > ability to use git-r3 internally via make.conf switch. > >> > >> I am a bit skeptical about this. Why would someone want to do this > >> apart from testing the git-r3 eclass without touching > >> the existing git-r2 compatible ebuilds? And why do you want to do that in > >> the first place? If the maintainer is happy with how git-r2 works with > >> his ebuilds > >> I see no reason to allow users to silently override that eclass. > > > > The goal is to give git-r3 most testing it could get before it gets > > widely used. I'd prefer catching corner cases sooner than later. > > > > -- > > Best regards, > > Michał Górny > > Ok but I don't think allowing users to override eclasses like this is > a good thing. > Maintainers expect the existing ebuilds to work with git-r2. If they > start getting bugs > because a user silently overrode the eclass the this is not going to > be pleasant. It is not done silently. It comes with big fat warning at the top: + ewarn "Using git-r3 backend in git-2. Not everything is supported." + ewarn "Expect random failures and have fun testing." -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
On 3 September 2013 12:17, Michał Górny wrote: > Dnia 2013-09-03, o godz. 11:53:22 > Markos Chandras napisał(a): > >> On 3 September 2013 11:45, Michał Górny wrote: >> > Hello, all. >> > >> > >> > I'm attaching git-r3.eclass and a patch to git-2.eclass that adds >> > ability to use git-r3 internally via make.conf switch. >> >> I am a bit skeptical about this. Why would someone want to do this >> apart from testing the git-r3 eclass without touching >> the existing git-r2 compatible ebuilds? And why do you want to do that in >> the first place? If the maintainer is happy with how git-r2 works with >> his ebuilds >> I see no reason to allow users to silently override that eclass. > > The goal is to give git-r3 most testing it could get before it gets > widely used. I'd prefer catching corner cases sooner than later. > > -- > Best regards, > Michał Górny Ok but I don't think allowing users to override eclasses like this is a good thing. Maintainers expect the existing ebuilds to work with git-r2. If they start getting bugs because a user silently overrode the eclass the this is not going to be pleasant. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
Dnia 2013-09-03, o godz. 11:53:22 Markos Chandras napisał(a): > On 3 September 2013 11:45, Michał Górny wrote: > > Hello, all. > > > > > > I'm attaching git-r3.eclass and a patch to git-2.eclass that adds > > ability to use git-r3 internally via make.conf switch. > > I am a bit skeptical about this. Why would someone want to do this > apart from testing the git-r3 eclass without touching > the existing git-r2 compatible ebuilds? And why do you want to do that in > the first place? If the maintainer is happy with how git-r2 works with > his ebuilds > I see no reason to allow users to silently override that eclass. The goal is to give git-r3 most testing it could get before it gets widely used. I'd prefer catching corner cases sooner than later. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
Dnia 2013-09-03, o godz. 13:09:50
Ulrich Mueller napisał(a):
> > On Tue, 3 Sep 2013, Michał Górny wrote:
>
> > Please do the final review the eclasses. Unless someone finds large
> > issues with them, I'm going to commit them in a few days.
>
> In git-r3_pkg_outofdate():
>
> ewarn "old: ${EGIT_VERSION}"
> ewarn "new: ${new_commit_id}"
>
> This is just part of the normal operation, so it shouldn't be a
> warning.
Oh, that was rather supposed to be debug-print. Though some kind
of einfo would be fine as well.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
> On Tue, 3 Sep 2013, Michał Górny wrote:
> Please do the final review the eclasses. Unless someone finds large
> issues with them, I'm going to commit them in a few days.
In git-r3_pkg_outofdate():
ewarn "old: ${EGIT_VERSION}"
ewarn "new: ${new_commit_id}"
This is just part of the normal operation, so it shouldn't be a
warning.
Ulrich
Re: [gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
On 3 September 2013 11:45, Michał Górny wrote: > Hello, all. > > > I'm attaching git-r3.eclass and a patch to git-2.eclass that adds > ability to use git-r3 internally via make.conf switch. I am a bit skeptical about this. Why would someone want to do this apart from testing the git-r3 eclass without touching the existing git-r2 compatible ebuilds? And why do you want to do that in the first place? If the maintainer is happy with how git-r2 works with his ebuilds I see no reason to allow users to silently override that eclass. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
[gentoo-dev] RFC: final version of git-r3 (+ compat for git-2)
Hello, all.
Here's the final version of git-r3.eclass. Features were detailed
in the previous thread [1] already. I've applied a few more polishes
and added more helpful quirks to make migration less painful.
I'm attaching git-r3.eclass and a patch to git-2.eclass that adds
ability to use git-r3 internally via make.conf switch. This is intended
to allow heavy testing most of the new eclass without need to actually
convert ebuilds first.
Please do the final review the eclasses. Unless someone finds large
issues with them, I'm going to commit them in a few days.
[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/87922
--
Best regards,
Michał Górny
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: git-r3.eclass
# @MAINTAINER:
# MichaŠGórny
# @BLURB: Eclass for fetching and unpacking git repositories.
# @DESCRIPTION:
# Third generation eclass for easing maitenance of live ebuilds using
# git as remote repository. The eclass supports lightweight (shallow)
# clones and bare clones of submodules.
case "${EAPI:-0}" in
0|1|2|3|4|5)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
if [[ ! ${_GIT_R3} ]]; then
inherit eutils
fi
EXPORT_FUNCTIONS src_unpack
if [[ ! ${_GIT_R3} ]]; then
# @ECLASS-VARIABLE: EGIT3_STORE_DIR
# @DESCRIPTION:
# Storage directory for git sources.
#
# EGIT3_STORE_DIR=${DISTDIR}/git3-src
# @ECLASS-VARIABLE: EGIT_REPO_URI
# @REQUIRED
# @DESCRIPTION:
# URIs to the repository, e.g. git://foo, https://foo. If multiple URIs
# are provided, the eclass will consider them as fallback URIs to try
# if the first URI does not work.
#
# It can be overriden via env using ${PN}_LIVE_REPO variable.
#
# Example:
# @CODE
# EGIT_REPO_URI="git://a/b.git https://c/d.git";
# @CODE
# @ECLASS-VARIABLE: EVCS_OFFLINE
# @DEFAULT_UNSET
# @DESCRIPTION:
# If non-empty, this variable prevents any online operations.
# @ECLASS-VARIABLE: EGIT_BRANCH
# @DEFAULT_UNSET
# @DESCRIPTION:
# The branch name to check out. If unset, the upstream default (HEAD)
# will be used.
#
# It can be overriden via env using ${PN}_LIVE_BRANCH variable.
# @ECLASS-VARIABLE: EGIT_COMMIT
# @DEFAULT_UNSET
# @DESCRIPTION:
# The tag name or commit identifier to check out. If unset, newest
# commit from the branch will be used. If set, EGIT_BRANCH will
# be ignored.
#
# It can be overriden via env using ${PN}_LIVE_COMMIT variable.
# @ECLASS-VARIABLE: EGIT_CHECKOUT_DIR
# @DESCRIPTION:
# The directory to check the git sources out to.
#
# EGIT_CHECKOUT_DIR=${WORKDIR}/${P}
# @ECLASS-VARIABLE: EGIT_NONSHALLOW
# @DEFAULT_UNSET
# @DESCRIPTION:
# Disable performing shallow fetches/clones. Shallow clones have
# a fair number of limitations. Therefore, if you'd like the eclass to
# perform complete clones instead, set this to a non-null value.
#
# This variable is to be set in make.conf. Ebuilds are not allowed
# to set it.
# @FUNCTION: _git-r3_env_setup
# @INTERNAL
# @DESCRIPTION:
# Set the eclass variables as necessary for operation. This can involve
# setting EGIT_* to defaults or ${PN}_LIVE_* variables.
_git-r3_env_setup() {
debug-print-function ${FUNCNAME} "$@"
local esc_pn livevar
esc_pn=${PN//[-+]/_}
livevar=${esc_pn}_LIVE_REPO
EGIT_REPO_URI=${!livevar:-${EGIT_REPO_URI}}
[[ ${!livevar} ]] \
&& ewarn "Using ${livevar}, no support will be provided"
livevar=${esc_pn}_LIVE_BRANCH
EGIT_BRANCH=${!livevar:-${EGIT_BRANCH}}
[[ ${!livevar} ]] \
&& ewarn "Using ${livevar}, no support will be provided"
livevar=${esc_pn}_LIVE_COMMIT
EGIT_COMMIT=${!livevar:-${EGIT_COMMIT}}
[[ ${!livevar} ]] \
&& ewarn "Using ${livevar}, no support will be provided"
# Migration helpers. Remove them when git-2 is removed.
if [[ ${EGIT_SOURCEDIR} ]]; then
eerror "EGIT_SOURCEDIR has been replaced by EGIT_CHECKOUT_DIR.
While updating"
eerror "your ebuild, please check whether the variable is
necessary at all"
eerror "since the default has been changed from \${S} to
\${WORKDIR}/\${P}."
eerror "Therefore, proper setting of S may be sufficient."
die "EGIT_SOURCEDIR has been replaced by EGIT_CHECKOUT_DIR."
fi
if [[ ${EGIT_MASTER} ]]; then
eerror "EGIT_MASTER has been removed. Instead, the upstream
default (HEAD)"
eerror "is used by the eclass. Please remove the assignment or
use EGIT_BRANCH"
eerror "as necessary."
die "EGIT_MASTER has been removed."
fi
if [[ ${EGIT_HAS_SUBMODULES} ]]; then
eerror "EGIT_HAS_SUBMODULES has been removed. The eclass no
longer needs"
eerror "to switch the clone type in order to support submodules
and therefo
Re: [gentoo-dev] rfc: escape sequences in logs
> On Tue, 3 Sep 2013, Tobias Klausmann wrote: > My two cents for viewing-logs-in-vim (which is a use case for me): > $ eix ansiesc > * app-vim/ansiesc > Available versions: (~)12 > Homepage:http://www.vim.org/scripts/script.php?script_id=302 > Description: vim plugin: ansi escape sequences concealed, but > highlighted as specified Well, Emacs has this (M-x list-packages): ansi-color 3.4.2built-in translate ANSI escape sequences into faces It doesn't support such broken concepts like escape sequences in files out of the box, so some manual configuration is needed for it. Ulrich
Can we have process names and stdout / stderr indication to more efficiently parse build logs? (was: Re: [gentoo-dev] rfc: escape sequences in logs)
> On Tue, 3 Sep 2013, Tom Wijsman wrote: > On Mon, 2 Sep 2013 14:21:52 -0500 > William Hubbs wrote: >> I can see why someone might want to use escape codes for color >> displays, etc. However, imo, escape codes do not belong in log files. > They belong there so future display can remain colorful. > Why do they not belong there? What do people have to do who want > them? Escape sequences have been designed for communication with peripheral devices, not for markup or as a storage format. Also "future colorful display" generally won't be portabe because escape sequences depend on the setting of the TERM variable. (And again, software that emits them with TERM=dumb or TERM unset is broken.) Ulrich
Re: [gentoo-dev] rfc: escape sequences in logs
On Mon, Sep 2, 2013 at 8:21 PM, William Hubbs wrote: > > mgorny says many people benefit from having escape codes in log > files, but I see no benefit from it, and I don't like going through > build.log because of them. If you load a build.log into an editor, the > escape sequences are basically trash characters that get in the way. You do know that many eclasses (including the Ruby ones) have a setting that enables/disable color output? I keep it enabled on my system but I've always been disabling it for tinderboxes.. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] rfc: escape sequences in logs
Hi! My two cents for viewing-logs-in-vim (which is a use case for me): $ eix ansiesc * app-vim/ansiesc Available versions: (~)12 Homepage:http://www.vim.org/scripts/script.php?script_id=302 Description: vim plugin: ansi escape sequences concealed, but highlighted as specified Regards, Tobias
[gentoo-dev] new eclass proposal, perl-mb-tiny.eclass
Presently, in tree, for perl modules, there's a generic perl-module.eclass This has been OK for the most part, because the assumptions it has made have often been true. For instance, perl-module.eclass thinks that if a file exists called Build.PL, that it will be using Module::Build, so it uses a series of specific ways of invoking that file, and performs a few QA warnings if you don't depend on module build. Previously, people figured an explicit dependency on Module::Build was excessive, because it was shipped as part of a standard Perl installation. However, Perl upstream are changing this, and will stop shipping Module::Build with perl in a future release, so things that presently need Module::Build to work *MUST* depend on it. Additionally, there's a newcommer on the field, *Module::Build::Tiny*, which has a mostly compatible interface, but is rather different under the hood, and things that need it to work MUST depend on it in order to perform *src_configure* However, as Module::Build::Tiny also uses Build.PL, we can no longer rely on that files existence as an indicator of the toolchain that is required. And to add insult to injury, the way we currently invoke Build.PL does *NOT*work when Build.PL is Module::Build::Tiny The *ONLY *safe way to determine what tooling a distribution needs is by looking at *META.yml* or *META.json* within a perl distribution, and looking for the *configure.requires* dependencies. But this is hardly something that can be done at runtime, and the very best we can do without having a seperate ebuild is a special magic variable that controls behaviour of *perl-module.eclass* But thats a poor design approach, using conditionals is a poor mans polymorphism. It seems much more sane to have an *.eclass* per perl-toolchain required, and then we can just handle the difference in behaviour by changing the inherit line. For perl distributions that inherently seem to support multiple ways of being built, we as downstream should pick one and force that method in the ebuild. Now, I'm not the best eclass author, I've given my approach to it here: https://github.com/gentoo-perl/perl-experimental/blob/master/eclass/perl-mb-tiny.eclass Its not perfect yet, and the documentation is wrong. It bases itself on the present perl-module.eclass and overrides everything applicable to focus on the task of building Module::Build::Tiny based distributions. This is an early query to the ML to get feedback on the general approach I've taken, and get an idea of whether I'm heading in the right direction or not. I would also be thinking about creating perl-mb.eclass and perl-eumm.eclass , for the 2 other dominant toolkits at this time, and then moving to transition packages that use perl-module.eclass to one of the 3. ( This is really just a move to apply the method we presently use for non-perl packages to perl packages, for instance, we don't autodetect during src_configure whether a gentoo package uses cmake or autoconf, that would just be silly, we do the smart thing and have an eclass for cmake, and an eclass for autoconf ) If somebody else knows what they're doing here and can contribute a better version of perl-mb-tiny.eclass, that'd be cool too =) -- Kent
