Making good progress, but also requires kf5 port of https://quickgit.kde.org/?p=kdegraphics-mobipocket.git

Which I am working on now.

Review

• job not green http://build.neon.kde.org/job/xenial_stable_applications_okular/
• again has changelog entries https://packaging.neon.kde.org/applications/okular.git/tree/debian/changelog?h=Neon/stable stop writing them. We do not changelog changes in debian/changelog, we write commit messages which act as changelog. There is no time where a human should need to provide a debian/changelog entry. Ever.
• okular-mobile needs Depends level requirement on okular (uses its qml module, among other things)
• inconsistency with backend packaging: okular-extra-backends contains the desktop files for both mobile and regular okular backends. for the default backends the desktop files are split between okular and okular-mobile. to be consistent the default backend desktop files for both mobile and desktop should be in the okular package, the okular-mobile package should only contain the mobile qml files and the mobile desktop file (for the application)
• okular-mobile needs Depends on kpackagelauncherqml. its desktop file has Exec=kpackagelauncherqml ... which lintian complains about since kpackagelauncherqml is not in the package, this was overridden but the package doesn't actually depend on kpackagelauncherqml so the lintian complaint is still valid as the package is installing a non-functional desktop file.
• okular has a lintian override on desktop-command-not-in-package which should not be needed as all desktop files therein Exec=okular which is in that package
• compared to debian the dbgsym migration in debian/rules was changed which is a) probably wrong b) the new version is definitely wrong as it lacks an epoch

kdegraphics-mobipocket:

• has a Neon/release branch but no build on jenkins

fine besides that

Jonathan was making changes to the mobile bits and putting them in non mobile package. I do not fully understand the why so I will leave that to him to sort out.

I will look at the other bits today.

I finally understand now to not touch changelog... sorry this was not made clear to me, I thought we just append neon.

The .desktop files for the extra backends should be in the extra backends package, else the app will show they are there when they're not. For the main backends I guess the .desktop files can go in either the okular package (togather with the backends) or int he mobile package (where the frontend that cares for them is).

Back on this. Sorry for the interruption...

Look like libqimageblitz is bringing in qt4 crap. It was recently ported and I do not see it packaged. SO I will do that first..

Ok at least it builds again... now back on these bloody tests..

Holy errors batman :( I do not know C++ enough to be able to debug this. compiler not supporting C++ ... and it want fPIC and and
maybe I should disable acc, but I really want to know how to fix ! any thoughts ?

how do you get this error?

Running abi-compliance-checker -l okular-dev -dump debian/okular-dev.acc -dump-path debian/okular-dev/usr/lib/x86_64-linux-gnu/dh-acc/okular-dev_4:16.12.1-0neon.abi.tar.gz ( manually copied from dh_acc command ) after running debuild generates this log. The original output from debuild is a less than useful exit status 6 ( which when I looked that up, means error compiling headers ) So my curiosity led me here.

But FWIW I got it from an exit status 4 to 6. It wasn't able to find the files originally, so I did fix something!

ach just remove the acc test if it's a pain, tracking ABI is difficult and not necessarily useful for master CI

ok. I will for now, and just mess with it locally for learning purposes. Still have the other test to debug though.

building fine. failing tests are a problem for okular devs

https://build.kde.org/job/okular%20master%20kf5-qt5/ code CI disagrees.

I agree it needs fixed, but have admitted on several occasions that I am at a loss as to why it fails. I need help.
Thanks,
Scarlett

lintcmake tests fixed

the test is just running okular and seeing if it stops
QTRY_COMPARE_WITH_TIMEOUT(p.state(), QProcess::NotRunning, 20000);
it should keep trying until the timeout happens
what I don't get is why the timestamps on the build logs suggest it isn't taking any time to run the test, it should be at least 20 seconds