https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
= Wayland by Default for SDDM =
== Summary ==
Change the default display server mode for SDDM to use a Wayland-based
greeter rather than an X11-based one.
== Owner ==
* Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
[[User:Jgrulich|Jan Grulich]]
* Email: ngompa13(a)gmail.com, rdieter(a)gmail.com, jgrulich(a)redhat.com
* Product: KDE Spin, Kinoite
* Responsible WG: KDE SIG
== Detailed Description ==
With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
SDDM to support using a Wayland based greeter] and
[[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
broken fallback when platform drivers are unavailable]], it is now
possible for the Fedora KDE variants (the regular spin and Kinoite) to
move to Wayland for the login manager, which effectively completes the
switch to Wayland for these variants.
== Benefit to Fedora ==
As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
Change to switch Plasma to Wayland by default]], Fedora is a leader in
advancing the adoption of the Wayland protocol as part of the overall
strategy to improve the Linux graphical software stack. We have been
successful in helping drive Wayland forward in the Plasma Desktop, and
we intend to do the same for SDDM.
== Scope ==
* Proposal owners:
** Upgrade {{package|sddm}} to the latest snapshot and introduce
mutually exclusive <code>sddm-wayland-generic</code> and
<code>sddm-x11</code> greeter configuration packages.
** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
*** Enable installation of the SDDM Wayland configuration snippet and
ship as <code>sddm-wayland-plasma</code> that is mutually exclusive
with the other sddm greeter configuration packages. This package will
supplement {{package|sddm}} and <code>plasma-workspace-wayland</code>
to be automatically installed together.
** Modify <code>@kde-desktop</code> comps group for Fedora Linux 36 to
include <code>sddm-wayland-plasma</code> for the media.
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10536 #10536]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
On upgrade to Fedora Linux 36, SDDM will be transparently switched
from the X11 greeter to the Wayland one leveraging kwin. In order to
override this, the user can do one of the following:
* Drop in a configuration file in <code>/etc/sddm.conf.d</code> to set
the display server back to X11
* Swap back to X11 with the configuration package: <code>dnf swap
sddm-wayland-plasma sddm-x11</code>
== How To Test ==
Once the SDDM and Plasma Wayland changes are made, Rawhide users can
try this by using nightly KDE ISOs and using them normally to install
and run a Rawhide KDE Plasma environment.
== User Experience ==
Ideally, there should be no noticeable impact on the user experience,
though users may notice that things operate more smoothly and with
slightly lower resources.
== Dependencies ==
This change is dependent on [[Changes/ReplaceFbdevDrivers|the Change
to replace fbdev with SimpleDRM]]. Without that Change, we will need
to keep SDDM using X11 because otherwise the fallbacks are broken when
drivers do not work.
== Contingency Plan ==
* Contingency mechanism: Update comps and {{package|plasma-workspace}}
so that <code>sddm-x11</code> is shipped instead.
* Contingency deadline: beta freeze
* Blocks release? Yes
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
SDDM, the login manager for the Fedora variants using the KDE Plasma
Desktop, now uses the Wayland display system.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_7.0
== Summary ==
Ruby on Rails 7.0 is the latest version of well known web framework
written in Ruby.
== Owner ==
* Name: [[User:pvalena| Pavel Valena]], [[User:jprokop| Jarek Prokop]]
* Email: pvalena(a)redhat.com, jprokop(a)redhat.com,
ruby-sig(a)lists.fedoraproject.org
== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 6.1 in Fedora 35 to 7.0 (latest version) in Fedora 36.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.
== Benefit to Fedora ==
This update will keep Fedora up-to-date and will ensure that the
current Ruby on Rails developers stay with us as they will get support
for system-packaged Ruby on Rails of the latest version. Update to
Rails 7.0 contains hundreds of fixes and improvements across all the
frameworks. For new features, please see [#User_Experience User
Experience].
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated.
** Some dependencies of the Rails stack will need update.
=== Packages need to be created/updated ===
* Rails bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2032639 #2032639]
** Specific changes: (see wiki)
* Current development state can be observed in
[https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/
pvalena/ruby-on-rails] COPR repository.
** Current status: '''version 7.0.0''' built and tested
* Other developers: Update Rails dependent packages to be working with
Ruby on Rails 7.0
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Web applications build above Ruby on Rails framework might need to be
updated. Official upstream upgrade guide might come handy:
http://guides.rubyonrails.org/upgrading_ruby_on_rails.html
== How To Test ==
* No special hardware is needed.
* Some additional adjustments to dependencies are needed to start the
default app. Example:
** https://github.com/pvalena/theprototype/blob/main/rails/test.sh
=== To test only Rails itself ===
<pre>
dnf install rubygem-rails
rails new app
cd app && rails s
</pre>
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 7.0.x
=== To test the complete feature including generating a new Rails app
using RPM ===
<pre>
dnf group install 'Ruby on Rails'
rails new app --skip-bundle && cd app
rails s
</pre>
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 7.0.x
== User Experience ==
* New version of Ruby on Rails (7.0) available
* The most significant Rails 7.0 features:
** No-Node default approach to the front end
** Hotwire’s combination of Turbo and Stimulus
** Easily use any JavaScript bundler
** Encrypted attributes in Active Record
** Asynchronous Query Loading
** Zeitwerk autoloader is used exclusively
== Dependencies ==
* There are several packages, which depends on Ruby on Rails framework.
* These needs to be surely updated:
** (none)
* Following gems don't support Rails 7.0 right now and would be broken
by the update:
** (none)
* As Rails requires Ruby >= 2.7, the platform less than the version
can not use Rails 7.0.
== Contingency Plan ==
* Contingency mechanism: None needed. Rails stack won't be updated
until all its dependencies are in Rawhide. After that, it will be a
simple matter of updating the core packages (and their dependencies)
via side-tag.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
* http://api.rubyonrails.org/
== Release Notes ==
* https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision
* https://edgeguides.rubyonrails.org/7_0_release_notes.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/F36MLT-7
== Summary ==
update MLT to version 7.4 (latest version)
== Owner ==
* Name: [[User:sergiomb| Sérgio Basto]]
* Email: sergiomb(a)fedoraproject.org
== Detailed Description ==
Update of MLT from v6 to v7 breaks the builds, binaries changed the
name and devel files changed the location [1], authors argue that
facilitates have 2 versions of MLT at same time, but I personally
don't want keep to versions of MLT because MLT just 3 or 5 projects
that use it,
[1]
https://github.com/mltframework/mlt/issues/713
== Benefit to Fedora ==
Up-to-date and latest MLT release will be delivered to Fedora users.
== Scope ==
* Proposal owners: [[User:Sergiomb | Sérgio Basto]]
[[https://accounts.fedoraproject.org/user/martinkg/ | Martin
Gansser]]
* Other developers: [[User:Kwizart | Nicolas Chauvet]]
* Release engineering:
* 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 ==
We need update ETL , synfig and synfigstudio from version 1.40 to
version 1.5.1 .
webvfx (THE PROJECT IS DEPRECATED BY THE MLT TEAM AND NO LONGER
MAINTAINED) we may retire it or build it without MLT support.
== How To Test ==
Run the new synfigstudio and work with it, testing the tasks that user
already did with the previous version
== User Experience ==
They will have updated tools
== Dependencies ==
Already explained on Upgrade/compatibility impact
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) (not a System
Wide Change) report upstream and apply fixes ASAP
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
https://www.mltframework.org/docs/
== Release Notes ==
post https://www.mltframework.org/blog/v7.0.0_released/
and blog it self https://www.mltframework.org/blog/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Just thought I would share that (finally) we have completed upgrades on
the koji hubs and builders.
The hubs have been upgraded to Fedora 35 and
the latest koji version (1.17.1).
Builder hypervisors have been upgraded to RHEL8.5 and the latest
advanced virt stack. Builders have been upgraded/reimaged to Fedora 35
and the latest packages.
On armv7 builders: As you all know due to
https://bugzilla.redhat.com/show_bug.cgi?id=1920183
( Overeager OOM kills on 5.10 kernels on 32bit arm with lpae )
we had been running an old kernel on them, but after some testing in
staging it seemed that the upcoming 5.16 kernel worked pretty well.
So, All of them are running that now. There have been some OOM kills
already, I'm playing around with options on them to try and get that
number to 0. Hopefully they will be ok for the mass rebuild.
On s390x builders: We got some more resources, so the kvm builders now
have more memory and cpus. I've asked for some more disk space and once
we have that I plan to spread those resources out to have 2x as many
builders (ie, now: 4 cpus, 20gb mem x 10, after: 2 cpus, 10gb mem x 20)
I don't know if this will be done in time for the mass rebuild, but
hopefully so.
On ppc64le: We have some more power9 hardware waiting to be put in
service, so we should be adding some builders here, and/or spreading out
resources.
Thanks for everyone's patience with builds that have been taking a while
or restarting. Do continue to report them and we will do the best we can
to fix things.
kevin
Planned Outage - Datanommer Migration - 2022-01-17 11:00 UTC
There will be an outage starting at 2022-01-17 11:00 UTC,
which will last approximately 2 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2022-01-17 11:00 UTC'
Reason for outage:
We are making some improvements to the performance of the datanommer
database including adding the timescaledb plugin, a migration to a new
database was required as this involved some breaking changes, the migration
has already taken place but the required apps will now be required to point
to the new database
Affected Services:
datanommer/datagrepper and any service which interacts with those
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/10476
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
Mark
This is your reminder that Tuesday 18 January is the deadline for
submitting F36 Self-Contained Change proposals. Note that this
deadline is for putting the proposals into the ChangeReadyForWrangler
category, not for approval or implementation of the proposal.
Since I have your attention, here are a few upcoming dates from the schedule[1]
* 2022-01-18 — Self-Contained Change proposal deadline, mass rebuild begins
* 2022-02-08 — Change completion (testable) deadline, F36 branches from Rawhide
* 2022-02-22 — Change complete (100% complete) deadline, Beta freeze begins
[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
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
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-shap…</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
Hello packagers,
I intent to rebuild the following packages with libffi 3.4 in Rawhide side tag
f36-build-side-49314 today.
The previous version remains available as libffi13.1, so failures to build will
not result in uninstallable packages.
You can inspect some known failures:
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/cjs/https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/gjs/
both "killed by signal 11 SIGSEGV"
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/hadol…
Not all RPM dependencies satisfied
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/jffi/
make: *** No rule to make target '-L/usr/lib64/../lib64', needed by
'/builddir/build/BUILD/jffi-jffi-1.3.4/build/jni/jffi/Array.o'. Stop.
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/ruby/
Segmentation fault
FAIL 1/1489 tests failed
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/thund…
collect2: error: ld returned 1 exit status
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/xs/
Run-time dependency ffi found: NO (tried pkgconfig and cmake)
TIP: If your package is present in c9s, consider looking how it was fixed there.
The rest of the packages I'll rebuild (passed on x86_64 in copr):
Agda
alex
bench
brainfuck
bustle
cab
cabal-install
cabal-rpm
cpphs
darcs
dfuzzer
dhall
dhall-json
dl-fedora
ecl
fbrnch
firefox
gambas3
gforth
ghc
ghc-aeson-pretty
ghc-cabal-helper
ghc-clientsession
ghc-criterion
ghc-DAV
ghc-doctest
ghc-hakyll
ghc-HaXml
ghc-hgettext
ghc-highlighting-kate
ghc-hjsmin
ghc-hspec-discover
ghc-cheapskate
ghcid
ghc-libffi
ghc-pretty-show
ghc-servant-server
ghc-vty
ghc-wai-app-static
ghc-wai-websockets
ghc8.10
ghc9.0
ghc9.2
git-annex
gitit
git-repair
glib2
gnustep-base
gobject-introspection
gtk2hs-buildtools
guile
guile22
guile30
happy
haskell-platform
hedgewars
hledger
hledger-ui
hledger-web
hlint
hscolour
idris
jna
libomp
librep
llvm
llvm10
llvm11
llvm12
llvm7.0
llvm9.0
lsfrom
lua-lgi
micropython
moarvm
ocaml-ctypes
ormolu
pagure-cli
pandoc
patat
perl-FFI-Platypus
perl-Glib-Object-Introspection
php
pkgtreediff
pygobject2
pygobject3
pypy
pypy3.7
pypy3.8
python-cffi
python2.7
python3.10
python3.11
python3.6
python3.7
python3.8
python3.9
p11-kit
racket
rhbzquery
rpmbuild-order
rubygem-ffi
seamonkey
shake
ShellCheck
squeak-vm
tart
unlambda
wayland
xmobar
xmonad
yosys
As always, please don't rebuild the package in regular rawhide until the side
tag is merged.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok