[appimagetool] Wrong message/instruction re. icon placement for creating AppImage

[pdfkungfoo]

Consider this situation:

 kp@stretch:AppDirs>  ls -ld */
   drwxr-xr-x 3 kp kp 4096 Dec 19 11:45 env/

 kp@stretch:AppDirs>  ls -l /home/kp/AppDirs/env/usr/share/icons/hicolor/256x256/apps/env.png
   -rw-r--r-- 1 kp kp 55897 Dec  5 13:27 /home/kp/AppDirs/env/usr/share/icons/hicolor/256x256/apps/env.png

 kp@stretch:AppDirs>  appimagetool env/
   Using architecture x86_64
   /home/kp/AppDirs/env should be packaged as env-x86_64.AppImage
   env{.png,.svg,.svgz,.xpm} defined in desktop file but not found
   For example, you could put a 256x256 pixel png into
   /home/kp/AppDirs/env/usr/share/icons/hicolor/256x256/apps/env.png

 kp@stretch:AppDirs>  appimagetool env/

So, the icon env.png is in the place appimagetool demands (i.e. '/home/kp/AppDirs/env/usr/share/icons/hicolor/256x256/apps/env.png'), but then still doesn't seem to create the AppImage.

However, when I place the icon in the root of the AppDir (i.e. '/home/kp/AppDirs/env/env.png'), it seems to have no problem:

 kp@stretch:AppDirs>  mv env/usr/share/icons/hicolor/256x256/apps/env.png  env/env.png 

 kp@stretch:AppDirs>  ls -l /home/kp/AppDirs/env/env.png 
   -rw-r--r-- 1 kp kp 55897 Dec  5 13:33 /home/kp/AppDirs/env/env.png

 kp@stretch:AppDirs>  appimagetool env
   Using architecture x86_64
   /home/kp/AppDirs/env should be packaged as env-x86_64.AppImage
   Deleting pre-existing .DirIcon
   Creating .DirIcon symlink based on information from desktop file
   WARNING: AppStream upstream metadata is missing, please consider creating it
         in usr/share/metainfo/podofo.appdata.xml
         Please see https://www.freedesktop.org/software/appstream/docs/chap-
   Quickstart.html#sect-Quickstart-DesktopApps
         for more information.
   Generating squashfs...
   Parallel mksquashfs: Using 2 processors
   Creating 4.0 filesystem on env-x86_64.AppImage, block size 131072.
   [========================================================|] 9/9 100%

   Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments, compressed xattrs
        duplicates are removed
   Filesystem size 81.05 Kbytes (0.08 Mbytes)
        68.00% of uncompressed filesystem size (119.18 Kbytes)
   Inode table size 259 bytes (0.25 Kbytes)
        42.53% of uncompressed inode table size (609 bytes)
   Directory table size 236 bytes (0.23 Kbytes)
        63.96% of uncompressed directory table size (369 bytes)
   Number of duplicate files found 0
   Number of inodes 19
   Number of files 9
   Number of fragments 1
   Number of symbolic links  1
   Number of device nodes 0
   Number of fifo nodes 0
   Number of socket nodes 0
   Number of directories 9
   Number of ids (unique uids + gids) 1
   Number of uids 1
        root (0)
   Number of gids 1
        root (0)
   Embedding ELF...
   Marking the AppImage as executable...
   Success

   Please consider submitting your AppImage to AppImageHub, the crowd-sourced
   central directory of available AppImages, by opening a pull request
   at https://github.com/AppImage/appimage.github.io

---

My appimagetool dates from Dec 6th, is an AppImage, shows version 'continuous', with a filesize of 431.800 Bytes, and has this md5sum: 4dfe8814504c88ad9bec81ec07196bf1.

[TheAssassin]

So, the icon env.png is in the place appimagetool demands (i.e. '/home/kp/AppDirs/env/usr/share/icons/hicolor/256x256/apps/env.png'), but then still doesn't seem to create the AppImage.

I tried to reproduce the issue with a recent appimagetool version, and the message I get is different:

> env ARCH=x86_64 appimagetool-x86_64.AppImage test test.AppImage
Using architecture x86_64
/tmp/test should be packaged as test.AppImage
echo{.png,.svg,.svgz,.xpm} not present but defined in desktop file

I get this exact message for two situations: no icon file at all in the AppDir, and an icon called test.png in test/usr/share/icons/hicolor/256x256/.

General remark: Error reports for outdated continuous versions are generally a bad idea by the way. This branch is deployed after every build, and there may be a malfunction which has been fixed within the two weeks since you downloaded your current version, or there may have been a faulty commit for your specific issue. Please always update and try to reproduce your issue before opening an issue on GitHub.

I will close the issue now. Please proceed by updating appimagetool (e.g., using AppImageUpdate), and if the error can be reproduced, maybe zip your AppDir and upload it here.

P.S.:

doesn't seem to create the AppImage

Either it creates one or not. In your case, it did not. Please avoid imprecise language in such cases.

[pdfkungfoo]

@TheAssassin commented:

"General remark: Error reports for outdated continuous versions are generally a bad idea by the way."

I also have a general remark: if you had read my message precisely, you'd have seen that the tool version I used isn't outdated, but current as from a few hours ago. You'd have noticed the date, the file size and the MD5 sum of the binary in order to check.

It is "current as from a few hours ago", because I did, just minutes before creating this issue, run appimageupdate ./appimagetool, and it did indeed create an updated AppImage, and this updated AppImage gives exactly the date (Dec 5th), filesize and MD5 sum I quoted.

@TheAssassin also said:

"Please avoid imprecise language in such cases."

You are right here. I used a sloppy wording (which you however interpreted correctly, in that it in fact didn't create the AppImage).

[pdfkungfoo]

Meanwhile I updated appimagetool AGAIN:

$~>  ~/bin/appimageupdatetool ~/bin/appimagetool
Checking for updates...
Fetching release information for tag "continuous" from GitHub API.
... done!
Starting update...

Fetching release information for tag "continuous" from GitHub API.
0% done
Updating from GitHub Releases via ZSync
0% done
zsync2: /home/kp/bin/appimagetool-x86_64.AppImage found, using as seed file
zsync2: Target file: /home/kp/bin/appimagetool-x86_64.AppImage
zsync2: Reading seed file: /home/kp/bin/appimagetool
zsync2: Reading seed file: /home/kp/bin/appimagetool-x86_64.AppImage
zsync2: Usable data from seed files: 99.563319%
zsync2: Renaming temp file
zsync2: Fetching remaining blocks
99.56% done (0.44 of 0.45 MiB)...
zsync2: Downloading from https://github-production-release-asset-2e65be.s3.amazonaws.com/9435153/c67c878e-e384-11e7-8977-e63cf0a6ba1c?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20171219%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20171219T154526Z&X-Amz-Expires=300&X-Amz-Signature=7dfce7227aa6c2e1cef220ad277cc5601020be77fa3280146cfbeae7dd78971a&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dappimagetool-x86_64.AppImage&response-content-type=application%2Foctet-stream
99.56% done (0.44 of 0.45 MiB)...
zsync2: Verifying downloaded file
zsync2: checksum matches OK
zsync2: used 466944 local, fetched 1456
100.00% done (0.45 of 0.45 MiB)...
Update successful. New file created: /home/kp/bin/appimagetool-x86_64.AppImage

I now have this version:

$~>  ls -l /home/kp/bin/appimagetool-x86_64.AppImage
  -rwx--x--x 1 kp kp 468400 Dec 17 22:48 /home/kp/bin/appimagetool-x86_64.AppImage

$~>  md5sum /home/kp/bin/appimagetool-x86_64.AppImage
  dfc237bc9ede47dd98d9020d1dd9fbe4  /home/kp/bin/appimagetool-x86_64.AppImage

And this updated version gives precisely this message, without creating an AppImage:

$~>  /home/kp/bin/appimagetool-x86_64.AppImage  env
Using architecture x86_64
/home/kp/AppDirs/env should be packaged as env-x86_64.AppImage
env{.png,.svg,.svgz,.xpm} defined in desktop file but not found
For example, you could put a 256x256 pixel png into
/home/kp/AppDirs/env/usr/share/icons/hicolor/256x256/apps/env.png

This message is wrong, because a 256x256 pixel PNG is exactly in that place. If I move the PNG into the root of the AppDir, to /home/kp/AppDirs/env/env.png, then appimagetool creates the AppImage.

One last advise, dude: Mind your comments. You tend to insult people.

[TheAssassin]

My appimagetool dates from Dec 6th, is an AppImage, shows version 'continuous', with a filesize of 431.800 Bytes, and has this md5sum: 4dfe8814504c88ad9bec81ec07196bf1.

Dec 6th, 2017, was 13 days ago. I have tested it with the latest continuous build, which I downloaded with AppImageUpdate as well. Your build is just not the one I have.

> md5sum appimagetool-x86_64.AppImage 
7c94c12b50d8855f88cb94b5c7fd1254  appimagetool-x86_64.AppImage

Instead of comparing error messages or arguing about semantics, I went to the source code, and found the error message's location.

https://github.com/AppImage/AppImageKit/blame/b50a73e9fe34f6e0337a4aa4985d47010de5ef1d/src/appimagetool.c#L612-L616

The commit which modified a month ago. Looking at my file, it seems like I am the one with an outdated version, but that hasn't been detected so far.

It turned out to be a bug in AppImageUpdate, which, when using -O and when the .zsync file contains the same output file name, the update is performed, but the resulting file moves fail to move the update to the appropriate location.

You're often claiming I wouldn't read your reports. I do. Thoroughly. And as you can see, your data, especially the build date, to me shows you're using an outdated version.

One last advise, dude: Mind your comments. You tend to insult people.

If you really want to start such a flame war in public (again):

I haven't said anything negative about your person, but may have criticized your methods, as they often seem not precise enough to me to make claims about applications' behavior, . If you can't bear such criticism on your methods, or on your ideas, which I may criticize as well, and you think you can all blame it on my replies, I can offer to stop working on any issue you will ever report in the future. This is not in the project's interest, but it is an option I consider.

Discussions is defined as sharing opinions with each other. Saying "yes" to everything doesn't make up a discussion. Insulting people is bad, but criticising people's ideas or postings must be allowed.

Whenever I asked about a detail you should share, you provide anything else. This time, I asked for the AppDir to make sure the issue can be reproduced locally. I don't see that upload anywhere. When flagging an issue as invalid for being unable to reproduce it, you start to complain.

Do you really believe posting apparently biased "analyses" of discussions is doing any good to a discussion or issue report? Or did you just feel treated "unfair" or so, and tried to "find justice" by trying to pillory your "enemy" there? Whatever it is, it is very bad style.

I will no longer work on this issue. It definitely isn't urgent for the project. Anybody may send a PR to restore the old message, or make appimagetool search in these locations for potential icons.

Thanks for assisting in finding the bug in AppImageUpdate, though.

[pdfkungfoo]

Here is an idiot-proof way to reproduce this bug with a minimally viable example setup.

First part

Prepare a first AppDir, with the icon at the recommended location:

mkdir -p ./env1/usr/bin
cp /usr/bin/env ./env1/usr/bin/
mkdir -p ./env1/usr/share/icons/hicolor/256x256/apps/
touch ./env1/usr/share/icons/hicolor/256x256/apps/env.png
cat <<__EOF__ > ./env1/env.desktop 
[Desktop Entry]
Name=env
Type=Application
Exec=env
Icon=env
Comment=Print environment variables and their value
Categories=X-Utilities;
Terminal=true
__EOF__
cat << __EOF__ > ./env1/AppRun
#!/bin/bash
exec $HERE/usr/bin/env
__EOF__
chmod +x ./env1/AppRun

This gives you the following minimal directory structure:

find env1 -ls
  9047472      4 drwxr-xr-x   3 kp       kp           4096 Dec 19 17:14 env1
  9184798      4 drwxr-xr-x   4 kp       kp           4096 Dec 19 17:14 env1/usr
  9446152      4 drwxr-xr-x   3 kp       kp           4096 Dec 19 17:14 env1/usr/share
 10361185      4 drwxr-xr-x   3 kp       kp           4096 Dec 19 17:14 env1/usr/share/icons
 10493595      4 drwxr-xr-x   3 kp       kp           4096 Dec 19 17:14 env1/usr/share/icons/hicolor
 10623964      4 drwxr-xr-x   3 kp       kp           4096 Dec 19 17:14 env1/usr/share/icons/hicolor/256x256
 10752257      4 drwxr-xr-x   2 kp       kp           4096 Dec 19 17:14 env1/usr/share/icons/hicolor/256x256/apps
 10752258      0 -rw-r--r--   1 kp       kp              0 Dec 19 17:14 env1/usr/share/icons/hicolor/256x256/apps/env.png
  9309699      4 drwxr-xr-x   2 kp       kp           4096 Dec 19 17:14 env1/usr/bin
  9316910     32 -rwxr-xr-x   1 kp       kp          31496 Dec 19 17:14 env1/usr/bin/env
  9047479      4 -rw-r--r--   1 kp       kp            150 Dec 19 17:14 env1/env.desktop

(Note, I'm aware that this probably is NOT a complete and valid AppDir structure. That, however, is irrelevant here...)

This AppDir makes appimagetool fail when asked to create an AppImage:

appimagetool env1
Using architecture x86_64
/home/kp/AppDirs/tmp1/env1 should be packaged as env-x86_64.AppImage
env{.png,.svg,.svgz,.xpm} defined in desktop file but not found
For example, you could put a 256x256 pixel png into
/home/kp/AppDirs/tmp1/env1/usr/share/icons/hicolor/256x256/apps/env.png

Second part:

Create an AppDir with the icon placed in the root of the AppDir:

mkdir -p ./env2/usr/bin
cp /usr/bin/env ./env2/usr/bin/
#### mkdir -p ./env2/usr/share/icons/hicolor/256x256/apps/
touch ./env2/env.png
cat <<__EOF__ > ./env2/env.desktop 
[Desktop Entry]
Name=env
Type=Application
Exec=env
Icon=env
Comment=Print environment variables and their value
Categories=X-Utilities;
Terminal=true
__EOF__
cat << __EOF__ > ./env2/AppRun
#!/bin/bash
exec $HERE/usr/bin/env
__EOF__
chmod +x ./env2/AppRun

This gives you the following minimal directory structure:

find env2 -ls
 10885985      4 drwxr-xr-x   3 kp       kp           4096 Dec 19 17:14 env2
 10885995      0 -rw-r--r--   1 kp       kp              0 Dec 19 17:14 env2/env.png
 11010471      4 drwxr-xr-x   3 kp       kp           4096 Dec 19 17:14 env2/usr
 11148110      4 drwxr-xr-x   2 kp       kp           4096 Dec 19 17:14 env2/usr/bin
 11148112     32 -rwxr-xr-x   1 kp       kp          31496 Dec 19 17:14 env2/usr/bin/env
 10885997      4 -rw-r--r--   1 kp       kp            150 Dec 19 17:14 env2/env.desktop

And appimagetool creates a (locally) working AppImage from this structure:

 appimagetool env2
Using architecture x86_64
/home/kp/AppDirs/tmp1/env2 should be packaged as env-x86_64.AppImage
Deleting pre-existing .DirIcon
Creating .DirIcon symlink based on information from desktop file
WARNING: AppStream upstream metadata is missing, please consider creating it
         in usr/share/metainfo/env.appdata.xml
         Please see https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps
         for more information.
Generating squashfs...
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on env-x86_64.AppImage, block size 131072.
[==============================================================================|] 2/2 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments, compressed xattrs
        duplicates are removed
Filesystem size 14.13 Kbytes (0.01 Mbytes)
        44.95% of uncompressed filesystem size (31.43 Kbytes)
Inode table size 105 bytes (0.10 Kbytes)
        46.67% of uncompressed inode table size (225 bytes)
Directory table size 86 bytes (0.08 Kbytes)
        71.07% of uncompressed directory table size (121 bytes)
Number of duplicate files found 1
Number of inodes 7
Number of files 3
Number of fragments 1
Number of symbolic links  1
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 3
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
Embedding ELF...
Marking the AppImage as executable...
Success

Please consider submitting your AppImage to AppImageHub, the crowd-sourced
central directory of available AppImages, by opening a pull request
at https://github.com/AppImage/appimage.github.io

(Again, I'm aware that this AppImage may not be portable. However, this is irrelevant here...)

[pdfkungfoo]

"Dec 6th, 2017, was 13 days ago. I have tested it with the latest continuous build, which I downloaded with AppImageUpdate as well. Your build is just not the one I have."

So? You could have stated that fact already hours ago. Because I gave date, filesize and MD5 sum of my binary. Something you already didn't take into account the last time we disagreed about the viability of my report about another problem.

Instead you prefer to start a general briefing and lecturing from a high horse about "bad the idea to use outdated versions" upon me.

Even if it was "13 days ago": at the time of writing the issue it was the latest I could get through appimageupdate.

"Instead of comparing error messages or arguing about semantics,"

Wait! I can ONLY compare error messages, because I'm not a developer. Do you not want AppImage users to report what they see?? Do you want users to look at the C/C++ source code (and learn to read code) whenever they encounter problems? Doesn't sound AppImage-ish to me...

Oh, and you may want to read up about the meaning of "semantics". Did you mean to say "phrasing" or "wording"? This discussion IS about the semantics of the problem...

"I went to the source code, and found the error message's location."

That's your role. You are a developer.

" Looking at my file, it seems like I am the one with an outdated version,"

A-ha.

"but that hasn't been detected so far."

And? Is this MY fault?

"And as you can see, your data, especially the build date, to me shows you're using an outdated version."

And to ME, as to any other user, it shows that the most version I got through appimageupdate is just from built on that date, and it must be the most recent one....

"I [....] may have criticized your methods,"

You haven't. You have started to generally lecturing someone else from your high horse.

"as they often seem not precise enough to me to make claims about applications' behavior"

I will try to think hard about how I could make my reports even more precise.

From my point of view I could not do it better than I did at the time I reported it. (BTW, I had noticed this already a few days ago, but failed to report it immediately, because of other urgent tasks. This morning I remembered, and updated appimagetool before I really submitted the issue, so I was sure to have the latest and greatest in my hands.)

"[....] flame war [....] you can't bear such criticism on your methods [....] bla-blah...]"

No further comment.

"When flagging an issue as invalid for being unable to reproduce it, you start to complain."

Not correct.

I didn't "complain". I simply tested again, with an even more up-to-date version of appimagetool, re-confirmed the problem and now flagged the issue as a definite bug.

"I will no longer work on this issue."

Your decision.

"It definitely isn't urgent for the project."

This is a wrong message every user will see if he/she has a similar setup, because they follow some instruction how to prepare an AppDir in the project's documents (I can't pinpoint the location right now, but will look once I've the time) and this message also gives them a wrong instruction about what to do next if their AppImage build fails.

Also your decision if you rate this as "not urgent for the project".

[probonopd]

Let me look into this. If there is a bug, it is most likely my bug, and of course I will want to fix it.