devel-announce June 2017

devel-announce@lists.fedoraproject.org

9 participants
30 discussions

F27 System Wide Change: Golang 1.9
by Jan Kurik 21 Jun '17

21 Jun '17

= 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

1 0

F27 System Wide Change: Fedora 27 Boost 1.64 upgrade
by Jan Kurik 21 Jun '17

21 Jun '17

= 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

1 0

F27 System Wide Change: Enable TRIM pass down to encrypted disks
by Jan Kurik 20 Jun '17

20 Jun '17

= 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

1 0

F27 System Wide Change: Separate Subpackage and Source Debuginfo
by Jan Kurik 20 Jun '17

20 Jun '17

= 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/debugsubp…) and integrate them into rpm upstream. This will involve two steps: - https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package… - https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-package… 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

1 0

F27 System Wide Change: Parallel Installable Debuginfo
by Jan Kurik 20 Jun '17

20 Jun '17

= 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

1 0

Fwd: Node.js v8.x in Fedora
by Zuzana Svetlikova 20 Jun '17

20 Jun '17

---------- 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

1 0

Fedora 27 Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild)
by Jan Kurik 20 Jun '17

20 Jun '17

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

1 0

F27 System Wide Change: Kerberos KCM credential cache by default
by Jan Kurik 20 Jun '17

20 Jun '17

= 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

1 0

Planned Outage - Fedora Buildsystem Server reboots - 2017-06-20 21:00UTC
by Kevin Fenzi 19 Jun '17

19 Jun '17

There will be an outage starting at 2017-06-20 21:00UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2017-06-20 21:00 UTC Reason for outage: We will be applying updates and rebooting servers into newer kernels. Fedora build related services may be up or down during the outage window. Affected Services: pkgs.fedoraproject.org koji koshei kojipkgs pkgdb bodhi / updates mdapi service Services not listed are not affected by this outage. Contact Information: Ticket Link: https://pagure.io/fedora-infrastructure/issue/6118 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. `` To reply, visit the link below or just reply to this email https://pagure.io/fedora-infrastructure/issue/6119

1 0

F27 Self Contained Change: PHP 7.2
by Jan Kurik 19 Jun '17

19 Jun '17

= 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce June 2017