Difficulty with building sigil 0.9.0 on linux

[philja]

My original comment was on the thread about Unofficial Sigil Ubuntu-ish binary packages where I expressed my pleasure in recovering from a disappointing build experience by finding the pre-compiled deb package for 0.8.6.

I had been following the quite detailed instructions on the sigil site in BuildingOnLinux.md to install sigil on a 32 bit laptop running Debian Jessie 8.2. I had checked and installed all missing dependencies listed and the first failure was on the "sudo pip3 install lxml" where the pip.log states : "/usr/bin/ld: cannot find -lz"

Not having a great deal of experience on linux, I didn't know where to go from there and while searching found the pre-compiled package for sigil0.8.6 which I had running inside 10 minutes and with which I have already modified the ncx in my first epub on my work machine.

DiapDealer suggested that a good place to continue with 0.9.0 would be to install the zlib1g-dev package.

I installed zlib1g-dev and the pip3 install lxml then completed.

I moved on to the next stage running :

cmake -G "Unix Makefiles" -DCMAKE_PREFIX_PATH=/opt/Qt5.4.2/5.4/gcc/lib/cmake -DCMAKE_BUILD_TYPE=Release ../sigil-src

This failed with a message "Failed to find"GL/gl.h" in "usr/include/libdrm" which raises the spectre of another missing dependency.

It is true that I do not have a "usr/include/libdrm/GL/".

So, please, what is GL and which package would that come from ?

[DiapDealer]

OpenGL development header missing, most likely. Probably needed by Qt5's OpenGL library. Newer proprietary video drivers often don't include header files.

Try "sudo apt-get install mesa-common-dev" and see if that clears it up.

[eschwartz]

Debian traditionally splits the development headers needed for compiling from the runtime libraries.

The official build control file lists the following build dependencies:

Build-Depends: cmake (>= 3.0.0),
               debhelper (>= 9),
               libhunspell-dev,
               libjs-jquery,
               libjs-jquery-scrollto,
               libminizip-dev,
               libpcre3-dev (>= 2:8.35-4),
               libqt5svg5-dev (>= 5.4.0),
               libqt5webkit5-dev (>= 5.4.0),
               libqt5xmlpatterns5-dev (>= 5.4.0),
               pkg-config,
               python3.4-dev,
               qtbase5-dev (>= 5.4.0),
               qttools5-dev (>= 5.4.0),
               qttools5-dev-tools (>= 5.4.0),
               zlib1g-dev

Which pulls in mesa-common-dev via the dependency chain for qtbase5-dev.


What works for them will probably work for you.

[dhdurgee]

If you would not mind a suggestion, at least one other package I have built from source on my linux system included a "cvslvlck" script in its util directory that when run reports any required libraries that are either missing or too old to build the package with. Perhaps a similar script could be added here to allow the user to confirm they are ready to attempt a build without the need of making sense of the error messages issued during a failed build attempt.

Dave

[DiapDealer]

Originally Posted by dhdurgee

If you would not mind a suggestion, at least one other package I have built from source on my linux system included a "cvslvlck" script in its util directory that when run reports any required libraries that are either missing or too old to build the package with. Perhaps a similar script could be added here to allow the user to confirm they are ready to attempt a build without the need of making sense of the error messages issued during a failed build attempt.

That is rare and wonderful thing you experienced.
But I'd have no idea how to go about making it happen.I don't know how to look for what I don't know is needed; let alone if it might be might be missing. And as the OP is finding out, the library that might be missing rarely tells someone what package it might be a part of in their distro's repositories.

[eschwartz]

Someone who is building from source might want to get acquainted with the minutiae of their package manager.

[eschwartz@arch ~]$ pacman -Qo /usr/include/GL/gl.h
/usr/include/GL/gl.h is owned by mesa 11.0.6-1

I am sure debian must have some similar command.

And a script that checks for needed libraries could wrap the search feature of various package managers.

...

Of course, as you say, knowing what to check for is a feat all of its own.

[DiapDealer]

It's possible that the libdrm-dev package could be the one that's needed, too. I'd probably take the "clobber" route and install the freeglut3-dev package (and everything it pulls in) and be done.

[philja]

Thanks to all who responded. Installing the mesa-common-dev package solved everything.

I know the old lap top I use for these experiments is slow (32 bit Dell recovered from a friend who had Windows XP on it), but the 'make' alone took longer to complete than it took me yesterday to find, download, install and get running the pre-compiled deb package.

Anyway, sigil 0.9.0 is now running on that laptop and I'll spend a little time to see how it goes before deciding whether I want to go thro all this again with my desktop mc.

I've already remade and improved my first epub book (originally fashioned using Calibre and its html editor) on sigil0.8.6 and I can see what a useful production tool sigil can be.

I've been using linux just over a year and I've built a few bits of software. It's certain that I know a lot more now than I did a year ago but there's a long way to go, I'm sure. Although there is a certain satisfaction when an applications gets built successfully, this is tempered by the realization of the time it takes because however detailed the instructions are, there has always been something missing.

Thanks again for all the contributions.

[DiapDealer]

Glad you had the patience to get it going! And thanks for sharing your experience. Now when next I update the BuildingOnLinux document, I'll be able to include some notes like; "if you should get an error like XXX you may need to install package YYY."

[philja]

I've tried to use the next section in the BuildingOnLinux.md document "Testing Sigil's Python plugin framework" but can't get the 6 steps in that paragraph to work as described.

The Plugins/Manage Plugins menu 'Add plugin' button refuses to load testplugin_v010.zip with a Sigil error "Plugin not a valid Sigil plugin". (The Xarchiver won't touch this file either but I can read it in a text editor.)

I did download and install the FlightCrew plugin and this works ok.

Step 5 in the testing para refers to Plugins->Manage Plugins ->Edit but I don't see any edit option in the ManagePlugins dialogue.

In Sigil 0.9.0, the F7 key and the big green arrow on the tool bar activate a "SanityCheck' function rather than FlightCrew. I can get FlightCrew to work via Plugins/Validation/FlightCrew. Can F7 and the big green arrow be reassigned to FlightCrew or is that facility lost in 0.9.0 ?

[eschwartz]

Originally Posted by philja

Thanks to all who responded. Installing the mesa-common-dev package solved everything.

I know the old lap top I use for these experiments is slow (32 bit Dell recovered from a friend who had Windows XP on it), but the 'make' alone took longer to complete than it took me yesterday to find, download, install and get running the pre-compiled deb package.

I hear ya.
This 11-year-old 32-bit Dell one-time XP laptop is running ArchLinux these days.

I find that software in the repos tends to be more up-to-date on ArchLinux, sometimes by a significant amount.

Anyway, sigil 0.9.0 is now running on that laptop and I'll spend a little time to see how it goes before deciding whether I want to go thro all this again with my desktop mc.

I've already remade and improved my first epub book (originally fashioned using Calibre and its html editor) on sigil0.8.6 and I can see what a useful production tool sigil can be.

I've been using linux just over a year and I've built a few bits of software. It's certain that I know a lot more now than I did a year ago but there's a long way to go, I'm sure. Although there is a certain satisfaction when an applications gets built successfully, this is tempered by the realization of the time it takes because however detailed the instructions are, there has always been something missing.

Thanks again for all the contributions.

Building it yourself does give a certain satisfaction.
But working out how isn't nearly as fun. Fortunately, ArchLinux has a User Repository with instructions for building most things that aren't in the repos, and it is simple to manage -- although compiling still takes time.

You also don't have to mess around with split development packages.

I maintain the PKGBUILD for sigil-from-git.



...

I will admit, ArchLinux isn't for everyone -- but it's a good way to gain a lot of familiarity with how linux works -- assuming one is interested enough to mess around that deep.

[Turtle91]

I do like "messing" with computers...build my own, can program a fair bit, etc. I've even looked at linux to run a fileserver. I don't understand the benefit of "building" your own software. It seems like a bit of a hassle but I'm sure there must be a plus side to it. Could someone please enlighten me??

[eschwartz]

Originally Posted by Turtle91

I do like "messing" with computers...build my own, can program a fair bit, etc. I've even looked at linux to run a fileserver. I don't understand the benefit of "building" your own software. It seems like a bit of a hassle but I'm sure there must be a plus side to it. Could someone please enlighten me??

I like linux for various reasons, but Debian and most other distros lag terribly in pushing updated versions of non-security-critical software.

And the few that keep up to date basically boil down to Gentoo and Arch.
Arch doesn't always carry pre-compiled software -- it depends how popular it is and whether a Trusted User sponsors it.
Gentoo is fundamentally built around the idea of building everything yourself. You can tune it to work exactly the way you want, but it takes a lot of time.


Evolution of a linux user: http://www.explainxkcd.com/wiki/inde...56:_Cautionary

[KevinH]

Hi philja,
The testplugin.zip requires Python 3.4 or later. The flghtcrew plugin runs on either Python 2.7 or python 3. My guess is you have only set the path to the python 2.7 interpreter.

Try going to Plugins->Manage Plugins and try using auto on the Python 3.4 interpreter path and if needed browse to find it. Once you have set the Python 3.4 interpreter path you should be able to load and run the testplugin.

KevinH

[KevinH]

philja,

Sigil-0.9.0 is the first step in working towards adding epub3 support. Since FlightCrew is epub2 only and therefore of no use for epub3 users, we decided to move it to a plugin. The user can then choose to use flightcrew or epubcheck as a validator. Sanitycheck simply checks for parseability which can work no matter if epub3 or epub2.

At some future point, we hope to add 5 user-assignable buttons to launch their most frequently used plugins. But that is down the road a ways. Next step is to try and create a metadata editor for epub3 metadata without losing metadata efiting for epub2. Then hopefully continue down that path adding, something to create the nav, and ...

KevinH

Originally Posted by philja

In Sigil 0.9.0, the F7 key and the big green arrow on the tool bar activate a "SanityCheck' function rather than FlightCrew. I can get FlightCrew to work via Plugins/Validation/FlightCrew. Can F7 and the big green arrow be reassigned to FlightCrew or is that facility lost in 0.9.0 ?