Rpmfind(s)
The saga of restoring rpmfind services goes on, of course
a couple of hours after I wrote about rpmfind.net being back
in shape one of the drives died, apparently it makes a cyclic
click audible though a closed door :-\ , it was hosting the
packages pages of course, Murthy in action. I will swap a
new drive in probably today. In the meantime the speakeasy
people contacted me, they built a new box, first surprize is
that it's an Opteron box :-) , they initially installed
the x86 RHEL version which was working surizingly well, but
they reinstalled with the AMD64 version, I don't know for
desktop work but for servers x86_64 rocks. Rebuilding the
services takes a while still, even at 2MBytes/s it takes an
awful long time to resynch hundreds of gigabytes of mirrored
stuff.
gamin
Struggling quite a bit with some bizarre behaviour I
want to fix before pushing it as the replacement for fam
in Fedora Core. At least it builds, but debugging threaded
stuff is a pain, I absolutely need to remove the threading.
I also think I will not enable Suspend/Resume operations
that FAM provides, they mean the server has to stack
operations if the client asks for them and this really
doesn't sound like a proper client/server model for
operations. Beside that I doubt it's used anywhere on the
desktop, well pushing it for test2 of Fedora Core 3 should
help find if it's too strict or not.
GCC aliasing and runtime profiling
Seems other people are interested at shaving their code
size by 5-10% following the work done with Arjan on gcc
aliasing for library symbols and using gcc runtime
profiling. fcrozat also activated it on
the Cooker build and gained 7% on size apparently. Seems
gtk and some parts of OpenOffice are also potential
candidates for those optimizations.
libxml2 and libxslt
Despite the number of changes made in the last release
they seems stable, ncm might a bit
optimistic (or ironic ;-) to call them "stellar". William
and Kasimier chased down a problem in Schemas debugging
showing up only in 64bits. William had the machine with
64bits and Kasimier had the knowledge of the code. This
resulted in a long IRC session of cut and past gdb and
discussion. I think a GDB <-> IRC connector would rock,
just so often people manage to get into a problem, but
reproducing it outside of their environment is nearly
impossible (code/data/platform issues are not always
shareable), If we had a standalone python (or perl :-\)
script which could create a gdb (or other DB) session
and gate it as a user on a public IRC channel, there is
tons of obscure bugs that could be debugged in a matter
of minutes instead of standing unreproduced in a bugzilla
entry. Googling a bit for this I could not find any such
tool, it should not be too hard too do, but IMHO would
be extremely valuable.