devel-announce March 2014

devel-announce@lists.fedoraproject.org

7 participants
34 discussions

Summary of accepted Fedora 21 Changes - week 12
by Jaroslav Reznik 26 Mar '14

26 Mar '14

Greetings! This is a summary of FESCo's accepted Fedora 21 Changes for week 12 (2014-03-19 meeting). Reminder: the Change Submission deadline for System Wide Change is due in less than two weeks! = System Wide Changes = * u-boot syslinux by default URL: https://fedoraproject.org/wiki/Changes/u-boot_syslinux Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-March/196448.html 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. u-boot is the bootloader used on ARM systems in Fedora so the scope of this change is limited to ARM hardware only. * jQuery URL: https://fedoraproject.org/wiki/Changes/jQuery Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-March/196411.html 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. * Xorg without root rights URL: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-March/196534.html 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. = Self Contained Changes = * Allwinner sunxi (A10 / A13 / A20) ARM SoC support URL: https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-March/196231.html Allwinner A10 / A13 / A20 SoCs? are used in a number of popular low cost arm development boards and arm mini computers. Currently Fedora ARM is supported on these devices through a Remix. Allwinner kernel support is progressing rapidly upstream, and with this upstream kernel support it should be possible to support Allwinner SoCs? in the official Fedora ARM images, without the need for a remix. * Add amd map parser to autofs URL: https://fedoraproject.org/wiki/Changes/Add_amd_map_parser_to_autofs Announcement: https://lists.fedoraproject.org/pipermail/devel/2014-March/196372.html The am-utils package provides automount services for automount maps that use an amd format. However, the am-utils project has not been actively maintained for quite a while now. The am-utils package in Fedora has significant problems that are not easily resolved so an amd format parser is to be added to the autofs package. * CUPS Journal Logging URL: https://fedoraproject.org/wiki/Changes/CupsJournalLogging Announcement: https://fedoraproject.org/wiki/Changes/CupsJournalLogging By default, CUPS will send log output to the system journal rather than /var/log/cups/error_log.

1 0

F21 Self Contained Change: Amplab Tachyon
by Jaroslav Reznik 26 Mar '14

26 Mar '14

= Proposed Self Contained Change: Amplab Tachyon = https://fedoraproject.org/wiki/Changes/AmplabTachyon Change owner(s): Timothy St. Clair <tstclair(a)redhat.com> Amplab-Tachyon [1] is a fault tolerant distributed file system enabling reliable file sharing at memory-speed across cluster frameworks. == Detailed Description == Amplab-Tachyon is a fault tolerant distributed file system enabling reliable file sharing at memory-speed across cluster frameworks, such as Spark and MapReduce. It achieves high performance by leveraging lineage information and using memory aggressively. Amplab-Tachyon caches working set files in memory thereby avoiding going to disk to load datasets that are frequently read. This enables different jobs/queries and frameworks to access cached files at memory speed. == Scope == * Proposal owners: Currently our Amplab-Tachyon package has been accepted into Fedora. It should feature all of the functionality available from the upstream release. * 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] http://tachyon-project.org/index.html

1 0

[HEADS UP] Update to Django-1.6, even for f20
by Matthias Runge 26 Mar '14

26 Mar '14

On Tue, Mar 18, 2014 at 08:17:36AM -0400, Stephen Gallagher wrote: > When this goes to updates-testing for F20, please make a > devel-announce post describing what changes that Django package owners > should make in order to keep their package on Django 1.5 or older if > they need to. Earlier today, I've built Django-1.6 for Rawhide and for F20 as well and submitted the upgrade to f20-testing via bodhi[1]. Please test and leave karma there. If you're a packager and your package requires an older Django version, please change your package to require python-django15 and add from pkg_resources import require require('Django>=1.5,<1.6') to appropriate location(s) in your package. There is a blog post[2] on how to consume older versions of Django. Even if the update to Django-1.6 won't make it to stable, it should be safe to change your package anyways, as older Django versions will be retired sooner or later. If you require help, please contact me off list. Thanks, Matthias [1] https://admin.fedoraproject.org/updates/python-django-1.6.2-1.fc20 [2] https://www.matthias-runge.de/2014/03/26/fedora-django-1-6/ -- Matthias Runge <mrunge(a)matthias-runge.de>

1 0

Reminder: Change Proposals Submission Deadline in two weeks
by Jaroslav Reznik 25 Mar '14

25 Mar '14

Hi, the Change Proposals Submission Deadline is coming soon, in two weeks [1] - 2014-04-08. I'd like to ask especially WGs to work on the PRD/Tech Specs break out into the Change Proposals - so the scope of release can be evaluated and also for tracking purposes to knwo where we are with Fedora 21/Next release. Help us with Fedora 21 and .next initiative planning and development coordination! See https://fedoraproject.org/wiki/Changes/Policy for current policy for submissions and start a new proposal using this template https://fedoraproject.org/wiki/Changes/EmptyTemplate Let me know in case of any issues, I'll try to help you! [1] https://fedoraproject.org/wiki/Releases/21/Schedule Jaroslav

1 0

F21 Self Contained Change: NFS Ganesha File Server
by Jaroslav Reznik 21 Mar '14

21 Mar '14

= Proposed Self Contained Change: NFS Ganesha File Server = https://fedoraproject.org/wiki/Changes/NFSGanesha Change owner(s): Jim Lieb <lieb(a)sea-troll.net> NFS Ganesha is a user mode file server that supports NFSv3, NFSv4, and NFSv4.1 including pNFS for distributed filesystems. It uses loadable filesystem driver modules to support its backend filesystems. It also integrates 9P.2000L file service. == Detailed Description == NFS Ganesha is a user-mode file server for NFS (v3, v4.0 , v4.1 pNFS) and for 9P from the Plan9 UNIX O/S. It integrates with backend filesystems via its File System Abstraction Layer (FSAL) which is a set of loadable modules that implement the access to these filesystems. Using a FSAL is similar to FUSE in that the whole filesystem can be implemented in user space. This is especially advantagious for pNFS and distributed filesystems where storage is distributed across a network. For backend (FSAL) modules than can be supported , see Change Page. Those FSALs labeled as Yes are packaged for Fedora. Those labeled Not Yet require upstream packages that are not available yet. Those labeled No cannot be packaged with Fedore either due to licensing or availability. NFS Ganesha supports pNFS as both a metadata server (MDS) and a data server (DS). It supports both files and object layouts for depending on what is supported by the underlying filesystem. == Scope == This is a new package based on the new V2.0.0 upstream release. No other changes to the system are required. * Proposal owners: The upstream just released (DEC 2013) V2.0.0. Initial packaging is complete and accepted. The package will be updated during the development period to the latest stable release. * 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 0

F21 Self Contained Change: Apache Spark
by Jaroslav Reznik 21 Mar '14

21 Mar '14

= Proposed Self Contained Change: Apache Spark = https://fedoraproject.org/wiki/Changes/ApacheSpark Change owner(s): William Benton <willb(a)redhat.com> Apache Spark is a fast and general engine for large-scale data processing. This change brings Spark to Fedora, allowing easy deployment and development of Spark applications on Fedora. == Detailed Description == Apache Spark is a fast and general engine for large-scale data processing. It supports developing custom analytic processing applications over large data sets or streaming data. Because it has the capability to cache intermediate results in cluster memory and schedule DAGs of computations, Spark programs can run up to 100x faster than equivalent Hadoop MapReduce jobs. Spark applications are easy to develop, parallel, fast, and resilient to failure, and they can operate on data from in-memory collections, local files, a Hadoop- compatible filesystem, or from a variety of streaming sources. Spark also includes libraries for distributed machine learning and graph algorithms. == Scope == * Proposal owners: Currently our Spark package has been accepted into Fedora [1]. It features nearly all of the functionality available from the upstream release. (The missing features -- specifically, Python bindings, the Spark REPL, Kryo-based serialization, primitives for approximate cardinalities of very large sets, and Mesos integration -- were missing from the initial packages due to unavailable dependencies and bundling issues; we're working to close the gap with upstream as quickly as possible.) This work depended upon Fedora 21's improved support for the Scala ecosystem [2]. * 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] http://pkgs.fedoraproject.org/cgit/spark.git [2] https://fedoraproject.org/wiki/Changes/ImprovedScalaEcosystem

1 0

F21 Self Contained Change: Improved Scala Ecosystem Support
by Jaroslav Reznik 21 Mar '14

21 Mar '14

= Proposed Self Contained Change: Improved Scala Ecosystem Support = https://fedoraproject.org/wiki/Changes/ImprovedScalaEcosystem Change owner(s): William Benton <willb(a)redhat.com> Fedora now supports several essential parts of the Scala language ecosystem as well as building packages with sbt, the de facto build tool for the Scala community. == Detailed Description == Fedora has had a Scala package for some time, but the larger Scala ecosystem has been absent from Fedora. In fact, until very recently, Fedora included no packages that depended on Scala. The main obstacle to getting Scala ecosystem projects packaged for Fedora was the difficulty in packaging sbt, the Simple Build Tool, which many Scala projects use for build, dependency, and release management. Fedora 21 now includes sbt as well as several interesting and foundational Scala ecosystem projects, most notably: * akka, a toolkit for developing actor-based systems; * json4s, a unified interface to JSON parsers and generators; * sbinary, a typed Scala interface for reading and writing binary formats; * sbt, the simple build tool for Scala and Java projects; * scala-stm, a software transactional memory implementation for Scala; * scalacheck, a property-based testing framework for Scala; and * scalaz, a set of extensions to the Scala standard library to facilitate functional programming. == Scope == * Proposal owners: The change is complete as described; other ecosystem packages and additional Fedora-specific developer documentation will continue to become available. * 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 0

F21 System Wide Change: Java 8
by Jaroslav Reznik 21 Mar '14

21 Mar '14

= Proposed System Wide Change: Java 8 = https://fedoraproject.org/wiki/Changes/Java8 Change owner(s): Omair Majid <omajid(a)redhat.com> Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk) the default Java runtime. The current default Java runtime (Java 7, provided by OpenJDK 7, java-1.7.0-openjdk) will be obsoleted and removed. This is essentially an upgrade to the latest Java and OpenJDK version. == Detailed Description == The current default Java 7 runtime in Fedora is OpenJDK 7. The latest version of OpenJDK, 8, was released on 18 March 2014. Given that Fedora 21 will not be released before August, it makes sense to include the latest version of OpenJDK in Fedora 21. OpenJDK 8 is a significant update to Java. It brings in significant new features to the Java language, including lambdas, a new javascript engine and lots of new library features. A complete list of features is available [1]. OpenJDK 8 is a backwards compatible update. Theoretically everything that worked against OpenJDK 7 should continue working against OpenJDK 8. There are a few exceptions: OpenJDK8 is much more strict when it comes to building javadocs. Many - javadoc package in Fedora fail to build. Those that are built should continue working just fine. Packages that rely on non-public OpenJDK API may fail to build/run. A complete list of incompatibilities is available [2]. The incompatibilities are source and behavioral only. It may be a good idea to mass rebuild Java packages against OpenJDK 8 to spot any source incompatibilities earlier. This is not required. == Scope == * Proposal owners: ** Deprecate/Obsolete java-1.7.0-openjdk ** Promote java-1.8.0-openjdk to a full java runtime status (fix provides in package) ** In case of a mass rebuild, supply/apply patches to fix build against OpenJDK 8 * Other developers: ** icedtea-web maintainers will need to update icedtea-web to run against OpenJDK 8 ** Other java packagers will need to apply patches to their java package to ensure they can build against OpenJDK 8 ** Everyone will need to test packages to verify that they work against OpenJDK 8 * Release engineering: ** Remove java-1.7.0-openjdk ** Possibly mass-rebuild (?) all Java packages. This is not strictly required to make OpenJDK 8 the default Java runtime. * Policies and guidelines: ** Many -javadoc packages fail to build. The OpenJDK 8 maintainers and the Java SIG are working on identifying a solution. The solution may require [3] guideline changes making -javadoc subpackages optional. [1] http://openjdk.java.net/projects/jdk8/features [2] http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366… [3] https://lists.fedoraproject.org/pipermail/devel/2014-March/196808.html

1 0

bodhi 0.9.9 deployed
by Luke Macken 18 Mar '14

18 Mar '14

Hi all, A new version of bodhi has just hit production. This release contains a few karma-related changes that packagers should be aware of. https://admin.fedoraproject.org/updates Summary of changes ------------------ * Reset the karma to 0 when new builds are added to an existing update (Mathieu Bridon) https://fedorahosted.org/fesco/ticket/1238 https://fedorahosted.org/bodhi/ticket/388 * Disable karma automatism upon AutoQA test failures (Luke Macken) https://fedorahosted.org/fesco/ticket/1242 https://github.com/fedora-infra/bodhi/issues/36 * Do not trigger the stablekarma threshold if the update is being pushed (Luke Macken) https://fedorahosted.org/bodhi/ticket/649 * Prefix the updateinfo file with its hash in the repo metadata (Mathieu Bridon) https://github.com/fedora-infra/bodhi/pull/35 * Fixed a bug with querying the RPM changelogs, which are used in update announcements (Mathieu Bridon) https://github.com/fedora-infra/bodhi/pull/38 Complete list of changes ------------------------ https://github.com/fedora-infra/bodhi/compare/0.9.8...0.9.9 Bugs & Enhancements ------------------- If you encounter any issues, or want to suggest an enhancement, please file a ticket here: https://fedorahosted.org/bodhi/newticket

1 0

F21 System Wide Change: Optional Javadocs
by Jaroslav Reznik 18 Mar '14

18 Mar '14

= Proposed System Wide Change: Optional Javadocs = https://fedoraproject.org/wiki/Changes/OptionalJavadocs Change owner(s): Stanislav Ochotnicky <sochotnicky(a)redhat.com> Make javadoc subpackages of Java packages optional in guidelines and communicate this change to users. == Detailed Description == With introduction of ARM as primary Fedora architecture and release of OpenJDK 8 it will become increasingly difficult to maintain javadoc subpackages in all Java packages. Initial testing showed 80% build failure rate due to OpenJDK 8 update. Additionally building javadocs is memory and CPU intensive and usually severely impacts build times (most on ARM architecture) for questionable benefit. Moreover our javadoc subpackages were never fully interconnected, mostly due to non-automated parts in generation. Work on improving javadoc generation is currently low-priority. Making javadoc subpackages optional will enable packages with leaf packages (end user applications) or deprecated libraries with dead upstream which nobody should be developing against to opt-out of javadoc subpackage creation. == Scope == * Proposal owners: Prepare new Java packaging guideline draft * Other developers: (optionally) Remove their javadoc subpackages if it makes sense for their packages and make main package Obsolete them * Release engineering: Nothing * Policies and guidelines: New Packaging:Java guideline has to be prepared

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce March 2014