[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: libzeep version 6



Hi Étienne,

Thanks very much for this thorough review of libzeep.

The copyright on the name characters file was an error. Should have been Boost as well of course.

The test files were downloaded from https://www.w3.org/XML/Test/. There's no license to be found there. This has never been a problem before in Debian for libzeep, so I would be surprised if it would fail to pass NEW this time.

It is not a real option to replace the fonts and scripts in the documentation with local versions. I do understand this would shave a couple of megabytes of the size of the doc package, but it would require the user to install all of the debian packages containing these scripts and fonts just to be able to install the docs. The list is quite long. And then, this documentation would then only be viewable when browsing with a local web browser, if you only have access to a subdirectory containing the documentation, the paths to the fonts and scripts would be incorrect.

I've pushed a new version (6.1.1-1) to salsa.

regards, -maarten


Op 06-02-2025 om 23:18 schreef Étienne Mollier:
Hi Maarten,

Maarten L. Hekkelman, on 2025-02-05:
Op 05-02-2025 om 13:17 schreef Maarten L. Hekkelman:
The version of libzeep in Debian is almost two years old. I've prepared
a new package and it seems to build mostly on salsa (i386 and reprotest
fail, but both seem to fail not due to any error in libzeep as far as I
can see).
Ha, my bad, had the wrong distribution. Package now builds nicely, all tests
are green.

So, pretty please?
Thanks for the provision of the libzeep, I had a look at the
package.  It is overall in good shape, but with the round trip
through NEW, it is preferable to put some extra care in the
copyright information, to reduce the risk of seeing the package
being rejected.

The d/copyright file mostly documents the fact that the whole
package is governed by the Boost license 1.0.  I have found
however an exception:

   * You released lib-xml/src/html-named-characters.cpp under
     BSD-2-Clause.  It would be necessary to document the
     different license of this file from the rest of the source
     code in d/copyright.

   * lib-xml/test/XPath-Test-Suite/data-013.xml looks to
     reference a great many resources with varying copyright
     information, but as far as I can examine, this seems to be
     just an index, not actual content.  It may be worth dropping
     a word about this file in a comment in the d/copyright file,
     as the numerous occurrence of "copyright" may trip also on
     ftpmaster side.

I would feel better about uploading the package with the extra
entry for lib-xml/src/html-named-characters.cpp in d/copyright.
If you had to do just one change, please to this one.


Other than that, lintian issued new warnings with the new
version of the software.  If you have an idea how to use the
Debian provided javascript libraries, then you should probably
address that:

	W: libzeep-doc: embedded-javascript-library please use libjs-jquery [usr/share/doc/libzeep/_static/jquery.js]
	W: libzeep-doc: embedded-javascript-library please use sphinx [usr/share/doc/libzeep/_static/doctools.js]
	W: libzeep-doc: embedded-javascript-library please use sphinx [usr/share/doc/libzeep/_static/language_data.js]
	W: libzeep-doc: embedded-javascript-library please use sphinx [usr/share/doc/libzeep/_static/searchtools.js]

If you manage to resolve the two below informational messages,
that might facilitate build reproducibility, although sbuild
uses a constant reproducible build path nowadays, so it may be
less problematic that it used to:

	I: libzeep-doc: file-references-package-build-path [usr/share/doc/libzeep/_sources/api/dir__build_reproducible-path_libzeep-6.1.0_include_zeep.rst.txt]
	I: libzeep-doc: file-references-package-build-path [usr/share/doc/libzeep/api/dir__build_reproducible-path_libzeep-6.1.0_include_zeep.html]

It would be possible to slightly reduce the size of the
libzeep-doc package if you make use of the font provided by the
package fonts-lato instead of embedding those; although I think
they stem from automatically generated documentation, so I'm not
sure they can be removed easily:

	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-Bold.ttf.gz]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-Bold.woff2]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-BoldItalic.ttf.gz]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-BoldItalic.woff2]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-Italic.ttf.gz]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-Italic.woff2]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-Regular.ttf.gz]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/Lato-Regular.woff2]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/RobotoSlab-Bold.woff2]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/RobotoSlab-Regular.woff2]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.eot.gz]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.ttf.gz]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.woff2]
	I: libzeep-doc: font-in-non-font-package [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.woff]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-Bold.ttf.gz]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-Bold.woff2]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-BoldItalic.ttf.gz]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-BoldItalic.woff2]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-Italic.ttf.gz]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-Italic.woff2]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-Regular.ttf.gz]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/Lato-Regular.woff2]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/RobotoSlab-Bold.woff2]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/RobotoSlab-Regular.woff2]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.eot.gz]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.ttf.gz]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.woff2]
	I: libzeep-doc: font-outside-font-dir [usr/share/doc/libzeep/_static/fonts/fontawesome-webfont.woff]

This informational message is for implementation of the symbols
tracking with d/libzeep6.symbols.  In C language it facilitates
identification of ABI breakages, but in C++, due to the symbols
inflation and leaks, this results in a mostly unreadable file,
so not providing it would be fair enough in my opinion:

	I: libzeep6: no-symbols-control-file usr/lib/x86_64-linux-gnu/libzeep.so.6.1.0

Updating the standards version to 4.7.0 would be a low hanging
fruit if you are to make a few changes to the package:

	I: libzeep source: out-of-date-standards-version 4.6.0 (released 2021-08-18) (current is 4.7.0)

 From a quick grep in the source code of libzeep, the below
message seems to be a false positive caused by two strings
concatenated within the library and can probably be ignored:

	I: libzeep6: spelling-error-in-binary characteer character [usr/lib/x86_64-linux-gnu/libzeep.so.6.1.0]

That is all I have to mention for now, I hope it is not too
overwhelming.  If you have to focus somewhere, that would be on
the copyright file.  On the other end of the spectrum, some of
the informational lintian messages may prove to be difficult to
address, and I would understand if they are left alone in a
first time.  Thank you for your work on the libzeep, both as the
packager and upstream developer!

Have a nice day,  :)

--
Maarten L. Hekkelman
http://www.hekkelman.com/


Reply to: