I should sit on #fedora-devel . I don't, for the very simple reason that
the FreeNode server uses an authentication machanism for nicknames where
my nick is "owned by someone else" , is "private" and there is no way
apparently to get out of the situation except changing nick which I
consider more than an annoyance.
Can we find a way out:
- have a contact to handle authentication conflict
- drop the authentication mechanism
- change server
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

While I am unable to sleep despite taking a sleeping pill, I might as
well give the status update about gaim in Fedora Core.
Late Wednesday night gaim-0.82 was released which resolves various
security and crashing issues. It was a very good release, but
unfortunately upstream discovered a nasty crash that would lead to 3
weeks of annoying duplicate reports and complaints. In an admittedly
unwise move 18 hours later they replaced the gaim-0.82 tarball silently
fixing that one issue. But I think they said it wasn't entirely fixed
correctly.
This of course can lead to all kinds of confusion for us distributors,
as Fedora and other Linux distributions had already issued updates with
the original 0.82. So we requested a 0.82.1 release which happened late
Thursday.
Rawhide now has 0.82.1-1 which should work very well. gaim-0.82-0.FCX
released in updates has only one crash in the corner case of the user
having open windows with buddy icons while they change the button
display preferences. Most users will probably never run into this
problem. In any case, I do not consider this issue to be reason enough
to issue the already too frequent gaim updates.
In the future I am hoping to help gaim upstream establish a better
formalized testing procedure, perhaps with release candidates with
automated distribution of binaries to an army of eager testers. It will
take something like this in order to avoid many regressions that are
always discovered after each gaim release.
We the Fedora community are well equiped to provide valuable feedback.
I will probably be announcing a more rapidly changing gaim
side-repository along with testing/reporting methodology documents later
in the next upstream gaim development cycle.
I am also especially interested in hearing any suggestions from Fedora
developers about ways to further integrate gaim into other desktop
components, to provide a more smooth & cohesive desktop experience.
One example that needs help is in gaim + evolution integration.
Currently the plugin is included in rawhide gaim, but disabled by
default since it has been unstable in my limited testing. Volunteer
help is needed there to try it, and communicate with both gaim &
evolution upstream to figure out how it can be fixed/improved.
Ok... might be able to actually sleep now...
Warren Togami
wtogami(a)redhat.com

With udev now handling /dev and repopulating upon reboot, it seems that
the dev and MAKEDEV packages are no longer relevant. However, they can
not be uninstalled due to manual requirements for some packages:
[root@dhollis-lnx i2c]# rpm -e dev MAKEDEV
error: Failed dependencies:
dev is needed by (installed) which-2.16-4
dev is needed by (installed) mod_ssl-2.0.50-4
dev is needed by (installed) kdelibs-3.3.0-1
dev is needed by (installed) mkinitrd-4.1.1-1
dev is needed by (installed) initscripts-7.67-1
MAKEDEV >= 3.0 is needed by (installed) raidtools-1.00.3-8
I'm not terribly concerned about these packages from a space perspective
(especially since all of dev's files get blown away anyway!) but now rpm
--verify dev blows up in all kinds of fun ways since all of its files
are missing. With the active discussions about udev, I'm quite certain
that it is not the only way to do things at this point and the dev and
MAKEDEV packages will remain for those that prefer that method, but
should these dependencies be investigated to see just how necessary they
really are?
--
David T Hollis <dhollis(a)davehollis.com>

In reference to this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122304
Just wondered if anyone had a good way to detect a 64-bit platform in
the context of an RPM spec file. While building for the Alpha, we've
come across similar situations a couple of times, where we turn up a
bug that's already patched, but it's %ifarch-ed to x86_64 or whatever
or, like in this case, just checking for "lib64" being used instead of
"lib".
Aside from just manually updating ifarch lists for patches, is there
any good way to just pull in a patch on any system that happens to be
64-bit? Of course, if there's not, that's no big deal, but thought it
might be worth mentioning in case someone comes up with something
brilliant. :)

Can the FC3 xterm be compiled with support for 256 colors enabled?
(i.e. configure with --enable-256-color)
This would enable applications to take advantage of a higher number
of colors.
For example, the next version of Emacs will have support for 256 color
xterms.
With that support, syntax coloring in emacs running in an xterm looks
almost identical to emacs running in X11. This is great for using
emacs over slow connections.
As an illustration of this means, please look at:
http://www.ics.uci.edu/~dann/emacs-X11-256c-8c.jpg
It shows (from left to right) 1 X11 emacs frame (with the toolbar and
scrollbar turned off), 1 emacs running in a 256 color xterm
and 1 emacs running in a classic 8 color xterm.
font-lock-* are the colors emacs uses for syntax highlighting, observe
that there's almost no difference between the colors used by the X11
emacs frame and emacs running in a 256 color xterm.
(This support is not present in emacs-21.3 but it can probably be
easily backported, if desired. It would probably be an ~200 lines
patch -- elisp only).
Thanks.
--dan