Bug 2437509

Summary:	Unusual locale length error is incorrectly raised
Product:	[Fedora] Fedora	Reporter:	Andrea Musuruane <musuruan>
Component:	rpm	Assignee:	Panu Matilainen <pmatilai>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	igor.raits, mdomonko, packaging-team-maint, pmatilai
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2026-02-10 13:56:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2435922

Description Andrea Musuruane 2026-02-07 13:50:30 UTC

Description of problem:
I was updating gcompris-qt to the latest release but fedpkg mockbuild returns the following blocking error:

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.hepOSX
[...]
+ /usr/bin/cmake --install redhat-linux-build
-- Install configuration: "release"
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/icons/hicolor/256x256/apps/gcompris-qt.png
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/icons/hicolor/scalable/apps/gcompris-qt.svg
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/metainfo/org.kde.gcompris.appdata.xml
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/applications/org.kde.gcompris.desktop
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/gcompris-qt/translations
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/gcompris-qt/translations/gcompris_teachers_qt_br.qm
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/gcompris-qt/translations/gcompris_teachers_qt_ca.qm
-- Installing: /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr/share/gcompris-qt/translations/gcompris_teachers_qt_ca
[...]

+ /usr/bin/add-det --brp -j16 /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT
Scanned 32 directories and 334 files,
   processed 0 inodes,
   0 modified (0 replaced + 0 rewritten),
   0 unsupported format, 0 errors
+ /usr/bin/linkdupes --brp /builddir/build/BUILD/gcompris-qt-26.0-build/BUILDROOT/usr
Scanned 31 directories and 334 files,
   considered 334 files, read 6 files, linked 0 files, 0 errors
   sum of sizes of linked files: 0 bytes
Reading /builddir/build/BUILD/gcompris-qt-26.0-build/SPECPARTS/rpm-debuginfo.specpart
Processing files: gcompris-qt-26.0-1.fc44.x86_64
error: Unusual locale length: "gcompris_teachers_qt_ca@valencia" in %lang(gcompris_teachers_qt_ca@valencia)
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.MLfqee

The problem seems to be that rpm has selected some value as the maximum length one of these filenames can have, and the gcompris-qt file exceeds this length.

WIP spec file is available here:
https://musuruan.fedorapeople.org/gcompris-qt.spec

Version-Release number of selected component (if applicable):
6.0.1-2

How reproducible:
Always

Steps to Reproduce:
1. fedpkg mockbuild the aforementioned spec file

Actual results:
The following error is raised:
error: Unusual locale length: "gcompris_teachers_qt_ca@valencia" in %lang(gcompris_teachers_qt_ca@valencia)

Expected results:
rpm should not raise this error

Comment 1 Michal Domonkos 2026-02-10 13:56:41 UTC

Thanks for the report, I've filed it upstream: https://github.com/rpm-software-management/rpm/issues/4114. Once fixed there, this will make its way into the Fedora package in the next rebase, most likely for the next RPM 6.0.x release.

Comment 2 Michal Domonkos 2026-02-10 13:58:25 UTC

That said, I can see this is blocking the update of your package. Is there a way to work around this in your spec?

Comment 3 Andrea Musuruane 2026-02-10 14:01:50 UTC

(In reply to Michal Domonkos from comment #2)
> That said, I can see this is blocking the update of your package. Is there a
> way to work around this in your spec?

AKAIK no.