https://bugzilla.redhat.com/show_bug.cgi?id=2267629
Bug ID: 2267629
Summary: liberation-mono-fonts breaks default font for Hebrew
Product: Fedora
Version: 40
OS: Linux
Status: NEW
Component: google-noto-fonts
Keywords: i18n
Severity: medium
Assignee: tagoh(a)redhat.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
google-noto-sans-hebrew-vf-fonts is supposed to be a default monospace font for
Hebrew though, liberation-mono-fonts is picked up as the default monospace font
when it is installed.
This happens because liberation use 59 as the priority number although
google-noto-sans-hebrew-vf-fonts use 66.
The priority number needs to be updated.
Reproducible: Always
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2267629
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=2277345
Bug ID: 2277345
Summary: NotoSansMono[wght].ttf file name causes scripts with
failglob enabled to fail
Product: Fedora
Version: 40
Hardware: All
OS: Linux
Status: NEW
Component: google-noto-fonts
Severity: medium
Assignee: tagoh(a)redhat.com
Reporter: hartsjc(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
shopt failglob
If set, patterns which fail to match filenames during pathname expansion result
in an expansion error.
Using this feature is good practice in scripts as helps prevent scripting
mistakes; however, having file name with square brackets causes failures. And
with Fedora 40 upgrade seems
google-noto-sans-mono-vf-fonts-20240301-2.fc40.noarch has added one with:
/usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf
Reproducible: Always
Steps to Reproduce:
1. Causes globs that don't expand to cause errors
$ shopt -s failglob
2. Try use files from rpm as variable, and fail
$ for file in $(rpm -q --list google-noto-sans-mono-vf-fonts) ; do
[[ -f "/${file}" ]] || echo "${file}"
done
-bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf
3. Note the RC
$ echo $?
1
4. Or even command line
$ rpm -qf /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf
-bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf
$ rpm -qf '/usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf'
google-noto-sans-mono-vf-fonts-20240301-2.fc40.noarch
Actual Results:
-bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf
Expected Results:
no error accessing files with failglob shopt enabled
started fedora 40 upgrade, as daily script of mine fails because this file is
included in initramfs too.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2277345
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=2274629
Bug ID: 2274629
Summary: Please branch and build artwiz-aleczapka-fonts in
epel9
Product: Fedora EPEL
Version: epel9
Status: NEW
Component: artwiz-aleczapka-fonts
Assignee: dchen(a)redhat.com
Reporter: davide(a)cavalca.name
QA Contact: extras-qa(a)fedoraproject.org
CC: dchen(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org,
spotrh(a)gmail.com
Blocks: 1914423 (EPELPackagersSIG)
Target Milestone: ---
Classification: Fedora
Please branch and build artwiz-aleczapka-fonts in epel9.
If you do not wish to maintain artwiz-aleczapka-fonts 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/artwiz-aleczapka-fonts/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=2274629
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=2166360
Bug ID: 2166360
Summary: sil-andika-fonts-6.200 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: sil-andika-fonts
Keywords: FutureFeature, Triaged
Assignee: aekoroglu(a)linux.intel.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: aekoroglu(a)linux.intel.com,
fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net
Target Milestone: ---
Classification: Fedora
Releases retrieved: 6.200
Upstream release that is considered latest: 6.200
Current version/release in rawhide: 6.101-3.fc38
URL: https://software.sil.org/andika/
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/4816/
To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/sil-andika-fonts
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2166360
https://bugzilla.redhat.com/show_bug.cgi?id=2262410
Bug ID: 2262410
Summary: Fonts are looking wrong after 20240101 update
Product: Fedora
Version: 39
Hardware: x86_64
OS: Linux
Status: NEW
Component: google-noto-fonts
Severity: medium
Assignee: tagoh(a)redhat.com
Reporter: priv.luk(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Fonts look improperly in multiple places, e.g. mpv or KDE file picker.
Reproducible: Always
Steps to Reproduce:
1. Open mpv and look at OSD fonts
Actual Results:
Fonts look wrong
Expected Results:
Fonts look properly
See https://github.com/mpv-player/mpv/issues/13396 for screenshots.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2262410
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=1999078
Bug ID: 1999078
Summary: Hinting broken for Bitstream Vera/DejaVu in Epiphany
Product: Fedora
Version: 34
Status: NEW
Component: freetype
Assignee: mkasik(a)redhat.com
Reporter: ossman(a)cendio.se
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,
kevin(a)tigcc.ticalc.org, mark(a)net-c.com,
mclasen(a)redhat.com, mkasik(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1819062
--> https://bugzilla.redhat.com/attachment.cgi?id=1819062&action=edit
Screenshot with varying sub pixel placement
Description of problem:
After upgrading from Fedora 33 to Fedora 34, there is some extremely odd
hinting bug in Epiphany. The same glyph appears with different amount of
hinting in the same line of text, causing a very odd and blurry appearance.
Version-Release number of selected component (if applicable):
freetype-2.10.4-3.fc34.x86_64
bitstream-vera-sans-fonts-1.10-41.fc33.noarch
dejavu-sans-fonts-2.37-16.fc34.noarch
epiphany-40.3-1.fc34.x86_64
webkit2gtk3-2.32.3-1.fc34.x86_64
pango-1.48.9-2.fc34.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Configure Epiphany to use Bitstream Vera or DejaVu Sans Book
2. Configure full hinting
Actual results:
Fully hinted, consistent glyphs.
Expected results:
Some glyphs are fully hinted, some look like they've been offset by a fraction
of a pixel. (See screenshot)
Additional info:
So far I'm only seeing this in Epiphany. I still filed this for freetype since
as far as I know it is freetype that does all glyph layout, hinting and
sub-pixel stuff. Feel free to move as appropriate. So it seems odd that a bug
in Epiphany can screw this up.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Bug ID: 1833858
Summary: Hangul Jamo is seperated and printed respectively
Product: Fedora
Version: 32
Status: NEW
Component: google-droid-fonts
Assignee: nicolas.mailhot(a)laposte.net
Reporter: hyunwoo.park(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, oliver(a)redhat.com,
paul(a)frixxon.co.uk, tremble(a)tremble.org.uk
Target Milestone: ---
Classification: Fedora
Created attachment 1687129
--> https://bugzilla.redhat.com/attachment.cgi?id=1687129&action=edit
wrong display of Hangul at LibreOffice Writer
Description of problem:
When Hangul is output to the monitor, Chosung, Neutral, and Jongseong are
output separately.
Version-Release number of selected component (if applicable):
Font file, /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf,
of google-droid-sans-fonts-20200215-3.fc32.noarch
How reproducible:
If you create a test.html containing "가속도" and open the file in the chrome
browser, the Korean alphabet will be displayed separately.
Or, write "가속도" at LibreOffice Writer and select font as "Droid Sans Fallback".
Steps to Reproduce:
1. write "가속도" at LibreOffece Writer
2. select the text and change font name to "Droid Sans Fallback"
Actual results:
The text is displayed like "가ㅅㅗㄱㄷㅗ".
Expected results:
Text should be "가속도"
Additional info:
https://kldp.org/node/163247
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2213602
Bug ID: 2213602
Summary: update to version 7.0
Product: Fedora
Version: rawhide
OS: Linux
Status: NEW
Component: paktype-naskh-basic-fonts
Severity: medium
Assignee: extras-orphan(a)fedoraproject.org
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: extras-orphan(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, vishalvijayraghavan(a)gmail.com
Target Milestone: ---
Classification: Fedora
Currently we have version 6.0 in Fedora.
In April 7.0 was released.
Reproducible: Always
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2213602
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=1999864
Bug ID: 1999864
Summary: Cannot find package with font for Coptic although such
a package exists for Fedora 34
Product: Fedora
Version: 34
Status: NEW
Component: fontconfig
Assignee: tagoh(a)redhat.com
Reporter: mfabian(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
Created attachment 1819530
--> https://bugzilla.redhat.com/attachment.cgi?id=1819530&action=edit
Gnome Software unable to find Coptic fonts
Using Fedora-Workstation-Live-x86_64-34-1.2.iso in qemu.
I played with emoji picker and Gnome popped up something requesting more fonts.
I clicked and then Gnome Software said:
“Unable to find the Coptic, Persian, Old (ca. 600-400 B.C.), Ugaritic you were
searching for. Please see _the documentation_ for more information.”
See attached screenshot.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2251384
Bug ID: 2251384
Summary: Wrong Arabic font prioritization in several apps.
(Droid kufi prioritized over noto-sans)
Product: Fedora
Version: 39
OS: Linux
Status: NEW
Component: fontconfig
Severity: low
Assignee: tagoh(a)redhat.com
Reporter: alawamiaz(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
rstrode(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Few fedora releases ago, Noto-Sans-Arabic was set to be the default. It was
working fine and Arabic text was displayed in all web browsers using this font.
sometime in last few months, every web browser in fedora suddenly started
prioritizing "Druid Kufi" font over noto-sans-arabic. which now looks makes
arabic text looks jarring.
Interestingly, when running from live usb image, noto-sans-arabic is correctly
priotirized and being used to render all arabic web pages, but only for FEW
MINUTES and then suddenly it's switched to druid kufi!, without updating
anything, just running Firefox for few minutes.
It's also reproducible after fresh install, the first 3 minutes of using the
new fedora installation, Firefox and other browsers are displaying noto-sans
then suddenly switch to druid kufi.
Version-Release number of selected component (if applicable):
38-39
How reproducible:
Consistently
Steps to Reproduce:
1.Connect to internet
2.Open arabic webpage in firefox (ex, wikipedia)
3.text would be displayed with druid kufi instead of the default
noto-sans-arabic which was chosen to be the default sometime around fedora 36.
Actual results:
Arabic Text displayed with druid kufi font
Expected results:
Arabic text should be displayed using noto-sans-arabic as was the case before.
Additional info:
The font in gnome and top bars is still correctly displayed using
noto-sans-arabic. It's browsers that exhibit the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2251384
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=2247028
Bug ID: 2247028
Summary: fonttools fails to build with Python 3.13: error:
implicit declaration of function ‘_PyLong_Copy’
Product: Fedora
Version: rawhide
Status: NEW
Component: fonttools
Assignee: pnemade(a)redhat.com
Reporter: ksurma(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, ksurma(a)redhat.com,
mhroncok(a)redhat.com, pnemade(a)redhat.com,
tagoh(a)redhat.com
Blocks: 2244836 (PYTHON3.13)
Target Milestone: ---
Classification: Fedora
fonttools fails to build with Python 3.13.0a1.
This report is automated and not very verbose, but we'll try to get back here
with details.
Lib/fontTools/qu2cu/qu2cu.c: In function ‘__Pyx_PyLong_AbsNeg’:
Lib/fontTools/qu2cu/qu2cu.c:10421:26: error: implicit declaration of function
‘_PyLong_Copy’ [-Werror=implicit-function-declaration]
10421 | PyObject *copy = _PyLong_Copy((PyLongObject*)n);
| ^~~~~~~~~~~~
https://docs.python.org/3.13/whatsnew/3.13.html
For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.13/fedora-r…
For all our attempts to build fonttools with Python 3.13, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/package/fonttoo…
Testing and mass rebuild of packages is happening in copr.
You can follow these instructions to test locally in mock if your package
builds with Python 3.13:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/
Let us know here if you have any questions.
Python 3.13 is planned to be included in Fedora 41.
To make that update smoother, we're building Fedora packages with all
pre-releases of Python 3.13.
A build failure prevents us from testing all dependent packages (transitive
[Build]Requires),
so if this package is required a lot, it's important for us to get it fixed
soon.
We'd appreciate help from the people who know this package best,
but if you don't want to work on this now, let us know so we can try to work
around it on our side.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2244836
[Bug 2244836] Python 3.13
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2247028
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=2245798
Bug ID: 2245798
Summary: fontforge fails to build with Python 3.13: error:
implicit declaration of function `Py_SetProgramName`
Product: Fedora
Version: rawhide
Status: NEW
Component: fontforge
Assignee: kevin(a)scrye.com
Reporter: ksurma(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, kevin(a)scrye.com,
ksurma(a)redhat.com, mhroncok(a)redhat.com,
pnemade(a)redhat.com
Blocks: 2231791 (F40FTBFS,RAWHIDEFTBFS), 2244836 (PYTHON3.13)
Target Milestone: ---
Classification: Fedora
fontforge fails to build with Python 3.13.0a1.
/builddir/build/BUILD/fontforge-20230101/fontforge/python.c:19636:5: error:
implicit declaration of function ‘Py_SetProgramName’; did you mean
‘Py_GetProgramName’? [-Werror=implicit-function-declaration]
19636 | Py_SetProgramName(saved_progname);
| ^~~~~~~~~~~~~~~~~
| Py_GetProgramName
Py_SetProgramName has been removed from Python 3.13.
According to https://docs.python.org/3.13/whatsnew/3.13.html:
Py_SetProgramName(): set PyConfig.program_name instead.
https://docs.python.org/3.13/whatsnew/3.13.html
For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.13/fedora-r…
For all our attempts to build fontforge with Python 3.13, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/package/fontfor…
Testing and mass rebuild of packages is happening in copr.
You can follow these instructions to test locally in mock if your package
builds with Python 3.13:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/
Let us know here if you have any questions.
Python 3.13 is planned to be included in Fedora 41.
To make that update smoother, we're building Fedora packages with all
pre-releases of Python 3.13.
A build failure prevents us from testing all dependent packages (transitive
[Build]Requires),
so if this package is required a lot, it's important for us to get it fixed
soon.
We'd appreciate help from the people who know this package best,
but if you don't want to work on this now, let us know so we can try to work
around it on our side.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2231791
[Bug 2231791] Fedora 40 FTBFS Tracker
https://bugzilla.redhat.com/show_bug.cgi?id=2244836
[Bug 2244836] Python 3.13
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2245798
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=2258723
Bug ID: 2258723
Summary: Variable fonts packages dont include all axis
Product: Fedora
Version: 39
OS: Linux
Status: NEW
Component: google-noto-fonts
Keywords: RFE
Severity: low
Assignee: tagoh(a)redhat.com
Reporter: sharpenedblade(a)proton.me
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
The *-vf packages package files from the `slim-variable-ttf` dir, which do not
include every axis available for the font. Variable font files with all
supported axis are in `variable-ttf` dir instead.
Reproducible: Always
Steps to Reproduce:
1. Install `google-noto-sans-vf`
2. Check which axis are supported
3. Download
`https://github.com/notofonts/notofonts.github.io/archive/refs/tags/noto-monthly-release-23.8.1.tar.gz`
and look in the `fonts/NotoSans/unhinted/variable-ttf` direcotry
Actual Results:
Only the weight axis is variable in this package
Expected Results:
The weight and width axis are variable in this package
Changing the path at
https://src.fedoraproject.org/rpms/google-noto-fonts/blob/rawhide/f/google-…
works for every variable font/script except for NotoKufiArabic, which has the
complete font files in the `variable` dir.
Before compression, this is ~16mb larger than before (total, across all
subpackages).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2258723
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=2207623
Bug ID: 2207623
Summary: Please branch and build mozilla-fira-fonts in epel9
Product: Fedora
Version: 38
OS: Linux
Status: NEW
Component: mozilla-fira-fonts
Severity: medium
Assignee: relrod(a)redhat.com
Reporter: redhat(a)skarbek.name
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org, relrod(a)redhat.com
Target Milestone: ---
Classification: Fedora
Please branch and build mozilla-fira-fonts in epel9.
Reproducible: Always
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2207623
https://bugzilla.redhat.com/show_bug.cgi?id=2253923
Parag Nemade <pnemade(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |NOTABUG
Status|NEW |CLOSED
Last Closed| |2024-04-23 03:30:51
--- Comment #16 from Parag Nemade <pnemade(a)redhat.com> ---
Thanks for your comment.
Please do keep reporting bugs as and when you find them.
But good to add one more comment to bug about what were you doing when that bug
occurred. This will help us to follow same steps to reproduce reported bug.
Bugs detected by Fedora shows how many times its detected. So if you find count
more than 1 time bug is detected then you can try to remember what were you
doing that might have caused that bug detected by Fedora on your system.
Right now I am closing this bug as there is not much information available on
how to reproduce this bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253923
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=2253923
Sylvain Arth <sylvain(a)gwenved.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(sylvain(a)gwenved.o |
|rg) |
--- Comment #15 from Sylvain Arth <sylvain(a)gwenved.org> ---
I'd like to answer, to the question "How to reproduce" because I really can't.
Nowadays; all my Fedora OS machines are running as virtual machines on two
different Windows servers.
The main purpose of those instances is to act as servers for mails, DNS, NTP
and many other usual servers like that.
Punctually, I use them for comparison about possibly different behaviour about
"mock-up software" of my personal coding in Ada complied with GNAT.
In other words, I usually just check by emails that all those V-machines and
servers are still in good health.
I very rarely fall into the bug I reported, whilst I'm currently doing anything
on.
Most of the time, It's after reboot-startup (clean or dirty because of some
failure of the hosting PC), at login time I get the warning about bugs detected
by Fedora.
I could ignore them, but my thought is that it could help bug solving, with
providing more data, even "raw" ones.
I very know this is not quite at all the best bug reporting way.
But I also know (I was famous about that prior I retired) my "bug catcher"
reputation.
In other words, I tend to fall into bug traps other people never fall in.
I ignore why about this, I just know it's a fact.
I just suspect it's because I've my own way to do things that is often not the
"most common way to do things".
But if my reports are rather totally useless, just tell me that's the actual
case.
If so, I will totally stop top sending such kind of reports, to only report
those I'm able to tell something like a clue about "how to reproduce,
possibly".
Regards
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253923
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…