Bug 902024
Summary: | Review Request: gdk-pixbuf-psd - GdkPixbuf loader for the PSD file format | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mamoru TASAKA <mtasaka> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | kwizart, luya, package-review |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-08-12 01:37:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1000885 |
Description
Mamoru TASAKA
2013-01-20 14:04:22 UTC
> README The more recent file format documentation from Adobe seems to be more complex due to Photoshop >= 4.0: http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/ If some file format is not recognized, I will report it upstream. The primary reason why I've searched a bit about this is that PSD is (or used to be?) a proprietary and undocumented file format. I wanted to learn how much of this is "open", legal and not just reengineered. I'm not familiar with what's included in Adobe's SDKs (both old and new). Many closed SDKs only include binary objects with API documentation, but the existing file formats specification for 3rd parties means that something has been opened up here. See also: http://www.coolutils.com/Formats/PSD > If some file format is not recognized, I will report it upstream. With only having skimmed over the linked specs from Adobe, it is doubtful that the 15K C source file supports everything mentioned in Adobe's specs, in particular the long(er) list of image resources. > The loader supports: > - RGB and CYMK images Spec mentions: Bitmap = 0; Grayscale = 1; Indexed = 2; RGB = 3; CMYK = 4; Multichannel = 7; Duotone = 8; Lab = 9. > - RLE compression Spec mentions: 0 = Raw Data, 1 = RLE compressed, 2 = ZIP without prediction, 3 = ZIP with prediction > - 8 and 16 bit color depths Spec mentions: 1, 8, 16 and 32. (In reply to comment #3) > The primary reason why I've searched a bit about this is that PSD is (or > used to be?) a proprietary and undocumented file format. .. <snip> Fedora already has PSD supporting software (e.g. gimp) > > See also: http://www.coolutils.com/Formats/PSD > > > If some file format is not recognized, I will report it upstream. > > With only having skimmed over the linked specs from Adobe, it is doubtful > that the 15K C source file supports everything mentioned in Adobe's specs, > in particular the long(er) list of image resources. > > > The loader supports: > > - RGB and CYMK images > > Spec mentions: Bitmap = 0; Grayscale = 1; Indexed = 2; RGB = 3; CMYK = 4; > Multichannel = 7; Duotone = 8; Lab = 9. Actually this package supports 4 of them gimp supports 5 of them, not all > > - RLE compression > Spec mentions: 0 = Raw Data, 1 = RLE compressed, 2 = ZIP without prediction, > 3 = ZIP with prediction gimp does not support 2 and 3, either > > > - 8 and 16 bit color depths > Spec mentions: 1, 8, 16 and 32. gimp only support 1 and 8 (In reply to comment #4) > > > - RLE compression > > Spec mentions: 0 = Raw Data, 1 = RLE compressed, 2 = ZIP without prediction, > > 3 = ZIP with prediction > gimp does not support 2 and 3, either 0 is also support by this I don't think there is an remaining concern about either this can be considered as a free format according to the documentation provided by Adobe. I will follow with a full review soon. Package Review ============== Key: [x] = Pass [!] = Fail [-] = Not applicable [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== C/C++: [x]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package contains no bundled libraries. [x]: Changelog in prescribed format. [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Sources contain only permissible code or content. [x]: Each %files section contains %defattr if rpm < 4.4 [-]: Macros in Summary, %description expandable at SRPM build time. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: Package requires other packages for directories it uses. Requires(post): gdk-pixbuf2 is available for post install scriplet but could be removed then. The library dependencies requires the gdk-pixbuf2 that will owns the needed directories. [x]: Package uses nothing in %doc for runtime. [-]: Package is not known to require ExcludeArch. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package complies to the Packaging Guidelines [x]: Spec file lacks Packager, Vendor, PreReq tags. [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "LGPL (v2 or later) (with incorrect FSF address)", "Unknown or generated". 2 files have unknown license. Detailed output of licensecheck in /home/mockbuilder/902024-gdk-pixbuf-psd/licensecheck.txt [!]: Package consistently uses macro is (instead of hard-coded directory names). I would suggest to use this in order not to hardcode the version in the path for the files section: %global gdk_pixbuf_binarydir %(pkg-config gdk-pixbuf-2.0 --variable=gdk_pixbuf_binarydir) [x]: Package is named using only allowed ASCII characters. [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. Note: Package contains no Conflicts: tag(s) [x]: Package do not use a name that already exist [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: Package installs properly. [x]: Package is not relocatable. [x]: Requires correct, justified where necessary. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file is legible and written in American English. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [-]: Package contains systemd file(s) if in need. [x]: File names are valid UTF-8. [x]: Useful -debuginfo package or justification otherwise. [-]: Large documentation must go in a -doc subpackage. Note: Documentation size is 30720 bytes in 2 files. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Dist tag is present. [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Final provides and requires are sane (rpm -q --provides and rpm -q --requires). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: The placement of pkgconfig(.pc) files are correct. [x]: Scriptlets must be sane, if used. [x]: SourceX tarball generation or download is documented. [x]: SourceX / PatchY prefixed with %{name}. [x]: SourceX is a working URL. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [-]: Packages should try to preserve timestamps of original installed files. [x]: Spec use %global instead of %define. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Rpmlint ------- Checking: gdk-pixbuf-psd-debuginfo-0.1.0-1.fc17.x86_64.rpm gdk-pixbuf-psd-0.1.0-1.fc17.src.rpm gdk-pixbuf-psd-0.1.0-1.fc17.x86_64.rpm gdk-pixbuf-psd.src: W: spelling-error %description -l en_US gThumb -> g Thumb, thumb, humbug gdk-pixbuf-psd.x86_64: W: spelling-error %description -l en_US gThumb -> g Thumb, thumb, humbug 3 packages and 0 specfiles checked; 0 errors, 2 warnings. I will try to run a usability test later tonight. ping? Well, I'm not sure to understand how to test using gnome-nautilus If I open the directory using gimp, the thumbnail is generated and shown in nautilus. But if I move the .psd file into a new directory, there is no thumbnail ?! Well, I no longer use nautilus (actually I've removed nautilus rpm) so currently I cannot check it (for now). I tried pcmanfm and it seems to be working. By the way, would you clarify what is the left blocker currently? Your comment 9 means that I have to check if the issue you see is due to nautilus side or not? I Can reproduce the issue with gnome-nautilus or pcmanfm. Tested with 3 cases: - sample psd file taken from the internet - psd file exported from gimp - png file of the same picture Only the png file appears thumbnailed in both nautilus/pcmanfm. But if I browse the directory with psd using The gimp and create a thumbnail, then the picture appears in both nautilus/pcmanfm. Moving the files into another directory and using eog doesn't create the thumbnail either, gThumb is frozen at launch. My concern is about does the gdk-pixbuf-psd plugin really works ? According to the git log, it wasn't updated over two years, and this plugin seems to lack support for some psd features. Do you have a sample psd file that should work ? I sent a mail to you privately. What happens if you restart nautilus or so? I still cannot get the thumbnail from a cold boot after the psd files were moved into a new directory. That's either with nautilus/pcmanfm, there is no thumbnail browsing the new directory. If I open the psd with The Gimp, then a thumbnail of the psd is created for the directory and seen in nautilus/pcmanfm I will try to reproduce on el6 (I was using fc17). el6 doesn't have the necessary libraries to test easily. But I can confirm that using this library breaks a working system. When I was testing with this library installed, another application started crashing. It was unable to even load xpm icons with error like: ---------------------- (amule:19706): GdkPixbuf-WARNING **: Error loading XPM image loader: Le type d'images « xpm » n'est pas pris en charge (amule:19706): Gdk-CRITICAL **: IA__gdk_drawable_get_size: assertion `GDK_IS_DRAWABLE (drawable)' failed ---------------------- Uninstalling this library and using yum reinstall gdk-pixbuf2 solved the issue. Trying with a scratch build from koji to reproduce the exact binary (f17 x86_64). http://koji.fedoraproject.org/koji/taskinfo?taskID=5224057 Same problem. I cannot generate psd thumbnails on f17 x86_64 phenom CPU For info, which files do you have in /usr/share/thumbnailers ? I will try to grab some debug enviroment for gdk to test with nautilus and pcmanfm $ ls -al /usr/share/thumbnailers 合計 36 drwxr-xr-x 2 root root 4096 4月 7 18:20 . drwxr-xr-x. 529 root root 20480 4月 7 23:32 .. -rw-r--r-- 1 root root 490 3月 27 03:05 evince.thumbnailer -rw-r--r-- 1 root root 1304 4月 4 21:19 gsf-office.thumbnailer Done a new scratch build for f18: http://koji.fedoraproject.org/koji/taskinfo?taskID=5270698 This time it worked on my fc18 x86_64 running an intel core 2 duo CPU. I will try to reproduce again on my fc17 x86_64 box running an AMD Phenom. I suppose it could be a threading issue that would invalidate the gdk plugin cache. Any update about the package? This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted. Sorry about the lack of answer on this topic. I never understood why I wasn't able to preview psd file myself, probably because this software lacked support for my particular psd format. Packaging wise this review is okay altough I expect it's usage to be limited. Package is APPROVED. Package never imported, resetting ticket status. Mamoru, are you still on this? This package is very old, and I am not going to import this any longer. |