F21 System Wide Change: Modular Kernel Packaging for Cloud
by Jaroslav Reznik
= Proposed System Wide Change: Modular Kernel Packaging for Cloud =
https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud
Change owner(s): Cloud SIG / Sandro Mathys <red(a)fedoraproject.org>, Kernel
Team / Josh Boyer <jwboyer(a)fedoraproject.org>
Kernel modules that are not necessary in virtualized environments become
optionally (un)installable.
== Detailed Description ==
Space is precious in the cloud, therefore the Cloud SIG tries to keep the
images' footprint as small as reasonably possible. Therefore, we'd like to
split the kernel into two (plus one meta) packages. One package would contain
the core modules, i.e. a minimum(-ish) set of drivers to only just be able to
run in virtualized environments. And another package for the rest. The
'kernel' package would then become a meta package that installs both (-core
and -drivers).
== Scope ==
Normal installations will continue installing the kernel (meta-)package and
users should not notice any difference. Same goes for updating from earlier
Fedora releases. But where desired, it should become possible to install only
a reasonably minimal subset of kernel modules. Both kernel and kernel-core
will Provide "kernel", therefore the "install instead of update" magic of
yum/dnf will work as expected even if only kernel-core is installed.
* Proposal owners: The kernel package needs to be changed to produce a meta-
(kernel) and two new packages (-core and -drivers) packages additionally to
those already built out of the SRPM. Aside from the obvious changes to the
package spec file, that includes evaluating what modules need to go into which
package and making sure updating from pre-split kernel packages works as
expected. Most of this work has already been done but still requires some fine-
tuning: [1]
* Other developers: Anaconda must allow to install kernel-core instead of
kernel, when using a kickstart file. (To gain full benefits of this change, but
the change itself can be implemented without). Work has been done but is not
well tested yet: [2]
* Release engineering: No changes necessary.
* Policies and guidelines: No changes necessary.
[1] http://copr-fe.cloud.fedoraproject.org/coprs/jwboyer/kernel-core/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1074522
10 years, 1 month
F21 System Wide Change: Ruby on Rails 4.1
by Jaroslav Reznik
= Proposed System Wide Change: Ruby on Rails 4.1 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.1
Change owner(s): Vít Ondruch <vondruch(a)redhat.com>, Josef Stříbný
<jstribny(a)redhat.com>, ruby-sig(a)lists.fedoraproject.org
Ruby on Rails 4.1 is the latest version of well know web framework written in
Ruby.
== 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 4.0 in
Fedora 20 to 4.1 (latest version) in Fedora 21. This will ensure that all the
Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on
Rails.
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update
For the list of packages that need to be created/updated, see the Change Page.
* Other developers: Update Rails dependent packages to be working with Ruby on
Rails 4.1
* Release engineering: Not needed.
* Policies and guidelines: Not needed
10 years, 1 month
F21 Self Contained Change: Security Policy In The Installer
by Jaroslav Reznik
= Proposed Self Contained Change: Security Policy In The Installer =
https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
Change owner(s): Vratislav Podzimek <vpodzime(a)redhat.com>
There are many known tips and tricks how to make a system more secure, often
depending on the use case for the system. With the OSCAP Anaconda Addon [1]
and the SCAP Security Guide [2] projects, we may allow users choosing a
security policy for their newly installed system.
== Detailed Description ==
The OSCAP Anaconda Addon is a project implementing an Anaconda installer addon
integrating the installer with the OpenSCAP toolkit to provide nice UX when it
comes to security policy application. Its kickstart and GUI support allows
users choosing a security policy for the newly installed system in an easy and
nicely scaling way. The SCAP Security Guide project on the other hand focuses
on development of so-called SCAP content for Fedora, RHEL and other projects.
A SCAP content is a set of XML files defining rules that should be followed by
the system together with checks and fixes used to check and fix system's state.
It also defines profiles selecting some of the rules (or groups of rules)
targetting various use cases.
== Scope ==
We are basically all set. Both OSCAP Anaconda Addon (OAA) and SCAP Security
Guide (SSG) are packages that can be installed by lorax to the installation
compose (distributed images). The addon is then detected and loaded by the
installer and the SCAP content provided by the SSG is automatically detected
and loaded by the addon.
Of course a lot of future development is expected in both of the projects to
provide additional features, but even the current state provides nice features
and good UX.
* Proposal owners: Bug fixing of both the OAA and SSG is expected to be
required, but there are no known major bugs. Further development especially on
the SSG side may be requried to provide more security policies for various
products/spins/use cases.
* Release engineering: Few simple changes in the lorax templates will be
needed to make the OAA and SSG included in the installer images. Patches are
already available and will be submitted to the lorax maintainer (Brian Lane)
who has agreed to review and help with them.
[1] https://fedorahosted.org/oscap-anaconda-addon/
[2] https://fedorahosted.org/scap-security-guide/
10 years, 1 month
F21 Self Contained Change: CUPS Journal Logging
by Jaroslav Reznik
= Proposed Self Contained Change: CUPS Journal Logging =
https://fedoraproject.org/wiki/Changes/CupsJournalLogging
Change owner(s): Tim Waugh <twaugh(a)redhat.com>
By default, CUPS will send log output to the system journal rather than
/var/log/cups/error_log.
== Detailed Description ==
CUPS has traditionally sent log output to the /var/log/cups/error_log file. In
Fedora 20, CUPS was enhanced to be able to send log output to the system
journal, including useful information such as the corresponding job ID. I've
written more about this [1] elsewhere.
== Scope ==
The work involved is a simple one-line change in /etc/cups/cups-files.conf to
change the ErrorLog line to read "ErrorLog journal", and potentially a note in
/var/log/cups/error_log (in log format) describing a journalctl command to
retrieve the CUPS logs.
Proposal owners: The change noted above is all that is required.
[1] http://cyberelk.net/tim/2013/10/25/cups-adding-support-for-system-journal/
10 years, 1 month
F21 System Wide Change: Xorg without root rights
by Jaroslav Reznik
= Proposed System Wide Change: Xorg without root rights =
https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
Change owner(s): Hans de Goede, graphics team <hdegoede(a)redhat.com>
The Xorg xserver is a large piece of software which currently runs as root,
making it a potential vector for attacks against the system. With recent
changes made to systemd-logind it is possible for the xserver to let systemd-
logind do device management for it, at which point the xserver will no longer
need root rights. Initially this will likely be implemented as the xserver
dropping root rights early on.
== Detailed description ==
Currently work is in progress upstream to add systemd-logind integration to
the xserver, this is expected to land for 1.16, which is expected to be the
xserver with which Fedora 21 will ship. In order for the xserver to be able to
run as a systemd-logind session controller it will need to be started inside a
(pam) user-session, this will require changes to apps starting the xserver,
specifically to display-managers such as gdm.
== Scope ==
In order for the xserver to be able to run as a systemd-logind session
controller it will need to be started inside a (pam) user-session, this will
require changes to apps starting the xserver, specifically to display-managers
such as gdm. This is already being coordinated with gdm and other display-
managers. For Fedora 21 there likely will be a fallback mode where the xserver
will do the device-management itself when not started from a display-manager
which starts it inside a user-session.
Proposal owners: Make the xserver run properly as non-root, or drop root
rights early on
Other developers: Display manager developers may need to make changes to how
the xserver is started, so that it always is started inside a user session.
Note this change is also necessary for display managers which want to support
wayland, as wayland must always be started like this.
Release engineering: N/A
Policies and guidelines: N/A
See Dependencies section [1] for more details regarding cooperation with DM
maintainers.
[1] https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights#Dependencies
10 years, 1 month
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
We've been very bad at announcing changes to the Packaging Guidelines.
So very bad. Bear with us as we announce all the changes we should have
been announcing in the past, but failed to do. Again, so bad.
---
The Mersenne Twister implementation (mt19937ar) has been granted a
general bundling exception.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
After an unintentional delay, the Haskell Guideline revision approved
four months ago has been officially written into the Guidelines. A
profound apology to everyone who wanted to point people at the new
guidelines and couldn't find them in the meantime. The updated
guidelines can be read here:
https://fedoraproject.org/wiki/Packaging:Haskell
---
The Naming Guidelines for python modules has been updated to remove the
exception for packages which have a "py" prefix in the upstream name.
This change comes at a time when python2 and python3 modules are
commonly built from the same package and all python3 modules are
required to have a "python3" in their name. This change makes it easier
for users to identify that the python3-foo module is part of the
python-foo package for filing bugs and searching for the python3 version
of a package they use in python2.
Note that packages that are already in Fedora with names allowed under
the old guidelines are considered grandfathered. Renaming makes sense
but the FPC is not requiring that they do. This is up to the individual
package maintainers (or FESCo should someone ask them for permission to
do a mass package rename).
---
The syntax in the guidelines for Source macro naming of github generated
tarballs has been changed from
"%{name}-%{version}-%{shortcommit}.tar.gz" to
"$PROJECT-%{commit}.tar.gz", because that is the default naming from github.
https://fedoraproject.org/wiki/Packaging:SourceURL#Github
---
An exception has been granted for sigrok-firmware-fx2lafw to bundle fx2lib.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A line has been added to the arch specific Octave template to exclude
.oct files from provides. (This will no longer be necessary when Fedora
19 is EOL.)
https://fedoraproject.org/wiki/Packaging:Octave#Arch_specific_Octave_spec...
---
A bundling exception for JAXP and JAX-WS in openJDK has been granted.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gr...
---
A new section was added to the guidelines covering build time network
access:
Packages in the Fedora buildsystem are built in a mock chroot with no
access to the internet. Packages must not depend or or use any network
resources that they don't themselves create (ie, for tests). In no cases
should source code be downloaded from any external sources, only from
the lookaside cache and/or the Fedora git repository.
https://fedoraproject.org/wiki/Packaging:Guidelines#Build_time_network_ac...
---
Additional wording was added to the procedures for dealing with bundled
library handling.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#When_a_Bund...
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions
---
Added a guideline: "Packages MUST NOT have SourceN or PatchN tags which
are conditionalized on architecture." This makes sure an srpm has all of
the files needed to rebuild itself. Note that this change *is not*
intended to prevent packages from conditionally applying patches or
sources during the build. That remains a valid practice.
---
The trigger scripts that saved information about sysv runlevels when
converting to systemd have been dropped on the basis that everything of
importance has been converted and the system for saving that information
was always kludgy and complex. Packages that are converting now should
not include them. Lennart will submit a Changes Proposal to coordinate
updating packages that presently have these trigger scripts in order to
remove the actual systemd-sysv package.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Packages_migra...
---
The Node.JS guidelines have been changed in the following ways:
* The %nodejs_fixdep section included in the original version of the
draft has been readded.
* The RPM magic was recently split into it's own "nodejs-packaging"
SRPM, similar to Java. Accordingly, packages can now require
"nodejs-packaging" instead of "nodejs-devel" to reduce the number of
deps dragged in at build-time.
* The necessary ExclusiveArch? line needed for Node.js packages is now
documented, including the %{nodejs_arches} macro recently added to
redhat-rpm-config for this purpose.
* A strategy for handling multiple/compatibility versions of packages
that is transparent to dependent packagers has been implemented.
* The %{nodejs_default_filter} default automatic virtual provides
filtering macro (similar to Perl's) is now documented.
* A --check argument was added to %nodejs_symlink_deps simplify running
test suites in specs.
* A brief mention that additional virtual provides are added for native
modules to track ABI compatibility was added.
* Some minor edits were made to the installing native modules section to
reflect reality; my initial draft contained errors.
* A brief note about an additional macro required to enable dependency
generation on EPEL was added.
https://fedoraproject.org/wiki/Packaging:Node.js
---
The prohibition against packages installing files into /bin, /sbin,
/lib, and /lib4 has been removed and a section explaining how Fedora's
UsrMove? feature interacts with the rpm %files section has been added.
Packagers who maintain software that installs into /bin, /sbin, /lib,
and /lib64 historically or in upstream are encouraged to read that
section to understand what's best for their package:
https://fedoraproject.org/wiki/Packaging:Guidelines#Effect_of_the_UsrMove...
---
The Conflicts guidelines have been clarified to state that the goal is
for users to be able to install the latest packages from Fedora's repos
regardless of what other Fedora packages are installed.
https://fedoraproject.org/wiki/Packaging:Conflicts
---
Added an additional allowed use of Conflicts to the packaging guidelines
on Conflicts. This usage is for a package which is split into multiple
packages with files that may conflict with files in the older version of
the base package. See the Conflicts Guidelines if you think you may be
able to make use of this:
https://fedoraproject.org/wiki/Packaging:Conflicts#Splitting_Packages
---
Due to changes in which packages are in the minimal set pulled into the
buildsystem, BuildRequires?: systemd has become necessary for packages
which install systemd unit files. The Guidelines have been updated to
show this:
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scrip...
---
Fedora packages which use pkg-config to build against a library (e.g.
'foo') on which they depend, '''SHOULD''' express their build dependency
correctly as <pkgconfig(foo). For more information, see
https://fedoraproject.org/wiki/Packaging:PkgConfigBuildRequires
---
Guidelines for shared web assets including browser-side javascript have
been added. These finally add rules for unbundling javascript libraries
from web applications as well as shared css libraries, icons, and other
files. Two related areas were clarified as part of this: pre-compiled
shockwave flash files count as pre-compiled binaries and are not allowed
(compile flash resources from source with an open source flash toolchain
or patch them out of the package). Font files need to have proper
licensing informaiton in their metadata. The following pages contain the
updated guidelines:
* https://fedoraproject.org/wiki/Packaging:Web_Assets
* https://fedoraproject.org/wiki/Packaging:JavaScript
*
https://fedoraproject.org/wiki/Packaging:FontsPolicy#Licensing_Informatio...
---
The naming guidelines have been changed to emphasize that package names
should generally use lowercase and turn underscores into dashes unless
there's a compelling reason to follow a different upstream convention.
---
The FPC changed its recommendation on dealing with library conflicts.
The new recommendation makes clear that using a subdirectory is useful
in very few cases, makes use of environment-modules instead of an
ld.so.conf.d file to switch between them, and asks that for the cases
where subdirectories don't work maintainers press upstreams hard to
change their library names. If someone would care to submit a draft for
dealing with library conflicts that fall outside of this area FPC would
be happy to look at whether it makes sense to add those instructions.
https://fedoraproject.org/wiki/Packaging:Conflicts#Library_Name_Conflicts
---
The autodep filter guidelines were updated to reflect changes to RPM in
Fedora 20.
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering...
---
A method of handling noarch packages which have dependencies that are
not present on some architectures was made official.
https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_...
These methods are a change from the common practice in, for instance,
node.js packaging. Packagers should think about updating their packages
to the new guidelines as they make other updates.
Please see https://fedorahosted.org/fpc/ticket/355#comment:8 or the
meeting log for that date if you want more information than is in the
Guidelines. The possibility of enhancing rpm or koji to deal with this
in a better manner is being looked into by the packaging-team and
rel-eng. When those features eventually are available to Fedora, we'll
update the Guidelines to take advantage of them.
---
The guidelines for including both sysvinit scripts and systemd unit
files were changed. New packages must not include both even if the
sysvinit scripts are in a separate subpackage. As in many cases of
guideline changes, old packages are grandfathered but packagers are
encouraged to look into dropping the sysvinit subpackages as they update
in rawhide.
https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_ad...
---
A new bundling exception has been made for the java time-api package to
reverse bundle the javax.time api present in openjdk8 for code which
uses prior versions of the jdk.
---
The kernel provides a library for monitoring events which is used by
perf, powertop, rasdaemon and possibly other programs. As the library is
not currently built and installed for general use but the plan is to
enable that in kernel-3.14 a temporary bundling exception has been
granted through Fedora 22.
---
Two changes have been made to the Ada Guidelines:
* instructions on using comfignat to build ada packages has been added
to the Ada Guidelines:
* instructions on how to allow rpaths for testsuites and binaries that
are only used at buildtime. The instructions also include a requirement
to explicitly run %{_rpmconfigdir}/check-rpaths in %check if rpaths are
turned on for the build.
https://fedoraproject.org/wiki/Packaging:Ada
---
As part of the ongoing effort to update the guidelines for an eventual
change from python2 to python3 as the default python we're promoting use
of %{python2}, %{python2_sitelib}, and %{python2_sitearch} instead of
the unversioned %{python}, %{python_sitelib}, and %{python_sitearch}
macros. These macros are not available for EPEL5 and EPEL6. We've
updated the Python Guidelines to mention conditionally defining those
macros for EPEL5 and EPEL6 builds.
---
Changes to python-setuptools in F20 cause easy_install to install egg
files instead of egg directories by default. This sometimes causes
problems for rpms of multi-version python modules as the egg filenames
are the same if the version of the package hasn't been increased and rpm
is unable to replace the directory with a file. To fix this, the
https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions
guideline has been updated to pass the "-Z" switch to easy_install which
restores the former behaviour of installing eggs as a directory.
If you package a backwards or forwards compat python module that makes
use of the Multiple_Versions guideline (or easy_install in some other
way), please update your spec file to include the -Z switch.
---
The java guidelines have seen a large update that simplifies the
language and removes instructions for EOL-Fedora releases. One
particularly important change is the addition of the java-headless
virtual dependency. Please see the Java Guidelines for complete
information:
https://fedoraproject.org/wiki/Packaging:Java
---
New guidelines have been added that address modifying the /etc/shells
file when a package adds a new login shell:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Shells
---
Packaging Guidelines for building modules and themes for Drupal7 have
been approved: https://fedoraproject.org/wiki/Packaging:Drupal7
---
The Guidelines contained a section stating not to use
"Requires(post,pre):" type syntax due to rpm bugs. Since those bugs only
apply to the rpm shipped in RHEL5, the prohibition has been removed from
the guidelines.
---
These guideline changes were approved by the Fedora Packaging
Committee (FPC).
Many thanks to the uncountable number of people in the Fedora community
for raising and resolving these issues, and all of the members of the
FPC, for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
10 years, 1 month
F21 System Wide Change: u-boot syslinux by default
by Jaroslav Reznik
= Proposed System Wide Change: u-boot syslinux by default =
https://fedoraproject.org/wiki/Changes/u-boot_syslinux
Change owner(s): Dennis Gilmore <dennis(a)ausil.us>
Add syslinux support to u-boot enabling both pxelinux and extlinux support.
simplifying booting arm machines, making anaconda installs easy and overall
providing for a better user experience. Default u-boot to using syslinux config
files for booting. pxelinux for network and extlinux for local booting.
== Detailed description ==
u-boot has support for booting using syslinux style configuration files, this
change is to default to using it on all supported systems.
=== Benefit to Fedora ===
This takes away the complexity of booting arm systems. There is no need to
know addresses or to wrap images with mkimage. Users will get a menu that
allows them to choose which kernel to boot. making things like a boot.img will
be possible. Initiating installs via anaconda will also be much more simple
and straight forward.
== Scope ==
* Proposal owners: default u-boot to loading extlinux.conf files. anaconda to
write a devicetreedir line in extlinux.conf on arm systems. appliance-creator
to write out a devicetreedir in extlinux.conf on arm systems
* Other developers: grubby to update extlinux.conf appropriately.
* Release engineering: None
* Policies and guidelines: None
10 years, 1 month
F21 System Wide Change: jQuery
by Jaroslav Reznik
= Proposed System Wide Change: jQuery =
https://fedoraproject.org/wiki/Changes/jQuery
Change owner(s): T.C. Hollingsworth <tchollingsworth(a)gmail.com>
jQuery is a fast, small, and feature-rich JavaScript library. It makes things
like HTML document traversal and manipulation, event handling, animation, and
Ajax much simpler with an easy-to-use API that works across a multitude of
browsers. With a combination of versatility and extensibility, jQuery has
changed the way that millions of people write JavaScript.
Traditionally, a copy of jQuery has been included with every web application
that requires it. This change will migrate many of those applications to a
shared system copy of jQuery. Both the 1.x branch of jQuery that supports
Internet Explorer 6 and the 2.x branch of jQuery that only works with modern
web browsers will be provided.
== Detailed description ==
Traditionally, a copy of jQuery has been included with every web application
that requires it. This change will migrate many of those applications to a
shared system copy of jQuery.
The following packages will be provided:
* js-jquery - The latest version of the jQuery 2.x branch, suitable for web
applications that are only compatible with modern web browsers that fully
support modern web standards.
* js-jquery1 - The latest version of the jQuery 1.x branch, suitable for web
applications that endeavor to be compatible with older web browsers such as
Internet Explorer 6.
* js-jquery-migrate - The jQuery migrate plugin, which is a compatibility shim
that enables web applications that depend on older versions of jQuery to work
with the latest version, so that they can be ported away from old, unsupported
jQuery versions that may potentially have security issues.
== Scope ==
Proposal owners:
=== New Packages ===
In addition to the new packages described above, several support packages must
be introduced to enable proper building and minification of jQuery packages in
Fedora. For more information, see the dependencies section.
Other developers:
=== Migrating Web Applications ===
Web applications that depend on modern versions of jQuery will simply be
ported to use the systemwide version instead,
Web applications that use older versions of jQuery (> 1.6.4 but <1.9) will be
ported to use jquery-migrate and the systemwide version of jQuery. Packagers
will be encouraged to work with upstream to migrate to the latest version of
jQuery without jquery-migrate, since using this plugin re-enables misfeatures
rightly removed from jQuery core that are XSS holes waiting to happen.
Maintainers of web applications that use extremely old versions of jQuery (<
1.6.4) will be strongly encouraged to work with upstream to migrate to the
latest versions of jQuery and update their packages. However, current Fedora
policy regarding bundled libraries permits these packages to be grandfathered
in, so I am unable to force any action here.
Preliminary repoqueries have been performed to identify potentially affected
packages, see the dependencies section for more details.
=== Migrating documentation frameworks ===
Certain documentation frameworks, such as python-sphinx, ship copies of jQuery
as well. These frameworks will be modified to use a symlink or other means so
that they too can use the new systemwide versions.
Policies and guidelines: None other than those needed for JavaScript packaging
in general.
Release Engineering: No special attention required.
10 years, 1 month
ANN Retiring pdftk for F20+
by Jochen Schmitt
Hello,
I have reitiered pdftk for F-20 and rawhide.
The rationals for this steps are:
1.) pdftk is a C++ programm which calls methods of a Java library called
iText. To do this, gcj with CNI support is required. The support of this
technology is discontinued in Fedora Linux. Therefore you can't make
any successfuls builds for pdftk on Fedora Linux anymore.
2.) pdftk2 may dempends of iText5 or later which is not provides on Fedora
during licensing issues.
Best Regards:
Jochen Schmitt
10 years, 1 month