Binary for most Linux distributions

[probonopd]

On https://github.com/Sigil-Ebook/Sigil/releases binary downloads are made available for Windows and OS X but not for Linux. While referring users to "your OS's package management system" might help those who run the latest bleeding-edge version of Ubuntu, it won't help users of other less popular and/or less recent Linux distributions.

Hence I have generated an AppImage that should run on most 64-bit Linux distributions.

https://bintray.com/probono/AppImages/Sigil/_latestVersion#files

To use it on almost any 64-bit Linux distribution, simply download it, make it executable, and run it:

wget https://bintray.com/probono/AppImages/download_file?file_path=Sigil-0.9.5-x86_64.AppImage -O Sigil-0.9.5-x86_64.AppImage
chmod a+x Sigil-0.9.5-x86_64.AppImage
./Sigil-0.9.5-x86_64.AppImage

I have tested it on various distributions, including CentOS 6, Fedora 23, Ubuntu 16.04, and even the venerable Ubuntu 10.04.

Please note that in order to maximize compatibility also with older distributions, this AppImage has not been optimized for size.

In case you are curious how the AppImage was made: here is the recipe that was used to generate it.

[dougmassay]

While referring users to "your OS's package management system" might help those who run the latest bleeding-edge version of Ubuntu, it won't help users of other less popular and/or less recent Linux distributions.

Which is why we also provide fairly decent build instructions in the source docs folder.

You're free to provide unofficial binaries for Sigil (just as any distro is), but you're on your own in getting the word out about where to download them from. And we won't be able to provide support to users of your AppImage should they run into any bugs (unless the bugs can be duplicated with versions of Sigil built using the official instructions, of course).

I had a thread in Mobileread.com's Sigil subforum providing unofficial deb packages for older versions of Sigil for a long time. Perhaps you can create something similar for your binary.

EDIT: also... the Sigil plugin framework is broken/incomplete with your image. This is the output of the official test plugin: `Status: failed

Verify sys.path settings manually /tmp/.mount_Cgwg9d/usr/share/sigil/plugin_launchers/python /tmp/.mount_Cgwg9d/usr/lib/python3.5 /tmp/.mount_Cgwg9d/usr/lib/python3.5/plat-x86_64-linux-gnu /tmp/.mount_Cgwg9d/usr/lib/python3/dist-packages /usr/lib/python35.zip /usr/lib/python3.5 /usr/lib/python3.5/plat-x86_64-linux-gnu /usr/lib/python3.5/lib-dynload /home/dlmassay/.local/share/sigil-ebook/sigil/plugins/testplugin

Verifying proper Python packages are available Python Package: PIL Missing Python Package: cssselect Missing Python Package: cssutils Missing Python Package: html5lib Missing Python Package: lxml Found Python Package: regex Missing Python Package: chardet Missing Python Package: six Missing

Verifying Sigil Python Libraries can be found/loaded Sigil Python library: epub_utils Found Sigil Python library: quickparser Found Sigil Python library: compatibility_utils Found Sigil Python library: sigil_bs4 Found

Verifying Hunspell Spell Checking Hunspell en_US affix file and dictionary Missing Hunspell shared library Found Hunspell spellchecking works False

Verifying Sigil Gumbo Library operation Sigil Gumbo BS4 Adapter library Traceback (most recent call last): File "/tmp/.mount_Cgwg9d/usr/share/sigil/plugin_launchers/python/launcher.py", line 135, in launch self.exitcode = target_script.run(container) File "/home/dlmassay/.local/share/sigil-ebook/sigil/plugins/testplugin/plugin.py", line 182, in run import sigil_gumbo_bs4_adapter as gumbo_bs4 File "/tmp/.mount_Cgwg9d/usr/share/sigil/plugin_launchers/python/sigil_gumbo_bs4_adapter.py", line 35, in import sigil_gumboc as gumboc File "/tmp/.mount_Cgwg9d/usr/share/sigil/plugin_launchers/python/sigil_gumboc.py", line 161, in SourcePosition.EMPTY = SourcePosition.in_dll(_dll, 'kGumboEmptySourcePosition') ValueError: /usr/bin/python3: undefined symbol: kGumboEmptySourcePosition Error: /usr/bin/python3: undefined symbol: kGumboEmptySourcePosition`

[probonopd]

You're free to provide unofficial binaries for Sigil (just as any distro is), but you're on your own in getting the word out about where to download them from.

Would you be interesting in having an official Linux build, e.g., if it was done 1:1 by following your build instructions? Like you do for OS X and Windows? If not, what is the reason and how could it be overcome?

This is the output of the official test plugin: Status: failed

Thanks for pointing me to the test plugin. Fixed the missing packages errors by bundling the Python packages PIL, cssselect, cssutils, html5lib, regex, chardet, six.

Also, I noted the line

bundled_python3_path = QCoreApplication::applicationDirPath() + "/python3/bin/sigil-python3";

So if I am bundling Python (which I am) then I am likely supposed to put it there, however symlinking it to ./usr/lib/sigil/python3/bin/sigil-python3 doesn't seem to work for me.

[mapreri]

On Sat, May 28, 2016 at 01:55:37PM -0700, probonopd wrote:

Would you be interesting in having an official Linux build, e.g., if it was done 1:1 by following your build instructions? Like you do for OS X and Windows? If not, what is the reason and how could it be overcome? [...] Thanks for pointing me to the test plugin. It looks like I need to bundle the Python packages PIL, cssselect, cssutils, html5lib, regex, chardet, six? [...] So if I am bundling Python (which I am)

There is a reason no real linux distribution bundles things inside a package (mainly, security reasons); And not bundling things means a different build is needed for different releases for different distribution due to different toolchains. That's about how linux distribution works, more or less.

IMHO, if a recently enough release of some distribution that already ships sigil by its own wants a more recent sigil release, they should just backport it. (that said, with my ubuntu maintainer hat I say people are welcome to do it, but I'm not going to get involved into ubuntu backports.

Anyway, I'm not from the sigil team, and I know they are not too much welcoming towards linux things (understandably: for medium-sized project like this, with a very small number of contributors and only one real "full-time" developer, keeping up with all the little differences between the distributions, and supporting the different methods of building things, etc, etc, is hard, I acknowledge that), so don't consider my message more than a mere comment from a user (better: from a distribution developer, probably a user wouldn't really care/know).

[probonopd]

keeping up with all the little differences between the distributions, and supporting the different methods of building things, etc, etc, is hard

This is exactly why I am suggesting AppImage. Projects like Krita, MuseScore, and Scribus have already adopted it as a means to distribute recent binaries to users for the various Linux distributions for exactly this reason.

[kevinhendricks]

The sigil gumbo test in the testplugin failed which means the python ctypes interface could not find the libsigilgumbo.so or the build/toolchain being used to build that Sigil internal library did not properly include all symbols, as you have a missing symbol error.

[dougmassay]

Anyway, I'm not from the sigil team, and I know they are not too much welcoming towards linux things (understandably: for medium-sized project like this, with a very small number of contributors and only one real "full-time" developer, keeping up with all the little differences between the distributions, and supporting the different methods of building things, etc, etc, is hard, I acknowledge that)

I take offense to that (OK, not really, but still! ;) ). I'm very welcoming towards linux things. I do my development and testing on linux. I am primarily a linux user. I love linux. I just don't feel any particular need to strictly adhere to the prevailing "that's just how we do things here in linux-land" dogma.

@probonopd

As to an "official" Linux binary/bundle. I'm just not all that interested anymore, to tell you the truth. The line between "including the kitchen sink" and "a broken mess" is too fine for me. We're starting to see Sigil appear in more and more repos now, and as @maprei mentioned; back-porting is always possible. I'd rather leave the binaries to the repos and focus on adding features to Sigil in a way that doesn't make their jobs too, too hard.

[probonopd]

The sigil gumbo test in the testplugin failed which means the python ctypes interface could not find the libsigilgumbo.so or the build/toolchain being used to build that Sigil internal library did not properly include all symbols, as you have a missing symbol error.

Thanks @kevinhendricks I seem to get around that using export LD_PRELOAD=./lib/sigil/libsigilgumbo.so so the .so seems fine but it doesn't appear to get loaded correctly somehow.

[probonopd]

Down to 3 remaining hunspell errors. Seemingly tries to access .local/share/sigil-ebook/sigil/hunspell_dictionaries but there is nothing there.

[dougmassay]

@> Thanks @kevinhendricks I seem to get around that using export LD_PRELOAD=./lib/sigil/libsigilgumbo.so so the .so seems fine but it doesn't appear to get loaded correctly somehow.

The embedded Python is able to use gumbo OK, so your relocation of the libsigilgumbo shared library is probably tripping up the python plugin routines that attempt to locate it. On Linux, the Python plugin framework expects libsigilgumbo.so to be in the same directory as the sigil binary (/usr/local/lib/sigil/ by default)

Down to 3 remaining hunspell errors. Seemingly tries to access .local/share/sigil-ebook/sigil/hunspell_dictionaries but there is nothing there.

That's just the last place Sigil looks for dictionaries. If the test plugin is failing there, then the python framework can't find the any hunspell dictionaries is any of the places it's configured to look. Set the runtime SIGIL_DICTIONARIES environment variable to wherever you've put the dictionaries in your image's tmp file system (or use SIGIL_EXTRA_ROOT if you've relocated all of Sigil's support ("share") files.

[mapreri]

On Sat, May 28, 2016 at 02:35:21PM -0700, Doug Massay wrote:

I take offense to that (OK, not really, but still! ;) ).

uops! Sorry, I had/have no reason to offend anybody with that.

I'm very welcoming towards linux things.

I was clearly mainly referring to user_none (and for by far less extent to kevin).

I just don't feel any particular need to strictly adhere to the prevailing [...] dogma.

somehow (not sure how), I ended up in the fairly extreme wing indeed :)

back-porting is always possible.

until you start requiring a new Qt. That's e.g. why the current development version of scribus can't run on ubuntu 14.04 anymore (unless you backport Qt, which I find a dangerous business, which goes against my definition of "stable")

[dougmassay]

Keep in mind that user_none has retired from the Sigil project.

And no, I wasn't really offended. I realize there was was some tension/resentment between Sigil and Linux for a long time. Hopefully that can change (as long as we devs and the repo maintainers can try to find some middle-ground).

As far as Qt goes, we're only seeing an exchange of old bugs for new bugs (and some of the old ones still hanging around for good measure) with Qt 5.5+. So we're not feeling any compelling need to move toward requiring the newest versions of Qt5 right now. The plan is to stick with 5.4.2 as the minimum Qt requirement for as long as possible (though people are welcome to build with newer versions that don't remove support for QtWebKit if they can verify they don't cause any Sigil issues).

I'd like nothing better than to see stable versions of Sigil popping up in as many distro's repos as possible.

[probonopd]

until you start requiring a new Qt. That's e.g. why the current development version of scribus can't run on ubuntu 14.04 anymore

@mapreri ...or unless you use the Scribus AppImage. In that case, the latest bleeding-edge version runs on Ubuntu 14.04 just fine (heck, even on CentOS 6) because it comes with its own bundled Qt so that your system doesn't become less stable in any way. The absolute worst thing that could happen is that Scribus itself could be unstable, but hey, it's a development version after all. This is why the format is especially well suited for nightly or continuous builds which you can run in a "non-committal" way.

[kevinhendricks]

@mapreri

I was clearly mainly referring to user_none (and for by far less extent to kevin).

Hey, I resemble that remark!! ;) I actually am a longtime linux user and developer and early unix adopter, after MicroVaxs and DEC disappeared. I was part of the original Blackdown project to port the Java virtual machine to Linux, I helped write all of the C/C++ bridge code used in the OpenOffice.org object model for Linux PPC (I hated their ABI but ..), contributed radeon graphics driver and ppc linux fixes to the Linux kernel, contributed a small bit to glibc support for linux ppc, created MySpell that was later absorbed by hunspell, and MyThesaurus for OOorg lingucomponent project, helped Apple port the first Mach microkernel to Linux (pre OSX), and finally I still use it almost every day for my number crunching and research (using Centos 6).

My issue with linux has always been the need to rebuild the entire OS system and userland just to up update a package, the lack of any true standards, multiple desktop non-sense and all it entails, different distribution package managers for no truly good reason, the entire emacs vs vi debate (obviously emacs is better!), KDE vs gnome nonsense, etc and etc. And finally when Mac OSX came out and it gave me a nice unix base with a great gui, I moved to Mac.

I am not anti-linux in any way. I just got frustrated after about 30 years and found I wanted a unix that just worked with no fiddling and no nonsense so I could actually get real work done and never have to re-istall my OS every few months.

@probonopd

If this AppImage approach can work without generating a lot of bug report noise and is not huge (50 meg or so compressed), I am not against it in any way. That said, I do not want to advertize or post binaries that I can not trust as something "official". Distribution official repos I can trust as they are signed and backed by a linux distribution. That is also the reason I sign the Mac OSX builds and register as an Apple Developer. So I not sure how to deal with that. So I am with Doug here. If you want to create and post them youself someplace, and support them, I am okay with that. We just can't/won't do that.

Now if someone instead wanted to join the Sigil developer team officially and pledged to create new builds for each and every release using these AppImages and tracked down and fixed Sigil bugs on Linux, and maybe even added a few new features to Sigil and helps out, that might change our minds.

[mapreri]

On Sat, May 28, 2016 at 04:40:10PM -0700, Kevin Hendricks wrote:

I actually am a longtime [...]

I was truly very shocked when I first discovered that on year ago or something, but even if you are a unix/linux (as a platform) lover you:

My issue with linux has always been the [...]

are against all of these :)

the lack of any true standards

somebody (me? :P) may say that there are standards, just that due to the very nature of this business there is no central "authority" stating what standards are in place. Great example: FHS can be called a standard, but you can't rely on that as somebody doesn't care, and create a distro that doesn't follow it.

the entire emacs vs vi debate (obviously emacs is better!)

emh... /me just looks away for this time... :>

and never have to re-istall my OS every few months just to get needed updates.

Not sure if 20odds years ago this was needed, but I'm confided nobdy did a reinstall "just to get needed updates" in the last 10 years (unless you are running ubuntu and installing from random 3rd parties repositories that mess up with your system and makes the fragile upgrade path cramble down, but probably if you install stuff from random places you got to hold the pieces…)

Now if someone instead wanted to join the Sigil developer team officially and pledged to create new builds for each and every release using these AppImages and tracked down and fixed Sigil bugs on Linux, and maybe even added a few new features to Sigil and helps out, that might change our minds.

please go to your near shop and buy some spare time for me!

[probonopd]

Just for curiosity, I tried how far compatibility of this AppImage can go. In this case, since I am bundling essentially "everything", it even runs on "Slacko64 Puppy 6.3.0" slacko64-6.3.0.iso, a distro that would probably never get a chance to see a native package... ;-)

One can also do more conservative AppImages that bundle less (more like the OS X and Windows bundles), this will decrease the bundle size, but then certain basic libraries are assumed to be "just there" in the base system.

[kevinhendricks]

@mapreri

Not sure if 20odds years ago this was needed, but I'm confided nobdy did a reinstall "just to get needed updates" in the last 10 years (unless you are running ubuntu and installing from random 3rd parties repositories that mess up with your system and makes the fragile upgrade path cramble down, but probably if you install stuff from random places you got to hold the pieces…)

Yes, it was much worse 20 years ago especially for linux ppc. There were few distributions that supported it (YellowDog Linux and Caldera come to mind) but neither the glibc nor the gcc binutils toolchain was stable for ppc yet. So lots of packages had to be compiled from source and whole distro upgrades were common due to changes in glibc/gcc/binutils toolchains to mainly deal with how ppc handled atomic operations needed for threads, and the like. Linux x86 was probably much better. I did move over to x86 and Redhat (release 7) eventually but then shortly after Redhat moved to their fast release cycle with lots of unstable packages and so I moved to RedHat Enterprise LInux and then when they started to charge educational users, the final move was to Centos which I only use via ssh (no gui) and for running older compiler toolchains needed to work with old binaries from commercial datasets such as CRSP (security prices for stocks from Univ. of Chicago).

I am sure life has been better over the last 10 years about package availability but back then, installing a later point release often required a full blown install.

[probonopd]

@dougmassay this was closed, so I assume the Sigil project is not interested in providing an upstream packaged AppImage.

For interested users, I will keep one available at https://bintray.com/probono/AppImages/Sigil/_latestVersion#files

[kevinhendricks]

No we are not.

• our developer team is too small to make and support them
• we can not promote an untrusted binary from a third party site from our site
• official linux distribution packages are now available and easy to install
• it is not hard to build Sigil from source on Linux Mint/Ubuntu, ArchLinux, etc

[eli-schwartz]

It seems the primary justification for providing such a package is for the sake of Ubuntu LTS users and the like -- people running old stable releases. Such people are surely used to having outdated software, in fact I was under the impression that that is rather the point. Outdated software has been "tested". :wink:

It's not really odd to expect linux distros to provide your software, in fact downloading trusted binaries from a distribution repository is a great advantage over Windows. And the latest version of Sigil can now be found in the stable releases of Arch, Debian, and Ubuntu (Fedora has 0.9.3). So everyone who wants current software releases can get them -- and the people who chose an obscure distro which doesn't provide them are likely also knowledgeable enough to build it from source and/or help their distro support more software (which might help them with their obscurity issue :smiley:).

...

So I am not sure why this should be Kevin and Doug's problem.

[probonopd]

Well, if you see a distribution as something that is supposed to include every application on earth in the always latest version, then good luck. This is not how desktops work and one reason why Linux on the desktop still doesn't have the market share. You could also see a distribution as a platform to run a wealth of third-party software on top of. This is how I see distributions.

To the developer, binaries without the source code are useless. But to the user, source code without the binaries is useless.

So, to answer your question: For the same reason that Firefox or Atom or you name it provide binaries on their homepages. But I guess this topic has been closed as there is no interest from the maintainers to do that.

[eli-schwartz]

Firefox has a rather large development team. :wink: So does Atom in addition to being backed by a corporation, AND being nodejs-based.

They have extra time on their hands, and don't have to rely on distros doing their job.

(P.S. I don't need good luck, I run Arch. :p And that isn't the reason for low market share either. But all that is beside the point. Which is that binaries are provided by the people who have both time and interest, and the maintainers have neither.)