| View previous topic :: View next topic |
| Author |
Message |
jgehrig
n00b
Joined: 15 Nov 2009
Posts: 17
|
 Posted: Wed Oct 04, 2023 4:10 pm Post subject: AppImage based EBuilds not working |
 |
|
There are a few packages I prefer to pull in via ebuild, usually due to long build times, propriety code, etc.
In the past, I wrote some basic ebuild scripts to download, write menu entries, copy to /opt, and symlink the packages. For a long time, these ebuild scripts worked fine.
However, it looks like a change in portage broke my scripts at some point. The scripts now result in an invalid AppImage installed to /opt. It looks like some sort of stripping, or preprocessing is going on during the copy. I've tried various commands/techniques for copying the file from within the ebuild with no success.
Here is an example ebuild script:
| Code: |
EAPI=8
APPIMAGE_BIN="Nextcloud-${PV}-x86_64.AppImage"
SYM_BIN_NAME="nextcloud"
inherit desktop xdg-utils
DESCRIPTION="Desktop Syncing Client for Nextcloud"
HOMEPAGE="https://github.com/nextcloud/desktop"
SRC_URI="https://github.com/nextcloud-releases/desktop/releases/latest/download/${APPIMAGE_BIN}"
RESTRICT="mirror"
LICENSE="CC-BY-3.0 GPL-2"
SLOT="0"
KEYWORDS="amd64"
src_unpack() {
local EXTRACT_DIR="squashfs-root"
local EXTRACT_DEST="${P}"
cp "${DISTDIR}/${APPIMAGE_BIN}" "${WORKDIR}"
chmod +x "${APPIMAGE_BIN}" \
|| die "Failed to add execute permissions to bundle"
"${WORKDIR}/${APPIMAGE_BIN}" --appimage-extract >/dev/null 2>/dev/null \
|| die "Failed to extract AppImage bundle"
mv "${EXTRACT_DIR}" "${EXTRACT_DEST}" \
|| die "Failed to move AppImage bundle to destination"
}
src_install() {
doicon Nextcloud.png
domenu com.nextcloud.desktopclient.nextcloud.desktop
exeinto /opt/${PN}
doexe ../${APPIMAGE_BIN}
dosym /opt/${PN}/${APPIMAGE_BIN} usr/bin/${SYM_BIN_NAME}
}
pkg_postinst() {
xdg_desktop_database_update
}
|
Everything works fine, except the `doexe` command results in a AppImage that is modified and smaller than the original. It will not run. Everything works if the AppImage is manually copied over to portage's working directory mid-build or to /opt after the merge.
Any ideas on how to resolve this? Or is this simply an un-supported workflow for portage?
Thanks! |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1849
|
| Posted: Wed Oct 04, 2023 4:46 pm Post subject: |
|
|
All 'doexe' does is ensures the target directory and source file exists and runs: | Code: | | install ${EXEOPTIONS} "${mysrc}" "${ED%/}/${__E_EXEDESTTREE#/}" |
Where defaults are: EXEOPTIONS="-m0755" ED=${DISTDIR} __E_EXEDESTTREE=""
__E_EXEDESTTREE is affected by 'exeinto'
EXEOPTIONS affected by 'exeopts'
See its source
Perhaps your unpack has caused the file to change itself? |
|
| Back to top |
|
|
arran4
n00b
Joined: 19 Sep 2003
Posts: 9
Location: Melbourne, Australia
|
| Posted: Mon Jun 24, 2024 11:03 am Post subject: |
|
|
I had to add:
To my ebuilds to get around the stripping:
| Code: |
* QA Notice: Pre-stripped files found:
* /usr/bin/appimagetool
strip: x86_64-pc-linux-gnu-strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version
/usr/bin/appimagetool
|
|
|
| Back to top |
|
|
|
Portage & Programming
