| 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] GNOME | Assignee: | 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
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.
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. 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 :) (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. (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... (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 (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. > ~ $ 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
Created attachment 158089 [details]
Output of "strace gnome-open test.txt.zip"
Here you go. I hope this is right :)
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.
(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/` (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! the run on .local/share/mime fixed the problem for me aswell :-) Phew, so no need to p.mask 0.40 :) Thanks Nirbheek and to all of you for the follow up. *** Bug 229181 has been marked as a duplicate of this bug. *** (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/ there is nothing we can do for files in /usr/local, they are under your responsability. (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." (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. *** Bug 229339 has been marked as a duplicate of this bug. *** (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. *** Bug 229675 has been marked as a duplicate of this bug. *** *** Bug 230856 has been marked as a duplicate of this bug. *** (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? Although this bug has been resolved, it should not be marked "invalid": the problem was real, as I can attest. (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. try: # update-desktop-database 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") That could be unrelated. Do you have gtk+ built with the jpeg USE flag? 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? (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 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. (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... (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 (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. (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 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 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. The ebuild patch looks good. ACK from me. Thanks (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? I have been confused by the elog. Please implement Martin's bug228885b.patch. Thank you. I have been confused by the elog message. Please implement Martin's patch. Please disregard the previous comment Thank you. 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. |
