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 sea
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 valu
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
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
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,
(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
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
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 s
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
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 shoul
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 se
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
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
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 w
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
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
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 abou
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 file
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 mo
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
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
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 an
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 es
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 o
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 sati
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
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 p
> 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.
> H
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
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 fro
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
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 intern
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
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
> 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
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 wit
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
> 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:
> 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 col
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
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
highl
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
42 matches
Mail list logo
