| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This uses an extracted pkg2appimage, since it would be tricky to get fuse
to work in the Podman containers.
|
|
OBS builds
* There are nightly OBS builds, so there is no need to build and distribute them via CI.
* On the upside we can download the packages for the AppImages from a proper (OBS) repository.
* AppImages are now built on Ubuntu 20.04 (instead of 22.04 which was the oldest
Github runner).
|
|
* We can therefore no longer provide 20.04 nightly builds.
Perhaps I will manually build binary releases for the v2.4.0 release for the last time.
The PPA will still provide 20.04 of course.
* The AppImages are consequently also built based on the Ubuntu 22.04 packages,
which are now the oldest supported ones.
|
|
Should improve the SciTECO site at the AppImages Hub (appimage.github.io).
We will have to make another PR before the site gets updated.
|
|
* You can now specify `--with-scitecodatadir` as a relative path,
that will be interpreted relative to the binary's location.
* Win32 binaries already were relocatable, but this was a Windows-specific
hack. Win32 binaries are now built with `--with-scitecodatadir=.`
since everything is in a single directory.
* Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`.
This is not crucial for ordinary installations, but is meant for AppImage creation.
* Since AppImages are now built from relocatable packages,
we no longer need the unionfs-workaround from pkg2appimage.
This should fix the strange root contents when autocompleting in
AppImage builds.
* This might also fix the appimage.github.io CI issues.
I assume that because I could reproduce the issue on FreeBSD's
Linuxulator in dependence of pkg2appimage's "union"-setting.
See https://github.com/AppImage/appimage.github.io/pull/3402
* Determining the binary location actually turned out be hard and
very platform-dependant. There are now implementations for Windows
(which could also read argv[0]), Linux and generic UNIX (which
works on FreeBSD, but I am not sure about the others).
I believe this could also be useful on Mac OS to create app bundles,
but this needs to be tested - currently the Mac OS binaries are
installed into fixed locations and don't use relocation.
|
|
* Since they blacklist Pango among other things, it would use the Pango from the host system with the glib from the AppImage,
which resulted in a version mismatch on Linux Mint 21.1.
* It is now confirmed to work at least on Linux Mint 21.1.
* The Curses AppImage still bundles libglib as SciTECO should be the only thing referencing its functions.
|
|
|
|
|
