Re: RFS: libzeep version 6
"Maarten L. Hekkelman" <[email protected]>
| Newsgroups | gmane.linux.debian.devel.medical |
|---|---|
| Message-ID | <[email protected]> |
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, :)