On Wed, 2006-06-14, Jeremy Katz <katzj(a)redhat.com> wrote:
> On Thu, 2006-06-15 at 08:31 +1000, David Timms wrote:
> > 2. Able to boot or instigate boot from external usb / firewire hdd.
> > Reason is employer does not like employees screwing with work provided
> > notebooks. This would allow more home usage of linux (even when you are
> > not allowed to), whether it be a live distros or complete installs.
> This functionality should be present in test1. Having testing from
> other people would be greatly appreciated!
Did this make fc6t1? I'd like to test it, but I'm not seeing USB drives
detected using installation (even with the 'linux expert' boot line,
which seems like a regression).
I've just taken a good look at ImageMagick after being bitten by a bug
in convert, which I use in some of my spec files.
The open bug list on ImageMagick is quite long (not really long though)
and some of those bug look like they are not too hard to fix. So it
looks like ImageMagick could use some love and attention.
Now without doubt the same goes for many other core packages. I have the
feeling that with the ever growing and competent FE community we are
missing out on a chance here. We need some kinda mechanism for Core
package maintainers to mark bugs as
"easy fix" or
"fixing this should be doable, packaging"
"fixing this should be doable, C programming"
"fixing this should be doable, PERL"
So that Core package maintainers who as we all know are a bit swamped
can mark bugs, which look like low priority but should be fixed never
the less, with one of these and FE contributers interested in helping
out can then find these bugs by these markers (blocker bugs / keywords?)
and write a patch.
Preferably in the end some in the community should get direct access to
FC cvs / svn so that we can really _scale_ up the developer effort put
I've put together some python 2.5 (beta 1) packages. You can grab them from:
The packages should install cleanly side by side with the standard python
2.4.3 packages. Applications will continue to use 2.4 unless you explicitly
invoke python25 or python2.5 (or your #! line says python2.5).
If you want to see a glimpse of what is coming up in the python world, go
ahead and check the packages out.
If there is interest, I can produce packages for FC5 too.
After applying today's updates to my system, an IBM ThinkPad T23, I notice
intermittent desktop freezes during which it's even impossible to move the
mouse pointer for 5-10 seconds. Running 'top' in a shell, a process
"events/0" is reported at the top of the process list with a load share of
about 80% after the system has become responsive again. Similar observations?
I couldn't find this issue addressed in the fedora pacakging guidelines page,
so I'll pose it here-
(How) Should one go about detecting in pre/post(/un) scripts in an rpm, whether
or not the rpm (de)installation is occurring on a live running system, or
within a chrooted (e.g. anaconda installer) based environment.
Specifically, lets pretend like qemu author decides to open source the kqemu
It would seem you would want to modprobe the module during the post install,
and rmmod it during the postun(install). But you would only want to do these
things if the rpm was being installed on a live system. Not if you were doing
an rpm install in a chrooted environment (or whatever anaconda does during it's
Now mind you, it's an entirely seperate question which I would like answered,
as to whether or not in the above case, there is a way to configure things such
that the kernel module gets autoloaded whenever qemu runs and tries to open
But the general idea of not wanting to execute parts of your rpm installscripts
in the situation of chrooted, rather than live (un)installs, seems quite
relevent for many situations. (and it seems like you would still probably want
to unload the old version of the module on uninstall if the autoloading
mechanism didn't also auto-unload).
Am I missing something? Feel free to point me to a link to a prior thread
which hashes out this issue.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
Why are the people in charge of the kernel RPM making seperate RPMs for
non-SMP and SMP?
The main feature in 2.6.17 is the autodetection of such CPUs! This should
reduce it to just one package and could enable the use of one kernel
package across multiple machine configurations.