log colorizer? - Suse

This is a discussion on log colorizer? - Suse ; On Sat, 6 Sep 2008, houghi wrote:- >David Bolt wrote: >> >> >> On Fri, 5 Sep 2008, houghi wrote:- >> >>>(And why don't you have an account there? ;-) ) >> >> I do have an account, but I ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 43

Thread: log colorizer?

  1. Re: log colorizer?

    On Sat, 6 Sep 2008, houghi wrote:-

    >David Bolt wrote:
    >>
    >>
    >> On Fri, 5 Sep 2008, houghi wrote:-
    >>
    >>>(And why don't you have an account there? ;-) )

    >>
    >> I do have an account, but I just didn't bother using it. However, the
    >> prodding's finally been enough to actually sit down and work out how to
    >> use the CLI osc and the web interface together. To that end, I've
    >> uploaded ccze, and a few other packages, into my home projects and am
    >> now getting used to the differences between how I'm used to working, and
    >> how the build service works.

    >
    >W00t! http://software.opensuse.org/search?...ALL&p=1&q=ccze I
    >can imagine that especially rebuilding for factory can be extremely easy
    >now.


    I didn't really have that much of a problem before, although my test
    machine was a 32bit virtual one. Now it means I can build for both 32
    and 64 bit versions.

    >One thing i have not figured out is how to add other peoples packages to
    >your own project. The reson this would be interesting is that way you
    >can build your own repo, without the need to maintain everything
    >yourself and then you need to only add yourself as repo and have all the
    >things you want.


    I haven't thought about that, nor have I thought about adding my own
    home as a repo.

    >Yes, I can anderstand that it is a serious adaption of how you used to
    >work and how you work now.


    Well, my normal method is to run a script on each machine I build for.
    This script retrieves all the source packages from a central location,
    and then checks each one against a database to see if they've been
    changed, or hasn't already been built. Any that have been changed, or
    haven't been built, get built. Once the build has completed, whether it
    was successful or not is entered into the database and the script goes
    on to the next package. Finally, after all the packages have been built,
    each of the RPMs are signed and then moved to the central location.

    Another script is then run that copies the built packages from there to
    the correct location on my backup web server. The, if required, patches
    are created to identify the updated packages and then createrepo is used
    to update the location so it can be used as an installation source.
    Finally, I mirror the backup web server onto the net-facing server and
    that's it until I need to do another build.

    This way is a lot different to my above method, but I am getting used to
    it. The combo of using the CLI for uploading changed files, etc. and the
    web interface to look and see what failed, and why, makes for a nice and
    easy way of doing things.

    It also leads to a bit of confusion as well. One of the packages I've
    uploaded, cssed, successfully built locally when I had a Fedora system
    available. However, when building it using the build service results in
    a failure. The confusing part is that it fails because the files it's
    expecting to include in the package can't be found, even though it lists
    those exact same file as being installed but not packaged.

    Another minor annoyance is having failed builds for factory when I can
    build the same package locally using alpha2. That I'm going to recheck
    after I finish updating that system to the present factory, and so may
    be able to identify the cause and then sort it out.

    >I asume you have already found the
    >documentation on https://build.opensuse.org/documentation/obs/ and
    >http://en.opensuse.org/SUSE_Build_Tutorial


    I'd already read those a while ago, but never actually gotten round to
    using the info. I had even thought about setting up my own local build
    service, but then gave up on that idea. I might think about it again in
    the future, especially if the set-up is made somewhat easier. It would
    be nice to be able to implement a system to act like PPC-based build
    service, since there isn't that capability available at the moment.

    >so this is more material for
    >others.


    Some of the obs documentation needs to be updated a bit, especially some
    of the commands available to the CLI client. There are a few new
    commands, some have been renamed, and others removed.


    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

  2. Re: log colorizer?

    David Bolt wrote:
    >>W00t! http://software.opensuse.org/search?...ALL&p=1&q=ccze I
    >>can imagine that especially rebuilding for factory can be extremely easy
    >>now.

    >
    > I didn't really have that much of a problem before, although my test
    > machine was a 32bit virtual one. Now it means I can build for both 32
    > and 64 bit versions.


    What I mean is that now each and every thing can be rebuild by pressing
    a button. New factory version? Press on it.

    >>One thing i have not figured out is how to add other peoples packages to
    >>your own project. The reson this would be interesting is that way you
    >>can build your own repo, without the need to maintain everything
    >>yourself and then you need to only add yourself as repo and have all the
    >>things you want.

    >
    > I haven't thought about that, nor have I thought about adding my own
    > home as a repo.


    It is only one of the possabilities. The moment you have one package and
    do an install via the website, it will add you automagically.

    > This way is a lot different to my above method, but I am getting used to
    > it. The combo of using the CLI for uploading changed files, etc. and the
    > web interface to look and see what failed, and why, makes for a nice and
    > easy way of doing things.


    You can also link to a remote file on e.g. sourceforge or a developers
    website. Tey can be compressed files.

    > It also leads to a bit of confusion as well. One of the packages I've
    > uploaded, cssed, successfully built locally when I had a Fedora system
    > available. However, when building it using the build service results in
    > a failure. The confusing part is that it fails because the files it's
    > expecting to include in the package can't be found, even though it lists
    > those exact same file as being installed but not packaged.


    No idea.

    > Another minor annoyance is having failed builds for factory when I can
    > build the same package locally using alpha2. That I'm going to recheck
    > after I finish updating that system to the present factory, and so may
    > be able to identify the cause and then sort it out.


    Don't forget that Alpha2 is already old when you download it. factory
    can be newer and can fail rebuilds if it needs something that is
    b0rken on factory.

    >>I asume you have already found the
    >>documentation on https://build.opensuse.org/documentation/obs/ and
    >>http://en.opensuse.org/SUSE_Build_Tutorial

    >
    > I'd already read those a while ago, but never actually gotten round to
    > using the info. I had even thought about setting up my own local build
    > service, but then gave up on that idea. I might think about it again in
    > the future, especially if the set-up is made somewhat easier. It would
    > be nice to be able to implement a system to act like PPC-based build
    > service, since there isn't that capability available at the moment.


    The reason is hardware, I believe. They don't have enough hardware.

    >>so this is more material for
    >>others.

    >
    > Some of the obs documentation needs to be updated a bit, especially some
    > of the commands available to the CLI client. There are a few new
    > commands, some have been renamed, and others removed.


    I mainly am concerned about the fact that I am still not able to make
    one working spec file.

    houghi
    --
    This was written under the influence of the following:
    | Artist : Beastie Boys
    | Song : 5-Piece Chicken Dinner
    | Album : Paul's Boutique

  3. Re: log colorizer?

    On Sat, 6 Sep 2008, houghi wrote:-

    >David Bolt wrote:


    >> I didn't really have that much of a problem before, although my test
    >> machine was a 32bit virtual one. Now it means I can build for both 32
    >> and 64 bit versions.

    >
    >What I mean is that now each and every thing can be rebuild by pressing
    >a button. New factory version? Press on it.


    I don't know if it's possible, but it would be good if it would
    auto-build whenever there was a new version of any of the packages that
    were dependencies. It would mean that if any of the core packages were
    updated then a rebuild would be triggered, but it would be nice, and it
    would save me having to click

    >> I haven't thought about that, nor have I thought about adding my own
    >> home as a repo.

    >
    >It is only one of the possabilities. The moment you have one package and
    >do an install via the website, it will add you automagically.


    Maybe. I've used the one-click install a few times before, but only once
    have I left the repos added to my list.

    >> This way is a lot different to my above method, but I am getting used to
    >> it. The combo of using the CLI for uploading changed files, etc. and the
    >> web interface to look and see what failed, and why, makes for a nice and
    >> easy way of doing things.

    >
    >You can also link to a remote file on e.g. sourceforge or a developers
    >website. Tey can be compressed files.


    I think I'd prefer to have the files locally. That way I know the
    version won't change without me making the change myself.

    >> It also leads to a bit of confusion as well. One of the packages I've
    >> uploaded, cssed, successfully built locally when I had a Fedora system
    >> available. However, when building it using the build service results in
    >> a failure. The confusing part is that it fails because the files it's
    >> expecting to include in the package can't be found, even though it lists
    >> those exact same file as being installed but not packaged.

    >
    >No idea.


    No, I don't either so I'm downloading the Fedora and Centos installation
    DVDs to see if I can figure out the source of the problem, and a
    solution locally, and then I'll see if it works on the build service.

    >> Another minor annoyance is having failed builds for factory when I can
    >> build the same package locally using alpha2. That I'm going to recheck
    >> after I finish updating that system to the present factory, and so may
    >> be able to identify the cause and then sort it out.

    >
    >Don't forget that Alpha2 is already old when you download it.


    Well, I don't know about that when I first downloaded it. It was when I
    first installed it, mainly because I didn't really do anything with it
    until after I had completed the complement to makeSUSEdvd, namely
    makeSUSEcd.

    After that, it was a good few days after that because I started playing
    about at getting a PXE server set up and working. Initially the idea was
    so I could boot the gparted live system over the network. After that
    worked, I added the ability to install 10.2, 10.3, 11.0 and 11.1a2.

    Now, if I want to perform an installation, all I need to do is start up
    a system and do a network boot. Then it's a matter of picking the
    version and arch I want, and then getting on with it. And, with the
    traffic being across my LAN, it's about as fast as using a DVD local to
    the machine. It also works very nicely with freshly created virtual
    machines

    >factory
    >can be newer and can fail rebuilds if it needs something that is
    >b0rken on factory.


    I've met that one already. I have two packages that won't build because
    of broken dependencies.

    >> I'd already read those a while ago, but never actually gotten round to
    >> using the info. I had even thought about setting up my own local build
    >> service, but then gave up on that idea. I might think about it again in
    >> the future, especially if the set-up is made somewhat easier. It would
    >> be nice to be able to implement a system to act like PPC-based build
    >> service, since there isn't that capability available at the moment.

    >
    >The reason is hardware, I believe. They don't have enough hardware.


    Most likely.

    >> Some of the obs documentation needs to be updated a bit, especially some
    >> of the commands available to the CLI client. There are a few new
    >> commands, some have been renamed, and others removed.

    >
    >I mainly am concerned about the fact that I am still not able to make
    >one working spec file.


    You tried using the wizard to assist? It's available if you add a new
    package. I can't say how well it would work, since I write my own spec
    files. Experimenting with it might help you learn to write your own.


    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

  4. Re: log colorizer?

    On Sat, 6 Sep 2008, houghi wrote:-

    >David Bolt wrote:




    >> Another minor annoyance is having failed builds for factory when I can
    >> build the same package locally using alpha2. That I'm going to recheck
    >> after I finish updating that system to the present factory, and so may
    >> be able to identify the cause and then sort it out.

    >
    >Don't forget that Alpha2 is already old when you download it. factory
    >can be newer and can fail rebuilds if it needs something that is
    >b0rken on factory.


    I've figured this one out[0], and created a patch for it, and it was
    because factory is newer than alpha2.

    The change is because, with the addition of wide character support, the
    header files for ncurses development had to move to prevent
    incompatibilities. Now the headers go in either /usr/include/ncurses or
    /usr/include/ncursesw, while the previous versions didn't have wide
    character support and just put them in /usr/include.

    It also means I've got to check other packages I build to see if the
    builds are going to fall over due to this change.


    [0] It clicked when looking through the packaging mailing list and
    spotting some messages about a new version of ncurses. They were almost
    three weeks old and, with the list being a quiet one, I'd ignored it for
    a while.

    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

  5. Re: log colorizer?

    David Bolt wrote:
    > I don't know if it's possible, but it would be good if it would
    > auto-build whenever there was a new version of any of the packages that
    > were dependencies. It would mean that if any of the core packages were
    > updated then a rebuild would be triggered, but it would be nice, and it
    > would save me having to click


    Talk to the developers and either they already do that, are working on
    it or will flame you fr the stupid idea. ;-)

    > Maybe. I've used the one-click install a few times before, but only once
    > have I left the repos added to my list.


    Why?

    > I think I'd prefer to have the files locally. That way I know the
    > version won't change without me making the change myself.


    It just saves a bit on the upload time. Instead of first downloading
    http://example.org/dir/file.tgz saving it and then uploading it, you
    skip the step of the the download and save and just enter the URL

    >>No idea.

    >
    > No, I don't either so I'm downloading the Fedora and Centos installation
    > DVDs to see if I can figure out the source of the problem, and a
    > solution locally, and then I'll see if it works on the build service.


    I would ask the OBS developers what happens and why. There are some
    people who breathe RPM.

    >>I mainly am concerned about the fact that I am still not able to make
    >>one working spec file.

    >
    > You tried using the wizard to assist? It's available if you add a new
    > package. I can't say how well it would work, since I write my own spec
    > files. Experimenting with it might help you learn to write your own.


    I have a package that builds in 10.3 but not in 11.0 and the reasons
    are chinese to me.
    https://build.opensuse.org/package/s...=home%3Ahoughi

    The log exmplanation starts with the following:
    RPMLINT report:
    ===============
    xe.src: W: %install-no-mkdir-buildroot
    Your install section removes the buildroot but does not create them
    afterwards in a secure way, which allows attackers to trivially play
    tricks with symlinks on you. use mkdir %buildroot (no -p option!) or
    don't clean the buildroot in %install, because that's anyway already
    done for you by rpm.

    And this is for a script. No real building takes place.
    http://download.opensuse.org/reposit....1-4.4.src.rpm

    The files are:
    *** rpm filelist (*=executeable)
    ------------------------------------------------------------------
    * /usr/bin/xe
    /usr/share/doc/packages/xe
    /usr/share/doc/packages/xe/CHANGELOG
    /usr/share/doc/packages/xe/LICENSE
    /usr/share/doc/packages/xe/README
    /usr/share/man/man1/xe.1.gz

    and xe itself is 128 lines of bash.

    The explantion is probaly very clear to people who know what they are
    doing. To me it is completely gooblegock. As if trying to explain how a
    woman thinks from a womans point of view. :-D

    houghi
    --
    This was written under the influence of the following:
    | Artist : The Moody Blues
    | Song : To Share Our Love
    | Album : On the Threshold of a Dream

  6. Re: log colorizer?

    David Bolt wrote:
    > I've figured this one out[0], and created a patch for it, and it was
    > because factory is newer than alpha2.


    That is why so many people love Windows and hate Linux. That only
    changes every decade and Lnux changes every minute. ;-)

    houghi
    --
    This was written under the influence of the following:
    | Artist : Santana
    | Song : Primavera
    | Album : Supernatural

  7. Re: log colorizer?

    On Sun, 7 Sep 2008, houghi wrote:-

    >David Bolt wrote:
    >> I've figured this one out[0], and created a patch for it, and it was
    >> because factory is newer than alpha2.

    >
    >That is why so many people love Windows and hate Linux. That only
    >changes every decade and Lnux changes every minute. ;-)


    I'd have thought the fact that Windows crashes almost daily but Linux
    crashes only once in a blue moon, if that, would sort of counteract
    that.


    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

  8. Re: log colorizer?

    On Sun, 7 Sep 2008, houghi wrote:-

    >David Bolt wrote:
    >> I don't know if it's possible, but it would be good if it would
    >> auto-build whenever there was a new version of any of the packages that
    >> were dependencies. It would mean that if any of the core packages were
    >> updated then a rebuild would be triggered, but it would be nice, and it
    >> would save me having to click

    >
    >Talk to the developers and either they already do that, are working on
    >it or will flame you fr the stupid idea. ;-)


    Already have the nomex underwear for use on Usenet. Using it on the
    build service mailing list won't take any extra effort

    >> Maybe. I've used the one-click install a few times before, but only once
    >> have I left the repos added to my list.

    >
    >Why?


    Actually, it was twice. One has the home project for rembrand, and
    another has KDE:backports left enabled. As for the others, I only wanted
    the one package from the repos to perform some tests. After I'd checked
    what I wanted, I removed the package. No sense in keeping the repos
    present when I don't want the packages any more.

    Thinking about it, I'm not entirely sure what I still have the home for
    rembrand enabled. It's not like there's any need to do any more
    development of it any more. The branding is supposedly being, or has
    been, moved into separate packages.

    >> No, I don't either so I'm downloading the Fedora and Centos installation
    >> DVDs to see if I can figure out the source of the problem, and a
    >> solution locally, and then I'll see if it works on the build service.

    >
    >I would ask the OBS developers what happens and why. There are some
    >people who breathe RPM.


    I've finished downloading the installation DVDs. I'll get them installed
    on a couple of virtual machines and then look at the results. Much
    easier when I can see the contents of %{buildroot} to see if I fscked up
    the spec file.

    >> You tried using the wizard to assist? It's available if you add a new
    >> package. I can't say how well it would work, since I write my own spec
    >> files. Experimenting with it might help you learn to write your own.

    >
    >I have a package that builds in 10.3 but not in 11.0 and the reasons
    >are chinese to me.
    >https://build.opensuse.org/package/s...=home%3Ahoughi
    >
    >The log exmplanation starts with the following:
    >RPMLINT report:
    >===============
    >xe.src: W: %install-no-mkdir-buildroot


    That's because the %install section removes the %{buildroot} and doesn't
    recreate it. Personally, I'd remove the part where it removes
    %{buildroot} as it's not needed[0] but, if you're wanting to keep it,
    insert the line:

    mkdir -p %{buildroot}

    immediately before line 32, "make ROOT=...".

    >The explantion is probaly very clear to people who know what they are
    >doing. To me it is completely gooblegock. As if trying to explain how a
    >woman thinks from a womans point of view. :-D


    Erm... I don't even want to try thinking about how you'd do that. It
    would give me a severe headache.


    [0] If you check the build logs, search for the line starting
    "Executing(%build)" and you'll see that %build removes %{buildroot} and
    recreates it again, just to make sure that it will be empty.

    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

  9. Re: log colorizer?

    David Bolt wrote:
    > I'd have thought the fact that Windows crashes almost daily but Linux
    > crashes only once in a blue moon, if that, would sort of counteract
    > that.


    That is what the sysadmins make you believe. Where I work everubody is
    happy when their Windows crashes, because then they do not have to work.
    :-D

    houghi
    --
    This was written under the influence of the following:
    | Artist : De Dijk
    | Song : Onderuit
    | Album : Zullen We Dansen

  10. Re: log colorizer?

    David Bolt wrote:
    >>The log exmplanation starts with the following:
    >>RPMLINT report:
    >>===============
    >>xe.src: W: %install-no-mkdir-buildroot

    >
    > That's because the %install section removes the %{buildroot} and doesn't
    > recreate it. Personally, I'd remove the part where it removes
    > %{buildroot} as it's not needed[0] but, if you're wanting to keep it,
    > insert the line:
    >
    > mkdir -p %{buildroot}
    >
    > immediately before line 32, "make ROOT=...".


    I can see what you have typed, but I ahve no idea what you are saying.
    The only thing I have been able to do is copy and paste spec files.


    houghi
    --
    This was written under the influence of the following:
    | Artist : De Dijk
    | Song : Onderuit
    | Album : Zullen We Dansen

  11. Re: log colorizer?

    On Fri, 5 Sep 2008 14:33:12 +0100
    David Bolt wrote:

    >Actually, I was being a little cruel because I do know what's causing
    >the problems, and what I did to cure them.


    Shame on you! Drove me to having to imbibe some frothy, malt-based,
    adult beverages . . . ;-)


    >You need to apply the following patch:
    >
    >--- ./configure.ac
    >-AC_CHECK_TYPE(error_t, int)


    I missed that one and instead, I commented out,
    in ./ccze-0.2.1/system.h the following line:

    #define error_t int

    Same result, but your way is better.


    >
    >And:
    >
    >--- ./src/Makefile.in
    >- -Wreturn-type -Wswitch -Wmulticharacter \
    >+ -Wreturn-type -Wswitch \


    I had already changed this one.


    >And then there should be no problems building it.
    >


    That is correct.


    >Of course, if you're wanting to build an RPM from it using rpmbuild,
    >you'll need to edit the spec file as it's using the old Copyright: tag,
    >and building with it will fail.
    >


    I noticed that, but haven't gotten around to fixing that, yet. I'm not
    sure if I will take this program on, now, with the MultiTail program
    available, especially since my time is so tight right now. We'll see, I
    guess . . .


    >Alternatively, you can find my source RPM package, with a replacement
    >spec file and those patches here:
    >
    >
    >


    Thanks for making that available, David!


    --
    Kevin Nathan (Arizona, USA)
    Linux Potpourri and a.o.l.s. FAQ -- (temporarily offline)

    Open standards. Open source. Open minds.
    The command line is the front line.
    Linux 2.6.25.11-0.1-pae
    10:10am up 9 days 4:24, 20 users, load average: 0.30, 0.40, 0.47


  12. Re: log colorizer?

    houghi wrote:

    > I use ccze to get a bit of color in my logfiles when running a tail on
    > them. However I am afraid that this tool will be out of date in the not
    > so near future. Are there any other more recent tools thta will do the
    > same?
    >
    > A search gave me just one that is even older and less maintained.
    >
    > houghi


    Just thought I'd throw in this idea in case you thought it worked for your
    purpose. As you seem concerned about using things that might not be
    supported/maintained in the future here's an idea. Using a script you
    could launch an editor to open up whatever log file you are interested in
    with color syntax highlighting using whatever lexer (Apache log ?) you
    need. I'm suggesting 'Editra' which seems to be well maintained and
    available from the openSUSE repo:
    (wxPython-common-gtk2-unicode-2.8.8.1-4.3.i586.rpm)

    or there web site:

    http://editra.org

    where you'll find there is even an online community. They seem to do an
    update every month or two. Note that this is version 0.3.38 but it seems
    quite stable and has a plugin architecture.

    I just happened to glance through my menus today and spotted Editra in
    my 'Development -> More Programs menu and thought I'd take a closer look at
    it. I hadn't really used it until now. So it got me thinking about log
    colorizing and I opened up my Apache2 log and used the Apache2 logfile
    lexer and the color highlighting is there. You can use your own css to
    define custom colors and there are plenty of other goodies that come with
    the editor...

    You can use ->Tools -> Generator -> Generate HTML, Generate LaTex or
    Generate RTF to save in these formats. I just saved my Apache2 logfile as
    html and opened it up in my browser and the color highlighting and
    formatting worked flawlessly !!

    P.S. This is just a suggestion that works well. As this is a python based
    application it is fast. It is licensed under the wxWindows license. Also,
    there are keyboard and mouse bindings if you like that...

    Of course you'll need to use Root privileges (su or sudo editra) to access
    your log files but you knew that. ;-)


  13. Re: log colorizer?

    Michael Soibelman wrote:

    > or there web site:
    >
    > http://editra.org


    > You can use ->Tools -> Generator -> Generate HTML, Generate LaTex or
    > Generate RTF to save in these formats. I just saved my Apache2 logfile as
    > html and opened it up in my browser and the color highlighting and
    > formatting worked flawlessly !!



    As great as it is to colorize things, what I need is a colorizer that
    does things live. So it needs to be like tail, but with colors.
    http://houghi.org/shots/wmaker/slide...4_png_orig.php

    Now if you do this with e.g. the apache log, you might go a bit crazy,
    but if you do it with some other things, you can pretty fast see what is
    going on with your system.

    houghi
    --
    >>>> Run the following from the bashprompt if you have the kernel sources

    for I in `find /usr/src/linux/ -name *.c`; \
    do A=`grep -i -A 1 -B 1 **** $I`;if [ "$A" != "" ]; \
    then printf "$I \n$A \n\n"; fi ;done|less

  14. Re: log colorizer?

    On Sun, 7 Sep 2008, Kevin Nathan wrote:-

    >On Fri, 5 Sep 2008 14:33:12 +0100
    >David Bolt wrote:
    >
    >>Actually, I was being a little cruel because I do know what's causing
    >>the problems, and what I did to cure them.

    >
    >Shame on you! Drove me to having to imbibe some frothy, malt-based,
    >adult beverages . . . ;-)


    I know. I was just so horrible wasn't I?



    >>And then there should be no problems building it.
    >>

    >
    >That is correct.


    Good.

    >>Of course, if you're wanting to build an RPM from it using rpmbuild,
    >>you'll need to edit the spec file as it's using the old Copyright: tag,
    >>and building with it will fail.
    >>

    >
    >I noticed that, but haven't gotten around to fixing that, yet.


    Extra prodding required? Or just some more imbibing?

    >I'm not
    >sure if I will take this program on, now, with the MultiTail program
    >available, especially since my time is so tight right now. We'll see, I
    >guess . . .


    To be honest, I don't use either of them. I prefer to use Kconsole and a
    console open for each log file I'm watching, and then just use tail -F.



    >Thanks for making that available, David!


    It's in the build service as well, after finally getting my finger out
    and uploading something, so should be available for all supported
    versions. Houghi's already posted a search link for it.


    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

  15. Re: log colorizer?

    On Sun, 7 Sep 2008, houghi wrote:-

    >David Bolt wrote:
    >>>The log exmplanation starts with the following:
    >>>RPMLINT report:
    >>>===============
    >>>xe.src: W: %install-no-mkdir-buildroot

    >>
    >> That's because the %install section removes the %{buildroot} and doesn't
    >> recreate it. Personally, I'd remove the part where it removes
    >> %{buildroot} as it's not needed[0] but, if you're wanting to keep it,
    >> insert the line:
    >>
    >> mkdir -p %{buildroot}
    >>
    >> immediately before line 32, "make ROOT=...".

    >
    >I can see what you have typed, but I ahve no idea what you are saying.
    >The only thing I have been able to do is copy and paste spec files.


    Think of them as a script file, since they are in a way, and you might
    find understanding them easier. What you put in each of the individual
    parts, %prep, %build, %install, %clean, etc. get added to scripts that
    are then used to perform each part of the build progress.

    As for the spec file in question, I've rewritten that, "borrowed" the
    source archive from your home, and let it be rebuilt. With the new spec
    file, it now builds with 11.0, and should do so with factory. If you
    want any explanations to help understand it, don't hesitate to ask.


    Regards,
    David Bolt

    --
    www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
    SUSE 10.1 32b | | openSUSE 10.3 32b | openSUSE 11.0 32b
    | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b
    RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11

  16. Re: log colorizer?

    houghi wrote:

    > Michael Soibelman wrote:
    >
    >> or there web site:
    >>
    >> http://editra.org

    >
    >> You can use ->Tools -> Generator -> Generate HTML, Generate LaTex or
    >> Generate RTF to save in these formats. I just saved my Apache2 logfile
    >> as html and opened it up in my browser and the color highlighting and
    >> formatting worked flawlessly !!

    >
    >
    > As great as it is to colorize things, what I need is a colorizer that
    > does things live. So it needs to be like tail, but with colors.
    > http://houghi.org/shots/wmaker/slide...4_png_orig.php
    >
    > Now if you do this with e.g. the apache log, you might go a bit crazy,
    > but if you do it with some other things, you can pretty fast see what is
    > going on with your system.
    >
    > houghi


    O.K.

  17. Re: log colorizer?

    David Bolt wrote:
    > To be honest, I don't use either of them. I prefer to use Kconsole and a
    > console open for each log file I'm watching, and then just use tail -F.


    The reason I use it is because it gives colour to tail. The colours of
    ccze are better as a standard then multitail. Multitail had the
    advantage ofhaving some very nice possabilities as well.

    For multitail I use in /var/log:
    sudo multitail -s 2 messages warn -ke '/home/houghi/wallpaper' \
    /home/houghi/wallpaper/latest_files mail

    The result is http://houghi.org/shots/tail02.jpg

    With tail and ccze, I would use the following
    sudo tail -f messages warn /home/houghi/wallpaper/latest_files \
    mail | ccze

    The result is http://houghi.org/shots/tail01.jpg

    When taking some time, multitail can also have some nice colours, but
    ccze already has them standard.

    I am tempted to keep using tail with ccze, as the colours are already
    configured, so all I need to do is is run it. With multitail I would
    need to configure all the colours.

    Multitail is a much better tool. For what I want it to do, it is just
    overkill for now.

    houghi
    --
    ________________________ Open your eyes, open your mind
    | proud like a god don't pretend to be blind
    | trapped in yourself, break out instead
    http://openSUSE.org | beat the machine that works in your head

  18. Re: log colorizer?

    David Bolt wrote:
    >>I can see what you have typed, but I ahve no idea what you are saying.
    >>The only thing I have been able to do is copy and paste spec files.

    >
    > Think of them as a script file, since they are in a way, and you might
    > find understanding them easier. What you put in each of the individual
    > parts, %prep, %build, %install, %clean, etc. get added to scripts that
    > are then used to perform each part of the build progress.


    I understand that. I also understand why oe works. I just don't
    understand why things don't work.

    > As for the spec file in question, I've rewritten that, "borrowed" the
    > source archive from your home, and let it be rebuilt. With the new spec
    > file, it now builds with 11.0, and should do so with factory. If you
    > want any explanations to help understand it, don't hesitate to ask.


    Again thanks. I blatently stole it from you now. :-D
    As for the explanation: I will when I have time to get my head around
    it. I will realy need to sit down for it and for now that is not an
    option.

    houghi
    --
    ________________________ Open your eyes, open your mind
    | proud like a god don't pretend to be blind
    | trapped in yourself, break out instead
    http://openSUSE.org | beat the machine that works in your head

  19. Re: log colorizer?

    On Thu, 11 Sep 2008 09:16:13 +0200
    houghi wrote:

    >Great. I hope you will do it on the build server. Because that woudl
    >mean you will be building not only for yourself, but for everybody else
    >as well.
    >
    >That way you can focus on things that are not in the distribution.
    >


    That's exactly what I plan to do, if I ever find the time. :-) I'm also
    looking forward to getting more involved on openSUSE.org, as well.


    >> That's what I do at work, most of the time. But, it gets a little
    >> messy with 20+ servers -- I'm hoping to use MultiTail to get four
    >> tails per console screen. I should probably just setup Zabbix, but
    >> that damn lack of time keeps getting in the way! :-)

    >
    >Well, I asume you then only show /var/log/warn.


    Actually, no. I'm not one of the network guys -- I have to monitor the
    Apache error and access logs relating to our web apps; and watching the
    database connections from time to time.


    >And Zabbix looks nice. Run it in fullscreen on a HUGE walldisplay. :-D


    They do that at the co-location we use. They have 18 or so Zabbix
    windows on a wallscreen about 5m x 2m. It's really cool! ;-)


    --
    Kevin Nathan (Arizona, USA)
    Linux Potpourri and a.o.l.s. FAQ -- (temporarily offline)

    Open standards. Open source. Open minds.
    The command line is the front line.
    Linux 2.6.25.11-0.1-pae
    8:29pm up 1 day 12:33, 16 users, load average: 1.29, 1.34, 1.04


  20. Re: log colorizer?

    Kevin Nathan wrote:
    >>And Zabbix looks nice. Run it in fullscreen on a HUGE walldisplay. :-D

    >
    > They do that at the co-location we use. They have 18 or so Zabbix
    > windows on a wallscreen about 5m x 2m. It's really cool! ;-)


    The last time I saw such a screen up close it was used only for show
    (and tv during the night) When people watching it asked the network
    people if they could put the routers up there so they could see if a
    router went down, the answer was: sure you can, if you want a ****ing
    christmas tree on your walldisplay.

    The reason was that it was standard and expected that many routers were
    down much of the time and unless you had a LOT of experience, it was
    almost impossible to know which alarm was a real one and which router it
    was normal to be down.

    They then wisely decided not to do it, because the screen was mainly for
    show and a lot of flashing things and red alerts would not have been a
    good thing.

    Also the wall was made in such a way that if you sat down, the thing at
    your desk in front of you where the screens where, made it impossible to
    see the lower half meter of the screen.

    I think the screen was some 5x4 meters.

    houghi
    --
    You can have my keyboard ...
    if you can pry it from my dead, cold, stiff fingers

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast