------------------------------------------------------------------------
r54 | rgb | 2007-07-11 17:48:36 -0400 (Wed, 11 Jul 2007) | 2 lines

Sending it in to the other two svn repos.

------------------------------------------------------------------------
r53 | rgb | 2007-07-11 17:48:15 -0400 (Wed, 11 Jul 2007) | 15 lines

OK, all packages are now installed and working on:

  i386
  x86_64 single core
  Intel dual core

with several examples of each.  I do have an x86_64 dual core but I'm
pretty confident that this is a go.  I therefore dub this:

   Tag 2.6.0

and release it into the wild...



------------------------------------------------------------------------
r52 | rgb | 2007-07-11 17:09:11 -0400 (Wed, 11 Jul 2007) | 3 lines

THIS is a version worth of checkin, although we don't know for sure if
wulf2html is working or not yet.

------------------------------------------------------------------------
r51 | rgb | 2007-07-11 14:47:56 -0400 (Wed, 11 Jul 2007) | 12 lines

This is a working 2.6.0alpha.  We've fixed (I think) the multicore
problem, pulling the number of cores from /proc/cpuinfo and turning them
into xml and parsing them at the receiving end.  Because of the silly
format of /proc/cpuinfo, the parsing code is a bit ugly, but it is
servicable as long as they don't reorder the fields.

I have dual, dual core servers to try this on almost immediately, after
an rsync.  I also need to think about adding the fields to wulf2html and
testing that before releasing 2.6.0.  2.6.0 will NOT be backwards
compatible on dual (or quad) core systems, but all that means is that an
upgrade to 2.6.x will be forced for dual core owners.

------------------------------------------------------------------------
r50 | rgb | 2007-07-11 10:06:35 -0400 (Wed, 11 Jul 2007) | 20 lines

This fixes a bug I discovered on my own.  The newest multicore CPUs
added another line to /proc/cpuinfo:

  cpu cores :2

I was parsing out cpu family, and all other cpu XXX were assumed to be
clock with XXX the speed.  Wrongo, moose breath -- caused wulfstat to
complain about multiple cpu clock tags (as it should have).

The fix was easy enough -- to add another conditional in xmlsysd to
check for cores before parsing for the (remaining) clock.  I could parse
for clock directly on MHz, but I'm fairly certain that any day now
they're going to change over to GHz units, as we're rapidly approaching
10,000+ MHz clocks.  Truthfully I'm surprised they haven't already.

This still leaves me with the issue of how to display the number of
cores on the already jammed wulfstat line.  Might have to snitch part of
the CPU name field.


------------------------------------------------------------------------
r49 | rgb | 2007-07-05 13:22:17 -0400 (Thu, 05 Jul 2007) | 2 lines

This fixes the bug, making this an official final 2.5.1 release.

------------------------------------------------------------------------
r48 | rgb | 2007-07-05 12:56:35 -0400 (Thu, 05 Jul 2007) | 4 lines

This is a small update on 2.5.1 -- basically I tested the build after
eliminating the automated ./configure from autogen.sh.  Generally
speaking, though, it worked perfectly.

------------------------------------------------------------------------
r47 | rgb | 2007-07-05 11:23:23 -0400 (Thu, 05 Jul 2007) | 3 lines

This is STILL Tag 2.5.1, but I screwed up and did a checkin as root so
who knows what happened or will happen now.

------------------------------------------------------------------------
r46 | root | 2007-07-05 11:20:26 -0400 (Thu, 05 Jul 2007) | 10 lines

This is Tag: 2.5.1

It actually builds rpms and builds/installs from autoconf as a beginning.

In fact, it looks pretty cute.  I DO need to work out a way of doing
development work, but I'm guessing that my set load library path script will
work for now.



------------------------------------------------------------------------
r45 | rgb | 2007-07-05 02:55:37 -0400 (Thu, 05 Jul 2007) | 4 lines

Well, we'll try one more time.  NOW we've actually cleaned up some of
the Makefile cruft associated with the port, and I'm sort of remembering
how this thing goes.

------------------------------------------------------------------------
r43 | rgb | 2007-07-05 02:40:43 -0400 (Thu, 05 Jul 2007) | 2 lines

This is another way to sync it up at home.

------------------------------------------------------------------------
r42 | rgb | 2007-07-05 02:39:33 -0400 (Thu, 05 Jul 2007) | 3 lines

This is really really close -- it builds ok, and even builds most of the
way through an rpm.  Probably two or three more hours of work...

------------------------------------------------------------------------
r41 | rgb | 2007-07-05 02:18:43 -0400 (Thu, 05 Jul 2007) | 4 lines

This is well on the way to having autoconf tools installed, perhaps more
parsimoniously than they are in dieharder, which is in need at this
point of a good decrufting.

------------------------------------------------------------------------
r40 | rgb | 2007-07-05 02:07:25 -0400 (Thu, 05 Jul 2007) | 2 lines

This is getting closer and closer to working through several levels...

------------------------------------------------------------------------
r38 | rgb | 2007-07-05 01:44:15 -0400 (Thu, 05 Jul 2007) | 3 lines

Well, we'll try one more time to get this right.  Note that we shouldn't
be saving Makefile any more.

------------------------------------------------------------------------
r37 | rgb | 2007-07-05 01:38:22 -0400 (Thu, 05 Jul 2007) | 2 lines

ALMOST configures clean...

------------------------------------------------------------------------
r36 | rgb | 2007-07-05 01:36:12 -0400 (Thu, 05 Jul 2007) | 4 lines

Well, this seems to "work" in that it autoconf's right up, but alas it
also fails to actually build.  I need to keep adding the minimal amount
from the dieharder tree required to make it all work.

------------------------------------------------------------------------
r33 | rgb | 2007-07-05 01:28:16 -0400 (Thu, 05 Jul 2007) | 2 lines

This buildroot is not necessary or desireable.

------------------------------------------------------------------------
r32 | rgb | 2007-07-05 01:27:32 -0400 (Thu, 05 Jul 2007) | 2 lines

This seems to work, right through Makefile.am...

------------------------------------------------------------------------
r31 | rgb | 2007-07-05 01:25:48 -0400 (Thu, 05 Jul 2007) | 2 lines

This nees a quick checkin, although it isn't really "there".

------------------------------------------------------------------------
r30 | rgb | 2007-06-28 06:32:39 -0400 (Thu, 28 Jun 2007) | 5 lines

I have no idea what's going on here, but either way I need to
pursue/continue this.  I also NEED to register dieharder as an FC
project, but that's another story.  Oh, and of course I need to install
debian under vmware.

------------------------------------------------------------------------
r29 | rgb | 2007-02-06 08:08:09 -0500 (Tue, 06 Feb 2007) | 2 lines

Making sure that this goes in and around...

------------------------------------------------------------------------
r28 | rgb | 2007-02-06 01:26:57 -0500 (Tue, 06 Feb 2007) | 11 lines

I have no idea what just happened, but a few of the scripts in this
package seem to get overwritten at random here and there.  I ended up
with a wulf2html that was, in fact, a mirror of
/etc/wulfware/wulf2html.sh, which created a lovely loop that would lock
my box up in about 1 second beyond repair on the recursive loop.  I
couldn't even zap it -- the zap command couldn't catch up.

Anyway, squashed, and wulfware now DEFINITELY does NOT do this, but gee,
I have no idea how or when it started in the first place and I suppose
it could happen again.  Thank God for subversion...

------------------------------------------------------------------------
r27 | rgb | 2007-02-05 11:21:22 -0500 (Mon, 05 Feb 2007) | 2 lines

Just to make sure that this is all checked in and everything...

------------------------------------------------------------------------
r26 | rgb | 2007-02-04 22:49:40 -0500 (Sun, 04 Feb 2007) | 4 lines

This is a decrufting checking.  Note that I'm carefully moving the cruft
into Cruft subdirectories instead of throwing it away.  This just plain
seems sensible.

------------------------------------------------------------------------
r25 | rgb | 2007-02-04 22:26:04 -0500 (Sun, 04 Feb 2007) | 5 lines

This may, finally, be "it" -- done at last, with a working wulf2html.
This is clearly the way it should have been done in the first place.
I'm not certain I've got all the dependencies and so on done correctly,
but it seems like they are probably all right.

------------------------------------------------------------------------
r24 | rgb | 2007-02-04 21:46:27 -0500 (Sun, 04 Feb 2007) | 2 lines

OK, FIRST we check this in, as it all seems (miraculously) to work!

------------------------------------------------------------------------
r23 | rgb | 2007-02-04 20:34:19 -0500 (Sun, 04 Feb 2007) | 3 lines

I have NO IDEA what I did before, but we need to check this in and make
everything good.

------------------------------------------------------------------------
r22 | root | 2007-02-04 20:33:35 -0500 (Sun, 04 Feb 2007) | 3 lines

Let's see if this doesn't build and install for a really functional
wulf2html.

------------------------------------------------------------------------
r19 | rgb | 2007-02-03 11:35:46 -0500 (Sat, 03 Feb 2007) | 2 lines

This SHOULD work, but it isn't, quite.  Odd.

------------------------------------------------------------------------
r18 | rgb | 2007-02-03 11:30:59 -0500 (Sat, 03 Feb 2007) | 5 lines

This should maybe build/install into ./buildroot cleanly on a make
install, so that I can replace all that garbage in the specfile
with a make BUILDROOT=%{buildroot} install and be done.  One stop
shopping, so to speak.

------------------------------------------------------------------------
r17 | rgb | 2007-02-03 09:44:34 -0500 (Sat, 03 Feb 2007) | 3 lines

This is now fixed to make install through xmlsysd.  Hmmm, let's do this
via the toplevel make install.

------------------------------------------------------------------------
r16 | rgb | 2007-02-03 08:58:04 -0500 (Sat, 03 Feb 2007) | 12 lines

This now works again through libwulf.  I have to insert the buildroot
trick into the other four targets and fix the specfile, but then I
should be once again cooking with gas, so to speak.  This is clearly
the way to go -- in fact I can easily enough make buildroot point
anywhere I like by default and life will be just fine, as long as
I have installs that create the actual tree as required beneath it.

I also want to make the build happen with a single make target, the
good old "make install".  That will then build everything and install it
so that rpmbuild can package things up.  In fact, I'm starting to grok
rpmbuild a bit better -- ALL that matters is building the tree...

------------------------------------------------------------------------
r15 | rgb | 2007-02-03 08:47:19 -0500 (Sat, 03 Feb 2007) | 5 lines

This MIGHT just work correctly, but we'll have to see if it builds at
all.  It has to build even if the buildroot tree doesn't exist (that is,
the build cannot depend on buildroot/usr/include being already
installed) unless it forces it to be installed FIRST.

------------------------------------------------------------------------
r14 | rgb | 2007-02-03 08:32:35 -0500 (Sat, 03 Feb 2007) | 2 lines

Trying again...

------------------------------------------------------------------------
r12 | rgb | 2007-02-03 08:26:25 -0500 (Sat, 03 Feb 2007) | 7 lines

Alas, we're going to have to reorganize.  Looks like
library/multipackage trees (and maybe even simple trees) benefit
tremendously in terms of portable Makefiles from having a buildroot.
make install can then build directly into it with a single
BUILDROOT or PREFIX override, and the spec file will do the Right Thing.
In the meantime, it becomes very easy to test.

------------------------------------------------------------------------
r9 | rgb | 2007-02-03 07:34:35 -0500 (Sat, 03 Feb 2007) | 3 lines

This now builds the source, libwulf, xmlsysd, wulfstat and wulflogger
rpms in a single build.  Pretty cool, actually...

------------------------------------------------------------------------
r8 | rgb | 2007-02-03 07:21:00 -0500 (Sat, 03 Feb 2007) | 2 lines

This actually works.  Now to add the other two clients...

------------------------------------------------------------------------
r7 | rgb | 2007-02-03 06:54:43 -0500 (Sat, 03 Feb 2007) | 2 lines

BEFORE I run this and maybe overwrite include, let's save this.

------------------------------------------------------------------------
r6 | rgb | 2007-02-03 06:40:30 -0500 (Sat, 03 Feb 2007) | 4 lines

This is getting CLOSER to a build.  I do need to get my dependencies
right in the toplevel makefile, as the tgz needs to autorebuild when the
rpm is made.

------------------------------------------------------------------------
r5 | rgb | 2007-02-02 20:22:18 -0500 (Fri, 02 Feb 2007) | 3 lines

OK, this now actually "works" to make a tgz, we could start to work on
rpms...

------------------------------------------------------------------------
r4 | rgb | 2007-02-02 20:11:30 -0500 (Fri, 02 Feb 2007) | 2 lines

We'd better check this in lest we lose things...

------------------------------------------------------------------------
r3 | rgb | 2007-02-02 17:46:26 -0500 (Fri, 02 Feb 2007) | 2 lines

Well, we do need to check this in before we drop anything, sigh.

------------------------------------------------------------------------
r2 | rgb | 2007-02-02 16:50:26 -0500 (Fri, 02 Feb 2007) | 3 lines

OK, this checks in a completely ported libwulf that should be
build/installable from the toplevel Makefile.

------------------------------------------------------------------------
r1 | rgb | 2007-02-02 15:07:43 -0500 (Fri, 02 Feb 2007) | 3 lines

This should be interesting.  This is a shell for the whole wulfware
project...

------------------------------------------------------------------------
