I am the maintainer of the redmine package.  Redmine upstream ships
four NotoSans fonts in the .woff2 format.

https://salsa.debian.org/ruby-team/redmine/-/tree/debian/latest/app/assets/fonts?ref_type=heads

I would like to stop shipping these fonts in the redmine package
and instead depend on a proper Debian font package.

The purpose of this feature request is to ask about the feasibility
of also shipping a noto package that includes the .woff2 format
of the fonts.

If you are open to shipping the .woff2 format but do not have the
available time to implement it, I would be willing to prepare a patch
to do so.

tags -1 + patch
thanks

Dear maintainers,

I have prepared an MR for this issue:
https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/2

Best regards,

Quoting Soren Stoutner (2025-09-22 23:51:38)

You can use sfnt2woff-zopfli during build for the fonts you need.

 - Jonas

I am not sure I fully understand your comment.  Are you suggesting we use
sfnt2woff-zopfli instead of woff2_compress (which is what is currently used in
the MR)?

Quoting Soren Stoutner (2026-04-20 22:43:20)

No, I was just (through a random concrete tool) generally suggesting
that you do what you now make me aware that you already doing already
:-)

 - Jonas

We believe that the bug you reported is fixed in the latest version of
fonts-noto, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1116004@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Manuel Guerra <ar.manuelguerra@gmail.com> (supplier of updated fonts-noto package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 28 Apr 2026 21:57:12 +0000
Source: fonts-noto
Binary: fonts-croscore fonts-noto fonts-noto-core fonts-noto-extra fonts-noto-hinted fonts-noto-hinted-udeb fonts-noto-mono fonts-noto-ui-core fonts-noto-ui-extra fonts-noto-unhinted fonts-noto-unhinted-udeb fonts-noto-web
Architecture: source all
Version: 20201225-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Fonts Task Force <pkg-fonts-devel@lists.alioth.debian.org>
Changed-By: Manuel Guerra <ar.manuelguerra@gmail.com>
Description:
 fonts-croscore - width-compatible fonts for improved on-screen readability
 fonts-noto - metapackage to pull in all Noto fonts
 fonts-noto-core - "No Tofu" font families with large Unicode coverage (core)
 fonts-noto-extra - "No Tofu" font families with large Unicode coverage (extra)
 fonts-noto-hinted - obsolete metapackage to pull in a subset of Noto fonts
 fonts-noto-hinted-udeb - "No Tofu" font families with large Unicode coverage (d-i default) (udeb)
 fonts-noto-mono - "No Tofu" monospaced font family with large Unicode coverage
 fonts-noto-ui-core - "No Tofu" font families with large Unicode coverage (UI core)
 fonts-noto-ui-extra - "No Tofu" font families with large Unicode coverage (UI extra)
 fonts-noto-unhinted - "No Tofu" font families with large Unicode coverage (unhinted)
 fonts-noto-unhinted-udeb - "No Tofu" font families with large Unicode coverage (d-i optional (udeb)
 fonts-noto-web - WOFF2 webfont versions of Noto fonts
Closes: 1116004
Changes:
 fonts-noto (20201225-5) unstable; urgency=medium
 .
   * Team upload
   * Create new fonts-noto-web binary package.
   * Add debian/scripts/generate-noto-web.sh to convert TTF to WOFF2.
     (Closes: #1116004)
   * Update debian/control:
     - Add woff2 to Build-Depends.
     - Define fonts-noto-web package.
   * Update debian/rules:
     - Modernize to use debhelper options instead of CDBS.
     - Execute conversion script after dh_install.
   * Update copyright holders for debian/* stanzas.
   * Delete vendored *.mk files for the CDBS options.
   * Add debian/javascript/*.css files to control web fonts.
Checksums-Sha1:
 ea59c0efb25f252d1c052e8dc96532980530ba66 2795 fonts-noto_20201225-5.dsc
 ce9eb07102fc55d45c9ad923fbbe4a82cfe6fad8 111916 fonts-noto_20201225-5.debian.tar.xz
 2452b7894236c69b78a5fadac72275190df80736 1560528 fonts-croscore_20201225-5_all.deb
 0d3d276cb0804305df3d0392ea475fae8881cc51 12174864 fonts-noto-core_20201225-5_all.deb
 9f520bed61b55719a6cb85218513bf60e0f9d23a 72411788 fonts-noto-extra_20201225-5_all.deb
 356542b4db013cda5f19c1fb38ffc8ee60e2c083 145564 fonts-noto-hinted-udeb_20201225-5_all.udeb
 8a0193c415557e6d929e137dc2f05bac44554b53 4756 fonts-noto-hinted_20201225-5_all.deb
 9f15c88b96a9b66531369fc6c5898204bf264ca4 385636 fonts-noto-mono_20201225-5_all.deb
 623cd748669970c9d66caad8ecbf8466308d2f6a 1408080 fonts-noto-ui-core_20201225-5_all.deb
 e9db88b2297b83b68efacd73705c1f52f89cf36f 14239252 fonts-noto-ui-extra_20201225-5_all.deb
 844f0f510a082996a74264259904c97bacb7954f 10483188 fonts-noto-unhinted-udeb_20201225-5_all.udeb
 be6df0eeb4ee6b7b3d7d14ae0dff1697fda4aa03 4988 fonts-noto-unhinted_20201225-5_all.deb
 3fc0d0355a69b5a9532b21315d80186f90a30af0 892920 fonts-noto-web_20201225-5_all.deb
 b9c67e427ddd36c395531f6d44c0c30b9e52d136 16060 fonts-noto_20201225-5_all.deb
 2df97ff9eefb6913ac5fb32e64cc7cd21f68a7a2 9703 fonts-noto_20201225-5_amd64.buildinfo
Checksums-Sha256:
 8e3d4599bb47b5350eebc883f06dd8a9b99816fbb8fe1d9763a949988e3c39f0 2795 fonts-noto_20201225-5.dsc
 b7c170775e4732a5f58aec04f94a604e6c4c0b45a379aa0e06a84d8c3c85a587 111916 fonts-noto_20201225-5.debian.tar.xz
 3b624e4196661b12129143ddf0ef80f2f946ab94bc2e21a9951e7dc70362458d 1560528 fonts-croscore_20201225-5_all.deb
 da6115ab7211b1877337600b1b7ed1d2cab4d55dd9c288bd515ec1affb750845 12174864 fonts-noto-core_20201225-5_all.deb
 48825565992633c43c08a355993c6078d978f14c7232e65d5a1d3e4395bf902f 72411788 fonts-noto-extra_20201225-5_all.deb
 b65ccd3306eec9b4b81fa121ec2b30bc0730255bbb1dabeeafad238fa6642d79 145564 fonts-noto-hinted-udeb_20201225-5_all.udeb
 ede264d08b81ee46826a98ff4cb620785ca296a757480d3ce3a925cfe9c4d74a 4756 fonts-noto-hinted_20201225-5_all.deb
 bc444775973318f071c26bc9ece0d8458a7013fa1fa0f78cca778d307e5e3691 385636 fonts-noto-mono_20201225-5_all.deb
 d14eaddba40cb773dbcc93920febcb47410609b0468cdb947a64a7d1734cd4fa 1408080 fonts-noto-ui-core_20201225-5_all.deb
 f5f8e91c4f7228700185e429f14de1a84d79f8d1e7b36f78338af49578061177 14239252 fonts-noto-ui-extra_20201225-5_all.deb
 465015ba9adf04e031fe090e61b6bf617025d0cbcc5fed94e99d07220feafbe7 10483188 fonts-noto-unhinted-udeb_20201225-5_all.udeb
 f3a2310cc4cd7a28607220e20a37cb090776917fc38807dd0937a1dc0c437eb8 4988 fonts-noto-unhinted_20201225-5_all.deb
 60b8f7062f174bbbdc6a76dea5b0707cbbab1b57ad3d94cc5d9c6cfb22ceab17 892920 fonts-noto-web_20201225-5_all.deb
 02633c90e031b7735e23a6fb0870daec3b9d5eb8f6d08ad7aefa008fd7733dfc 16060 fonts-noto_20201225-5_all.deb
 8af3f42b1a794d104d2609c139c6ed38ed954a0a186462d7d06bc74eb6292226 9703 fonts-noto_20201225-5_amd64.buildinfo
Files:
 ea7da74d50c9e4cbc3d394d7bfd49541 2795 fonts optional fonts-noto_20201225-5.dsc
 86e94ecee74862f831af08789a8871eb 111916 fonts optional fonts-noto_20201225-5.debian.tar.xz
 61cfb6b507143fef312e2e1484158cde 1560528 fonts optional fonts-croscore_20201225-5_all.deb
 4e90fef759eeafba509df788d2d91771 12174864 fonts optional fonts-noto-core_20201225-5_all.deb
 2f9e0c4718d3bf3a4406e3910e3a9a32 72411788 fonts optional fonts-noto-extra_20201225-5_all.deb
 e335ab642cb1b453c5452ce4b60b1f09 145564 debian-installer optional fonts-noto-hinted-udeb_20201225-5_all.udeb
 df7d9ad166fb58e7120a49b9aaf5ce78 4756 oldlibs optional fonts-noto-hinted_20201225-5_all.deb
 7c8d4124e4e74a55159cde90f1f714d7 385636 fonts optional fonts-noto-mono_20201225-5_all.deb
 dc5d2ba05ad4c0d99928e618669a54da 1408080 fonts optional fonts-noto-ui-core_20201225-5_all.deb
 2feeb05851d2e19e486ffaf49a7fa954 14239252 fonts optional fonts-noto-ui-extra_20201225-5_all.deb
 357094e65c7795d81013cfe2c2ffc28b 10483188 debian-installer optional fonts-noto-unhinted-udeb_20201225-5_all.udeb
 0f97e2ae41068df8aeb3b1915c963606 4988 fonts optional fonts-noto-unhinted_20201225-5_all.deb
 776750f67b3bfedf1fbdc31a71db8316 892920 fonts optional fonts-noto-web_20201225-5_all.deb
 99b738f8bbd3ad5245e5c4fa6e931277 16060 metapackages optional fonts-noto_20201225-5_all.deb
 4e39e0bd7b176f091dd4aa7517781ed3 9703 fonts optional fonts-noto_20201225-5_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEj23hBDd/OxHnQXSHMfMURUShdBoFAmnxG3AACgkQMfMURUSh
dBpYBg/+JDgVc7EhfV/+Fj0beIrbDcwjwcj7QJuR0eytQFLPUaQ1YL8Qzkod5aDp
ASgjVf3QTFz5vgv3dl7GsbWAvLZ4X9gk7MrZQMrtSZLZ4o4KWNJDKjUN21SW+NdB
ygBbth81WI8D89fYQTi3xAwplwet7ZqV2/7ZKIaaYmF3XshAzhTvv5L2jh1bIEDu
BoozvsIPbsjxXEOWKa7zLPnGP3ZhOpaEQ/U7pR4ipC8uADqJ+ZRrP9bU05rep8vD
XJ+heYvfsuzloq9M01cxmjjItzet8St9Z+QhHi1RjSJqC8veVSzo8H9r2IMfdhed
wCfGUMz6KeOJfJ+yHVWImtMbBvTAOcmz1hK2v/Uw1z3Plzh+Rv5isztvRGlDZhjt
H6AVz/cQyz9aFzEQeA8Hp5Ap0pPtUZCgCRhUZiUHisFY8on1E4z3sKdVesbfHo2c
cGJPAj+UnvTKr6CLIBnsIVHGRxaiPsvvUyXBzLCGWa0tJZ1ggn5fi8eWt59Q/i35
lQVA+pWqyGFjNxQ7ZjagAq164oArBcAciNF8mu5wnrvForYxaBXfEiJdyCDczb4l
gTs6i3H2ySxi24/XltgUz0bjJEYAw8ipC227HSVUpY4epSqj1PhSUaN17iQQ5EXD
55oBIAi5SIT96q5Llx1IuxoJAiXBhKI7FkHAj0ygUE/228+gbnw=
=YWTl
-----END PGP SIGNATURE-----

I think is wrong for fonts-noto to provide a binary package
containing only a synthesized variation for a minor subset of its
fonts.

I find it wrong to go ahead and introduce such new package without
discussion.

I think the right cause of action now is to revert that change and drop
the newly introduced binary package fonts-noto-web.

Raising severity to avoid the package change to reach testing.

 - Jonas

Are you saying you would prefer that it shipped all the fonts in WOFF2 format
instead of just a subset?  If so, I would imagine that would be easy to do.

Wow, Jonas, applying a RC bug? That's pretty aggressive!

Could you support your "opinion" with something more technical, like the
Debian Policy, for example? I mean, what technical flaw does fonts-noto-web
have?

And regarding the consensus, the MR was there to discuss it for several
days. A responsible maintainer would have given their opinion directly in
the MR, stating that they disagreed with the update. In any case, if you
need a consensus, we still have time to try to achieve it (or not) instead
of completely blocking the package...

Regarding the fonts-noto update, I imagine you also prefer to keep the
vendorized CDBS options as well...

This only leads me to think that you don't allow anyone to touch your
packages.

I'd like to know Detiste's opinion on this. If the consensus is to roll
back fonts-noto, then that's fine by me.

Sorry if I sound rude.

Best regards,

Hello.

I just would like to point out that the maintainer of a package has
always the freedom to apply the serious severity for bugs in their
*own* package (i.e. it is not really necessary to mention any
precise item in policy).

https://www.debian.org/Bugs/Developer.en.html#severities

serious
[...]
or, in the package maintainer's [or release manager's] opinion,
makes the package unsuitable for release.

Thanks.

Quoting Soren Stoutner (2026-04-29 23:21:23)

With the subset you are quoting, I intended to say that the chosen
solution for the larger problem that I am only vaguely touching in my
full post and not discussed at all before the package change, is one
which I find wrong for several reasons.

No, I will not begin a discussion from "should we do more of this?" but
want to discuss the bigger picture.

 - Jonas

Quoting Manuel Guerra (2026-04-30 02:27:21)

From my point of view, you appear out of the blue and make a radical
change to a gigantic package with zero coordination ahead of that
change.

RC bugs are for more that Policy violations. I already stated my reason
for raising severity.

Interesting that I am to blame here for lack of collaboration. This is
clearly not working: I do not use MRs. I don't know who enabled MRs for
this package, but you should expect MR-style collaboration from those
who did, and not assume that everyone in Debian nor everyone in the
fonts team use that communication style. The fonts team has a
mailinglist that you can expect all team members to follow, if you want
to ensure that all have been heard and all are fine with you doing a
major change.

Oh, and "several days" is in my opinion not an acceptably sized window
for major packaging changes.

We have time until next freeze, indeed.

Do you also assume that I am racist and white and male? Or where did
that accusation spring from, and what on Earth does that have to do
with my putting a pause on an uncoordinated major packaging change?

Please elaborate. I would genuinely want to understand how you reach
that position. Is it my choice of using CDBS or my use of the BTS or
something else that you find a clear indication of me being antisocial?

Why Detiste? Because he has intimate knowledge on the Noto font
packaging, or...?

 - Jonas

Hi,

I m on VAC till Sunday and my phone data plan is depleted so I ll try to
keep short.(PS: I failed)


There were fears about one year ago that I broke the udeb's generation by
changes done in CDBS. Since then I had been validating changes in CDBS by
running debdiff and diffoscope on the result of rebuilding fonts-noto and
other.

I was happy to see Manuel's MR that would had allowed me to have all of
this further behind me.

I was very tempted to cherry pick from his MR only the CDBS -> DH bits and
revert the web package until next week.

I felt that doing that would had been disrepectfull of Manuel's work on my
part, and I saw no one complaining on the bug report.

What's the tipping point: we now have a NEW queue that works correctly.

~

Manuel could fork src:fonts-noto to build his webfont package but that
seems a very technicaly bad "legal" solution and I hope everyone will find
a better consensus.

~

I agree this package is just _too_ big (for Salsa CI for example) and the
plan to switch to newer/smaller splitted upstream releases seems better.
But I have a very shallow knowledge of this package and don't know the
orthogonality with the webfonts and udeb package... I m curious of the
outcome and will keep up reading but I guess I won't have anything more
valuable to contribute.




Greetings

Alexandre

On Wednesday, April 29, 2026 10:27:43 PM Mountain Standard Time Jonas Smedegaard wrote:
do.

I am sorry that this change has generated a lot of anger and bad feelings.  It
was certainly never my intention when submitting this request.  I genuinely
don’t understand what the bigger issues are that have been triggered, but I
would like to understand them so that everyone can reach an amicable
resolution.  As I understand it, the change that adds the WOFF2 fonts and
originally closed this bug report also made some changes from CDBS to DH.

Based on the email communications, I can imagine three possible concerns:

1.  Shipping some of the fonts as WOFF2 without shipping all of them.
2.  Converting the build system from CDBS to DH.
3.  Communicating on an MR instead of the BTS.

There are possibly other concerns that I have not picked up on.

Jonas, do all of the above concern you, or just some of them?

I am really hoping that we can find a way forward on the WOFF2 issue, so that
I can stop shipping fonts inside of the redmine package.  From a personal
perspective, I don’t have a strong position on the other issues and would hope
that we can do whatever accords with your wishes as the package maintainer.

We believe that the bug you reported is fixed in the latest version of
fonts-noto, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1116004@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Smedegaard <dr@jones.dk> (supplier of updated fonts-noto package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 14 May 2026 07:29:18 +0200
Source: fonts-noto
Architecture: source
Version: 20201225-6
Distribution: unstable
Urgency: medium
Maintainer: Jonas Smedegaard <dr@jones.dk>
Changed-By: Jonas Smedegaard <dr@jones.dk>
Closes: 1116004
Changes:
 fonts-noto (20201225-6) unstable; urgency=medium
 .
   * Friendly takeover,
     confirmed by all active maintainers of the package;
     add myself as uploader; update Vcs-* fields
   * drop binary package fonts-noto-web; closes: bug#1116004
Checksums-Sha1:
 1d6e5b5ea217fc357bf38fc5719e7c36af3fe154 2699 fonts-noto_20201225-6.dsc
 12708bed469ae8cbc7a030c335a62b39b14c2e80 111020 fonts-noto_20201225-6.debian.tar.xz
 38aae6faeb1f8fa54c18de62abb7998d6e3e6608 8824 fonts-noto_20201225-6_amd64.buildinfo
Checksums-Sha256:
 df8a81f0d6fd5740c8a7f11f2d6241d0b3b1ca19a2b3c9d4705a01350b1adf78 2699 fonts-noto_20201225-6.dsc
 589476694940ec77f62d9d9377df878e7090b404652429823fa45085b053c650 111020 fonts-noto_20201225-6.debian.tar.xz
 67ae15ff5fd11771b571976f935dc8eb6fa8b6522fdc7f2ec27ab67244716ed5 8824 fonts-noto_20201225-6_amd64.buildinfo
Files:
 80d9404e4bcd4bc6b7f49e999ac27ad7 2699 fonts optional fonts-noto_20201225-6.dsc
 16c41598b471014e7e77e186b136d972 111020 fonts optional fonts-noto_20201225-6.debian.tar.xz
 eb6557847d5d8c539baea1087cfc747b 8824 fonts optional fonts-noto_20201225-6_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmoFX9oMHGRyQGpvbmVz
LmRrAAoJECx8MUbBoAEhWkIP/RqEC6eVoETRC3wnVmDaEAub2O+TL/v8IUnWvTu9
PLJ3P5WZGwZ4nCJEXn0Q++PPIYVAVk9r26exfcVp5qw8JpQy6iRE1FhHarwjbHOy
6mxwpDdO64MMppSC9UhzLReNV2eXbp+4k5RwSxl4Ogew6MohZ3kmHxln/e8LB9WP
ObzrLY18ZnyBCxaGilhDXa0OBZk1XSTwoDEvJFJWfQsl4IiFvCTZ6TuR5w8+3SFq
IgNQkTx0uc0Mk9YKykzI5As2uyxDxBkkpkgszVllNj1Kf89EjOZSBZGEYkkNvUBP
LTAuIhpaUf0NcqI87jjxE5O9mO6PkEvqNU4Jr2Qax0nUYFhd2fDCvO26nXiCCa5v
lKXmanJYoTCTBTVOkHzVB+ys1z4wxCxC+X0CRtnPhH7EupLfmezdxvq4rOOvd/5M
drdKnI41HwCVF/Zxef0rZPMnyJlIPy9tJlTUTkdLNUXiGc0ch5mxzk1Zv1f+Ng7e
VrOYsVmyllN+l86ksmJH1Cl4h7fZsJ6svj0gjtwPm7mFNXjS1+34OWitOZYJLI3z
lnI5iMtpP6F515glhLnVFfpmPRaeNP4ziD1fZx6yRDv/KnTtHLeDUKei8WQkcUUj
CFz6xJIKG+AU7gBv7MWWG43oA5QmO5FqhnilonVhCaN2fUkkyU0FzUgKe4aA6GEN
x8LR
=tXuT
-----END PGP SIGNATURE-----

Jonas,

Is there a way we can ship the .woff2 versions of these fonts?

Hi Soren,

Quoting Soren Stoutner (2026-05-14 19:04:29)

I see several ways:

 a) have redmine build-depend on fonts-noto and a compressor,
    and compress during build
 b) have redmine depend on fonts-noto and a compressor,
    and compress during install
 c) introduce new source package src:fonts-noto-web that
    build-depends on fonts-noto and a compressor
    and compresses during build,
    and then have redmine depend on fonts-noto-web
 d) introduce new source package src:webfonts-common
    which offers a hook for packages to request compression of fonts,
    and have redmine depend on and provide hook for webfonts-common
 e) convince maintainers of javascript-common to implement a hook
    for compressing fonts,
    and have redmine depend on and provide hook for webfonts-common
 f) convince maintainers of fonts-noto to build-depend on a compressor
    and extend the package with webfont-support,
    and have redmine depend on that

 - Jonas

It seems to me that the way this is generally handled in Debian is (f), which
is to have the fonts-noto source package compress and ship the woff2 fonts.

In some cases they use a separate package called -web or something similar.

https://tracker.debian.org/pkg/fonts-dejavu
https://tracker.debian.org/pkg/fonts-atkinson-hyperlegible
https://tracker.debian.org/pkg/fonts-tlwg

In other cases, they ship the woff2 fonts in a binary package that includes
other font formats.

https://tracker.debian.org/pkg/fonts-materialdesignicons-webfont

Is this something you would consider as the maintainer of the fonts-noto
package?

Quoting Soren Stoutner (2026-05-15 18:52:10)

How did you reach that conclusion?

Here is a quick'n'dirty count:

jonas@cairon:~$ apt-file search -l .woff2 | grep -c .
858
jonas@cairon:~$ apt-file search -l .woff2 | grep -c ^fonts-
35

What am I missing?

 - Jonas

Those are exactly the types of bugs I am attempting to fix.  Specifically,
those trigger the following 2 lintian tags:

https://udd.debian.org/lintian-tag/font-in-non-font-package

https://udd.debian.org/lintian-tag/font-outside-font-dir

You can see how those affect redmine:

https://udd.debian.org/lintian/?
email1=&email2=&email3=&packages=redmine&ignpackages=&format=html<_error=on<_warning=on<_information=on&lintian_tag=#all

As you noted, .WOFF2 fonts are particularly affected by this (858 times),
because a lot of upstream packages ship them in their tarballs, especially web
applications.  The purpose of this bug report is to handle this in a more
Debian-appropriate way for noto by shipping the .WOFF2 fonts in a font package
and then linking to them from the web application.

Quoting Soren Stoutner (2026-05-26 01:52:39)

Sorry, I lost you there.

You state Debian use a specific approach, and I ask you how you
conclude that. I still don't read from this follow-up an elaboration on
that.

Do you mean to say that you agree that Debian currently package WOFF2
fonts in each binary package that needs them, and that you instead
*envision* a different approach?

Earlier, you asked how it could be done. It seems you don't care how it
can be done, you already know how you want it done and only care to
discuss that. I am not really excited to engage in that type of
conversation, and hope that I am mistaken about that impression of your
conversation scope here.

 - Jonas

It seems we have been suffering from a lack of communication, which isn’t my
intention.  Let me try to describe the problem from the beginning in a way
that I hope will be more helpful.

I believe it is the general consensus in Debian that fonts should only be
packaged by font packages and that these fonts should be installed inside
/usr/share/fonts/.

This general consensus is expressed in the following two lintian tags:

https://udd.debian.org/lintian-tag/font-in-non-font-package
https://udd.debian.org/lintian-tag/font-outside-font-dir

Upstream programs are often packaged with embedded fonts, particularly web
application.  Sometimes these have slipped into the Debian packaging instead
of properly being remove and simlinked to the appropriate Debian font package.
Debian contains a number of such packages with inappropriate embedded fonts,
some of which have existed in the archive for quite a long time.  Redmine is
such a package.  Since taking over maintenance of the redmine package, I am
attempting to clean up these packaging bugs.

I do not think that all font packages need to ship .WOFF2 variants.  I
maintain the fonts-adobe-sourcesans3 package, wich doesn’t ship .WOFF2 fonts
because there aren’t currently any package in Debian that would consume them.
However, if a package were to start needed them, and a bug was filed against
fonts-adobe-sourcesans3 request that I ship the .WOFF2 fonts, I would be happy
to do so.

Looking at how this is handled by other font packages, sometimes they ship the
.WOFF2 fonts in a separate binary package (sometimes named -web).  In other
instances they ship them in the same binary package as the other fonts.
Either seems appropriate depending on the size of the font packages and the
maintainer’s preference.

My request is that you ship these fonts as part of the fonts-noto source
package, either in one of the existing binary packages or in a new binary
package.  I genuinely do not understand why there would be any opposition to
doing so.

Quoting Soren Stoutner (2026-05-26 20:00:58)

The above lintian tags are both about system fonts, not recompressions
of fonts targeted web browsers.

I am unaware of any consensus in Debian on how to handle recompression
of fonts for targeting web browsers. The optimal likely involves
subsetting to only include glyphs relevant for the scope of the web
application.

You asked for possibilities, I provided you are list of possibilities
which you then ignored, and insist on the one approach that you try to
frame as already common in Debian. I fail to recognize that to be the
established common approach, and I dislike you framing me as being the
weird stubborn outsider here.

 - Jonas

my

Both of these tags flag against the WOFF2 fonts embedded in Redmine.

https://udd.debian.org/lintian/?
email1=&email2=&email3=&packages=redmine&ignpackages=&format=html<_error=on<_warning=on<_information=on&lintian_tag=#all
instead
fonts
against
to

Perhaps I am incorrect about there being a consensus on this topic.  Would you
prefer if I asked on the Debian Fonts mailing list?

I am not trying to frame you as being a stubborn outsider here.  I am just
trying to discuss my understanding of how these scenarios are typically
handled in Debian.

Quoting Soren Stoutner (2026-05-26 21:33:51)

Right.

I am not interested in discussing only *your* understanding, omitting
other views or ideas or proposals.

 - Jonas.

On Tuesday, May 26, 2026 2:39:50 PM Mountain Standard Time Jonas Smedegaard wrote:
Smedegaard

Can you provide any information that the other ways you proposed dealing with
the situation are the consensus for how WOFF2 fonts should be packaged in
Debian?

I have a question for the Debian Fonts mailing list regarding the correct way
to package WOFF2 (or WOFF or other web font formats).  As background, a number
of applications in Debian include fonts as part of their upstream tarballs.
Generally, it is considered best to remove these fonts from the Debian
packages and depend instead on the appropriate Debian font package.  In the
case of web applications, in recent years the use of WOFF and WOFF2 fonts have
become common.  WOFF and WOFF2 are compressed versions of TTF and OTF fonts.
There are a number of tools in Debian that can perform these conversions, like
woff2_compress or sfnt2woff-zopfli.

There are a number of fonts packages in Debian that already ship WOFF or WOFF2
fonts.  Sometimes they do this in separate binary packages (offen suffixed by
-web) and other times they do this in the same binary package that ships the 
TTF and OTF fonts.  For example:

https://tracker.debian.org/pkg/fonts-dejavu
https://tracker.debian.org/pkg/fonts-atkinson-hyperlegible
https://tracker.debian.org/pkg/fonts-tlwg
https://tracker.debian.org/pkg/fonts-materialdesignicons-webfont

I maintain the redmine package, which is a web application that ships several
WOFF2 versions of NotoSans in the upstream tarball.

I filed #1116004 requesting that fonts-noto start shipping WOFF2 versions of
their fonts so I could stop shipping them in redmine.  The bug report went
unanswered for a while until a DM named Manuel Guerra prepared an MR that
added a new binary package named fonts-noto-web.  This MR was posted to the
bug report, at which point one of the maintainers of fonts-noto, Jonas
Smedegaard, responded to the bug report suggesting one of the utilities for
converting TTF to WOFF2.  Alexandre Detiste reviewed Manuel Guerra’s MR and
sponsored it as a team upload.

After the upload, Jonas Smedegaard objected to the changes, reverting them
entirely with the next upload.  I believe this was the first time than anyone
involved had any indication that he was displeased in any way with what was
being done.  The core of his objection appears to be that he thinks some other
package should produce the WOFF2 fonts instead of fonts-noto.  He expresses
this here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116004#95

My understanding is that there is a consensus in Debian that fonts should
generally be shipped only by font packages, and that those fonts should be
installed under /usr/share/fonts/.  This is reflected in the following lintain
tags:

https://udd.debian.org/lintian-tag/font-in-non-font-package
https://udd.debian.org/lintian-tag/font-outside-font-dir

Jonas’ opinion is that this only applies to font formats like TTF and OTF, not
WOFF and WOFF2, even though these two lintian tags flag against the WOFF2
fonts in redmine.

https://udd.debian.org/lintian/?
email1=&email2=&email3=&packages=redmine&ignpackages=&format=html<_error=on<_warning=on<_information=on&lintian_tag=#all

My questions for the mailing list are these:

1.  Is there a general consensus in Debian that WOFF2 and other web fonts
should be shipped by font packages (when there is a need for them) and that
they should be installed under /usr/share/fonts/?

2.  If not, what is the recommended way for these fonts to be packaged?

Quoting Soren Stoutner (2026-06-10 01:41:45)

If you seek a general consensus in Debian, then it seems more sensible
to me to raise the question in Debian generally, rather than within a
team context.

That said, I find it sensible to raise it in the team, just wanted to
point out that limited scope of discussion implies limited range of
replies.

 - Jonas

Am 2026-06-10 01:41, schrieb Soren Stoutner:

In the font packages that I maintain, I generally keep the web fonts in
the same package as the TTF/OTF variants, but keep them out of the
/usr/share/fonts name space. The reason is that (1) they are duplicates
anyway and (2) fontconfig may pick them up as valid candidates for font
rendering but they will mostly fail to get rendered. (I think their
headers look like regular TTF fonts, but their actual content is
compressed).

I'd recommend as above.

Cheers,

  - Fabian

1.  Where do you place them?  I see some examples of /usr/share/custom-font-
directory/.

https://packages.debian.org/sid/all/fonts-atkinson-hyperlegible-web/filelist

2.  Is anyone aware of any problems caused by the packages that do place them
in /usr/share/fonts/WOFF/ or /usr/share/fonts/WOFF2/?

https://packages.debian.org/sid/all/fonts-dejavu-web/filelist
https://packages.debian.org/sid/all/fonts-thai-tlwg-web/filelist


Here is an example of a package that does both.  I am not sure what the
purpose of that is:

https://packages.debian.org/sid/all/fonts-materialdesignicons-webfont/filelist

-------- Ursprüngliche Nachricht --------Von: Soren Stoutner <soren@debian.org> Datum: 11.06.26  18:04  (GMT+01:00) An: 1116004@bugs.debian.org, Debian Fonts <debian-fonts@lists.debian.org> Betreff: Re: Bug#1116004: fonts-noto: fonts-noto-web is wrong On Wednesday, June 10, 2026 12:39:36 AM Mountain Standard Time fabian@greffrath.com wrote:> Am 2026-06-10 01:41, schrieb Soren Stoutner:> > 1.  Is there a general consensus in Debian that WOFF2 and other web> > fonts> > should be shipped by font packages (when there is a need for them) and> > that> > they should be installed under /usr/share/fonts/?> > In the font packages that I maintain, I generally keep the web fonts in> the same package as the TTF/OTF variants, but keep them out of the> /usr/share/fonts name space. The reason is that (1) they are duplicates> anyway and (2) fontconfig may pick them up as valid candidates for font> rendering but they will mostly fail to get rendered. (I think their> headers look like regular TTF fonts, but their actual content is> compressed).1.  Where do you place them?  I see some examples of /usr/share/custom-font-directory/.https://packages.debian.org/sid/all/fonts-atkinson-hyperlegible-web/filelist2.  Is anyone aware of any problems caused by the packages that do place them in /usr/share/fonts/WOFF/ or /usr/share/fonts/WOFF2/?https://packages.debian.org/sid/all/fonts-dejavu-web/filelisthttps://packages.debian.org/sid/all/fonts-thai-tlwg-web/filelistHere is an example of a package that does both.  I am not sure what the purpose of that is:https://packages.debian.org/sid/all/fonts-materialdesignicons-webfont/filelist-- Soren Stoutnersoren@debian.org

-------- Ursprüngliche Nachricht --------Von: Soren Stoutner <soren@debian.org> Datum: 11.06.26  18:04  (GMT+01:00) An: 1116004@bugs.debian.org, Debian Fonts <debian-fonts@lists.debian.org> Betreff: Re: Bug#1116004: fonts-noto: fonts-noto-web is wrong On Wednesday, June 10, 2026 12:39:36 AM Mountain Standard Time fabian@greffrath.com wrote:> Am 2026-06-10 01:41, schrieb Soren Stoutner:> > 1.  Is there a general consensus in Debian that WOFF2 and other web> > fonts> > should be shipped by font packages (when there is a need for them) and> > that> > they should be installed under /usr/share/fonts/?> > In the font packages that I maintain, I generally keep the web fonts in> the same package as the TTF/OTF variants, but keep them out of the> /usr/share/fonts name space. The reason is that (1) they are duplicates> anyway and (2) fontconfig may pick them up as valid candidates for font> rendering but they will mostly fail to get rendered. (I think their> headers look like regular TTF fonts, but their actual content is> compressed).1.  Where do you place them?  I see some examples of /usr/share/custom-font-directory/.https://packages.debian.org/sid/all/fonts-atkinson-hyperlegible-web/filelist2.  Is anyone aware of any problems caused by the packages that do place them in /usr/share/fonts/WOFF/ or /usr/share/fonts/WOFF2/?https://packages.debian.org/sid/all/fonts-dejavu-web/filelisthttps://packages.debian.org/sid/all/fonts-thai-tlwg-web/filelistHere is an example of a package that does both.  I am not sure what the purpose of that is:https://packages.debian.org/sid/all/fonts-materialdesignicons-webfont/filelist-- Soren Stoutnersoren@debian.org

themin

That is an informative bug report.  The upstream conversation indicates it
still isn’t resolved.

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/work_items/92

Based on that, I think Debian should consider it a bug for WOFF or WOFF2 fonts
to be installed under /usr/share/fonts/.

It appears that the convention currently used by several packages is:

/usr/share/fonts-fontname/woff/
/usr/share/fonts-fontname/woff2/

Does anyone have any objections if we standardize that as a policy
recommendation and update the lintian tests to match?

-------- Ursprüngliche Nachricht --------Von: Soren Stoutner <soren@debian.org> Datum: 11.06.26  22:22  (GMT+01:00) An: 1116004@bugs.debian.org, Debian Fonts <debian-fonts@lists.debian.org> Betreff: Re: Bug#1116004: fonts-noto: fonts-noto-web is wrong On Thursday, June 11, 2026 1:05:20 PM Mountain Standard Time Fabian Greffrath wrote:> > Is anyone aware of any problems caused by the packages that do place themin> > /usr/share/fonts/WOFF/ or> > /usr/share/fonts/WOFF2/?> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=8> > 63835This refers to Xetex, but may apply to other applications as well.  -That is an informative bug report.  The upstream conversation indicates it still isn’t resolved.https://gitlab.freedesktop.org/fontconfig/fontconfig/-/work_items/92Based on that, I think Debian should consider it a bug for WOFF or WOFF2 fonts to be installed under /usr/share/fonts/.It appears that the convention currently used by several packages is:/usr/share/fonts-fontname/woff//usr/share/fonts-fontname/woff2/Does anyone have any objections if we standardize that as a policy recommendation and update the lintian tests to match?-- Soren Stoutnersoren@debian.org