devel-announce May 2016

devel-announce@lists.fedoraproject.org

6 participants
16 discussions

Fedora 24 Final Freeze (2016-05-31)
by Dennis Gilmore 27 May '16

27 May '16

Hi all, Tuesday May 31st 2016 is an important day on the Fedora 24 schedule[1], with significant cut-offs. Tuesday is the Final Freeze[2]. This means that only packages which fix accepted blocker or freeze exception bugs[3][4] will be marked as 'stable' and included in the Final composes. Other builds will remain in updates-testing until the Final release is approved, at which point the Final freeze is lifted and packages can move to the 'updates' repository, pending updates will be pushed before final release as zero day updates. The final stable push before freeze will happen shortly after 2016-05-31 00:00:00 Please get all updates you want included requested for stable in bodhi[5] before then. Regards Dennis [1] https://fedoraproject.org/wiki/Releases/24/Schedule [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://bodhi.fedoraproject.org/

1 0

F25 Self Contained Change: Koji Generates Installation Media
by Jan Kurik 27 May '16

27 May '16

= Proposed Self Contained Change: Koji Generates Installation Media = https://fedoraproject.org/wiki/Changes/KojiInstallMedia Change owner(s): * Jay Greguske <jgregusk with the usual red hat domain> Extend Koji with a new feature that allows users to create installation media for various architectures. == Detailed Description == This is a significant enabler for generating DVD media, other ISOs, and images more efficiently. It also allows other tools such as mash or pungi to offload much of the heavy-lifting to the build system. Longer term, we may be able to reduce the number of tools needed to manufacture Fedora releases. == Scope == Proposal owners: * to implement this change Release engineering: * This feature does require coordination with release engineering (e.g. changes to installer image generation or update package delivery.) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Planned Outage: buildsystem Server reboots - 2016-05-24 21:00 UTC
by Kevin Fenzi 20 May '16

20 May '16

Planned Outage: buildsystem Server reboots - 2016-05-24 21:00 UTC There will be an outage starting at 2016-05-24 21:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2016-05-24 21:00 UTC' Reason for outage: We will be updating and rebooting the servers in our build network. Services related to building may be down and up during the outage window. Affected Services: * pkgs.fedoraproject.org * koschei * koji * kojipkgs * bodhi / updates.fedoraproject.org Services not listed are not affected by this outage. Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/5312 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

F25 System Wide Change: Parallel Installable Debuginfo
by Jan Kurik 20 May '16

20 May '16

= Proposed System Wide Change: Parallel Installable Debuginfo = https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo Change owner(s): * Mark Wielaard <mjw AT redhat DOT com> debuginfo packages can be installed in parallel to make it easier to observe what programs are doing or to debug when they have crashed. That way debugging, tracing or profiling programs can be done independent of whether they are 32bit, 64bit, a slightly newer or older version than currently installed or even from a different architecture. == Detailed Description == Currently only one version of a debuginfo package can be installed for a given package. Even on a multi-lib system you cannot install the 64-bit and 32-bit versions of a debuginfo package in parallel (technically you sometimes can, because of RPM file coloring, the 64bit version of the .debug files win over the 32bit version - causing lots of confusion). But there are various situation where having multiple versions of the debuginfo package installed help with tracing, profiling, debugging and/or crash analysis (see the Benefit to Fedora section below). There are various things provided by a debuginfo file that might conflict preventing parallel installation of different versions: * build-id file /usr/lib/debug/.build-id/xx/yyyy...yyy which is a symlink to the main ELF file. * build-id.debug file /usr/lib/debug/.build-id/xx/yyyy...yyy.debug which is a symlink to the .debug ELF file. * The .debug files under /usr/lib/debug/ with file path names mirroring the main ELF file paths under / with .debug added. * The source files under /usr/src/debug/<name>-<version>/ They can be made non-conflicting in the following ways: * The main build-id file should not be in the debuginfo file, but in the main package (this was always a problem since the package and debuginfo package installed might not match). If we want to make usr/lib/debug/ a network resource then we will need to move the symlink to another location (maybe /usr/lib/.build-id). Unfortunately this means a change will be necessary for debuginfo consumers to that depend on the old location. We could keep the old symlink and point it to the new location to work around it. But I will audit the consumers to see which depend on it and discuss if we can have a new standard location. * build-ids are globally unique identifiers. They will be different across arches. But might match between minor releases if the exact same ELF image is produced. The linker will get an option to hash in the full nvr to make sure all build-ids are always fully unique. * The .debug file names will be changed to main ELF file name-vr.debug. This name will also be set in the .gnu_debuglink section of the main file by changing the options given to eu-strip in the rpm find-debuginfo.sh script. * The source files will be moved under /usr/src/debug/<name>-<version>-<release>.<arch>/. This needs changes to the rpm debugedit program which rewrites the DWARF source file information. These changes will make all files in any debuginfo file unique so they don't conflict when installed in parallel. There should be no changes necessary to programs (gdb, perf, valgrind, systemtap, systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids or .gnu_debuglink to lookup DWARF debug information and source references for tracing, profiling and debugging. It would be good to tweak dnf debuginfo-install to know about parallel installable debuginfo packages and maybe have an easy option to install the debuginfo for a core file or for the packages running in a container. Alternative solutions currently rejected: * Move main ELF image build-id file under /usr/lib/.build-id/xx/yyyy...yyy when moving into main pages. Because existing programs probably depend on the link being under /usr/lib/debug/. * Since when the build-id is identifical also the ELF file is identical we could mark all build-id.debug files as replacable in the rpm. It isn't clear that works for symlinks though (but we could reverse the symlink direction from debug file to build-id file). And currently you can identify the exact package nvr installed given just one build-id. That would be impossible if multiple packages could contain the same build-id/ELF image file. * Do away with the old .gnu_debuglink way of accessing files under /usr/lib/debug and just not install .debug files and only support build-id based debug lookups. Because it isn't clear build-ids are 100% available and all programs work with build-id lookups instead through .gnu_debuglink names. * Move the .debug files under a subdir like the sources. /usr/lib/debug/<name>-<version>-<release>.<arch>/. This cannot easily be expressed in .gnu_debuglink, which officially only allows a basename. == Scope == * Proposal owners: Patches need to be developed against the linker (binutils ld and gold) to accept a hash value to seed the build-id calculation, against rpm debugedit to rewrite source paths (currently source paths can only be smaller, this change might create larger paths) and the rpm find-debuginfo.sh script to change the paths, symlinks and .gnu_debuglink names as outlined in the Detailed Description. And the dnf debuginfo-install plugin might be patches to provide subcommands for pulling in debuginfo packages found by build-id in core files and/or programs running in containers. * Other developers: Upstream binutils, rpm and dnf maintainers have to review the proposed patches. If accepted the package maintainers will have to decide whether those patches can be backported for the next fedora release. Once all changes are in a package debuginfo needs to be regenerated before it becomes parallel installable. * Release engineering: Needs to be discussed. In theory no changes apart from those listed above are needed. But if we want to support installing cross-architectures (not just multi-lib arch) debuginfo then some way needs to be found to get those in the right repodata. * List of deliverables: N/A (Still Unknown) * Policies and guidelines: No changes, the debuginfo related rpm macros won't change. They will just start producing parallel installable debuginfo packages once all changes are in place. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F25 Self Contained Change: Java/OpenJDK enforces the system-wide crypto policy
by Jan Kurik 20 May '16

20 May '16

= Proposed Self Contained Change: Java/OpenJDK enforces the system-wide crypto policy = https://fedoraproject.org/wiki/Changes/JavaCryptoPolicies Change owner(s): * Nikos Mavrogiannopoulos <nmav AT redhat DOT com> As it is now, the System-wide crypto policy in F24 is only enforced by the OpenSSL and GnuTLS TLS libraries. To harmonize crypto across all applications in Fedora, including the Java ones, OpenJDK is enhanced to respect the settings of the system-wide crypto policy as well. == Detailed Description == As it is now, the System-wide crypto policy in F24 is only enforced by the OpenSSL and GnuTLS TLS libraries. To harmonize crypto across all applications in Fedora, including the Java ones, OpenJDK is enhanced to respect the settings of the system-wide crypto policy as well. After that change the administrator should be assured that any Java application will follow a policy that adheres to the configured profile. == Scope == * Proposal owners: The change requires modifying OpenJDK to read additional security properties from the generated by the crypto policies file (/etc/crypto-policies/back-ends/java.config). * Other developers: There are no required actions by other developers. The change requires only targeted changes to openjdk and crypto-policies. * Release engineering: No actions required. * Policies and guidelines: The packaging guidelines for crypto policies need to be modified to include OpenJDK/java in the list of libraries supporting the policies. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F25 Self Contained Change: NSS enforces the system-wide crypto policy
by Jan Kurik 20 May '16

20 May '16

= Proposed Self Contained Change: NSS enforces the system-wide crypto policy = https://fedoraproject.org/wiki/Changes/NSSCryptoPolicies Change owner(s): * Nikos Mavrogiannopoulos <nmav AT redhat DOT com> As it is now, the System-wide crypto policy in F24 is only enforced by the OpenSSL and GnuTLS TLS libraries. To harmonize crypto in Fedora, NSS is enhanced to respect the settings of the system-wide crypto policy as well. == Detailed Description == As it is now, the System-wide crypto policy in F24 is only enforced by the OpenSSL and GnuTLS TLS libraries. To harmonize crypto in Fedora, NSS is enhanced to respect the settings of the system-wide crypto policy as well. After that change the administrator should be assured that any application that uses NSS will follow a policy that adheres to the configured profile. == Scope == * Proposal owners: The change requires modifying the NSS library to read a policy generated by the crypto-policy package. * Other developers: There are no required actions by other developers. The change requires only targeted changes to NSS. * Release engineering: No actions required. * Policies and guidelines: - The packaging guidelines for crypto policies need to be modified to include NSS in the list of libraries supporting the policies. - The text "(note that adherence to the system-wide policies is work in progress for NSS libraries)" must be removed - The text "Currently the policies are restricted to applications using GnuTLS and OpenSSL" must be changed to include NSS. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Announcing the release of Fedora 24 Beta for Power64!
by Peter Robinson 17 May '16

17 May '16

The Fedora 24 Beta for Power64 is here, for our planned June final release. For Beta we have Cloud and Docker base images. Download the prerelease from our Get Fedora site: - Get Fedora 24 Beta Server: make use of the very latest server-based technologies available in the open source community https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Ser… https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Ser… - Get Fedora 24 Beta Cloud: build scale-out computing and utilize the next generation of container deployment technology https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Clo… https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Clo… https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Doc… https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Doc… What is the Beta release? ------------------------- The Beta release contains all the exciting features of Fedora 24's editions in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs from the Alpha version. When most of these bugs are fixed, we make a Beta release available. A Beta release is code-complete and bears a very strong resemblance to the third and final release. The final release of Fedora 24 is expected in June. We need your help to make Fedora 24 the best yet. Please take some time to download and try out the Beta and make sure the things that are important to you are working. If you find a bug, please report it – every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. This is a great opportunity for non-programmers to contribute back to fedora. Together, we can make Fedora rock-solid. We have a culture of adding new features to software and pushing fixes to the upstream developers at the same time. This means your feedback will help improve not only Fedora but Linux and free software on the whole. - <https://fedoraproject.org/wiki/Releases/24/Schedule> - <https://fedoraproject.org/wiki/How_to_file_a_bug_report> Fedora-Wide Changes ------------------- Under the hood, glibc has moved to 2.23. This update includes better performance, increased security, bugfixes, improvements to POSIX compliance, and additional locales. The new library is backwards compatible with the version of glibc that was shipped in Fedora 23. We've also updated the system compiler to GCC 6 and rebuilt all of our packages with it, providing greater code optimization and improved program error catching. Server ------ Fedora 24 beta server edition has also been more streamlined. Unnecessary packages were removed and the installer has a smaller footprint. FreeIPA 4.3, an integrated security information management solution is now included. The installation of replicas is streamlined by adding a replica promotion method for new installs. A new topology plugin has also been added to this version of FreeIPA that automatically manages new replication segment creation. An effective replica topology visualization tool is now available in the webUI. Cloud ----- We are working hard to make Fedora the best platform for containerized applications, from base Fedora container images to a full-featured platform as a service to run and manage them. To meet this goal, we are packaging OpenShift Origin so it is easy to deploy. OpenShift Origin is a distribution of Kubernetes, a container cluster manager from Google. It is optimized for enterprise application development and deployment. Origin makes it easy for developers to get started building applications in containers and for operators to manage them. Issues and Details ------------------ This is a Beta release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the mailing list or in #fedora-qa on Freenode. As testing progresses, common issues are tracked on the Common F24 Bugs page. - <https://fedoraproject.org/wiki/Common_F24_bugs> For tips on reporting a bug effectively, read "how to file a bug report." - <https://fedoraproject.org/wiki/How_to_file_a_bug_report> Release Schedule ---------------- The full release schedule is available on the Fedora wiki: - <https://fedoraproject.org/wiki/Releases/24/Schedule> The current schedule calls for a beta release towards the beginning of May, and the final release in early June. Be aware that these dates are development targets. Some projects release on a set date regardless of feature completeness or bugs; others wait until certain thresholds for functionality or testing are met. Fedora uses a hybrid model, with milestones subject to adjustment. This allows us to make releases with new features and newly-integrated and updated upstream software while also retaining high quality.

1 0

F25 System Wide Change: Use /etc/distro.repos.d as default reposdir
by Jan Kurik 12 May '16

12 May '16

= Proposed System Wide Change: Use /etc/distro.repos.d as default reposdir = https://fedoraproject.org/wiki/Changes/ReposInEtcDistroReposD Change owner(s): * Neal Gompa <ngompa13 at gmail dot com> * Jan Silhan <jsilhan at fedoraproject dot org> == Detailed Description == For DNF 2.0 in Fedora 25, the DNF team would like to make the default repository configuration directory /etc/distro.repos.d. In contrast to /etc/yum.repos.d (current default path), /etc/distro.repos.d path is a package manager agnostic name and less misleading. The configuration files are currently used by DNF, PackageKit, and Yum. The proposed location more accurately reflects the nature of the repositories, and also implies that other tools can look there for repository information. Note: current default repository configuration directory /etc/yum.repos.d will still be supported by package managers but /etc/distro.repos.d would be preferred default path. == Scope == * Proposal owners: DNF already supports /etc/distro.repos.d, but it should be set as default. Yum will need to use the new path by default while supporting the current one. * Other developers: PackageKit's Hif backend will need to use the new path by default while supporting the current one. fedora-repos and fedora-workstation-repositories will need to change to the new path. * Release engineering: N/A List of deliverables: N/A (Not needed for this Change) * Policies and guidelines: Packages containing repository configuration will need to change to store repo files in /etc/distro.repos.d. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

[Guidelines change] Changes to the packaging guidelines
by Jason L Tibbitts III 11 May '16

11 May '16

Here are the recent changes to the packaging guidelines. ----- The section on the use of pregenerated code was amended to indicate the preference for having tools necessary to regenerate such code be free software and packaged in Fedora. * https://fedoraproject.org/wiki/Packaging:Guidelines * https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_pregenerated_code * https://fedorahosted.org/fesco/ticket/1514 ----- The outdated prohibition on socket activated services was removed from the Systemd packaging guidelines. * https://fedoraproject.org/wiki/Packaging:Systemd * https://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation * https://fedorahosted.org/fpc/ticket/618 ----- The Perl guidelines were modified to include information about necessary build dependencies now that Perl itself is being removed from the default buildroot. * https://fedoraproject.org/wiki/Packaging:Perl * https://fedoraproject.org/wiki/Packaging:Perl#Build_Dependencies * https://fedorahosted.org/fpc/ticket/620 ----- The section on use of /run has been simplified. * https://fedoraproject.org/wiki/Packaging:Guidelines#.2Frun * https://fedorahosted.org/fpc/ticket/622

1 0

Announcing the release of Fedora 24 Beta for aarch64!
by Peter Robinson 10 May '16

10 May '16

The Fedora 24 Beta for aarch64 is here, on schedule for our planned June final release. For Beta we have added Cloud and Docker base images. Download the prerelease from our Get Fedora site: - Get Fedora 24 Beta Server: make use of the very latest server-based technologies available in the open source community https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Ser… - Get Fedora 24 Beta Cloud: build scale-out computing and utilize the next generation of container deployment technology https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Clo… https://dl.fedoraproject.org/pub/fedora-secondary/releases/test/24_Beta/Doc… What is the Beta release? ------------------------- The Beta release contains all the exciting features of Fedora 24's editions in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs from the Alpha version. When most of these bugs are fixed, we make a Beta release available. A Beta release is code-complete and bears a very strong resemblance to the third and final release. The final release of Fedora 24 is expected in June. We need your help to make Fedora 24 the best yet. Please take some time to download and try out the Beta and make sure the things that are important to you are working. If you find a bug, please report it – every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. This is a great opportunity for non-programmers to contribute back to fedora. Together, we can make Fedora rock-solid. We have a culture of adding new features to software and pushing fixes to the upstream developers at the same time. This means your feedback will help improve not only Fedora but Linux and free software on the whole. - <https://fedoraproject.org/wiki/Releases/24/Schedule> - <https://fedoraproject.org/wiki/How_to_file_a_bug_report> Fedora-Wide Changes ------------------- Under the hood, glibc has moved to 2.23. This update includes better performance, increased security, bugfixes, improvements to POSIX compliance, and additional locales. The new library is backwards compatible with the version of glibc that was shipped in Fedora 23. We've also updated the system compiler to GCC 6 and rebuilt all of our packages with it, providing greater code optimization and improved program error catching. Server ------ Fedora 24 beta server edition has also been more streamlined. Unnecessary packages were removed and the installer has a smaller footprint. FreeIPA 4.3, an integrated security information management solution is now included. The installation of replicas is streamlined by adding a replica promotion method for new installs. A new topology plugin has also been added to this version of FreeIPA that automatically manages new replication segment creation. An effective replica topology visualization tool is now available in the webUI. Cloud ----- We are working hard to make Fedora the best platform for containerized applications, from base Fedora container images to a full-featured platform as a service to run and manage them. To meet this goal, we are packaging OpenShift Origin so it is easy to deploy. OpenShift Origin is a distribution of Kubernetes, a container cluster manager from Google. It is optimized for enterprise application development and deployment. Origin makes it easy for developers to get started building applications in containers and for operators to manage them. Issues and Details ------------------ This is a Beta release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the mailing list or in #fedora-qa on Freenode. As testing progresses, common issues are tracked on the Common F24 Bugs page. - <https://fedoraproject.org/wiki/Common_F24_bugs> For tips on reporting a bug effectively, read "how to file a bug report." - <https://fedoraproject.org/wiki/How_to_file_a_bug_report> Release Schedule ---------------- The full release schedule is available on the Fedora wiki: - <https://fedoraproject.org/wiki/Releases/24/Schedule> The current schedule calls for a beta release towards the beginning of May, and the final release in early June. Be aware that these dates are development targets. Some projects release on a set date regardless of feature completeness or bugs; others wait until certain thresholds for functionality or testing are met. Fedora uses a hybrid model, with milestones subject to adjustment. This allows us to make releases with new features and newly-integrated and updated upstream software while also retaining high quality.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce May 2016