devel-announce March 2014

devel-announce@lists.fedoraproject.org

7 participants
34 discussions

F21 System Wide Change: Modular Kernel Packaging for Cloud
by Jaroslav Reznik 18 Mar '14

18 Mar '14

= 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

1 0

F21 System Wide Change: Ruby on Rails 4.1
by Jaroslav Reznik 18 Mar '14

18 Mar '14

= 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

1 0

libvpx 1.3.0 ABI break
by Wim Taymans 13 Mar '14

13 Mar '14

Hi all, libvpx-1.3.0 unexpectedly broke ABI without updating the .so name. See more info here https://bugzilla.redhat.com/show_bug.cgi?id=1068664 I'm rebuilding the gstreamer 0.10 and 1.0 packages now but there are more packages depending on libvpx. Wim

1 0

F21 Self Contained Change: Security Policy In The Installer
by Jaroslav Reznik 13 Mar '14

13 Mar '14

= 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/

1 0

F21 Self Contained Change: CUPS Journal Logging
by Jaroslav Reznik 12 Mar '14

12 Mar '14

= 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/

1 0

F21 System Wide Change: Xorg without root rights
by Jaroslav Reznik 10 Mar '14

10 Mar '14

= 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

1 0

[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway 08 Mar '14

08 Mar '14

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_gran… --- 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_gran… --- 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_t… --- A bundling exception for JAXP and JAX-WS in openJDK has been granted. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_gran… --- 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_acce… --- Additional wording was added to the procedures for dealing with bundled library handling. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#When_a_Bundle… 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_migrati… --- 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_F… --- 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_scriptl… --- 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_Information_… --- 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#P… --- 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_de… 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_addi… --- 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

1 0

F21 System Wide Change: u-boot syslinux by default
by Jaroslav Reznik 07 Mar '14

07 Mar '14

= 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

1 0

F21 System Wide Change: jQuery
by Jaroslav Reznik 07 Mar '14

07 Mar '14

= 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.

1 0

ANN Retiring pdftk for F20+
by Jochen Schmitt 06 Mar '14

06 Mar '14

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce March 2014