Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "highlight":

  * Package name     : highlight
    Version          : 4.10-1
    Upstream contact : Andre Simon <as@andre-simon.de>
  * URL              : http://www.andre-simon.de
  * License          : Expat, LGPL-2.1+, GPL-3+
  * Vcs              : https://salsa.debian.org/debian/highlight
    Section          : devel

The source builds the following binary packages:

   highlight - Universal source code to formatted text converter
   highlight-common - source code to formatted text converter (architecture independent files)
   libhighlight-perl - perl bindings for highlight source code to formatted text converter

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

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

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

   dget -x https://mentors.debian.net/debian/pool/main/h/highlight/highlight_4.10-1.dsc

Changes since the last upload:

  highlight (4.10-1) unstable; urgency=medium
  .
    * New upstream version 4.10
    * New maintainer (Closes: #1022114)
    * d/copyright:
      - Add new maintainer to copyright
      - Convert copyright to DEP5 format
      - Remove stanzas for files that no longer exist
    * d/control:
      - Add new maintainer's name to Maintainer field
      - Update VCS-Browser field to canonical URI
    * d/p/*: Remove git-debcherry artifacts and follow DEP-3
    * Add debian/upstream/metadata

Regards,

Hello mentors,

I am getting a few lintian "source-is-missing" errors for some HTML
files. These HTML files are infact present in the source code but they
have too many lines which triggers a
"very-long-line-length-in-source-file" lintian tag and that in turn
causes the "source-is-missing" error.

Most of the info I could find in the policy manual and in the forums
pertained to binary files that were included in the source, the strategy
these resources suggested were
1. Repack upstream tar with the source code of these files
2. Add the source code to the d/missing-sources directory

I don't think either of these are viable options in my case. I was
wondering whether it would be okay to suppress these errors. Is there
any other way to solve this?

The question is if the long lines in these HTML files are actually indications
that the HTML files are not the original source.  This usually happens in one
of two cases.

1.  The files have been minified.
2.  The files were originally created in another format and converted to HTML.

Sometimes HTML files naturally have long lines.  If you look at the
descriptions of the lintian warnings, they acknowledge that this is an
imperfect check that will result in some false-positives.  If that is the
case, the HTML files are the original source, and they have not been minified,
then you can override these warnings with a description as to why.

Thanks, Soren.

It looks like most of these files have just one or two lines that are
extremely long.

These are mostly README files. Most of them seem to have this
github-markdown.css
<https://gist.github.com/jojoldu/9cb1b6a5110619e221dfd4603f30ddd4>
minified and pasted in them. While others have the sources that were
used to generate them listed in the same folder.

Should I copy these sources into the d/missing-sources directory?
-- 
Shriram Ravindranathan

Shriram,

1.  For anything that has the unminified source in the upstream tarball, I would just create a
lintian override with a comment listing the full path to the source for each file.  You can see
an example of how this can be done here:

https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/lintian-overrides?ref_type=heads[1]

Typically you only copy the source to the debian/missing-sources directory when it is not
included in the upstream tarball and you have had to acquire it from another place.

2.  The github link below includes an embedded font in woff format.  Typically, fonts like
this would be considered compiled, so a separate font source would be needed.  However,
I’m not sure what the Debian guidance for dealing with an HTML embedded font like this.
If someone else on mentors doesn’t know, I would recommend you ask on debian-legal.

As these are mostly README files, and if it becomes difficult for you to acquire the source
for some of them, you might consider excluding those you can’t get the source for, at least
temporarily, using Files-Excluded in debian/copyright (and then running uscan, which will
produce a modified tarball that does not include the problematic files).  For example, see:

https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads[2]

Whether this is a good option depends on how helpful those README files are for the users
of your package.  If you go this route, you should add +dfsg to the version of your package
to indicate that the upstream tarball has been repackaged to remove files that are not free
(or for which the source is not available).

Soren

--------
[1] https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/
lintian-overrides?ref_type=heads
[2] https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?
ref_type=heads

Upon inspecting the embedded font, It seems to be a bespoke icon-font
generated using a tool called "Fontello" from one of the icons of the
octicons iconset from Atom <https://github.com/primer/octicons> (MIT
Licensed SVGs)

The font has only 1 glyph, Would it suffice to add this source image to
d/missing-souces and add that copyright info to d/copyright?
-- 
Shriram Ravindranathan
ters

Shriram,

I would assume so.  If anyone on mentors knows differently please speak up.
sou
copyr

Le mer. 21 févr. 2024 à 15:38, Soren Stoutner <soren@debian.org> a écrit :

You should rebuilt from source also... See for instance how I do with node-long

Thank you Bastien,
I tried doing this but it appears that the scripts to build these
example files all depend on having the highlight binary itself installed
on the machine. I am unsure whether it is okay to have the package
depend on itself for building.

Thank you Soren and Bastien,

I have uploaded a new version of highlight

<https://mentors.debian.net/package/highlight/>changes since last upload:
  - Add sources to d/missing-sources/
  - Add lintian overrides for all missing-sources with the paths to the
sources
  - Add copyright stanzas for newly added missing-sources
  - Add d/p/0004-escape-groff-backslash.patch (Fixes groff syntax error
and lintian warning)

Le jeu. 22 févr. 2024 à 06:07, Shriram Ravindranathan <s20n@ters.dev> a écrit :

Yes and no.

Best use the built package to generate the file

Other way is staged build

Bastien

Shriram,

I am very impressed with the work you have put into this package.  As long as
you are willing to commit to working on addressing the documentation not being
built at compile time issue in the future, I would be willing to sponsor the
upload without resolving it for this release because 1) all the source is
provided and can be build by the user with the compiled highlight binary, 2)
as has been discussed, this is a very difficult issue to resolve, 3) your
packaging work already significantly improves the status of the package in
Debian.

In reviewing the package, I have just a few small notes you should address
before it is uploaded.

1.  Lintian produces the following warning, which is easy to resolve by
changing the build-depends to use the current package name.

W: highlight source: build-depends-on-obsolete-package Build-Depends: pkg-
config => pkgconf
N:
N:   The package build-depends on a package that has been superseded. If the
N:   superseded package is part of an ORed group, it should not be the first
N:   package in the group.
N:
N:   Visibility: warning
N:   Show-Always: no
N:   Check: fields/package-relations

2.  The upstream copyright information appears to be out of date.

Files: *
Copyright: © 2002-2010 Andre Simon <as@andre-simon.de>
License: GPL-3+

The upstream source code doesn’t provide copyright dates in a centralized
place (as far as I could tell).  But a number of files indicate they were
created after 2010.  For example, README.adoc contains the following text near
the top of the document.

André Simon
v4.9, October 2023


Soren

P.S.  As a side note, Lintian also produces the following info.

I: highlight source: debian-watch-uses-insecure-uri http://www.andre-simon.de/
zip/download.html [debian/watch:2]
N:
N:   The watch file uses an unencrypted transport protocol for the URI such as
N:   http:// or ftp://. It is recommended to use a secure transport such as
N:   HTTPS for anonymous read-only access.
N:
N:   Upstream may already provide a HTTPS variant of the URI. If not, please
N:   contact them and ask them to consider adding one.
N:
N:   Visibility: info
N:   Show-Always: no
N:   Check: debian/watch

Dealing with this is not necessary for this upload, but if you haven’t already
done so you might consider contacting upstream and asking them if they could
enable HTTPS on their website.