devel-announce March 2018

devel-announce@lists.fedoraproject.org

8 participants
19 discussions

F29 System Wide Change: Make dbus-broker the default DBus implementation
by Jan Kurik 13 Mar '18

13 Mar '18

= Proposed System Wide Change: Make dbus-broker the default DBus implementation = https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementa… Owner(s): * David Herrmann <dh dot herrmann at gmail dot com> * Tom Gundersen <teg at jklm dot no> Enable dbus-broker.service to use dbus-broker as system and session message bus backend. == Detailed description == The dbus-broker project is an implementation of a message bus as defined by the D-Bus specification. Its aim is to provide high performance and reliability, while keeping compatibility to the D-Bus reference implementation. It is exclusively written for linux systems, and makes use of many modern features provided by recent linux kernel releases. The main focus points of dbus-broker are reliability, scalability and security. The dbus-broker project tries to improve on these points over dbus-daemon, and thus provide a better alternative. And in-depth analysis can be found in the initial announcement of dbus-broker. An excerpt: * Accounting: dbus-broker maintains per-user accounting, including inter-user quotas. This guarantees that no single user can cause irregularly high memory consumption in the daemon. Unlike dbus-broker, dbus-daemon accounts memory in a multi-tier system, based on plain resource counters on users, connections, and other resources. The multi-tier system suffers from resource-chaining-exhaustion, where clients effectively circumvent the accounting by creating multiple connections/objects, which themselves grant them each a new set of quotas. The single-tier accounting scheme of dbus-broker avoids this, while at the same time adding inter-user quotas to prevent misuse even across clients. * Reliability: While D-Bus is used on reliable transports, dbus-daemon might still silently drop messages and given circumstances. This is the only possible solution dbus-daemon has, given several of its runtime guarantees. The dbus-broker project changed the architecture of the bus daemon to a degree, that it can provide many guarantees, including that no message will be silently, or unexpectedly, dropped. * Scalability: The message bus broker is a crucial infrastructure on modern linux system, which is a hot-path for almost all IPC going on. Hence, the broker should perform fast and be scalable to its users. dbus-daemon has several **global** data-structures that affect the overall scalability of independent message transactions. dbus-broker does not employ any global data-structures (unless required by the spec), as such any message transaction is only affected by the data provided by the involved peers. Moreover, even for spec-defined global behavior, dbus-broker avoids global data-structures, unless clients actually make use of these obscure features. In several other cases, dbus-daemon scales O(n) time looking up message targets and related data. dbus-broker runs all these in O(log(n)) time. * Linux-specific: The dbus-broker project was explicitly designed for linux system, making use of many linux-specific APIs and behavior. This allows mitigation of several possible DoS attacks. == Scope == * Proposal owners: ** Fix regressions. ** Enable dbus-broker.service in system and user-global context of systemd (via systemd presets). ** Pull in dbus-broker package from dbus package. * Other developers: ** Watch for regressions * Release engineering: #7262 https://pagure.io/releng/issues/7262 * List of deliverables: N/A * Policies and guidelines: No changes needed. * Trademark approval: No changes needed. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Request for testing: dbus-broker as system and user bus
by Tom Gundersen 13 Mar '18

13 Mar '18

Hi, dbus-broker is a new DBus message bus implementation. We are proposing it as the default in Fedora as of F29 [0], and as such we would be grateful for as much testing as possible before the switch is made. For instructions on how to test, see [1]. Cheers, Tom and David [0]: <https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementa…> [1]: <https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementa…>

1 0

F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer
by Jan Kurik 09 Mar '18

09 Mar '18

= Proposed Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer = https://fedoraproject.org/wiki/Changes/OpenLDAPdropMozNSSCompatibilityLayer Owner(s): * Matus Honek <mhonek at redhat dot com> Since Fedora 28, OpenLDAP is compiled with OpenSSL instead of NSS and includes MozNSS Compatiblity Layer (i.e. TLSMC) to assure backwards compatiblity. After this change the TLSMC will be removed. == Detailed description == This change drops support for NSS-like configuration style for TLS in OpenLDAP. Only PEM files will be supported. This is the expected follow-up to the Changes/OpenLDAPwithOpenSSL [1]. The change will be accomplished by dropping a downstream patch that brings the feature and removing all the related statements from the SPEC file, including --enable-moznss-compatiblity=yes configure option. [1] https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL == Scope == * Proposal owners: Drop downstream patching as described in #Detailed Description * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/7382 #7382] ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

[ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++
by Igor Gnatenko 07 Mar '18

07 Mar '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This is the second iteration of my mass-scratch-rebuild without gcc/gcc-c++ in the buildroot[0]. Everything what was written in original mail still applies. Since people might have fixed their packages after I started rebuild, I decided to include information about commits I have used to build packages. Hope this helps. New list of packages, their commits and build logs are available: * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-commits-2.tx t * https://ignatenkobrain.fedorapeople.org/gcc-removal-2.txt [0] https://lists.fedoraproject.org/archives/list/devel-announce@lists. fedoraproject.org/thread/IJFYI5Q2BYZKIGDFS2WLOBDUSEGWHIKV/ - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqfmBkACgkQaVcUvRu8 X0x5/hAAt1gDH1lzIlkxn9ImLM8339foWlEnLKcqfFH5/dKpIE5x7rgjofRn3OYG +Ca/qtC/iWwOZUYJncXCl+nEPaaBX5v+zpMHAlIZWe/TL7mbLAfwGCAuSupl3agb DG6zuD4gcM0N+5Y5+CtEBv4Yawh+xjb0sKbjCwY8aFsHaVIJHlrnSjWNUz+mUUc1 bEcLUAwf2p581ATN7N3ZiJFvlb8LKuwKtEl3EmIk7K8URE/MDOZLBl0dy8+mXywP BXwPeb4mHXZz/JADocWWMKhotVhPc/kUTixLeSmN7RNAcrgqEkNRQ2imy3LxoygE px2I5UO1H/Tko0ALN8Ga5SeSrpU9U6yqJ2uhreCkPEZN6yRUQYY7kCUULTnh17P5 cYUV6Uu6LELN7mzt6lZ1C0xMtV+WNVK35XkHDwKe/yk0upFb85jFTOKy65L/QvEi CsAs2sOMfQ4KhZoKyPx3iDavickk4PA2DJ40ALWKuroxCnc+IVu1Q7ZZqqsdys+c bL764wTBbmz1pye2sLNerVAwd7Z4e9y+4AZnVTyNTZl0GBhcxumqp1La0Ku9Gl40 jxxHMGhjkkRSwoWiltlj26I13C+L48xYeldxXSvXwjG5YDhQ47pf2cj3oA78i9m/ eNk7cW4zTIdmsNG7WdKZ8kRsExasOxNV1tDxdHAq20hMnpDtbQ0= =yy9a -----END PGP SIGNATURE-----

1 0

Software Translation Deadline has been reached
by Jan Kurik 06 Mar '18

06 Mar '18

Today on 2018-Mar-06 [1] we have reached the Software Translation Deadline [2]. At this time all the strings translations should be substantially finished. [1] https://fedoraproject.org/wiki/Releases/28/Schedule [2] https://fedoraproject.org/wiki/L10N_Freezes#Translation_Deadline Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze
by Jan Kurik 06 Mar '18

06 Mar '18

Today, on 2018-Mar-06, we reach two important milestones of the Fedora 28 release [1]: == Change Checkpoint: 100% Code Complete Deadline [2] == * New accepted changes must be code complete, meaning all the code required to enable a new Change is finished. * The level of code completeness is reflected in tracker bug as state "ON_QA". The change does not have to be fully tested by this deadline. == Beta Freeze [3] == Only packages fixing a bug approved as Accepted Blocker or Freeze Exception [4] will be marked as 'stable' and included in 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. [1] https://fedoraproject.org/wiki/Releases/28/Schedule [2] https://fedoraproject.org/wiki/Changes/Policy [3] https://fedoraproject.org/wiki/Milestone_freezes [4] https://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Fedora 28 Bodhi Activation Point
by Mohan Boddu 05 Mar '18

05 Mar '18

Hi all, Today’s an important day on the Fedora 28 schedule[1], with several significant cut-offs. First of all today is the Bodhi activation point [2]. That means that from now all Fedora 28 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 Software String freeze[4], which means that strings marked for translation in Fedora-translated projects should not now be changed for Fedora 28. Finally, today is the ‘completion deadline’ Change Checkpoint[5], meaning that Fedora 28 Changes must now be ‘feature complete or close enough to completion that a majority of its functionality can be tested’. Regards Release Engineering. [1] https://fedoraproject.org/wiki/Releases/28/Schedule [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release [4] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy [5] https://fedoraproject.org/wiki/Changes/Policy

1 0

f28-ppc64le chroots finally working in COPR
by Michal Novotny 01 Mar '18

01 Mar '18

Hello, the fedora-28-ppc64le chroot was no working up until now due to lack of compose. This was resolved however in issue. https://pagure.io/releng/issue/7357 clime

1 0

Open Seats on the Fedora Packaging Committee
by James Antill 01 Mar '18

01 Mar '18

The Fedora Packaging Committee has some open seats and is accepting submissions from interested candidates to serve on the FPC. The FPC would like to thank Ralf Corsepius, Dominik 'Rathann' Mierzejewski, and Thomas Spura for their service. This position involves not only reviewing Packaging Guideline drafts submitted to the FPC for consideration, but also helping rewrite drafts to resolve issues in a more acceptable fashion. Additionally, the FPC reviews UID/GID soft static assignment. Currently the FPC meets on IRC weekly, on alternate Wednesdays/Thursdays based around 12:00 EST, for approximately an hour. However that is likely to change back to a single day/time slot, and the time would depend on when is good for all the members (East Coast US and German TZs, at least). FPC members serve for as long as they are willing, there are currently no term limits. All decisions are voted on using a +1 (for), 0 (abstain), and -1 (against) mechanism, and all decisions must be approved by a majority (+5). FPC Meetings do not happen if quorum (5) is not present. Candidates who are interested should provide the following details to the FPC for consideration, by emailing it directly to me (james(a)fedoraproject.org). The FPC will consider all candidates, but strongly prefers candidates who have extensive experience packaging in Fedora. We will accept applications for the next two weeks (deadline Wednesday, 2018-03-14). Name: FAS Account: Provenpackager? (Yes/No): Main area of packaging interest/expertise: Reason(s) for wanting to join the FPC: Thanks in advance, ~James

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce March 2018