F22 System Wide Change: Login Screen Over Wayland
by Jaroslav Reznik
= Proposed System Wide Change: Login Screen Over Wayland =
https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland
Change owner(s): Ray Strode <rstrode(a)redhat.com>
Change the Login screen that GDM uses to run on Wayland instead of X.
== Detailed Description ==
At the moment, a user can choose to log in to a Wayland session from the login
screen, but the login screen itself always runs on top of X. The point of this
change is to change that, and make the login screen always run on a Wayland
session.
== Scope ==
* Proposal owners: The main things that need be accomplished are:
** Change GDM to not start an X server at startup, instead run the login
screen in Wayland mode
** Change X based user sessions to run on their own VT, since they can no
longer piggyback off the login screen VT
** Come up with some answer for proprietary Nvidia driver users, since that
stack doesn't yet support Wayland. One idea is to force the login session to
use software-based mesa if the proprietary Nvidia driver is detected.
* Other developers: We may need to get the mesa maintainer involved as part of
a proprietary Nvidia driver handling, but also might not need to pending
investigation.
* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines
== Contingency Plan ==
* Contingency mechanism: Revert to existing mechanism of login screen on Xorg
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
9 years, 3 months
F22 Self Contained Change: Gradle 2.x
by Jaroslav Reznik
= Proposed Self Contained Change: Gradle 2.x =
https://fedoraproject.org/wiki/Changes/Gradle
Change owner(s): Mikolaj Izdebski <mizdebsk(a)redhat.com>
This change aims at making latest version of Gradle available in Fedora and
making it possible to easily build Fedora packages using Gradle.
== Detailed Description ==
Gradle [1] is a popular Java build automation tool, which can automate
building, testing, publishing, deployment and more of software packages or
other types of projects such as generated static websites, generated
documentation or indeed anything else.
This change brings latest upstream version of Gradle to Fedora, which enables
Fedora users to use Gradle to work with software projects.
This change also implements integration with software used for Java packaging
in Fedora (XMvn and Javapackages), which makes it possible to use standard
Fedora pagkaging techniques to build RPM packages with Gradle with all
features, such as automatic artifact installation or auto-requires/provides.
== Scope ==
* Proposal owners:
** Package latest Gradle 2.x
** Implement local Gradle resolver so that RPM packages can be built with
Gradle
** Update Java Packaging HOWTO to include information about Gradle packaging
* Other developers:
** Maintainers of packages not built with Gradle and which upstreams are using
Gradle as build system can optionally update their packages to be built with
Gradle, but that's not absolutely required as existing ways of building Java
packages will continue to work.
* Release engineering: N/A
* Policies and guidelines: N/A
[1] http://gradle.org/
9 years, 3 months
F22 System Wide Change: Glibc Unicode 7.0
by Jaroslav Reznik
= Proposed System Wide Change: Glibc Unicode 7.0 =
https://fedoraproject.org/wiki/Changes/Glibc_Unicode_7
Change owner(s): Mike Fabian <mfabian At redhat DOT com>, Pravin Satpute
<pravins At fedoraproject DOT org>, Siddhesh Poyarekar<spoyarek AT redhat DOT
com>
We are updating Glibc Unicode data from Unicode 5.1 to Unicode 7.0 version. It
took long time since there was not much documentation on how to update Unicode
data and also there was chance of loosing backward compatibility. Most of the
issues are resolved now and patches are ready for inclusion. This update adds
around 8000 number of character support in Glibc and also correcting the
Unicode data of many characters as per latest Unicode standard.
== Detailed Description ==
In this update we are planning to update Glibc's the Unicode locale data -
character map and LC_CTYPE information to Unicode 7.0 version. This data is
used almost in all locales and going to affect all applications using these
locales. It is system wide change since it impacting glibc and application
dependent on it. Glibc provides two files for Unicode data, UTF-8 and i18n.
UTF-8 file provides information about CHARMAP and WIDTH for Unicode characters.
i18n file provides CTYPE (uppercase, lowercase, punct etc.) information for all
Unicode characters. It has been long time this is not updated due to
incomplete documentation and also possible chances of loosing backward
compatibility. Work has been started on this 5-6 months back and now most of
the issues are resolved.
Respective bugs in upstream for more information.
* Update locale data to Unicode 7.0.0 [1]
* Update UTF-8 charmap and width to Unicode 7.0.0 [2]
Github repo for scripts. [3]
== Scope ==
* Proposal owners:
1. Writing scripts for generating UTF-8 and i18n files from Unicode character
database.
2. Preparing patch for UTF-8 and i18n files.
3. Preparing backward compatibility report.
4. Applying patches to Fedora.
5. Testing whether does it breaks anything around.
* Other developers: This change impacting glibc and all applications that
using locales. Other Developers do not need to do any changes from there end
but they need to watch how there application behave with improved localedata.
We need proper testing to see it does not break any application.
* Release engineering: No work required from Release engineering.
* Policies and guidelines: No, this change does not required any updates to
Policies or packaging guideline updates.
== Contingency Plan ==
* Contingency mechanism: Will drop patches from Glibc build.
* Contingency deadline: Before F22 Beta release eg. Beta freeze.
* Blocks release? No
* Blocks product? product No
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14094
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17588
[3] https://github.com/pravins/lohit
9 years, 3 months
F22 Self Contained Change: Dnf Langpack Plugin
by Jaroslav Reznik
= Proposed Self Contained Change: Dnf Langpack Plugin =
https://fedoraproject.org/wiki/Changes/DnfLangpacksPlugin
Change owner(s): Parag Nemade <pnemade at fedoraproject dot org>
A dnf plugin that allows langpacks to be installed/removed for the given
languages using its commands.
== Detailed Description ==
This is similar to what we have yum langpacks plugin which is already a
Features/YumLangpackPlugin [1] in Fedora but there is one missing thing that
this plugin currently does not provide automatic installation of langpacks
which is under development [2]. Therefore I am proposing this as basic
langpacks plugin that provides all the required commands for langpacks only.
== Scope ==
* Proposal owners: implement langpacks plugin
* 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)
[1] https://fedoraproject.org/wiki/Features/YumLangpackPlugin
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1114422
9 years, 3 months
F22 System Wide Change: Django 1.8
by Jaroslav Reznik
= Proposed System Wide Change: Django 1.8 =
https://fedoraproject.org/wiki/Changes/Django18
Change owner(s): Matthias Runge <mrunge(a)fedoraproject.org>
Update python-django to version 1.8.
== Detailed Description ==
Update python-django to version 1.8. Fedora 21 contains version 1.6, which
will become deprecated by upstream, once Django-1.8 is out. This is a change,
impacting many of python-django-* packages.
Django upstream is transparent and announces deprecation far in advance.
== Scope ==
* Proposal owners:
** update python-django to version 1.8. To support maintainers of dependent
packages, a copr repo containing latest Django-1.8 is here: [1]
** A build containing latest Django will be pushed to f22 branch late in dev
cycle. If we decide not to push Django-1.8, nothing will be broken.
** Django 1.8 final release is expected around April 1st, 2015: [2]
* Other developers: update dependent packages to work with Django-1.8
* Release engineering: N/A
* Policies and guidelines: N/A
== Contingency Plan ==
* Contingency mechanism: If we can not make it, we'll keep Django-1.7 from
rawhide.
* Contingency deadline: Fedora 22 Beta release.
* Blocks release? No
* Blocks product? doesn't block a product.
[1] https://copr.fedoraproject.org/coprs/mrunge/django-1.8/
[2] https://code.djangoproject.com/wiki/Version1.8Roadmap#schedule
9 years, 3 months
F22 Self Contained Change: Database Server Role
by Jaroslav Reznik
= Proposed Self Contained Change: Database Server Role =
https://fedoraproject.org/wiki/Changes/DatabaseServerRole
Change owner(s): Stephen Gallagher <sgallagh(a)redhat.com>, Kevin Fenzi
<kevin(a)scrye.com> and Truong Anh Tuan <tuanta(a)fedoraproject.org> and Server WG
<server(a)lists.fedoraproject.org>
The Fedora Server Product will provide a standard deployment mechanism for a
Linux Database Server (powered by the postgresql project).
== Detailed Description ==
The Fedora Server Product will be shipped with a role-deployment mechanism.
One such role will be to act as a primary or replica Database Server for the
Linux machines in the network.
This will be implemented by taking advantage of the postgresql project,
packaging it up within the Server Role Framework and enabling it to be
deployed through the mechanisms described in the Framework for Server Role
Deployment Change Proposal.
Note that this role is a secondary target of the Server Working group.
== Scope ==
* Proposal owners:
** Postgresql server and related tools need to be packaged appropriately for
use with the Server Role Infrastructure.
** A D-BUS API plugin needs to be written and tested to support deployment and
monitoring of the Database server.
* Other developers:
** None
* Release engineering:
** Pre-loading roles will need to be a capability of the Anaconda install
system, both in the graphical installer and kickstart
* Policies and guidelines:
** Packaging guidelines for this Change should be inherited from the Framework
for Server Role Deployment Change Proposal.
9 years, 3 months
F22 Self Contained Change: Domain Controller Set Up Through Cockpit
by Jaroslav Reznik
= Proposed Self Contained Change: Domain Controller Set Up Through Cockpit =
https://fedoraproject.org/wiki/Changes/CockpitDomainController
Change owner(s): Stephen Gallagher <sgallagh(a)redhat.com>
With Fedora 21, the rolekit project now provides a public D-BUS interface for
creating a Domain Controller based on the FreeIPA project. This Change will
track adding this capability to the Cockpit management console of Fedora
Server.
== Detailed Description ==
Providing users with a simple graphical user interface to set up a FreeIPA
Domain Controller will provide a fast way to bootstrap an enterprise-grade
Linux environment. Once the Domain Controller is made available, it becomes
easy to manage single-sign-on between systems (and Cockpit instances), control
user authentication and authorization centrally and manage DNS entries (among
other things).
== Scope ==
* Proposal owners: The Cockpit user experience needs to be written and added
to that upstream project. It needs to be connected to the local rolekit
daemon.
* 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)
9 years, 3 months
openSUSE Beer
by Douglas DeMaio
Hi all. openSUSE will have it's conference between May 1-4 in The
Hague, Netherlands. If you want to participate, do some cross
pollinating and hack with us, we would love to have you attend -
http://bit.ly/1yeBGg0 Cya at FOSDEM and come enjoy one of our openSUSE
beers while you're there.
See some of you at SCALE
Cheers
Doug
9 years, 3 months
F22 Self Contained Change: Wine to use mesa Direct3D
by Jaroslav Reznik
= Proposed Self Contained Change: Wine to use mesa Direct3D =
https://fedoraproject.org/wiki/Changes/Wine_to_use_mesa_Direct3D
Change owner(s): Igor Gnatenko <ignatenkobrain(a)fedoraproject.org>
Enhancing mesa and wine with Direct3D9 support will increase performance and
reduce resource usage in applications which using D3D9 framework.
== Detailed Description ==
When playing d3d9 games on Wine, their d3d9 calls are translated to OpenGL.
This is complicated process, because you have to deal with different drivers
having different extensions available, and the fact that opengl and d3d9 don't
map perfectly together. Gallium Nine implements the d3d9 API with Gallium
internal API, which maps better to d3d9 than OpenGL. You remove some layers of
translation in the process which enables better performance. Gallium Nine is
not as mature as Wine OpenGL translation, and it is likely to have more bugs,
but when the games work, you can expect 5-10% improvement for gpu limited
games, or much more (sometimes 100%) for cpu limited games.
what is Gallium: Gallium is an internal graphic driver abstraction of Mesa to
enable support of non-opengl languages more easily (it is used for vdpau and
vaapi on r600/radeonsi for example). It is used by nouveau and r300 up to
radeonsi for AMD. Intel OpenGL support doesn't use gallium, but a gallium
driver named ilo exists, but isn't sponsored by Intel.
In practice, games have also smoother frame rate on Gallium Nine. Gallium Nine
has good DRI_PRIME support, and if you have a system with an iGPU+dGPU, you
can play without issues with the parameters DRI_PRIME=1 thread_submit=true
https://wiki.ixit.cz/d3d9
== Scope ==
* Proposal owners: work on the Mesa Direct3D support
* 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)
== Contingency Plan ==
* Contingency mechanism: Revert and try to do in next release
* Contingency deadline: beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)
9 years, 3 months