Due to https://pagure.io/fesco/issue/1639 we have orphaned 2 packages
that need a new point of contact:
rpms/authd -- A RFC 1413 ident protocol daemon ( master f25 f24 f23 )
rpms/python-gudev -- Python (PyGObject) bindings to the GUDev library ( master f25 f24 f23 )
Please do take a look and see if you would like to manage them for
I messed up the change proposal for Boost 1.61 in F25, which means it
isn't on the schedule.
Given the huge amount of work involved in every Boost update, I'm not
going to be too upset if I don't have to do it!
How upset will other people be if F25 ships with Boost 1.60 (same as
in F24)? Then F26 would get an update, possibly skipping 1.61 and going
straight to 1.62 which should be out by then.
Boost 1.61 adds four new libraries: Boost.Compute, Boost.DLL,
Boost.Hana and Boost.Metaparse.
Full 1.61 release notes:
Is it supposed to be supported to install RPMs onto NFS filesystems?
Apparently NFSv3 doesn't support capabilities, so I'm not sure what to
do with this bug which happens because cap_net_raw is used for the
We often deal with upstream developers that bundle libraries in their
code, so to make a package we have to debundle them, etc.
This time, an upstream dev. asked me what he could do to make easier
the work of packagers.
In this case the software is python-netjsongraph  that bundles
I think it would be nice to make a discussion even for non Python
packages, so we can elaborate a sort of vademecum that a packager
could show to upstreams when there is a collaboration between them.
Have a nice day
= Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags Updates =
* Florian Weimer <fweimer AT redhat DOT com>
This change updates the default C/C++ compilation flags, as determined
by the redhat-rpm-config package.
== Detailed Description ==
This change covers the following modifications to the default C and
C++ compiler flags in the redhat-rpm-config package.
* Drop -mtune=atom on i686: This flag was added to improve performance
on the Intel Bonnell microarchitecture. Such CPUs are rare these days.
In addition, many users of the i686 packages download them for use
within a 64-bit x86_64 installation, and only a small part of these
Fedora installations use Atom CPUs. Current microarchitectures for
Atom CPUs are different from the original Bonnell microarchtecture and
would need different GCC flags for tuning, but many current Atom-based
devices cannot run Fedora because Fedora does not support their 32-bit
UEFI boot environment.
* Add -Werror=implicit-function-declaration: Implicit function
declarations allows a programmer to call functions without declaring
them (or including the relevant header files). The official C language
specification has not supported implicit function declarations for
almost two decades now. GCC still supports them as a GNU extension.
Implicit function declarations introduce bugs because these functions
use a different calling convention and have a fixed return type of
int. Resulting issues are pointer truncation (on 64-bit
architectures), exposure of padding bits (particular for
bool-returning functions on x86_64), and unexpected lack of hardening.
Implicit function declarations are not part of C++ (with or without
GNU extensions), and adjusting C code accordingly simplifies reuse in
* Add -Werror=implicit-int: Implicit ints were removed from the C
programming language at the same time as implicit function
definitions, and were also retained as a GNU extension. Implicit ints
are usually source code bugs, and the presence of such code may
interfere with future C language directions (for example, consider how
C++ reused the auto keyword and an omitted type specifier).
The main risk from these changes are incorrect autoconf feature
checks, which often rely on technically invalid C fragments. However,
a review of existing configure scripts did not find any places where
they relied on these two problematic GNU extensions.
The technical side of this change is tracked in bug 1393492.
== Scope ==
* Proposal owners: The defaults in redhat-rpm-config need to be
changed, as described above.
* Other developers: Source code which relies on implicit function
declarations or implicit ints needs to be adjusted.
* Release engineering: This change requires a mass rebuild to become
* List of deliverables: No release blocking deliverables.
* Policies and guidelines: no changes proposed (change will be
implemented through redhat-rpm-config)
* Trademark approval: N/A (not needed for this Change)
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
remix authors rejoice: I have ported the old livecd-creator from yum to dnf
(in one night):
(The other tools in the package were also ported away from yum and its
rpmUtils to dnf, but livecd-creator was the main user of yum stuff.)
So, if you are unhappy with livemedia-creator for whatever reason, e.g.:
* because of its heavy weight, requiring the whole Anaconda,
* because of its lack of persistent caching (which was the dealbreaker for
* because of more stringent requirements on the kickstart (in particular,
livemedia-creator requiring more changes to your existing kickstarts),
* because livecd-creator "is more friendly when kickstarts are broken or
packages are missing" (quote from a Korora commit message),
or whatever, you will probably appreciate it.
* It works for me, but of course there is only so much testing you can do in
only a few hours of work including the porting.
* It is still using Python 2, and thus needs python2-dnf (which nothing else
needs). If somebody feels like porting it to Python 3, that should be easy
now that it uses dnf, so please feel free. I would be happy to take a pull
request for that.
* The switch to dnf may change the dependency resolving in a way that may or
may not be an improvement.
* In particular, you will probably have to explicitly add these packages:
to your kickstart to avoid getting the kernel-debug* versions dragged in.
For my KDE Fedora Remix Kannolo, I also had to explicitly add pinentry-qt
to my kickstart to avoid having pinentry-gnome3 dragged in instead.
These changes are completely backwards-compatible with the original yum
version of livecd-tools. (They should not have any effect there.)
I just noticed this in a root.log for a koji rawhide build that didn't
error out doing the install:
DEBUG util.py:421: Skipping packages with conflicts:
DEBUG util.py:421: (add '--best --allowerasing' to command line to
force their upgrade):
DEBUG util.py:421: acl x86_64 2.2.52-11.fc24
build 75 k
DEBUG util.py:421: bash-completion noarch 1:2.4-1.fc26
build 268 k
DEBUG util.py:421: compat-openssl10 x86_64
1:1.0.2j-5.fc26 build 1.1 M
DEBUG util.py:421: cracklib-dicts x86_64 2.9.6-3.fc25
build 3.9 M
DEBUG util.py:421: dbus x86_64
1:1.11.6-1.fc26 build 245 k
DEBUG util.py:421: dbus-libs x86_64
1:1.11.6-1.fc26 build 172 k
DEBUG util.py:421: deltarpm x86_64 3.6-17.fc25
build 88 k
DEBUG util.py:421: dnf-conf noarch
2.0.0-0.rc1.4.fc26 build 41 k
DEBUG util.py:421: dnf-plugins-core noarch
1.0.0-0.rc1.1.fc26 build 38 k
This doesn't seem right to me.
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
I was always impressed with the amount and quality of audio software in
Linux. When it all works, and is driven by someone who knows what
they're doing, it's essentially a high-end DAW production environment.
If it all worked smoothly, I am sure it could be one of Linux and Fedora
I am a musical dilettante, so my attempts have been perhaps haphazard,
but I had a mixed luck: I was able to get everything to run, but the
setup seemed very brittle. I was not very successful debugging the
problems because the audio chain is pretty complex, what with the raw
devices, ALSA, PulseAudio and Jackd having overlapping roles, and lots
of obsolete and conflicting information on the web. I decided to write
to the development list in the hope of starting a technical discussion
that would result in either technical and/or configuration fixes, or at
least some documentation, that I could perhaps help develop.
I have been using the following programs:
play/aplay simple .wav players
espeak speech synthesizer
Qsynth/fluidsynth .midi players/synthesizers
audacity sound editor
pianobooster keyboard play-along teaching tool
Rosegarden w/lilypond music editor
Hydrogen drum synthesizer
rakarrack guitar effect processor
As I said, I was able to use all of them successfully, but I had
problems integrating them and keeping them up and running in the long
term. I wonder if I am doing something wrong, or are there technical
issues that I'm running into, currently on Fedora 25 but also on
Obviously, out of the box, simple sound obviously works: I can aplay a
.wav file, espeak works, and some of the synthesizers like audacity and
hydrogen simply work without any preconditions.
Other audio programs require starting Qsynth first: that seems to be the
case for Rosegarden, Yoshimi and pianobooster. What is puzzling is that
there seems to be a lot of hidden state: after running Qsynth for a
while, the simple sound (aplay, espeak) tend to no longer work: they
hang without producing any sound, even though Qsynth is no longer
running. I tried stracing them, but they just go into nanosleep() busy
loops on internal file descriptors, so it's not clear what exactly
they're blocking on. I ran into one glitch where qsynth somehow inserted
a .wav file as a soundfont in the configuration file, which prevented it
from working subsequently (I had to delete the
I am planning to log some bugzilla reports, but I am not sure against
what subsystems: is it ALSA, or PulseAudio, or Gnome/pavucontrol, or
Qsynth. Specifically, I'd like to address the following issues:
- simple sound (aplay, espeak) failing after running fancy synthesized
sound apps (Qsynth): I'd need guidance what to test to find the hidden
state that causes that.
- fancy sound apps (Rosegarden/pianobooster) silently failing without
the synthesizer (Qsynth) running first. I'd like to discuss what could
be done to at least produce some error messages directing users to set
up synthesizers first, or maybe to automatically start the required
Noticed one notification about "File operations" in GNOME Shell, clicked
on it, and the entire machine was frozen for maybe ten seconds. Mouse
pointer couldn't be moved, keyboard input didn't work, couldn't switch
to virtual console either.