devel July 2018

devel@lists.fedoraproject.org

224 participants
297 discussions

Nonresponsive maintainer: salimma
by Miro Hrončok 27 May '19

27 May '19

https://bugzilla.redhat.com/show_bug.cgi?id=1589077 Does anyone know how to contact the maintainer? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

4 4

Proposal: Abandon v8 package
by Tom Callaway 07 Mar '19

07 Mar '19

Background: I made the original v8 Fedora package many moons ago, when I was more optimistic about the possibility of separating the useful components inside of chromium. Since that point, it has become clear that while v8 is useful software, the following facts are also true: 1. The v8 upstream is entirely disinterested in the concept of maintaining any sort of ABI/API consistency between releases. 2. The v8 that is used in chromium is not necessarily compatible with the upstream v8, as they have a history of picking and choosing code changes (and even applying chromium specific changes locally). 3. Virtually all consumers of v8 (including chromium) take a git checkout (not a specific one, just whatever they decided to code to) and use that revision, often creating a local fork of v8 from that revision, as they are either unwilling or unable to track v8 upstream. 4. Since v8 has no concept of a "stable" release that I can see, they simply do security fixes to the master branch, which, combined with the code changing violently, makes it very difficult to backport security fixes. This means that other than plv8 (which is currently unable to build against the current v8 package in Fedora), I do not see any consumers of the Fedora v8 package (chromium has long since abandoned any possibility of using it). It does contain a "d8" binary, which is a javascript CLI debugger, but it is not clear to me that this is widely used, or that the benefit of its inclusion in Fedora outweighs the pain of maintaining this package. Thus, I propose that the v8 package be abandoned/orphaned/taken to the farm upstate to run and play with the other dogs. If you disagree, or are crazy enough to want to take it over, speak now. ~tom P.S. I'll still maintain v8-314 as best I can, since there are actually users of that. The irony of that really ancient version being considered stable (and thus, used by other software) as a result of Fedora sticking on that version of v8 for so many releases is not lost on me.

4 7

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

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

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

Python3 will be in next major RHEL release, please adjust %if statements accordingly
by Troy Dawson 04 Oct '18

04 Oct '18

Hello, Python3 will be in the next major RHEL release. I don't mean RHEL 7.6, but with numbers higher than 7. There are many, many packages with something like the following if 0%{?fedora} %define with_python3 1 %endif If you have something like that, please change it to something like this. if 0%{?fedora} || 0%{?rhel} > 7 %define with_python3 1 %endif Thank You

21 40

Starting a Container SIG
by Clement Verna 27 Aug '18

27 Aug '18

Greeting all, The container effort in Fedora has until now been looked after by the Atomic WG, since this Working Group is now going to focus mostly on Fedora CoreOS, I propose to create a new container SIG to regroup people interested in the maintenance of application containers in Fedora. This SIG would look after the container guidelines [0], the container review process [1] and also the release process and tooling. Please Reply if you're interested with helping out making the Container story great in Fedora. If there is a good response, I will create a Container SIG wiki page, and I guess we can ask for container-devel mailing list for SIG discussions. Regards, Clément [0] - https://fedoraproject.org/wiki/Container:Guidelines [1] - https://fedoraproject.org/wiki/Container:Review_Process

19 25

dokuwiki packagers unresponsive
by Peter 'Pessoft' Kolínek 27 Aug '18

27 Aug '18

Hello. I'd like to fix some issues (including security problems) which are for a long time present in dokuwiki package. Maintainers of the dokuwiki however seem unresponsive. https://bugzilla.redhat.com/show_bug.cgi?id=1518716 Does anyone know how to contact maintainers? Thanks. -- Kind regards, Peter "Pessoft" Kolínek ---------------------------------------- Freehosting PIPNI - http://www.pipni.cz/

7 17

kcov: code coverage for programs and python/shell scripts
by Dridi Boukelmoune 23 Aug '18

23 Aug '18

Greetings developers, I just submitted a review request [1] for kcov [2] that I recently discovered. It has no relation to Linux's kcov and is more akin to lcov, except that all it needs is a binary with DWARF debuginfo instead of requiring compile-time instrumentation. I came across kcov when I was looking for a way to measure code coverage in a Rust project and I'm impressed. It supposedly has a low overhead, but so far I've been monitoring small single-threaded programs so I can't really tell. I haven't tested python and shell support, although I have cases where it would be relevant, but I don't have time yet. The package itself is simple, but it bundles javascript and doesn't build on all main platforms so I may have to be granted an exception from some group starting with an F. Been busy lately, I'm a little behind on anything Fedora. If that's the case, please RTFM me a link to the wiki, and if you want to take the review I'll gladly take one in return. Cheers, Dridi [1] https://bugzilla.redhat.com/show_bug.cgi?id=kcov [2] https://simonkagstrom.github.io/kcov/index.html

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2018