Some packages with very odd file deps - I wanted to check on.
I was going through the tree looking for packages that had file deps
that did not match:
so here is what I found - some of these are odd:
this file is part of redhat-menus and apparently nothing else - why
not just depend off of that?
ditto of above.
ditto of above.
/usr/share/pixmaps/splash/gnome-splash.png - in fedora-logs
/usr/share/magic.mime - part of file - why not depend on that?
/usr/lib/news/lib/innshellvars.pl - this file is actually provided by
/usr/share/openldap/migration/migrate_common.ph - this file is provided
by openldap-servers :)
/usr/X11R6/lib/X11/XKeysymDB - xorg-x11-libs-data - kinda lengthy but
why not list it?
- these are both provided by redhat-lsb
- how about depending on up2date instead?
- depending on 'perl' is just not ok?
/usr/share/dict/words - this one baffles me - why does stunnel depend
why do these two depend on a directory?
thoughts on these?
I'll be glad to fix the spec files up and get rid of these file deps.
When I tried to disable firewall on install, Anaconda die with:
Traceback (most recent call last):
File "/usr/lib/anaconda/gui.py", line 759, in nextClicked
rc = self.currentWindow.getNext ()
File "/usr/lib/anaconda/iw/firewall_gui.py", line 32, in getNext
File "/usr/lib/anaconda/security.py", line 39, in setSELinux
raise ValueError, "Setting to invalid SELinux state: %s" %(val,)
ValueError: Setting to invalid SELinux state: -1
Local variables in innermost frame:
self: <security.Security instance at 0xb7d8c0cc>
Solved installing with FW enabled
Given that FC2 is scheduled to be released on May 17, would it be
possible to extend the errata lifetime for RH9 by one month, making EOL
happen on May 31 instead of April 30? That would allow for a smooth
upgrade from RH9 to FC2, with a few days to the mirrors to catch up,
some margin for delays and even time for the most common quirks to hit
-----BEGIN PGP SIGNED MESSAGE-----
Again, an old nasty problem is back: using the latest
linux-2.6.5-1.327, when I attach an IOMEGA ZIP CD (USB) (RW) unity to
USB port, usb_storage recons it and registers correcty (both at /sys
and /proc/...), device /dev/scd0 is active (I can read CDs) and I got
a message indicating that it was registered as sr0 (althought I cannot
have access do /dev/sr0). But the device is not reconned by sg.ko (is
is not registered).
The first consequence of this behaviour is that I cannot record
anything using the unity.
I tried almost everything: from the module loading order, etc.. (this
worked in old RH8.0).
Have anybody had the same probem?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
This is a reminder of the mailing lists for the Fedora Project, and
the purpose of each list. You can view this information at
When you're using these mailing lists, please take the time to choose
the one that is most appropriate to your post. If you don't know the
right mailing list to use for a question or discussion, please contact
me. This will help you get the best possible answer for your question,
and keep other list subscribers happy!
Mailing lists are email addresses which send email to all users
subscribed to the mailing list. Sending an email to a mailing list
reaches all users interested in discussing a specific topic and users
available to help other users with the topic.
The following mailing lists are available. To subscribe, send email to <listname>-request(a)redhat.com
(replace <listname> with the desired mailing list name such as
fedora-list) with the word subscribe in the subject.
fedora-announce-list - Announcements of changes and events
fedora-list - For users of releases
fedora-test-list - For testers of test releases
fedora-devel-list - For developers, developers, developers
fedora-docs-list - For participants of the docs project
fedora-desktop-list - For discussions about desktop issues such as user
interfaces, artwork, and usability
fedora-config-list - For discussions about the development of
fedora-legacy-list - For discussions about the Fedora Legacy Project
fedora-selinux-list - For discussions about the Fedora SELinux Project
fedora-de-list - For discussions about Fedora in the German language
fedora-ja-list - For discussions about Fedora in the Japanese language
fedora-i18n-list - For discussions about the internationalization of
fedora-trans-list - For discussions about translating the software and
documentation associated with the Fedora Project
Brazilian Portuguese: fedora-trans-pt_br
Simplified Chinese: fedora-trans-zh_cn
Traditional Chinese: fedora-trans-zh_tw
1. Name: Peter Edward Popovich
2. Location: Orlando, FL, US
3. Profession: Consultant
4. Company: Self-employed
5. Your goals in the Fedora Project
* Which packages do you want to see published?
crm114, tre (tre, tre-devel, tre-agrep), nagios, perhaps someday rt.
* Do you want to do QA?
* Anything else special?
Nothing else comes to mind.
6. Historical qualifications
* What other projects have you worked on in the past?
Formerly: Director of Online Operations, MAPS.
Editor, Fidonews Software Versions List.
Currently: Packaging crm114 rpms for SourceForge file release.
* What computer languages and other skills do you know?
* Why should we trust you? <--- too blunt?
Depends on one's definition of "trust".
As Director of Online Operations for MAPS, I oversaw day-to-day operations
of the RBL, RSS, and DUL projects, used to block spam by thousands of
sites, including several major ISPs and tier-1 providers. At the time, it
was operated as a philanthropic not-for-profit community service project,
with dozens of volunteer contributors.
That doesn't necessarily mean anyone should trust me, though.
7. GPG KEYID and fingerprint
[kani:i686] gpg --fingerprint 39CD7551
pub 1024D/39CD7551 2004-04-26 Peter E. Popovich <peter(a)popovich.net>
Key fingerprint = 7A22 25E2 6BB4 6B63 5DAF ED79 FEDA 1742 39CD 7551
uid Peter Popovich <peter(a)popovich.net>
sub 1024g/D7B7D9DF 2004-04-26
I know the rawhide kernels are more about testing and saying, "hey,
would this day-old feature be cool to eventually put into production",
but what's the philosophy on the FC2 kernel? Has it already been
decided that it will be an older version? I haven't tried all of the
new kernels, but neither the nvidia nor the savage X drivers have worked
on any kernel I have tried since 2.6.3-1.118. I know a lot of people
have said, "Blame NVIDIA. They don't come out with a new driver every
week to match the way our kernels are changing", but I don't think this
is a reasonable stance. The nvidia module is widely used, and I think
to say that FC2 doesn't support it may be a serious issue for some
people. I know most people don't care about the savage driver, but I
wonder if a new one will ever be released. I don't think its a good
idea at this time to include a default kernel that isn't backward
compatible in this respect to the older ones.