F26 System Wide Change: Debugging Information For Static Libraries
by Jan Kurik
= 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
7 years, 5 months
F26 System Wide Change: GHC 8.0
by Jan Kurik
= 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
7 years, 5 months
F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates
by Jan Kurik
= 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
7 years, 5 months
evolution-data-server soname version bump in rawhide with the
3.23.2 release
by Milan Crha
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
7 years, 5 months
COPR auto-rebuilds on pagure commits
by Michal Novotny
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
7 years, 5 months
Fedora 25 Final Release Readiness Meeting, Thursday, November 10th @
19:00 UTC
by Jan Kurik
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
7 years, 5 months
Fedora 25 Final Go/No-Go Meeting, Thursday, November 10th @ 17:00 UTC
by Jan Kurik
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
7 years, 5 months
F26 Self Contained Change: Module Build Service
by Jan Kurik
= 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
7 years, 5 months
F26 Self Contained Change: Modular Compose
by Jan Kurik
= 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
7 years, 5 months
