Spinning of from this, I think there is some mess around the Virtio
drivers; I would be glad if someone could explain that to me.
Sorry for the length of this mail but I could not shorten it.
Let's say I would like to grab the latest virtio drivers and tools for my
Windows guest and the accompanying source code; this is what I found:
1) Recent version from Fedora in iso format
- No WHQL, no changelog, no QXL drivers, no Spice Agent available, no source
- Updated every once in a while
2) Roughly the same versions of Fedora, in zip format
- No WHQL, no changelog, no QXL drivers, no Spice Agent but the changelog
- All the changelog points to an internal Redhat git repository.
- From my understanding, these tarballs are the one that every once in a
while make their way into the Fedora iso and the "pre WHQL" Redhat ones.
- The source is there in a zip file.
3) Official Spice Agent (very old and buggy):
4) Spice Guest Tools setup
- Unofficial Spice Agent, built from the latest sources using the mingw
- Latest Fedora iso drivers
- Recent built from source QXL driver, but unfortunately unsigned so it
doesn't work properly in Fedora.
- The Balloon Service is not installed as part of the setup
5) Official RHEL drivers (need an account for this)
- Contains signed and WHQL drivers for everything.
- Always a bit older than the Fedora ones.
- Follows the same numbering and logs as no. 2.
- Contains signed WHQL drivers for Windows XP and Windows 7 32/64 bits, but
outside of the normal iso (why?)
- Does not contain the Spice Agent.
6) Yan Vugenfirer's repository
- Contains only source, and is public.
- Does not match with Fedora or RHEL provided drivers.
- Contains only the Virtio drivers, no Spice Agent or QXL driver.
7) QXL drivers for various targets
- Sometime, someone builds an updated driver and posts it to the
spice-devel mailing list.
- All the drivers are not signed, of course.
So far, my best setup is to recreate an iso everytime there is an update to
- Latest Fedora drivers for Windows XP, 2003
- Latest QXL binary from the Spice Guest Tools for Windows XP
- Latest signed RHEL drivers for Windows Vista and up
- Latest signed QXL driver for Windows Vista and up
- Latest Spice Agent binary from the Spice Guest Tools
I would say this is suboptimal, especially when I try to explain someone
moving from Windows that si trying to virtualize Windows on their newly
At the best case, they don't have the QXL driver, causing lag in the
desktop, no Spice Agent for cut&paste and usually a lot of problems with
Before this, I used to compile drivers myself with the DDK following the
instructions. This gave me the option to compile the QXL drivers for
Windows 2003 and Windows 2008 targets as well, but I always had the same
problems with signing.
Since all the problems go back to signing the binaries for making them work
out of the box in Windows Vista/7/2008/2008r2/8, I would like to know if
it's possible to do this from time to time:
- Have Fedora build the latest Virtio drivers (this is already done)
- Build also the Spice Agent for 32/64 bit (this is done at
spice-space.orgas part of the Spice Guest Tools)
- Build the latest QXL drivers for all the Windows targets supported by the
Virtio drivers (I know the Windows 8 XWDM driver will come eventually later)
- Sign everything with the Redhat key, as it's doing for the drivers at
- Pack everything into an iso.
I'm not asking for WHQL as I understand this is a "benefit" for the Redhat
All the bits are there except they are dispersed everywhere, so I don't
think it's a big effort.
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).
I have just submitted a request for rename of the package
community-mysql "back" to mysql-community:
See there for more details and rationale.
I'm sorry that this took somewhat longer than intended to get out, I
had some urgent tasks to attend do, such as getting the first
development release of MySQL 5.7 out the door and its source to
Launchpad. On the other hand. this also means we have already updated
the 5.6 package from the initial GA release 5.6.10 to 5.6.11.
Since I do not yet have a sponsor, I cannot upload to
fedorapeople.org. Also, Oracle does not have public web host usable
for ad-hoc uploads like this, so for the time being I have ulpoaded to
my private web page here:
Please excuse my ISP for thinking the file extension .rpm is music. :-)
I have also run a koji scratch build:
I've had some in-house expert help for preparing the new source RPM
and spec file, but I will be responsible for keeping the Fedora
packages up-to-date going forward. I have just ordered a laptop on
which I will install F18 for this purpose :-) . Development/testing is
also being done on a VM in our development lab running Rawhide.
I waw at Sun since they acquired the small database startup I worked
for in 2002. When Sun acquired MySQL in 2008, I was working with
Release Engineering of PostgreSQL in Sun's own database group; I was
responsible for integrating PostgreSQL 8.3 into OpenSolaris.
After Sun scaled down its PostgreSQL efforts (I still build Solaris
binaries for the PG community when they have new releases), I worked
for a few years on maintaining the test framework that comes with
MySQL, before I moved back to doing Release Engineering.
Now I'm part of the MySQL RE team which is responsible for building
and releasing MySQL and other associated products on all the platforms
we deliver for, plus we run the large in-house automated build and
test farm in the lab in Trondheim, Norway where I'm also located.
It took a little time to get this (and myself) ready but future
updates should come much faster.
MySQL Release Engineering
I reported the large memory leak in clock-applet:
(TLDR: clock-applet grows by 1GB/day when reporting weather)
Since clock-applet is a default install on every Fedora, I thought this
would be widely reported---it essentially makes the system unusable
within a day or two if you run into this problem---but that doesn't
seem to be the case. I guess people don't see it because nobody
Anyway, I am looking for a way to debug this: I tried attaching GDB to
the running process but the results are unreliable (see BZ). I couldn't
figure out how to run valgrind on the executable: it has to be run in
the context of the Gnome panel, so how do I tell it to run 'valgrind
/usr/libexec/clock-applet', and how do I get access to the results?
Is there another way?
I co-maintain a package that contains a library that is used as module
for a server.
The 32 bits version of this library is pushed automatically into the 64
bits repositories (i.e. in epel6),
which doesn't make much sense, since the 64 bits version of the server
won't run with the 32 bits
This wouldn't be a big problem, but the pushed 32 bits rpm has a dependency
on the 32 bits server, so then I will get complains (with reason) about
the broken package.
globus-gridftp-server-progs is the server, and dpm-dsi is the module.
So my question is: how should I approach this? I got some suggestions in
Is there any way I can prevent this rpm from being copied into the 64
On 2013-04-23 18:19, Tom Callaway wrote:
> On 04/23/2013 12:05 PM, Alec Leamas wrote:
>> Just a double check: whether I symlink or patch the css files, the
>> system path must be accessible for the web app. Is this really true in
>> general, isn't it depending on the web server configuration?
> Hmm. I think if you couldn't use the system copy for those technical
> reasons... well, there is a nasty way to do it with triggers to handle
> copying, but I'm not sure I can recommend that in good conscience.
> You could simply copy the font in a %post scriptlet, but if it ever got
> updated, you'd be using an old copy. If you copy it from BuildRequires,
> it would only get updated on new builds, but I think that method might
> be the simplest. You'd need to ask for a bundling request, but I'm
> pretty sure I'd support it.
> Fedora Project
Hm... unless there is more input on this I'll go for the BuildRequires +
bundling exception. This will take some time, have some fonts to package.
There will probably be more of this, fedora-review is updated with a new
test looking for bundled font files.My gut feeling is also that there
are some other bundled fonts in existing packages...
we have two kernels build on F18 that fix security problems and in F17
kernel-3.8.8-100.fc17 still in updates-testing and kernel-3.8.8-102.fc17
is not even in updates testing, shouldn't this kernels be push to
stable , due a security fixes ?
Sérgio M. B.
In a large package (openerp7) I have found some bundled .ttf and .otf
font files. One of these (Inconsolata) seems to exist in Fedora as
levien-inconsolata-fonts, the others (see below) I cannot find with a
The fonts are parts of specific addons (a. k. a. plugins). They are
referenced with explicit paths in various .css or css/* files.
The entypo-webfont.ttf seems to have a working upstream
I cannot find an upstream for mnmliconsv21-webfont.ttf, hint is that
it's generated by "Font Squirrel" ?!
There seem to be an upstream for zocial-regular-webfont.ttf, at
https://github.com/adamstac/zocial, providing a woff file.
Now, what should I do with these? Packaging GL tells me to "avoid"
bundling ttf/otf files. What's this in this case?
Utterly confused. Any hint, out there?