Re-lint

https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/package/pt-sans-fonts/

https://download.copr.fedorainfracloud.org/results/nim/fonts-rpm-macros/fedora-rawhide-x86_64/01296922-pt-sans-fonts/pt-sans-fonts.spec
https://download.copr.fedorainfracloud.org/results/nim/fonts-rpm-macros/fedora-rawhide-x86_64/01296922-pt-sans-fonts/pt-sans-fonts-20141121-12.fc33.src.rpm

Good that I saw this package review same time I was about to pick this package for conversion :)

will review this.

Review:

This package follows new fonts packaging guidelines.

Rpmlint
-------
Checking: pt-sans-fonts-20141121-12.fc33.noarch.rpm
          pt-sans-fonts-doc-20141121-12.fc33.noarch.rpm
          pt-sans-fonts-20141121-12.fc33.src.rpm
pt-sans-fonts.noarch: W: spelling-error %description -l en_US libre -> lire, lib re, lib-re
pt-sans-fonts.noarch: W: obsolete-not-provided paratype-pt-sans-caption-fonts
pt-sans-fonts.noarch: W: obsolete-not-provided paratype-pt-sans-fonts
pt-sans-fonts.noarch: W: no-documentation
pt-sans-fonts.src: W: spelling-error %description -l en_US libre -> lire, lib re, lib-re
pt-sans-fonts.src: W: invalid-url Source0: http://www.fontstock.com/public/PTSansOFL.zip HTTP Error 404: Not Found
3 packages and 0 specfiles checked; 0 errors, 6 warnings.

Source checksums
----------------
http://rus.paratype.ru/system/attachments/655/original/ptsans77narrowbold.pdf :
  CHECKSUM(SHA256) this package     : 4d95b075902e6dffe0ff3a314d53a0ad6d8f3f58a65171b2443f4e3d36749ba3
  CHECKSUM(SHA256) upstream package : 4d95b075902e6dffe0ff3a314d53a0ad6d8f3f58a65171b2443f4e3d36749ba3
http://rus.paratype.ru/system/attachments/649/original/ptsans57narrow.pdf :
  CHECKSUM(SHA256) this package     : 1ac8dfe705240f9c58dc8a50ccc215dc44542a65483861e4c123f76f65718ce7
  CHECKSUM(SHA256) upstream package : 1ac8dfe705240f9c58dc8a50ccc215dc44542a65483861e4c123f76f65718ce7
http://rus.paratype.ru/system/attachments/653/original/ptsanscaption57bold.pdf :
  CHECKSUM(SHA256) this package     : d19c2fd4c4d1d868084d4d0338f6d3666586901384928c71a92afe5b50d83eea
  CHECKSUM(SHA256) upstream package : d19c2fd4c4d1d868084d4d0338f6d3666586901384928c71a92afe5b50d83eea
http://rus.paratype.ru/system/attachments/652/original/ptsanscaption55.pdf :
  CHECKSUM(SHA256) this package     : 5a96afc4e93c0c785dd7d33fec376e7d30f8eccc42cd2bf3a44a7c5d3cbface4
  CHECKSUM(SHA256) upstream package : 5a96afc4e93c0c785dd7d33fec376e7d30f8eccc42cd2bf3a44a7c5d3cbface4
http://rus.paratype.ru/system/attachments/651/original/ptsans76bit.pdf :
  CHECKSUM(SHA256) this package     : 854e0b919e865c2136418aa829dece15dd686487c539da60f11e5e96c0c715a3
  CHECKSUM(SHA256) upstream package : 854e0b919e865c2136418aa829dece15dd686487c539da60f11e5e96c0c715a3
http://rus.paratype.ru/system/attachments/648/original/ptsans56it.pdf :
  CHECKSUM(SHA256) this package     : e485dcaf3d4f5be1dab928db0e70abf936e451f5728f4a99c33d43b4b11acec1
  CHECKSUM(SHA256) upstream package : e485dcaf3d4f5be1dab928db0e70abf936e451f5728f4a99c33d43b4b11acec1
http://rus.paratype.ru/system/attachments/650/original/ptsans75bold.pdf :
  CHECKSUM(SHA256) this package     : 95ecfb4325e1864f282ca570a7dc7a4e13acaadb70ddeff6e8ded6c1f1cd6d62
  CHECKSUM(SHA256) upstream package : 95ecfb4325e1864f282ca570a7dc7a4e13acaadb70ddeff6e8ded6c1f1cd6d62
http://rus.paratype.ru/system/attachments/647/original/ptsans55reg.pdf :
  CHECKSUM(SHA256) this package     : c22feb7960e54241f79a1aa5fdf862b7b3aa9b60f39a4396aa948057df053d23
  CHECKSUM(SHA256) upstream package : c22feb7960e54241f79a1aa5fdf862b7b3aa9b60f39a4396aa948057df053d23


Requires
--------
pt-sans-fonts (rpmlib, GLIBC filtered):
    config(pt-sans-fonts)
    fontpackages-filesystem

pt-sans-fonts-doc (rpmlib, GLIBC filtered):


Provides
--------
pt-sans-fonts:
    config(pt-sans-fonts)
    font(ptsans)
    font(ptsanscaption)
    font(ptsansnarrow)
    metainfo()
    metainfo(org.fedoraproject.pt-sans-fonts.metainfo.xml)
    pt-sans-fonts

pt-sans-fonts-doc:
    pt-sans-fonts-doc


Issues:
1) Just want to note here Obsoletes: are not Provided
2) If upstream source has gone then maybe add a note in spec that upstream source no more downloadable.

APPROVED.

> 1) Just want to note here Obsoletes: are not Provided

dnf repoquery does not find anything depending on them today; I’d rather avoid giving people something to hang on before F33 is published (not something I want to push to F32 now it’s frozen, given the font files are still the same as before)

> 2) If upstream source has gone then maybe add a note in spec that upstream source no more downloadable.

There is one:
# This is now dead and ParaType still publishes an older version on its website

And you forgot to set fedora-review :)

Still, thanks for all the reviews you’ve been doing

Thanks for your reply above.

ah sorry I missed the flag. It is set now :)

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/pt-sans-fonts

https://bodhi.fedoraproject.org/updates/FEDORA-2020-96ca935e72

Re: comment #3 and #4 - this was IMO a clear violation of the packaging guidelines. https://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required states "The reviewer of the package MUST...check the package for the proper Obsoletes and Provides (see the naming guidelines for more information.) They MUST document in the review request that they have done so", and the renaming policy - https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages - states:

"If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:

Provides: oldpackagename = $provEVR
Obsoletes: oldpackagename < $obsEVR
"

there is no weasel wording in either of those places that makes the Provides: optional. It is clearly mandatory. Nicolas should not have chosen to leave it out, and Parag should not have approved the package without it.

Just querying package dependencies is not sufficient to decide that nothing depends on it (to say nothing of the possibility that external packages do), because we have other tools and configuration that potentially use package names and provides, as https://github.com/fedora-silverblue/issue-tracker/issues/33 shows.

Please note also going forward that fonts are often listed in https://pagure.io/fedora-comps and https://pagure.io/fedora-kickstarts . If you're going to be systematically renaming a lot of font packages it would be a good idea to write into the process that those two repos plus https://pagure.io/workstation-ostree-config should be checked and PRs submitted if necessary.

PRs for this rename:

https://pagure.io/fedora-comps/pull-request/477
https://pagure.io/fedora-kickstarts/pull-request/620

(for the record, though you should put in the Provides: as the policy says, it's also important to update comps and kickstarts for the new names. This is because some tools/processes that read the comps and kickstarts will only accept them as literal binary package names; if an entry isn't a package name but is provided by some package, they won't pull that package in, they'll either just skip it or fail, depends on the context. *Other* tools/processes that read the files *do* pull packages in by Provides. It's a lot of fun!)

Apologies that this created some work for you, Adam. There was few thoughts going in my mind when I approved this package review without mandating Provides: tag but I clearly missed further steps required for this package. These thoughts were like adapting to new fonts packaging in Fedora, packages getting renamed due to that in Fedora, RHEL N+1 upgrade path, keeping "Obsoletes: and Provides:" tag for many years and then is no way to auto cross-check these old "Obsoletes: and Provides:" tag in existing spec files. I understand its package maintainer responsibility to add and remove "Obsoletes: and Provides:" tag when time comes.

There are few more font packages now in queue that are ready to get renamed in Fedora when they will adapt to new fonts packaging guidelines. While I missed that point about clean upgrade path for this package. I did remember it for my other packages, hence my work on converting existing packages to new guidelines is stalled currently. I have got one rename review (google-carlito-fonts) approved since few days but have not built it in Fedora yet as it also involves changing package name to all those places. But now I am going to build it today.

About querying package dependencies, I am surprised why Fedora users are not affected by this dnf bug https://bugzilla.redhat.com/show_bug.cgi?id=1812596 which should have been fixed on urgent basis. It is present in at least F31 and F32 releases. This is causing me issues to understand package dependency chain. Its good that RHEL-8 is not poisoned by introducing new dnf updates yet. So, I am using it to understand probable dependency chain in Fedora.

It is good that failed-composes repository is helping releng to quickly find such issues but I understand is costs one more complete compose to have reported issues fixed.

I will make sure to check for further steps taken on such rename request packages in my future package review work.

Thank you.

Hadn't noticed that bug, that is annoying. IIRC, though, it always used to work that way, and querying by provides as well as literal name is a fairly recent feature, so I always used to hack up a little bash something like this:

for i in `dnf repoquery --provides foo`; do echo "PROVIDES $i"; dnf repoquery --whatrequires "$i"; done

untested and it probably has a mistake in it somewhere, but you get the idea anyway :)

BTW, there's I think one more reason to have the Provides: to ensure the package actually gets installed on upgrade. I haven't checked to be sure, but IIRC if 'new-foo' only Obsoletes 'old-foo' but doesn't Provides it, when you do an upgrade, it's not actually guaranteed that 'new-foo' will be installed to replace 'old-foo', it'll only happen if 'new-foo' is pulled into the transaction for some other reason.

(In reply to Adam Williamson from comment #10)
> PRs for this rename:
> 
> https://pagure.io/fedora-comps/pull-request/477
> https://pagure.io/fedora-kickstarts/pull-request/620

But, weren't langpacks supposed to deprecate and replace all those groups?

Is i18n maintaining two set of font lists now?

Good question, I'm not sure about that. I only grepped the files that exist, and found those entries. If they shouldn't be there, I suppose someone needs to remove them :)

Let me explain langpacks history.

Previously when Workstation was producing DVD iso, anaconda team helped to hook the code to also install required langpacks based on selected language supports. E.g. if you install Fedora in Japanese language and also enabled French then you was getting both language support installed on your system. Also, DVD iso contained all required packages already. 

Then the decision comes to drop DVD iso for Workstation and only Live iso, this created challenge to have langpacks installed automatically when you installed Live iso on your harddisk. We then dropped dnf-langpacks package and moved to langpacks metapackage concept in Fedora 24. Then I tried to keep maintaining system-config-language tool that some users demanded to install langpacks. Then we again went into discussion to find some solution to have langpacks auto-installed. I developed some tool "langpacks-install" but again it was not complete solution.

We also keep working on enhancing langpacks usage by end users and also in containers.
In Fedora 30, we implemented https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks , so comps language support groups (e.g. japanese-support or hindi-support) was gone.
In Fedora 31, we implemented https://fedoraproject.org/wiki/Changes/Langpacks-core , packages like langpacks-ja need to be split to langpacks-core-ja to provide minimal i18n support (i.e. locale, default font and any input method).

With this we kept exploring options to have langpacks-<LANGCODE> package auto-installed on the Fedora system. We tried gnome-initial-setup but again it was not good solution. Now, work has been done by Sundeep in gnome-software to detect the current language of your system in Gnome and if its corresponding langpacks metapackage is not installed then gnome-software plugin will install it. Now, he is working on same to be working in Fedora Silverblue system.

Once we will see this auto-installation of langpacks working fine, we can think about "fonts" comps group existence.

If it was easy way to install langpacks on Fedora system during first set of packages installation only then we could have able to remove "fonts" comps group.

But is listing font packages in Comps file is only related to langpacks/language support? No, just grep "fonts" in comps-f33.xml.in file and you will find 752 occurrence of "fonts" string in that file.

1) "authoring-and-publishing" group pulls "tex-fonts-hebrew" which installs almost all culmus*fonts packages.
2) "design-suite" group needs many fonts packages default installed on the system.
3) "electronic-lab" group installs "xorg-x11-fonts-*" packages default installed on the system.
4) "engineering-and-scientific" group installs "stix-math-fonts"
5) "fonts" group itself installs 32 default fonts packages and have 595 fonts packages marked as optional.
6) "gnome-desktop" comps group installs "adobe-source-code-pro-fonts" package by default.
7)  Then we still have "legacy-fonts" packages group which install 4 default fonts and have 77 optional fonts packages. These are the fonts which should get removed or converted to ttf/otf in Fedora.


Now, if we want to remove "fonts" comps group then I am not sure how these different Desktop environments will work. E.g. kde-desktop-environment, xfce-desktop-environment, workstation-product-environment, lxde-desktop-environment, lxqt-desktop-environment, cinnamon-desktop-environment, mate-desktop-environment, sugar-desktop-environment, deepin-desktop-environment and then these other groups developer-workstation-environment, basic-desktop-environment, base-system will work.

I still don't see its an easy way to remove fonts group from comps file. So, any changes to fonts name should be changed in comps file as well.

That’s i18n land, so not my stuff to complain about, but most of the comps fonts stuff is obsolete unmaintained junk.

1) "authoring-and-publishing" group pulls "tex-fonts-hebrew" → completely useless, we’ve have had Hebrew support in the default system font for 13 years now

2) "design-suite" group needs many fonts packages → is anyone maintaining those? I haven’t seen anyone design-side bothering about fonts for 5/7 years at least

3) "electronic-lab" group installs "xorg-x11-fonts-*" → that is obsolete now that wayland is here and legacy font format support is gone from harfbuzz-ng

4) "engineering-and-scientific" group installs "stix-math-fonts" → this has been gone upstream for years and it is gone in F33 too now

5) "fonts" group itself → replace it will langpacks

6) "gnome-desktop" comps group installs → don’t get me started on how GNOME is unable to work with the rest of the distribution

7)  Then we still have "legacy-fonts" → death row corner from ~13 years ago. Just let them go

So, not impressed at all with this list. Just remove the damn groups (or fill them with langpacks). Two competing systems won’t make one working system. Two competing systems mean two broken systems. No one will maintain two lists of fonts (tedious and pretty useless work). Please don’t stop in the middle of the river, finish the transition.