Before we put upstart into the main tree for the feature freeze, we want
to make sure we have all the big bugs worked out. If you're interested in
helping out, read on!
To start, just grab the repo file at
and do an upgrade (or 'yum install upstart event-compat-sysv')
WHAT WE ARE LOOKING FOR
Confirmation that the system boots and runs more or less as expected.
If you're using SELinux, make sure you're running the latest rawhide
policy, as well as an initramfs made with the latest rawhide mkinitrd.
This is because upstart does not load policy directly - it relies on
policy being loaded from initramfs.
Please file bugs against the proper components in bugzilla; if you
want to see known issues, take a look at:
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 get this error from rpmlint, but there's not much guidance on what
to do about it. Apparently it's because the META-INF/MANIFEST.MF file
is missing from the jar file. However these jar files still seem to
work OK with everything I've tried, so should I just ignore this?
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/threads.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/bigarray.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/stdlib.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/dbm.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/graphics.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/str.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/unix.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/nums.jar
ocaml-ocamljava.i386: E: no-jar-manifest /usr/lib/ocaml/cadmium/cadmiumLibrary.jar
Here's the package I'm building:
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
What happened to this sysctl? It appears that some stuff depends on
this setting, e.g. kqemu. There is only a hpet.max-user-freq now and
I get this funky permission error on 'sysctl -a':
# /sbin/sysctl -a | grep freq
error: permission denied on key 'kernel.sched_nr_migrate'
dev.hpet.max-user-freq = 64
# /sbin/sysctl -n -q dev.rtc.max-user-freq
error: "dev.rtc.max-user-freq" is an unknown key
I've compiled a list of all packages that have a file dependency
outside of these globs:
I'm going to file a bug against each of the packages to see if we can
work out a virtual provide/requires to deal with this problem.
The issue is this: In order for apt/smart/yum to depsolve for a
each of them have to download the full filelists for ALL enabled
repositories in the configuration.
For Everything it is 8MB
For Updates it is 3.5MB
That's a fair sized chunk. In the shape of updates it gets updated
frequently and it needs to be re-downloaded. That's unfortunate for a
lot of users.
So I'm going to file bugs against each of the packages which have this
issue and we're going to work out a solution. One way or another. :)
What I'm going to recommend for the moment is that for each package with
a file-dep for multilib purposes we consider making virtual provides in
the corresponding providing pkg[s] that handle the declaration
per-architecture or library-type.
In some cases this is just legacy dreck that we can now clean up.