Hi, I found that a gzip compressed file (not a tar.gz one) is not seen as an archive in pcmanfm because the list of MIME types handled by xarchiver in libfm contains application/x-gzip but, in Mageia 5, the MIME type used for gzip compressed files is application/gzip. Best regards, Nico.
Suggested advisory: ======================== The updated packages allow the extraction of a gzip compressed file (other than a tar.gz one, for which there was already no problem) using the context menu (right-click) of pcmanfm. ======================== Updated package in core/updates_testing: ======================== libfm-1.2.3-4.7.mga5 lib(64)fm4-1.2.3-4.7.mga5 lib(64)fm-devel-1.2.3-4.7.mga5 lxshortcut-1.2.3-4.7.mga5 from SRPMS: libfm-1.2.3-4.7.mga5.src.rpm
Status: NEW => ASSIGNEDAssignee: bugsquad => qa-bugsSource RPM: (none) => libfm-1.2.3-4.6.mga5.src.rpm
CC: (none) => davidwhodginsWhiteboard: (none) => advisory
$ potrace --help potrace 1.14. Transforms bitmaps into vector graphics. $ potrace bitmap.bmp [brian@localhost Documents]$ ls -ltr total 2544 -rw-rw-r-- 1 brian brian 8885 Mar 4 20:46 bitmap.bmp.odg -rw-rw-r-- 1 brian brian 2585142 Mar 4 20:47 bitmap.bmp -rw-r--r-- 1 brian brian 2525 Mar 4 20:49 bitmap.eps eps file was crated. I verified it in fact converted the bmp to a vector graphic.
CC: (none) => brtians1Whiteboard: advisory => advisory mga5-32-ok
(In reply to Brian Rockwell from comment #2) > $ potrace --help > potrace 1.14. Transforms bitmaps into vector graphics. > > > $ potrace bitmap.bmp > [brian@localhost Documents]$ ls -ltr > total 2544 > -rw-rw-r-- 1 brian brian 8885 Mar 4 20:46 bitmap.bmp.odg > -rw-rw-r-- 1 brian brian 2585142 Mar 4 20:47 bitmap.bmp > -rw-r--r-- 1 brian brian 2525 Mar 4 20:49 bitmap.eps > > > eps file was crated. > > > > I verified it in fact converted the bmp to a vector graphic. Wrong Link - if someone can delete these thanks
Whiteboard: advisory mga5-32-ok => advisory
Testing M5_64 using LXDE Sorry for leaving this so long, especially as it it so easy to test. Not sure. BEFORE the update, I gzipped a file which *already had a suffix* to tmp.pcap.gz , and PCMANFM did not recognise it as an archive; i.e. no archive program was offered in the right-click pop-up menu. I did not try a filename.gz file... Things like .tar.gz or .tar.bz2 were recognised as archives. libfm-1.2.3-4.7.mga5 lxshortcut-1.2.3-4.7.mga5 lib64fm4-1.2.3-4.7.mga5 AFTER the update, the test file tmp.pcap.gz was *still not* recognised as an archive. However, re-naming it to tmp_pcap.gz , it *was* recognised as an archive. So this update is only effective if the .gz suffix *has no previous suffix*. Back to Nicolas, please. Another point: this update is labelled 'enhancement'and is flagged as having an advisory uploaded. In fact when I last checked that, it was not there in SVN. I only know about 'security' & 'bugfix' for updates which require advisories. If 'enhancement' is valid, something might need changing in QA procedures. OTOH if enhancement is valid, does it need an advisory?
CC: (none) => lewyssmithWhiteboard: advisory => advisory feedback
Hi, That is strange: I tested with a file ".pcap.gz" and it was recognized as an archive. Did you log out and then log into LXDE again after the update? If you do not do that, the behaviour you described is normal because the file "/usr/share/libfm/archivers.list" seems to be read only when pcmanfm is launched. By the way, I also found that compressed GIMP images (".xcf.gz" or ".xcf.bz2") are not considered as archives so I modified my patch to also add image/x-compressed-xcf MIME type. Updated package in core/updates_testing: ======================== libfm-1.2.3-4.8.mga5 lib(64)fm4-1.2.3-4.8.mga5 lib(64)fm-devel-1.2.3-4.8.mga5 lxshortcut-1.2.3-4.8.mga5 from SRPMS: libfm-1.2.3-4.8.mga5.src.rpm
Severity: enhancement => minor
Regarding the fact that this update was flagged as enhancement, it was me that chose that severity (because it is very very minor) but I now put the severity to minor be allow that bug to appear as bugfix.
Testing M5x64 Updated again to: lib64fm4-1.2.3-4.8.mga5 libfm-1.2.3-4.8.mga5 lxshortcut-1.2.3-4.8.mga5 This certainly answers most of the corrections noted in comments 1 & 5. But exact right-click pop-up menu results are inconsistent when using PCmanFM under LXDE, after logout/login: 1a. tmp.pcap.gz Offers Wireshark, but *no* archive related option. 1b. tmp_pcap.gz Offers archive programs and 'extract' options. OK. 2. tmp.pcap.bz2 Offers archive programs and 'extract' options; but not Wireshark. OK. 3. falls.xcf.gz Offers Gimp & the 'extract' options, but no specific archive programs. OK. 4. falls.xcf.bz2 Offers Gimp & the 'extract' options, but no specific archive programs. OK. So what do you make of this, Nicolas?
I have understood the difference in behaviour between you and me: wireshark is not installed in my case. When wireshark is installed, the files ending with ".pcap" and ".pcap.gz" are linked to "Packet Capture" MIME type so it is not possible for PCmanFM to see ".pcap.gz" files as GZIP archives. Moreover, I cannot add "Packet Capture" MIME type to the list of MIME types that are considered as archives by PCmanFM because, in that case, ".pcap" files will also be considered as archives, which is clearly wrong. So I think the current situation, with "4.8.mga5" packages, is the best solution we can achieve.
(In reply to Nicolas Salguero from comment #8) > So I think the current situation, with "4.8.mga5" packages, is the best > solution we can achieve. In which case I shall OK this. But in the light of what follows, please undo that if you see another update possible. > When wireshark is installed, the files ending with ".pcap" and ".pcap.gz" > are linked to "Packet Capture" MIME type so it is not possible for PCmanFM > to see ".pcap.gz" files as GZIP archives. > Moreover, I cannot add "Packet Capture" MIME type to the list of MIME types > that are considered as archives by PCmanFM because, in that case, ".pcap" > files will also be considered as archives, which is clearly wrong. How is it that this works OK with .pcap files (offer Wireshark) and .pcap.bz2 files which offer Archive & Extract, but (correctly) not Wireshark? i.e. makes the proper decision for .bz2 . Are not these situations similar? For the Gimp archive file types .xcf.bz2|gz, I guess that it offers both Gimp & Extract because Gimp itself opens these compressed files directly. Guessing that Wireshark would not.
Whiteboard: advisory feedback => advisory feedback MGA5-64-OK
(In reply to Lewis Smith from comment #9) > How is it that this works OK with .pcap files (offer Wireshark) and > .pcap.bz2 files which offer Archive & Extract, but (correctly) not > Wireshark? i.e. makes the proper decision for .bz2 . Are not these > situations similar? Exactly: in the MIME type database ("/usr/share/mime/..."), ".pcap" and ".pcap.gz" are described as "Packet Capture" files, so the definition from ".gz" (GZIP archive) is not taken into account, whereas ".pcap.bz2" is not defined so the definition that applies is the one from ".bz2" i.e. BZIP2 archive. > For the Gimp archive file types .xcf.bz2|gz, I guess that it offers both > Gimp & Extract because Gimp itself opens these compressed files directly. > Guessing that Wireshark would not. Exactly again: because Gimp is able to directly open ".xcf.gz" and ".xcf.bz2" files, in the MIME type database, ".xcf.gz" and ".xcf.bz2" are both defined as "compressed GIMP images" (so the definition from ".gz" and ".bz2" are not taken into account); on the contrary, Wireshark can only directly open ".pcap.gz" (and not ".pcap.bz2") so it explains why the MIME type database is configured like I explained above in this comment.
Sorry to have left this so long, Nicolas. I knew it would be fiddly to investigate... Going back to Comment 7, example 1a was the only thing that did not look right: a file ending .gz not offering 'extract' option. I have tried to understand the difference between Gimp/xcf and Wireshark/pcap behaviour. Gimp, xcf ========= has two xml files, one for compressed, one for uncompressed. /usr/share/mime/image/x-compressed-xcf.xml ------------------------------------------ <mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="image/x-compressed-xcf"> ... <glob pattern="*.xcf.gz"/> <glob pattern="*.xcf.bz2"/> which results in 'offer Gimp *and* extraction'. Good. /usr/share/mime/image/x-xcf.xml ------------------------------- <mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="image/x-xcf"> ... <glob pattern="*.xcf"/> which yields 'offer Gimp'. Normal. pcap, Wireshark =============== has just one xml file covering both normal & compressed pcap files. Perhaps the result is due to this. /usr/share/mime/application/vnd.tcpdump.pcap.xml ------------------------------------------------ <mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/vnd.tcpdump.pcap"> ... <glob pattern="*.pcap"/> <glob pattern="*.cap"/> <glob pattern="*.dmp"/> <alias type="application/x-pcap"/> <alias type="application/pcap"/> ... <alias type="application/x-pcap"/> <alias type="application/pcap"/> <glob pattern="*.pcap"/> <glob pattern="*.pcap.gz"/> which yields 'offer just Wireshark' even for gz compressed files. If it would be easy to differentiate normal & gz compressed pcap files like for Gimp, that would be best. If it would be a pain (M5 has a short future), I will validate this update as-is. The principle is however generic: for any application which natively accepts certain compressed formats of its own file type, ideally such files should offer both the main application and 'extraction'.
(In reply to Lewis Smith from comment #11) > If it would be easy to differentiate normal & gz compressed pcap files like > for Gimp, that would be best. If it would be a pain (M5 has a short future), > I will validate this update as-is. The main problem is that the XML files from the MIME types database are mainly implementations of international standards so I do not think we can easily create our own MIME types without being non standard. > The principle is however generic: for any application which natively accepts > certain compressed formats of its own file type, ideally such files should > offer both the main application and 'extraction'. I totally agree with you on that point: such a behaviour is the most logical one from my point of view too.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Whiteboard: advisory feedback MGA5-64-OK => advisory MGA5-64-OK
Update ID assignment failed Checking for QA validation keyword⦠â Checking dependent bugs⦠â (None found) Checking SRPMs⦠â (5/core/libfm-1.2.3-4.7.mga5) 'validated_update' keyword reset.
Keywords: validated_update => (none)
In fact, it is libfm-1.2.3-4.8.mga5 (as I wrote in comment 5). Does the advisory need to be updated in the database?
Keywords: (none) => validated_updateCC: (none) => mageia
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGAA-2017-0017.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED
(In reply to Nicolas Salguero from comment #14) > In fact, it is libfm-1.2.3-4.8.mga5 (as I wrote in comment 5). Does the > advisory need to be updated in the database? The advisory now has libfm-1.2.3-4.8.mga5 . I do not know whether it was wrongly created (? by myself); or created earlier & not updated (plead guilty); or corrected since Comment 13. If the last, thanks to whoever did that & apologies for not doing it myself.