On Fri, 2020-01-17 at 22:28 +0100, Andreas Müller wrote: > On fresh images file-browsers do not know how to open files and > usually open a > dialog with ALL applications available on the machine. This is not > what users > are used to when working with linux: For just one application > installed per > Mime-Type, the application is opened automatically. > > To get a working MIME on desktop it needs two 'databases' on target: > > 1. Mime-Types: This is handled by mime.bbclass and creates database > in > /usr/share/mime/mime.cache. > 2. Mime associations: A simple text-list of pairs Mime-Type <-> > application > in /usr/share/applications/mimeinfo.cache > > This patch series updates/implements/enhances both parts to get > images work as > expected. > > @Khem: This series creates many QA warnings for layers in meta- > openembedded and > a patch series fixing many was prepared [1]. Once this series get's > applied (or > you ask for it) I can send them out. > > [1] > https://github.com/schnitzeltony/meta-openembedded/tree/work-2020-01 > > V1 -> V2: > * Shelve global path export thingy > * Add me as maintainer of itstool (let's consider 'ü' in my name as > test case :) > * Change "to to" to "to" in commit message > * Build shared-mime-info from git to allow automated upgrades > * mime-xdg.bbclass: Be prepared for packages as libreoffice: Desktop > files > installed are absolut symlinks broken for us. In case other > projects do same: > Offer asolution and guide recipe writers how to handle by > generating warnings > with instructions how to handle.
Thanks, this looks good to me. It did generate a warning on master-next builds in many places: WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains desktop file with key 'MimeType' but does not inhert mime-xdg: libfm-gtk path '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-gtk/usr/share/applications/lxshortcut.desktop' [mime-xdg] WARNING: libfm-1.3.1-r0 do_package_qa: QA Issue: package contains mime types but does not inhert mime: libfm-mime path '/work/armv7vet2hf-neon-oe-linux-gnueabi/libfm/1.3.1-r0/packages-split/libfm-mime/usr/share/mime/packages/libfm.xml' [mime] It also generated: https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1458 which partly is the python2 removal that was in with the test and partly this series since itstool is GPLv3 :(. I have to admit I'm not sure how reasonable it is to keep hacking the gplv2 layer to work... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
