I am trying to get into packaging and now I have the perfect
opportunity to adopt a package - ddclient.
I know that a lot of us, that cannot afford static IP addresses but
like to tinker with home servers and new technology, really love this
little piece of software.
Now, the situation here is a bit tricky as the package is not (quite)
orphaned (and I would like it to stay that way) so I cannot adopt it;
and its owner doesn't want to maintain it anymore, so I cannot co
-maintain. To make it even worse, even if he wanted to sponsor me as a
"co-maintainer", he is not a sponsor :)
Can someone point me in the right direction to start packaging this
program. I read and understood wiki pages about packaging, naming,
licensing, responsibilities, ... I have built a lot of rpms for my own
purposes and have one package ready for review on rpmfusion; so I am
not completely clueless here :)
Thank you for your guidance!
Momcilo 'Momo' Medic.
for quite a while, I've been working on implementation of a new, revamped
UI, designed by Jakub Steiner for the LiveUSB Creator . Currently, me
and Luke are slowly moving to merge the changes back into the master
branch of the tree. Some stuff is not done, like descriptions of the
images or final look of the icons but the really important things are
I'm writing here to ask you guys for input on what you think about how it
looks like now. I've set up a Copr repository  and put a Windows
package together .
I'm open to all kinds of feature requests, bug reports, any kind of input
that comes to your minds.
The Copr version still contains just udisks support. Udisks2 will be added
ASAP (when I rebase my branch against master and build the package again).
Specifically, what we'd love to settle is: what to do with the main screen
with the three promoted images. Obviously, putting a Server or Cloud
Product on a USB drive is a nonsense. One could argue the tool at least
downloads the images for you, though.
I've got the misfortune of maintaining a small number of systems that use
the cx18 driver for their HVR-1600 cards; I'm just in the process of
bringing these systems up to Fedora 21, and have discovered that
cx18-firmware was retired.
As I'm going to have to maintain the package for work purposes, I'm
volunteering to maintain it in Fedora for F21 and later. If anyone's
interested in having it available in Fedora, the review request is at:
I sent this to the font mailing list a couple of nights ago, but
perhaps I should have CCd devel as well:
---------- Forwarded message ----------
From: Alexander Ploumistos <alex.ploumistos(a)gmail.com>
Date: Fri, May 29, 2015 at 3:24 AM
Subject: Issues with repo-font-audit
I am the new maintainer of the gdouros-* fonts . When I took over
the fonts, I was not aware of repo-font-audit (shame on me) and it was
the only check I hadn't run, but these days I had been working on
adding some more fonts from Mr. Douros and I stumbled upon the right
wiki pages, so I went along.
For quite some time, a lot of distros ship the Alexander font, but not
the closely related Anaktoria, Aroania and Asea (this one comes in
Regular, Bold, Italic and Bold Italic), which I want to include. I
wrote up all the necessary files based on the ones I had prepared for
Alexander and made the packages ,,. Two local builds on f21
and f22 were successful, rpmlint only whined about what it thought
were typos and I went on to submit to koji scratch builds for rawhide,
which were also successful.
And then I fed them to repo-font-audit. That gave me an error (fonts
in packages that contain non-font data), a warning (fonts that do not
pass fontlint sanity checks) and a suggestion (fonts with partial
unicode block coverage). I have uploaded the full test results at .
Seeing that I could not do anything for the warning and the
suggestion, I tried to figure out what was the cause of the error, but
I did not reach any solid conclusion. What is the problem? Is it the
%doc part of the file, the metadata/fontconfig files or all of them
That got me worried so, I decided to run a check against the other
gdouros fonts . Of the seven fonts, repo-font-audit managed to
check only three of them as it threw some error messages as soon as it
started . I looked around for the same errors and I found only a
bug report in cpan.org  about ttfcoverage trying to divide by zero.
It was closed as irrelevant. Should I file a bug report for that? For
the other three fonts it managed to check, I got the exact same error,
warning and suggestion...
Puzzled as I was, I decided to check the liberation and the droid
fonts and to my surprise, repo-font-audit spat out the following:
P# t3 t10 t13 t17 t20
1 ‧ 2 ‧ 2 ‧
2 15 15 ‧ 15 6
3 ‧ 1 ‧ 1 1
4 6 6 ‧ 6 4
5 ‧ 4 ‧ 4 ‧
6 ‧ 4 4 4 ‧
7 ‧ 4 ‧ 4 ‧
8 ‧ 4 ‧ 4 ‧
Total 21 40 4 40 11
Among the above errors, warnings and suggestions are the three ones
that I kept getting. So, is repo-font-audit an absolutely necessary
part of the font package creation process, or is it more of an
advisory tool and we can get by with just the other checks performed
by fedora-review? Are the fontlint sanity checks from  worth taking
And on a slightly different topic, is it absolutely required to create
a wiki page for a font package, before it is accepted for inclusion?
Thank you for your time