[Linux] FlightCrew Plugin don't works with 0.9.0

[eschwartz]

Originally Posted by mapreri@DebBug804887

FYI I do use sigil, and I firstly packaged and now maintain it in Debian
only because I needed (ans still need) it.

I'm sorry that upstream sigil developers are so little tolerant towards
linux distributions I fully understand their position, but still this
makes me sad.

Bonus points for being ontopic when discussing what is clearly a packaging bug.

And my $0.02 as an innocent bystander is that Debian has NO right to complain about the attitude of upstream, considering how long it took them to finish complaining about inscrutable licensing issues without ever having mentioned anything upstream.

[DiapDealer]

Originally Posted by eschwartz

Bonus points for being ontopic when discussing what is clearly a packaging bug.

And my $0.02 as an innocent bystander is that Debian has NO right to complain about the attitude of upstream, considering how long it took them to finish complaining about inscrutable licensing issues without ever having mentioned anything upstream.

My conscience is clear. Everything mapreri's asked for since Kevin and I took over, I feel we've made every effort to grant. And I'll continue to try and meet Linux packagers needs--especially if they make them known. I may not do things exactly the way they want things done, but I'll make every effort to accommodate them in some way. I want Sigil in the repos if at all possible.

[KevinH]

Hi FWIW,

I looked at the Debian auto build system results for Sigil 0.9.0 and for almost all failing packages, a suitable version of python 3 can not be found and so cmake fails. In other words, the build never started. So whomever is setting up those autobuild systems needs to make sure python3 can be found in the PATH in order for the build to actually have a chance to complete.

Also, I looked at the list of package requirements for Sigil-0.9.0 and many are incorrect. Sigil 0.9.0 no longer uses boost at all, no longer uses Xerces, no longer uses Tidy, etc, etc. so none of those package requirements are needed anymore.

The packagers probably should start from scratch for the Sigil-0.9.X series (throwing out everything from Sigil 0.8.X and earlier when it comes to requirements) and simply follow the official Linux build instructions while passing in a few extra CMAKE flags to use external versions of many packages.

And I agree with DiapDealer here. We are both happy to help Linux packagers and have done everything requested so far (our preferred version of it). But if additional modifications are made by packagers, then they must be the first point of contact for bugs.

I think, one approach might be to follow Kovid's/Calibre example and make our own official builds for Linux with everything bundled in (ie. standalone) and then the packagers could use it to test for bugs submitted to them, and pass along any to us that occur with our official builds.

Anyway, both DiapDealer and I, would like to improve relationships with all Linux packagers and try and get them all working from our main tree and not 5 different sets of patches/trees flying around. As far as I can tell, Sigil-0.9.X should build with no modifications at all on most Linux platforms with recent compiler tools and the build is relatively straightforward. If that is not true, then please let us know.

KevinH

[Doitsu]

Originally Posted by KevinH

As far as I can tell, Sigil-0.9.X should build with no modifications at all on most Linux platforms with recent compiler tools and the build is relatively straightforward.

Sigil builds fine on my Debian 8* machine without any modifications. I only installed the packages that DiapDealer listed in the build instructions and everything went smoothly.

* Debian 8 (AKA "Jessie") is the current stable Debian version.

[eschwartz]

I'm running the Arch User Repository build written by me: https://aur.archlinux.org/cgit/aur.g...LD?h=sigil-git

(Also I've filed a bugreport on the ArchLinux bugtracker to update the community sigil package with those changes. Quite surprisingly, for Arch anyway, it's been a few days and we still didn't get the update. )
Never did figure out why qt5-multimedia was listed as a build dependency?

[KevinH]

Hi eschwartz

Originally Posted by eschwartz

Never did figure out why qt5-multimedia was listed as a build dependency?

Just a guess but on Mac OS X you need the Qt multimedia plugins for audio and video in the epub to work. Not sure exactly what is in the qt5-multimedia package on Linux but it sounds similar.

KevinH

[eschwartz]

But surely in that case it should be an install dependency not a build dependency...

gah. videos in EPUBs.

...

I once got an ebook that turned out to be "enhanced" with a click-to-play audio button at the beginning. (Maybe because it was a short story they were trying to make it more "interesting".)

It played just fine in calibre's ebook-viewer, no qt5-multimedia at build or install...

But once I realized it was there, I edited it to delete it.
I never bother to check that kind of stuff I regard it as an unhappy coincidence.

[eschwartz]

Added:
Sigil never linked to libQt5Multimedia*.so
src/CMake,,Lists.txt:66 -- no mention of Multimedia in Sigil's required components.
I checked the git log in pickaxe mode to try to find mentions of it, didn't find anything.

Surely just displaying them would be part of qt5-webkit?


Anyway, 4MB save without it, so, win.

[KevinH]

Be careful, it may be a Qt plugin which is not directly linked but is dlopened only when needed. There is a tool called macdeployqt that we use to determine all of the Qt pieces we need to include on Mac OSX. There is a similar Qt deploy tool for Windows now as well.

Take care,

KevinH

[DiapDealer]

And both windeployqt and macdeployqt insist on including Qt5Multimedia(Widgets) when packaging Sigil. So until Linux comes up with it's own linuxdeployqt program ("he said; knowing it will be never"), I'm going to play it safe.

[KevinH]

Check out the latest issue/bug at Sigil (just closed by me).

Incredibly the packagers are now upset that Sigil uses a launch script that sets environment vars! I guess if using environment vars and scripts are "so 80s and a bad idea", then Linux users must now stop using PATH, or init.d or KDE Desktop, or Qt or ... as they all do the same thing. Complete silliness.

Using a install paradigm designed in the 70s, with virtually no standards, no way to have private shared libs or resources, no code signing or verification of apps on launch, no real way to limit app resourcs, pieces installed all over the place, no app containers, etc and yet they complain about scripts using environments vars.

You gotta love all of the different biases of all of the different packagers for linux. It seems you can never make them all happy.... no wonder user_none finally through in the towel when it came to supporting linux.

[DiapDealer]

I'm all for taking care of reasonable requests, but I must admit; I weary of the "please restructure your cross-platform application, so that it meets the philosophical (not functional) needs of a third-party redistributor of software for one of those platforms" sort of demands/lectures.

Things would obviously be different if Sigil was a Linux-only application, but it's not. It's intended to build/run reasonably well (and similarly) on three different platforms from the same codebase. Because of this, concessions must be made--by everyone.

I'll still consider respectful, reasonable (functionality-based) requests--and even philosophically-based requests that can be easily/quickly achieved with a minimum of code impact. But condescending "please change because this is how you should be doing things anyway" lectures aren't going to fly anymore. I won't be bullied. It's not my job to make their jobs effortless. They'll just have to settle for me being willing to make sure their job is possible.

[eschwartz]

Sigh. I think that is totally my fault.

I submitted a bugreport for ArchLinux with an updated PKGBUILD for Sigil 0.9.0 -- it included the USE_SYSTEM_LIBS option.

I guess they only just realized Sigil even had bundled libs.
Which is not really anyone's fault.

At least, now that Sigil includes documentation for that feature, which IIRC was so totally not the case when they packaged Sigil, on account of there was no BuildingOnLinux.md and even that didn't mention it until prompted by my mostly-unrelated PR.


But thanks for doing what you do for making it easier I really do appreciate it.


P.S. I don't like the launch scrip myself. But I accept it as a necessity, one which serves a valid purpose.

[mapreri]

Hi there! (don't worry, I won't lurk around here (really no time for also this, sorry), I'm just reading this post since it's linked in that debian bug)

Originally Posted by KevinH

I looked at the Debian auto build system results for Sigil 0.9.0 and for almost all failing packages, a suitable version of python 3 can not be found and so cmake fails. In other words, the build never started. So whomever is setting up those autobuild systems needs to make sure python3 can be found in the PATH in order for the build to actually have a chance to complete.

Actually the problem is that sigil has a buggy FindPythonLibs.cmake that is only able to discover libpython3.4m.so (or whatever) only amd64 and i386. In Debian we do multiarch, so libraries are in /usr/lib/<GNU arch triplet>, e.g. for arm64 is '/usr/lib/aarch64-linux-gnu/libpython3.4m.so'. Anyway, I made up a simple patch for that and seems everything builds now. I'm not sure if this is the correct approach, once I convince myself it is I'll open a PR

Originally Posted by KevinH

Also, I looked at the list of package requirements for Sigil-0.9.0 and many are incorrect. Sigil 0.9.0 no longer uses boost at all, no longer uses Xerces, no longer uses Tidy, etc, etc. so none of those package requirements are needed anymore.

https://anonscm.debian.org/cgit/coll...78151bc550ef8e (for the next upload, I read this thread right after uploading the package...)

Originally Posted by KevinH

The packagers probably should start from scratch for the Sigil-0.9.X series (throwing out everything from Sigil 0.8.X and earlier when it comes to requirements) and simply follow the official Linux build instructions while passing in a few extra CMAKE flags to use external versions of many packages.

when it comes to compiling the list of build-dependencies it's a laborius work made of trials and error (= we build in a clean chroot, if it doesn't build we add a build dep, and retry. repeat), removing them is boring.
Usually they don't affect end users, since the actual dependencies are generally evaluated on the final binaries, looking at which shared libs the binaries link to.

Originally Posted by KevinH

And I agree with DiapDealer here. We are both happy to help Linux packagers and have done everything requested so far (our preferred version of it). But if additional modifications are made by packagers, then they must be the first point of contact for bugs.

I just simple agree.
We often add local patches, usually harmless, but from time to time we also do some more.
This particular case is a missing dependencies (I think), since I managed to reproduce the error once I remove that package.
https://anonscm.debian.org/cgit/coll...01b378ebbeb267

Originally Posted by KevinH

Anyway, both DiapDealer and I, would like to improve relationships with all Linux packagers and try and get them all working from our main tree and not 5 different sets of patches/trees flying around.

Thanks. Really, this means a lot for me.

Originally Posted by KevinH

As far as I can tell, Sigil-0.9.X should build with no modifications at all on most Linux platforms with recent compiler tools and the build is relatively straightforward.

Yes, it does! (except on those exotic architectures that Debian supports... most of the time they are just good as a target for curses, but they are also good as a exercise)
Be assured, I strive to have 0-patches, they can also cause troubles to us, since they need merges, etc

[DiapDealer]

Originally Posted by mapreri

Actually the problem is that sigil has a buggy FindPythonLibs.cmake that is only able to discover libpython3.4m.so (or whatever) only amd64 and i386. In Debian we do multiarch, so libraries are in /usr/lib/<GNU arch triplet>, e.g. for arm64 is '/usr/lib/aarch64-linux-gnu/libpython3.4m.so'. Anyway, I made up a simple patch for that and seems everything builds now. I'm not sure if this is the correct approach, once I convince myself it is I'll open a PR

Please note that there are cmake instuctions that can be used to specify the exact libpython and python include files you want sigil to link against. These are documented in the BuildingOnLinux document(s) in the docs directory.

I already modified the FindPythonLibs.cmake file to include the two main multi-arch <GNU arch triplet> locations. It wasn't finding ANY of the distro-installed libpythons prior to that. If we can beef up that cmake file to include even more architectures, I'd be happy to incorporate those changes into the original source--when you're ready to make a pull request.