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)
Quote:
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
Quote:
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...)
Quote:
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.
Quote:
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
Quote:
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.
Quote:
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