https://bugzilla.redhat.com/show_bug.cgi?id=2183905
Bug ID: 2183905
Summary: replace gettext hostname helper with /usr/bin/hostname
Product: Fedora
Version: rawhide
Status: NEW
Component: gettext
Assignee: suanand(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
nphilipp(a)redhat.com, petersen(a)redhat.com,
praiskup(a)redhat.com, suanand(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
gettext includes its own hostname helper program
(presumably for systems that do not provide the hostname tool)
which uses deprecated gethostbyname() function...
If /usr/bin/hostname is a drop in replacement then it seems
better just to use that in place of it - this would avoid
the rpminspect warnings/errors about gethostbyname() usage.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2183905
https://bugzilla.redhat.com/show_bug.cgi?id=1974983
Bug ID: 1974983
Summary: After upgrade xkeyboard-config to version 2.33-1.fc35
layout indicator stop react to layout switch by
Ctrl-Shift key combination.
Product: Fedora
Version: rawhide
Status: NEW
Component: xkeyboard-config
Assignee: peter.hutterer(a)redhat.com
Reporter: mikhail.v.gavrilov(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
i18n-bugs(a)lists.fedoraproject.org,
negativo17(a)gmail.com, peter.hutterer(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
After upgrade xkeyboard-config to version 2.33-1.fc35 layout indicator stop
react to layout switch by Ctrl-Shift key combination.
The bug is affected only Wayland session and only non standard layout switch
key combination.
Last good version is 2.32-3.fc35
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2088665
Bug ID: 2088665
Summary: Noto Sans is chosen to display symbol characters it
doesn't contain
Product: Fedora
Version: 36
Status: NEW
Component: google-noto-fonts
Assignee: tagoh(a)redhat.com
Reporter: talk(a)danielflaum.net
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com,
pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1881507
--> https://bugzilla.redhat.com/attachment.cgi?id=1881507&action=edit
A zipped sample PDF and image of relevant portion of PDF when affected by the
issue
Description of problem:
Given a PDF lacking embedded fonts which use certain characters (including →
and ≥), GNOME's Evince on Fedora 36 chooses to substitute the Noto Sans font,
which does not include these characters.
Version-Release number of selected component (if applicable):
How reproducible:
Successfully reproduced by two people independently.
Steps to Reproduce:
1. Boot a fresh copy of Fedora 36 (the Live version in a VM will do).
2. Open the attached sample PDF in GNOME Evince (aka Document Viewer).
3. Observe the missing characters in the second paragraph from the top of the
page.
Actual results:
See attached image.
Expected results:
The missing characters should be displayed properly as → (that is,
https://unicode-table.com/en/2192/).
Additional info:
The filer initially sought help at
https://ask.fedoraproject.org/t/missing-characters-in-pdfs-since-upgrade-fr…,
which may be informative in reproducing the issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2088665
https://bugzilla.redhat.com/show_bug.cgi?id=2178746
Bug ID: 2178746
Summary: Please branch and build aspell-bn in epel9
Product: Fedora
Version: rawhide
Status: NEW
Component: aspell-bn
Assignee: aalam(a)fedoraproject.org
Reporter: davide(a)cavalca.name
QA Contact: extras-qa(a)fedoraproject.org
CC: aalam(a)fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org
Blocks: 1914423 (EPELPackagersSIG)
Target Milestone: ---
Classification: Fedora
Please branch and build aspell-bn in epel9.
If you do not wish to maintain aspell-bn in epel9,
or do not think you will be able to do this in a timely manner,
the EPEL Packagers SIG would be happy to be a co-maintainer of the package;
please add the epel-packagers-sig group through
https://src.fedoraproject.org/rpms/aspell-bn/addgroup
and grant it commit access, or collaborator access on epel* branches.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1914423
[Bug 1914423] Tracker for epel-packagers-sig
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2178746
https://bugzilla.redhat.com/show_bug.cgi?id=2093080
Bug ID: 2093080
Summary: Default fonts for Arabic do not match the font
packages list
Product: Fedora
Version: 36
Hardware: All
OS: Linux
Status: NEW
Component: fontconfig
Severity: medium
Assignee: tagoh(a)redhat.com
Reporter: awilliam(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
pnemade(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
There's a test case:
https://fedoraproject.org/wiki/QA:Testcase_i18n_default_fonts
which requires checking the default fonts for various languages against a list,
http://tagoh.fedorapeople.org/fonts/fc-test.sh .
The current default fonts for Arabic installs do not match the list. The list
states sans should be DejaVu Sans, serif should be FreeSerif or MPH 2B Damase,
and mono should be DejaVu Sans Mono. These may have been changed recently, as
our openQA reference text file expects them to be Noto Naskh Arabic (for both
sans and serif?) and PakType Naskh Basic for mono.
In any case, what we actually see doesn't match either the list or the openQA
reference file. We see "Noto Sans Arabic" and "PakType Naqsh" in the output
from the test, I think for serif (yes really) and monospace respectively.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2093080
https://bugzilla.redhat.com/show_bug.cgi?id=2217542
Bug ID: 2217542
Summary: cppcheck-2.11-1.fc39 fails on gettext.h with
returnDanglingLifetime
Product: Fedora
Version: rawhide
Hardware: x86_64
URL: https://github.com/rhinstaller/anaconda/actions/runs/5
378586167/jobs/9758588667#step:4:2099
OS: Linux
Status: NEW
Component: gettext
Severity: medium
Assignee: petersen(a)redhat.com
Reporter: jkonecny(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
nphilipp(a)redhat.com, petersen(a)redhat.com,
suanand(a)redhat.com
Target Milestone: ---
Classification: Fedora
On Rawhide cppcheck was recently updated and now we are getting
returnDanglingLifetime error from it on copied gettext.h file from
/usr/share/gettext/gettext.h path.
Version of cppcheck which shows this issue: 2.11-1.fc39
Last version of cppcheck which worked well: 2.9-4.fc38
I don't know if the error is valid or not...
Reproducible: Always
Steps to Reproduce:
1. podman run --rm -it fedora:rawhide
2. dnf install -y cppcheck gettext-devel
3. cppcheck -q -v /usr/share/gettext/gettext.h
Actual Results:
/usr/share/gettext/gettext.h:248:16: error: Returning pointer to local variable
'msg_ctxt_id' that will be invalid when returning. [returnDanglingLifetime]
return translation;
Expected Results:
No error
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2217542
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2135166
Bug ID: 2135166
Summary: libunistring-1.1 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: libunistring
Keywords: FutureFeature, Triaged
Assignee: p(a)draigbrady.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
jim(a)meyering.net, p(a)draigbrady.com,
redhat-bugzilla(a)linuxnetz.de
Target Milestone: ---
Classification: Fedora
Releases retrieved: 1.1
Upstream release that is considered latest: 1.1
Current version/release in rawhide: 1.0-2.fc37
URL: http://www.gnu.org/software/libunistring/
Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_M…
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from Anitya:
https://release-monitoring.org/project/1747/
To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/libunistring
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2135166
https://bugzilla.redhat.com/show_bug.cgi?id=2060102
Bug ID: 2060102
Summary: Remove libdb dependency
Product: Fedora
Version: rawhide
Status: NEW
Component: libpinyin
Severity: high
Assignee: pwu(a)redhat.com
Reporter: fjanus(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com,
robinlee.sysu(a)gmail.com
Target Milestone: ---
Classification: Fedora
Since there is a long-term effort to remove all libdb dependencies I would like
to find out solution also for libpinyin.
Libdb was marked as deprecated in Fedora by change[2] and it was also
deprecated in RHEL9[1]. Libdb is currently many many years without any update.
So it`s quite old code without upstream support.
[1] https://access.redhat.com/articles/6464541
[2] https://fedoraproject.org/wiki/Changes/Libdb_deprecated
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2060102