Re: help wanted
Hi Nilesh,
Op 31-08-2023 om 21:22 schreef Nilesh Patra:
Not sure why, but the package does not even compile for me in a clean unstable chroot.
It chokes with:
| error: Could not create output directory /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/docs/xml
| Doxygen version used: 1.9.4
| Exiting...
| make[4]: *** [docs/CMakeFiles/Sphinx.dir/build.make:123: docs/xml/index.xml] Error 1
| make[4]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
| make[3]: *** [CMakeFiles/Makefile2:1054: docs/CMakeFiles/Sphinx.dir/all] Error 2
| make[3]: *** Waiting for unfinished jobs....
| ...
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j5 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2
That's curious. As you can see on salsa, the code was built fine there
and so it was on several of my instances. But it might be that this
error is caused by a race condition, I'll see if I can find a reason for
this.
On 08/31/2023 5:45 PM IST Maarten L. Hekkelman <maarten@hekkelman.com> wrote:
Anyway, using sphinx introduces a lot of lintian warnings. Mostly
related to the fact that sphinx documentation installs its own copy of
jquery and a couple of fonts. My guess is that more packages in debian
use sphinx so before I start to work around this I'd like to know if
others have solved this 'problem' already. Or should I simply ignore the
warnings?
Seems you solved this with the following:
On 08/31/2023 9:18 PM IST Maarten L. Hekkelman <maarten@hekkelman.com> wrote:
override_dh_auto_build: export http_proxy=127.0.0.1:9
override_dh_auto_build: export https_proxy=127.0.0.1:9
override_dh_auto_build:
dh_auto_build
Ehm, no, that did not fix it. The reason I added these lines is to avoid
net access from the sphinx tool. The documentation still installs its
own copy of jquery and all which is what lintian is reporting.
I think a more correct way of doing so would be to export the http_proxy in dh_auto_build-indep
(and not dh_auto_build) and then override it for generating docs.
There are a few lintian warnings as far as I could see in the CI[1]. If you comment out the
"html_static_path = ['_static']" line in docs/conf.py.in, does it help? If so, is the documentation
usable?
If I leave out _static, the documentation will no longer work correctly.
I could add a dependency on the debian version of jquery e.g. and then
rewrite the documentation to refer to that version of jquery. But I
believe this is something that should be done in the debian package for
sphinx, not in a package using sphinx.
Another problem with my package is that the reprotest fails on salsa.
The actual error it stumbles upon has to do with locales. It seems that
something is fishy with the installation of locales on the machine where
the tests run. The test code tries to create a locale namen nl_NL.UTF-8
and then checks if the name of the result is the same as the name
requested to be sure it really got the correct locale. That check should
not be required since if that locale is not installed, the C++ standard
says an exception should be thrown but that doesn't happen, sometimes,
recently, on Debian. I can skip those tests, but I'd like to know why
they are failing. Not sure who to contact for this.
Locale check is a step in the reproducible builds check. The idea is that the resulting
.deb should not depend on the user's system locale and it should reliably and identically
build across systems.
You can find more details here[2]. You may want to simply export LC_ALL=C in d/rules to avoid the repro
failure based on locale. I don't think it is worth it to disable tests due to this reason.
Exporting LC_ALL=C is not going to solve the issue in my tests.
What the test does is processing a mock HTTP request that asks for a
reply in a specific language. The code in libzeep tries to load the
requested locale and use it to format dates and numbers. This code uses
several tricks to load the correct locale based on what is in the HTTP
header. If all fails, it ends up loading the C locale and use that.
So, if you have the requested locale installed, it will use it and if
you don't have it, the C locale is used.
This approach should not be affected by the current LC_ALL environment
variable or anything else.
The tests try a couple of locales, some of which I have installed on my
machine and others not. The tests try to find out if a locale is
installed and if not it will skip the test. On the repro test this fails
for some unknown reason. The locale is loaded (should throw an exception
if it cannot load, which works on my machine) and even has the name of
the requested locale but contains data that is different. So the test
fails, output is formatted in some English variant.
I will ignore the reprotests but I'm not going to invest time to rewrite
my tests since they work as expected on other machines.
-maarten
Reply to: