libportal license change and soname bump
by David King
As part of updating libportal to 0.5 in rawhide, there was a license
change from LGPLv2+ to LGPLv3.
The soname changed from libportal.so.0 to libportal.so.1, and I rebuilt
the following packages:
* epiphany
* gcolor3 (coordinated with fnux)
* gnome-builder
* gnome-todo
If there are any other packages which are affected, please let me know.
--
https://amigadave.com/
2 years, 5 months
Self Introduction: Brad Smith (aka buckaroogeek)
by Brad Smith
Greetings
Peter Hunt (aka haircommander) asked if I might be interested in
assisting with the maintenance of the kubernetes packages for Fedora.
I have the time and interest and some of the needed skills. I am
certainly willing to learn.
I am a retired senior manager for a U.S federal agency (US Forest
Service). I have a background in software development over the past
several decades contributing PRs for a number of open source projects
but am not an active member of any specific project. I have a number
of repositories on github including several fedora specific ansible
roles (https://github.com/buckaroogeek?tab=repositories). I also
recently submitted a short note to fedora magazine about some
optimizations to DNF that are useful on low/expensive bandwidth
internet connections (see
https://fedoramagazine.org/use-the-dnf-local-plugin-to-speed-up-your-home...).
Fedora is my primary OS at home for my workstation and Raspberry Pi
kubernetes cluster. The RPi4s all use Fedora 35 minimal currently with
ongoing experiments with Fedora CoreOS. I started with Fedora 2,
switching from Red Hat desktop.
I have long been an open source advocate. During my federal career, I
was the principal open source advocate within the Forest Service IT
team. I led the adoption of collaborative source code management, and
the adoption and use of open source tools and code. I installed and
managed Enterprise SourceForge in the early 1990s for the agency and
was an active leader in moving the agency from SUSE and AIX to RHEL as
the primary OS in our data centers.
Looking forward to contributing where I can.
Best wishes
Brad
2 years, 5 months
dosbox-staging license change: from GPLv2+ to GPLv3+
by Otto Urpelainen
I have changed the License field of dosbox-staging from GPLv2+ to
GPLv3+. That has been the correct license from start, but previously,
licenses of this package's many bundled dependencies were not
considered. Most of the licenses are permissive or public domain-like,
but one is GPLv3+, which becomes the effective license.
2 years, 5 months
'kinit' not works
by Евгений Пивнев
Trying to push new package:
```
bash-5.1$ kinit tieugene(a)FEDORAPROJECT.ORG
kinit: Cannot find KDC for realm "FEDORAPROJECT.ORG" while getting initial credentials
```
I’m wrong? Or what happens?
F35, updated an hour ago.
2 years, 5 months
F36 Change: Ibus-table cangjie default for zh_HK (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ibus_table_cangjie_default_for_zh_hk
== Summary ==
Make ibus-table cangjie the default input method for zh_HK (Hongkong) locale.
== Owner ==
* Name: [[User:Mfabian| Mike Fabian]]
* Email: <mfabian(a)redhat.com>
== Detailed Description ==
Currently, ibus-cangjie is the default input method for zh_HK in
Fedora. ibus-cangjie is not actively maintained anymore upstream.
ibus-table and the cangjie tables in ibus-table-chinese are actively
maintained and can replace ibus-cangjie.
== Benefit to Fedora ==
A better input experience for users of the zh_HK locale.
== 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 is the following default input method for zh_HK locale:
<pre>
static DefaultInputSource default_input_sources[] =
{
...
{ "zh_HK", "ibus", "cangjie" },
...
}
</pre>
Here, `cangjie` would need to be replaced with `table:cangjie5`.
fedora-comps needs to be updated to install
`ibus-table-chinese-cangjie` by default.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Nothing should happen when upgrading from a previous version of
Fedora. If a user used ibus-cangjie before the upgrade, they will
still use it after the upgrade. This change proposal only changes the
default input method for zh_HK locale for new installs or new user
accounts.
== How To Test ==
Do a new installation of Fedora 30 in zh_HK (Chinese Hongkont) locale.
The package `ibus-table-chinese-cangjie` should be installed.
Log into Gnome. See what input method is suggested by default by
gnome-initial-setup.
== User Experience ==
Less buggy and better maintained cangjie input method.
== Dependencies ==
gnome-initial-setup
== Contingency Plan ==
* Contingency mechanism: Leave the default input methods as they are
now and move the change to Fedora 37
* Contingency deadline: Fedora 36 Beta release
* Blocks release? No.
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
F36 Change: Malayalam Default Fonts Update (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/MalayalamDefaultFontsUpdate
== Summary ==
This change will update existing default Malayalam fonts and also
rename to new upstream source, which brings improved text shaping,
better glyphs for readability, Unicode 13 support, Appstream data
amongst other improvements.
== Owner ==
* Name: [[User:Rajeeshknambiar |Rajeesh K V]], [[User:Pnemade| Parag Nemade]]
* Email: <rajeeshknambiar(a)fedoraproject.org>, <pnemade(a)redhat.com>
== Detailed Description ==
Till Fedora 35, Meera (`smc-meera-fonts`) and Rachana
(`smc-rachana-fonts`) fonts were default sans-serif and serif fonts
for Malayalam script/language. From Fedora 36, these are obsolete by
Meera New (`rit-meera-new-fonts`) and RIT Rachana
(`rit-rachana-fonts`) respectively.
{| class="wikitable"
|-
! Style!! F35 Fontname!! F36 Fontname
|-
| Sans-Serif || Meera || Meera New
|-
| Serif || Rachana || RIT Rachana
|}
A new collection of Malayalam fonts suited for various publishing work
is also introduced.
{| class="wikitable"
|-
! Fontname!! Uasge
|-
| Sundar || Display/title font
|-
| TN Joy || Display/title font
|-
| Ezhuthu || Script/cursive/handwriting style font
|-
| Panmana || Body text font
|}
== Benefit to Fedora ==
Enhance the experience of Fedora for Malayalam users by improving font
rendering quality, flawless OpenType shaping and improved glyph
shapes, with Unicode 13.0 support. All fonts also contain supporting
metadata such as AppStream.
Major improvements brought by the new Malayalam fonts include:
# Redrawn glyph shapes for better readability and font metrics.<ref>KH
Hussain et al., Beyond Roman fonts: Extra dimensions in Malayalam
fonts, https://tug.org/TUGboat/tb41-2/tb128hussain-beyond.pdf</ref>
# Regular, Bold, Italic and BoldItalic variants for many fonts; most
variants are not present in older fonts.
# Consistent, flawless OpenType text shaping: redesigned OTL rules
fixes all longstanding shaping issues.<ref>KV Rajeesh, A new set of
OpenType shaping rules for Malaylam,
https://rajeeshknambiar.wordpress.com/2021/09/20/a-new-set-of-opentype-sh...</ref>
# Various fonts designed for different purposes of
typesetting/publishing/design work (body text, display/title,
informal/cursive fonts).
# Fonts containing more than 900 glyphs for ‘comprehensive character
set’ for Malayalam script; and fonts with ‘limited character set’
having lesser conjuncts suited for title text.
# Unicode 13.0 support in many fonts, with archaic characters suited
for reproducing historical text/scriptures.
# AppStream metadata which provides preview of the font in software
installers like GNOME Software and Discover
# Previous upstream (SMC) has stopped maintaining default fonts in
Fedora. New upstream (RIT) is actively maintaining the fonts.
# Notable differences with Noto {Sans,Serif} Malayalam fonts are the
‘reformed’ script which contains very less conjunct characters, while
all RIT fonts are ‘traditional’ script fonts. The ex-height and
em-size of RIT fonts are more suitable for reading/composing long
Malayalam text on web/print.
== Scope ==
* Proposal owners:
# Add new packages `rit-meera-new-fonts` and `rit-rachana-fonts`
# update `langpacks` package for these font packages
# update `fedora-comps` to install these new Malayalam fonts by default
* Other developers: N/A (not a System Wide Change)
* Release engineering: 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 ==
N/A (not a System Wide Change)
== How To Test ==
* Check Malayalam web sites which uses both Malayalam Sans and Serif fonts
* Use LibreOffice, use Sans and Serif fonts to see if it uses different fonts
* also check the output of following commands giving new package names
** LANG=ml_IN.UTF-8 fc-match sans-serif:lang=ml
** LANG=ml_IN.UTF-8 fc-match serif:lang=ml
== User Experience ==
* With good quality Malayalam Sans and Serif fonts, the Desktop or Web Browser
will display with both Sans and Serif fonts.
* With different Sans and Serif fonts, the Workstation will have better
font rendering quality.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Revert to use older Malayalam fonts.
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No
* Blocks product? No
== Documentation ==
* [https://gitlab.com/rit-fonts/MeeraNew Sans font]
* [https://gitlab.com/rit-fonts/RIT-Rachana Serif font]
== Release Notes ==
By using both Malayalam Sans and Serif fonts, the Workstation will
improve Malayalam fonts rendering quality and better OpenType shaping
for users.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
F36 Change proposal: No ifcfg by default (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
== Summary ==
Do not not include NetworkManager support for legacy network
configuration files by in new installations.
== Owner ==
* Name: [[User:Lkundrak| Lubomir Rintel]]
* Email: <lkundrak(a)v3.sk>
* Name: Ana Cabral
* Email: <acabral(a)redhat.com>
* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller(a)redhat.com>
== Detailed Description ==
Long ago, network was configured using "network" service.
It was essentially a set of shell scripts, that sourced snippets of
configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
files").
The ifcfg files compatible with the legacy network service were kept
when NetworkManager was intruduced.
As the NetworkManager feature set was expanding beyond what the legacy
network service could support,
the ifcfg files written by NetworkManager could no longer be
guarranteed to be compatible.
NetworkManager eventually gained support for connection types
completely unknown to the legacy network service
and ended up using a more streamlined configuration file format for
those, known as keyfile.
NetworkManager's use of various configuration files is, in fact,
configurable and extensible with plugins.
Prior to Fedora 33, NetworkManager by default was configured to enable
both ifcfg files and keyfiles, with the former taking precedence when
possible.
The precedence changed in
[https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_...
Fedora 33] to perfer keyfile.
The precedence has an effect when a network connection profile is created.
Once the connection profile exists, NetworkManager is unable to
convert the profile to a different configuration backend.
This makes it necessary for NetworkManager to support the same feature
set in all configuration backend.
Given the complexities stemming from historical legacy of ifcfg files
not being designed (or documented) in a
particularly forward-looking way, this has been a huge and complex
effort with all the downsides:
The ifcfg support code is huge (130K lines, not counting the enormous
test suite) and has constantly been a source of bugs.
== Benefit to Fedora ==
This change removes a body of code that has a large cost in terms of
bugs and maintenance at questionable benefit.
It slightly reduces the default installation size.
== Scope ==
* Proposal owners: Split the ifcfg plugin into a subpackage package.
Make sure the ifcfg plugin stays on upgrades. Provide a migration
tool.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
For the time being the ifcfg plugin is kept around, albeit in a
sub-package that's not included in new installations.
The appropriate RPM tags will ensure the sub-package with the ifcfg
plugin will be installed on upgrades.
A migration tool will be provided for users who'd like to remove the
legacy package from their systems after upgrade.
== How To Test ==
N/A.
The keyfiles are used by default in Fedora 33 already, so any problem
with them would've already been spotted.
== User Experience ==
Regular users will not notice anything.
Users of old installations with ifcfg files will get the new
sub-package on upgrade.
New systems will default to use keyfiles, which is not something
regulars user would notice.
System integrators and administrators might use tools that drop in
ifcfg files during automated installations (e.g. via kickstart or a
configration management tool).
They will need to update their tools -- convert the ifcfg files to
keyfiles or include the ifcfg sub-package.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: If it turns out we can't drop support for
ifcfg files by default, we can either fold the ifcfg sub-package back
into the main NetworkManager package or make sure it is included in
new installations (via comps change).
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
We'll need to write the documentation for the migration tool.
Perhaps also something the sysadmins wondering why their ifcfg files
don't work anymore could find and refer to.
TODO: Update this once it's done.
== Release Notes ==
We'll need to include a paragraph about this in the release notes.
TODO: Update this with the actual release note text.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months