Sigil on Linux
 

Good Morning:
I would like to know why in Linux there is no updated version of Sigil. Only version 0.99.
and I also want to know why there is no repository to update.
Thanks!

Take it up with your particular Linux flavor's repository maintainers. We don't actually maintain the Linux Sigil packages, but we do work with those maintainers when they have issues or reasonable requests. There are plenty of distros out there the offer quite recent versions of Sigil in their repositories. Unfortunately, some distros package management systems are a quagmire of slow-moving, overly bureaucratic processes that use "stability" as an excuse for maintaining mountains of ancient software. There's also a good deal of idealistic hair-pulling and teeth-gnashing over WebEngine that recent versions of Sigil require.

The bottom line is that any distro that has Qt5.9.5+ (including QtWebEngine), Python3.4+, and cmake 3.0+ in their repos could provide the latest version of Sigil if they wanted.

https://repology.org/project/sigil/versions

It has been my experience that most Sigil package maintainers are doing the best they can within the particular bureaucracy they have to work with.

I checked out a few of the mac repos listed there:

- MacPorts uses 1.5.1 but misses installing certifi, urllib3, and dulwich as python components
- HomeBrew just grabs and uses our official Mac binary from Releases

I does appear there are only a few truly functioning Linux distributions. I still have no idea why fedora is so far behind on the major distros.

I was pleasantly surprised to see 1.4.3 in Debian Stable Backports. ;)

But yeah... Fedora, and even Ubuntu to some degree, seem to be lagging considerably. Bigger, slower wheels grinding, I guess. Though last time I looked at the Fedora sigil package, there seemed to be an outright air of abandonment in my opinion. Ubuntu's a bit of a disappointment since I've tried really hard to make sure that the latest Sigil will build on Ubuntu 18.04 with stock components. They may finally get close about the time I have no choice but to target their next LTS version. Support for 18.04 is pretty tenous.

I've not checked out the Chocolatey Sigil package, yet. If they're using the official installer contents, it's probably all right. But if they're trying to maintain linux-like system versions of Qt5 and Python3 (that all other packages share), there's likely to be some plugin breakage.

I find it strange that fedora has trouble generating a recent Sigil package as long as they have QtWebengine support. Until I switched to Manjaro I used CentOS (free version of Redhat Enterprise) for builds and testing and it built Sigil almost out of the box after adding the latest Qt rpm package.

I often think we should adopt one on those newer disk image based App containers and build and release our own Linux version (with embedded python and Qt) for all those Linux dists that do not have active maintainers for Sigil. Did you ever try any of them?

I have looked into them, but usually got lost in what it actually took to create/maintain/update them and which would work best for the most distributions. I may have to revisit.

I took a look at flatpack, snap, and AppImage and of these, AppImage seemed to be the easiest to make, with the least overhead, and the no need for additional system level installation of tools.

What do you think?

The simplest solution is probably something like linuxdeployqt, shipped in a self-contained tarball.

A fairly elaborate solution would be to get into the distribution game yourself, via flatpak (please do not use snap, it's Ubuntu lockin nonsense, the server is proprietary, and not every distro ships it at all -- notably, Arch does not do so). Yes, flatpak and snap both constitute essentially an additional distribution layered on top of another one.

AppImage is basically just a fancy tarball with point and click support. It's a packaging tool, not a build tool, which is why it doesn't come with much in the way of system requirements.

https://bugzilla.redhat.com/show_bug.cgi?id=1724109

See the crickets chirping. A year ago in February the maintainer said that he managed to get qt5-webengine "built on ppc64le", and would start working on it... Then nothing.

Sounds like the maintainer just coincidentally uses a low-tier supported system that is having compilation issues with webengine and he can't get a build environment set up to test it on the primary arches?

It's all simple in theory, but putting together a build environment is the finicky part. Linuxdeployqt and the various AppImage creation tools are only "supported" on the oldest supported LTS (which is 14.04 on Ubuntu for 1 more year, and probably CentOS 6). But the latest QtWebEngine needs a minimum of gcc 5 to be able to build (14.04 comes with gcc 4.8). So if we want any kind of widespread compatibilty, we're probably looking at Ubuntu 16.04 as the very oldest supported systems. Then it's figuring out what the newest versions of Qt5/Python we can build with the stock libc we're stuck with on our chosen environment.

None of these things are impossible, by any means, but they are very tedious. The easiest part is building the AppDir and then turning linuxdeployqt loose on it. Getting a VM/Container/CI ready that will let us support anything earlier than 18.04 is the hard part. ;)

Actually, AppImage just uses a userspace mounted file system for each app so it could include Qt and Python in the image if we build both of them against a base system and run very much like Apple and Windows. With no outside support needed as long as it works with the real system glibc and kernel.

The AppImageAppKit exists on github and it is a very simple c program that should build on any system. So we could pick the oldest system (Ubuntu 18) and use it to build the AppKit tools and give it a test run.

Here is the link to AppImageKit:

https://github.com/AppImage/AppImageKit

On the ReadMe near the end there is a link to precompiled appimagetools that were already built on CentOS 6 and Ubuntu 14.4. So we should just beable to use those binaries to create a test package.

You can also get linuxdeployqt as an AppImage and use it to build a AppImage using Travis CI and trusty without having to keep an old ubuntu 14.4 build system VM around.

More here:

https://github.com/probonopd/linuxdeployqt

Yes. I did something very similar with my old binary rpm Sigil package. I ended up having to go pretty far down the rabbit hole of extra libs that needed to be included (and sometimes built with alternative configs to keep them from pulling the kitchen sink along with them) and still ended up with a version of Sigil that couldn't support sound/video. I drew the line at building/delivering gstreamer plugins with questionable licenses. ;)

I'd need to do some testing to see what all would need to be shipped in the image to have a fully working Sigil. And nothing short of a fully working Sigil with Qt5/Python versions that match the Windows/Mac packages would make sense to me. I don't think I'd try to tackle it without using linuxdeployqt to create the AppDir and/or the AppImage, though. It uses appimagetools.

Knock yourself out if you've got something you can use to create a test package. I probably won't be able to dive in before the weekend. :)

Unfortunately I am at my cottage for a couple of weeks and only have a laptop with no Linux VM or real linux around.

I agree, we keep it in sync with macOS and Windows with Qt 5.12.10 (plus our Qt patches) and Python 3.8.


As far as I can tell we may need to target Ubuntu 16 since Qt 5.12 seems to have that as a minimum requirement and Qt 5.9.5 will not support everything.

I may try and install a linux VM on my laptop just to play around with.

You can build your own gcc toolchain and qt userland, probably. The trick will be making sure that anything you don't build yourself, but instead pick up from the system, is old enough to support any target platform. Mostly that just means glibc.

I wonder if Kovid's bypy tool could help here? It already builds qt, python, etc.

I borrowed heavily from its predecessor (build-calibre, with Docker containers then) to build my linux Makeself Sigil installer on Ubuntu 14.04. There's probably some salvageable stuff there. https://github.com/dougmassay/pkg-sigil

The interesting thing is that Qt5 can actually be built statically (linking in qt plugins is weird though) but sadly not supported for webengine.

It would be a neat thought to be able to ship one exe file plus the sharedir... Sadly not to be...

I am running Debian/unstable and must note that the “current” Sigil 1.4.3 causes a crash on startup.
Terminal;
Error dialogue from Sigil:
Edit: Resolved
Today there was a update from nvidia driver and i did not reboot. After reboot Sigil works again. Sorry…

Is that the Debian unstable Sigil package, or did you compile Sigil yourself? If the former, you should check with the package maintainer. He's always been pretty accessible in the past.

The last time I saw that error on Linux (that prevented Sigil from launching), I actually had to "Pull a Windows" and shut down and reboot. I think my video driver kernel modules had updated at the same time Sigil had, or some such.

The package is from the Debian repository.

I've got a Debian Stable virtual machine that seems to install/run the 1.4.3 sigil package from buster-backports just fine. Might be a video driver issue. Did you try the reboot? I know that's foreign to linux users, but...

Yes, I rebooted (was really strange to me), see my edit in my first posting. Sigil worked fine after restart.

Gotcha... I missed the update to the post. Thanks for the update. Same thing happened to me on Arch with new nvidia drivers and Sigil. That's why I mentioned it. And yes... I always feel a little dirty and suggesting that Linux users should shut down and reboot! :o

But not knowing people's personal skill levels: telling someone to reboot is much easier than walking a neophyte through manually unloading/loading kernel modules. ;)

Rebooting is the only way to take advantage of improvements that are provided as kernel updates. It's perfectly reasonable to reboot sometimes to fix certain problems.

Windows is annoying because "did you try rebooting" is somehow supposed to be a solution to everything, from kernel updates to general windows userland updates, to "a program I installed says I have to reboot before I can use it", to "your computer is slow today, maybe you went too long without rebooting".

Compared to all that, "just reboot whenever the kernel or video drivers are updated" is a relief for how rare it is. Any other program can be reloaded by just... restarting the program or at *worst* logging out then back in which takes much less time than rebooting.