devel-announce November 2016

devel-announce@lists.fedoraproject.org

5 participants
21 discussions

F26 System Wide Change: Debugging Information For Static Libraries
by Jan Kurik 16 Nov '16

16 Nov '16

= Proposed System Wide Change: Debugging Information For Static Libraries = https://fedoraproject.org/wiki/Changes/StaticLibraryDebuginfo Change owner(s): * Florian Weimer <fweimer AT redhat DOT com> This change proposes to ship debugging information in static libraries. == Detailed Description == At present, rpm strips static libraries and discards the debugging information in them (that is, the debugging information is not copied into the -debuginfo packages). After that, there is no way to recover the debugging information, say if it is needed to analyze an issue in a statically linked application. This change proposes to stop stripping static libraries. To improve debugging experience, it is desirable that the static libraries are still rewritten at RPM build time, to point the file references to the final location under /usr/src/debug. The technical side of this change is tracked in bug 1395280. == Scope == * Proposal owners: rpm needs to be changed to stop stripping static libraries. If possible, static libraries should still be rewritten so that the debugging information points to the source files under /usr/src/debug, for optimum developer experience. * Other developers: Some packages copy static libraries into places where rpm cannot find them, so that they are not stripped. These changes are not strictly necessary, but can reduce RPM/installation size for developer packages. * Release engineering: This change requires a mass rebuild to become fully effective. * List of deliverables: No release blocking deliverables. * Policies and guidelines: no changes proposed (change will be implemented through rpm) * 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

F26 System Wide Change: GHC 8.0
by Jan Kurik 11 Nov '16

11 Nov '16

= Proposed System Wide Change: GHC 8.0 = https://fedoraproject.org/wiki/Changes/GHC_8.0 Change owner(s): * Jens Petersen <petersen AT redhat DOT com> * Haskell_SIG<haskell AT lists DOT fedoraproject DOT org> Update the GHC Haskell compiler in Fedora from version 7.10 to the current stable version 8.0, with much improved support for aarch64, ppc64, and ppc64le. == Detailed Description == GHC 8.0 contains many new features, fixes, and improvements including performance. Other distros are already moving to it and Fedora users will benefit from it too. This will require updating some and rebuilding all of the Haskell packages in Fedora. == Scope == * Proposal owners: all building work will be done in f26-ghc * Other developers: Negligible work outside Haskell SIG, but the SIG can try to help resolve any issues which should arise. * Release engineering: f26-ghc needs to be created and once all rebuilding there is completed the builds need to be tagged into f26 * List of deliverables: mostly just version bumps * Policies and guidelines: no Haskell Packaging changes currently planned (except possibly explicit `%files` lists) * 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

Fedora 25 Final status is NO-GO
by Jan Kurik 10 Nov '16

10 Nov '16

The result for the Go/No-Go meeting for the Fedora 25 Final release is NO-GO. Due to a present blocker [1] the decision is to slip the Fedora 25 Final release for a week. The new GA data is planned on 2016-Nov-22. More information can be found in the meeting minutes [2][3]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1393846 [2] https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gon… [3] https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gon… Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates
by Jan Kurik 10 Nov '16

10 Nov '16

= Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags Updates = https://fedoraproject.org/wiki/Changes/Fedora26CFlags Change owner(s): * Florian Weimer <fweimer AT redhat DOT com> This change updates the default C/C++ compilation flags, as determined by the redhat-rpm-config package. == Detailed Description == This change covers the following modifications to the default C and C++ compiler flags in the redhat-rpm-config package. * Drop -mtune=atom on i686: This flag was added to improve performance on the Intel Bonnell microarchitecture. Such CPUs are rare these days. In addition, many users of the i686 packages download them for use within a 64-bit x86_64 installation, and only a small part of these Fedora installations use Atom CPUs. Current microarchitectures for Atom CPUs are different from the original Bonnell microarchtecture and would need different GCC flags for tuning, but many current Atom-based devices cannot run Fedora because Fedora does not support their 32-bit UEFI boot environment. * Add -Werror=implicit-function-declaration: Implicit function declarations allows a programmer to call functions without declaring them (or including the relevant header files). The official C language specification has not supported implicit function declarations for almost two decades now. GCC still supports them as a GNU extension. Implicit function declarations introduce bugs because these functions use a different calling convention and have a fixed return type of int. Resulting issues are pointer truncation (on 64-bit architectures), exposure of padding bits (particular for bool-returning functions on x86_64), and unexpected lack of hardening. Implicit function declarations are not part of C++ (with or without GNU extensions), and adjusting C code accordingly simplifies reuse in C++ projects. * Add -Werror=implicit-int: Implicit ints were removed from the C programming language at the same time as implicit function definitions, and were also retained as a GNU extension. Implicit ints are usually source code bugs, and the presence of such code may interfere with future C language directions (for example, consider how C++ reused the auto keyword and an omitted type specifier). The main risk from these changes are incorrect autoconf feature checks, which often rely on technically invalid C fragments. However, a review of existing configure scripts did not find any places where they relied on these two problematic GNU extensions. The technical side of this change is tracked in bug 1393492. == Scope == * Proposal owners: The defaults in redhat-rpm-config need to be changed, as described above. * Other developers: Source code which relies on implicit function declarations or implicit ints needs to be adjusted. * Release engineering: This change requires a mass rebuild to become fully effective. * List of deliverables: No release blocking deliverables. * Policies and guidelines: no changes proposed (change will be implemented through redhat-rpm-config) * 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

evolution-data-server soname version bump in rawhide with the 3.23.2 release
by Milan Crha 08 Nov '16

08 Nov '16

Hello, the 3.23.2 release of the evolution-data-server contains a soname version bump for libcamel, which contains many API backward incompatible changes. This had been done for easier introspectionability of the libcamel. Most of the affected modules are covered by upstream [1], where some will be either released together with the evolution-data-server or contain patches, which I'll backport to Fedora. As always, I'll rebuild the required modules for which I've commit rights. There should be made special attention about compiler warnings of those rebuilds, to catch any issues caused by the libcamel API changes (some builds do not stop when a symbol cannot be resolved, some do). In case you'd face any build (or runtime) issue, please let me know and I'll be happy to help to resolve it. I send this notice rather earlier. The upstream 3.23.2 release is currently planned for the November 21st, while the update will reach rawhide shortly after it. Thanks and bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=764065#c24

1 0

COPR auto-rebuilds on pagure commits
by Michal Novotny 07 Nov '16

07 Nov '16

Hey, I'd like to announce that we now support package auto-rebuilding on a new commit(s) into a Pagure repository. Apart from having your package repo hosted in Pagure, you just need to enable firing of fedmsg notifications for new commits by clicking a single checkbox in 'Hooks' section...well, then you also need to save this setting and have auto-rebuilding enabled for the copr package but that really is it, I promise :). clime

1 0

Fedora 25 Final Release Readiness Meeting, Thursday, November 10th @ 19:00 UTC
by Jan Kurik 07 Nov '16

07 Nov '16

Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 25 Final Release Readiness Meeting meeting. The meeting is going to be held on Thursday, November 10th, 2016 at 19:00 UTC. Please check the [FedoCal] link for your time zone. We will meet to make sure we are coordinated and ready for the Final release of Fedora 25. Please note that this meeting is going to be held even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but it is by purpose to open this meeting to the teams and to raise awareness, so hopefully more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. [FedoCal] https://apps.fedoraproject.org/calendar/meeting/4855/ More information available at: https://fedoraproject.org/wiki/Release_Readiness_Meetings Thank you for your support and Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fedora 25 Final Go/No-Go Meeting, Thursday, November 10th @ 17:00 UTC
by Jan Kurik 07 Nov '16

07 Nov '16

Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 25 Final. The meeting is going to be held on Thursday, November 10th, 2016 at 17:00 UTC. Please check the [FedoCal] link for your time zone. Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. Release Candidate (RC) availability and good QA coverage are prerequisites for the Go/No-Go meeting. If you have any bug on the list, please help us with Final release. If we won't be ready by Thursday, we will use this meeting to review blockers and decide what to do. For more details about this meeting please follow the [GoNoGoMeeting] link. In the meantime, please keep also an eye on the Fedora 25 Final Blocker list [Blockers]. [FedoCal] https://apps.fedoraproject.org/calendar/meeting/4857/ [Blockers] http://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist [GoNoGoMeeting] https://fedoraproject.org/wiki/Go_No_Go_Meeting Thank you in advance for your support. Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F26 Self Contained Change: Module Build Service
by Jan Kurik 07 Nov '16

07 Nov '16

= Proposed Self Contained Change: Module Build Service = https://fedoraproject.org/wiki/Changes/ModuleBuildService Change owner(s): * Ralph Bean <rbean(a)redhat.com> We will deploy an instance of the Module Build Service to production in Fedora Infrastructure. Other teams will use this service to produce some "modular" content for the Fedora 26 release. == Detailed Description == We will deploy an instance of the Module Build Service (MBS) to production in Fedora Infrastructure. Other teams will use this service to produce some "modular" content for the Fedora 26 release. In short, the MBS is a workflow orchestration service on top of koji. When a user submits a request for a new module build: * A new tag is created in koji for that module build. * A module-build macros package is synthesized and built in the new buildroot. * The buildroot is linked with other module tags that it has declared dependencies on. * RPMs to be included in the module are rebuilt from source in the new tag. * Kojira generates a yum/dnf repo from the new tag. The compose tooling (pungi) will then pick up this tag and possibly include it in variants for the compose. For the Fedora 26 timeframe, we will lock down the users who can submit to the MBS to a small number of Modularity WG members. This is not ideal, but the thought is that we want to limit the amount of spam that the MBS will impose on the production koji instance - we don't want to interfere with the general release of Fedora 26. In the Fedora 27 timeframe, we will open it up to all packagers after we're sure MBS is sophisticated enough to throttle itself appropriately. == Scope == * Proposal owners: We are responsible for the development, deployment, and maintenance of the Module Build Service itself. We have a prototype already functioning. At the time of writing, we still need to harden it for production, and have it vetted for deployment by Release Engineering and Fedora Infrastructure. * Other developers: We don't think that other developers will have to make changes in response to this effort. The Base Runtime team (a sub-team of the Modularity Working Group) will be working to prepare content to be built in the Module Build Service. * Release engineering: In order to make use of the Module Build Service, we will need changes to pungi to pull rpms for a variant from the koji tags created by the Module Build Service, but that is a separate Change proposal [https://fedoraproject.org/wiki/Changes/ModularCompose] The owners of this proposal intend to do that work ourselves in consultation with Release Engineering. * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: Note that we do not think there are any packaging guidelines that will need to be changed in the Fedora 26 timeline. We would like to change the branching structure in pkgdb and dist-git in the Fedora 27 release cycle (with a separate Change document). We furthermore will need to submit new Module Guidelines that describe best practices and requirements for writing and maintaining modulemd definitions - similar to how the Packaging Guidelines describe best practices and requirements for writing and maintaining .spec files. We would like to avoid writing those Module Guidelines for the F26 cycle and instead limit the number of trusted module maintainers to a small subset of the Modularity Working Group. Once they have experience building the base modules, we'll use that experience to inform the docs we write for F27, at which time we'll open up the Module Build Service to the rest of the community. * 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

F26 Self Contained Change: Modular Compose
by Jan Kurik 07 Nov '16

07 Nov '16

= Proposed Self Contained Change: Modular Compose = https://fedoraproject.org/wiki/Changes/ModularCompose Change owner(s): * Ralph Bean <rbean(a)redhat.com> For Fedora 26, we would like to modify the compose tools (pungi) to produce an additional experimental variant, derived from modules built in the Module Build Service. == Detailed Description == As described in another change proposal [https://fedoraproject.org/wiki/Changes/ModuleBuildService] we are going to implement and stand up a Module Build Service (MBS). Once we have a built module (a side-tag in koji with a corresponding yum/dnf repo), we would like to be able to do something with it: The point of this change is to modify the existing compose tool used by Release Engineering (pungi) so that it can consume content for a new variant from the MBS. For Fedora 26, we would like to produce an experimental variant as an optional part of the primary compose called 'CrazyServer'. We want it to be produced alongside the now-traditional 'Server', 'Workstation', and 'Cloud' variants, using the same tools. In the event of failure, we don't want 'CrazyServer' to be release blocking. Consider this an experiment. == Scope == * Proposal owners: We need to modify pungi to consume content from the MBS. * Other developers: N/A (not a System Wide Change) * Release engineering: We will need to work with Release Engineering to debug any problems we inadvertently introduce. * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce November 2016