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.
I'm trying to create a new update and
I'm getting this error:
Builds : Unable to create update. Parent instance is not bound to a Session; lazy load operation of attribute 'release' cannot proceed
The build looks fine:
Any ideas what the problem is?
during the Tuesday's Modularity WG meeting I was talking about the status
of the Base Runtime prototype build and the package build failures we
encountered during our latest attempt. The meeting log is here:
In short: To bootstrap the Modularity infra (yeah, it's still not done)
we took a (fairly large) set of packages directly from Fedora 25 RC3
and put them all in one, self-hosting module, currently misleadingly
labeled as base-runtime. The next step was to rebuild this set using
only the packages in it, preferrably twice, to prove it works, produces
the same, reproducible builds (or as close as we can get) and to save us
from sudden, unexpected breakage later when we need to touch components
deep in the [build] dependency chain.
(Since this is a common question: No, the final Base Runtime module,
or the Generational Core stack it is part of, won't be self-hosting and
we won't be shipping the entire set we're currently working with under
We attempted to rebuild 2943 SRPMs and encountered 152 failures.
The reasons vary and include undiscovered conditional build dependencies,
undeclared build or runtime dependencies in combination with recent
buildroot and other package dependency chains changes, packages no
longer being compatible with their updated dependencies, random hangs
or non-deterministic, randomly failing test suites, to name a few.
Some but not all of those affect, and can be reproduced in, the traditional
Fedora release, too, and fixing these issues is not only crucial for the
upcoming modular Fedora 26 Server but will benefit the standard Fedora
release as well.
We'll be working on resolving these failures during the upcoming few weeks
-- via FTBFS bug reports or immediate fixes in the most trivial cases.
We'll use the following tracker bug for this purpose:
For the curious, the logs are here:
And the modulemd input for this build is here:
If you maintain some of these FTBFS'd packages, feel free to fix them
even before we get to you! :) Just, please, let us know if you do.
Finally, some quick test instructions: Make sure your package builds
in F25 and Rawhide. If it does, check whether it also builds in mock
using this configuration file: https://paste.fedoraproject.org/494173/
If it works there as well, chances are it's fine.
Thank you in advance,
I took over the maintenance of urw-fonts to update them to the latest
version (ghostscript and other packages needs them). However, there are
several problems in versioning of it, and I would like to discuss future
steps for the package.
The current problems:
* our urw-fonts are kind of old (~2 years), and ghostscript is unable to
build without latest version correctly
(unless I patch it, and it would still cause ghostscript crashes for some
* according to git log the urw-fonts in Fedora should be based on version
1.10, but the source code archive indicates version 1.07 pre-release
(1.06 in fact, if we check the source code)
* the NVR of urw-fonts does not correlate to this at all -
* we obtain the source archive from Artifex (aka upstream responsible for
ghostscript), nowadays they are no longer using the X.Y.Z versioning
system. Instead, they have created a separate git repository for it, and
are doing "snapshot based" releases... Their latest release is:
* I asked them if they could go back to X.Y.Z versioning system, here's
what Chris Liddell replied:
"If you check the versions in the font files, you'll see why I switched to
the release dates.
For several releases they never changed from 1.10, and with the latest
release, they're back to 1.00.
Since this is how URW++ release them to us, there's not a huge amount we
* and as you can see above, they also changed the name from 'urw-fonts' to
'urw-base35' because of this
As you can see, the versioning of urw-fonts is total mess right now, and I
would like to bring back some order to it, but I don't want it to backfire
on me because of how URW++ tends to version their fonts... Here's my
proposed solution to this:
- create a new package for urw-fonts which would obsolete the current
- choose a similar name to the new package - 'urw-base35-fonts' or similar
1) stick to URW++ based versioning - this would mean (at the moment)
Version == 1.0 and adding snapshot == 20160926
(YYYYMMDD as described in
2) or map the X.Y.Z versioning to YYYYMMDD from upstream - IOW - X == Year,
Y == Month, Z == Day (based on the snapshot date in the name of the source
3) or set the Version to some constant (35 for example) and just use the
snapshot to distinguish between older and newer releases.
I am affraid that I would pick option 1) it could pose problems in the
future again, because there's not guarantee that URW++ will follow sane
versioning. So, personally, I would choose 2) or 3).
There's also one more option, and that is to base the package on upstream's
git repository and the snapshot scheme, because we would be using snapshot
string in the package name anyway. And it would also solve one more issue
that upstream is not shipping license files in the archive. (I have already
contacted to correct this.)
What are you thoughts, guys? Anyone has a better idea how to solve this
mess? Or which option would you recommend?
Thank you in advance for all your ideas.
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.