Upstream update available: harfbuzz 11.4.1 → 14.2.0 #2

Open
opened 2026-04-28 01:14:43 +03:00 by sbelikov · 0 comments
Owner

Upstream update available: harfbuzz 11.4.114.2.0

Package

  • Package: harfbuzz
  • RPM name: harfbuzz
  • Branch: niceos-5.2
  • Current EVR: 11.4.1-1
  • Update class: major
  • Compare method: python_rpm
  • Update policy: leaf
  • Risk tags: github-upstream

Upstream

Signals

  • Security-relevant keywords detected: False
  • Policy blocked: False
  • Policy reason: -
  • Labels: ai-summary, bot, needs-build, needs-triage, priority/high, update/major, upstream-update, upstream/github

NiceSOFT AI preliminary stability analysis

Risk Assessment for harfbuzz Upstream Update (14.2.0)

Package Status: Major Update
Risk Tags: github-upstream
Policy: Not Blocked


1. Risk Evaluation

  • Risk Level: Medium
  • Reason:
    • The update is marked as major, implying potential ABI/API changes that could affect downstream packages (e.g., NAIOS).
    • While the API is described as "ready for stabilization", the encode entry point change (e.g., new function signatures) could introduce compatibility issues in the RPM spec file.
    • No CVEs detected (security keywords false), but major updates inherently carry risk of breaking compatibility.

2. ABI/API Risk

  • Risk Level: Low
  • Reason:
    • The release notes state: "Once stable, API/ABI won't be changed in incompatible ways."
    • The encode entry point change is not marked as incompatible, and the API is considered stable.
    • RPM spec file may need updates to reflect the new function signatures, but no explicit ABI breaks are reported.

3. RPM Packaging Considerations

  • Risk Level: Medium
  • Reason:
    • Major update may require spec file revisions to ensure compatibility with existing packages.
    • %check section may need to verify new features (e.g., encode entry point).
    • %prep or %build steps may need adjustments if the API changes.

4. Recommendation

  • Recommendation: Issue-Only
  • Reason:
    • The major update is not recommended for automatic deployment due to potential ABI/API changes.
    • Manual review is required to ensure compatibility with existing packages (e.g., NAIOS).
    • RPM spec file must be updated to reflect the new API, even if no explicit breaks are reported.

5. Key Actions

  1. Review RPM spec file for API changes (e.g., encode entry point).
  2. Update dependencies to ensure compatibility with harfbuzz 14.2.0.
  3. Test build and install to verify no ABI breaks.
  4. Document changes in the NAIOS package changelog.

Conclusion

The harfbuzz update (14.2.0) is major, but the API is stable and no CVEs detected. The ABI risk is low, but major updates require careful handling. The recommendation is to issue-only the update, with manual review and spec file updates to mitigate risks.

  1. GitHub release API: harfbuzz/harfbuzz 14.2.0
  2. GitHub tag page: harfbuzz/harfbuzz 14.2.0
  3. GitHub releases page: harfbuzz/harfbuzz
  4. GitHub compare page: harfbuzz/harfbuzz 11.4.1...14.2.0
  5. Apply to pay voluntary National Insurance contributions for periods ...
  6. Eat Your Nutrition Blog - Holistic Blogs for Gut Health
  7. HarfBuzz-NG, version 14.2.0 | Qt GUI | Qt 6.11.1
  8. HarfBuzz text shaping engine - GitHub
  9. Install & manage web apps - Chrome Web Store Help - Google Help

Upstream release notes / description

In this release, the experimental raster, vector, and GPU libraries went through several rounds of code review and cleanup to make sure they follow the high standards expected of HarfBuzz code. The API has also been extensively reviewed based on experience gained from using these libraries. We consider the code and API to be ready for stabilization, and we expect to graduate them from experimental in the near future. If you are using or planning to use these libraries and have any concerns about the API, it is time to raise them. Once a library is deemed stable, we will never change the API or ABI in an incompatible way.

  • GPU library:

    • New color-glyph paint renderer, based on design by Lê Duy Quang.
      hb_gpu_paint_t walks a font's paint tree (COLRv0 or COLRv1) and encodes its layers (solid fills, linear / radial / sweep gradients, transforms, composite groups) into a compact blob.
      A new fragment-shader function hb_gpu_paint() renders the blob in premultiplied RGBA; monochrome glyphs are handled transparently via a synthesized foreground-colored layer.
      Shader sources provided in GLSL, WGSL, MSL, and HLSL.
    • Paint encoder limitations: the encoder sets unsupported and returns NULL when num_ops would exceed 32767, push_group nests deeper than 4, or the paint tree calls back through the image callback (PaintImage).
      Nested glyph clips are intersected up to 3 levels; a few composite modes use approximate fallbacks; push_clip_rectangle is silently ignored.
    • Encode entry point now returns extents and auto-clears the encoder; the standalone get_extents() is gone.
    • Gradient color stop interpolation now happens in premultiplied space per the OpenType COLR specification.
    • The foreground color sentinel (is_foreground) now correctly preserves the paint-tree alpha from the encoded color data instead of discarding it.
    • The hb-gpu utility gains --draw / --paint flags with per-font auto-detect, and --output-file / -o for headless single-frame rendering to a PPM image.
  • Vector library:

    • New PDF output backend. Vector paint glyphs now render to PDF page content, producing scalable COLRv0 / COLRv1 color-glyph artwork (solid fills, linear / radial / sweep gradients, blend modes, PNG images with transparency) that can be embedded directly in PDF documents. Useful for PDF producers such as LibreOffice that want crisp, resolution-independent color emoji.
    • New SVG id prefix API on paint allows prefixing document references, which allows for embedding multiple SVGs in the same page without name clashes (hb_vector_paint_set_svg_prefix).
    • Removed glyph path dedup from vector draw and paint. Each glyph is emitted inline; no <defs> / <use> caching.
    • _glyph() functions are now thin convenience wrappers documented as equivalent expansions of the underlying font draw/paint API.
    • Drop glyph-source rendering of SVG-in-OT fonts.
  • Raster library:

    • Drop glyph-source rendering of SVG-in-OT fonts.
  • Across Draw / Paint subsystems:

    • _reset() methods gain matching_clear() companions that drop accumulated data while preserving user configuration. Getter companions added for setters across raster, vector, and gpu types.
  • Various fuzzer fixes for raster, vector, and GPU libraries.

  • Paint API:

    • New arbitrary-path clip: hb_paint_push_clip_path_start / _end let callers clip to a caller-supplied outline, not just a font glyph. push_clip_path_start() returns the draw-funcs (and matching draw data) for the backend’s path accumulator; the caller drives hb_draw_*() into it, then calls push_clip_path_end(), followed by painted ops, then hb_paint_pop_clip() to release the clip. Implemented for all paint backends: vector (SVG defs + clipPath + url ref), vector PDF (q / path / W n), raster (path rendered to an alpha mask, intersected with the current clip), and GPU (the path is encoded into a Slug sub-blob so the fragment shader clips against it the same way it clips against glyph outlines).
  • Shaping:

    • Indic: categorize U+1CF5 and U+1CF6 as CS.
  • Changed API

    • GPU library:

      • hb_gpu_draw_glyph() now returns void (was hb_bool_t). Use hb_gpu_draw_glyph_or_fail() if you need the success status.
      • hb_gpu_paint_glyph() now returns void (was hb_bool_t) and internally synthesizes a foreground-colored layer for non-color glyphs via hb_font_paint_glyph(), so every glyph with an outline produces output. Use hb_gpu_paint_glyph_or_fail() (which delegates to hb_font_paint_glyph_or_fail()) if you need to distinguish color vs synthesized paint. Encoder-level limits (unsupported ops, group-stack overflow) no longer fail paint_glyph; they surface from hb_gpu_paint_encode() returning NULL.
      • hb_gpu_draw_encode() now takes an extents out-parameter and auto-clears the encoder on return.
      • hb_gpu_draw_darken() renamed to hb_gpu_stem_darken().
    • Vector library:

      • hb_vector_svg_set_precision() and its paint counterpart renamed to hb_vector_draw_set_precision() / hb_vector_paint_set_precision() (SVG-specific naming is inaccurate with the PDF backend added).
      • hb_vector_draw_glyph() / hb_vector_paint_glyph() now return void (were hb_bool_t). Paint additionally gains a draw fallback for non-color glyphs. Use the matching _or_fail() variants for the hb_bool_t return.
    • Raster library:

      • hb_raster_draw_glyph() / hb_raster_paint_glyph() now return void (were hb_bool_t). Paint additionally gains a draw fallback for non-color glyphs. Use the matching _or_fail() variants for the hb_bool_t return.
    • General:

      • Many read-only getters gained const on their object argument.
      • Six public draw / paint funcs getters across raster, vector, and gpu now take a const-pointer to the relevant context instance instead of being singletons:
        hb_raster_draw_get_funcs (const hb_raster_draw_t *)`
        hb_ras

...[truncated 3718 chars]

NiceOS maintainer checklist

  • Confirm that the detected version is a stable upstream release.
  • Check upstream changelog for security fixes, ABI/API changes and build-system changes.
  • Check ABI/API compatibility and reverse dependencies.
  • Download source into NiceOS lookaside storage.
  • Update Version and related fields in SPECS/*.spec only if policy allows it.
  • Regenerate SOURCES/sources.lock.json, manifests, metadata and SBOM.
  • Build SRPM/RPM in a clean NiceOS buildroot.
  • Run package smoke tests.
  • Link PR/build logs and close this issue after update or triage.

Bot metadata

  • Tool: niceos_upstream_monitor.py 2.1.3-local-websearch-github-release-pages
  • Generated at: 2026-06-01T23:39:02Z
<!-- niceos-upstream-monitor:fingerprint=upstream-update:harfbuzz:14.2.0 --> <!-- niceos-upstream-monitor:package=harfbuzz --> <!-- niceos-upstream-monitor:current=11.4.1 --> <!-- niceos-upstream-monitor:latest=14.2.0 --> # Upstream update available: `harfbuzz` `11.4.1` → `14.2.0` ## Package - Package: `harfbuzz` - RPM name: `harfbuzz` - Branch: `niceos-5.2` - Current EVR: `11.4.1-1` - Update class: `major` - Compare method: `python_rpm` - Update policy: `leaf` - Risk tags: `github-upstream` ## Upstream - Upstream type: `github` - Upstream project: `harfbuzz/harfbuzz` - Upstream URL: <a href="https://github.com/harfbuzz/harfbuzz" target="_blank" rel="noopener noreferrer">github.com — harfbuzz</a> - Detected version: `14.2.0` - Tag/release: `14.2.0` - Source: `github_release_latest` - Published: `2026-04-20T03:15:55Z` - Release URL: <a href="https://github.com/harfbuzz/harfbuzz/releases/tag/14.2.0" target="_blank" rel="noopener noreferrer">github.com — 14.2.0</a> - Source URL: <a href="https://api.github.com/repos/harfbuzz/harfbuzz/tarball/14.2.0" target="_blank" rel="noopener noreferrer">api.github.com — 14.2.0</a> - Pre-release: `False` ## Signals - Security-relevant keywords detected: `False` - Policy blocked: `False` - Policy reason: `-` - Labels: `ai-summary, bot, needs-build, needs-triage, priority/high, update/major, upstream-update, upstream/github` ## NiceSOFT AI preliminary stability analysis ### **Risk Assessment for `harfbuzz` Upstream Update (14.2.0)** **Package Status:** Major Update **Risk Tags:** `github-upstream` **Policy:** Not Blocked --- ### **1. Risk Evaluation** - **Risk Level:** **Medium** - **Reason:** - The update is marked as **major**, implying potential **ABI/API changes** that could affect downstream packages (e.g., NAIOS). - While the **API is described as "ready for stabilization"**, the **encode entry point** change (e.g., new function signatures) could introduce **compatibility issues** in the RPM spec file. - **No CVEs detected** (security keywords false), but **major updates** inherently carry **risk of breaking compatibility**. --- ### **2. ABI/API Risk** - **Risk Level:** **Low** - **Reason:** - The release notes state: *"Once stable, API/ABI won't be changed in incompatible ways."* - The **encode entry point** change is **not marked as incompatible**, and the **API is considered stable**. - **RPM spec file** may need updates to reflect the new function signatures, but no explicit ABI breaks are reported. --- ### **3. RPM Packaging Considerations** - **Risk Level:** **Medium** - **Reason:** - **Major update** may require **spec file revisions** to ensure compatibility with existing packages. - **%check** section may need to verify new features (e.g., encode entry point). - **%prep** or **%build** steps may need adjustments if the API changes. --- ### **4. Recommendation** - **Recommendation:** **Issue-Only** - **Reason:** - The **major update** is not recommended for **automatic deployment** due to potential **ABI/API changes**. - **Manual review** is required to ensure compatibility with existing packages (e.g., NAIOS). - **RPM spec file** must be updated to reflect the new API, even if no explicit breaks are reported. --- ### **5. Key Actions** 1. **Review RPM spec file** for API changes (e.g., encode entry point). 2. **Update dependencies** to ensure compatibility with `harfbuzz` 14.2.0. 3. **Test build and install** to verify no ABI breaks. 4. **Document changes** in the NAIOS package changelog. --- ### **Conclusion** The `harfbuzz` update (14.2.0) is **major**, but the **API is stable** and **no CVEs detected**. The **ABI risk is low**, but **major updates require careful handling**. The recommendation is to **issue-only** the update, with **manual review** and **spec file updates** to mitigate risks. ### Источники, найденные web_search 1. <a href="https://github.com/harfbuzz/harfbuzz/releases/tag/14.2.0" target="_blank" rel="noopener noreferrer">GitHub release API: harfbuzz/harfbuzz 14.2.0</a> 2. <a href="https://github.com/harfbuzz/harfbuzz/tree/14.2.0" target="_blank" rel="noopener noreferrer">GitHub tag page: harfbuzz/harfbuzz 14.2.0</a> 3. <a href="https://github.com/harfbuzz/harfbuzz/releases" target="_blank" rel="noopener noreferrer">GitHub releases page: harfbuzz/harfbuzz</a> 4. <a href="https://github.com/harfbuzz/harfbuzz/compare/11.4.1...14.2.0" target="_blank" rel="noopener noreferrer">GitHub compare page: harfbuzz/harfbuzz 11.4.1...14.2.0</a> 5. <a href="https://www.gov.uk/guidance/apply-to-pay-voluntary-national-insurance-contributions-when-abroad-cf83" target="_blank" rel="noopener noreferrer">Apply to pay voluntary National Insurance contributions for periods ...</a> 6. <a href="https://quiz.tryinteract.com/" target="_blank" rel="noopener noreferrer">Eat Your Nutrition Blog - Holistic Blogs for Gut Health</a> 7. <a href="https://doc.qt.io/qt-6/qtgui-attribution-harfbuzz-ng.html" target="_blank" rel="noopener noreferrer">HarfBuzz-NG, version 14.2.0 | Qt GUI | Qt 6.11.1</a> 8. <a href="https://github.com/harfbuzz/harfbuzz" target="_blank" rel="noopener noreferrer">HarfBuzz text shaping engine - GitHub</a> 9. <a href="https://support.google.com/chrome_webstore/answer/1053346?hl=en" target="_blank" rel="noopener noreferrer">Install &amp; manage web apps - Chrome Web Store Help - Google Help</a> ## Upstream release notes / description In this release, the experimental raster, vector, and GPU libraries went through several rounds of code review and cleanup to make sure they follow the high standards expected of HarfBuzz code. The API has also been extensively reviewed based on experience gained from using these libraries. We consider the code and API to be ready for stabilization, and we expect to graduate them from experimental in the near future. If you are using or planning to use these libraries and have any concerns about the API, it is time to raise them. Once a library is deemed stable, we will never change the API or ABI in an incompatible way. - GPU library: * New color-glyph paint renderer, based on design by Lê Duy Quang. `hb_gpu_paint_t` walks a font's paint tree (COLRv0 or COLRv1) and encodes its layers (solid fills, linear / radial / sweep gradients, transforms, composite groups) into a compact blob. A new fragment-shader function `hb_gpu_paint()` renders the blob in premultiplied RGBA; monochrome glyphs are handled transparently via a synthesized foreground-colored layer. Shader sources provided in GLSL, WGSL, MSL, and HLSL. * Paint encoder limitations: the encoder sets `unsupported` and returns `NULL` when `num_ops` would exceed 32767, `push_group` nests deeper than 4, or the paint tree calls back through the image callback (PaintImage). Nested glyph clips are intersected up to 3 levels; a few composite modes use approximate fallbacks; `push_clip_rectangle` is silently ignored. * Encode entry point now returns extents and auto-clears the encoder; the standalone `get_extents()` is gone. * Gradient color stop interpolation now happens in premultiplied space per the OpenType COLR specification. * The foreground color sentinel (`is_foreground`) now correctly preserves the paint-tree alpha from the encoded color data instead of discarding it. * The hb-gpu utility gains `--draw` / `--paint` flags with per-font auto-detect, and `--output-file` / `-o` for headless single-frame rendering to a PPM image. - Vector library: * New PDF output backend. Vector paint glyphs now render to PDF page content, producing scalable COLRv0 / COLRv1 color-glyph artwork (solid fills, linear / radial / sweep gradients, blend modes, PNG images with transparency) that can be embedded directly in PDF documents. Useful for PDF producers such as LibreOffice that want crisp, resolution-independent color emoji. * New SVG id prefix API on paint allows prefixing document references, which allows for embedding multiple SVGs in the same page without name clashes (`hb_vector_paint_set_svg_prefix`). * Removed glyph path dedup from vector draw and paint. Each glyph is emitted inline; no `<defs>` / `<use>` caching. * `_glyph()` functions are now thin convenience wrappers documented as equivalent expansions of the underlying font draw/paint API. * Drop glyph-source rendering of SVG-in-OT fonts. - Raster library: * Drop glyph-source rendering of SVG-in-OT fonts. - Across Draw / Paint subsystems: * `_reset()` methods gain matching`_clear()` companions that drop accumulated data while preserving user configuration. Getter companions added for setters across raster, vector, and gpu types. - Various fuzzer fixes for raster, vector, and GPU libraries. - Paint API: * New arbitrary-path clip: `hb_paint_push_clip_path_start` / `_end` let callers clip to a caller-supplied outline, not just a font glyph. `push_clip_path_start()` returns the draw-funcs (and matching draw data) for the backend’s path accumulator; the caller drives `hb_draw_*()` into it, then calls `push_clip_path_end()`, followed by painted ops, then `hb_paint_pop_clip()` to release the clip. Implemented for all paint backends: vector (SVG defs + clipPath + url ref), vector PDF (q / path / W n), raster (path rendered to an alpha mask, intersected with the current clip), and GPU (the path is encoded into a Slug sub-blob so the fragment shader clips against it the same way it clips against glyph outlines). - Shaping: * Indic: categorize U+1CF5 and U+1CF6 as CS. - Changed API * GPU library: - `hb_gpu_draw_glyph()` now returns `void` (was `hb_bool_t`). Use `hb_gpu_draw_glyph_or_fail()` if you need the success status. - `hb_gpu_paint_glyph()` now returns `void` (was `hb_bool_t`) and internally synthesizes a foreground-colored layer for non-color glyphs via `hb_font_paint_glyph()`, so every glyph with an outline produces output. Use `hb_gpu_paint_glyph_or_fail()` (which delegates to `hb_font_paint_glyph_or_fail()`) if you need to distinguish color vs synthesized paint. Encoder-level limits (unsupported ops, group-stack overflow) no longer fail paint_glyph; they surface from `hb_gpu_paint_encode()` returning `NULL`. - `hb_gpu_draw_encode()` now takes an `extents` out-parameter and auto-clears the encoder on return. - `hb_gpu_draw_darken()` renamed to `hb_gpu_stem_darken()`. * Vector library: - `hb_vector_svg_set_precision()` and its paint counterpart renamed to `hb_vector_draw_set_precision()` / `hb_vector_paint_set_precision()` (SVG-specific naming is inaccurate with the PDF backend added). - `hb_vector_draw_glyph()` / `hb_vector_paint_glyph()` now return `void` (were `hb_bool_t`). Paint additionally gains a draw fallback for non-color glyphs. Use the matching `_or_fail()` variants for the `hb_bool_t` return. * Raster library: - `hb_raster_draw_glyph()` / `hb_raster_paint_glyph()` now return `void` (were `hb_bool_t`). Paint additionally gains a draw fallback for non-color glyphs. Use the matching `_or_fail()` variants for the `hb_bool_t` return. * General: - Many read-only getters gained const on their object argument. - Six public draw / paint funcs getters across raster, vector, and gpu now take a const-pointer to the relevant context instance instead of being singletons: hb_raster_draw_get_funcs (const hb_raster_draw_t *)` hb_ras ...[truncated 3718 chars] ## NiceOS maintainer checklist - [ ] Confirm that the detected version is a stable upstream release. - [ ] Check upstream changelog for security fixes, ABI/API changes and build-system changes. - [ ] Check ABI/API compatibility and reverse dependencies. - [ ] Download source into NiceOS lookaside storage. - [ ] Update `Version` and related fields in `SPECS/*.spec` only if policy allows it. - [ ] Regenerate `SOURCES/sources.lock.json`, manifests, metadata and SBOM. - [ ] Build SRPM/RPM in a clean NiceOS buildroot. - [ ] Run package smoke tests. - [ ] Link PR/build logs and close this issue after update or triage. ## Bot metadata - Tool: `niceos_upstream_monitor.py 2.1.3-local-websearch-github-release-pages` - Generated at: `2026-06-01T23:39:02Z`
Sign in to join this conversation.
No description provided.