Sude- / lgogdownloader

LGOGDownloader is unofficial downloader to GOG.com for Linux users. It uses the same API as the official GOG Galaxy.
https://sites.google.com/site/gogdownloader/
Do What The F*ck You Want To Public License
691 stars 67 forks source link

Docker image for lgogdownloader #211

Open acheronfail opened 2 years ago

acheronfail commented 2 years ago

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:

ssokolow commented 2 years ago

If that docker run ... command is acceptable, maybe I should experiment with making a Flatpak build definition for it.

  1. 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.)

  2. It'd work on any distro thanks to flatpak-builder and the Flatpak runtimes being equivalent to the Docker build process.
  3. 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.)

  4. If distributed with default 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.
  5. 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.)

shakeyourbunny commented 2 years ago

Some suggestions for the Dockerfile:

@ssokolow an appimage would be even better for distribution. just a simple file with everything in it.

shakeyourbunny commented 2 years ago

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
shakeyourbunny commented 2 years ago

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.

acheronfail commented 2 years ago

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.

shakeyourbunny commented 2 years ago

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).

acheronfail commented 2 years ago

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:

acheronfail commented 2 years ago

@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.

ssokolow commented 2 years ago

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 .debs using checkinstall if Flatpak isn't an option and what's in the distro repos is unsuitably old.

  1. Appimage requires you to either bundle all your libraries or not be fully portable. APT/RPM and Flatpak both allow stuff shared with other packages. (Flatpak is built on top of OSTree and will do per-file deduplication both between different versions of the runtimes and between different packages that had to bundle the same library that was missing from the runtime.)
  2. 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.
  3. Appimage is, at best, comparable to APT/RPM as far as the annoyance involved in wrapping Firejail around it. Flatpak is sandboxed by default and Flatseal makes it easy to replace things like filesystem=host with grants specific to the folders you want to download into.
  4. For non-lgogdownloader things, you also need that extra tooling to avoid it being a hassle to integrate Appimages into the launcher.

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.

shakeyourbunny commented 2 years ago

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.

ssokolow commented 2 years ago

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.

shakeyourbunny commented 2 years ago

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.

ssokolow commented 2 years ago

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.

abhiaagarwal commented 4 months ago

@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

shakeyourbunny commented 4 months ago

@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.

abhiaagarwal commented 4 months ago

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.

shakeyourbunny commented 4 months ago

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.

abhiaagarwal commented 4 months ago

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.

shakeyourbunny commented 4 months ago

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".

shakeyourbunny commented 4 months ago

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.

abhiaagarwal commented 4 months ago

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.

ssokolow commented 4 months ago

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.

shakeyourbunny commented 4 months ago

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?

ssokolow commented 4 months ago

" 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.

abhiaagarwal commented 4 months ago

License gives you the right to do whatever (the fuck) you want, but consider renaming it as to avoid confusion

ssokolow commented 4 months ago

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.