devel August 2018

devel@lists.fedoraproject.org

200 participants
269 discussions

F29 System Wide Change: OpenLDAP without Non-threaded Libraries
by Jan Kurik 04 Mar '19

04 Mar '19

= 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

5 9

F29 System Wide Change: Remove Excessive Linking
by Jan Kurik 18 Feb '19

18 Feb '19

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

11 17

Fedora 30 System-Wide Change proposal: Mass Python 2 Package Removal
by Ben Cotton 17 Feb '19

17 Feb '19

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

4 4

Intel's Clear Linux optimizations
by František Zatloukal 08 Feb '19

08 Feb '19

Hi, Phoronix recently release article[1] about Intel's Clear Linux with some cool graphs showing nice performance gain compared to Xubuntu. I didn't have time to dig in and look how it's performing against Fedora, but I'd assume Fedora can be compared to Xubuntu in terms of compiler settings. I think i'll be interesting to look into it and find out if Fedora can't tweak compiler settings (eg use LTO for critical things like Mesa, Kernel, ...). I think it could be interesting fo Fedora users to have this enabled if there are not any disadvantages other than compile time, compile memory usage and so on. What do you think? [1] http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1 -- Best regards / S pozdravem, František Zatloukal Project Coordinator Red Hat

15 50

Automating Package Review (Was: fedora-review -- do we have a maintainer?)
by Stephen Gallagher 18 Dec '18

18 Dec '18

On Thu, Aug 16, 2018 at 8:30 AM Michal Novotny <clime(a)redhat.com> wrote: > On Thu, Aug 16, 2018 at 10:49 AM Zbigniew Jędrzejewski-Szmek < > zbyszek(a)in.waw.pl> wrote: > >> f-r currently fails to build (#1603956), it has a bunch of bugs open [1] >> and many issues and unhandled pull requests in the upstream repo [2, 3]. >> The last upstream commit was 2 years ago. >> >> f-r has is annoyingly outdated and gives often outright bad advice >> (for example about BR:gcc or BR:g++). The situation would be >> significantly >> improved if the outstanding PRs were merged. >> >> f-r is also python2-only now, which will be a problem soon since >> support for python2 is waning [4]. >> >> Is there any hope of upstream and downstream activity on f-r? >> > > I was thinking about getting the fedora-review checks rewritten into the > standard Test interface > ( > https://qa.fedoraproject.org/docs/libtaskotron/latest/standard-test-interfa…) > so that they > can be run in Taskotron. We can also just probably run one big > fedora-review check from > a taskotron test, well, this just came to my mind recently, getting the > actual solution ready > might take a little bit of time. > ' > I'd *really* like to see us get to a point where package review is fully-automated. Basically we could just have a web-service that you pass a URL to an SRPM plus authenticate with your FAS account and it will perform all of the validity checks and if they all pass would go ahead and request the branches for you and import the SRPM. Once this is fully automated, we can then *also* add the same checks to CI (taskotron, OSCI or whatever) so that on each build it gets rerun, which will allow us to help reduce the rate of packages falling out of compliance (as well as being updated whenever the checks get made more comprehensive). Historically, we've had human review mainly to protect against two things, bundling and unacceptable licenses. In both of these cases, I'd like for us to move towards a culture of assuming goodwill on behalf of our packagers. Most of the packagers in Fedora have been doing it for a long time and know what is and is not acceptable. Optimizing for the minority case is wasteful, especially when it adds hurdles and delays to getting software delivered. I think what we should instead do is allow things through immediately following automated review and just assume that those few cases that slip through that should not will get handled after the fact as soon as they are noticed (either by someone noticing or an improvement in the automated tool discovering the problem). I feel strongly that automated, continuous review would be of far greater value to Fedora than front-loading the review process the way we have been doing (which serves mostly to discourage people from even starting).

10 15

Installed (but unpackaged) file(s) found on s390x and armv7hl: .s390x.debug.#dwz#
by Pavel Alexeev 21 Nov '18

21 Nov '18

Hello. I try build new version of perdition package. It build fine (https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416) on all architectures except armv7hl and s390x. On that I got (https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/build.log): error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/sbin/perdition.imap4-2.2-1.fc29.s390x.debug.#dwz#.sWwnyG /usr/lib/debug/usr/sbin/perdition.imap4s-2.2-1.fc29.s390x.debug.#dwz#.eE9BPY /usr/lib/debug/usr/sbin/perdition.imaps-2.2-1.fc29.s390x.debug.#dwz#.WRTN7g /usr/lib/debug/usr/sbin/perdition.managesieve-2.2-1.fc29.s390x.debug.#dwz#.GWCloz /usr/lib/debug/usr/sbin/perdition.pop3-2.2-1.fc29.s390x.debug.#dwz#.2Sm2W5 /usr/lib/debug/usr/sbin/perdition.pop3s-2.2-1.fc29.s390x.debug.#dwz#.kvArfo Could someone please help me solve that problem? -- With best wishes, Pavel Alexeev. Yes, I'm a fool - I believe in people, honesty, justice as open source. And also in the fact that I can make this world just a little better unless stop fighting. http://hubbitus.info

5 7

Nonresponsive maintainer: Björn Esser (besser82)
by Miro Hrončok 02 Nov '18

02 Nov '18

Björn Esser (besser82) is not responsive. https://bugzilla.redhat.com/show_bug.cgi?id=1610811 Anyone knows how to contact the maintainer? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

9 11

Orphaning nitroshare
by Raphael Groner 11 Oct '18

11 Oct '18

Hi, I'll orphan nitroshare. There are no dependencies except the subpackages. Reasons for my decision: Upstream did no release since monthes and claims instable branch for master in the documentation. There are some other good alternatives like KDE Connect or TotalCommander with WebDAV. Regards, Raphael

1 1

poppler soname bump in rawhide
by Marek Kasik 08 Oct '18

08 Oct '18

Hi, I'm going to rebase poppler in rawhide to poppler-0.67.0 now. There are several API changes and soname bump of the base library libpoppler.so.*. I've checked all packages which depend on the libpoppler.so.* and have backported/prepared fixes to reflect poppler's API changes. Unfortunately, libreoffice does not build currently (#1615616). But I've decided to push the rebase though because branching will happen today and I could not do chain build after that for F29. Btw, if your package use the unstable API (headers from poppler-devel), could you consider to change it to use a stable API (glib, qt, C++)? Regards Marek

7 10

F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
by Ben Cotton 05 Oct '18

05 Oct '18

== Summary == This change enables TLS 1.3 (draft28) support on the gnutls crypto library. == Owner == * Name: Nikos Mavrogiannopoulos == Detailed Description == This change will enable the TLS 1.3 protocol (draft28) on the gnutls library. TLS 1.3 is the latest version of the TLS protocol which addresses few shortcomings of the previous versions. The protocol has already been approved by IETF and is on its final publication stage, with only minor editorial changes expected. The change for gnutls depending is transparent to existing applications. More information for applications using gnutls: * https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html == Benefit to Fedora == * This brings the latest TLS protocol support to applications depending on gnutls, when crypto policies are updated for TLS1.3. == Scope == * Proposal owners: * Other developers: N/A (not a System Wide Change) == Upgrade/compatibility impact == That change should have no impact on upgrade or compatibility. The TLS 1.3 protocol is designed in a way that does not cause incompatibility issues with existing (and even broken) implementations. == How To Test == * Existing work-flows which include secure communications should be tested * Command line applications which use TLS (e.g., wget, lftp), should be tested against web-sites using TLS 1.3 (e.g., www.google.com) == User Experience == That change should not be noticeable by users except for applications which report the connected protocol. Other things users will notice - Latency on TLS sessions will be reduced - Performance of establishment of TLS sessions will be improved due to ed25519/x25519 support - Privacy of TLS sessions will be improved from the perspective of passive eavesdroppers; no client certificate will be sent in the clear - Transparent rekey of long-running sessions == Dependencies == GNOME, samba, rsyslog, wget, lftp, ... == Contingency Plan == If the expected transparent addition of TLS 1.3 cannot be assured (e.g., important issues are reported), the enablement of TLS1.3 protocol will be postponed for the next fedora release. * Contingency mechanism: The gnutls maintainer will not enable TLS1.3 by default in the build * Contingency deadline: Fedora 29 beta * Blocks release? No; the contingency plan is sufficient and can avoid a release block == Documentation == * https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html * https://www.gnutls.org/manual/gnutls.html#Upgrading-from-previous-versions -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

6 18

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2018