Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 228885

Summary: x11-misc/shared-mime-info-0.40 breaks mime type recognition in gnome-base/nautilus-2.22.3
Product: Gentoo Linux Reporter: Martin Wegner <gentoo-bugs>
Component: [OLD] GNOMEAssignee: Gentoo Linux Gnome Desktop Team <gnome>
Status: RESOLVED INVALID    
Severity: normal CC: hans, jlec, Martin.vGagern, pierre.poissinger, rose, skrot, tetromino, z23
Priority: High Keywords: Inclusion
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Test zip file which this bug occurs with
Output of "strace gnome-open test.txt.zip"
Requested gnome-open.strace.log
Have update-mime-tool check mime_dir exists
Have ebuild check existence of /usr/local/share/mime

Description Martin Wegner 2008-06-22 12:11:32 UTC
After installing x11-misc/shared-mime-info-0.40 and restarting nautilus nautilus recognizes many binary files as text files (mime type text/plain). I found zhis for .mp4's, .mp3's, .ogg's, .zip's, .rar's . On the other side .avi's, .jpg's seem to work.

Forced downgrade to x11-misc/shared-mime-info-0.30 temporarily solves this as workaround.

Reproducible: Always

Steps to Reproduce:
1. paludis -i1 =x11-misc/shared-mime-info-0.40
2. killall nautilus

Actual Results:  
Mime type and therefore appliciations linked to those files do not work.

Expected Results:  
Mime type recognition should work so that those files can be started directly with the correct application.

$ emerge --info
Portage 2.2_rc1 (default-linux/amd64/2007.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.25-gentoo-r5-mw x86_64)
=================================================================
System uname: Linux-2.6.25-gentoo-r5-mw-x86_64-Intel-R-_Core-TM-2_CPU_6400_@_2.13GHz-with-glibc2.2.5
Timestamp of tree: Sun, 22 Jun 2008 11:15:01 +0000
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
app-shells/bash:     3.2_p39
dev-java/java-config: 1.3.7, 2.1.6
dev-lang/python:     2.4.4-r6, 2.5.2-r4
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 2.0.0
sys-apps/openrc:     0.2.5
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.62
sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   2.2.4
virtual/os-headers:  2.6.25-r4
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="C"
LDFLAGS=""
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl amd64 berkdb cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi mmx mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x     ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3       trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis       sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Comment 1 Martin Wegner 2008-06-22 12:12:49 UTC
Created attachment 157995 [details]
Test zip file which this bug occurs with

After the upgrade this attached test zip file is recognized as mime type text/plain.
Comment 2 Hans Nieser 2008-06-23 03:26:06 UTC
I seem to be having the same issue after updating my system recently, except it isn't detecting the proper mime-type for *any* file, everything is shown as plain/text (except for links and directories). This has the side effect of not being able to open files with the appropriate application from Nautilus which is a big hindrance.
Comment 3 Rémi Cardona (RETIRED) gentoo-dev 2008-06-23 08:29:12 UTC
For the record, I've updated my ~amd64 system to 0.40 and everything works, including the attached zip file.

If it were only up to me, I'd close this WORKSFORME but this is just weird, shared-mime-data only installs data files and a database handling tool.

Maybe your database is broken/corrupted? Could both of you update to 0.40 and run the following command : update-mime-database /usr/share/mime

Again, don't forget to restart nautilus afterwards :)
Comment 4 Tijmen van Hoeckel 2008-06-23 08:53:58 UTC
(In reply to comment #3)
> For the record, I've updated my ~amd64 system to 0.40 and everything works,
> including the attached zip file.
> 
> If it were only up to me, I'd close this WORKSFORME but this is just weird,
> shared-mime-data only installs data files and a database handling tool.
> 
> Maybe your database is broken/corrupted? Could both of you update to 0.40 and
> run the following command : update-mime-database /usr/share/mime
> 
> Again, don't forget to restart nautilus afterwards :)
> 

I'm experiencing the same trouble as mentioned above with 0.40 on ~x86. I followed your instruction but that didn't fix the problem for me. 
After I downgraded to shared-mime-info-0.30 and restarted nautilus, everything wa back to normal.
Comment 5 Pierre Poissinger 2008-06-23 09:00:09 UTC
(In reply to comment #3)
> If it were only up to me, I'd close this WORKSFORME but this is just weird,
> shared-mime-data only installs data files and a database handling tool.
Then if Gentoo was up to you, I won't use it ;-p

> Maybe your database is broken/corrupted? Could both of you update to 0.40 and
> run the following command : update-mime-database /usr/share/mime
> Again, don't forget to restart nautilus afterwards :)
Done that, didn't help...

Btw, 0.30 working fine...

Comment 6 Rémi Cardona (RETIRED) gentoo-dev 2008-06-23 09:09:02 UTC
(In reply to comment #5)
> Then if Gentoo was up to you, I won't use it ;-p
Fair enough ;)

> Done that, didn't help...

Dammit...

> Btw, 0.30 working fine...

Alright, let's try something else. Could the both of you go again to 0.40 and try to open one of the zip files with "gnome-open"?

If that fails, I'll mask 0.40 while you help us figuring out. We really are going to need you guys' help because debugging something we can't reproduce is going to be very tricky.

Thanks
gnome-open
Comment 7 Dijon Page 2008-06-23 09:35:26 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Then if Gentoo was up to you, I won't use it ;-p
> Fair enough ;)
> 
> > Done that, didn't help...
> 
> Dammit...
> 
> > Btw, 0.30 working fine...
> 
> Alright, let's try something else. Could the both of you go again to 0.40 and
> try to open one of the zip files with "gnome-open"?
> 
> If that fails, I'll mask 0.40 while you help us figuring out. We really are
> going to need you guys' help because debugging something we can't reproduce is
> going to be very tricky.
> 
> Thanks
> gnome-open
> 

Same problem here. This is the output from using gnome-open on that test zip file:

~ $ gnome-open test.txt.zip 
Error showing url: There is no default action associated with this location.


The same thing shows for other file types that nautilus seems to have forgotten about.
Comment 8 Rémi Cardona (RETIRED) gentoo-dev 2008-06-23 09:42:07 UTC
> ~ $ gnome-open test.txt.zip 
> Error showing url: There is no default action associated with this location.
> 
> The same thing shows for other file types that nautilus seems to have forgotten
> about.

Great :) we're narrowing things down.

Could you run : "strace gnome-open test.txt.zip &> gnome-open.strace.log" and attach the log file here?

Thanks
Comment 9 Dijon Page 2008-06-23 09:47:52 UTC
Created attachment 158089 [details]
Output of "strace gnome-open test.txt.zip"

Here you go. I hope this is right :)
Comment 10 Martin Wegner 2008-06-23 09:52:19 UTC
Created attachment 158091 [details]
Requested gnome-open.strace.log

Updating mime database didn't work here, too, and gnome-open showed the same error.

So here is the requested strace of gnome-open.
Comment 11 Nirbheek Chauhan (RETIRED) gentoo-dev 2008-06-23 10:36:05 UTC
(In reply to comment #10)
> Updating mime database didn't work here, too, and gnome-open showed the same
> error.
> 
> So here is the requested strace of gnome-open.
> 

I've got a hunch (from the strace) that the old shared-mime db in ~/.local/share/mime is overriding the system one.

Try running `update-mime-database ~/.local/share/mime/`
Comment 12 Dijon Page 2008-06-23 10:41:57 UTC
(In reply to comment #11)
> I've got a hunch (from the strace) that the old shared-mime db in
> ~/.local/share/mime is overriding the system one.
> 
> Try running `update-mime-database ~/.local/share/mime/`

Hey that seems to have worked for me. Although nautilus wanted to open text files with totem, I've removed Totem from the 'open with' bit for text files and added gedit and everything looks good now.

Cheers!
Comment 13 Pierre Poissinger 2008-06-23 10:50:16 UTC
the run on .local/share/mime fixed the problem for me aswell :-)
Comment 14 Rémi Cardona (RETIRED) gentoo-dev 2008-06-23 10:55:50 UTC
Phew, so no need to p.mask 0.40 :)

Thanks Nirbheek and to all of you for the follow up.
Comment 15 Rémi Cardona (RETIRED) gentoo-dev 2008-06-24 07:34:43 UTC
*** Bug 229181 has been marked as a duplicate of this bug. ***
Comment 16 Alexandre Rostovtsev (RETIRED) gentoo-dev 2008-06-24 08:09:58 UTC
(In reply to comment #11)
> I've got a hunch (from the strace) that the old shared-mime db in
> ~/.local/share/mime is overriding the system one.
> 
> Try running `update-mime-database ~/.local/share/mime/`
> 

Good advice. But on my system, to get nautilus working, I had to also run (as root)

# update-mime-database /usr/local/share/mime/
Comment 17 Gilles Dartiguelongue (RETIRED) gentoo-dev 2008-06-24 08:21:08 UTC
there is nothing we can do for files in /usr/local, they are under your responsability.
Comment 18 Alexandre Rostovtsev (RETIRED) gentoo-dev 2008-06-24 08:47:18 UTC
(In reply to comment #17)
> there is nothing we can do for files in /usr/local, they are under your
> responsability.

Nevertheless, it is extremely unexpected for a minor version update of a package that doesn't install any libraries to break all of Gnome. You expect a soname update to break things. You do not expect an updated xml file to break your whole desktop...

Maybe you should add an ewarn to the ebuild, something like

"You MUST manually rebuild all mime database files that were generated with older versions of shared-mime-info, or Gnome will stop working. To search for mime database files, do
# locate mime.cache
To update the mime databases, for example, run (as normal user)
$ update-mime-database ~/.local/share/mime/
and (as root)
# update-mime-database /usr/local/share/mime/
to update the databases in the respective directories."
Comment 19 Gilles Dartiguelongue (RETIRED) gentoo-dev 2008-06-24 12:44:35 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > there is nothing we can do for files in /usr/local, they are under your
> > responsability.
> 
> Nevertheless, it is extremely unexpected for a minor version update of a
> package that doesn't install any libraries to break all of Gnome. You expect a
> soname update to break things. You do not expect an updated xml file to break
> your whole desktop...

This assumption has been proven wrong quite often since I started using linux, so... Anyway, the problem is not with the xml itself but with the cache format it seems. Adding an ewarn is a good idea though for the moment.
Comment 20 Rémi Cardona (RETIRED) gentoo-dev 2008-06-25 07:14:48 UTC
*** Bug 229339 has been marked as a duplicate of this bug. ***
Comment 21 Rémi Cardona (RETIRED) gentoo-dev 2008-06-25 10:18:51 UTC
(In reply to comment #19)
> Adding an ewarn is a good idea though for the moment.

Done in 0.40 without revbump. Should be enough for now.
Comment 22 Gilles Dartiguelongue (RETIRED) gentoo-dev 2008-06-27 08:22:02 UTC
*** Bug 229675 has been marked as a duplicate of this bug. ***
Comment 23 Rémi Cardona (RETIRED) gentoo-dev 2008-07-05 15:08:51 UTC
*** Bug 230856 has been marked as a duplicate of this bug. ***
Comment 24 Vladimir G. Ivanovic 2008-07-07 20:47:41 UTC
(In reply to comment #21)
> (In reply to comment #19)
> > Adding an ewarn is a good idea though for the moment.
> 
> Done in 0.40 without revbump. Should be enough for now.
> 

Since emerge is run as root, why not update the system mime cache automatically?
Comment 25 Vladimir G. Ivanovic 2008-07-07 20:50:26 UTC
Although this bug has been resolved, it should not be marked "invalid": the problem was real, as I can attest.
Comment 26 Rémi Cardona (RETIRED) gentoo-dev 2008-07-08 07:11:06 UTC
(In reply to comment #24)
> Since emerge is run as root, why not update the system mime cache
> automatically?

The system mime *is* updated by portage. All issues come from 2 places :
 - /usr/local which the box administrator is supposed to handle
 - ~/.local which portage is *never* allowed to touch

The best we can do is to warn users. We'll of course try to make sure nautilus and other tools provide upgrade paths next time around.
Comment 27 Matthew Joiner 2008-07-12 10:36:00 UTC
try:
# update-desktop-database
Comment 28 Skion 2008-07-14 18:58:47 UTC
Would there be any reason that the described fixes wouldn't work for gthumb as described in bug #229027? The update caches made my nautilus work again, but gthumb is still failing to detect correct mime types.

This is showing in two ways:
- no jpg images in the gthumb image listings (other types do work though)
- unable to save images when 'Determine by extension' is selected in the save dialog. (Message is: "Image type not supported: application/x-extension-jpg")
Comment 29 Daniel Gryniewicz (RETIRED) gentoo-dev 2008-07-17 18:24:10 UTC
That could be unrelated.  Do you have gtk+ built with the jpeg USE flag?
Comment 30 Justin Lecher (RETIRED) gentoo-dev 2009-02-08 08:13:04 UTC
elog says in postinst:
elog "(as root)       # update-mime-database /usr/local/share/mime/"

Is that the right path? Or should it be /usr/share/mime?
Comment 31 Rémi Cardona (RETIRED) gentoo-dev 2009-02-08 17:56:01 UTC
(In reply to comment #30)
> elog says in postinst:
> elog "(as root)       # update-mime-database /usr/local/share/mime/"
> 
> Is that the right path? Or should it be /usr/share/mime?

It is the right path because the ebuild already takes care of /usr/share/mime. In fact, the elog message points out to potential dirs that it will never ever update because the user/admin is supposed to know what goes on in there.

Thanks
Comment 32 Jarryd Beck 2009-03-05 22:36:52 UTC
For me the steps given didn't work, particularly because I don't have a ~/.local/share/mime. However after running
sudo update-desktop-database
everything seemed to work again.
Comment 33 Martin von Gagern 2009-03-08 15:55:00 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > elog "(as root)       # update-mime-database /usr/local/share/mime/"
> > Is that the right path? Or should it be /usr/share/mime?
> It is the right path because the ebuild already takes care of /usr/share/mime.

It is very irritating that when I follow this advice, I get the message

  update-mime-database: I don't have write permission on /usr/local/share/mime.
  Try rerunning me as root.

Cause is that the directory doesn't even exist, but the error gives little indication to that effect. I would suggest that you print the elog conditionally, only after checking that such a directory actually does exist. Or you could do an existence check before the write check in update-mime-database.c, and issue a different message if a directory does not exist. Adding an elog line like "If these directories don't exist on your system, there is no need for action" or similar might help as well. Of course, you can also implement a combination of my suggestions...
Comment 34 Rémi Cardona (RETIRED) gentoo-dev 2009-03-08 16:08:56 UTC
(In reply to comment #33)
>   update-mime-database: I don't have write permission on /usr/local/share/mime.
>   Try rerunning me as root.

That is a problem with the utility.

Emerge cannot and will not check what goes on in /usr/local because sandbox will kick and scream if we do.

If you use /usr/local, then you should know what you're doing. It's outside the scope of portage. Just like /home/*

Thanks
Comment 35 Martin von Gagern 2009-03-08 21:56:43 UTC
(In reply to comment #34)
> That is a problem with the utility.

Do you want a patch for this, adding an additional check and a more accurate error message?

> Emerge cannot and will not check what goes on in /usr/local because sandbox
> will kick and scream if we do.

I know sandbox will forbid any and all WRITE access, but it's my understanding that reading is all right. At least on my system, the default configuration in /etc/sandbox.d/00default lists SANDBOX_READ="/", with no special handling for /usr/local. An appropriately adjusted ebuild merged all right.

> If you use /usr/local, then you should know what you're doing. It's outside
> the scope of portage. Just like /home/*

If you don't use it, you should not get instructions leading to obscure error messages, and have to worry about it more than absolutely necessary. My whole point is about those people NOT using it being confused by the elog message.
Comment 36 Rémi Cardona (RETIRED) gentoo-dev 2009-03-08 22:07:01 UTC
(In reply to comment #35)
> Do you want a patch for this, adding an additional check and a more accurate
> error message?

Sure, but please do send it to upstream too.

> An appropriately adjusted ebuild merged all right.

If you have a patch for that, we'll take it in.

> If you don't use it, you should not get instructions leading to obscure error
> messages, and have to worry about it more than absolutely necessary. My whole
> point is about those people NOT using it being confused by the elog message.

The point of the elog message was to reduce the number of duplicate bug reports due to this terrible database format change. On the whole, it's been positive. That's why we've kept it that way.

Thanks
Comment 37 Martin von Gagern 2009-03-09 07:48:22 UTC
Created attachment 184411 [details, diff]
Have update-mime-tool check mime_dir exists

(In reply to comment #36)
> Sure, but please do send it to upstream too.

Here it is, also posted as http://bugs.freedesktop.org/20552
Comment 38 Martin von Gagern 2009-03-09 07:49:46 UTC
Created attachment 184413 [details, diff]
Have ebuild check existence of /usr/local/share/mime

(In reply to comment #36)
> > An appropriately adjusted ebuild merged all right.
> If you have a patch for that, we'll take it in.

Here you are.
Comment 39 Rémi Cardona (RETIRED) gentoo-dev 2009-03-09 07:53:16 UTC
The ebuild patch looks good. ACK from me.

Thanks
Comment 40 Martin von Gagern 2009-04-20 17:26:44 UTC
(In reply to comment #37)
> Have update-mime-tool check mime_dir exists
> Here it is, also posted as http://bugs.freedesktop.org/20552

Got included upstream.

(In reply to comment #39)
> The ebuild patch looks good. ACK from me.

Can we get that included then?
Comment 41 Jorge Peixoto de Morais Neto 2009-10-22 06:35:43 UTC
I have been confused by the elog. Please implement Martin's bug228885b.patch.
Thank you.
Comment 42 Jorge Peixoto de Morais Neto 2009-10-22 06:43:51 UTC
I have been confused by the elog message. Please implement Martin's patch.
Please disregard the previous comment
Thank you.
Comment 43 Martin von Gagern 2010-03-15 08:30:36 UTC
As comments 39 and 42 indicate approval of my ebuild improvement, and it still hasn't been included, I assume that's because this bug report here has been marked invalid. I just created bug #309461 to deal with the single issue of improving the ebuild.