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

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

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

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

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

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

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

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

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

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

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. ;-)

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

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

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

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.

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

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

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

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