Hello,

I created the shaderc package (see
https://salsa.debian.org/phsw/shaderc) and its almost ready for upload
(and RFS!). Yet, I have few questions:

* Copyright

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? Here is what I
get with a simple grep in upstream source files:

find . -type f -exec head -n 1 {} \; | grep -a "Copy" | sort | uniq -c
     23 # Copyright 2015 The Shaderc Authors. All rights reserved.
     49 // Copyright 2015 The Shaderc Authors. All rights reserved.
      6 # Copyright 2016 The Shaderc Authors. All rights reserved.
      7 // Copyright 2016 The Shaderc Authors. All rights reserved.
      4 # Copyright 2017 The Shaderc Authors. All rights reserved.
      3 // Copyright 2017 The Shaderc Authors. All rights reserved.
      6 # Copyright 2018 The Shaderc Authors. All rights reserved.
      4 // Copyright 2018 The Shaderc Authors. All rights reserved.
      5 # Copyright 2019 The Shaderc Authors. All rights reserved.
      2 // Copyright 2019 The Shaderc Authors. All rights reserved.
     17 # Copyright 2020 The Shaderc Authors. All rights reserved.
     29 # Copyright (C) 2017 Google Inc.
      4 :: Copyright (C) 2017 Google Inc.
      1 # Copyright (c) 2017 Pierre Moreau
      1 # Copyright (C) 2018 Google Inc.
      2 # Copyright (C) 2020 Google Inc.


* Building on ARM

The crossbuilding for arm64 fails on Salsa-CI, because of unavailable dependencies:

The following packages have unmet dependencies:
 builddeps:.:arm64 : Depends: asciidoctor:arm64
                 Depends: ruby-pygments.rb:arm64 but it is not installable

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.


* Library name

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:

/usr/lib/x86_64-linux-gnu/libshaderc_shared.so /usr/lib/x86_64-linux-gnu/libshaderc.a /usr/lib/x86_64-linux-gnu/libshaderc_combined.a /usr/lib/x86_64-linux-gnu/pkgconfig/shaderc.pc /usr/lib/x86_64-linux-gnu/pkgconfig/shaderc_combined.pc /usr/lib/x86_64-linux-gnu/pkgconfig/shaderc_static.pc

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?


* Symbol file

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?


Any additional review of the packaging would be warmly welcomed! :)

Thanks,

Philippe.


[1] https://github.com/google/shaderc/blob/7ea834ecc59258a5c13c3d3e6fa0582bdde7c543/AUTHORS

[2] https://github.com/google/shaderc/blob/7ea834ecc59258a5c13c3d3e6fa0582bdde7c543/CONTRIBUTORS

[3] https://github.com/google/shaderc/blob/7ea834ecc59258a5c13c3d3e6fa0582bdde7c543/LICENSE

[4] https://github.com/google/shaderc/blob/main/license-checker.cfg

[5] https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmMeikQACgkQMRa6Xp/6 aaMtuQ/9EAeXAUlxsy/V9KWoVG9QOCH8R+KPBvzk/LH6iAO0wPE3RDu2FXq+G5QV haeG8giu3VR8w7JoA0phDI7VDhk/B/1FuAJOhe3wC1SxPiPzuojA1C39dJivd9mk MFN4Ras7tbGIiCtgcaJZdwiTgTwSOM+exQ4MvJiQiZzLJIdN5eQJGPEPVG0D0wYx gshheAx8/eFeSunbgQxTGta7KXNFe5TSwE3e5ZvwSRewzw7M2BCimZu8SmHNl9lA qZGIP9YliadBpyCKf7PxP2NhVemXGtd0Vhd7mOhkGdEvqXi9oShavsK4A2lKH0/v 7m16GXrWifDFmPoNpNxkgBfYrnqs59/ZmS7fANcaC5Y0GM3smLUDJujHPIF2dGHM IUN5Z/8cDyGffVF6DkkNocPrKgbVXOxZjmO2wvzXVotHQVWNUOgne9K+EXbz0B9m cBhze+sdMkiS5ymyInweG6BJh8XG9ZZFEhiaNrn2+VTEHk/dyJ3VqUy79jPxy3og gpUgLnqONfeIs7J356kuOiFjgribQmivJXbCeTM7I6W3Bt7gD5HAawRpngs5EobB fNW2eFswyhB4N6EuA+skQSIlmQjj9aQlc6O5NahgOoLKs8MB/SU7ZVXY7r+Nv4o8 CgKUATDHiXsmboxihJRhIWJF3VCdp9PZDduAy5I9p78gkmiZDx4=
=58X9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)