F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates
by Jan Kurik
= Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags Updates =
https://fedoraproject.org/wiki/Changes/Fedora26CFlags
Change owner(s):
* 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
C++ projects.
* 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
fully effective.
* 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)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 3 months
Announcement: DNF port of livecd-creator
by Kevin Kofler
Hi,
remix authors rejoice: I have ported the old livecd-creator from yum to dnf
(in one night):
https://github.com/kkofler/livecd-tools
(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
me),
* 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.
Some caveats:
* 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:
kernel-modules
kernel-modules-extra
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.)
Enjoy,
Kevin Kofler
7 years, 3 months
dnf skipping updates in koji
by Orion Poplawski
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.
https://koji.fedoraproject.org/koji/taskinfo?taskID=16531079
--
Orion Poplawski
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
7 years, 3 months
state of advanced audio in Fedora
by Przemek Klosowski
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
showcases.
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
Yoshimi 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
previous versions.
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
~/.config/rncbc.org/Qsynth.conf file).
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
synthesizers.
7 years, 3 months
F25 GNOME Shell notification locked up hard for some time
by Michael Schwendt
WTF?
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.
7 years, 3 months