devel-announce August 2018

devel-announce@lists.fedoraproject.org

4 participants
14 discussions

Fedora 29 Beta Freeze
by Mohan Boddu 28 Aug '18

28 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

Fedora 30 System-Wide Change proposal: Mass Python 2 Package Removal
by Ben Cotton 20 Aug '18

20 Aug '18

https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal == Summary == (Sub-)packages only providing python2 importable modules without additional functionality will be removed from Fedora unless some other package(s) depends on them. Python 2 will be deprecated in Fedora. Packagers can mark any other Python 2 packages as deprecated as well. == Owner == * Miro Hrončok (Churchyard) * Petr Viktorin (Pviktori) * Charalampos Stratakis (Cstratak) * Zbigniew Jędrzejewski-Szmek (Zbyszek) * Igor Gantenko (Ignatenkobrain) * Neal Gompa (Ngompa) == Detailed Description == Python 2 reaches End of Life on 2020-01-01. Its current maintainers would like to orphan it before that date, and so far no one else has stepped up to maintain Python 2 (with the full ecosystem) past 2020. Since thousands of packages still depend on python2, we need a more careful approach than normal orphaning. Some of those packages are abandoned and/or the Python 2 version is unnecessary. Others are useful and just need more time to port to Python 3. Hence we set up criteria for python2 packages that can remain in the distribution and we remove everything else. This should allow us to keep python2 for limited use, not break everything, but should also send a strong message that it is no longer a first class citizen, and filter packages we need to focus Python 3 porting efforts on. (Sub-)packages that only provide a python2 importable module, and are not required for other packages, will be removed. Examples of situations where a (sub-)package does not provide only the importable module: * A package also provides an application, mostly likely in /usr/bin, /usr/libexec... ** (Note that according to current guidelines, if the Python 3 version of a package provides the same functionality, the Python 3 package should provide the application.) ** (In certain situations the provided application is only useful to boostrap or manage projects using the module. Such applications don't count.) * A package provides a plugin for another application, most likely trough a setuptools entrypoint interface or some custom location on disk. Our process will be: * File bugs for all packages that look like they only provide a Python 2 importable module. (This includes those needed by other packages we plan to remove.) * Leave at least a week for packagers to respond to the bugs. * If the packager approves or there is no response for a week, we will remove the package. There are currently ~3000 source packages that generate python2 dependent RPMs. Automation is being created to be able to provide us a rough list of packages to remove. === Packages to remove === The list is at https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List not to disturb the reading experience of this page. Packagers can block some packages from removal by responding on Bugzilla and providing reasons. If no general consensus is reached, FESCo will decide (as Python SIG does not have a formal process for such decisions). We'll also actively try to remove unused or optional dependencies to reduce the number of packages that need to be kept because other packages depend on them. As dependencies evolve over time, we will regularly repeat this proces on rawhide from now on even on future releases. Packagers are strongly encouraged to help port their applications to Python 3. Removing old Python 2 only applications from Fedora is also encouraged, especially if the upstream is dead. Python SIG is available to help with porting. Packaging guidelines will be updated to reflect that packaging for Python 3 only is the default. Instructions for Python 2 and dual-support will be moved to the Appendix. Python 2 will be marked deprecated (see https://fedoraproject.org/wiki/Packaging:Deprecating_Packages) Any package that only provides a Python 2 importable module may be marked as deprecated as well if the maintainer(s) want to. == Benefit to Fedora == A giant pile of unneeded software running on a legacy interperter will be removed from Fedora before the interpreter stops being supported upstream. While we would very much like to remove Python 2 entirely, this way we are not breaking Fedora, and we can accomodate some exceptions. == Scope == * Proposal owners: ** Provide a list of packages to remove ** Collect feedback from affected packagers ** Retire the python2 only packages ** Remove python2 subpackages from dual-python packages * Other developers: ** Ask for packages to be removed from the list if needed (with reasons). ** Remove python2 subpackages from dual-python packages (not needed, but helpful) ** Optionaly mark remainign python2 packages deprecated * Policies and guidelines: ** Python packaging guidelines will be changed to only describe Python 3 ** Python 2 and dual-support packaging will be moved to the appendix ** Only packages providing additional features different than importable modules will be allowed to be added in Fedora (with exception for dependenecies of other packages) ** Python 2 will be marked deprecated https://fedoraproject.org/wiki/Packaging:Deprecating_Packages * Trademark approval: not needed for this Change == Upgrade/compatibility impact == Packages removed form Fedora repos will remain on the installed OS until explicitly removed by the user or obsoleted by the packagers. We'll only obsolete packages that would break upgrade (from fedora-obsolete-packages). == How To Test == Any program written in Python and any program that has Python plugins could potentially be influenced by this change. Testing is different for software that is still using Python 2 and for software that has been switched to Python 3. For any ''python2'' programs, make sure those programs are still functional after the package removal. Since various packages that are no longer built will not be removed from an existing system, just upgrading and checking packages is not enough. Either a new installation should be used, or after a branching point, any packages which haven't been rebuilt for F30, so any packages with .fc29 or lower release suffix should be removed from the system before testing. For the ''python3'' programs, install all upgrades and check if the software works. Upgrade failures because of missing dependencies should be treated as bugs. Any removed python2 subpackages which break upgrades need to be added to Obsoletes in fedora-obsolete-packages. == User Experience == There will be less Python 2 RPMs in Fedora repos. Users are encouraged to switch to Python 3 and/or use Python 2 virtual environments and pip for development. == Dependencies == Ideally, all programs that use python2 would be switched to use python3. Although we don't expect everything to be switched over, as much as possible should be, so that the set of remaining python2 subpackages is as small as possible. == Contingency Plan == * Contingency mechanism: ** If for some reason not everything is removed, nothing happens, it can be removed later. If for some reason something breaks, some packages can be unretired or restored. ** If someone steps up to maintain Python 2 (including the full ecosystem of packages now in Fedora), they can decide to discontinue removing packages, revert the Change, or come up with another plan. (Note that in this case, current maintainers will most likely orphan many fundamental python2 packages.) == Documentation == This page is the main documentation. Also see: https://pythonclock.org/ -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

Fedora Copr can now flag commits and pull requests from src.fp.o
by Michal Novotny 20 Aug '18

20 Aug '18

Hello, in addition to auto-rebuilding feature from Fedora DistGit ( src.fedoraproject.org) we have added possibility to flag commits and pull requests after an auto-rebuild. This works not only with Fedora DistGit but with any pagure instance (e.g. also https://upstreamfirst.fedorainfracloud.org/ or just pagure.io). The setup for your Copr project is just a few simple steps. See the documentation here: https://docs.pagure.org/copr.copr/user_documentation.html#pagure-integration or you can just also follow instructions present in Settings->Integrations in your Copr project. Everything needed is there as well. Please, enjoy Copr team

1 0

Fedora 29 Mass Branching
by Mohan Boddu 14 Aug '18

14 Aug '18

Hi All, Fedora 29 has now been branched, please be sure to do a git pull --rebase to pick up the new branch, as an additional reminder rawhide/f30 has been completely isolated from previous releases, so this means that anything you do for f29 you also have to do in the master branch and do a build there. There will be a Fedora 29 compose ASAP and it'll appear http://dl.fedoraproject.org/pub/fedora/linux/development/29/ <http://dl.fedoraproject.org/pub/fedora/linux/development/28/> once complete. Please be sure to check it out. Bodhi is currently not active for Fedora 29, it will be enabled in couple of weeks time when we hit Beta change freeze point in the Fedora 29 schedule[1]. Mohan Boddu. [1] https://fedoraproject.org/wiki/Releases/29/Schedule

1 0

Fedora 29 Change Checkpoint: Completion deadline (testable)
by Ben Cotton 07 Aug '18

07 Aug '18

Greetings! In on week, on 2018-08-14, we will reach Fedora 29 Change Checkpoint:Completion deadline (testable) [1]. At this point, all accepted changes [2] should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes [3] will be reported to FESCo on 2018-Aug-23 meeting. Contingency plans for System Wide Changes in case of serious doubts regarding Change completion, will be activated. [1] https://fedoraproject.org/wiki/Releases/29/Schedule [2] https://fedoraproject.org/wiki/Releases/29/ChangeSet [3] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&… -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce August 2018