Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
On Tue, Jun 15, 2021 at 09:41:39PM +0300, Dmitry Shachnev wrote: > Following what Lisandro said, I will not upload the revert to unstable. > > Dennis, please contact the upstream Qt developers, and if they revert that > part of the patch or change the code to make your use case work, I will be > happy to backport those fixes to our package. Not necessary. In the meantime I figured out what the XDG people want you to do if you wish to associate an application with every MIME type: associate it with "application/octet-stream" (to which every other MIME type is implicitly subclassed) and "application/x-zerosize". Looking at it from very far away it even makes sense somewhat. So, for all I know this can be closed. Regards, Dennis.
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Hi all, On Mon, Jun 14, 2021 at 09:41:13AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Now I understand your use case, but it really sounds more like a hack > than the proper way of doing things. > > In my point of view you should reach KDE devs, explain them why you > need this functionality and convince them to support it. My guess is > that a flag in dolphin's config in order to get you all the options > would be just enough. Following what Lisandro said, I will not upload the revert to unstable. Dennis, please contact the upstream Qt developers, and if they revert that part of the patch or change the code to make your use case work, I will be happy to backport those fixes to our package. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Hi! On Sat, 12 Jun 2021 at 11:06, Dennis Filder wrote: > > On Sat, Jun 12, 2021 at 02:58:23PM +0300, Dmitry Shachnev wrote: > > > Just like Lisandro, I have never tried that. > > BTW: My original intention was to use this to edit extended attributes > on files and directories from within Dolphin. > > > Please test the attached .deb file. I did not change the version number, > > to make it possible to install only libqt5core5a and not the whole qtbase > > stack. > > Thanks. That indeed brings the behaviour close enough to how it was > before that I would consider it a fix for this bug. Since the > remaining patch still changes the MIME type decision logic the > behaviour is still somewhat different though. However, it becomes > difficult for me to tell how different because remembering the exact > details of the previous (5.15.2+dfsg-5) behaviour is not easy as it > never quite worked consistently either. > > For example now with the glob pattern "*.*" added to "all/allfiles" a > C source code file "test.c" in Dolphin's list view is listed as being > of type "all files" and also all operations defined for "all/allfiles" > are listed in the context menu, but after selecting "Properties" in > Dolphin's context menu its "Contents" field shows "C source code" > (presumably because Dolphin uses magic-based fingerprinting). All > this despite the file /usr/share/mime/text/x-csrc.xml defining the > MIME type "text/x-csrc" with the glob pattern "*.c". I think it has > to do with how user-defined MIME type definitions from > ~/.local/share/mime are merged into the set of system-defined ones. > Since KDE System Settings does not allow you to specify a weight value > for your glob patterns (and most under /usr/share/mime/* don't specify > it either) the merging does not actually always yield sensible results > as almost all glob patterns end up having the default weight of 50. > And it also leads to behaviour that is difficult to reproduce across > setups. Now I understand your use case, but it really sounds more like a hack than the proper way of doing things. > I just wished the KDE devs would actually try a little harder to make > all this MIME type handling more consistent (and easier to > investigate) and to make the MIME types "all/all" and "all/allfiles" > behave as you would expect. But I guess that belongs in a separate > bug report. In my point of view you should reach KDE devs, explain them why you need this functionality and convince them to support it. My guess is that a flag in dolphin's config in order to get you all the options would be just enough.
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
On Sat, Jun 12, 2021 at 04:01:55PM +0200, Dennis Filder wrote: > > Please test the attached .deb file. I did not change the version number, > > to make it possible to install only libqt5core5a and not the whole qtbase > > stack. > > Thanks. That indeed brings the behaviour close enough to how it was > before that I would consider it a fix for this bug. Since the > remaining patch still changes the MIME type decision logic the > behaviour is still somewhat different though. However, it becomes > difficult for me to tell how different because remembering the exact > details of the previous (5.15.2+dfsg-5) behaviour is not easy as it > never quite worked consistently either. Thank you for testing! As it is better than the -6 and -7 versions in archive, I am going to upload this fix to unstable and ask the release team for an unblock. Lisandro, do you agree with that plan? > For example now with the glob pattern "*.*" added to "all/allfiles" a > C source code file "test.c" in Dolphin's list view is listed as being > of type "all files" and also all operations defined for "all/allfiles" > are listed in the context menu, but after selecting "Properties" in > Dolphin's context menu its "Contents" field shows "C source code" > (presumably because Dolphin uses magic-based fingerprinting). All > this despite the file /usr/share/mime/text/x-csrc.xml defining the > MIME type "text/x-csrc" with the glob pattern "*.c". I think it has > to do with how user-defined MIME type definitions from > ~/.local/share/mime are merged into the set of system-defined ones. > Since KDE System Settings does not allow you to specify a weight value > for your glob patterns (and most under /usr/share/mime/* don't specify > it either) the merging does not actually always yield sensible results > as almost all glob patterns end up having the default weight of 50. > And it also leads to behaviour that is difficult to reproduce across > setups. > > I just wished the KDE devs would actually try a little harder to make > all this MIME type handling more consistent (and easier to > investigate) and to make the MIME types "all/all" and "all/allfiles" > behave as you would expect. But I guess that belongs in a separate > bug report. Thanks for the very detailed explanation, but it will be much better if you send all these details to upstream Qt or KDE bugtrackers (and also mention the regression caused by the patch). We are just packagers, and I am really not an expert in mimetypes and the relevant code. If you do it, please let me know the bug URL, I will keep an eye on it and backport any fixes when/if they become available. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
On Sat, Jun 12, 2021 at 02:58:23PM +0300, Dmitry Shachnev wrote: > Just like Lisandro, I have never tried that. BTW: My original intention was to use this to edit extended attributes on files and directories from within Dolphin. > Please test the attached .deb file. I did not change the version number, > to make it possible to install only libqt5core5a and not the whole qtbase > stack. Thanks. That indeed brings the behaviour close enough to how it was before that I would consider it a fix for this bug. Since the remaining patch still changes the MIME type decision logic the behaviour is still somewhat different though. However, it becomes difficult for me to tell how different because remembering the exact details of the previous (5.15.2+dfsg-5) behaviour is not easy as it never quite worked consistently either. For example now with the glob pattern "*.*" added to "all/allfiles" a C source code file "test.c" in Dolphin's list view is listed as being of type "all files" and also all operations defined for "all/allfiles" are listed in the context menu, but after selecting "Properties" in Dolphin's context menu its "Contents" field shows "C source code" (presumably because Dolphin uses magic-based fingerprinting). All this despite the file /usr/share/mime/text/x-csrc.xml defining the MIME type "text/x-csrc" with the glob pattern "*.c". I think it has to do with how user-defined MIME type definitions from ~/.local/share/mime are merged into the set of system-defined ones. Since KDE System Settings does not allow you to specify a weight value for your glob patterns (and most under /usr/share/mime/* don't specify it either) the merging does not actually always yield sensible results as almost all glob patterns end up having the default weight of 50. And it also leads to behaviour that is difficult to reproduce across setups. I just wished the KDE devs would actually try a little harder to make all this MIME type handling more consistent (and easier to investigate) and to make the MIME types "all/all" and "all/allfiles" behave as you would expect. But I guess that belongs in a separate bug report. Regards, Dennis.
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Hi! On Fri, 11 Jun 2021 at 15:42, Dennis Filder wrote: > > On Fri, Jun 11, 2021 at 02:12:45PM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > > According to the patch: > > > > This change also optimizes QMimeBinaryProvider::addFileNameMatches > > to have the same logic as xdgmime for glob matching: > > literals > extensions > other globs > > > > How does xdgmime behaves in your specific case? If xdgmime behaves > > differently then we definitely can call this a bug, but if the > > behavior is the same then not. > > xdg-mime calls /usr/bin/ktraderclient5 under the hood which relies on > the same libraries as dolphin. Consequently it shows me exactly what > I see in Dolphin. I learned something new today :-) > Dmitry Shachnev wrote: > > > Dennis, is there any chance you can build qtbase with that part of the patch > > removed? Or maybe you can test a *.deb file I share with you? > > .deb file sounds good. But also: Have you never tried to enable an > application for all file types? Because that always struck as a very > useful feature, and I am a bit puzzled that apparently only few people > actually use it. Never, in fact I still can't imagine why would I do that. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
On Fri, Jun 11, 2021 at 02:12:45PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > According to the patch: > > This change also optimizes QMimeBinaryProvider::addFileNameMatches > to have the same logic as xdgmime for glob matching: > literals > extensions > other globs > > How does xdgmime behaves in your specific case? If xdgmime behaves > differently then we definitely can call this a bug, but if the > behavior is the same then not. xdg-mime calls /usr/bin/ktraderclient5 under the hood which relies on the same libraries as dolphin. Consequently it shows me exactly what I see in Dolphin. Dmitry Shachnev wrote: > Dennis, is there any chance you can build qtbase with that part of the patch > removed? Or maybe you can test a *.deb file I share with you? .deb file sounds good. But also: Have you never tried to enable an application for all file types? Because that always struck as a very useful feature, and I am a bit puzzled that apparently only few people actually use it. Regards, Dennis.
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Hi all, On Fri, Jun 11, 2021 at 02:12:45PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > This really sounds like a use case that was possible due to the bug, > and the fix broke that path. According to the patch: > > This change also optimizes QMimeBinaryProvider::addFileNameMatches > to have the same logic as xdgmime for glob matching: > literals > extensions > other globs Actually the patch I cherry-picked contains two parts that are not directly related to each other. If this bug is caused by the change to src/corelib/mimetypes/qmimeprovider.cpp then I think we should just remove that file from the patch. That change is not related to the main bug [1][2] that I was trying to get fixed. Dennis, is there any chance you can build qtbase with that part of the patch removed? Or maybe you can test a *.deb file I share with you? [1]: https://launchpad.net/bugs/1857824 [2]: https://bugs.kde.org/show_bug.cgi?id=411718 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Hi! Typo from my side. On Fri, 11 Jun 2021 at 14:12, Lisandro Damián Nicanor Pérez Meyer wrote: [snip] > How does xdgmime behaves in your specific case? If xdgmime behaves > differently then we definitely can call this a bug, but if the > behavior is the same then not. That would be xdg-mime. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Control: tag -1 moreinfo Hi! On Fri, 11 Jun 2021 at 13:33, Dennis Filder wrote: > > Package: libqt5core5a > Version: 5.15.2+dfsg-7 > Severity: normal > X-Debbugs-CC: Dennis Filder > > Dear Maintainer, > > yesterday evening I upgraded the binary packages for > src:qtbase-opensource-src from 5.15.2+dfsg-5 to 5.15.2+dfsg-7. After > today's boot I noticed that all the file type associations in Dolphin > are broken. All files only have the associations for the type > "all/allfiles" and directories those for type "all/all" rendering > Dolphin effectively unusable. > > On a hunch I removed the glob patterns "*.*", "*.a*", and "*.j*" > (which I had added years ago since it was the only way to add > operations to all file types without adding a million MIME types > explicitly to the corresponding .desktop files) from the type > "all/allfiles" in System Settings -> Applications -> File Associations > and hit "Apply" while leaving "*" (which for some reason never worked > on its own) untouched. Restarting Dolphin then restored the normal > behaviour (but without my operations for all file types, of course). > > The changelog tells me that d/patches/mime_globs.diff was added > recently to fix something regarding the MIME type determination logic, > so that's probably the cause. > > I cannot tell whether this is a bug in QMimeType provided by > qtbase-opensource-src or in a different component elsewhere that > merely uses QMimeType to find lists of applications association > definitions, but now broke due to changes in its behaviour. > > The thing is: Wanting to associate certain applications to all file > types is a perfectly legitimate use-case, and it used to work. The > Shared MIME-info Database specification mentions the concept of > subclassing (§ 2.11. Subclassing), and it should allow for exactly > this. MIME types in a subclassing relationship should have their > application association definitions collected additively for the user > to choose from, and one association should not be able to just > overshadow all others. > > The spec does not mention the MIME types "all/all" and "all/allfiles", > but Qt clearly defines them for the purpose of subclassing, and > already contains implicit subclassing logic for them. The Qt > developers need to decide if they want to continue to offer this > feature by either fixing what broke or removing the MIME types > "all/all" and "all/allfiles" on account of being both > ineffective/superfluous and non-standard. > > N.B.: In my search for a workaround I found out that unfortunately it > is not possible to associate an application with a wildcard MIME type > by adding e.g. "MimeType=video/*;" to a .desktop under > ~/.local/share/applications/. This really sounds like a use case that was possible due to the bug, and the fix broke that path. According to the patch: This change also optimizes QMimeBinaryProvider::addFileNameMatches to have the same logic as xdgmime for glob matching: literals > extensions > other globs How does xdgmime behaves in your specific case? If xdgmime behaves differently then we definitely can call this a bug, but if the behavior is the same then not. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Package: libqt5core5a Version: 5.15.2+dfsg-7 Severity: normal X-Debbugs-CC: Dennis Filder Dear Maintainer, yesterday evening I upgraded the binary packages for src:qtbase-opensource-src from 5.15.2+dfsg-5 to 5.15.2+dfsg-7. After today's boot I noticed that all the file type associations in Dolphin are broken. All files only have the associations for the type "all/allfiles" and directories those for type "all/all" rendering Dolphin effectively unusable. On a hunch I removed the glob patterns "*.*", "*.a*", and "*.j*" (which I had added years ago since it was the only way to add operations to all file types without adding a million MIME types explicitly to the corresponding .desktop files) from the type "all/allfiles" in System Settings -> Applications -> File Associations and hit "Apply" while leaving "*" (which for some reason never worked on its own) untouched. Restarting Dolphin then restored the normal behaviour (but without my operations for all file types, of course). The changelog tells me that d/patches/mime_globs.diff was added recently to fix something regarding the MIME type determination logic, so that's probably the cause. I cannot tell whether this is a bug in QMimeType provided by qtbase-opensource-src or in a different component elsewhere that merely uses QMimeType to find lists of applications association definitions, but now broke due to changes in its behaviour. The thing is: Wanting to associate certain applications to all file types is a perfectly legitimate use-case, and it used to work. The Shared MIME-info Database specification mentions the concept of subclassing (§ 2.11. Subclassing), and it should allow for exactly this. MIME types in a subclassing relationship should have their application association definitions collected additively for the user to choose from, and one association should not be able to just overshadow all others. The spec does not mention the MIME types "all/all" and "all/allfiles", but Qt clearly defines them for the purpose of subclassing, and already contains implicit subclassing logic for them. The Qt developers need to decide if they want to continue to offer this feature by either fixing what broke or removing the MIME types "all/all" and "all/allfiles" on account of being both ineffective/superfluous and non-standard. N.B.: In my search for a workaround I found out that unfortunately it is not possible to associate an application with a wildcard MIME type by adding e.g. "MimeType=video/*;" to a .desktop under ~/.local/share/applications/. Regards, Dennis Filder. -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages libqt5core5a depends on: ii libc6 2.31-12 ii libdouble-conversion3 3.1.5-6.1 ii libgcc-s1 10.2.1-6 ii libglib2.0-0 2.66.8-1 ii libicu67 67.1-6 ii libpcre2-16-0 10.36-2 ii libstdc++6 10.2.1-6 ii libzstd1 1.4.8+dfsg-2.1 ii shared-mime-info 2.0-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages libqt5core5a recommends: pn qttranslations5-l10n Versions of packages libqt5core5a suggests: ii libthai0 0.1.28-3 -- no debconf information
