https://bugzilla.redhat.com/show_bug.cgi?id=1943000
Bug ID: 1943000
Summary: emacs-lookup: FTBFS with upcoming autoconf-2.71
Product: Fedora
Version: rawhide
Status: NEW
Component: emacs-lookup
Assignee: dueno(a)redhat.com
Reporter: odubaj(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Blocks: 1942967
Target Milestone: ---
Classification: Fedora
Your package fails to build with the newest upcoming autoconf-2.71, which is
part of a wide Fedora change. Please see the attached copr:
https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/. More
information about testing your package when building with autoconf available
here: https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1942967
[Bug 1942967] FTBFS with upcoming autoconf-2.71
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1951861
Bug ID: 1951861
Summary: switch to using %transfiletriggerin for updating ibus
cache
Product: Fedora
Version: rawhide
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Rather than having each ibus engine update in a dnf transaction
running ibus write-cache --system twice (%post and %postun) or once
separately in %posttrans, it would be better to do it centrally
from ibus.spec using a file trigger on "/usr/share/ibus/component".
I think you tested it locally once and I believe it should work well enough.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1690275
--- Comment #7 from Leslie Satenstein <lsatenstein(a)yahoo.com> ---
I am in Québec Canada, and since I use English, some Spanish and much French,
my keyboard layout is Canada French.
With Gnome, there is no issue, I just go to keyboard and set up the layout, and
to region and language, and setup the language and keyboard layout.
With many of the Remixes, eg, Deepin, Mate, etc, (my favoured language
interface is the default English language, but the Keyboard layout I chose, the
Canada French keyboard layout is not listed or the default. The default is
American English.
To set it up with the Deepin and other Remixes, I had to set the
region/language to French, and then I could search and find the French keyboard
layout. which now appeared in the list. I chose my Canadian French layout, and
exited.
I rebooted and on my first logon, everything was in French, (mostly). I used
the gnome settings to reset the region/language to Canadian English (favor
-->favour, neighbor -->neighbour) and rebooted.
Deepin now works in Canadian English with my Canadian French keyboard layout.
Mate and the others need the same tender loving care.
A good fix would be to have each remix show the entire list of keyboard
layouts, irrespective of the chosen "user interface language".
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1526467
Mike FABIAN <mfabian(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|33 |34
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1526464
Mike FABIAN <mfabian(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|33 |34
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1526463
Mike FABIAN <mfabian(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|33 |34
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1761885
Jens Petersen <petersen(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?(tagoh(a)redhat.com)
--- Comment #9 from Jens Petersen <petersen(a)redhat.com> ---
I am not seeing this on my Fedora 34 systems?
What am I missing? Because no fonts updated yet?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1699211
Jens Petersen <petersen(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |FutureFeature
Version|33 |rawhide
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1967541
Bug ID: 1967541
Summary: zinnia fails to build in Fedora 35+: Broken RPATH will
fail rpmbuild
Product: Fedora
Version: rawhide
Status: NEW
Component: zinnia
Assignee: liangsuilong(a)gmail.com
Reporter: thrnciar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
liangsuilong(a)gmail.com, mhroncok(a)redhat.com,
petersen(a)redhat.com, pwu(a)redhat.com,
thrnciar(a)redhat.com
Blocks: 1890881 (PYTHON3.10)
Target Milestone: ---
Classification: Fedora
zinnia fails to build in Fedora 35+
https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild
Related section in packaging guidelines.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
+ /usr/lib/rpm/check-rpaths
*******************************************************************************
*
* WARNING: 'check-rpaths' detected a broken RPATH OR RUNPATH and will cause
* 'rpmbuild' to fail. To ignore these errors, you can set the
* '$QA_RPATHS' environment variable which is a bitmask allowing the
* values below. The current value of QA_RPATHS is 0x0000.
*
* 0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
* issue but are introducing redundant searchpaths without
* providing a benefit. They can also cause errors in multilib
* environments.
* 0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
* nor relative filenames and can therefore be a SECURITY risk
* 0x0004 ... insecure RPATHs; these are relative RPATHs which are a
* SECURITY risk
* 0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
* RPATHs; this is just a minor issue but usually unwanted
* 0x0010 ... the RPATH is empty; there is no reason for such RPATHs
* and they cause unneeded work while loading libraries
* 0x0020 ... an RPATH references '..' of an absolute path; this will break
* the functionality when the path before '..' is a symlink
*
*
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
* $ QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like
* $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
*
*******************************************************************************
ERROR 0001: file '/usr/bin/zinnia_convert' contains a standard runpath
'/usr/lib64' in [/usr/lib64]
ERROR 0001: file '/usr/bin/zinnia_learn' contains a standard runpath
'/usr/lib64' in [/usr/lib64]
ERROR 0001: file '/usr/bin/zinnia' contains a standard runpath '/usr/lib64'
in [/usr/lib64]
For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.10/fedora-r…
For all our attempts to build zinnia with Python 3.10, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/package/zinnia/
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.10:
https://copr.fedorainfracloud.org/coprs/g/python/python3.10/
Let us know here if you have any questions.
Python 3.10 will be included in Fedora 35. To make that update smoother, we're
building Fedora packages with early pre-releases of Python 3.10.
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=1890881
[Bug 1890881] Python 3.10 tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #23 from Luke Hutchison <luke.hutch(a)gmail.com> ---
PS Droid Sans Fallback is often selected as the sans fallback font by Chrome on
Fedora, and since the droid-sans-fonts package is default on Fedora (or at
least a dependency of many other packages), this font frequently breaks Web
browsing in Korean on Fedora -- so it's a pretty visible bug.
Even within a single sentence, some words (words starting with 가) fall back to
Droid Sans Fallback, and some fall back to Noto Sans CJK. See a depiction of
this pattern here:
https://github.com/harfbuzz/harfbuzz/issues/3003
The reason for this is probably that 가 is the pronunciation of the first jamo
in the Korean alphabet, so it is used when spelling out bullet points etc.
(equivalent to A, B, C, ...), and I'm guessing that Droid Sans Fallback
contains the phonetic spelling of each jamo such as 가. So the fallback decision
is made based on the first character in each word (at least in Google Docs,
which probably calls the font measuring API for each word in a sentence,
triggering a fallback decision for each word).
This indicates that the fallback logic can be improved. Currently the fallback
determination seems to be being made based on the first Unicode codepoint in a
span of text submitted for shaping. Is that a correct assumption?
--
You are receiving this mail because:
You are on the CC list for the bug.