release automation needs?

[rakslice]

I don't know anything about how release engineering is done in this project, and I don't mean to impose, but is there some automation work you would like that would help with releases?

[alamminsalo]

Automated scripts for building installers upon committing to master would be great.

Windows: there's a installer script found in resources folder (orion-installer.iss). If that script could be automated via CI-job then that would be excellent. Of course it needs a pre-build task to compile the app and gather the required files under the installer package - static build of Qt with SSL would be great there

Mac: bit of a problem right now since I don't currently have a mac accessible, so I can't do release until then... There's some scripts inside distfiles folder, but I need to sort them out before they're any use

Linux: I've previously successfully built AppImage package in arch linux, this could be automated inside a docker container. I may have a look at that

[alamminsalo]

Also Qt Installer framework looks interesting and could be of use

[XenonPK]

Just a heads up on the appimage front. Orion is currently on the official OpenSUSE repos, and the open build service recently added the ability to generate appimages, you could branch the package and adapt it to generate appimages or even rpms/debs tailored to other distros?

[rakslice]

Travis CI's free offering has Mac nodes; it may be feasible to do mac builds on those

[rakslice]

https://github.com/alamminsalo/orion/pull/184

[ghost]

Orion is present in the AUR with multiple packages (stable and git version), since Arch users should be pretty familiar with using the AUR I think it's not a must to have prebuilt packages for Arch at least.

[ahjolinna]

@IdleGandalf : well arch and gentoo and alike distros are little bit different "thing" compare to the more "conventional" distros, so this doesn't matter on those as much. So now when it comes to prebuild version for the more "conventional" linux desktop I think orion should go with flatpak/snap/appimage instead of distro specific pkg's.

which one? that is a hard question: 1) snap, the more ubuntu, so will make it automatically popular (thing which does work on another distros), but ubuntu/canonical projects haven't had good mainstream backtrack lately, so I'm sceptical. 2) appimage, the RPM based distros favorite this (at least fedora and openSUSE) and obs does seem to support it so it would be easy to maintain it. 3) flatpak, is the freedesktop.org/XDG standard and there is now a steam pkgs of it (offical? cant say), and if valve/steam goes/is offically with flatpak then its highly likely that flatpak will become the most mainstream

my vote goes to the XDG standard aka flatpak

---

If I remember correctly both gnome and KDE support flatpak and snap...but not appimage

[WyohKnott]

There's a Fedora release here https://copr.fedorainfracloud.org/coprs/eclipseo/orion/

[probonopd]

Orion is currently on the official OpenSUSE repos, and the open build service recently added the ability to generate appimages

See https://git.io/obs-ai for more information on this. AppImage developers are usually on #AppImage on irc.freenode.net.

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

[alamminsalo]

I've set up the travis, appveyor integrations and they are currently working on tag creations

[rakslice]

The Windows builds currently at https://github.com/alamminsalo/orion/releases/tag/1.6.5 just exit on launch for me, I assume this is a Qt version issue; my AppVeyor config predated the new Qt 5.9-based version of Orion.

Updating the Appveyor config to use 5.9.3, the builds launch and the window displays normally, but video fails to play; with debug ouput on, I get

DirectShowPlayerService::doRender: Unresolved error code 0x80040218 (IDispatch error #24)

0x80040218 is VFW_E_CANNOT_RENDER "No combination of filters could be found to render the stream." (https://msdn.microsoft.com/en-us/library/windows/desktop/dd375623(v=vs.85).aspx). This usually indicates that a DirectShow codec corresponding to the stream format could not be found, however I am pretty sure I've used QtMultimedia builds successfully on this system before, so I don't understand what the issue is.

I'm using US regular non-N Windows 10 Pro 1709, with the feature Media Features -> Windows Media Player installed,