This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 902024 - Review Request: gdk-pixbuf-psd - GdkPixbuf loader for the PSD file format
Review Request: gdk-pixbuf-psd - GdkPixbuf loader for the PSD file format
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nicolas Chauvet (kwizart)
Fedora Extras Quality Assurance
:
Depends On:
Blocks: DESIGN-SW
  Show dependency treegraph
 
Reported: 2013-01-20 09:04 EST by Mamoru TASAKA
Modified: 2016-04-10 16:08 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
kwizart: fedora‑review?


Attachments (Terms of Use)

  None (edit)
Description Mamoru TASAKA 2013-01-20 09:04:22 EST
Spec URL: http://mtasaka.fedorapeople.org/Review_request/gdk-pixbuf-psd/gdk-pixbuf-psd.spec
SRPM URL: http://mtasaka.fedorapeople.org/Review_request/gdk-pixbuf-psd/gdk-pixbuf-psd-0.1.0-1.fc.src.rpm
Description: 
This project aims to provide a GdkPixbuf loader for the PSD file format.

GdkPixbuf is part of GTK and applications like Eye of GNOME and gThumb use it
to handle image loading. The loader provided by this project will let those
applications open PSD images and enable thumbnails in nautilus, too.

The loader supports:
- RGB and CYMK images
- RLE compression
- 8 and 16 bit color depths

Fedora Account System Username: mtasaka

Koji scratch build
F-19: http://koji.fedoraproject.org/koji/taskinfo?taskID=4887002
F-18: http://koji.fedoraproject.org/koji/taskinfo?taskID=4887003
Comment 1 Michael Schwendt 2013-01-20 17:56:18 EST
> 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/
Comment 2 Mamoru TASAKA 2013-01-20 19:10:50 EST
If some file format is not recognized, I will report it upstream.
Comment 3 Michael Schwendt 2013-01-21 07:55:17 EST
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.
Comment 4 Mamoru TASAKA 2013-01-21 08:30:07 EST
(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
Comment 5 Mamoru TASAKA 2013-01-21 08:32:34 EST
(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
Comment 6 Nicolas Chauvet (kwizart) 2013-03-01 11:48:55 EST
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.
Comment 7 Nicolas Chauvet (kwizart) 2013-03-13 13:03:03 EDT
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.
Comment 8 Mamoru TASAKA 2013-03-22 14:03:15 EDT
ping?
Comment 9 Nicolas Chauvet (kwizart) 2013-03-22 14:20:52 EDT
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 ?!
Comment 10 Mamoru TASAKA 2013-03-22 15:10:55 EDT
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.
Comment 11 Mamoru TASAKA 2013-03-23 03:02:54 EDT
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?
Comment 12 Nicolas Chauvet (kwizart) 2013-03-24 08:08:59 EDT
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 ?
Comment 13 Mamoru TASAKA 2013-03-24 09:13:26 EDT
I sent a mail to you privately.
Comment 14 Mamoru TASAKA 2013-03-28 05:56:39 EDT
What happens if you restart nautilus or so?
Comment 15 Nicolas Chauvet (kwizart) 2013-03-29 03:31:42 EDT
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
Comment 16 Nicolas Chauvet (kwizart) 2013-03-29 03:32:33 EDT
I will try to reproduce on el6 (I was using fc17).
Comment 17 Nicolas Chauvet (kwizart) 2013-04-07 17:46:01 EDT
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
Comment 18 Nicolas Chauvet (kwizart) 2013-04-09 04:41:49 EDT
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
Comment 19 Mamoru TASAKA 2013-04-09 10:25:54 EDT
$ 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
Comment 20 Nicolas Chauvet (kwizart) 2013-04-18 08:35:33 EDT
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.
Comment 21 Luya Tshimbalanga 2016-04-10 16:08:10 EDT
Any update about the package?

Note You need to log in before you can comment on or make changes to this bug.