Bug#958991: RFS: setzer/0.2.4-1 [ITP] -- simple yet full-featured LaTeX editor

[Boyuan Yang]

Hi,

Quick comment: at least files under data/resources/gtksourceview/language-
specs has different license information than what currently written in
debian/copyright. Please review copyright information again.

-- 
Best,
Boyuan Yang

在 2020-04-27星期一的 18:13 +，Stephan Lachnit写道：
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "setzer"
> 
>Package name: setzer
>Version : 0.2.4-1
>Upstream Author : cvfosa 
>URL : https://www.cvfosa.org/setzer/
>License : GPL-3.0+
>Vcs : https://salsa.debian.org/debian/setzer
>Section : tex
> 
> It builds those binary packages:
> 
>   setzer - simple yet full-featured LaTeX editor
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/setzer
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/setzer/setzer_0.2.4-1.dsc
> 
> Changes since the last upload:
> 
>* Initial release. (Closes: #954847)
> 
> 
> Setzer is an amazing LaTeX Editor with Gnome looks written in Python. It
> features a dark mode, many shortcuts for common symbols used in Latex, a
> document creation wizard and more.
> The only real build dependency is Meson, the runtime dependencies are also
> pretty light: Python GLib bindings and python3-xdg.
> I already had some contact with the developer to wire up support for Meson,
> and he responds very quickly to issues and PRs.
> 
> I don't mind maintaining it in a team, if someone is interested in that.
> 
> Cheers,
> Stephan
> 


signature.asc
Description: This is a digitally signed message part

Bug#959014: RFS: filezilla/3.39.0-2+deb10u1 [NMU, RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "filezilla".

 * Package name: filezilla
   Version : 3.39.0-2+deb10u1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla - Full-featured graphical FTP/FTPS/SFTP client
  filezilla-common - Architecture independent files for filezilla

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/filezilla

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.39.0-2+deb10u1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes:
#928282)

===

Note: Package requires sponsor for stable updates upload.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947102

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



signature.asc
Description: This is a digitally signed message part

Bug#959013: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnome-maps"

 * Package name: gnome-maps
   Version : 3.30.3.1-0+deb10u1
   Upstream Author : maps-l...@gnome.org
 * URL : https://wiki.gnome.org/Apps/Maps
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/gnome-team/gnome-maps
   Section : gnome

It builds those binary packages:

  gnome-maps - map application for GNOME

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/gnome-maps

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnome-maps/gnome-maps_3.30.3.1-0+deb10u1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * New upstream release
 - Make the shape layer renderer use the tile size specified in the
dynamic
   service file, fixing an issue with misaligned shape layer
(GeoJSON, GPX,
   KML) rendering with the new 512 pixel tile
 - Update Icelandic translation

===

Note: Package requires sponsor for stable updates upload.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947464

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



signature.asc
Description: This is a digitally signed message part

Bug#959011: RFS: rumur/2020.04.26-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rumur"

* Package name: rumur
   Version : 2020.04.26-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/rumur

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.04.26-1.dsc

Changes since the last upload:

   * New upstream release.

Regards,
Matthew

Bug#956395: marked as done (RFS: openscap/1.2.17-0.1 [NMU, RC] -- Set of libraries enabling integration of the SCAP line of standards)

[Debian Bug Tracking System]

Your message dated Mon, 27 Apr 2020 21:35:22 -0400
with message-id <8729f96418e6b5728844b1e94ec43c001b2a2069.ca...@debian.org>
and subject line Re: RFS: openscap/1.2.17-0.1 [NMU, RC] -- Set of libraries 
enabling integration of the SCAP line of standards
has caused the Debian Bug report #956395,
regarding RFS: openscap/1.2.17-0.1 [NMU, RC] -- Set of libraries enabling 
integration of the SCAP line of standards
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
956395: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956395
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "openscap"

 * Package name: openscap
   Version : 1.2.17-0.1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://www.open-scap.org/
 * License : [fill in]
 * Vcs : None
   Section : libs

It builds those binary packages:

  libopenscap-dev - Set of libraries enabling integration of the SCAP
line of standards
  libopenscap8 - Set of libraries enabling integration of the SCAP line
of standards
  python3-openscap - Set of libraries enabling integration of the SCAP
line of standards
  libopenscap-perl - Set of libraries enabling integration of the SCAP
line of standards
  libopenscap8-dbg - Set of libraries enabling integration of the SCAP
line of standards

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/openscap

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/o/openscap/openscap_1.2.17-0.1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * New upstream release
 This is the first version with full python3 compatibility.
   * Update package to python3 closes: #937211
   * d/control
 - Change to debhelper-compat
 - Bump to debhelper 10
   Being able to parallelize build
 - Remove autotools-dev and dh_autotools from build dependencies
   * Add apt-1.9.0.patch closes: #930673
   * Add apt-1.9.11.patch use pkgCacheFile instead of mmap
 Patches from Julian Andres Klode on Ubuntu
   * Add use_sys-xattr.patch closes: #953916
 also remove libattr1-dev as build-dependency
   * Disable 010-install-cpe-oval.patch
   * Add d/source/lintian-override for file with
 very_long_line_lenghts_in_source_file
   * Add d/libopenscap8.lintian-overrides for man page with long line length
   * d/missing-sources
 - Update jquery.js
 - Add bootstrap.js


The changelog became a bit longer than I expected. Though I believe it
is only the debhelper part that is excessive.
The bump to debhelper 10 was so i could take advantage to parallelize
the build.
It also meant I could clean up some no longer needed build-dependencies.

I also made a lintian-override because of a long line in manpage, not
sure if I should have split up the line instead.

Regards,
Håvard
--- End Message ---
--- Begin Message ---
X-Debbugs-CC: pol...@debian.org

Hi,

I just made the review and the changes looks okay to me. Since this is an NMU
and that the changes are not trival, I just uploaded it onto DELAYED/15 in
case the original maintainer find it necessary to make adjustments.

Pierre: you may review this package through mentors.debian.net at any time. If
you find it necessary, please use dcut(1) tool to block this upload and/or let
Håvard and I know your concern asap.

-- 
Best Regards,
Boyuan Yang

On Fri, 10 Apr 2020 18:03:28 +0200 =?UTF-8?Q?H=c3=a5vard_Flaget_Aasen?= <
haavard_aa...@yahoo.no> wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "openscap"
> 
>  * Package name: openscap
>Version : 1.2.17-0.1
>Upstream Author : [fill in name and email of upstream]
>  * URL : http://www.open-scap.org/
>  * License : [fill in]
>  * Vcs : None
>Section : libs
> 
> It builds those binary packages:
> 
>   libopenscap-dev - Set of libraries enabling integration of the SCAP
> line of standards
>   libopenscap8 - Set of libraries enabling integration of the SCAP line
> of standards
>   python3-openscap - Set of libraries enabling integration of the SCAP
> line of standards
>   libopenscap-perl - Set of libraries enabling integration of the SCAP
> line of standards
>   libopenscap8-dbg - Set of libraries enabling integration of the SCAP
> line of standards
> 
> 

Bug#959001: RFS: vzdump/1.2.6-6 [QA] -- OpenVZ backup scripts

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "vzdump"

 * Package name: vzdump
   Version : 1.2.6-6
   Upstream Author : Proxmox Server Solutions GmbH
 * URL : 
http://www.proxmox.com/cms_proxmox/en/virtualization/openvz/vzdump/
 * License : GPL-2.0+
 * Vcs : None
   Section : admin

It builds those binary packages:

  vzdump - OpenVZ backup scripts

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/vzdump

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vzdump/vzdump_1.2.6-6.dsc

Changes since the last upload:

   * QA upload.
   * Mark source format as 3.0
 - Import old diff in quilt format.
   * Update Standards-Version to 4.5.0
 - Mark priority as optional.
   * Use delhelper-compat.
 - Update to compat level 12.
   * Remove whitespace from rules and changelog.

Note:
Looks like this got removed from testing because of #925803, which has
been fixed with ploop update. There are still few lintian warning and
only little changes has been done so that a source only upload can be
done.


-- 
Regards
Sudip

Bug#958432: marked as done (RFS: libgadu/1:1.12.2-5 [QA] -- Gadu-Gadu protocol library)

[Debian Bug Tracking System]

Your message dated Mon, 27 Apr 2020 23:19:36 +0200
with message-id <20200427211936.ga29...@angband.pl>
and subject line Re: Bug#958432: RFS: libgadu/1:1.12.2-5 [QA] -- Gadu-Gadu 
protocol library
has caused the Debian Bug report #958432,
regarding RFS: libgadu/1:1.12.2-5 [QA] -- Gadu-Gadu protocol library
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
958432: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958432
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libgadu"

 * Package name: libgadu
   Version : 1:1.12.2-5
   Upstream Author :
 * URL : http://toxygen.net/libgadu/
 * License : LGPL-2.1
 * Vcs : https://salsa.debian.org/debian/libgadu
   Section : libs

It builds those binary packages:

  libgadu3 - Gadu-Gadu protocol library - runtime files
  libgadu-dev - Gadu-Gadu protocol library - development files
  libgadu-doc - Gadu-Gadu protocol library - documentation

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libgadu

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libg/libgadu/libgadu_1.12.2-5.dsc

Changes since the last upload:

   * QA upload.
   * Fix FTBFS with gcc-10. (Closes: #957441)
   * Use debhelper-commit.
 - Update compat level to 12.
 - Remove dependency on dh-autoreconf
 - Remove autoreconf and parallel from rules.
 - Adjust doc location.
   * Exclude md5 from doc package.
   * Update Standards-Version to 4.5.0
   * Mark Vcs to salsa.
 - Remove old gbp.conf


-- 
Regards
Sudip
--- End Message ---
--- Begin Message ---
On Wed, Apr 22, 2020 at 12:11:15AM +0100, Sudip Mukherjee wrote:
>  * Package name: libgadu
>Version : 1:1.12.2-5

> Changes since the last upload:
> 
>* QA upload.
>* Fix FTBFS with gcc-10. (Closes: #957441)
>* Use debhelper-commit.
>  - Update compat level to 12.
>  - Remove dependency on dh-autoreconf
>  - Remove autoreconf and parallel from rules.
>  - Adjust doc location.
>* Exclude md5 from doc package.
>* Update Standards-Version to 4.5.0
>* Mark Vcs to salsa.
>  - Remove old gbp.conf

Hi!
The docs now go partially to /usr/share/doc/libgadu-doc, partially to
/usr/share/doc/libgadu-dev.  This doesn't seem intentional.

I uploaded anyway -- no one really uses Gadu-Gadu anymore, thus people are
not going to develop new software against the library.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄--- End Message ---

Bug#958991: RFS: setzer/0.2.4-1 [ITP] -- simple yet full-featured LaTeX editor

[Stephan Lachnit]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "setzer"

   Package name: setzer
   Version : 0.2.4-1
   Upstream Author : cvfosa 
   URL : https://www.cvfosa.org/setzer/
   License : GPL-3.0+
   Vcs : https://salsa.debian.org/debian/setzer
   Section : tex

It builds those binary packages:

  setzer - simple yet full-featured LaTeX editor

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/setzer

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/setzer/setzer_0.2.4-1.dsc

Changes since the last upload:

   * Initial release. (Closes: #954847)


Setzer is an amazing LaTeX Editor with Gnome looks written in Python. It 
features a dark mode, many shortcuts for common symbols used in Latex, a 
document creation wizard and more.
The only real build dependency is Meson, the runtime dependencies are also 
pretty light: Python GLib bindings and python3-xdg.
I already had some contact with the developer to wire up support for Meson, and 
he responds very quickly to issues and PRs.

I don't mind maintaining it in a team, if someone is interested in that.

Cheers,
Stephan

Bug#951202: RFS review of cglm 0.7.1-1

[Thomas Goirand]

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
> 

Bug#951202: RFS review of cglm 0.7.1-1

[Jordan Justen]

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