I have no more time to support the following packages in the Fedora.
jack-audio-connection-kit -- The Jack Audio Connection Kit
klamav -- Clam Anti-Virus on the KDE Desktop
man-pages-uk -- Ukrainian man pages from the Linux Documentation Project
python-alsa -- Python binding for the ALSA library
qstat -- Real-time Game Server Status for FPS game servers
uniconvertor -- Universal vector graphics translator
With Best Regards,
I am orphaning the techtalk-pse package because the Gtk2::MozEmbed perl
module will no longer be maintained in Fedora because gtkmozembed
support has been removed from xulrunner.
If upstream (or anybody) has the time to work on techtalk-pse and get it
working with something like Gtk2::WebKit, I'm glad to pick up package
maintenance again. (I would, but my perl skills go as far as running
Ian Weller <ian(a)ianweller.org>
\/"/_ All Hail the Beefy Miracle!
I just orphaned gdk-pixbuf in pkgdb.
It failed the mass rebuild, not much left that depends on it, and
nothing I need. ;)
% repoquery --source --whatrequires gdk-pixbuf
So, if anyone really really really wants to keep it alive, feel free to
take it and fix it so it builds and works. ;)
While installing Fedora 16 Alpha, I ran into some problems that turned
out to be caused by the installer formatting with a GPT rather than an
MBR partition table.
I would like to understand the change and its implications, and I have
unsuccessfully tried to track down more information. I haven't been
able to find anything in the Fedora 16 Alpha Release Notes or the Grub2
feature page. The only definitive reference I've been able to find is
the comment "x86 uses GPT disklabels by default on all machines, even
non-EFI" on the Anaconda/Changes wiki page.
There seem to be some complications associated with the change. For
example, Windows can only support GPT on UEFI machines, so dual-booting
appears to be unsupported (I could not find an option for MBR partition
tables in the installer).
Where should I look for more information? Thanks.
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
I'm working on bringing OLPC up-to-date with all the great efforts
with GNOME 3, systemd, etc.
On the OLPC XO laptops we have quite a strange screen - it is small
(152mm x 114mm) but very high resolution (1200x900 i.e. 201 dots per
Previously, on Fedora 14, we had to adjust the default GNOME font
sizes since they didn't look right on the screen (I think they were
too big). Now I'm looking at applying the same set of customisations
to Fedora 16 since the default fonts are uncomfortably small on our
However, I've noticed a fundamental difference in the sizing of fonts
between Fedora 14 and Fedora 16. This is visible with a simple
1. Open gedit
2. Change document font size to Sans 72
3. Write the capital letter "I" and measure the height of the printed
character with a ruler
I do this on two laptops side by side, one running Fedora 14 and the
other running Fedora 16.
On F14 the height of the I character is 1.9cm, and on Fedora 16 it is
0.9cm. That is quite a difference.
On both laptops, xdpyinfo correctly prints the screen resolution, DPI
and display size, which have not changed.
>From a typographic standpoint, F14 seems to be correct here. As 1pt is
(approx) 1/72 of an inch, size 72 should produce characters of around
1 inch in size - and 1.9cm (the F14 measurement) is about an inch.
Also, Cantarell seems to play by its own rules. On F16, the "I" in
Cantarell 72 is 0.8cm, not too different from Sans 72, but the
difference between Sans 11 and Cantarell 11 is more significant - at
size 11, Cantarell is tiny.
Can anyone help me understand this behaviour?
We've been planning on doing one of these forever, but never seeming
to get around to it.
The kernel gets a lot of bugs (possibly more than any other package),
and as such, we've got nearly a thousand bugs open right now, and just
three people working on it full-time.
The problem we've faced with triage efforts in the past is that for many
bugs, the person doing the triage really needs to have at least some kernel
knowledge to know what information to ask the reporter.
However, there are some basic tasks that would help us out a lot, like
making sure bugs are assigned to the right people etc.
There's a first pass at some 'how to' ideas at https://fedoraproject.org/wiki/KernelTriage
We'll be doing this in #fedora-kernel next Monday (22nd)
I expect that the wiki page will continue to evolve as we start working
on this, and perhaps this can even become a regular thing.