devel-announce June 2018

devel-announce@lists.fedoraproject.org

5 participants
30 discussions

Today we have reached the Submission deadline for Change proposals of Fedora 29 requiring mass rebuild
by Jan Kurik 19 Jun '18

19 Jun '18

Hi everyone! The submission deadline for Changes of Fedora 29 [1], requiring mass rebuild, takes effect today (on June 19th). All the Changes requiring mass rebuild sent for review are going to be moved to Fedora 30 release. The mass rebuild it self is planned on July 11th. 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: Rename Atomic Workstation to Silverblue
by Jan Kurik 19 Jun '18

19 Jun '18

= Proposed System Wide Change: Rename Atomic Workstation to Silverblue = https://fedoraproject.org/wiki/Changes/Silverblue Owner(s): * Matthias Clasen <mclasen at redhat dot com> The Atomic Workstation variant is being renamed to Fedora Silverblue. == Detailed description == The Atomic Workstation is being rebranded as Fedora Silverblue, to give this project more visibility and realize its full potential for bringing new users to Fedora. There is new website, www.teamsilverblue.org, which is gathering information and resources around this effort. == Scope == Concrete suggested changes: ** Change ostree repo branch name to fedora/29/x86_64/silverblue ** Change /etc/os-release to say Silverblue in the appropriate places ** Provide branding in fedora-logos package that says Silverblue ** Change install media name to Fedora-Silverblue-ostree-... * Proposal owners: ** Provide patches for /etc/os-release and fedora-logos * Other developers: ** Change lorax templates to refer to new branch name ** Change anaconda install media: https://github.com/rhinstaller/anaconda/issues/1504 ** Create a Silverblue install class in anaconda: https://github.com/rhinstaller/anaconda/issues/1505 ** Make necessary changes in pungi: https://pagure.io/pungi/issue/982 * Release engineering: #7579 [https://pagure.io/releng/issue/7579] ** List of deliverables: *** The Fedora Atomic Workstation iso will be renamed to Fedora-Silverblue-x86_64... *** The getfedora.org webpage will need corresponding adjustments * Policies and guidelines: No changes * 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 Self Contained Change: glibc 32 Build Adjustments
by Jan Kurik 19 Jun '18

19 Jun '18

= Proposed Self Contained Change: glibc 32 Build Adjustments = https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments Owner(s): * Florian Weimer <fweimer at redhat dot com> The glibc32 package is a special package used by gcc and a few other packages to work around the lack of RPM multilib repository support in Koji [https://pagure.io/koji/issue/273]. It is difficult to maintain, and the current approach raises questions regarding (L)GPL compliance. == Detailed description == Some packages build non-64-bit code on 64-bit architectures, using GCC switches such as "-m32" and "-m31". Those that do not use "-nostdlib" at the same time need a non-64-bit glibc as well. However, Koji cannot currently provide such multilib RPMs; all RPM packages are either of the build architecture or noarch packages. In particular, GCC has a dependency on the non-64-bit (32-bit or 31-bit) glibc library. The current hack to support GCC's need (and a few other packages) is that a separate package, glibc32, contains pre-built 32-bit/31-bit binaries extracted from RPMs built in Fedora some time in the past. Since these binaries are pre-built, they can be built (actually copied around) on any architecture, including the relevant 64-bit architectures. This primarily affects the x86_64 architecture and its i686 multilib RPMs. Historically, the same problem occurred on ppc64 (with ppc as the multilib architecture) and s390x (with s390). However, Fedora no longer builds non-64-bit RPM packages on these architectures. This also means that the ppc and s390 binaries in the glibc32 package can no longer be recreated within Fedora, which is not sustainable. At the very least, these two sets of binaries would have to be removed, effectively making the glibc32 package specific to the x86_64 architecture. It appears that on ppc64 we still need to build GCC in such a way that the "-m32" option is supported. This means that some cross-package coordination is necessary. (A first check showed that the s390x boot loader support is built as 64-bit binary, so "-m31" support in glibc does not seem to be necessary for bootloader purposes.) There are two ways to address these problems: * Continue the current copy-based approach. It is simplified somewhat due to the switch to libxcrypt. Modify the (fully manual) extraction procedure so that the source RPM of the binary files is included as well, to provide airtight LGPL compliance. * Build glibc32 and libgcc32 subpackages from the glibc and gcc packages, which are then filtered by pungi from all composes [https://pagure.io/releng/issue/7576]. (Currently, the buildroot-only nature of glibc32 is achieved by tagging builds appropriately in Koji, which is rather fragile.) The big advantage of this approach is that the glibc32 package will always be in sync with the actual 64-bit library. == Scope == * Proposal owners: ** Drop ppc and s390 RPM contents from glibc32. Adapt the build procedure as agreed. * Other developers: ** Fedora GCC developers will need to drop the build dependency on `/usr/lib/libc.so` on ppc64 and s390x. It may be necessary to configure GCC with "--enable-targets=all", to support "-m32" for building boot loaders and other freestanding code. ** The compat-gcc-* and ghdl packages may need similar adjustments. ** Other packages with a "/usr/lib/libc.so.6" build dependency (chromium, systemtap, valgrind) appear to restricted to x86_64 already. ** If the filtered subpackage approach is chosen for Fedora 29, the gcc package will need to be updated to build a new subpackage, libgcc32, that contains the multilib libraries. These will be required for building glibc32 as a subpackage. * Release engineering: #7578 [https://pagure.io/releng/issue/7578] ** 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 JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

[Action Required] Node.js 10.x and the Fedora 29 schedule
by Stephen Gallagher 18 Jun '18

18 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This message is directed at anyone who maintains a Node.js package in Fedora. On Friday, FESCo approved the Fedora 29 System-Wide Change to move the default Node.js interpreter to the 10.x LTS stream. This means that we will need to ensure that any NPM packages that are present in Rawhide must work on 10.x. What you need to do if == ... your current package works fine with both Node.js 8.x and 10.x == No action required. == ... your current package doesn't work with 10.x == A) It has an upstream release that does (or you can patch it to work) - - Prepare the upstream package and build it in Rawhide during the week of June 25th through the 29th. I will update the Node.js interpreter in Rawhide sometime on Friday, June 22nd so it will be in the buildroot. B) It cannot be made to work with Node.js 10.x at all - - If this package is still valuable to have when people are using the 8.x module stream, contact me directly and we will coordinate including it in the module. - - If this package is no longer useful, retire it by June 29th. -----BEGIN PGP SIGNATURE----- Version: Mailvelope v2.2.2 Comment: https://www.mailvelope.com wkYEAREIABAFAlsnm1oJEHolVWI2uqOjAAB7nQCgiuZkpu2fDDHM6F47I8GN nD81quEAoIJtHaqfWscpZ/ZfjVRobMa3/NM4 =F1U7 -----END PGP SIGNATURE-----

1 0

F29 System Wide Change: Build non-RELRO ELF binaries with .plt.got isolation
by Jan Kurik 18 Jun '18

18 Jun '18

= Proposed System Wide Change: Build non-RELRO ELF binaries with .plt.got isolation = https://fedoraproject.org/wiki/Changes/.plt.got_Isolation Owner(s): * Florian Weimer <fweimer at redhat dot com> Fedora 23 enabled hardening for all packages. However, some ELF binaries still use lazy binding. This change proposes additional hardening for them. == Detailed description == With the RELRO and BIND_NOW dynamic linker features, it is possible to make the array of function pointers which is used to implement dynamic linking (the GOT) read-only at run time. This makes it harder for exploit writers to overwrite these function pointers and redirect execution. However, some ELF binaries are still built and linked without these hardening features. Sometimes, this is due to package maintainer preferences. Sometimes, there are technical reasons which preclude the use of BIND_NOW because the way the application is written, it relies on lazy binding. This change proposes to link ELF binaries in such a way that the <code>.plt.got</code> section is loaded as a separated page at run time. As a result, it is possible to use a kernel feature called [http://man7.org/linux/man-pages/man7/pkeys.7.html memory protection keys] to make the GOT with its function pointer array read-only most of the time. When the dynamic linker needs to perform a function symbol binding, it can make the GOT temporarily writable, for the current thread only. Memory protection keys are currently available with the POWER architecture (starting with POWER7), and on select Intel server CPUs. At this time, only a subset of Fedora systems will benefit from this hardening, so the recommendation to link with RELRO/BIND_NOW remains. == Scope == * Proposal owners: ** We will work with the binutils maintainer to implement this change in the linker, and enable it by default. (RELRO/BIND_NOW will automatically disable it because it is not needed there.) ** The glibc dynamic linker will be updated to use this new feature. This feature will likely arrive after the glibc 2.28 upstream release, but it can be backported to Fedora because there is no ABI impact. * Other developers: In the unlikely case that an application relies on GOT patching, it will have to specify a linker flag to disable this security hardening. * Release engineering: https://pagure.io/releng/issue/7575 #7575 (no release engineering impact is expected) ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: The packaging guidelines regarding build flags will not be updated. RELRO/BIND_NOW remains the recommended approach. * 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

New FESCo Meeting Time and Ticket Policy
by Stephen Gallagher 17 Jun '18

17 Jun '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 At today's FESCo meeting, we selected a new meeting time to accommodate the schedules of the newly-elected members. As such, FESCo meetings for the next cycle will be taking place on Mondays at 1500 UTC (1100 EDT, 1700 CEST). However, in the interest of having shorter and possibly less-frequent meetings, FESCo has opted to change its policy regarding ticket-handling, effective immediately. The new policy is as follows: * Most FESCo votes will be performed in the tickets. FESCo members will have one week[1] from the creation of the ticket to vote. So long as at least three members have voted, the majority of votes at the end of that week will be counted as the result. If three votes are not received in the first week, voting will be extended by one additional week and the minimum required responses reduced to a single vote. If by the end of that second week no votes have been counted, it will be treated as a vote *against* any change requested by the reporter, thus preserving the current status however it stands. We do not expect this clause to ever be invoked. * Within the voting period, any FESCo member may add the 'meeting' keyword if they believe that a proper decision will require in-person discussion in a meeting. That topic will then be added to the agenda for the next regularly scheduled meeting. No meeting will be held if there are no agenda items listed by noon UTC of the preceding business day. -----BEGIN PGP SIGNATURE----- Version: Mailvelope v2.2.2 Comment: https://www.mailvelope.com wkYEAREIABAFAlsj8jYJEHolVWI2uqOjAACxgwCfY/59iYVCDUmPgZKShaz8 d9ikSpQAn3m1b6IPrsaWTUNeB3PoWL+t+Zsl =BdWE -----END PGP SIGNATURE-----

1 0

[Guidelines change] Changes to the packaging guidelines
by Jason L Tibbitts III 15 Jun '18

15 Jun '18

Here are the recent changes to the packaging guidelines. ----- In Fedora 28 (and rawhide), the texinfo scriptlets (which call install-info) are no longer necessary and should be removed or, for cross-release specfiles, wrapped in conditionals. Note that there are nearly 300 specs currently calling install-info in scriptlets; lists of these packages will be posted separately to the devel list. * https://fedoraproject.org/wiki/Packaging:Scriptlets#Texinfo * https://pagure.io/packaging-committee/issue/773 ----- The section of the Python packaging appendix relating to manual byte compilation has been amended with a new section applying to Fedora 29 and newer only. Because this is a rarely-trafficked section of the guidelines and the change mandates modifications to a number of packages, I will summarize here: If your package installs files with names ending in ".py" outside of the standard directories for python files (/usr/lib(64)?/python\d.\d) then in rawhide you must disable automatic byte compilation of files outside of these directories by adding "%global _python_bytecompile_extra 0" to your spec and then, if necessary, manually byte-compile those files with a specific python version using the %py_byte_compile macro. There are 479 packages which will need attention to fix this before the default value of %_python_bytecompile_extra becomes 0 (and potentially breaks many of those packages) in a future release. Lists of these packages will be posted separately on the devel list. * https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compil… * https://pagure.io/packaging-committee/issue/772 ----- A new guideline page relating to package deprecation has been added, and both the main guidelines and review guidelines have been updated to reference it. * https://fedoraproject.org/wiki/Packaging:Deprecating_Packages * https://fedoraproject.org/wiki/Packaging:Guidelines#Deprecating_Packages * https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Things_To_Check_O… * https://pagure.io/packaging-committee/issue/723

1 0

F29 System Wide Change: Binutils 2.31
by Jan Kurik 14 Jun '18

14 Jun '18

= Proposed System Wide Change: Binutils 2.31 = https://fedoraproject.org/wiki/Changes/BINUTILS231 Owner(s): * Nick Clifton <nickc at redhat dot com> Rebase the binutils package from version 2.30 to version 2.31. == Detailed description == Switch the binutils package from being based on the 2.30 release of the FSF binutils to being based on the 2.31 release. This release will bring in numerous bug fixes, as well as the following new features: The linker can now put all code and read-only data sections into a separate segment with only READ and EXECUTE permissions. All writable data can be placed into a separate segment with READ and WRITE permissions. This makes programs larger, but safer. The linker's behaviour can be controlled via a command line option, and the default set by a configure option. The assembler can generate build notes for any input files which do not contain their own notes. Again this is controlled via a command line option whose default is set by a configure option. The x86 assembler supports a new -O[2|s] command-line option to enable alternate, shorter instruction encoding. It also supports a ,nop pseudo-op to simplify the insertion of NOP instruction sequences. The AArch64 assembler will now warn a combintation of an instruction and a register name are invalid. The AArch64 disassembler will now also flag inconsistent instruction encodings. The "ar" program will now accept an "O" modifier to its command line, which causes the offsets of members within the archive to be displayed alongside the other information. == Scope == * Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed.This should be followed by a mass rebuild in order for the changes to be noticed across the system. * Other developers: No other work should be necessary. Once the rebase is in place and the buildroot contains the new binutils its use should be automatic.It is possible that the new linker feature might prove to be problematic forsome packages, although no such problems are anticipated. If this doeshappen however the package maintainers can add a command line optionto disable the new linker feature. * Release engineering: https://pagure.io/releng/issue/7573 ** List of deliverables: Just the binutils package. * Policies and guidelines: No updates needed. * 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: Make BootLoaderSpec the default
by Jan Kurik 14 Jun '18

14 Jun '18

= Proposed System Wide Change: Make BootLoaderSpec the default = https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault Owner(s): * Javier Martinez Canillas <javierm at redhat dot com> * Peter Jones <pjones at redhat dot com> Use BootLoaderSpec fragment files by default to populate the bootloaders boot menu entries. == Detailed description == The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ Boot Loader Specification (BLS)] defines a scheme and file format to manage boot loader configuration for each boot option in a drop-in directory, without the need to manipulate bootloader configuration files. These drop-in directories are the standard on Linux nowadays, so the goal is to also extend this concept for boot menu entries. This is especially important in Fedora because the same bootloader is not used in all architectures. GRUB 2 is used in most of them, but there are others such as zipl for s390x and Petitboot for ppc64le. Not all bootloaders have the same configuration file format, so there is a need for an indirection level and per bootloader specific logic to edit these configuration files, when adding or removing a boot entry. The current component that does this work is grubby, that has support for all the different bootloader configuration file formats and manipulates them on kernel installation or uninstallation. Besides manipulating the bootloader configuration files, grubby also does other things like running dracut to create an initial ramdisk image. Fedora already has a lot of infrastructure in place to not require modifying bootloader configuration files for boot menu entries. The BootLoaderSpec and drop-in BLS fragments can be used instead, and the kernel-install script can do any additional task that is currently done by grubby. The kernel-install script has a pluggable design that uses a drop-in directory for scripts to extend its functionality. So if needed, any bootloader specific logic can be implemented as kernel-install scripts. With this setup the bootloader configuration could be static and not modified after installation. The missing piece was the lack of BLS support on all the supported bootloaders, but all of them have support to parse BLS fragments now. So we can default to install BLS files on kernel installation and drop grubby. == Scope == * Proposal owners: ** Generate BLS snippets at kernel build time and ship in the kernel packages. ** Make kernel-install scripts to copy the BLS, kernel and initramfs images and do any architecture specific task. ** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot menu entries from the information in BLS files. ** Have a grubby wrapper for backward compatbility that manipulates BLS files. ** Modify packages that use grubby to instead install BLS fragments (memtest86+, tuned). ** Make sure this is all properly documented in release-notes, etc. * Other developers: ** The anaconda developers will need to review and merge the patches to change the default to BLS. ** Test and watch for regressions. * Release engineering: RelEng review ticket: https://pagure.io/releng/issue/7572 ** List of deliverables: N/A * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: No changes needed. -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

FESCo Elections - May 2018 : Results announcement
by Jan Kurik 14 Jun '18

14 Jun '18

Greetings, all! The elections for FESCo - May 2018 have concluded, and the results are shown below. FESCo is electing 4 seats this time. A total of 86 ballots were cast, meaning a candidate could accumulate up to 430 votes (86 * 5). The results for the elections are as follows: # votes | name - --------+---------------------- 290 | Till Maas (till/tyll) 286 | Stephen Gallagher (sgallagh) 254 | Randy Barlow (bowlofeggs) 234 | Petr Šabata (contyk/psabata) - --------+---------------------- 231 | Justin Forbes (jforbes) Congratulations to the winning candidates, and thank you all candidates for running this elections! For more information please check the Voting App: https://admin.fedoraproject.org/voting/about/fesco-may-2018 -- 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 June 2018