Phoronix recently release article 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
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?
Best regards / S pozdravem,
So I went to request a new branch of an existing package only to find out
fedrepo-req-branch, which hasn't been around that long is already
depreceated and the facility brought into fedpkg... so:
$ fedpkg request-branch <branch>
Could not execute request_branch: The "token" value must be set under the
"fedpkg.pagure" section in your "fedpkg" user configuration
Ok, so where does that get stored?
$ man fedpkg
(not in there...)
$ vi /usr/share/doc/fedpkg/README
(not in there...)
I figured out somewhere else that the default config is in
/etc/rpkg/fedpkg.conf (In /etc/rpkg? That's intuitive!) but I didn't want
to add my token to the site wide config so the search continues...
$ rpm -ql fedpkg
$ vi /usr/lib/python2.7/site-packages/fedpkg/__main__.py
default_user_config_path = os.path.join(
os.path.expanduser('~'), '.config', 'rpkg', '%s.conf' % cli_name)
Now which token do I need? The one from the src.fedoraproject.org pagure or
Oh and the tokens expire all the time and don't seem to have any helper
scripts to automate updating of the tokens so I have to remember where they
all are and manually edit them every time...
Not coming from a programming background I found the learning curve pretty
steep when I first tried to become a packager, I'm not sure I wouldn't have
given up if I had to do it now.
I will be orphaning the ofono package today. I'd primarily packaged it with
the the intention that it may become a new dependency of pulseaudio (which
never happened), and I've not been able to give it the time it needs.
Recently updated to latest 1.22 release which fixed a long-standing FTBFS
issue, so at least it is in good shape for anyone interested in picking it
you can now very easily setup auto-rebuilds for your src.fp.o package:
1) make a SCM package in COPR with Clone URL pointing to the src.fp.o fork
(please, use the https:// cloning option)
2) make sure "Webhook Rebuild" checkbox is checked when you are creating
3) Go to settings for your package at src.fp.o and almost at the bottom in
Hooks->Fedmsg section, check "Activate" checkbox and then click on "Update"
If your package is a main package (not a fork), then you can omit step 3.
See https://pagure.io/copr/copr/issue/142 for more info.
-----BEGIN PGP SIGNED MESSAGE-----
Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.
The grep output is located here:
Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.
If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.
Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
List of packages and respective maintainers:
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
qpdf was updated from 7.1.1-4 to 8.0.0-1 in Rawhide on 2018-02-26.
This update bumped the soname from libqpdf.so.18 to libqpdf.so.21 .
This soname bump was not announced, as it is supposed to be, and
dependent packages were not rebuilt.
cups-filters depends on qpdf, so anything that includes cups-filters is
now broken. This includes at least the Astronomy_KDE live image, per
Once again, folks, *please* announce your soname bumps, and co-ordinate
rebuilds. (In fact it looks like Zdenek is the maintainer of both
packages and could have rebuilt cups-filters, but just forgot to).
I will attempt a rebuild of cups-filters using provenpackager
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
While working on adding CI tests  using the Standard Test
Interface a need arose to have a shared git repository where tests
could be stored:
* A large number of test files makes a dist-git repository more
difficult to maintain
* Tests might follow a different branching pattern than the
dist-git repo, leading to code duplication
* Shared maintenance for tests sometimes benefits from different
access levels than the release dist-git repository
The plan is to create a new “tests” namespace in Fedora git/pagure
dedicated to storing the shared test code. To enable execution of
these tests by the CI pipeline, tests.yml file in dist-git will be
used to link the tests in the standard way as defined by the
Standard Test Interface .
This approach should help to efficiently maintain tests & minimize
test code duplication. Using a dedicated git repo for test code
also means to keep dist-git more as a place for storing metadata
only: Build metadata (spec file = how to build the package) and
test metadata (tests.yml = how to test the package) rather than
mixing spec files with test code itself.
Please note that this does not mean that all tests should now go
into this new namespace. You can still link tests directly from
upstream (like GitHub) or any other source. Also, for unit tests
it makes more sense to be kept directly with the project source
and executed there. Shared tests namespace in Fedora will be
suitable especially for functional and integration testing which
should help to continuously ensure the OS works as a whole.
For more detailed motivation and real-life examples see the Share
Test Code proposal on the Fedora CI list . If you have any
questions or comments feel free to share them here or in the
pagure issue requesting the new namespace:
Proposed System Wide Change: Enable dbus-broker
* 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
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:
* [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
* [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
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:
** List of deliverables:
* Policies and guidelines:
No changes needed.
* Trademark approval:
No changes needed.
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic