F22 System Wide Change: Harden all packages with position-independent code
by Jaroslav Reznik
= Proposed System Wide Change: Harden all packages with position-independent
code =
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-...
Change owner(s): Till Maas <opensource(a)till.name>, Moez Roy
<moez.roy(a)gmail.com>
Harden all packages with position-independent code to limit the damage from
certain security vulnerabilities.
== Detailed Description ==
Currently, the Packaging Guidelines allow maintainers to decide whether their
packages use position-independent code (PIC). There are rules that say that a
lot of packages should use PIC, but in reality a lot of packages do not use
PIC even if they must. Also since a lot of packages if not all potentially
process untrusted input, it makes sense for these packages to use PIC to
enhance the security of Fedora. Therefore I propose to build all packages with
PIC by changing RPM to use the appropriate flags by default.
References:
* https://fedorahosted.org/rel-eng/ticket/6049
* There should be several mails about this on the devel list
== Scope ==
* Proposal owners:
Help writing the new packaging guidelines.
* Other developers:
Change the rpm macros to build packages by default with PIC/PIE flags (i.e. set
_hardened_package to 1 by default).
* Release engineering:
Do a mass rebuild for all arch packages
* Policies and guidelines:
Adjust the Packaging Guidelines to allow non-PIC packages only if the package
is not working otherwise and require a tracker bug similar to packages not
working on certain archs. Update the Guidelines to reflect the new defaults.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
IntelliJ
by Greg Hellings
I'm curious about the possibility of bringing IntelliJ/IDEA back into
Fedora. It was there previously, then was taken out sometime around
Fedora 15 or thereabouts. Back then the app was at version 9, it's
currently landed at version 14. With the announcement of Gradle making
an improved landing in Fedora 22, it might be possible to bring back
in. I was curious if anyone had a particular feeling strongly one way
or another, or if there were solid reasons not to resurrect it.
It looks like it was a behemoth to maintain, so I don't know how
deeply I want to dive into it (the build involved a large number of
bundled jars) at this time. I just wanted to put out feelers regarding
it.
--Greg
9 years, 3 months
Re: F22 System Wide Change: Login Screen Over Wayland
by Ian Pilcher
How does this affect users of other display managers (or does it)?
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================
9 years, 3 months
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
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
Boost 1.57.0
by Petr Machata
Your favorite time of the year, and mine as well, is here!
The plan is to do the rebase next week, maybe on the weekend already.
As usual, I'll request a side tag, build boost, and then work through
the dependent packages. I'll wrap the work on Thursday at the latest
regardless on what state it is in (hopefully most will have been done
by then), as I'll be traveling to FOSDEM on Friday.
If you want to take a fresh-from-the-oven candidate package for a spin,
help yourselves:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8677132
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2852665
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1706650
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2283587
I just noticed there are no MPICH packages, because I had MPICH support
turned off locally. I'm spinning a new batch, but if you happen not to
care about MPICH, the above should be just fine.
The sources are here:
https://github.com/pmachata/F22Boost158
I'll squash merge to Fedora just before I build the final package.
Thanks,
Petr
9 years, 3 months
F22 System Wide Change: Plasma 5
by Jaroslav Reznik
= Proposed System Wide Change: Plasma 5 =
https://fedoraproject.org/wiki/Changes/Plasma_5
Change owner(s): KDE SIG & Daniel Vrátil <dvratil(a)redhat.com>, Lukáš Tinkl
<ltinkl(a)redhat.com>, Jan Grulich <jgrulich(a)redhat.com>, Rex Dieter
<rdieter(a)fedoraproject.org>, Than Ngo <than(a)redhat.com>, Kevin Kofler
<kevin(a)tigcc.ticalc.org>
Plasma 5 is successor to KDE Plasma 4 created by the KDE Community. It is
based on Qt 5 and KDE Frameworks 5 and brings many changes and improvements
over previous versions, including new look & feel as well as important changes
under the hood.
== Detailed Description ==
Plasma 5 is a new major version of KDE's workspaces. It has a new theme called
Breeze, which has cleaner visuals and better readability, improves certain
work-flows and provides overall more consistent and polished interface.
Changes under the hood include switch to Qt 5 and KDE Frameworks 5 and
migration to fully hardware-accelerated graphics stack based on OpenGL(ES).
Note that Plasma 5 only includes the actual shell, decorations, icons and a
few applications coupled with workspace (e.g. KWin, System Settings,
KSysGuard). It does not include "regular" applications like Dolphin, Okular,
Konqueror, etc. which are part of KDE Applications product and released
independently of Plasma 5.
Plasma 5 gets a new feature release every three months, and each feature
release has monthly bugfix releases. Plasma 5.2 is scheduled to be released on
January 27. KDE SIG intends to ship Plasma 5.2.2 or Plasma 5.3, depending on
the final schedules.
== Scope ==
* Proposal owners:
** Submit, review and import new packages for Plasma 5 to rawhide/F22
** Modify existing KDE 4 packages to ensure smooth upgrade path to Plasma 5
** Retire KDE 4 packages not compatible with Plasma 5, or available in Plasma
5 under different names/components
* Other developers:
Optionally, maintainers of 3rd party KDE Workspace 4 packages such as Plasma
applets or KCMs may want to consult upstream regarding Qt 5/Frameworks
versions of their packages, and eventually update them to Frameworks version,
so that they are available in Plasma 5.
* Release engineering:
No, this change requires no coordination with rel-eng.
* Policies and guidelines:
No, this change requires no update to packaging guidelines or policies.
== Contingency Plan ==
* Contingency mechanism: Rolling back to KDE 4 and shipping KDE Workspace
4.11.X. As rawhide would already have packages with version 5.x.y, we would
have to increase the epoch number of all affected KDE 4 packages, and making
them Obsolete their Plasma 5 equivalents (since some Plasma 5 packages have
been renamed or split from larger KDE 4 packages)
* Contingency deadline: Before F22 beta freeze
* Blocks release? No
* Blocks product? No
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
[Test-Announce] Urgent F21 testing request: libhif and PackageKit
by Adam Williamson
Hi, folks!
We recently found out that there were some significant problems with
PackageKit and things that use it (GNOME Software, Apper, gnome-
packagekit...) in Fedora 21, since the release of libhif-0.1.7 as an
update shortly after F21 came out. The initial bug people noticed was
offline updates failing to work, but in subsequent testing we found
that regular package install and remove operations could cause crashes
in PackageKit-based apps and it was possible for the PackageKit
database to be corrupted.
It would be great if folks could, as a matter of urgency, test this
update:
https://admin.fedoraproject.org/updates/PackageKit-1.0.4-1.fc21,libhif-
0.1.8-1.fc21
Please install the updated packages, reboot (or at least restart the
packagekit service), run 'pkcon repair' as root, reboot again, and
then test regular use of GNOME Software and pkcon as much as possible -
try installing and removing packages, running offline updates, and so
on. If your package set is up to date you can try downgrading a
package in order to test offline updates - try 'yum downgrade
devassistant', for instance, if you have it installed, then check for
updates in GNOME Software.
As the bugs were pretty serious we'd like to release the fix as soon
as possible, but at the same time we want to make sure we tested it
thoroughly.
Thanks folks! And thanks a lot to Richard Hughes for working to fix
this quickly, and Kamil for doing a lot of testing on it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
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.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months
Agenda for Env-and-Stacks WG meeting (2015-01-14)
by Honza Horak
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
= Topics =
* Fedora Rings
* revisit the plan around rings
* interpret rings with users' use cases and requirements
* sync on where SCLs, copr, languages repositories etc. fit into
rings ideas
* Chairman for next meeting
* Open Floor
9 years, 3 months
F22 Self Contained Change: Minglish - New input method for Marathi Language
by Jaroslav Reznik
= Proposed Self Contained Change: Minglish - New input method for Marathi
Language =
https://fedoraproject.org/wiki/Changes/minglish
Change owner(s): anish <apatil(a)redhat.com>
New input method for Marathi language users.
== Detailed Description ==
Minglish input method is to type Marathi using Latin alpha-bates.However there
are existing mim layouts are available though each layout has few problems.
e.g to type word "anish" in Marathi using phonetic input method one has to
type sequence as "FniS" while with itrans input method one has to type
"anisha". In given example user often expects "अनिश" to be appear with
keystrokes "anish". In India, people who have familiar with English language
tend to type Marathi letters upon English letter pronunciation, that is why we
have new term http://en.wikipedia.org/wiki/Hinglish.
== Scope ==
* Proposal owner: Initial plan is to send this patch to upstream and otherwise
patch it into Fedora
* 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)
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 3 months