[Debian GNUstep maintainers] New PikoPixel release coming soon

[Josh Freeman]

Hi Yavor & Gürkan,

    Hope all's well!

    The new bug-fix version of PikoPixel I mentioned awhile back (fixing in-window menus on GNOME) is nearly done.

    It also has various minor fixes, including the compiler & AppStream warnings Yavor mentioned, and will let you remove most of the Debian patches.

    Here are the changes affecting the package:

1) PikoPixel's icon resource file (PikoPixel.png) must now be copied/linked to the default-icon-theme ("hicolor") directory

    In addition to the the AppStream warnings Yavor mentioned last year, the pikopixel.app package now also gives an AppStream error, icon-not-found:
https://appstream.debian.org/sid/main/issues/pikopixel.app.html

    To fix this, I updated fix_GNUstep_PP_desktop_file.sh to set PikoPixel.desktop's 'Icon' entry to just "PikoPixel", so its icon will get looked up by name:
https://specifications.freedesktop.org/icon-theme/latest/#icon_lookup
(This also allows other desktop-icon themes to override PikoPixel's icon with their own version).

    As suggested in the AppStream Report's error message:
"To make the icon easier to find, place it in /usr/share/icons/hicolor/<size>/apps and ensure the Icon= value of the .desktop file is set  correctly."

    PikoPixel's app-icon file, PikoPixel.png (renamed in this release from GNUstepAppIcon.png), is 128x128, so it should go in:
/usr/share/icons/hicolor/128x128/apps/

* NOTE: When I install PikoPixel from the command line, just installing the icon file isn't enough; The icon won't appear in the desktop environment until the modification-date of the hicolor theme's top-level directory is updated:
$ sudo touch /usr/share/icons/hicolor
(Does the Debian package system do this automatically?)

    Despite the issue with symbolic paths in the .desktop file, symbolically-linking to the app's icon file from the hicolor directory seems to work OK (since there's no longer an icon path in the .desktop file).


2) Most of debian/patches/desktop-file.patch can be removed (except for the part overriding the openapp command, which was noted as Debian-specific?):
https://sources.debian.org/src/pikopixel.app/1.0-b10b-3/debian/patches/desktop-file.patch

- Line 20: fix_GNUstep_PP_desktop_file.sh now includes a shebang interpreter path (#! /bin/sh), so it no longer needs one inserted

- Lines 36-43: no longer need to manually remove the deprecated fields (Encoding, FilePattern), since pl2link no longer generates them

- Lines 44-49: the .desktop's icon entry is now just a name - it's no longer a path that needs modifying (converting from a symbolic link)


3) debian/patches/bom-plist.patch can be removed
https://sources.debian.org/src/pikopixel.app/1.0-b10b-3/debian/patches/bom-plist.patch

- A byte-order mark (BOM) was added to PikoPixelInfo.plist, so it no longer needs one inserted


    You can check out a prerelease version of the sources here:
https://twilightedge.com/downloads/PikoPixel.Sources.1.0-b10c-prerelease2.tar.gz

    Please let me know if you have any questions or problems, and I'll let you know when the version's released!

    Thank you for packaging PikoPixel!

Cheers,

Josh



On 1/22/25 12:05 PM, Yavor Doganov wrote:
> Hi Josh, and Happy New Year,
> 
> On Wed, 09 Oct 2024 06:11:30 +0300,
> Yavor Doganov wrote:
>> Josh Freeman wrote:
>>>     There's a new bugfix release of pikopixel.app coming soon -
>>>     hopefully by the end of the week.
> [...]
>>>     Saw you just updated several GNUstep app Debian packages, so
>>>     letting you know in case you were about to update the
>>>     pikopixel.app package too.
>>
>> We'll hold it up until you make the release.
> 
> We had to make an upload for the (hopefully) forthcoming multiarch
> transition.  But of course we'll make another upload when you make the
> release, if it's not in the middle of the transition.  There are a few
> issues which I'd wish you include in the new release:
> 
> There's a compiler warning which I believe is legitimate:
> 
> NSBitmapImageRep_PPUtilities_ColorMasking.m:605:52: warning: ‘selectionMaskRow’ may be used uninitialized [-Wmaybe-uninitialized]
>    605 |             if ((selectionMask && !selectionMaskRow[checkCol])
>        |                                    ~~~~~~~~~~~~~~~~^~~~~~~~~~
> NSBitmapImageRep_PPUtilities_ColorMasking.m:548:61: note: ‘selectionMaskRow’ was declared here
>    548 |                     *destinationMaskRow, *sourceBitmapRow, *selectionMaskRow;
>        |                                                             ^~~~~~~~~~~~~~~~
> 
> Perhaps you fixed this already.
> 
> There's a lintian warning:
> 
> W: pikopixel.app: appstream-metadata-validation-failed Problems reported by "appstreamcli validate-tree".
> N:
> N:   The specified AppStream metadata file fail to validate using 'appstreamcli
> N:   validate-tree --no-net path-to-package-root'.
> N:
> N:   Please refer to https://wiki.debian.org/AppStream/Guidelines for details.
> N:
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: appstream-metadata
> 
> $ appstreamcli validate --no-net PikoPixel/PikoPixel.appdata.xml
> W: PikoPixel:4: cid-desktopapp-is-not-rdns PikoPixel
> I: PikoPixel:43: developer-name-tag-deprecated
> I: PikoPixel:~: developer-info-missing
> 
> ✘ Validation failed: warnings: 1, infos: 2, pedantic: 3
> 
> That's basically the same as:
> 
> https://appstream.debian.org/sid/main/issues/pikopixel.app.html
> 
> [...]
> 
> Please take a look at the patches in debian/patches and see if you can
> merge them.  Unfortunately, my change for the hppa problem is still
> unstested because pikopixel.app built on a non-problematic buildd
> there.  But I have no other clue for this issue.
> 
> [...]