devel-announce August 2018

devel-announce@lists.fedoraproject.org

4 participants
14 discussions

Fedora 29 Beta Freeze
by Mohan Boddu 27 Aug '18

27 Aug '18

Hi all, Today's an important day on the Fedora 29 schedule[1], with several significant cut-offs. First of all today is the Bodhi activation point [2]. That means that from now all Fedora 29 packages must be submitted to updates-testing and pass the relevant requirements[3] before they will be marked as 'stable' and moved to the fedora repository. Today is also the Beta freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Beta composes. Other builds will remain in updates- testing until the Beta release is approved, at which point the Beta freeze is lifted and packages can move to 'stable' as usual until the Final freeze. Finally, Today is the '100% code complete deadline' Change Checkpoint[5], meaning that Fedora 29 Changes must now be code complete, meaning all the code required to enable to the new change is finished. The level of code completeness is reflected as tracker bug state ON_QA. The change does not have to be fully tested by this deadline'. Finally, today is also the Software String freeze[7], which means that strings marked for translation in Fedora- translated projects should not now be changed for Fedora 29. Mohan Boddu [1] https://fedoraproject.org/wiki/Releases/29/Schedule [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release [4] https://fedoraproject.org/wiki/Milestone_freezes [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy

1 0

Fwd: fedora-tagger sunset - week post F29 beta freeze
by Clement Verna 24 Aug '18

24 Aug '18

Dear all, The Fedora Infrastructure is running the fedora-tagger [0] service, however it gets little usage and also has no one really maintaining it or fixing issues with it. Earlier this year [1] we have tried to support community members who expressed their interests in maintaining this application, unfortunately this effort did not results in a new version being released. During our last meeting [2], we agreed to retire this service a week after the end of the F29 beta freeze (see F29 schedule [3]). Once the F29 beta freeze is over, we will communicate a sunset date. Regards, Clément [0] - https://apps.fedoraproject.org/tagger/ [1] - https://communityblog.fedoraproject.org/maintainers-package-tagger/ [2] - https://meetbot.fedoraproject.org/teams/infrastructure/infrastructure.2018-… [3] - https://fedoraproject.org/wiki/Releases/29/Schedule?rd=Schedule

1 0

copr-frontend: fix for webhook secrets leakage
by Michal Novotny 23 Aug '18

23 Aug '18

Hello, there have been security problem fixed in copr-frontend today. Basically by forking, you could get to webhook secrets of an original project being forked. Also the integration page where you can insert pagure api token was actually available under certain URL if you knew how this URL should be structured. Both of these problems are now fixed. See full details here: https://lists.fedoraproject.org/archives/list/copr-devel@lists.fedorahosted… We will do full security audits now to prevent any future problems like this. Sorry for this trouble Copr team

1 0

Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages
by Ben Cotton 22 Aug '18

22 Aug '18

https://fedoraproject.org/wiki/Changes/Remove_Group_Tag == Summary == Remove the Group: tag from over 9000 source packages. == Owner == * Name: Jason Tibbitts (tibbs) * Email: tibbs(a)math.uh.edu == Detailed Description == I will remove the Group: tag from all specfiles in Fedora dist-git which still have it, verify that the result is syntactically correct, then commit and push the change. Since this is a relatively minor changeI am not planning to bump Release: or add %changelog entries, but I do that if it is deemed necessary. I am proposing this as an official change instead of just doing it (as with other low risk packaging cleanups) because: * It would be by far the largest mass package change we would ever have attempted. * It does technically cause a visible change in the resulting package. If queried, rpm will show the group as "Unspecified" for every binary package in the distribution instead of just the majority of them. It is theoretically possible that someone could have a tool which uses this information, although that tool most already be mostly useless. * People would yell at me even more loudly if I posted the full 9000+ package and maintainer listing. Since this changes many, many packages and has small but nonzero end user visibility I am filing this as a system-wide change. == Benefit to Fedora == 9420 source packages (43% of the total count) come closer to compliance with Fedora's packaging guidelines. The Group: tag has been in a "should not use" state since March of 2017. More useless cruft is removed from specfiles. This provides a slight benefit to ease of maintenance and eliminates yet another bizarre historical relic which confuses new packagers. Cargo cult behavior is rampant and removing the cruft in one go will be another step towards having system-wide clean specfiles. The Group: tag is not required in any live Fedora or EPEL release. RHEL5 did need it, but EPEL5 did not as it was supplied automatically via magic in the epel-rpm-macros package. The [[Packaging:Guidelines#Tags_and_Sections|Packaging Guidelines]] have indicated that the Group: tag should not be used since March of 2017. The tag is not used by Fedora currently; the concept was replaced long ago by comps which permits a far more flexible classification of packages. dnf has a "group" subcommand but this operates on comps groups, not anything defined by the Group: tag. dnf does not display information from Group: tag. If a package does include a Group: tag, a direct rpm query will display it but otherwise will show "Unspecified". There was never any strong standard for the contents of the Group: tag. Older versions of rpm (still present in RHEL7 but not in any live Fedora release) contained a documentation file named GROUPS with a list and rpmlint would check this, but it was never strongly adhered to. The current package set has some quality examples like a Group tag containing the string "Group:" and one containing only "evelopment/Languages". It seems relatively obvious that nobody is paying attention or making use of that data. Among the tags which are at least in the recommended set which rpm used to have, most do not convey particularly useful information. Of the Group: tags which remain, 5438 contain "Development/Libraries", 1871 have "System Environment/Libraries" and 1346 are "Development/Languages". == Scope == * Proposal owners: Whip up a quick script, test it well to ensure that it doesn't have unintended side effects, and handle outliers or special cases manually. Then wait a few hours to push commits to 9000+ repositories. * Other developers: Nothing besides dealing with any commit emails they receive. * Release engineering: There should be no releng involvement. There is no real need for any packages to be rebuilt. If there is an F30 rebuild scheduled, it would be advantageous for this change to be made before that happens. I filed [https://pagure.io/releng/issue/7627] in any case. ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: There should be no change to deliverables besides the fact that the packages no longer have Group: tags. * Policies and guidelines: This is implementing a requirement of the current packaging guidelines. The specific change mandating this happened in March of 2017. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == There is no effect on upgrades. Packagers have always been free to remove Group: tags, even within a stable release. This will simply result in the rest of them going away. == How To Test == There is not much to test. The change is simple and so if done with a modicum of care it will not cause syntax errors in the packages. Testers and maintainers can of course do local or koji builds after the changes have been pushed to ensure that there are no problems, and rpm -qip run on the resulting binary packages should only show Group: tags of "Unspecified". == User Experience == There should be no change to the end user experience unless there is an expectation that the Group: tags of the changed packages will show something other than "Unspecified". == Dependencies == There are no dependencies. == Contingency Plan == If there is some issue, it is simply possible to do nothing, or to change only a subset of packages. If changes are committed and it turns out that there is some unforeseen negative effect, the changes can simply be reverted. * Contingency mechanism: Either do nothing, or revert the changes in the unlikely event that they cause issues. * Contingency deadline: Before the mass rebuild. * Blocks release? No * Blocks product? N/A == Documentation == The process is generally obvious and should not require much in the way of involvement of anyone else. == Release Notes == There should be no need to note this change in any release notes, as it is merely the completion of a change which has been ongoing since the time of Fedora 12. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Fedora 30 System-Wide Change proposal: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE
by Ben Cotton 22 Aug '18

22 Aug '18

https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition == Summary == Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI. == Owner == * Name: Carlos O'Donell (codonell) * Email: carlos(a)redhat.com == Detailed Description == IBM has designed a new long double ABI that adheres to the 128-bit IEEE format. This format is more standard than the existing AIX double-double or IBM long double (2 grouped 64-bit doubles) which has discontinuous mantissas and is difficult for developers to use. In Fedora 29 the plan is to switch to the new ABI for long double, while still supporting old applications via compatibility symbols. Newly compiled applications use either the old or new ABI but not a mix of both. Changes are required in the core C libraries, and the compiler and the compiler runtimes including the C++ standard libraries. Therefore there is coordination required across the core toolchain componenents e.g. gcc, binutils, glibc, gdb (to debug the new types). == Benefit to Fedora == Fedora developers will be using a standard 128-bit IEEE format for long double instead of the non-standard double-double AIX format which has a discontinuous mantissa and multiple representations for the same value. == Scope == The change is relatively limited in that not many packages use the long double floating point ABI. The double floating point ABI is much more used, but not long double. It is estimated that few packages use long double directly, and those packages will need to be rebuilt in order to use the new ABI. This rebuilding can be targetted by analyzing which packages have long double usage in their debug information and rebuilding just those packages. However, we plan to just use the existing mass rebuild for glibc 2.29 to handle this issue. * Proposal owners: Transition glibc to float128 format for long double for IBM ppc64le. Transition gcc to the default for long double. Implement support for the new <code>long double</code> format in libstdc++. Ensure gdb can handle the new types. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 30 branch. * Release engineering: A mass rebuild request has been filed for the parent system-wide change to upgrade glibc to 2.29<br>[https://pagure.io/releng/issue/7475 #7475] * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: Not needed for this change == Upgrade/compatibility impact == The library and language runtimes are backwards compatible with the version shipped in Fedora. We fully expect to fix all packaging changes in Fedora Rawhide first when everything is ready. == How To Test == The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has 2500+ tests that run to verify the correct operation of the library. In the future we'll also be running the microbenchmark to look for performance regressions as well as behavioural ones. Specific testing for 128-bit IEEE long double ABI will be carried out by the glibc testsuite. Integration smoke testing will be carried out by the glibc developers to make sure new applications are built with the correct defaults and work as expected. Specific testing for 128-bit IEEE long double ABI will be carried out by the gcc testsuite. Specific smoke testing will be carried out using gdb to read and write the new types. == User Experience == Users will see a new 128-bit floating point ABI, but this will largely be transparent to them. On POWER hardware that supports 128-bit long double in hardware the compiler will use the hardware transparently to accelerate floating point operations, otherwise software floating point emulation will be used. == Dependencies == This change requires coordination of glibc and gcc to change the compiler defaults and build the compiler language runtimes correctly. Also gdb must be able to support the new type to make the process of transition seamless. == Contingency Plan == * Contingency mechanism: Ship glibc 2.28 instead of glibc 2.29, or ship glibc 2.29 without this feature if it is not ready. * Contingency deadline: Final mass rebuild before Fedora release. * Blocks release? Upgrading glibc does block the release. We should not ship without the float128 ABI change. == Documentation == The glibc/gcc manual contain the documentation for the release and don't need any more additional work. == Release Notes == * The ppc64le architecture changed the format of the <code>long double</code> type to binary128. (Previously, a pair of two doubles was used.) -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot
by Ben Cotton 22 Aug '18

22 Aug '18

https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buil… == Summary == glibc-minimal-langpack is added to @Buildsystem group and installed into the minimal buildroot instead of glibc-all-langpacks. Packages which need more locales than plain C/C.UTF-8/POSIX need to pull them in through BuildRequires. == Owner == * Name: Zbigniew Jędrzejewski-Szmek (zbyszek) * Email: zbyszek(a)in.waw.pl == Detailed Description == Right now glibc-all-langpacks is installed in buildroots (mock, koji, …). It is 24 MB, out of the total of 145 MB. Replacing it with glibc-minimal-langpack, which has negligible size, decreases the buildroot size by 17%. glibc Requires glibc-langpack, and Suggests glibc-all-langpacks, so it gets installed automatically to satisfy that dependency. If a different package providing glibc-langpack is installed, glibc-all-langpacks is skipped. This change is basically adding glibc-minimal-langpack to @Buildsystem in comps and fixing any fallout in packages. A quick grep over spec files reveals: ``` $ rg -l 'LC_CTYPE=[^C]' *.spec | wc -l 11 $ rg -l 'LC_ALL=[^C]' *.spec | wc -l 42 ``` that there are at least ~50 packages which need adjustment. They can be either switched over to C.UTF-8 or a BuildRequires can be added. == Benefit to Fedora == The minimal buildroot becomes smaller, making builds slightly faster. == Scope == * Proposal owners: ** adjust comps ** fix packages which can be identified without rebuilding (see grep output above) ** fix fallout in the mass rebuild if anything is missed above * Other developers: report breakage and/or fix their own packages * Release engineering: [https://pagure.io/releng/issue/7610 #7610] * Policies and guidelines: no changes needed (The Packaging Guidelines already specify that all necessary dependencies must be declared using BuildRequires.) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This only affect package building process, so it has no end-user impact. == How To Test == Verify that packages still build after the comps change. == User Experience == Not visible to end-users. == Dependencies == None. == Contingency Plan == Revert the comps change. Any changes in packages would be backwards compatible, so there's no need to revert them. There is also no need to rebuild any packages already successfully built. * Contingency mechanism: remove glibc-minimal-langpack from @Buildsystem * Blocks release? not directly, but if packages fail to build, it would be problem * Blocks product? no == Documentation == None -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Fedora 30 Self-Contained Change proposal: No more automagic Python bytecompilation (phase 2)
by Ben Cotton 22 Aug '18

22 Aug '18

https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila… == Summary == See https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila… Now we are changing the default to be <code>%global _python_bytecompile_extra 0</code>. == Owner == * Name: Miro Hrončok (Churchyard) * Name: Petr Viktorin (pviktori) * Email: mhroncok(a)redhat.com, pviktori(a)redhat.com == Detailed Description == See thed etailed Description of the previous Change Proposal: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila… We will now set <code>%_python_bytecompile_extra</code> to <code>0</code> by default. All packages that ship Python 3 bytecode outside of Python 3 directories should be preferably converted to use <code>%py_byte_compile</code>, but if they are not, it's fine. We'll check all pyc/pyo files shipped by packages. We'll check if those are explicitly compiled using <code>%py_byte_compile</code>. If not, we mass push `%global _python_bytecompile_extra 1` to the package specs to make them work. It's up the package maintainers to adjust the package to the new style (or keep the line forever). == Benefit to Fedora == See https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila… == Scope == * Proposal owners: Change the default, slightly change the guidelines, get the list of packages, push the change into them. * Other developers: Maintainers of python3 packages are encouraged to change their packages to use explicit <code>%py_byte_compile</code> (not a System Wide Change, they don't have to do anything). * Policies and guidelines: will be changed as described in description == Upgrade/compatibility impact == None expected. == How To Test == N/A == User Experience == The users of this change are packagers. The new behavior should make byte-compilation more obvious, explicit, and discoverable. Users of Fedora should not feel this (except if this change uncovers a packaging bug). == Contingency Plan == * Contingency mechanism: we'll finish the change later (not a System Wide Change) == Documentation == The guidelines will be the documentation. == Release Notes == This change does not deserve Release Notes, it is not user facing. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error
by Ben Cotton 22 Aug '18

22 Aug '18

https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error == Summary == The <code>/usr/lib/rpm/redhat/brp-mangle-shebangs</code> buildroot policy script will be changed to make the build fail when it sees an ambiguous python shebang, such as <code>#!/usr/bin/python</code> or <code>#!/usr/bin/env python</code>. (The script has been warning in these cases for 2 Fedora releases already, saying ''This will become an ERROR''.) == Owner == * Name: Miro Hrončok (churchyard) * Email: <mhroncok(a)redhat.com> == Detailed Description == The buildroot policy script in <code>/usr/lib/rpm/redhat/brp-mangle-shebangs</code> currently changes all python shebangs to python2 with a message like: *** WARNING: mangling shebang in /usr/bin/taskotron_result from #!/usr/bin/python to #!/usr/bin/python2. This will become an ERROR, fix it manually! We will change it to: *** ERROR: ambiguous python shebang in /usr/bin/taskotron_result: #!/usr/bin/python. Change it to python3 (or python2) explicitly. The script will exit with nonzero exit code, rendering the build failed. The warning and a promise of the error was there for 2 releases (28 and 29). Taskotron check was also present. There are standard mechanics to avoid this buildroot policy script or to block certain files form it. Those remain intact by this change. For details see https://fedoraproject.org/wiki/Packaging:Guidelines#Shebang_lines and https://fedoraproject.org/wiki/Packaging:Guidelines#BRP_.28BuildRoot_Policy… sections of the packaging guidelines. == Benefit to Fedora == Packagers will be notified by build error if they accidentally have python2 shebangs (and python2 dependency) they didn't anticipate. It's up to them to decide what to do with such files, no automation can know. == Scope == * Proposal owners: change the script, change Python Packaging Guidelines (https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes) * Other developers: fix their packages if they fail because of this * Policies and guidelines: Adjust Python Packaging Guidelines (https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes) slightly. * Trademark approval: N/A (not needed for this Change) == How To Test == Have an RPM package that tries to ship files with ambiguous python shebang. Observe the warning on Fedora 29 and the error on Fedora 30. == User Experience == Users should not notice this, expect there might be less unneeded python2 dependencies created by accident. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Reminder: Beta freeze and code complete deadline in one week
by Ben Cotton 21 Aug '18

21 Aug '18

According to the Fedora 29 schedule[1], the 100% code complete deadline[2] for Changes is Tuesday, 28 August. The beta freeze[3] takes effect on this date as well. All Changes should be in "ON_QA" state by then. [1] https://fedoraproject.org/wiki/Releases/29/Schedule [2] https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_100.25_cod… [3] https://fedoraproject.org/wiki/Milestone_freezes -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Fedora 30 schedule approved
by Ben Cotton 21 Aug '18

21 Aug '18

The Fedora 30 schedule was approved by FESCo. Highlights are available on the wiki[1], with the full schedule — including subproject-specific tasks and milestones — on fedorapeople.org[2]. The schedule structure is largely the same with a few key changes: * Proposed Changes that require changes to Fedora infrastructure now have an explicit deadline pinned to 4 weeks before the start of the mass rebuild window. * Election nominations and questionnaire development will occur in parallel to allow time for Marketing to record and publish a Fedora Podcast episode with candidates. Prior to the development of the Fedora 31 schedule, I will work with subprojects to evaluate the existing milestones for relevance and accuracy. In the meantime, if you have any questions or suggestions you can email me or join the weekly FPgM Office Hours on Wednesday at 1300 UTC in #fedora-meeting. [1] https://fedoraproject.org/wiki/Releases/30/Schedule [2] https://fedorapeople.org/groups/schedule/f-30/f-30-all-tasks.html -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce August 2018