F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark
by Jan Kurik
Proposed Self Contained Change: Drop Legacy GTK+ GUI in wireshark
https://fedoraproject.org/wiki/Changes/Drop_Legacy_GTK+_GUI_in_wireshark
Owner(s):
* Michal Ruprich <mruprich at redhat dot com>
== Detailed description ==
Since wireshark-2.0 there are two GUIs availble for use. One is based
on GTK+ and the other on Qt. The upstream focuses on the development
of the Qt-based GUI and the GTK-based GUI has been marked as legacy.
Since wireshark 2.4.0 the GTK-based GUI is not supported anymore and
it is disabled by default. We should drop the GTK-based wireshark in
Fedora 29.
== Scope ==
* Proposal owners:
This is an isolated change. The new GUI is more or less the same as
the new one. It does not affect any functionality of wireshark
package. This will be a very easy change from developer point of view.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
[https://pagure.io/releng/issue/7319 #7319]
**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
6 years, 1 month
F29 Self Contained Change: True Noarch Erlang Packages
by Jan Kurik
Proposed Self Contained Change: True Noarch Erlang Packages
https://fedoraproject.org/wiki/Changes/TrueNoarchErlangPackages
Owner(s):
* Randy Barlow <bowlofeggs at fedoraproject dot org>
Erlang packages are currently all installed into
%{_libdir}/erlang/lib, despite most of them being noarch packages.
This proposal is to modify Erlang to search %{_datadir}/erlang/lib in
addition to %{_libdir}/erlang/lib when searching for dependencies.
== Detailed description ==
The Erlang VM is currently hardcoded to search for dependencies in
%{_libdir}/erlang/lib (on x86_64 this is /usr/lib64/erlang/lib). Due
to this, all Erlang packages are currently compiled "archful", despite
most of them being pure Erlang and thus truly noarch. This leads to
longer build times for Erlang packages, and more storage used in Koji
and on the mirrors.
This change proposes to add an additional path to be searched by the
Erlang VM when finding dependencies at %{_datadir}/erlang/lib (on
x86_64 this is /usr/share/erlang/lib). Additionally, the build macros
will be udpated to automatically use this new path for installation
for noarch packages. "Archful" packages will continue to store their
files where they do today.
== Scope ==
* Proposal owners:
** Write a small patch for the Erlang VM to search two paths instead
of one when loading dependencies. We will attempt to get this patch
accepted upstream first, but we will then carry the patch downstream
until accepted by upstream.
** Modify the Erlang RPM macros to use the new path for noarch packages.
* Other developers:
** Any developers who are not using the Erlang install RPM macro
should modify their spec file to either use the macro, or to install
their noarch packages to the new location.
* Release engineering:
[https://pagure.io/releng/issue/6685 #6685]
** We could mass-rebuild Erlang packages, but everything should keep
working without doing a mass rebuild so it is probably not necessary
or worthwhile, unless we want to more immediately clear up a little
disk space. The recommendation is to wait until the next mass rebuild
since there will be no interruptions for existing packages, i.e., no
effort required from Releng.
** Any erlang packages that switch from being archful to being noarch
will need all their dependent packages to be rebuilt, since they will
no longer provide archful versions of themselves. However, this can be
done at the time each package switches to being noarch. This change
will not switch any particular packages to noarch.
**List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines:
** Erlang packages do not have formal packaging guidelines yet, though
this document does exist:
https://fedoraproject.org/wiki/User:Peter/Erlang_Packaging_Guidelines
*** We should update the WIP guidelines.
* 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
6 years, 1 month
F29 Self Contained Change: No more automagic Python bytecompilation
by Jan Kurik
Proposed Self Contained Change: No more automagic Python bytecompilation
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompi...
Owner(s):
* Miro Hrončok <mhroncok at redhat dot com>
* Petr Viktorin <pviktori at redhat dot com>
The current way of automatic Python byte-compiling of files outside
Python-specific directories is too magical and error-prone. It is
built on heuristics that are increasingly wrong.
We will provide a way to opt-out of it and adjust the guidelines to
prefer explicit bytecompilation of such files. Later, the old behavior
will be opt-in only or will cease to exist.
Note that bytecompilation in Python-specific directories (e.g.
/usr/lib/python3.6/) is not affected.
== Detailed description ==
[Change wrangler note]: As the detailed description of this Change
proposal is quite extensive I am just referring to the Change Proposal
wiki page: https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompi...
. Please review the proposal following the link.
== Scope ==
* Proposal owners:
Make it work technically, propose the new guidelines, file pull
requests for python3 modules that follow the current guidelines.
* Other developers:
Maintainers of python3 packages that redefine %__python should merge
provided pull requests. Others may opt-in for the new behavior or
explicitly stick with the old one (not a System Wide Change, they
don't have to do anything).
* Release engineering:
[https://pagure.io/releng/issue/7315 #7315]
* Policies and guidelines:
will be changed as described in description
* Trademark approval:
not needed
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 1 month
F29 System Wide Change: Enable dbus-broker
by Jan Kurik
Proposed System Wide Change: Enable dbus-broker
https://fedoraproject.org/wiki/Changes/EnableDbusBroker
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
[https://dvdhrm.github.io/rethinking-the-dbus-message-bus/
announcement] of dbus-broker. An excerpt:
* [https://github.com/bus1/dbus-broker/wiki/Accounting 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 [https://github.com/bus1/dbus-broker/wiki/Accounting
single-tier accounting] scheme of dbus-broker avoids this, while at
the same time adding inter-user quotas to prevent misuse even across
clients.
* [https://github.com/bus1/dbus-broker/wiki/Reliability 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
[https://github.com/bus1/dbus-broker/wiki/Reliability guarantees],
including that no message will be silently, or unexpectedly, dropped.
* [https://github.com/bus1/dbus-broker/wiki/Scalability 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.
** Enabledbus-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:
[https://pagure.io/releng/issues/7262 #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
6 years, 1 month
F29 Self Contained Change: BINUTILS 2.30
by Jan Kurik
Proposed Self Contained Change: BINUTILS 2.30
https://fedoraproject.org/wiki/Changes/BINUTILS230
Owner(s):
* Nick Clifton <nickc at redhat dot com>
Rebase the binutils package from version 2.29 .1 to version 2.30. This
will bring in bug-fixes and some new features.
== Detailed description ==
Switch the binutils package from being based on the 2.29.1 release of
the FSF binutils to being based on the 2.30 release. This release
includes bug-fixes and new features.
== Scope ==
* Proposal owners:
Replace the 2.29.1 source tarball with the 2.30 source tarball and
update the Fedora specific patches. (This work has already been
completed locally and is ready for comitting).
* Other developers:
None.
* Release engineering:
https://pagure.io/releng/issue/7282 - A mass rebuild is required.
** List of deliverables:
Just the binutils packages.
* Policies and guidelines:
No updates needed.
* 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
6 years, 1 month
[HEADS UP] Package wireshark-gtk going away
by Michal Ruprich
Hi,
the wireshark-gtk is no longer supported by the upstream since
wireshark-2.4.0. You may have noticed that there is new GUI based on Qt
since wireshark-2.0. This GUI will become default and the GTK-based GUI
will be dropped and no longer provided. This change should appear in
Fedora 29.
--
Michal Ruprich
Associate Software Engineer
Email: mruprich(a)redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
6 years, 1 month
Call for users of darkserver
by Pierre-Yves Chibon
Good Morning Everyone,
The week before DevConf, a number of the members of the Fedora Infrastructure
met in Brno to discuss states and plans for the infrastructure.
One of the question that raised was about darkserver.
This application is available at: https://darkserver.fedoraproject.org/
and is meant to:
enable developer tools to identify exact package builds from which process
images (e.g. core dumps) come. This can enable their analysis, debugging
profiling, by finding out where the rpm / elf / dwarf files may be found, so
they can download them. (This is even better than
abrt-action-install-debuginfo-to-abrt-cache because that apparently cannot query
files no longer indexed by repodata.)
Source: https://fedoraproject.org/wiki/Darkserver
However, it seems this application has not been working for a long time now and
not many people asked about it.
So, is anyone using this service?
If there is little interest for this project, we will likely decommission it in
the coming weeks (say end of March).
Thanks for your attention and your feedback,
Pierre
For the Fedora Infrastructure team
6 years, 1 month
Orphaned packages seeking new point of contact
by Kevin Fenzi
Greetings.
There's some packages that have been orphaned by FESCo and are seeking a
new point of contact to stay in the collection.
If you are interested in becoming the point of contact for these, please
note it in the appropriate ticket below for quickest processing.
(no need to reopen the ticket, just add your fas name and what packages
you want to take)
https://pagure.io/fesco/issue/1801
rpms/fotowall
rpms/monkeystudio
rpms/posterazor
https://pagure.io/fesco/issue/1836
rpms/minion
rpms/pastebinit
rpms/tlomt-orbitron-fonts
https://pagure.io/releng/issue/7173
rpms/cclive
rpms/cdm
rpms/faience-icon-theme
rpms/fbset
rpms/freedoom
rpms/freedoom-freedm
rpms/freehoo
rpms/getdata
rpms/gpm
rpms/gqview
rpms/hddtemp
rpms/iniparser
rpms/knapsen
rpms/ldd-pdf
rpms/libcryptui
rpms/npush
rpms/phatch
rpms/photoprint
rpms/prboom
rpms/prboom-plus
rpms/preload
rpms/pulseaudio-equalizer
rpms/PySolFC
rpms/PySolFC-cardsets
rpms/PySolFC-music
rpms/remind
rpms/sap
rpms/sipcalc
rpms/sudoku-savant
rpms/tong
rpms/tuxcmd
rpms/xcftools
rpms/yadex
rpms/yafc
Thanks,
kevin
6 years, 1 month