May I wonder what's the status of this bug?
It was reported when FC6 was just released however it is still not fixed
today in FC6 and we have been forced to upgrade to Fedora 7.
Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F)
A set of CD ISOs and a DVD ISO based on the Fedora 7 test4 ISOS of the
ia64 Fedora development branch (also known as rawhide) are available from:
(Click on Download on left-hand side, and then the F7-test3 directory)
Please remember that F7 ia64 is _unsupported_ by Fedora. You can file
but be sure to file them against the devel branch of Fedora Core. Also,
add "fedora-ia64" to the "blocks" field of the BZ.
A new feature, the rescue CD, has been added to this release.
While upgrading to Fedora 7 Test 4 fixed the intel video driver bug,
another important feature is compromised.
I was not able to wake up my laptop (Dell 700M) from a
suspend-to-RAM. Anyone seeing similar problems? Is there a workaround?
I filed a bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238342
Leo <sdl.web AT gmail.com> (GPG Key: 9283AA3F)
Is it possible to grab video from firewire camera with new IEE1394
When i power on camera there is /dev/fw1 made
but from dvgrab i get "no camera".
As i understand dvgrab needs a raw1394 module loaded for working
but there is no such module anymore.
Do we need new dvgrab or is there some other way.
I would like to see these patches make it in for FC7 test4, although it may
be a tight squeeze. Both patches should be against T3. The only thing
missing here is anaconda support, but I will need some help on that. I know
the anaconda support won't be for FC7 but we can make it happen for FC8.
The complete instructions for using the modified versions are posted on
will be prettier at a later date, but I wanted to get this out to the
community as soon as possible.
In short, with the modified mkinitrd, you can massage a FC6 and FC7 (test3)
CD installation into a fully encrypted installation (sans boot media). The
byproduct is being able to resume a hibernated session from an encrypted
disk as well as detected media for removable keys.
Extra functionality added to mkinitrd is ability to add persistent options
in /etc/mkinitrd.conf ... This also allows for some anaconda flexibility
when generating encrypted installation when we can get to that point.
I'll send this up through bugzilla as soon as I get my password reset.
ARGH! Thoughts and feedback are appreciated.
The early bird may get the worm, but the it's the second mouse that gets the
This also failed, trying again:
Ron Arts wrote:
> I have an additional question. If I install autogen-devel, there
> still is no options.h to be found. should I generate it somehow?
I am sorry to say that I use SuSE meaning that I do not know what is
in which package, except by what people tell me. My recollection
is that I was told that autoopts/options.h lives in the autogen-devel
Paul Johnson maintains autogen-on-fedora, so I'm forwarding this
to him for comment. Thank you, Paul.
P.S. _I_ generate options.h when I pull from the source repository
in a bootstrap step. If you wish to tweak and regenerate for
some reason, you'd need to pull CVS from savannah and run the
config/bootstrap script. You don't want to. ;)
using GMail, this bounced:
Hi Kevin Fenzi, Ralf Corsepius, et al.,
Some history and clarifications:
> I can't find this situation to be satisfactory and actually think this
> situation is messed up. But, AFAICT, nobody but autogen actually uses
> libopts, so this isn't much of a problem.
There are actually tens of projects that I personally know about that
use libopts. None are widely distributed. All of them redistribute
libopts. That is why I separated libopts from the un-disentangleable
(is that a word?) autogen distribution. The NTP project, however, has
a version in the pipeline that uses libopts, so there will be one you've
likely heard of soon. Though, again, it redistributes libopts.
So, the "libopts" package is for one purpose: to allow developers of
other projects to require that it be installed on production machines
in order to keep sources out of their own package.
"libopts" by itself is pretty useless. The interface is sufficiently
complicated that hand coding to it is infeasible. That is why a
definition language gets translated into C code and data structures.
That is what the autoopts templates do, with the help of autogen.
In turn, autogen uses these templates and the library to process its
options. Separating them is more pain than it is worth.
C.F.: Yeah, what a mess. ;(
I'd suggest either one big ball of wax (as I have done it for years),
or use the partitioning done by Debian:
libopts -- runtime library
libopts-dev -- headers, man pages, etc. for compiling a project with
autoopts generated source
autogen -- various binaries, templates and docs for generating source.
Matt Kraai is the maintainer: kraai in the debian organization.
He might give you some hints, Paul, about his reasoning.
Hope that makes the "mess" a little more understandable.