On Sun, 2022-09-11 at 21:40 +0200, Philippe SWARTVAGHER wrote: > Upstream has several files describing copyrights of the project [1-4]. > In d/copyright, I licensed the whole project with Apache 2.0, with > "Google Inc." as copyright holder. Should I detail more? Generally, the ftp-masters require the copyright and license info of every file in the source package to be documented in debian/copyright. https://ftp-master.debian.org/REJECT-FAQ.html The machine-readable copyright format design helps make that easy. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ There are various tools available to partially automate that process. Allegedly ScanCode is the best one, but it isn't available in Debian. The output of the tools should be checked manually for correctness too. https://wiki.debian.org/CopyrightReviewTool > The crossbuilding for arm64 fails on Salsa-CI, because of unavailable > dependencies: Cross-building is optional so you don't have to fix that right now, all arch-specific Debian packages are created using native builds. It is estimated that only about 50% of Debian is cross-buildable, that number is slowly going up over time as people work on issues. > The following packages have unmet dependencies: > builddeps:.:arm64 : Depends: asciidoctor:arm64 > Depends: ruby-pygments.rb:arm64 but it is not installable I note that both asciidoctor and ruby-pygments.rb have issues reported by the multi-arch hinter. Fixing those might allow this to work. https://tracker.debian.org/pkg/asciidoctor https://tracker.debian.org/pkg/ruby-pygments.rb > Since asciidoctor is only used at build time to generate the manpage, is > it possible to specify in d/control that asciidoctor doesn't have to be > available on arm? Indeed, the version for the host architecture will be > enough to build the package and won't be required to install the package. Please note that asciidoctor is installable on arm64 (I checked), the issue you face is only a problem in the cross-build scenario. You can mark asciidoctor with the nodoc build profile, so that people who don't want to build documentation can apply the profile and disable building the manual page and not need the asciidoctor build dependency. https://wiki.debian.org/BuildProfileSpec > The name of the shared library generated by upstream source code is > libshaderc_shared.so.1, but the suffix "shared" seems to be used just to > emphasize the shared aspect of the library. The following files are also > installed: ... > I named the library package libshader1. Is it a correct situation? Or > should I rather rename the shared library to libshaderc.so? or the > package to libshaderc-shared1? I suggest talking to upstream about this. It does seem like the "shared" suffix should not be part of the SONAME. > As stated in [5], I didn't include a symbols file in the package, since > the library is in C++ (I generated it, and even unmangled, it will be > hard to maintain). Is it correct for this package? That is reasonable, if you change your mind, the KDE team documentation on this issue might be useful for maintaining the C++ symbols files: https://qt-kde-team.pages.debian.net/symbolfiles.html Please note that not using symbols files means you will need to maintain the shlibs and be sure to bump them when symbols change, or just make reverse-deps use more strict dependencies. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part