devel-announce July 2018

devel-announce@lists.fedoraproject.org

6 participants
29 discussions

F29 System Wide Change: ZRAM support for ARM images
by Jan Kurik 03 Jul '18

03 Jul '18

= Proposed System Wide Change: ZRAM support for ARM images = https://fedoraproject.org/wiki/Changes/ZRAMforARMimages Owner(s): * Peter Robinson <pbrobinson at fedoraproject dot org> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to improve performance and reliability on ARM Single Board Computers such a the Raspberry Pi. == Detailed description == Current Fedora release artifacts for ARM platforms enable a small amount of swap by default. While this has generally works OK in the past it can cause a number of issues primarily wearing out SD cards due to excess use of wear leveling. ZRAM can mitigate this and provide more memory for ARM SBCs by compressing part of memory and using it as a swap space. This provides better performance and improved reliability across this class of device which overall provides a better end user experience. == Scope == * Proposal owners: Package and include zram config and systemd units. * Other developers: N/A (does not affect developers) * Release engineering: #7607 [https://pagure.io/releng/issue/7607] ** List of deliverables: N/A * Policies and guidelines: N/A (No updates to policies and guidelines required) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F29 System Wide Change: uEFI for ARMv7
by Jan Kurik 03 Jul '18

03 Jul '18

= Proposed System Wide Change: uEFI for ARMv7 = https://fedoraproject.org/wiki/Changes/uEFIforARMv7 Owner(s): * Peter Robinson <pbrobinson at fedoraproject dot org> Move to uEFI as the default boot mechanism for ARMv7 devices. == Detailed description == Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has served us very well and has allowed us to standardise the ARMv7 boot process with the vast majority of devices booting this way OOTB due to the support being in a wide variety of u-boot releases. Over recent years there have been a number of improvement to uEFI including robust support in u-boot. We've supported uEFI on aarch64 as the only way of booting Fedora supporting both Tianocore, proprietary uEFI implementations and since Fedora 27 we've supported uEFI via u-boot too. The uEFI provided by u-boot is now stable enough that we can now move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi and have a single standard booth path/stack for both ARMv7 and aarch64. == Scope == * Proposal owners: Patches, updates to the process, testing * Other developers: System component owners will need to review and merge patches for certain components. * Release engineering: #7606 [https://pagure.io/releng/issue/7606] ** List of deliverables: N/A * Policies and guidelines: N/A I don't believe this changes any policies or guidelines * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fedora 29 Change Checkpoint: Proposal submission deadline (System Wide Changes) has been reached today
by Jan Kurik 03 Jul '18

03 Jul '18

The submission deadline for System Wide Change Proposals of Fedora 29 [1] has been reached today (on July 3rd). From July 4th, please schedule your System Wide Changes for a next release (Fedora 30). The deadline for Self Contained Change Proposals is planned on July 24th. In case you'll need any help with your Change proposals, feel free to contact me. [1] https://fedoraproject.org/wiki/Releases/29/Schedule Best Regards, Jan -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F29 System Wide Change: Remove Excessive Linking
by Jan Kurik 03 Jul '18

03 Jul '18

Note from Change Wrangler: This Change Proposal requires mass rebuild. However, two weeks ago (June 19th), we have already passed the deadline for Change proposals requiring mass rebuild. I will leave the decision whether this Change proposal is accepted or not to RelEng and FESCo teams. = Proposed System Wide Change: Remove Excessive Linking = https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking Owner(s): * Igor Gnatenko <ignatenkobrain at fedoraproject dot org> * Neal Gompa <ngompa13 at gmail dot com> Pass "--as-needed" flag the linker through default system-wide LDFLAGS. == Detailed description == The flag ("--as-needed") tells the linker to link in the produced binary only the libraries containing symbols actually used by the binary itself. This binary can be either a final executale or another library. The use of the "--as-needed" flag allows the linker to avoid linking extra libraries in a binary. This not only improves startup times (as the loader does not have to load all the libraries for every step) but might avoid the full initialization of big frameworks. == Scope == * Proposal owners: Add "-Wl,--as-needed" into RPM_LD_FLAGS (in redhat-rpm-config). * Other developers: Nothing should break, but immediate work-around would be to disable this flag (will be provided in redhat-rpm-config) and fix real issue later. * Release engineering: #7604 [https://pagure.io/releng/issue/7604] (mass rebuild is desired after this change). ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: Add information how to turn it off (TODO link to FPC ticket). * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F29 System Wide Change: OpenLDAP without Non-threaded Libraries
by Jan Kurik 03 Jul '18

03 Jul '18

= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries = https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries Owner(s): * Matus Honek <mhonek at redhat dot com> OpenLDAP will not ship non-threaded version of libldap. Instead, libldap will be built with the same threading support as libldap_r. == Detailed description == After this change the non-threaded version of libldap will not be shipped any more. Instead, this library will rather be built the same way as the threaded libldap_r. This has been previously discussed in Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and other distributions where this change already happened. Upstream still supports non-threaded version of their library as it might be used on processors where threads are not supported. However, when these two versions happen to be loaded at the same time (as discussed about Curl in the Bugzilla) symbol names overlap which may result in unpredictable behaviour. Immediate solution would be to symlink libldap to libldap_r, however SONAME of the library would be the same, hence breaking dependencies of other packages. For that reason the solution hereby proposed should be the most convenient one. == Scope == * Proposal owners: update SPEC file so that non-threaded libldap is replaced with threaded one. * Other developers: None. Issues should not occur. * Release engineering: [https://pagure.io/releng/issue/7253] ** List of deliverables: N/A * Policies and guidelines: None. * Trademark approval: (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Python 3.7 on its way to rawhide
by Miro Hrončok 02 Jul '18

02 Jul '18

The merge of the f29-python side tag into rawhide has started. Expect Python 3.7 in rawhide soon. If your package will have broken dependencies (on Python 3.6), rebuild it. If you cannot rebuild it due to dependencies not being rebuilt, (search and) open bugs. Make sure to block PYTHON37 [1] so we are aware of all the issues. [1] http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

F29 System Wide Change: Discontinue PPC64 as Alternative Architecture
by Jan Kurik 02 Jul '18

02 Jul '18

= Proposed System Wide Change: Discontinue PPC64 as Alternative Architecture = https://fedoraproject.org/wiki/Changes/DiscontinuePPC64 Owner(s): * Dan Horák <sharkcz at fedoraproject dot org> After a number of projects dropped support for the big endian ppc64 architecture and our move of ppc64 to "maintenance-only" mode few releases back, now a vital dependency, the Eclipse project, stops supporting ppc64. As a consequence we need to discontinue producing any ppc64 content. This is a long time anticipated step as the upstream focus on the little endian variant (ppc64le) on Linux is well known. My email [https://lists.fedoraproject.org/archives/list/ppc@lists.fedoraproject.org/m…] sent to the Fedora PPC mailing list has few more details. == Detailed description == Fedora will stop producing ppc64 content - binary rpms or composes. == Scope == * Proposal owners: synchronize with rel-engs * Other developers: none * Release engineering: #7602 [https://pagure.io/releng/issues/7602] changes in koji, bodhi and pungi configurations are expected ** List of deliverables: N/A * Policies and guidelines: none * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F29 System Wide Change: Fedora 29 Boost 1.67 upgrade
by Jan Kurik 02 Jul '18

02 Jul '18

= Proposed System Wide Change: Fedora 29 Boost 1.67 upgrade = https://fedoraproject.org/wiki/Changes/F29Boost167 Owner(s): * Jonathan Wakely <jwakely at fedoraproject dot org> This change brings Boost 1.67.0 to Fedora 29. This will mean F29 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 [https://fedoraproject.org/wiki/Changes/F22Boost158] and Fedora 23 Change [https://fedoraproject.org/wiki/Changes/F23Boost159] and Fedora 24 Change [https://fedoraproject.org/wiki/Changes/F24Boost160] and Fedora 26 Change [https://fedoraproject.org/wiki/Changes/F26Boost163] and Fedora 27 Change [https://fedoraproject.org/wiki/Changes/F27Boost164] and Fedora 28 Change [https://fedoraproject.org/wiki/Changes/F28Boost166]. == Scope == * Proposal owners: ** Build will be done with Boost.Build v2 (which is the upstream-sanctioned way of building Boost) ** Request a "f29-boost" build system tag (discussion [http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html]): 7278 (similar ticket for F28: https://pagure.io/releng/issue/7278) ** Build boost into that tag (take a look at the build #606493 [http://koji.fedoraproject.org/koji/buildinfo?buildID=606493] for inspiration) ** 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: #7595 [https://pagure.io/releng/issue/7595] ** 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 JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F29 System Wide Change: Zchunk Metadata
by Jan Kurik 02 Jul '18

02 Jul '18

= Proposed System Wide Change: Zchunk Metadata = https://fedoraproject.org/wiki/Changes/Zchunk_Metadata Owner(s): * Jonathan Dieter <jdieter at gmail dot com> * Neal Gompa <ngompa13 at gmail dot com> All dnf repository metadata will be compressed with the zchunk format rather than xz or gzip. == Detailed description == Currently Fedora's repository metadata is compressed using the xz and gzip formats. Zchunk is a new compression format designed to allow for highly efficient deltas. When Fedora's metadata is compressed using zchunk, dnf will download only the differences between any earlier copies of the metadata and the current version. == Scope == * Proposal owners: ** Package zchunk for Fedora ** Get the pull requests to enable zchunk in dnf, libdnf, librepo, libsolv and createrepo_c merged upstream *** https://github.com/rpm-software-management/librepo/pull/127 *** https://github.com/openSUSE/libsolv/pull/270 *** https://github.com/rpm-software-management/dnf/pull/1107 *** https://github.com/rpm-software-management/libdnf/pull/478 *** https://github.com/rpm-software-management/createrepo_c/pull/92 ** Create a new package for Fedora's zchunk dictionaries. * Other developers: Fedora Infrastructure needs to start creating zchunked metadata * Release engineering: #7600 [https://pagure.io/releng/issue/7600] ** List of deliverables: Zchunk repository metadata * Policies and guidelines: Packaging guidelines are not affected by this change. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP 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 July 2018