Howto: Popular AppImages one click away

Post tutorials, HOWTO's and other useful resources here.
User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#76 by M. Eerie » 31 Oct 2020, 09:16

Hi everyone!

Recent findings, have led me to this link
(Just do a duckduckgo !g "pkg2appimage recipes") ;)

Once you get the pkg2appimage.appimage from their continuous build, you can build a bunch of the last appimage available in the previous recipes repository (recipes are those *.yml files). Take in mind most of them are really old, but you get the idea on how appimages are builded/converted from packages.

Result, however is not guaranteed to work in every environment, but then, I've been able to produce a working appimage for Spotify, Chromium and (... errrmmm) that new brow$er under development (forgive me, just trying around...). All you have to do is open your terminal and making sure your pkg2appimage.appimage is executable, proceed like this:

Code: Select all

$ ./pkg2appimage.appimage Spotify
which results in getting the last Spotify package being built.

So easy!

Further reading is available from the Examples section in the appimage-builder docs provided by Tolkem above.

Also, I highly recommend reading Appimage Bundle section.


Cheers!
Last edited by M. Eerie on 31 Oct 2020, 11:50, edited 3 times in total.
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Howto: Popular AppImages one click away

Post#77 by Rava » 31 Oct 2020, 09:20

M. Eerie wrote:
31 Oct 2020, 09:16

Code: Select all

$ ./pkg2appimage.appimage Spotify
which results in getting the last Spotify package being built.
So that would get the latest stable Spotify package build.

I presume the .yml is able to deduce if it should build a i586 or x/86_64 - as by the system you currently run?
Cheers!
Yours Rava

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#78 by M. Eerie » 31 Oct 2020, 09:43

Rava wrote:
31 Oct 2020, 03:57
Do we need a Package Manager for AppImages ?
Hi Rava! Nice to hear from you again.

I think that package manager is trying to sort out the appimages maintenance bringing apt/pacman functionality to appimages. Who knows, maybe it would be useful If you use them often and widely.

Anyhow, I think the original package manager is easy to manage:

to extract:

Code: Select all

$ Myapp.appimage --appimage-extract
to package:

Code: Select all

$ ./appimagetool-x86_64.AppImage squashfs-root
Get appimagetool:

Code: Select all

$ wget https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage && chmod +x appimagetool-x86_64.AppImage
Cheers!
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#79 by M. Eerie » 31 Oct 2020, 09:53

Rava wrote:
31 Oct 2020, 09:20
I presume the .yml is able to deduce if it should build a i586 or x/86_64
It seems you have to declare the involved architecture explicitly in the .yml.

See the examples section:

gnome-calculator is (i386)

while shell bash application is arm64.

Cheers!
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#80 by M. Eerie » 31 Oct 2020, 10:06

All in all, I really think AppImages add great potential to your system if used correctly and.

You can opt for a "stable debian like base system", and then, you have the option to add self contained updated apps.

Of course, we Porteus users prefer to go fit with bundles, but the alternative is there and integrates very well with the Porteus modular concept. :)

Cheers!
Last edited by M. Eerie on 31 Oct 2020, 11:06, edited 1 time in total.
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#81 by M. Eerie » 31 Oct 2020, 10:33

The latest instance of VSCodium (referred at first post) has not been published as appimage due to a bug.

This is what I've done:
  • Get the latest commit .tar.gz package and unpack the .tar.gz file

    Code: Select all

    $ mkdir codium && tar xzf VSCodium-linux-x64-1.50.1.tar.gz -C codium
  • Unpack your last working appimage:

    Code: Select all

    $ VSCodium*.AppImage --appimage-extract
  • Replace the old codium folder in squashfs-root/usr/share/codium with the new one:

    Code: Select all

    $ rm -rf squashfs-root/usr/share/codium && mv codium squashfs-root/usr/share
  • Repack the appimage like said before:

    Code: Select all

    $ ./appimagetool-x86_64.AppImage squashfs-root
Done.

I hope you get the idea on how you can update other appimages using this method.

Cheers!
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Howto: Popular AppImages one click away

Post#82 by Rava » 31 Oct 2020, 14:48

M. Eerie wrote:
31 Oct 2020, 09:53
It seems you have to declare the involved architecture explicitly in the .yml.
Fair enough…
M. Eerie wrote:
31 Oct 2020, 09:53
See the examples section:

gnome-calculator is (i386)

while shell bash application is arm64.
but such naming non convention drives me up the hills. [*]

Is it too much to ask to name the thingg either

whatevers-i586
whatevs-x86_64
whatnow_arm64

Is it that hard to make everyone's lives more easy. Seriously.


________________
[*]
No biggie since climbing is my thing. LOL.
Cheers!
Yours Rava

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#83 by M. Eerie » 01 Nov 2020, 09:52

Finally builded GEarth Pro AppImage (64 bit version) from the official .deb package.

Code: Select all

!#/bin/bash

APP=GoogleEarth
LOWERAPP=${APP,,}
mkdir -p ./$APP ./$APP.AppDir

cd ./$APP/
wget -c https://dl.google.com/dl/earth/client/current/google-earth-stable_current_amd64.deb
wget https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage && chmod +x appimagetool-x86_64.AppImage

cd ../$APP.AppDir/
find ../$APP/*.deb -exec ar p {} data.tar.xz \; | tar xJ || true

cp ./opt/google/earth/pro/product_logo_128.png google-earth-pro.png
cp ./opt/google/earth/pro/google-earth-pro.desktop .

# Fix .desktop file so that it passes validation
sed -i -e 's|MultipleArgs|X-MultipleArgs|g' google-earth-pro.desktop
sed -i -e 's|Network|Network;|g' google-earth-pro.desktop
sed -i -e 's|keyhole|keyhole;|g' google-earth-pro.desktop

ln -s ./opt/google/earth/pro/googleearth AppRun
cd ..

./$APP/appimagetool-x86_64.AppImage GoogleEarth.AppDir

rm -rf ./$APP ./$APP.AppDir
Note: Of course, there's also a .xzm module produced a while ago by wread.

Cheers!
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Howto: Popular AppImages one click away

Post#84 by Rava » 01 Nov 2020, 11:00

M. Eerie wrote:
01 Nov 2020, 09:52
Finally builded GEarth Pro AppImage (64 bit version) from the official .deb package.

Note: Of course, there's also a .xzm module produced a while ago by wread.
Would a xzm be more responsive or is there no real difference, only that with a module you might have less double libraries installed compared to what an AppImage might bring with it.
Cheers!
Yours Rava

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#85 by M. Eerie » 01 Nov 2020, 12:14

Rava wrote:
01 Nov 2020, 11:00
Would a xzm be more responsive
In fact, I did this appimage because I had trouble with the .xzm portability of Google Earth (have a look to the linked thread).

Also, the appimage for Google Earth just includes the repackaged data from the main .deb binary with the addition of the icon, the .desktop launcher and a softlink pointing to the launcher and that's all (i.e. no gst/gstreamer plugins included). :roll:

If you follow the instructions already given in this topic, you will see the pros/cons of appimages:

Pros: You have the bundled package ready to launch (One Click Away launch-->close vs. activate --> use --> deactivate approach) ;)

Cons: Appimages tend to be bloated (not this case).

Cheers!
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Howto: Popular AppImages one click away

Post#86 by Rava » 01 Nov 2020, 13:03

M. Eerie wrote:
01 Nov 2020, 12:14
Pros: You have the bundled package ready to launch (One Click Away launch-->close vs. activate --> use --> deactivate approach) ;)

Cons: Appimages tend to be bloated (not this case).
Both approaches seemingly can go very far when it comes to portability but also for slimness.
Some years back I gave it my all to slim down the then most recent GIMP version so that is gives errors on startup, but runs okay and can save and open all files AFAIK.
It was by ratio the most slimmed down x86-64 GIMP ever done for Porteus.

By filesize alone the Tiny Core modules are all more amazingly compressed than our Porteus ones.

I never did create one, they have a long list of how you need to create a module,and that was a deal breaker cause I was unwilling to concentrate and learn so much, but probably these rules are part of why the modules are so small.

And a fun fact, the modules are compatible to Port! Just rename the module and you can activate them as Port modules.

At least it was like so some years back and AFAIK it is still so.

I wonder why it was never considered adding Tiny Core modules to the Porteus existing modules lists.
Cheers!
Yours Rava

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#87 by M. Eerie » 01 Nov 2020, 13:19

I don't really feel that size matters nowadays... Just consider how much pendrives and HD/SSD's you have collected by now. ;)

On the other hand, the bloated nature of appimages, could perhaps be considered as a strength if used the right way... That is, firejailed/sandboxed.

Think of those unique and deprecated/unmaintained applications (gems) no longer working because of new versions of dependant libraries...

Cheers!
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Howto: Popular AppImages one click away

Post#88 by Rava » 01 Nov 2020, 14:47

M. Eerie wrote:
01 Nov 2020, 13:19
I don't really feel that size matters nowadays... Just consider how much pendrives and HD/SSD's you have collected by now. ;)
Indeed but also consider that even my best 8Core machine or the two Two Core Mini Tower machines are all considered obsolete by NVidia's POV (that is mainly profit-oriented I presume)

Compared to what less capable systems folks with even less money than yours truly have to use, the wish for slim modules working fine on outdated hardware is a valid point! We shall never exclude poorer People from what is the net and all that is to be found there, and even People who do above average well today might be thrown into financial troubles in the future, and then have to rely on older hardware for the time being just as well.
Cheers!
Yours Rava

User avatar
M. Eerie
Moderator
Moderator
Posts: 616
Joined: 31 Aug 2017, 21:18
Distribution: Nemesis Xfce/MATE x64

Howto: Popular AppImages one click away

Post#89 by M. Eerie » 01 Nov 2020, 17:08

Rava wrote:
01 Nov 2020, 14:47
We shall never exclude poorer People
I'm doing this not to exclude anyone, but (I hope) to give everyone an alternate method that I think is a perfect match with the Porteus style due to its modular concept.

In fact, appimages are squashed filesystems like the ones in xzm modules. By the way, I think the bigger size is related to the default 128kb chunk size used to compress appimages. It provides for faster compression, but at the cost of bigger storage size. :pressure:

Now, computing the stored size and not the RAM memory actually used once the module is injected in the union filesystem, may lead to mistake. Once the module is activated, it is uncompressed in RAM memory the same way a single appimage would. Granted that appimages still may use a few more RAM but again, you're not launching lots of appimages at once, and you're not activating hundred of modules either, are you? :wodoo:

Which lead us to the big question: Should anyone be given more flexibility at the cost of whatever storage he can afford or not? I vote :punk:



Cheers!
> Does not compute_ 🖖

https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584

User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Howto: Popular AppImages one click away

Post#90 by Rava » 01 Nov 2020, 17:22

M. Eerie wrote:
01 Nov 2020, 17:08
Which lead us to the big question: Should anyone be given more flexibility at the cost of whatever storage he can afford or not? I vote :punk:
Freedom, Free software, flexibility, Free speech and choice is the only solution for a future.

____________________________________________________________

fx and sx are both explained in my Ravas Coding Goodies thread. [ I think ]

Code: Select all

root@porteus:/home/guest# fxsx
01.11.2020 18:32:38 ____________________________________________________________
              total        used        free      shared  buff/cache   available
Mem:           3873        2091         490          99        1292        1248
Swap:          3326           1        3324
________________________________________________________________________________
Filename				Type		Size	Used	Priority
/mnt/sda5/linuxswap                     file            2047    0       -2      
/dev/zram0                              partition       1278    1       100     
Then I did nothing in the system, just loaded one of my larger modules and asked fxsx again about free memory and about the swap.

Code: Select all

root@porteus:/home/guest# fxsx
01.11.2020 18:46:20 ____________________________________________________________
              total        used        free      shared  buff/cache   available
Mem:           3873        2092         485          99        1295        1250
Swap:          3326           1        3324
________________________________________________________________________________
Filename				Type		Size	Used	Priority
/mnt/sda5/linuxswap                     file            2047    0       -2      
/dev/zram0                              partition       1278    1       100  
Here is the loaded module:

Code: Select all

# du 007-interlink-52.9.7403.linux-x86_64_GTK3_rava_ln-interlink-bin.xzm
39708	007-interlink-52.9.7403.linux-x86_64_GTK3_rava_ln-interlink-bin.xzm
As you can see, just loading a module actually freed RAM and not consumed any. Starting the actual program is a different matter but you wrote above only about loading modules.

It differs when I actually started and used the program for a while:

Code: Select all

root@porteus:/home/guest# fxsx
01.11.2020 19:46:06 ____________________________________________________________
              total        used        free      shared  buff/cache   available
Mem:           3873        2501         309          83        1062         880
Swap:          3326          21        3305
________________________________________________________________________________
Filename				Type		Size	Used	Priority
/mnt/sda5/linuxswap                     file            2047    0       -2      
/dev/zram0                              partition       1278    21      100
And here the situation after finishing with emails and exiting interlink:

Code: Select all

root@porteus:/home/guest# fxsx
01.11.2020 20:45:52 ____________________________________________________________
              total        used        free      shared  buff/cache   available
Mem:           3873        1933         860          84        1079        1447
Swap:          3326          21        3305
________________________________________________________________________________
Filename				Type		Size	Used	Priority
/mnt/sda5/linuxswap                     file            2047    0       -2      
/dev/zram0                              partition       1278    21      100
All in all, I am content with the mem use.

And nor for updating Interlink.
Cheers!
Yours Rava

Post Reply