F27 System Wide Change: Golang 1.9
by Jan Kurik
= System Wide Change: Golang 1.9 =
https://fedoraproject.org/wiki/Changes/golang1.9
Change owner(s):
* Jakub Čajka <jcajka AT redhat DOT com>
Rebase of Golang package to upcoming version 1.9 in Fedora 27,
including rebuild of all dependent packages(pre-release version of Go
will be used for mass rebuild).
== Detailed Description ==
Rebase of Golang package to upcoming version 1.9 in Fedora 27. Golang
1.9 is schedule to be released in Aug/Sep. Due to current nature of Go
packages, rebuild of dependent package will be required to pick up the
changes.
Along with the rebase I do propose to drop ppc64 from Go
architectures(effectively disabling build of all packages adhering to
draft Go packaging guidelines) as ppc64 port of "GC" is not feature
complete(never were) and with Go 1.9 "GC" will be supporting only
Power 8 and up. Due to limitation of the Go port impact should be
fairly limited. Possible alternative could be switch to gccgo, but it
is generally not used by upstreams and less tested than GC and move
will most probably require nontrivial amount of packaging/debugging
work.
== Scope ==
* Proposal owners:
Rebase golang package in f27, help with resolving possible issues
found during package rebuilds. Change Go packaging macros in way that
will drop ppc64 builds.
* Other developers:
fix possible issues with help from golang maintainers
* Release engineering:
As there is scheduled mass-rebuild ( #6853 ), nothing should be required.
* List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 10 months
F27 System Wide Change: Fedora 27 Boost 1.64 upgrade
by Jan Kurik
= Proposed System Wide Change: Fedora 27 Boost 1.64 upgrade =
https://fedoraproject.org/wiki/Changes/F27Boost164
Change owner(s):
* Jonathan Wakely <jwakely AT fedoraproject DOT org >
This change brings Boost 1.64.0 to Fedora 27. This will mean F27 ships
with a recent upstream Boost release.
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.
The equivalent changes for previous releases were Fedora 22 Change and
Fedora 23 Change and Fedora 24 Change and Fedora 26 Change.
https://fedoraproject.org/wiki/Changes/F22Boost158
https://fedoraproject.org/wiki/Changes/F23Boost159
https://fedoraproject.org/wiki/Changes/F24Boost160
https://fedoraproject.org/wiki/Changes/F26Boost163
== Scope ==
* Proposal owners:
- Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
- Request a "f27-boost" build system tag (discussion
http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
): https://fedorahosted.org/rel-eng/ticket/6235 → f24-boost
- Build boost into that tag (take a look at the build #606493 for
inspiration) http://koji.fedoraproject.org/koji/buildinfo?buildID=606493
- Post a request for rebuilds to fedora-devel
- Work on rebuilding dependent packages in the tag.
- When most is done, re-tag all the packages to rawhide
- Watch fedora-devel and assist in rebuilding broken Boost clients (by
fixing the client, or Boost).
* Other developers:
Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering: #6851 https://pagure.io/releng/issue/6851
** List of deliverables: All deliverables will include updated Boost packages
* Policies and guidelines:
Apart from scope, this is business as usual, so no policies, no guidelines.
* 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
6 years, 10 months
F27 System Wide Change: Enable TRIM pass down to encrypted disks
by Jan Kurik
= System Wide Change: Enable TRIM pass down to encrypted disks =
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
Change owner(s):
* Vratislav Podzimek <vpodzime AT redhat DOT com>
* Ondrej Kozina <okozina AT redhat DOT com>
Override kernel default for dm-crypt mappings of LUKS1 encrypted
volumes via flag put in /etc/crypttab file. This change should affect
only newly created encrypted storage based on LUKS1 format during
installation.
== Detailed Description ==
User base of Fedora distribution with SSDs grows steadily and while
the argument for kernel default setting not to enable the discard is
still strong one it doesn't change the fact that vast majority of
users (with SSDs) doesn't want to sacrifice better performance of
drive with discard/trim enabled for the sake of secrecy.
We're not speaking encrypted data security here and double emphasize
on it! Only the fact that blank filesystem on top of dm-crypt device
with discard enabled may create well visible patterns in ciphertext
device below on SSDs.
For LUKS1 metadata format we don't have a space to store the new
default in metadata and therefore we can't flip the default for new
LUKS1 devices being formated via libcryptsetup or cryptsetup utility.
Changing the kernel default is of the table due to risk of data
corruption with some TrueCrypt configurations involving hidden
volumes.
For rotational devices the cost of enabled discard is negligible
== Scope ==
* Proposal owners:
This change despite being system wide change due to overriding legacy
default is quite small and easy to manage.
* Other developers:
Very minor change in python-blivet. Basically we just need to store
discard keyword in /etc/crypttab lines related to new partitions
created during installation process.
* Release engineering:
N/A
* List of deliverables:
N/A
* Policies and guidelines:
Add short information in documentation we're changing long term
default and copy the reasoning there.
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 10 months
F27 System Wide Change: Separate Subpackage and Source Debuginfo
by Jan Kurik
= System Wide Change: Separate Subpackage and Source Debuginfo =
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
Change owner(s):
* Mark Wielaard <mjw AT fedoraproject DOT org>
* Neal Gompa <ngompa13 AT gmail DOT com>
Allow to install just the debuginfo for a subpackage and/or without
the source files. The debuginfo packages are huge because they contain
debuginfo and all sources for all subpackages. Being able to install
only the debuginfo for the subpackage that is installed reduces the
size that needs to be downloaded to analyze, trace, profile or debug a
program or core file. Some tracing and profiling tools don't need the
actual source files to provide stack traces or insert probes. So
installing the debugsources should be optional.
== Detailed Description ==
Currently both the .debug files and the source files of all
subpackages are included in a debuginfo package. This creates huge
debuginfo packages with a lot of data that might not be relevant to
the user/developer. By splitting out the sources (found under
/usr/src/debug) and the .debug file for the separate binaries of the
subpackages (under /usr/lib/debug) the amount of data a developer/user
needs to install to trace, profile or debug will be greatly reduced.
Other distributions (notably Suse) already split their debuginfo
packages this way. We will take those patches
(https://build.opensuse.org/package/view_file/openSUSE:Factory/rpm/debugsu...)
and integrate them into rpm upstream. This will involve two steps: -
https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-packa...
- https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-packa...
This depends on some of the cleanups introduced by the
ParallelInstallableDebuginfo change.
We can either make this work with the current dnf debuginfo-install
plugin by providing a meta package that matches the main-debuginfo
package which depends on all sub- and source-debuginfo packages. Or we
work with the dnf hackers to make dnf debuginfo-install work with
sub-debuginfo packages.
A couple of packages already have hand-written sub-debuginfo packages
(notably the kernel, glibc and gcc). We will work with those packages
to adopt the new standard approach.
Release engineering needs to be involved to see if any changes are
necessary for adding the sub-debuginfo/debugsources packages to the
repodata.
== Scope ==
* Proposal owners:
Patches against rpm upstream need to be integrated as outlined in the
Detailed Description.
* Other developers:
Upstream 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. Packages that
now split their debuginfo packages by hand might want to change their
package to adopt the new (standard) approach. Once all changes are in
a package debuginfo needs to be regenerated before it becomes
sub-package/source split.
* Release engineering:
Needs to be discussed. In theory no changes apart from those listed
above are needed. But release engineering might know whether any
changes are necessary for adding the sub-debuginfo/debugsources
packages to the 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 sub-package debuginfo and debugsources 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
6 years, 10 months
F27 System Wide Change: Parallel Installable Debuginfo
by Jan Kurik
= System Wide Change: Parallel Installable Debuginfo =
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
Change owner(s):
* Mark Wielaard <mjw AT fedoraproject DOT org>
debuginfo packages can be installed in parallel to make it easier to
trace, profile and 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 have been developed against rpm debugedit
to accept a hash value to seed the build-id calculation, 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 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. (Note most of this
has been done already during the F25 cycle. Only one outstanding patch
is not yet ready.)
* 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
6 years, 10 months
Fwd: Node.js v8.x in Fedora
by Zuzana Svetlikova
---------- Forwarded message ----------
From: Zuzana Svetlikova <zsvetlik(a)redhat.com>
Date: Mon, Jun 19, 2017 at 5:48 PM
Subject: Node.js v8.x in Fedora
To: devel(a)lists.fedoraproject.org
Cc: nodejs(a)lists.fedoraproject.org
Hi everyone,
as there is nothing stopping us now, the nodejs package in Rawhide will
soon be
updated to Node.js v8.x. It also comes with npm@5 and new V8.
Note that upstream has made a lot of changes and your projects/packages
might have
some issues.
I'll update nodejs in rawhide next week, if you wish to try it out sooner,
it's already built here:
https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-lts/
Zuzka
6 years, 10 months
Fedora 27 Change Checkpoint: Proposal submission deadline (Changes
requiring mass rebuild)
by Jan Kurik
Greetings!
Today, on 2017-June-20, we have reached Fedora 27 Change Checkpoint:
Proposal submission deadline (Changes requiring mass rebuild) [1].
At this point, only Changes not requiring mass rebuild will be
accepted for Fedora 27. Any Change Proposal requiring mass rebuild
should be scheduled for a later Fedora release.
System Wide as well as Self Contained Changes not causing a need for
mass rebuild are still accepted according to the F27 schedule [1].
[1] https://fedoraproject.org/wiki/Releases/27/Schedule
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 10 months
F27 System Wide Change: Kerberos KCM credential cache by default
by Jan Kurik
= System Wide Change: Kerberos KCM credential cache by default =
https://fedoraproject.org/wiki/Changes/KerberosKCMCache
Change owner(s):
* Jakub Hrozek <jhrozek AT redhat DOT com>
Default to a new Kerberos credential cache type called KCM which is
better suited for containerized environments and provides a better
user experience in the general case as well.
== Detailed Description ==
Over time, Fedora used different credential cache types to store
Kerberos credentials - going from a simple file-based storage (FILE:)
to a directory (DIR:) and most recently a kernel-keyring based cache
(KEYRING:).
Each of these caches has its own set of advantages and disadvantages.
The FILE ccache is very widely supported, but does not allow multiple
primary caches in a collection. The DIR cache does, but creating and
managing the directories including proper access control can be
tricky. The KEYRING cache is not well suited for cases where multiple
semi-isolated environments might share the same kernel. Managing
credential caches' life cycle is not well solved in neither of these
cache types automatically, only with the help of a daemon like SSSD.
The scope of this change is to introduce a new Kerberos credential
cache type called KCM and switch to using it by default.
With KCM, the Kerberos caches are not stored in a "passive" store, but
managed by a daemon. In this setup, the Kerberos library (typically
used through an application, like for example, kinit) is a "KCM
client" and the daemon is being referred to as a "KCM server". The KCM
server will be provided as a socket-activated service of the SSSD
deamon.
== Scope ==
* Proposal owners:
SSSD developers will implement a KCM server. The deamon along with a
krb5.conf snippet will be packaged in a subpackage called `sssd-krb5`.
The interested variants of Fedora that would wish to opt in would add
the `sssd-krb5` subpackage to their compose.
* Other developers:
None required
* Release engineering:
None required
* List of deliverables:
None affected
* Policies and guidelines:
None required
* 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
6 years, 10 months
F27 Self Contained Change: PHP 7.2
by Jan Kurik
= Proposed Self Contained Change: PHP 7.2 =
https://fedoraproject.org/wiki/Changes/php72
Change owner(s):
* Remi Collet < remi at fedoraproject dot org >
Update the PHP stack in Fedora to latest version 7.2.x
== Detailed Description ==
Update the PHP stack in Fedora to latest version 7.2.x.
PHP 7.2.0 is planed for end of year, which seems compatible with
Fedora roadmap. [ https://wiki.php.net/todo/php72 ]
Compatibility for PHP code is very good.
== Scope ==
* Proposal owners:
- Check Koschei status. Test with latest version to ensure compatibility.
- Work with upstream on bug fixing.
- Needed mass rebuild (C extensions) done by change owner.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
RelEng ticket: https://pagure.io/releng/issue/6846
* 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
6 years, 10 months
