Joined: Aug 13, 2004 Posts: 335 Location: Maysville, KY
Posted: Fri Jan 13, 2006 3:58 am Post subject: fix could not find mime type or no mime types installed
I noticed after upgrading KDE recently that I was getting a random error whenever opening kchmviewer and a few other programs. The error message was always like this:
Code:
Could not find mime type
application / octet-stream
After selecting O.K., the next error message would display:
Code:
No mime types installed
This is relatively very easy to fix.
1. Logon to KDE
2. open a console (kconsole or whatever you use)
3. Enter -> rm -vf ~/.kde/share/config/ksycoca
4. For gentoo (and maybe others) Enter -> rm /tmp/kde-username/ksyscoca
For other distributions, the file may be Enter -> rm /var/tmp/kdeche-username/ksycoca
In both examples above, replace username in the command with the username you log into kde with (or the person who is having problems)
4. enter -> kbuildsycoca
5. Logout and login again
If during step 4 you get a bunch of messages similar to this:
hello. i am using a gentoo system. i have installed and run kaffeine and get that "mime type" error. I follow ur instructions above and as you have mentioned, during the step 4 some warnings occured. but i think, there shouldn't be any conflicting files on my system because i have installed kde 3.4.3 only once before, and i haven't updated any software on my system since then. so altough i have installed kde only once and not updated it, is it possible to have files from two different versions of kde that are conflicting? and is there any other solution instead of re-installing kde, because it takes too long to re-compile and install it.
btw, running kaffeine with a super-user account is fine, i just get the following warning with a su account:
kio_file: WARNING: KLocale: trying to look up "" in catalog. Fix the program
Joined: Aug 13, 2004 Posts: 335 Location: Maysville, KY
Posted: Fri Feb 10, 2006 6:17 am Post subject:
hgfdsa wrote:
hello. i am using a gentoo system. i have installed and run kaffeine and get that "mime type" error. I follow ur instructions above and as you have mentioned, during the step 4 some warnings occured. but i think, there shouldn't be any conflicting files on my system because i have installed kde 3.4.3 only once before, and i haven't updated any software on my system since then. so altough i have installed kde only once and not updated it, is it possible to have files from two different versions of kde that are conflicting? and is there any other solution instead of re-installing kde, because it takes too long to re-compile and install it.
btw, running kaffeine with a super-user account is fine, i just get the following warning with a su account:
kio_file: WARNING: KLocale: trying to look up "" in catalog. Fix the program
thanks in advance.
Welcome to the MLUG.
You shouldn't have any file conflicts if you haven't installed more than one version of kde. One thing that you could try is to delete the ksyscoca file for your username and then copy the one for root and chown it to your user name. Also, in my instructions above, it seems that gentoo has also moved the ksyscoca file to /var/tmp/kdecache-username so the instructions would be:
$ cd /var/tmp/kdecache-username (replace username with your normal user name)
$ rm ksycoca <remove the file>
$ kbuildsycoca
Log out of kde and log back in as the normal user. See if the problem still exists. If so, follow these next steps to see if the problems exist using the roots ksycoca file.
$ su - < change to root user - enter password >
# cp /var/tmp/kdecache-root/ksycoca /var/tmp/kdecache-username/ ( make sure you enter your user name for username - this step will copy the root ksycoca file to your directory to see if problem will still exist >
# chown username:username /var/tmp/kdecache-username/ksycoca < changes the username to your username for the ksycoca file we copied from roots folder - make sure to replace username with your login user name >
# exit < logs out of root terminal >
# exit < logs username out of terminal >
You can find out what version you are currently running by doing this command as root:
laptop ~ # gcc-config -l
[1] i686-pc-linux-gnu-3.3.6
[2] i686-pc-linux-gnu-3.3.6-hardened
[3] i686-pc-linux-gnu-3.3.6-hardenednopie
[4] i686-pc-linux-gnu-3.3.6-hardenednopiessp
[5] i686-pc-linux-gnu-3.3.6-hardenednossp
[6] i686-pc-linux-gnu-3.4.4 *
[7] i686-pc-linux-gnu-3.4.4-hardened
[8] i686-pc-linux-gnu-3.4.4-hardenednopie
[9] i686-pc-linux-gnu-3.4.4-hardenednopiessp
[10] i686-pc-linux-gnu-3.4.4-hardenednossp
If you don't have the * next to 3.4.4, then that could be your problem. The gentoo gcc upgrade guide says to do this (you may already have some of the programs below) :
If you want to follow this guide to the letter (step by step) here is the url
http://www.gentoo.org/doc/en/gcc-upgrading.xml I have quoted the quick method below, which is how I upgraded gcc to 3.4.4
# emerge -an gentoolkit
# emerge -uav gcc
Note: This assumes that you have CHOST="i686-pc-linux-gnu" set. If you are using another CHOST, please use the appropriate gcc-config line.
Now, we want to see which packages that revdep-rebuild will want to rebuild. Then we will tell revdep-rebuild to actually rebuild the packages. This may take some time, so have some patience.
Note: It is possible that you might have problems with non-existing package versions due to them being outdated or masked. If this is the case, you will want to use the --package-names option to revdep-rebuild. This causes packages to be recompiled based on the package name, rather than the exact name and version.
To provide compatibility with older binary C++ applications and any packages that revdep-rebuild might have missed, sys-libs/libstdc++-v3 needs to be merged before you unmerge GCC 3.3 from your system.
-----------------------
The slower way, using emerge -e:
This method, while much slower, will rebuild your whole system to ensure that everything has been rebuilt with your new compiler, and therefore safer. At first, you will upgrade GCC and libtool and switch to your new compiler.
Note: This assumes that you have CHOST="i686-pc-linux-gnu" set. If you are using another CHOST, please use the appropriate gcc-config line.
To provide compatibility with older binary C++ applications, sys-libs/libstdc++-v3 needs to be merged onto your system.
# emerge --oneshot sys-libs/libstdc++-v3
Now we will go about first rebuilding the system target, then the world target. This will take a very long time, depending on the number of packages that you have installed, as it will rebuild your entire toolchain and supporting system files, followed by every package on your system, including the toolchain. This is necessary to ensure that all packages have been compiled with the new toolchain, including the toolchain itself.
# emerge -e system
# emerge -e world
It is also safe to remove older GCC versions at this time:
hello, after trying all suggestions on this forum and on some others as well, nothing changed. so i migrate from kde3.4.3 to kde3.5.1 and all problem had gone away. thanks for all help efforts!
hello, after trying all suggestions on this forum and on some others as well, nothing changed. so i migrate from kde3.4.3 to kde3.5.1 and all problem had gone away. thanks for all help efforts!
thanks for replying with what you did to fix your problem, maybe it will help someone else.
Printed below:
Tutorial: adding MIME information to the database
This tutorial is for application authors and users who want to extend the database. For example, the Gimp may wish to add:
* image/png can be edited using the Gimp.
* image/png should be described in English as "Portable Network Graphics file".
* Files whose names end in .png should have the type image/png.
Users should normally use a graphical editor application, such as [WWW]MIME-Editor, to edit the database (although ideally no user-editing should be required at all). If you really want to do it manually, create a file called $XDG_DATA_HOME/mime/packages/Override.xml in the format described below.
(see the Base Directory Specification for information about the XDG_ variables)
When your application is installed, it should install a file with the application's name in $XDG_DATA_DIRS/mime/packages. For example, doing ./configure && make install with Gimp should create /usr/local/share/mime/packages/gimp.xml.
This provides a comment (in two languages), a rule to recognise PNG files by their contents, and a rule to recognise them by their names. You can provide information about several types in the single gimp.xml file. You do not need to provide any information which is also in the base package (in fact, all the information above is already present; this is just an example!).
You can also add extra elements, provided they are namespaced to avoid conflicts. For example:
This indicates that the named desktop entry file describes an application that can edit image/png files. Note that the above is just an example; the desktop entry specification does not currently define this element. See the MIME actions specification for more details.
Note also that information added to the database should be static ("gimp can edit PNG files"), not configuration ("gimp is the preferred editor for PNG files"). See the shared configuration system for storing configuration information.
Once you have installed the gimp.xml file, run the update-mime-database command to rebuild the output files. This program checks that the syntax of your file is correct and merges the information in it with that in the other XML files in the packages directory. It then puts the rules for recognising files into one set of files, and the information about each type into other files (eg $XDG_DATA_DIR/mime/image/png.xml), where other programs can access it easily.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
All content Copyright 2000 - 2008, Maysville Linux Users Group unless otherwise credited.
All Rights Reserved!
The opinions expressed by visitors to this web site are their own and not necessarily the opinions of the MLUG!