Hi Leon, Jordan did detect something was wrong with the doc. Indeed, there's some issues. It's overall a good review, though missing some advice, which I intend to give myself here.
1/ Sphinx documentation Your package must be using: --with sphinxdoc and the -doc package must depends on ${sphinxdoc:Depends} so that everything is handled automatically for you. I also wouldrecommend the following sequence which I use myself (not mandatory, but nice...): override_dh_sphinxdoc: ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS))) python3 -m sphinx -b html doc/sources \ $(CURDIR)/debian/libcglm-doc/usr/share/doc/libcglm-doc/html dh_sphinxdoc endif then you don't need these: Package: libcglm-doc Depends: fonts-font-awesome, fonts-lato, libjs-jquery, libjs-underscore, neither you need a debian/libcglm-doc.links file, as dh_sphinxdoc will do that for you. 2/ copyright Jordan is right about debian/copyright needing a debian/* section. Though the license that you're using is "Expat", which is one flavor of the MIT license (there's multiple MIT licenses, unfortunately, and Debian recognize this one as "Expat"). 3/ Missing hardening options You may want to add this to your debian/rules: export DEB_BUILD_MAINT_OPTIONS = hardening=+all 4/ Missing .symbol file Please read on here: https://wiki.debian.org/UsingSymbolsFiles 5/ Others You don't need this file: debian/libcglm0.dirs since you're installing things in /usr/lib with debian/libcglm0.install, then there's no need to re-declare /usr/lib a 2nd time. Same thing for debian/libcglm-dev.dirs and debian/libcglm-doc.dirs. 6/ General advice Leon, I strongly recommend that you run Lintian this way on your package before asking for a review: lintian -Ii -E --pedantic *.changes you would have seen the issues, and win time for everyone. Now, if you come back with a corrected package, maybe Jordan can review it again. If he does, I agree to do an initial sponsoring of it (though not the follow-up ones) if Jordan is volunteering for the subsequent ones. Jordan, just let me know when the package is ok. No need to CC me or the archive-...@nm.debian.org anymore. Cheers, Thomas Goirand (zigo) On 4/27/20 12:24 PM, Jordan Justen wrote: > Leon, > > I reviewed the 0.7.1-1 packaging you posted on mentors.debian.net. I > didn't see any major issues, but maybe some suggestions. > > The license is MIT, and debian/copyright has it listed properly. > > I think packages often will call out the debian directory in > debian/copyright, even if it matches the upstream license. I don't > know that this is required, but here's an example: > > https://salsa.debian.org/xorg-team/lib/libglvnd/-/blob/debian-unstable/debian/copyright#L50 > > You can also move the license text to a separate section if multiple > sections list the same license. (Like the MIT license in the example > above.) > > I did see that `lintian --display-info` prints some issues relating to > fonts in the doc package. From `build-rdeps python3-sphinx-rtd-theme`, > I found the dbus-python package also uses the rtd theme. I notice they > use dh_sphinxdoc, and I wonder if it could be useful for the cglm > package. (And, perhaps fix the lintian note.) > > lintian --display-info also flags no-symbols-control-file > usr/lib/x86_64-linux-gnu/libcglm.so.0.0.1. (See dpkg-gensymbols) > > lintian --pedantic --display-experimental flags > debian-watch-does-not-check-gpg-signature, but I see upstream doesn't > sign the releases. You could ask upstream to do this, and pointing > them at https://wiki.debian.org/Creating%20signed%20GitHub%20releases > might make it easier for them. > > I don't these the info or experimental lintian items would block the > package from debian, since they aren't even at the warning level. > > One easy cleanup change for the package would be to run wrap-and-sort. > > Do you plan to try to maintain the package going forward? (Watch for > new upstream releases, work on bugs, etc?) > > Do you have plans to manage the package files in git, perhaps on > salsa.debian.net? I'm not sure if it is allowed to start using salsa > for a project before it makes it into debian. The salsa FAQ is vague > on this point: > > https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa > > But I think it is often allowed. I know of at least 2 cases where a > repo was created for a package before it got included into Debian. I > expect some basic review of the package is probably good first, and > perhaps this email can serve for that. > > If not salsa.debian.net, you could still host it in a github repo and > include the links to it in the control file. (And, that could move to > salsa later too.) > > -Jordan > > Some more info, mainly for Thomas to know what I checked. > > I looked over https://wiki.debian.org/SponsorChecklist. > > I checked the provided orig tarball vs upstream. > > I built the package with sbuild. > > I looked over the lib, dev and doc packages in the control file and > .deb outputs. > > I *did not* use the library with any code, but I did note that the > upstream package has 633 tests which all passed during the sbuild > build. > > I ran piuparts, and it reported that all tests passes. > > I reviewed each item on https://ftp-master.debian.org/REJECT-FAQ.html: > > Serious violations checklist (REJECT-FAQ): > > * OpenSSL - not linked => Ok > * CDBS - doesn't use => Ok > * PHP License - MIT license => Ok > * License - upsteam has LICENSE file => Ok > * Transition - Ok > * Experimental Library - not linked => Ok > * Hijack - no => Ok > * Package split > * FTBFSIASW - built with sbuild => Ok > * debian/control breakage #2 - Ok > * Copyright - Ok, with comment > * optionally, could add a separate debian section > * https://salsa.debian.org/xorg-team/lib/libglvnd/-/blob/debian-unstable/debian/copyright#L50 > * Need to check for multiple copyright holders > * License II - upsteam has LICENSE file => Ok > * License III - Ok > * Using `licensecheck`, it appears "Recep Aslantas" is the only listed copyright holder > * Non-Main - checked Depends on .deb files, Build-Depends, Recommended manually => Ok > * Non-Main II - Ok > * Package Content - Ok > * Policy Violation - > * manually inspected - looks ok > * lintian reports some font issues at "info" level > * font-in-non-font-package usr/share/doc/libcglm-doc/html/_static/fonts/Lato-Bold.woff2.gz > * and, several more. this appears to come from debian/libcglm-doc.links > * Contents of orig.tar.gz - not being rebuilt; no *.{a,so} => Ok > * Lintian (with --display-info) > * libcglm-dev: capitalization-error-in-description api API > * libcglm-doc: font-in-non-font-package usr/share/doc/**/*.woff2.gz > * libcglm-doc: font-outside-font-dir usr/share/doc/**/*.woff2.gz > * libcglm0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libcglm.so.0.0.1 > * rpath - not used => Ok > * Package name - Ok > * Common license - MIT not under common-license => Ok > * Renaming source for DFSG-removals - not dfsg repacked => Ok > * Wrong license pointer - no common-license is used => Ok > * Symbol file wrong - no symbol file currently (but, suggested) => Ok > * Source missing - no missing source => Ok > * Generated files - none seen, or flagged by lintian => Ok > * Package uses waf as build system - autotools => Ok > * Source package missing source - no source missing => Ok > > Minor issue checklist (REJECT-FAQ): > > * Description - Ok > * Repackage orig.tar.gz - not repacked => Ok > * Native/Non-Native - non-native => Ok > * Multiple versions - only 1 version => Ok > * debian/rules - Ok > * .ex files - Ok > * Standards-Version - Ok > * Manpages - no manpages, but not a requirement > * Useless Settings - Ok >
signature.asc
Description: OpenPGP digital signature