Hello Andreas, A few things changed since the previous email. I found a way of getting the dependencies via another chroot environment and now the package builds in cowbuilder with no troubles. My work routine usually goes along the lines of getting stuck on something for a couple of hours, emailing here on the mailing list then 30 mins later somehow managing to fix whatever issue I was stuck on :). I am having some issues with moving libFAST.so. I am not sure if I should simply use mv or use d-shlibmove. d-shlibmove just throws an error with regards to dependencies not existing so if I am meant to use d-shlibmove, please have a look at this in fast. Lintian is reporting package-name-doesnt-match-sonames. I believe this is where I have to rename "fast" to "libFAST" for the package name. I am also getting shlib-without-versioned-soname and I am unsure as to how this is rectified. Compilation of the test binaries fail and I am even unable to build these in an isolated system just using cmake so I assume this is some sort of an upstream bug or even an incomplete wiki page with some dependency not documented. I'll figure out something for this as usual. Luckily all other informational lintian outputs can simply be fixed by removing the unneeded directories like fonts. I can't think of anything else to write at this time of night. Thanks for your time & best regards, Shayan Doust On 09/08/2019 20:00, Shayan Doust wrote: > Hello, > > Well I believe that's all with FAST library dependencies migrated and > adapted. I'm having a slight issue with making out what dependencies are > still missing from debian/control, as cowbuilder still fails. For me, > cowbuilder seems to have truncated the output of cmake compared to the > more dirty way of using dpkg-buildpackage so I cannot make sense as to > what is missing. > > Is there a way as to increase verbosity or alter settings? > > Best Regards, > Shayan Doust > > On 09/08/2019 00:04, Shayan Doust wrote: >> Hello Andreas, >> >>>> Although I do not understand why upstream are manually building these... >>> >>> If you are into packaging a bit longer you will face way more crazy >>> ideas than this. Believe me, done this for > 20 years and have seen >>> a lot of crazy things. ;-) >> >> Thinking about this now, I think upstream did this to not break windows >> - linux cross-compability. Yet again, it should be done in a fashion as >> to check if not win32 and lib exists on the system and use that instead >> of downloading. >> >> I also spent around an hour or two patching and successfully building >> the realsense library only to find that this is an optional module not >> enabled by default in fast cmake - whoops :(. >> >> The quest to erradicate git as a dependency and migrate libs still >> continues :). This is an interestingly lengthy package. Luckily it's >> only QT and its seemingly many modules that is the major library that >> needs dealing with and then everything else is simpler and quicker. >> >> Best Regards, >> Shayan Doust >> >> On 08/08/2019 16:06, Andreas Tille wrote: >>> On Thu, Aug 08, 2019 at 03:44:57PM +0100, Shayan Doust wrote: >>>> Hello Andreas, >>>> >>>> Thanks, that makes sense. I will patch anything that needs building >>>> instead of allowing git to download then build. >>>> >>>> Although right now, I am still in the process of migrating everything to >>>> use libs that have already been packaged and are available via apt, >>>> though until I go through everything one by one I won't be too sure as >>>> to what is not available via apt. >>>> >>>> Although I do not understand why upstream are manually building these... >>> >>> If you are into packaging a bit longer you will face way more crazy >>> ideas than this. Believe me, done this for > 20 years and have seen >>> a lot of crazy things. ;-) >>> >>> Kind regards >>> >>> Andreas. >>> >>> >> >
Attachment:
signature.asc
Description: OpenPGP digital signature