Dear Maintainer,

Would it be possible to upload the latest upstream release.

Thanks in advance

Best regards

Mike

+1 from me (and I'm happy to do an NMU if this helps); the newer fonts
are required for the new version of Spyder.

Best wishes,

   Julian

ready to upload to unstable if wanted.

Key change: The SVG fonts are no longer shipped by upstream with the
webfonts; they are now in a seperate repository.  So my package does
not include the SVG fonts.

Medium change: I've upgraded to 5.5.55.  This is the last version with
a clear license and copyright statement.  The current one is too vague
to pass DFSG, but they are working on it (see
https://github.com/Templarian/MaterialDesign/issues/5777).

Smaller changes: I've updated the debhelper-compat to (= 13), and now
Build-Depends: openstack-pkg-tools; having debian/rules potentially
behave differently depending on whether this package is installed or
not seems quite unwise.  I've also removed one of the lintian
overrides (tabs in copyright file - I replaced the tabs with
spaces!).  The override for preview.html is a bit more problematic: it
is clearly auto-generated from something, but I have no idea how.

My Git repository is on salsa at
https://salsa.debian.org/jdg/fonts-materialdesignicons-webfont

It is a fork of the OpenStack salsa repository, but I encountered some
significant problems using it, most notably, the final commit on the
master branch does not exist in the current upstream GitHub
repository, so it is not possible to cleanly merge the current
upstream.  One could do a git reset --hard HEAD^ on that branch and
then merge the current upstream and force push to salsa.  What I did
instead was to create a new branch called upstream which is now
up-to-date with the upstream GitHub repository, and base my debian
version on it - it is in the branch debian/unstable.  Somewhat sadly,
though, this means that the history of the debian/* files is lost, but
I don't think it's that big a deal.

I can't make a pull request for my work against your repository, as
these two branches are not forked from any of your existing branches
because of the upstream discrepancy.

Finally, there is a piece of BOM removal code in the debian/rules
file.  This seems to be historic, as scss can now happily process the
scss files even with the BOM present.  (I reported it upstream at
https://github.com/Templarian/MaterialDesign/issues/5778)

Best wishes,

   Julian

There has been no progress or follow-up on this bug report in over two
years.

I also recently noticed that some of the icons in the existing font
are brand icons which should be removed because of licensing issues.
Also, this package is not built from source - it is the precompiled
fonts build using @mdi/font-build.

My proposal is to repackage this using @mdi/font-build to actually
build the font from source, removing the brand icons first.  I'll NMU
this when the required node packages are packaged and have reached
unstable.  If you'd prefer me to take the package over, or to add
myself as an uploader, I'm also happy to do that.  I'll do the work in
a new repository since the existing one (as already noted earlier in
this thread) is too muddled to really build on it.

Best wishes,

   Julian

Dear all,

I have now uploaded a package (version 7.1.96-1) to DELAYED/7-day,
closing this bug; it will also have to go through NEW processing
before it is accepted into unstable.  You can see the package at its
new salsa location
https://salsa.debian.org/debian/fonts-materialdesignicons-webfont

I realise that with the lack of response to this bug report, I should
have gone through the salvage process; I will begin that now with a
separate bug report.

Best wishes,

   Julian

Hi Julian,

I'm ok to add you as uploader if you like, but I would like the package
to stay in the OpenStack team. I have given you write access to the Git
(as maintainer).

Cheers,

Thomas Goirand (zigo)

Hi Thomas,

Thanks for that; happy to accept the offer!  I do have some questions
and thoughts.

(1) As I noted earlier in this report, I was a little confused by the
current Salsa repository, but am becoming less so.  There are numerous
branches there, and none of them match the current version in unstable
(they only have 1.6.50-2).  I'm assuming the branch names match the
OpenStack release names (except for the debian/unstable and master
branches).  I would suggest modifying the repository into a
git-buildpackage (gbp) setup with upstream, pristine-tar and
debian/unstable branches, with debian/[openstack-code-name] branches
being used as they are currently.

(2) You said that newer versions of MDI break Horizon.  I've just
looked in some detail at python3-xstatic-mdi, which is the only
package that depends on fonts-materialdesignicons-webfont and is
maintained by the OpenStack team.  Am I correct about this?  I see
that it is a plugin for python3-xstatic, and it appears to be quite
straightforward.  Now I am aware of the problem, I don't see a good
reason for removing MDI version 1.6.50 from Debian as the effort
required to make sure newer versions work correctly with Horizon
doesn't seem worth it.

However, we do need newer versions of MDI for other packages.  (I will
discuss this with the tulip maintainers; their code seems to require
version 4.9.95 of the icons...; on the other hand, searx-admin is
fine.)  So can I propose the following solution which will (all being
well!) work for both OpenStack and the other users of the MDI font:

* My version of the package in salsa currently produces the following
  binary packages:

  fonts-materialdesignicons-webfont - the current version of the font (7.x)
  fonts-materialdesignicons-webfont-v5 - version 5.9.55 of the font
  fonts-materialdesignicons-webfont-v6 - version 6.9.96 of the font
  fonts-materialdesignicons-webfont-v7 - the latest version 7 of the font

  These binary packages store the fonts in
  /usr/share/fonts/*/materialdesignicons-webfont/ (as in the current
  version of the package), and has symlinks to them in
  /usr/share/fonts-materialdesignicons-webfont/fonts; the different
  versions are distinguished by filename and fontname (with only the
  current version being called "materialdesignicons"; the others are
  called "materialdesigniconsv5" etc.).

* We would then add one further binary:

  fonts-materialdesignicons-webfont-v1 - version 1.6.50 of the font

  This package would provide the current contents of
  /usr/share/fonts-materialdesignicons-webfont in
  /usr/share/fonts-materialdesignicons-webfont/1.6.50
  (including the css, scss, fonts directories).  To avoid fontname
  conflicts, the contents of the fonts directory would *not* be
  symlinks to /usr/share/fonts but would be the actual fonts
  themselves.

  The only changes then required to the python-xstatic-mdi package for
  this to work are to modify debianize.patch from

+BASE_DIR = '/usr/share/fonts-materialdesignicons-webfont/'

to

+BASE_DIR = '/usr/share/fonts-materialdesignicons-webfont/1.6.50/'

  and to depend on fonts-materialdesignicons-webfont-v1 instead of
  fonts-materialdesignicons.

This way, everyone will be happy (I hope!).  The only small issue with
this solution is that the v1.6.50 fonts are not available in
/usr/share/fonts, but I don't think that is a problem as they are only
required by this one package (python3-xstatic-mdi), and the v1.6.50
fonts are not being provided as general-use fonts.


If you're OK with this idea, please could you either give me access to
the python-xstatic-mdi salsa repository or make these two changes
yourself once I have made the fonts-materialdesignicons-webfont
changes?  (These will have to wait for node-webfont to be accepted
into unstable and then the modified fonts-materialdesngicons-webfont
changes to pass through NEW as well, though that is likely to be
quick.)

In the meantime, I'll drop a line to the tulip maintainers....

Best wishes,

   Julian

That's correct. But you don't need to care. The only thing you need to
know, is that the current default branch is the one you should push to.
Currently, that's debian/zed.

There's no such thing as pristine-tar in the OpenStack packaging. The
workflow is described here:

https://wiki.debian.org/OpenStack/PackageUpdate#Import_upstream_changes_to_the_debian.2FOSRELEASE_branch

Yes.

I would very much prefer if this could be avoided, for example using
update-alternative (or something similar), to avoid breaking anyone
(changing the path is always disruptive). But I'm ok with this solution
if you think that's the easiest way forward.
Debian from simple Debian users...). You'd be breaking them. But it's
probably ok...

I've added you as maintainer, feel free to push directly to this repo.
Please note that on every push, packages are automatically backported to
the current stable. You may join #debian-openstack-commits to see the
build result.

Thanks Julian, for the work and contribution,

Cheers,

Thomas Goirand (zigo)

Excellent!

OK, I'll take a read of that.
called "materialdesignicons", and to have a version which is ancient
and never being updated seems a little un-Debian-like.  Since within
Debian, only this one package uses this version, I don't think my
proposed solution would be bad.  But it turns out there is a separate
difficulty - see below.

I've also been wondering why updating MDI breaks Horizon, and in what
way.  There is a DFSG issue with version 1.6.50 of the MDI font: it is
not distributed in source form, but rather in a compiled form.
Various tools were used to generate the different font formats, for
example.  So if there's a way to drop 1.6.50 from Debian (probably not
for bookworm - it's a bit too close, but for bookworm+1), that would
be great.

It seems that there's only one place in horizon (source) where the MDI
fonts are referenced (great encapsulation!!):
  openstack_dashboard/themes/material/static/horizon/_icons.scss

If I understand it correctly, this scss file replaces each FontAwesome
4.7 icon in the icon-swap list (eg "asterisk") with an MDI icon (in
this case "star").  My guess is that the problem with upgrading is
that two icons in that list no longer appear in the latest version of
MDI: "settings" has been replaced by "cog" (version 5.0.45) and
"desktop-mac" has recently been removed (version 7.0.96) with
"monitor" (already present in 1.6.50) recommended as a replacement.
So it might be that the following two-line patch:

-  cog: 'settings',
-  desktop: 'desktop-mac',
+  cog: 'cog',
+  desktop: 'monitor',

would be enough to allow horizon to use the current MDI fonts.  But I
don't use OpenStack myself, so I would certainly ask you or someone
else in the OpenStack team to test such a patch before releasing it
into the wild!

True, but we constantly upgrade packages in Debian to "the latest and
greatest" upstream versions.  And there's this bug report specifically
requesting an upgrade....

Now this may be tricky, because building the proposed new version of
the fonts requires the new node-webfont package; would that be
backported as well?  (BTW, I've just pushed a new version to my
experimental repository at
https://salsa.debian.org/debian/fonts-materialdesignicons-webfont
which generates a version 1.6.50 package as well as the newer ones.)

:-)

   Julian

and it's not happy:

The following packages have unmet dependencies:
 sbuild-build-depends-main-dummy : Depends: node-svg2ttf but it is not installable
                                   Depends: node-nunjucks (>= 3.2.3) but it is not installable
                                   Depends: node-parse-json (>= 5.2.0) but 5.1.0+~cs5.1.6-2 is to be installed
                                   Depends: node-xml2js (>= 0.4.23) but it is not going to be installed
                                   Depends: node-jasmine but it is not installable

So at least 4 (and quite possibly more) nodejs packages would have to
be backported to bullseye-backports to be able to do this.
(node-xml2js is too old in stable for this package.)

Best wishes,

   Julian

Another update:

* node-svg2ttf: requires node-xmldom to be backported
  * node-xmldom: builds with bullseye-backports
* node-nunjucks: builds with bullseye-backports
* node-parse-json: builds with bullseye-backports
* node-xml2js: builds with bullseye-backports
* node-jasmine: has the dependencies require to build, but the build
   fails on one of the tests

So it may only be six packages which require backporting in order to
backport node-webfont (once it reaches testing), but node-jasmine
might well require some additional help, perhaps from the maintainer;
it might be that it has a versioned dependency that has not been
declared in the build-depends.

Best wishes,

   Julian

We believe that the bug you reported is fixed in the latest version of
fonts-materialdesignicons-webfont, 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 973617@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thomas Goirand <zigo@debian.org> (supplier of updated fonts-materialdesignicons-webfont 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: Sat, 29 Nov 2025 14:55:11 +0100
Source: fonts-materialdesignicons-webfont
Architecture: source
Version: 7.4.47-1
Distribution: experimental
Urgency: medium
Maintainer: Debian OpenStack <team+openstack@tracker.debian.org>
Changed-By: Thomas Goirand <zigo@debian.org>
Closes: 973617
Changes:
 fonts-materialdesignicons-webfont (7.4.47-1) experimental; urgency=medium
 .
   * New upstream release (Closes: #973617).
   * Do not install .svg files (file is gone from uptream source).
Checksums-Sha1:
 8d6c21494d3937d90fa7ca8e2224dceb903a9b68 2316 fonts-materialdesignicons-webfont_7.4.47-1.dsc
 7d327ff9a6008e98c6c2a79aee123543d1fac09c 1625052 fonts-materialdesignicons-webfont_7.4.47.orig.tar.xz
 bf7b41a6f0630ce6b37d0ce31fa391893b54c80b 9404 fonts-materialdesignicons-webfont_7.4.47-1.debian.tar.xz
 07b3d2adcb08772b83c7013ab97190adf757562a 6067 fonts-materialdesignicons-webfont_7.4.47-1_amd64.buildinfo
Checksums-Sha256:
 ee3aac998e986dcdb16954dff6e8f1c1fc5d77bc239f3319bcfaa8f6120740dd 2316 fonts-materialdesignicons-webfont_7.4.47-1.dsc
 f0e958d8b7ad0207b7606a386c8b668a8fd520e93a21dfcdc2353dc41adefd58 1625052 fonts-materialdesignicons-webfont_7.4.47.orig.tar.xz
 5d93a4fb8895f620fecd7be10b634ed1d4118b49ec48daef64be14779b9bde3e 9404 fonts-materialdesignicons-webfont_7.4.47-1.debian.tar.xz
 e631360f5c3fd191c05287fcd323381c35ff29cb64b4a8d6d8f35468e3fef681 6067 fonts-materialdesignicons-webfont_7.4.47-1_amd64.buildinfo
Files:
 0bd11f69ffc9bded3fd0e885362a16f4 2316 fonts optional fonts-materialdesignicons-webfont_7.4.47-1.dsc
 bec977815236e3c7b90a835edba7bbf4 1625052 fonts optional fonts-materialdesignicons-webfont_7.4.47.orig.tar.xz
 a37b123741c9a04d3ccafce1b95a111f 9404 fonts optional fonts-materialdesignicons-webfont_7.4.47-1.debian.tar.xz
 300dd44cf89c93b98fc22a32ebadceff 6067 fonts optional fonts-materialdesignicons-webfont_7.4.47-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEoLGp81CJVhMOekJc1BatFaxrQ/4FAmkq/eQACgkQ1BatFaxr
Q/596g/9GYyyGtzDave6qERn0er7SXa5pWst5IeOn9yssvQA9UktnquRR7COM8JV
ez5701TybPsbuLiOUq6PH1KBYPqmlm3josJbU+Mu6pWJZDdwRAi0vM8H0g6J64Cu
BMWtbG+DyIpIGRtB6DYRWsLv1vlVBwo5ccRHJ/yibHQbEQU792GwHZ1oekiNlyRv
WE+k9ZIvHN85OR3K6GKvMnZDQVMH397Bc/VS+f7r8LcFFxJAHPMIcM3e5p13YHBX
VrK7mOpdwZ7CTnmIsUGLkjTB3td+O6EOVjV900ThY8SZaArHMJ+U3nGYR6YyGC70
Xxbp1EF0iKx90z9gyhqNKsxnqySdRkdtCbL4JToon0arxQVVxFmKbBryyhzNQu02
+ClJVDP2lReS2Bqj6OUChIos0NLs1AUJYRgTKUg/7I/UR4mOrKErSCHh92vuiQg1
k16x5i0lPOcIMjfVz5jf9tKOEp0X8bTVEwt1HxyDe6BBwRjW6XFuoRrHjGIAMaTg
V6MXdLFk916MKrTtQGGBIgw18N9VXzooeU5A9I7mKC5SdVdJ8Oo6lFKOb/dmUOQr
LU90Td9Y6ORZXXlHx805p76H8K8xXuJpLHbdpX0PpUZvfldVoXwoow1viSMES+U9
0ZBMdbIfmOS1GLAKj0kg2lYCPu6YOd1ryEM7Gv+8ICK6k5sA3fk=
=e4mU
-----END PGP SIGNATURE-----

Dear Thomas,

I was just thinking about this bug, and took a look at it again.  I've
just seen that you've uploaded 7.4.47-1 to experimental.  Amazing,
thank you!  This is much simpler solution than I was proposing, giving
just one version of the font.  (If DFSG requirements mean that you
need to have source for the font, I can advise on how to achieve that,
or even do it - all of the required components are already in Debian.)

Best wishes,

   Julian