Menu Policy - please read if you maintain a package with a .desktop file in it!
by Seth Nickell
1) Don't change menu structures without asking. FYI, most of the time
the answer will be "no".
2) If your package is in any of the default package sets:
a) You must get approval for any changes that change the menus. This
includes renaming items or adding new .desktop files. In other words,
almost any change to a .desktop file, save translations.
b) The menu item should usually be the application's
generic/descriptive name. For example, use "Web Browser" instead of
"Mozilla" or "Mozilla Web Browser".
3) If your package is NOT in any of the default package sets:
a) The menu name should usually be the application's given name + the
generic/descriptive name. For example, use "Mozilla Web Browser" instead
of "Web Browser" or "Mozilla".
3) The default packages in the package sets (in the comps file) may not
include any applications that are functional duplicates. In other words,
if the user clicks all the package sets in the installer (other than
everything), they should not end up with two web browsers or two
spreadsheets in the menus. To give a hypothetical example, lets say we
shipped Gnumeric as one of the default apps in the "Office" package set.
In this case OpenOffice.org Calc should not show up in the menus, even
if the openoffice.org package is installed (presuming we install the
rest of openoffice by default). One way to address this would be to
include a separate "openoffice.org-calc" package that simply installs
a .desktop file.
a) Exception: Although KDE and GNOME overlap we include both in
package sets. To deal with this, we mark smaller utilities and core
desktop pieces that overlap (e.g. gnome-utils, kdeutils, kdebase,
kdemultimedia, gnome-media, kdeadmin, etc) with "OnlyShowIn=...". That
way we still don't get overlapping menu items. By default all items in
these sort of packages should be marked OnlyShowIn. Ask me about
specific things you think should be exceptions.
Some general guidelines:
- Include a generic version of the name, even if your app isn't install
by default (e.g. "Mozilla Web Browser").
- Don't add menu entries for things for the heck of it. For example, the
number of people who launch emacs from the menus is probably very
small. ;-) If its mostly launched from the command line (could still be
an X application, note), don't put it in the menus.
- Don't add a bunch of entries for the same application unless its a
really big monster application (like OpenOffice.org). For example,
KBabel, a translation tool has three menu entries. It shouldn't!
- Don't have a "_____ Configuration" menu entry (e.g. Chromium
Configuration). Configuration should be launched from inside the app. If
its not, cry, but don't add it to the menus ;-)
As soon as we have a Fedora wiki, I'll put this information up there and
maintain it.
-Seth
19 years, 11 months
Kudzu issue
by Peter Arremann
Hi,
we've a couple of different systems here that all experience the same
problem - Network cards get configured correctly during the install
but when you reboot, the devices get re-detected every time. We've
been able to reproduce the problem with the KT600 integrated VIA-Rhine
and realtek 8139 cards.
I've looked at the issue quite a bit and the problem seems to be that
the ioctl calls for the hwaddress detection fail if the interface is not
up. You can verify that by booting the system in single user mode, loading
the drivers by hand and then run kudzu. it will try to reconfigure the
device. Ignore that. Then use ifconfig to up the device (no IP required)
and then rerun kudzu.. it should work this time - at least on the 2 cards
I've tried that fixed the problem.
The code that acutally fails is in kudzu.c getNetInfo (790-810). I've no
problems fixing it and sending in a patch but to do so I'd like to
A) Know that this really is the issue and if it happens on other cards.
B) The best way of fixing this. I see several options...
1) Have a list of drivers (the driver is known at that time) that
can't handle this ioctl call and then just not detect the hwaddress
2) Have a list of drivers and just bring the interface up if it isnt
3) Just simply gracefully fail and make an entry in the netdev list that
is returned by getNetInfo with a special null entry for the hw address
and then modify the compareDevices code to handle that special value.
Any input/ideas?
Peter.
19 years, 11 months
Searching 4 Fedora core 2
by Morteza A. Nia
I'm using fedora core 2 test 3 , but i wanna core 2 ( real version ).
where can i find it. I wanna to achive it before its schedule! ;)
19 years, 11 months
Re: Fedora Tracker (big) Update
by Brad Smith
On Mon, 2004-05-17 at 15:35, Steven Pritchard wrote:
> On Mon, May 17, 2004 at 12:29:51PM -0400, Brad Smith wrote:
> > * (probably related to #1) Currently some repos fail to index because
> > tracker-process.py doesn't provide a useragent string. Fix.
>
> I had to remove the block on empty user agents... Apparently anaconda
> doesn't send a user agent header when it requests stage2.img, so I
> couldn't do net installs. (I didn't figure this out until I tried to
> do an x86_64 net install. Apparently squid on my firewall had the
> i386 version cached, so my i386 installs were working fine. Fun
> stuff...)
>
> Steve
Ok. Good to know. I'll still try and fix it so at least repo maintainers
will know who to yell at if tracker starts banging on their servers too
often. =;)
--Brad
19 years, 11 months
Fedora Tracker (big) Update
by Brad Smith
Hey folks,
Well, I've been working off-and-on for the last couple of months to
implement feedback I've gotten from people on this list, along with a
few features that I've deemed necessary.
All-in-all I think things have worked out pretty nicely and believe that
tracker is just about ready for prime-time. I'd like everybody to take a
look at the latest changes and report any problems or major suggestions
asap. If nobody gives me a good reason not to, I'm going to start
shouting from the rooftops in an attempt to make the resource known and
we can start seeing how it handles under an actual load.
One known issue is that a few repositories like the livna non-us didn't
index when I rebuilt the db. I'm working on it.
The url, as always is: http://www.fedoratracker.org/
Changelog highlights follow:
=========================================================================
* The repo search page now has an option to generate apt/yum config
files for matching repos.
* Package and repo description search fields now support negation by
prepending '!' to any non-regex criteron. For example, you can search
for "game !rpg !puzzle".
* Package name searches are regex searches by default, so a search for
"gnome" will match *gnome* instead of nothing.
* There is no longer a field for searching by filename in the package
search dialog. Removing the need to join the repo and package tables
with the file table (which at last count had about 1.4 million records!)
has _vastly_ improved search performance. Look for searching by filename
to be added as its own search mode soon.
* The repo and package search pages now have fields for searching by
Fedora release number. These fields default to searching version 1
repositories. This will change once FC2 and co become more widely used.
* To prevent users from accidentally installing unstable packages, any
repo with "unstable", "testing" or "bleeding" in the description will be
skipped in repo or package searches by default. This is changable with a
checkbox. Eventually I would like to have a simple unstable/stable (or
something like that) chooser for when repos are added instead of
searching repo description. For now, just mind your wording when adding
a new repo (and DO use those keywords where appropriate!!)
* On the back-end I am just working the final kinks out of having
tracker-process recognize and update the db entries for repositories
that have added or removed packages.
Some things on my TODO (in rough order of priority):
===========================================================================
* Some repos didn't index when the db was rebuilt. Fix.
* Add a new search mode for searching by filename
* Change the various search interfaces to be static html pages instead
of modes of the script. This should improve performance under heavy
loads.
* The requires,provides and obsoletes fields are now stored for each
package, but currently nothing is done with them. I'd like to at least
let the user print out their values, similarly to how the changelog
field is currently handled.
* (probably related to #1) Currently some repos fail to index because
tracker-process.py doesn't provide a useragent string. Fix.
Thanks in advance to anyone who can help out,
-- Brad
19 years, 11 months
Module symbol versions in installer kernel
by Paul Gear
Hi folks,
I'm very sorry to bother you all with this, but i've asked this before
and never received an answer: what controls the presence or absence of
module symbol versions in the FC1 installer kernel?
I have a module that works fine after install, but can't be used in the
installer (either by plain insmod or by creating a driver disk) due to
the fact that it is looking for versioned module symbols that aren't there.
I have read all of the documentation i can find on this, but can't find
anything relevant in my searches due to the fact that the keywords are
too common and thus the results are not specific enough.
Could you please spare me a couple of minutes to explain what is going
on or point me to some relevant documentation?
Thanks,
Paul
http://paulgear.webhop.net
--
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
19 years, 11 months
*Heads up* for FC1 Alsa users from fedora.us
by Thorsten Leemhuis
Hi *,
users that have installed the package alsa-driver (needed for the alsa
kernel-modules) from the fedora.us repository should update to the
latest Version 1.0.4-0.fdr.2.1 before they upgrade to FC2. This version
is out since one week, so if you use yum, up2date or apt to keep your
system always up2date you should already have it installed. All other,
please get it at your local mirror or directly at
http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/alsa-driver-1....
This version avoids a conflict during an FC1 -> FC2 update between
alsa-driver and the new MAKEDEV package.
Also note that it may be a good idea to remove all alsa-packages from
fedora.us before upgrading to FC2 as it contains alsa itself, but in an
older Version (fedora.us currently at 1.04, FC2 ships 1.03). This is no
must as the newer version should not do any harm. *Should*.
If you miss(ed) it and run into any alsa related errors after FC2 update
please remove alsa-driver, kernel-module-alsa*, alsa-lib, alsa-utils
(for the last two you properly need --nodeps parameter for rpm) and
install the FC2 packages from you FC2 install media afterwards to
resolve depencies.
BTW, Sorry for crossposting, I think this time it's worth it. Further
discussion should go to fedora-list, please.
BTW2: Is there any interest in alsa-tools and alsa-firmware packages for
FC2? FC2 will not ship them AFAIK, but I could try to package them for
fedora.us if there are interested users.
Thanks
CU
thl
19 years, 11 months
The Fedora Hardware Project
by Chan Min Wai
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
How is this hardware Project working? any plane?
and by the way are fedora going to come out with some test suit like RHEL3?
Like with the link below?
http://hardware.redhat.com/hcl/?pagename=files
Which will actually increase the speed of testing hardware.
However I don't really know if this work :)
Thank You
Chan Min Wai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFApnRWV0p9slMZLW4RAmJLAKD4gv+gaXdP5yX0q9l4js2IDc9MaACdFB15
pEegsnLgHzmXkP48pUCWY0M=
=Rz1E
-----END PGP SIGNATURE-----
19 years, 11 months