F30 Self-Contained Change proposal: Ibus-typing-booster default for
Indian languages
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_in...
== Summary ==
Make ibus-typing-booster the default input method for Indian languages.
== Owner ==
* Name: [[User:Mfabian|Mike Fabian]]
* Email: <mfabian(a)redhat.com>
== Detailed Description ==
Currently, ibus-m17n is the default input method for Indian languages
in Fedora. ibus-typing-booster uses the same libm17n used by
ibus-m17n to support input for Indian languages and thus it can do
everything ibus-m17n can do. But on top of that, ibus-typing-booster
supports predictive input by remembering user input and by using words
from dictionaries. Therefore, ibus-typing-booster is a more useful input method
for these languages.
== Benefit to Fedora ==
A better input experience for users of Indian languages.
== Scope ==
* Proposal owners:
The langtable package has data about default input methods. Change this data.
But the data in langtable is currently apparently not used by
gnome-initial setup.
The list of default input methods used by gnome-initial-setup us stored in
<pre>
libgnome-desktop/default-input-sources.h
</pre>
Currently there are the following default input methods for the Indian locales:
<pre>
static DefaultInputSource default_input_sources[] =
{
...
{ "as_IN", "ibus", "m17n:as:phonetic" },
...
{ "bn_IN", "ibus", "m17n:bn:inscript" },
...
{ "gu_IN", "ibus", "m17n:gu:inscript" },
...
{ "hi_IN", "ibus", "m17n:hi:inscript" },
...
{ "kn_IN", "ibus", "m17n:kn:kgp" },
...
{ "mai_IN", "ibus", "m17n:mai:inscript" },
...
{ "ml_IN", "ibus", "m17n:ml:inscript" },
...
{ "mr_IN", "ibus", "m17n:mr:inscript" },
...
{ "or_IN", "ibus", "m17n:or:inscript" },
...
{ "pa_IN", "ibus", "m17n:pa:inscript" },
...
{ "sd_IN", "ibus", "m17n:sd:inscript" },
...
{ "ta_IN", "ibus", "m17n:ta:tamil99" },
...
{ "te_IN", "ibus", "m17n:te:inscript" },
...
{ "ur_IN", "ibus", "m17n:ur:phonetic" },
...
</pre>
Here, "m17n:as:phonetic" would need to be replaced with "typing-booster".
And similar for the other Indian languages.
ibus-typing-booster selects the default input method to use
from the locale when it is first started. For the above Indian
locales ibus-typing-booster >= 2.4.2 has the same default
m17n input methods as libgnome-desktop/default-input-sources.h,
except that it always uses inscript2 instead of inscript by default.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Nothing should happen when upgrading from a previous version of Fedora.
If a user used ibus-m17n before the upgrade, he will still use it
after the upgrade.
This change proposal only changes the default input method for an
Indian language
for new installs or new user accounts.
== How To Test ==
Do a new installation of Fedora 30 in an Indian language. Log into Gnome.
See what input method is suggested by default by gnome-initial-setup.
== User Experience ==
Easier input of Indian language because of predictive input.
== Dependencies ==
gnome-initial-setup
== Contingency Plan ==
* Contingency mechanism: Leave the default input methods as they are
now and move the change to Fedora 31
* Contingency deadline: Fedora 30 Beta release
* Blocks release? No.
* Blocks product? No.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
F30 Self-Contained Change proposal: Bash 5.0
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Bash_5.0
== Summary ==
Upgrade bash to 5.0 release. This release fixes several outstanding
bugs in bash-4.4 and introduces several
new features. The most significant bug fixes are an overhaul of how
nameref variables resolve and a number of potential out-of-bounds memory
errors discovered via fuzzing.
== Owner ==
* Name: [[User:svashisht| Siteshwar Vashisht]]
* Email: svashisht(a)redhat.com
* Release notes owner:
== Detailed Description ==
There are a number of changes to the
expansion of $@ and $* in various contexts where word splitting is not
performed to conform to a Posix standard interpretation, and additional
changes to resolve corner cases for Posix conformance.
The most notable new features are several new shell variables: BASH_ARGV0,
EPOCHSECONDS, and EPOCHREALTIME. The `history` builtin can remove ranges of
history entries and understands negative arguments as offsets from the end
of the history list. There is an option to allow local variables to inherit
the value of a variable with the same name at a preceding scope. There is
a new shell option that, when enabled, causes the shell to attempt to
expand associative array subscripts only once (this is an issue when they
are used in arithmetic expressions). The `globasciiranges' shell option
is now enabled by default; it can be set to off by default at configuration
time.
There are a few incompatible changes between bash-4.4 and bash-5.0. The
changes to how nameref variables are resolved means that some uses of
namerefs will behave differently, though upstream has tried to minimize the
compatibility issues.
== Benefit to Fedora ==
Bash is the default shell in Fedora and it will benefit from new
features and performance improvements of the latest release.
== Scope ==
* Proposal owners: Upgrade bash to 5.0
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
** List of deliverables]: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Code related to resolving namerefs was changed, so some scripts may
break. But impact should be minimum as this release is largely
backward compatible.
== Dependencies ==
N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
Retiring perl-perlmenu
by Emmanuel Seyman
[ perl-devel is in cc: ]
Hello, all.
I maintain perl-perlmenu in Fedora and I will be retiring it at the end
of the week unless someone offers to maintain it instead. For the record,
I would advise against this since upstream no longer exists and nothing
depends on the particular package.
Emmanuel
5 years, 2 months
Orphaning: llvm5.0, clang5.0, llvm6.0, clang6.0
by Tom Stellard
Hi,
I am orphaning the llvm and clang compatibility packages for versions 5.0 and 6.0.
We are about to push LLVM 8.0 into rawhide, so I will no longer maintain these
older versions. There are still a few users of these packages, so the package
owners can either rebuild their packages for LLVM 7/8 or take over ownership
of the compatibility package they need.
-Tom
5 years, 2 months
Boost 1.69 update with soname bumps in rawhide/F30
by Jonathan Wakely
With enormous thanks to Denis Arnaud for doing the actual boost.spec
rebase, we're ready to update Boost in rawhide, for this change:
https://fedoraproject.org/wiki/Changes/F30Boost169
As always, this changes the soname of every libboost_*.so library, so
we'll be rebuilding all the packages that link to Boost libs. These
rebuilds will happen on the f30-boost side tag, and once they're all
done everything will move to the main f30 target all at once.
IF YOU MAINTAIN A PACKAGE THAT DEPENDS ON BOOST and need to rebuild it
in the next few days, please get in touch so we can coordinate. It's
better to avoid me doing a rebuild in the f30-boost side tag, then
somebody else doing another rebuild in the main f30 target, and then
me having to do another build in the side tag! If you'd rather I don't
rebuild your package (e.g. so you can finish an update and then build
it yourself) please get in touch.
I've done local builds of most of them, and 130+ build OK. Any that
fail I'll create bugzilla FTBFS reports for.
I expect the following to fail, because they link to
libboost_python.so and that has changed to libboost_python27.so, so
unless they have build-system logic to already detect that change
(which might exist in some build systems already, I guess), they'll
need a fix:
avogadro
condor
dmlite
freecad
gfal2-python
ledger
5 years, 2 months
Intel's Clear Linux optimizations
by František Zatloukal
Hi,
Phoronix recently release article[1] about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
settings.
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
[1]
http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1
--
Best regards / S pozdravem,
František Zatloukal
Project Coordinator
Red Hat
5 years, 2 months
Orphaning pl (SWI Prolog)
by Petr Pisar
I have no interest in maintaining pl (SWI Prolog) package and thus I'm
going to orphan it.
The package is a Prolog langugage interpreter with bundled various
libraries and tools written in that language. E.g. an HTTP server or an
interface to Java virtual machine.
Upstream does a new major release roughly every year and a few bug-fix
releases during the year.
From packaging point of view there are few downs like:
Reviewing each rebase for licenses is tiresome due the size (118 MB).
Upstream does not like how it is packaged because Fedora bends it to FHS.
Fedora does not like how it is packaged because it's not bended enough.
There are occasional FTBFS when JVM reorganizes its files.
The package should be renamed to swipl to match the upstream.
The source archive is stripped down from non-free files.
The pl package has two comaintainers, mef and bagnara, who did not touch the
pacakge for last 10 years.
The package is required when building and running these source packages:
perl-Language-Prolog-Yaswi ppisar,jplesnik Can be removed.
ppl bagnara,pcpa A subpackage can be disabled.
python-pyswip thofmann A subpackage can be disabled.
The package builds fine now and a new 8.1 release is waiting for
packaging.
If you want to take over a maintainership of this package, let me know
and I will assign it to you. Otherwise I will orphan it next week.
-- Petr
5 years, 2 months
F30 Self-Contained Change proposal: Improved GRUB menu
by Ben Cotton
https://fedoraproject.org/wiki/Changes/ImprovedGrubMenu
== Summary ==
Improve the GRUB menu by only having the default boot option for each
installed operating system in the main menu, and the other options
into a sub-menu. This would better organize the boot options and lead
to an easier and seamless boot experience.
== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javierm(a)redhat.com
== Detailed Description ==
The current GRUB menu is confusing, specially when multiple operating
systems are installed. The Fedora boot entries are added first and
then the ones for the other installed operating systems.
The main menu contains all the boot entries for Fedora but only the
default boot entry for the other operating systems, the non-default
boot entries for the other installed operating systems are placed into
a per operating system sub-menu.
An example of how the GRUB menu currently looks can be found at
[https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png
https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png]
This can be improved by adding a sub-menu for the Fedora non-default
boot entries, as is already the case for the other installed operating
systems. This will make the boot entries for all the operating systems
consistent.
Another improvement would be to group all the default options for the
operating systems as one section, followed by another section that
groups all the sub-menus for the non-default options.
A tentative design made by Allan Day for the improved GRUB menu can be
found at [https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design
https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design]
For Fedora, the boot option in the main menu will either be the
selected default boot entry or if no default was chosen, the latest
installed kernel. For the other installed operating systems, the boot
option in the main menu will be the latest kernel as found by GRUB's
os-prober script.
== Benefit to Fedora ==
Making the menu less confusing and with better organized boot options
will lead to a better user experience and make easier for users to
choose the operating systems to boot.
== Scope ==
* Proposal owners:
# Change GRUB to implement the changes as described in the "Detailed
Description" section.
# Make sure this is all properly documented in release-notes, etc.
* Other developers:
# Test and watch for regressions.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: No changes needed.
== Upgrade/compatibility impact ==
The changes are in the grub.cfg file generated at install time by
Anaconda. Users can manually enable this after an upgrade by executing
gru2-mkconfig to regenerate their grub.cfg file.
== How To Test ==
# Single OS test
## Install Fedora in a VM.
## On boot the default boot option is in the main menu and the other
options (e.g: rescue boot option) are in a sub-menu.
# Multi boot test
## Install Fedora on a machine which other operating system installed.
## On boot the default boot options for the operating systems are in
the main menu and the other options in sub-menus.
== User Experience ==
A simpler and easier to understand GRUB boot menu. Choosing which
operating system to boot should be simpler and involve less steps.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the GRUB changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
== Summary ==
Remove scriptlets which are not needed anymore (ldconfig,
gtk-update-icon-cache, etc.).
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]]
* Email: ignatenkobrain(a)fedoraproject.org
== Scope ==
* Proposal owners: Find appropriate packages and remove obsolete scriptlets.
* Other developers: Package Maintainers are advised to remove
scriptlets themselves or wait until Proposal Owners will do that.
* Release engineering: [https://pagure.io/releng/issue/7977 #7977] (to
avoid multiple rebuilds, completing this change before mass rebuild is
advised)
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: N/A
* Policies and guidelines: Guidelines are already updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Installed F30 RPMs on F28/EL6/EL7 might not work although it is not supported.
== How To Test ==
Install new version of package with removed scriptlets and observe
that it works.
== User Experience ==
Installation of packages are faster.
== Dependencies ==
No specific dependencies.
== Contingency Plan ==
* Contingency mechanism: Proposal Owners will revert changes which
break specific packages when encountered.
* Contingency deadline: Final freeze.
* Blocks release? No
== Documentation ==
Everything is already documented in
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/
Packaging Guidelines].
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
Fixing Wireguard spec file
by Germano Massullo
This [1] is the Wireguard spec file from upstream Copr repo [2].
Wireguard will be included in kernel 5.0, but meanwhile we are using it as dkms.
The only problem is that at every Wireguard upgrade, a manual action
is required.
For example now that I have installed 0.0.20190123, I have to remove the old
/var/lib/dkms/wireguard/0.0.20181218/
folder in order to let
# dkms autoinstall
work.
Otherwise I will get a
=======
# dkms status
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist.
=======
and wg-quick service unable to start.
Do you have any idea about how the Wireguard spec file could be fixed
in order to avoid this action having to be runned at every package
update?
Thank you
[1]: https://copr-be.cloud.fedoraproject.org/results/jdoss/wireguard/fedora-29...
[2]: https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/
5 years, 2 months
