Nobody stepped up to maintain this crypto library which is no longer
used by rpm or anything else in Fedora. So the next logical step is to
retire this package from rawhide (dist-f9).
I will do that tomorrow.
No matter how far down the wrong road you've gone, turn back.
here are the latest changes for system-config-firewall for F-9+:
The usage of --port=<port>:<proto> for lokkit will open up this port and
not a service using this port anymore. To enable a service you have to
use the new --service=<name> option. There are no magic default open
services. You have to open up the services, you want to use. The interim
options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now.
To setup a new firewall, you can use the new --default=<name>
configuration option as a start:
server : ssh is enabled
desktop : ipsec, mdns and ipp are enabled
These changes for lokkit also affect the kickstart firewall configuration.
There is an utility to convert existing configurations, which will be
used automatically while updating the package.
Today InstantMirror is pretty useful for home and small office mirrors,
but its limitations make it unsustainable without manual intervention of
I've been beginning to think that perhaps InstantMirror is heading down
the wrong path and we seriously need to rethink it. There are simply
too many limitations of the current "stateless" operation of
InstantMirror where it runs only on-demand as mod_python script:
- Synchronization/locking of multiple connections downloading the same
file is awkward and broken.
- There is no good way to clean up aborted tmp files.
- There is no good way to know what are old files that need pruning.
- There is no good way of keeping track of the "Big Picture" of its own
cache, "least recently used" knowing what files were unpopular locally
and should be pruned.
We need a daemon to handle all this. Perhaps the daemon could allow
socket connections from a mod_python script for accesses. Or perhaps it
might be better for the daemon itself to handle serving connections.
Stepping back, what we really need is:
A reverse proxy caching server with all the logic of squid or varnish,
except it stores its cache with file and directory names intact.
How do we get there?
1) Write a new daemon from scratch?
2) Write a new backend storage engine for squid or varnish? (Store
files in target directory structure, store metadata elsewhere.)
I have difficulties building pl on ppc64. The previous build (a few
releases back) has been fine, and i386, x86_64, ppc are ok, too. The
koji build page is:
The 64-bit ppc arch seems to cause a lot of trouble compared to the
32-bit arch and x86_64. Is there any specific reason for this? In any
case I hope someone can help fixing the issue.
BTW. I would welcome a co-maintainer for the pl package, preferably
someone with experience on archs other that i386.
-----BEGIN PGP SIGNED MESSAGE-----
I would like to ask you, why was a package "alien" removed from RH distros?
Alien is a program that converts between the rpm, dpkg, stampede slp, and
slackware tgz file formats. (http://kitenet.net/~joey/code/alien/)
Zdenek Prikryl <zprikryl(a)redhat.com>
Software Engineer - Base Operating Systems Brno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
As some of you may know I've been packaging and testing nouveau (the
free NVIDIA 3D driver) for some time. The current way the driver is
packaged is making things very difficult to properly test on fedora:
* The xf86-video-nv-2.1.5.tar.bz2 and nouveau-gitID.tar.gz are included
in the xorg-x11-drv-nv-2.1.5 srpm.
* This srpm spits out xorg-x11-drv-nv-2.1.5 and
xorg-x11-drv-nouveau-2.1.5 rpm files when built.
This poses me problems as:
* I can't easily keep the original nv rpm intact when building the new
* The upstream version of nouveau ddx is 1.2.0, and the rpm version is
* I can't uninstall the xorg-x11-drv-nv driver to test nouveau from
source without nuking the nv driver too.
I understand that one day the nouveau ddx will replace the nv ddx, but
this can be accomplished with standard rpm obsoletes rather than
shipping the nouveau source in the nv srpm. For me, I think the proper
way of doing this would be to:
* Have a nouveau srpm *and* a nv srpm - they are different codebases and
have different version numbers
* Somehow fix the brokenness that has lead to the version number
xorg-x11-drv-nouveau-2.1.5 being installed when actually installed was
Is anyone else seeing regular crashing of applications like pidgin,
mplayer or xine caused by pulseaudio? Did anybody manage to get useful
backtraces out of this?
(cc dwmw2, fedora-devel)
Josh Boyer wrote:
>> I'd like to import the latest version of ctrlproxy because
>> 3.0.2 randomly crashes every few days of operation.
> Odd, I've been running it without problems for quite a while.
Hmmm... Must be something specific to my configuration, then.
I'm thinking x86_64, or the fact that I connect through 2 xchat
clients all the time. Or irssi-style logging.
>> Additionally, I wrote an initscript to run ctrlproxy
>> as a daemon. Would you approve such a change to the package?
> Oh, interesting.
I've scratch-built a candidate RPM for you to try:
It includes both ctrlproxy-3.0.5 and the daemonization work.
I'm also cc'ing dwmw2 because I know he uses ctrlproxy and
may like to test this new version.
> Could you open a bug in bugzilla and attach a patch there? (Or point
> to the SRPM from there.) I'd certainly be interested in the changes.
Unfortunately, I could never catch ctrlproxy 3.0.3 crashing
when I had enabled coredumps with ulimit. Since I upgraded
to 3.0.5, I've not yet seen another crash.
|___| Bernardo Innocenti - http://www.codewiz.org/
\___\ One Laptop Per Child - http://www.laptop.org/