Open acheronfail opened 2 years ago
If that docker run ...
command is acceptable, maybe I should experiment with making a Flatpak build definition for it.
While Flatpak isn't specifically intended for non-GUI applications, flatpak run com.github.Sude-.lgogdownloader <args>
is less awkward than that docker run
command and I have a proof of concept for auto-generating/updating wrapper scripts from the flatpak info -m
output that allow me to run Flatpak'd stuff like mpv
just the same as if I were running the APT-provided versions.
(My proof of concept uses the command=mpv
line output by flatpak info -m io.mpv.Mpv
to determine what the wrapper should be called and punts on resolving naming conflicts since it's just a PoC. Not perfect, as in cases like command=scummvm_wrapper
or command=PPSSPPSDL
or command=com.github.tchx84.Flatseal
, but pretty damn close for something with no special-casing or upstream buy-in.)
flatpak-builder
and the Flatpak runtimes being equivalent to the Docker build process.It could be published to Flathub so people who may be on LTS distros can still get automatic updates without having to do their own builds from source.
(Flatpak also has integration plugins for updater GUIs like GNOME Software and KDE Discover, making it as comfortable to keep up to date as APT/RPM/etc.)
filesystem=host
permissions (unsandboxed, except for the bits overlayed by Flatpak's equivalent to the Steam Runtime and the bits explicitly blacklisted), it'd be easy for end users to use Flatseal or the flatpak override
CLI command to narrow the sandbox to just the folders where they maintain their GOG collections.If you wanted to explicitly support sandboxed operation, I think some of the game engine reimplementations on Flathub use a launcher script which invokes zenity
on first run to request a "Select the directory where your game assets are" dialog which will be permanently granted into the sandbox.
(Thus removing the need for filesystem=host
... but please don't yet. I'm on Kubuntu 20.04 LTS, directory picker support was added to the spec late in the game, Kubuntu 20.04 LTS is a bit too old for the KDE portal host to have directory picker support, and the Flatpak PPA only provides an updated version of the GTK/GNOME portal host.)
@Sude- If I were to produce a working Flatpak manifest (build definition), would you be willing to at least consider having it be an official thing? If published to Flathub, they'll provide the build service for the manifest, similar to how Jekyll is integrated into GitHub Pages.
(I haven't tried it, since I like to keep my downloading and managment of installed games firmly separated, but Minigalaxy is already on Flathub.)
Some suggestions for the Dockerfile:
@ssokolow an appimage would be even better for distribution. just a simple file with everything in it.
just saw a whole ubuntu desktop gets pulled into the docker image:
The following additional packages will be installed:
accountsservice acl adwaita-icon-theme alsa-topology-conf alsa-ucm-conf apg
apport apport-symptoms aptdaemon aptdaemon-data aspell aspell-en
at-spi2-core avahi-daemon avahi-utils bind9-host bind9-libs binutils
binutils-common binutils-x86-64-linux-gnu bluez bolt bsdmainutils bubblewrap
ca-certificates cheese-common cmake-data colord colord-data cpp cpp-9
cracklib-runtime crda cups-pk-helper dbus dbus-user-session dbus-x11
dconf-cli dconf-gsettings-backend dconf-service desktop-file-utils
dictionaries-common dirmngr distro-info-data dmsetup dns-root-data
dnsmasq-base docbook-xml dpkg-dev emacsen-common enchant-2
evolution-data-server evolution-data-server-common fakeroot file fontconfig
fontconfig-config fonts-dejavu-core fprintd g++ g++-9 gcc gcc-9 gcc-9-base
gcr gdm3 geoclue-2.0 gettext-base gir1.2-accountsservice-1.0 gir1.2-atk-1.0
gir1.2-atspi-2.0 gir1.2-freedesktop gir1.2-gck-1 gir1.2-gcr-3
gir1.2-gdesktopenums-3.0 gir1.2-gdkpixbuf-2.0 gir1.2-gdm-1.0
gir1.2-geoclue-2.0 gir1.2-glib-2.0 gir1.2-gnomebluetooth-1.0
gir1.2-gnomedesktop-3.0 gir1.2-graphene-1.0 gir1.2-gtk-3.0
gir1.2-gweather-3.0 gir1.2-ibus-1.0 gir1.2-json-1.0 gir1.2-mutter-6
gir1.2-nm-1.0 gir1.2-nma-1.0 gir1.2-notify-0.7 gir1.2-packagekitglib-1.0
gir1.2-pango-1.0 gir1.2-polkit-1.0 gir1.2-rsvg-2.0 gir1.2-secret-1
gir1.2-soup-2.4 gir1.2-upowerglib-1.0 gir1.2-vte-2.91 gjs gkbd-capplet
glib-networking glib-networking-common glib-networking-services
gnome-control-center gnome-control-center-data gnome-control-center-faces
gnome-desktop3-data gnome-keyring gnome-keyring-pkcs11 gnome-menus
gnome-online-accounts gnome-session-bin gnome-session-common
gnome-settings-daemon gnome-settings-daemon-common gnome-shell
gnome-shell-common gnome-startup-applications gnome-user-docs gnupg
gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf
gpgsm groff-base gsettings-desktop-schemas gstreamer1.0-clutter-3.0
gstreamer1.0-gl gstreamer1.0-plugins-base gstreamer1.0-plugins-good
gstreamer1.0-pulseaudio gstreamer1.0-x gtk-update-icon-cache
hicolor-icon-theme humanity-icon-theme hunspell-en-us i965-va-driver ibus
ibus-data ibus-gtk ibus-gtk3 icu-devtools iio-sensor-proxy im-config
intel-media-va-driver ippusbxd iptables iso-codes iw keyboard-configuration
kmod krb5-locales language-selector-common language-selector-gnome libaa1
libaacs0 libaccountsservice0 libalgorithm-diff-perl
libalgorithm-diff-xs-perl libalgorithm-merge-perl libaom0 libapparmor1
libappindicator3-1 libappstream4 libarchive13 libargon2-1 libasan5
libasn1-8-heimdal libasound2 libasound2-data libasound2-plugins libaspell15
libassuan0 libasyncns0 libatk-bridge2.0-0 libatk1.0-0 libatk1.0-data
libatomic1 libatspi2.0-0 libavahi-client3 libavahi-common-data
libavahi-common3 libavahi-core7 libavahi-glib1 libavc1394-0 libavcodec58
libavformat58 libavutil56 libbdplus0 libbinutils libbluetooth3 libbluray2
libboost-date-time1.71-dev libboost-date-time1.71.0
libboost-filesystem1.71-dev libboost-filesystem1.71.0
libboost-iostreams1.71-dev libboost-iostreams1.71.0
libboost-program-options1.71-dev libboost-program-options1.71.0
libboost-regex1.71-dev libboost-regex1.71.0 libboost-serialization1.71-dev
libboost-serialization1.71.0 libboost-system1.71-dev libboost-system1.71.0
libboost-thread1.71.0 libboost1.71-dev libbrotli1 libbsd0 libc-dev-bin
libc6-dev libcaca0 libcairo-gobject2 libcairo2 libcamel-1.2-62
libcanberra-gtk3-0 libcanberra-gtk3-module libcanberra-pulse libcanberra0
libcap2 libcap2-bin libcc1-0 libcdparanoia0 libcheese-gtk25 libcheese8
libchromaprint1 libclutter-1.0-0 libclutter-1.0-common libclutter-gst-3.0-0
libclutter-gtk-1.0-0 libcodec2-0.9 libcogl-common libcogl-pango20
libcogl-path20 libcogl20 libcolord-gtk1 libcolord2 libcolorhug2 libcrack2
libcrypt-dev libcryptsetup12 libcss-parser-pp0v5 libcss-parser0
libctf-nobfd0 libctf0 libcups2 libcurl3-gnutls libcurl4 libdaemon0
libdatrie1 libdbus-1-3 libdbusmenu-glib4 libdbusmenu-gtk3-4 libdconf1
libdevmapper1.02.1 libdouble-conversion3 libdpkg-perl libdrm-amdgpu1
libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libdv4
libebackend-1.2-10 libebook-1.2-20 libebook-contacts-1.2-3 libecal-2.0-1
libedata-book-1.2-26 libedata-cal-2.0-1 libedataserver-1.2-24
libedataserverui-1.2-2 libedit2 libegl-dev libegl-mesa0 libegl1 libelf1
libenchant-2-2 libepoxy0 libevdev2 libevent-2.1-7 libexif12 libexpat1
libfakeroot libfile-fcntllock-perl libflac8 libfontconfig1 libfontenc1
libfprint-2-2 libfreetype6 libfribidi0 libgail-common libgail18 libgbm1
libgcc-9-dev libgck-1-0 libgcr-base-3-1 libgcr-ui-3-1 libgd3 libgdata-common
libgdata22 libgdbm-compat4 libgdbm6 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-bin
libgdk-pixbuf2.0-common libgdm1 libgee-0.8-2 libgeoclue-2-0 libgeocode-glib0
libgirepository-1.0-1 libgjs0g libgl-dev libgl1 libgl1-mesa-dri
libglapi-mesa libgles2 libglib2.0-0 libglib2.0-bin libglib2.0-data
libglu1-mesa libglu1-mesa-dev libglvnd0 libglx-dev libglx-mesa0 libglx0
libgme0 libgnome-autoar-0-0 libgnome-bluetooth13 libgnome-desktop-3-19
libgnomekbd-common libgnomekbd8 libgoa-1.0-0b libgoa-1.0-common
libgoa-backend-1.0-1 libgomp1 libgphoto2-6 libgphoto2-l10n libgphoto2-port12
libgpm2 libgraphene-1.0-0 libgraphite2-3 libgsm1 libgsound0 libgssapi-krb5-2
libgssapi3-heimdal libgssdp-1.2-0 libgstreamer-gl1.0-0
libgstreamer-plugins-base1.0-0 libgstreamer-plugins-good1.0-0
libgstreamer1.0-0 libgtk-3-0 libgtk-3-bin libgtk-3-common libgtk2.0-0
libgtk2.0-bin libgtk2.0-common libgtop-2.0-11 libgtop2-common libgudev-1.0-0
libgupnp-1.2-0 libgupnp-av-1.0-2 libgupnp-dlna-2.0-3 libgusb2
libgweather-3-16 libgweather-common libharfbuzz-icu0 libharfbuzz0b
libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhtmlcxx3v5
libhunspell-1.7-0 libhx509-5-heimdal libhyphen0 libibus-1.0-5 libical3
libice6 libicu-dev libicu66 libidn11 libiec61883-0 libieee1284-3 libigdgmm11
libimobiledevice6 libinput-bin libinput10 libip4tc2 libip6tc2 libisl22
libitm1 libjack-jackd2-0 libjansson4 libjavascriptcoregtk-4.0-18 libjbig0
libjpeg-turbo8 libjpeg8 libjson-c4 libjson-glib-1.0-0
libjson-glib-1.0-common libjsoncpp1 libk5crypto3 libkeyutils1 libkmod2
libkrb5-26-heimdal libkrb5-3 libkrb5support0 libksba8 liblcms2-2
libldap-2.4-2 libldap-common libldb2 libllvm12 liblmdb0
liblocale-gettext-perl liblsan0 libltdl7 libmagic-mgc libmagic1
libmaxminddb0 libmbim-glib4 libmbim-proxy libmediaart-2.0-0 libminizip1
libmm-glib0 libmnl0 libmozjs-68-0 libmp3lame0 libmpc3 libmpdec2 libmpfr6
libmpg123-0 libmtdev1 libmutter-6-0 libmysqlclient21 libndp0
libnetfilter-conntrack3 libnewt0.52 libnfnetlink0 libnftnl11 libnghttp2-14
libnl-3-200 libnl-genl-3-200 libnl-route-3-200 libnm0 libnma0 libnotify4
libnpth0 libnspr4 libnss-mdns libnss-systemd libnss3 libnuma1 libogg0
libopenjp2-7 libopenmpt0 libopus0 liborc-0.4-0 libpackagekit-glib2-18
libpam-cap libpam-fprintd libpam-gnome-keyring libpam-systemd libpango-1.0-0
libpangocairo-1.0-0 libpangoft2-1.0-0 libpangoxft-1.0-0 libpcap0.8 libpci3
libpciaccess0 libpcre2-16-0 libpcsclite1 libperl5.30 libphonenumber7
libpipeline1 libpixman-1-0 libplist3 libpng16-16 libpolkit-agent-1-0
libpolkit-gobject-1-0 libpopt0 libprotobuf17 libproxy1v5 libpsl5
libpthread-stubs0-dev libpulse-mainloop-glib0 libpulse0 libpulsedsp
libpwquality-common libpwquality1 libpython3-stdlib libpython3.8
libpython3.8-minimal libpython3.8-stdlib libqmi-glib5 libqmi-proxy
libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5
libqt5opengl5 libqt5opengl5-dev libqt5positioning5
libqt5positioning5-plugins libqt5positioningquick5 libqt5printsupport5
libqt5qml5 libqt5quick5 libqt5quickparticles5 libqt5quickshapes5
libqt5quicktest5 libqt5quickwidgets5 libqt5sql5 libqt5sql5-sqlite libqt5svg5
libqt5test5 libqt5webchannel5 libqt5webchannel5-dev libqt5webengine-data
libqt5webengine5 libqt5webenginecore5 libqt5webenginewidgets5 libqt5widgets5
libqt5xml5 libquadmath0 libraw1394-11 libre2-5 libreadline8 librest-0.7-0
librhash0 libroken18-heimdal librsvg2-2 librsvg2-common librtmp1
librygel-core-2.6-2 librygel-db-2.6-2 librygel-renderer-2.6-2
librygel-server-2.6-2 libsamplerate0 libsane libsane-common libsasl2-2
libsasl2-modules libsasl2-modules-db libsbc1 libsecret-1-0 libsecret-common
libsensors-config libsensors5 libshine3 libshout3 libslang2 libsm6
libsmbclient libsnapd-glib1 libsnappy1v5 libsndfile1 libsnmp-base libsnmp35
libsodium23 libsoup-gnome2.4-1 libsoup2.4-1 libsoxr0 libspeex1 libspeexdsp1
libsqlite3-0 libssh-4 libssh-gcrypt-4 libssl1.1 libstartup-notification0
libstdc++-9-dev libstemmer0d libswresample3 libtag1v5 libtag1v5-vanilla
libtalloc2 libtdb1 libteamdctl0 libtevent0 libtext-iconv-perl libthai-data
libthai0 libtheora0 libtiff5 libtinyxml2-6a libtsan0 libtwolame0 libubsan1
libuchardet0 libudisks2-0 libunwind8 libupower-glib3 libusb-1.0-0
libusbmuxd6 libuv1 libv4l-0 libv4lconvert0 libva-drm2 libva-x11-2 libva2
libvdpau1 libvisual-0.4-0 libvorbis0a libvorbisenc2 libvorbisfile3 libvpx6
libvte-2.91-0 libvte-2.91-common libvulkan-dev libvulkan1 libwacom-bin
libwacom-common libwacom2 libwavpack1 libwayland-client0 libwayland-cursor0
libwayland-egl1 libwayland-server0 libwbclient0 libwebkit2gtk-4.0-37
libwebp6 libwebpdemux2 libwebpmux3 libwebrtc-audio-processing1
libwhoopsie-preferences0 libwhoopsie0 libwind0-heimdal libwoff1 libwrap0
libx11-6 libx11-data libx11-dev libx11-xcb1 libx264-155 libx265-179
libxatracker2 libxau-dev libxau6 libxaw7 libxcb-dri2-0 libxcb-dri3-0
libxcb-glx0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-present0
libxcb-randr0 libxcb-render-util0 libxcb-render0 libxcb-res0 libxcb-shape0
libxcb-shm0 libxcb-sync1 libxcb-util1 libxcb-xfixes0 libxcb-xinerama0
libxcb-xinput0 libxcb-xkb1 libxcb-xv0 libxcb1 libxcb1-dev libxcomposite1
libxcursor1 libxdamage1 libxdmcp-dev libxdmcp6 libxext-dev libxext6
libxfixes3 libxfont2 libxft2 libxi6 libxinerama1 libxkbcommon-x11-0
libxkbcommon0 libxkbfile1 libxklavier16 libxml2 libxmu6 libxmuu1 libxpm4
libxrandr2 libxrender1 libxshmfence1 libxslt1.1 libxss1 libxt6 libxtables12
libxtst6 libxv1 libxvidcore4 libxvmc1 libxxf86vm1 libyaml-0-2 libyelp0
libzvbi-common libzvbi0 linux-libc-dev lsb-release make man-db manpages
manpages-dev mesa-va-drivers mesa-vdpau-drivers mesa-vulkan-drivers
mime-support mobile-broadband-provider-info modemmanager mousetweaks mutter
mutter-common mysql-common netbase network-manager network-manager-gnome
network-manager-pptp networkd-dispatcher ocl-icd-libopencl1 openssl p11-kit
p11-kit-modules packagekit packagekit-tools patch pci.ids perl
perl-modules-5.30 pinentry-curses pinentry-gnome3 policykit-1 ppp pptp-linux
publicsuffix pulseaudio pulseaudio-module-bluetooth pulseaudio-utils
python-apt-common python3 python3-apport python3-apt python3-aptdaemon
python3-aptdaemon.gtk3widgets python3-blinker python3-cairo python3-certifi
python3-cffi-backend python3-chardet python3-cryptography python3-cups
python3-cupshelpers python3-dbus python3-defer python3-distro
python3-entrypoints python3-gi python3-httplib2 python3-ibus-1.0
python3-idna python3-jwt python3-keyring python3-launchpadlib
python3-lazr.restfulclient python3-lazr.uri python3-ldb
python3-macaroonbakery python3-minimal python3-nacl python3-oauthlib
python3-pkg-resources python3-problem-report python3-protobuf
python3-pymacaroons python3-requests python3-requests-unixsocket
python3-rfc3339 python3-secretstorage python3-simplejson python3-six
python3-systemd python3-talloc python3-tz python3-urllib3 python3-wadllib
python3.8 python3.8-minimal qt5-gtk-platformtheme qt5-qmake qt5-qmake-bin
qt5-qmltooling-plugins qtbase5-dev qtbase5-dev-tools qtchooser
qtdeclarative5-dev qtdeclarative5-dev-tools qtpositioning5-dev
qttranslations5-l10n qtwebengine5-doc readline-common rtkit rygel samba-libs
sane-utils session-migration sgml-base sgml-data shared-mime-info
sound-theme-freedesktop switcheroo-control system-config-printer
system-config-printer-common system-config-printer-udev systemd systemd-sysv
systemd-timesyncd tzdata ubuntu-docs ubuntu-mono ubuntu-session
ubuntu-wallpapers ubuntu-wallpapers-focal ucf udev unzip update-inetd upower
usb-modeswitch usb-modeswitch-data usb.ids usbmuxd va-driver-all
vdpau-driver-all wamerican whoopsie-preferences wireless-regdb wpasupplicant
x11-common x11-xkb-utils x11-xserver-utils x11proto-core-dev x11proto-dev
x11proto-xext-dev xauth xdg-dbus-proxy xdg-user-dirs xfonts-base
xfonts-encodings xfonts-utils xkb-data xml-core xorg-sgml-doctools
xserver-common xserver-xephyr xserver-xorg xserver-xorg-core
xserver-xorg-input-all xserver-xorg-input-libinput xserver-xorg-input-wacom
xserver-xorg-legacy xserver-xorg-video-all xserver-xorg-video-amdgpu
xserver-xorg-video-ati xserver-xorg-video-fbdev xserver-xorg-video-intel
xserver-xorg-video-nouveau xserver-xorg-video-qxl xserver-xorg-video-radeon
xserver-xorg-video-vesa xserver-xorg-video-vmware xtrans-dev xwayland
xz-utils yaru-theme-gnome-shell yelp yelp-xsl zenity zenity-common
Suggested packages:
apport-gtk | apport-kde aspell-doc spellutils avahi-autoipd binutils-doc
whois vacation cmake-doc colord-sensor-argyll cpp-doc gcc-9-locales tor
docbook docbook-dsssl docbook-xsl docbook-defguide debian-keyring evolution
g++-multilib g++-9-multilib gcc-9-doc gcc-multilib autoconf automake libtool
flex bison gdb gcc-doc gcc-9-multilib gnome-orca gnome-software
| gnome-packagekit gnome-user-share realmd libcanberra-gtk-module usbguard
chrome-gnome-shell gir1.2-telepathyglib-0.12 gnome-themes-standard-data
gnome-backgrounds gir1.2-telepathylogger-0.2 parcimonie xloadimage scdaemon
groff gvfs hunspell openoffice.org-hunspell | openoffice.org-core
i965-va-driver-shaders ibus-clutter ibus-doc firewalld nftables isoquery
indicator-application lrzip alsa-utils libbluray-bdj libboost1.71-doc
libboost-atomic1.71-dev libboost-chrono1.71-dev libboost-container1.71-dev
libboost-context1.71-dev libboost-contract1.71-dev
libboost-coroutine1.71-dev libboost-exception1.71-dev libboost-fiber1.71-dev
libboost-graph1.71-dev libboost-graph-parallel1.71-dev
libboost-locale1.71-dev libboost-log1.71-dev libboost-math1.71-dev
libboost-mpi1.71-dev libboost-mpi-python1.71-dev libboost-numpy1.71-dev
libboost-python1.71-dev libboost-random1.71-dev libboost-stacktrace1.71-dev
libboost-test1.71-dev libboost-thread1.71-dev libboost-timer1.71-dev
libboost-type-erasure1.71-dev libboost-wave1.71-dev libboost1.71-tools-dev
libmpfrc++-dev libntl-dev glibc-doc libcanberra-gtk0 cups-common
libcurl4-doc libidn11-dev libkrb5-dev libldap2-dev librtmp-dev libssh2-1-dev
git bzr libdv-bin oss-compat libenchant-2-voikko libgd-tools gdbm-l10n
gphoto2 gpm krb5-doc krb5-user libvisual-0.4-plugins gstreamer1.0-tools
icu-doc libusbmuxd-tools jackd2 liblcms2-utils mmdb-bin avahi-autoipd
| zeroconf opus-tools pciutils pcscd qt5-image-formats-plugins qtwayland5
libraw1394-doc librsvg2-bin hplip libsasl2-modules-gssapi-mit
| libsasl2-modules-gssapi-heimdal libsasl2-modules-ldap libsasl2-modules-otp
libsasl2-modules-sql lm-sensors snapd snmp-mibs-downloader speex libssl-doc
libstdc++-9-doc gstreamer1.0-libav libx11-doc libxcb-doc libxext-doc
make-doc apparmor less www-browser libteam-utils isc-dhcp-client
network-manager-openconnect-gnome network-manager-openvpn-gnome
network-manager-vpnc-gnome network-manager-pptp-gnome opencl-icd appstream
ed diffutils-doc perl-doc libterm-readline-gnu-perl
| libterm-readline-perl-perl libb-debug-perl liblocale-codes-perl
pinentry-doc pavumeter pavucontrol paman paprefs ubuntu-sounds python3-doc
python3-tk python3-venv python3-apt-dbg python-apt-doc python-blinker-doc
python-cryptography-doc python3-cryptography-vectors python-dbus-doc
python3-dbus-dbg python3-crypto libkf5wallet-bin python3-keyrings.alt
python3-testresources python-nacl-doc python3-setuptools python3-openssl
python3-socks python-secretstorage-doc python3.8-venv python3.8-doc
binfmt-support default-libmysqlclient-dev firebird-dev libpq-dev
libsqlite3-dev unixodbc-dev readline-doc gstreamer1.0-plugins-ugly
rygel-playbin rygel-preferences rygel-ruih rygel-tracker tumbler unpaper
sgml-base-doc perlsgml w3-recs opensp libxml2-utils gnome-software
python3-smbc systemd-container ubuntu-wallpapers-karmic
ubuntu-wallpapers-lucid ubuntu-wallpapers-maverick ubuntu-wallpapers-natty
ubuntu-wallpapers-oneiric ubuntu-wallpapers-precise
ubuntu-wallpapers-quantal ubuntu-wallpapers-raring ubuntu-wallpapers-saucy
ubuntu-wallpapers-trusty ubuntu-wallpapers-utopic ubuntu-wallpapers-vivid
ubuntu-wallpapers-wily ubuntu-wallpapers-xenial ubuntu-wallpapers-yakkety
ubuntu-wallpapers-zesty ubuntu-wallpapers-artful ubuntu-wallpapers-bionic
ubuntu-wallpapers-cosmic ubuntu-wallpapers-disco ubuntu-wallpapers-eoan zip
comgt wvdial libvdpau-va-gl1 nvidia-vdpau-driver
nvidia-legacy-340xx-vdpau-driver nvidia-legacy-304xx-vdpau-driver wpagui
libengine-pkcs11-openssl nickle cairo-5c xorg-docs-core debhelper
xfonts-100dpi | xfonts-75dpi xfonts-scalable xinput firmware-amd-graphics
xserver-xorg-video-r128 xserver-xorg-video-mach64 firmware-misc-nonfree
Build also fails with
Step 3/10 : WORKDIR /opt
---> Running in 2adbc223acaa
Removing intermediate container 2adbc223acaa
---> 3c9b66453a0b
Step 4/10 : COPY ./entrypoint.sh ./entrypoint.sh
COPY failed: file not found in build context or excluded by .dockerignore: stat entrypoint.sh: file does not exist
[root@mountdoom dockerstuff]# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 3c9b66453a0b 25 seconds ago 1.78GB
note that this docker image is 1,78 GiB big.
Yeah, I'm well aware that the docker image is large, pulls in unnecessary packages, and could definitely be slimmer if based off of alpine
or something else! :sweat_smile:
My main motivation was for running lgogdownloader
on an Unraid system, and this was the quickest way. It's hacky that's for sure, but could definitely be cleaned up if there was more interest in it.
Build also fails with
Looks like your machine can't find the entrypoint.sh
file - did you clone it and run the docker build .
from within the repository?
(If you were unaware you don't need to build it yourself, you can just use the published image. It is large though, as you've pointed out).
If that docker run ... command is acceptable, maybe I should experiment with making a Flatpak build definition for it.
I think flatpak would also be good, but IMO I would still use the Docker one even if that were available, since in my experience Docker is more widely supported on various systems than flatpak (I could be wrong, this is just my experience).
@ssokolow an appimage would be even better for distribution. just a simple file with everything in it.
10/10 agree here. It's difficult to install things like flatpak on systems like unraid, etc. An AppImage would be way more portable and solve all the problems I had, etc.
I got so mad at this (sorry) that I built my own docker image version of it, netting about 80 MB (build environment is about ~560MB) with Alpine Linux.
Note that the graphical dialog is not compiled in to save some space.
See https://github.com/shakeyourbunny/lgogdownloader-docker if you want to have something to toy with it.
Perhaps this is a better basis for @ssokolow idea of making a flatpack.
PS: @acheronfail thank you for pushing me to implement this and for your entrypoint script (you are credited).
No worries at all - this was mainly the intention! :smile: I had an issue running it on Unraid, wrote up a quick-and-dirty Docker image to solve my problem, and shared it in case there was more interest, etc.
More than happy to use yours, since you've saved me the time of optimising it and making it smaller! :rofl:
EDIT: I've linked to your one, and archived mine. :+1:
@shakeyourbunny though it might be a good idea to put something in your README about mapping the PWD inside the docker image - otherwise I think users could run it, and accidentally start downloading something from GOG into the Docker container itself and fill up their docker space without actually downloading the files to where they want!
I did include this in the README of my repository if you'd like to reference it, etc.
10/10 agree here. It's difficult to install things like flatpak on systems like unraid, etc. An AppImage would be way more portable and solve all the problems I had, etc.
Unfortunately, I don't like Appimage and would go looking for a PPA or go back to building my own half-baked .deb
s using checkinstall
if Flatpak isn't an option and what's in the distro repos is unsuitably old.
filesystem=host
with grants specific to the folders you want to download into.Perhaps this is a better basis for @ssokolow idea of making a flatpack.
Flatpak provides its own analogue to Docker images based on Red Hat's OSTree, which is sort of like git for filesystems, for deduplicating files in common across multiple runtimes or flatpak packages, so I don't see how Docker would help.
I've actually already started whipping up a Flatpak manifest for lgogdownloader since it caught me as an interesting learning experience. (I'm using org.kde.Platform
as the base runtime since that provides a ready-made Qt and I already have it pulled in by other apps like Krita.)
Unfortunately, progress went from flying along to stymied when I slammed into what I diagnosed as "htmlcxx
has been unmaintained since 2018, isn't present already in org.kde.Platform
, and the base Freedesktop runtime that it amends contains a version of Flex too new for htmlcxx
to build successfully". (#212)
I'll see if I feel like figuring out how Debian and Ubuntu get it to build tomorrow. Maybe I'll have to vendor whatever patches they're applying.
Appimage requires you to either bundle all your libraries or not be fully portable.
This is the whole point of the appimage format.
Appimage requires yet another daemon if you want automatic updates and, from what I've heard, that still only works if the packager went to extra effort to set up automatic update support.
Appimage does not require any daemons or something, they are purely standalone. If you want the appimage launcher, this is your own choice and it is not mandatory for using them.
Appimage is, at best, comparable to APT/RPM as far as the annoyance involved in wrapping Firejail around it.
Again, you missed the whole point of appimages. They are meant to be portable across any linux distribution, self-contained and stand-alone. If you want to compare them, they are mostly similiar to the OSX .app format or "portable applications" under Windows.
Unfortunately, progress went from flying along to stymied when I slammed into what I diagnosed as "htmlcxx has been unmaintained since 2018,
Yes, htmlcxx is the old problem with lgogdownloader and you will have to build it from source if you don't have a CentOS 8, Fedora variant or force install the edge:testing package in Alpine Linux. It should be not really that a problem, though you have to modify the header files a bit in order to make it work.
If you want to provide a flatpak of lgogdownloader, I'd suggest that you provide two versions. One version without the graphical password dialog and one with. The main problem of the "simple" graphical dialog is that it will blow up the distribution enormously and is not really necessary to have.
Edit: having a whole org.kde.platform dependency on flatpak for this small application is total overkill, as it is with all dependencies only 80 MB in a docker container and - if you compile it as a static binary - even smaller, if you don't include the graphical dialogue.
Maybe a reimplementation of the password dialog in a smaller toolkit like https://github.com/sallecta/gkit, FLTK, pure Xlib or any other than QT would shrink a packaged, cross-distribution version with a graphical dialog considerably.
Again, you missed the whole point of appimages. They are meant to be portable across any linux distribution, self-contained and stand-alone. If you want to compare them, they are mostly similiar to the OSX .app format or "portable applications" under Windows.
No, I'm well aware of the point of appimages. They just defined me out of the target demographic.
(I don't want something self-contained if it means I have to give up having something that prioritizes integration. I don't want something with "Download and run an .exe
" simplicity, I want something focused on making sandboxing and automatic updates via my existing update manager as easy as possible.)
Yes, htmlcxx is the old problem with lgogdownloader and you will have to build it from source if you don't have a CentOS 8, Fedora variant or force install the edge:testing package in Alpine Linux.
I have flatpak-builder
and the org.kde.Sdk
image.
It should be not really that a problem, though you have to modify the header files a bit in order to make it work.
Naturally... but I still have to find time to figure out what to patch to make it work.
If you want to provide a flatpak of lgogdownloader, I'd suggest that you provide two versions. One version without the graphical password dialog and one with. The main problem of the "simple" graphical dialog is that it will blow up the distribution enormously and is not really necessary to have.
I'll look into the recommended way to go about it, but anyone who already has org.kde.Platform
installed for at least one other Flatpak (a group I belong to) will have Qt provided by that with no need for extra downloads, which does reduce the value of providing both.
Boost is the biggest dependency that'll be in this Flatpak and I doubt that a pre-built copy of Boost is provided in any of the Flatpak runtimes, since the KDE one has QtCore, the GNOME one probably doesn't include any C++ stuff by default, and the Freedesktop Runtime is the common base that both extend.
(And any files that match files in another Flatpak's bundled copy of Boost will be deduplicated, thanks to the OSTree underpinnings of Flatpak. Likewise, downloading the KDE runtime won't re-download or store two copies of any of the files it receives from the Freedesktop runtime.)
Maybe a reimplementation of the password dialog in a smaller toolkit like https://github.com/sallecta/gkit, FLTK, pure Xlib or any other than QT would shrink a packaged, cross-distribution version with a graphical dialog considerably.
The password dialog uses Qt to get access to a browser engine so it can run the reCAPTCHA code. I don't think you're going to find a lighter alternative if you need to bundle a copy of a full-blown browser engine no older than the most recent versions of whatever browser you're looking at in the various support channels. (I often run into reCAPTCHA being over-eager to display a "we know Mozilla has pushed a Firefox update. You can't use reCAPTCHA until you update" notice.)
That's why it can't bundle a cut-down Qt. QtWebEngine is one of the bulkiest parts of it, being basically Google Chrome with the GUI stripped off, and it's the hard requirement. That's also why I used org.kde.Platform
. It provides a copy of Qt, kept up to date by someone else and shared with other Flatpaks I've already got installed. Bundling something like GtkWebKit wouldn't improve anything.
No, I'm well aware of the point of appimages. They just defined me out of the target demographic.
(I don't want something self-contained if it means I have to give up having something that prioritizes integration. I don't want something with "Download and run an .exe" simplicity, I want something focused on making sandboxing and automatic updates via my existing update manager as easy as possible.)
You are looking for QubesOS or OpenBSD where everything on the OS level is secured and isolated up to the application by default and enforced. Or use an ostree/"atomic workstation" based Linux distribution, like Fedora Silver Blue where you can either use podman for your applications or flatpak.
If you are using a traditional Linux distribution alongside a whole bunch of flatpak packages instead of available packages, you are giving yourself just delusions. Security is moot, if only one thing of a security chain is compromised or not enforced.
(graphical subsystem for password / captcha) The password dialog uses Qt to get access to a browser engine so it can run the reCAPTCHA code. I don't think you're going to find a lighter alternative if you need to bundle a copy of a full-blown browser engine
If you need to package a whole graphical subsystem alongside with a browser engine for a console application, you are doing something wrong.
(htmlcxx) Naturally... but I still have to find time to figure out what to patch to make it work.
Well, I figured that (for CentOS 7) 3 years ago and documented it. https://gist.github.com/shakeyourbunny/33e228844bd04e5ca6ce750cc287c24d#file-building_and_compiling_lgogdownloader_on_centos_7-txt-L36 (CentOS 8 (RIP) and Fedoria have pre-built packages).
Maybe it is the same for Debian-based distros.
You are looking for QubesOS or OpenBSD where everything on the OS level is secured and isolated up to the application by default and enforced.
No, I'm not an "everything or nothing" kind of person who can afford to buy extra hardware (especially during a chip shortage) to maintain my current level of functionality (It was hard enough tuning things to get A Hat In Time playable on an Athlon II X2 270 with Wine overhead) and, as far as OpenBSD goes, I prefer to leave "Buy your hardware specifically for this and we don't support 32-bit Wine on 64-bit OS" for my router.
EDIT: That said, when I have some spare time, I want to send some patches upstream to lock down the systemd sandboxing settings on various things like spacenavd which have a lot of low-hanging fruit in their poor systemd-analyze security
scores.
EDIT: Also, OpenBSD fudges their marketing a bit. The security record they trumpet is for the core system and is invalidated as soon as you install any non-default package needed to accomplish a real-world task.
Or use an ostree/"atomic workstation" based Linux distribution, like Fedora Silver Blue where you can either use podman for your applications or flatpak.
No thanks. I actually like having the option to easily hack on the stuff I haven't sandboxed. Immutable distros make that a hassle.
If you need to package a whole graphical subsystem alongside with a browser engine for a console application, you are doing something wrong.
Yes, it's called letting companies like Google dictate that authentication in the 21st century is humans inside official upstream browsers and, if you try to bypass that, you're obviously a dirty botter/spammer/hacker.
The solution is legislation to force companies with vendor-user dynamics like GOG's to provide a more comfortable option akin to GitHub's Deploy Keys feature.
Well, I figured that (for CentOS 7) 3 years ago and documented it. https://gist.github.com/shakeyourbunny/33e228844bd04e5ca6ce750cc287c24d#file-building_and_compiling_lgogdownloader_on_centos_7-txt-L36 (CentOS 8 (RIP) and Fedoria have pre-built packages).
Maybe it is the same for Debian-based distros.
Thanks. I'll give that a try when I can block out a little time to work on it next.
@Sude- would you be open to publishing a docker image on this repo using Github Package repository? I have a dockerfile I made for my own use to develop on (since I'm on MacOS), it could be convenient for end users who want bleeding-edge features without an official release
@Sude- would you be open to publishing a docker image on this repo using Github Package repository? I have a dockerfile I made for my own use to develop on (since I'm on MacOS), it could be convenient for end users who want bleeding-edge features without an official release
I already did a small docker image for lgogdownloader (thank you @acheronfail for providing the base for that), see https://github.com/Sude-/lgogdownloader/issues/211#issuecomment-1011457419 .
https://github.com/shakeyourbunny/lgogdownloader-docker
Instructions for use see my repo. I did not make a PR, because I don't want to take full credit for that as it is based on @acheronfail initial dockerfile and it's just a proof of concept. For using that in the real world, you will also have to remap the configuration directory, the cache directory and the output directory into the container, so it's kludgy.
A better solution for running lgogdownloader on macos would be a native port, either making it buildable with xcode or within homebrew. The latter one shouldn't be to hard and my guess is that can directly use the supplied build instructions and run it without the docker overhead.
I'm building fine on MacOS, I make sure to test with Linux. My point is that the docker builds can be automated with CI for other users rather than manually rebuilding based on source changes here.
That makes no sense if you want to use lgogdownloader to "use it in other projects/users" and not hiding that you are using it.
For "production use" you still need a container environment and what user has that installed except developers? There is a very limited set of uses for running a console application as a docker image and none of them are very useful.
Using a dockerized lgogdownloader (for what) in a CI pipeline is useless for usage because it does not mirror the reality of the standard usage of lgogdownloader.
I have successfully used my own docker image for this project in a CI to download game builds completely fine. My general point is that the build process is easy, might as well make it part of the project repo running on a push for end users rather than having to manually update whenever this library does.
You can also just directly pull the binary out of the compiled docker image and publish those binaries as well, if they don't want to use docker.
You still achieve fast build times if you use the build artifact from the initial build run around and restart from within.
I have a build script (in bash) which does all things CI does like checking for required binaries, libraries etc, doing a git clone if no git repo there, a git pull for deltas etc. Also, it keeps old binary build versions in an archive and relinks (symbolic link) to the most recent build. Run time is single digit seconds rather than waiting for a minute build time, because your CI has the reconstruct the builder image etc.
But everyone has his/her own preferences I guess.
PS: lgogdownloader is not a "library".
Also, in that light of your endeavour with the docker image your PR also makes some certain sense why you want that in the project.
I can imagine a certain scenario with both things.
Sorry, I mispoke, it's an application, not a library (though you could probably use it directly like a library if you're willing to be a little creative and don't compile main.cpp).
My broader point is that this is a CLI which requires manual releases for the majority of end users, who probably don't know how to compile anything. There's a recent issue where an user wants a new build. Broadly, I guess this can be summed up as "I desire a CI/CD process, of which this includes a docker file attached to this repository".
I can maintain all of this downstream with not much effort, I'm just wondering if the maintainer of the project has any desire to have this in-tree.
FYI: the "certain scenario" is not malicious in nature, I'm creating reference binaries of a video game so mod authors can compile builds against publicly available C# dlls stripped of their implementation. This enables mod authors to compile their mods without having the game available on their system, or to test that it works on prior builds. The game's author has OK'd this process. The idea is using this project to download the desired files, strip them, then publish the reference binaries as artifacts.
I can maintain all of this upstream with not much effort, I'm just wondering if the maintainer of the project has any desire to have this in-tree.
I made a proof-of-concept Flatpak manifest back in 2022 and opened #218 about it but never got a response, so I'm in a similar situation.
I think the only blocker in the checklist there is that the icon requirement may still be mandatory for CLI apps too (even if something is omitted from the Flathub web interface for being a CLI app, icons still get used in things like GNOME Software and KDE Discover), and I wouldn't want to whip up an icon without official approval. If that's solved, I'd be OK with maintaining a Flathub release.
I can maintain all of this upstream with not much effort, I'm just wondering if the maintainer of the project has any desire to have this in-tree.
I made a proof-of-concept Flatpak manifest back in 2022 and opened #218 about it but never got a response, so I'm in a similar situation.
I think now that a Flatpak would make more sense than a docker image, but ultimately it's on Sude-'s part what he wants to have. If it's just the icon, perhaps somebody could offer some variants and one of them is chosen?
" if necessary, start brainstorming to make some candidate submissions myself." was actually in my TODO list. It's the "Sude- responds" part that's blocking it.
For every other checklist item, I'm comfortable with going the third-party package route that various things on Flathub follow, but making an icon without the go-ahead feels like packaging it under a different name without creating a fork to carry that name and, since Sude- hasn't said a word about anything there, I didn't want to start making candidate icons that may also receive no response.
License gives you the right to do whatever (the fuck) you want, but consider renaming it as to avoid confusion
I have no interest in maintaining a following fork of lgogdownloader. I'm fine with acting as a Flatpak package maintainer, akin to what an APT/RPM/etc. maintainer would do, but that's it.
This isn't exactly an issue, but I'm just letting you know that I created a docker image for
lgogdownloader
since I wanted to use it on a machine which couldn't easily install all the build dependencies, etc.It might come in handy for others too, so posting it here: https://github.com/acheronfail/lgogdownloader-docker
See the README for more information, but its usage is exactly like using the command (you just have to remember to map the config and data directories, etc).
Other notes:
lgogdownloader
stores its config files - from what I could see in the help text there's no option to control this