one of the updates I am preparing is supposed to replace some of the
folders with symlinks. Unfortunately, this leads to rpm cpio: rename
errors upon an update attempt. Is there a standard way of dealing with this?
the Samba Team has announced  that it will remove SWAT from the Samba
Suite. SWAT is unmaintained and has the most security bugs.
I plan to remove the samba-swat subpackage in Fedora 18, 19 and rawhide as
soon as it gets removed from the current Samba development tree.
Andreas Schneider GPG-ID: 8B7EB4B8
Red Hat asn(a)redhat.com
Samba Team asn(a)samba.org
It looks like all of the gnome games are still at v3.6.1 in Fedora 19...
I guess because they were split into multiple packages upstream. I guess
it's too late to get these into F19 since they are basically new
packages now, but I wanted to give a heads-up since they're still at
v3.6.1 in rawhide as well.
>From time to time, when setting up virtual machines for testing, I miss a
fast way to install the minimal set of packages which allows me to boot
into the desktop of a desktop environment. Currently, I do a minimal
install, then install some core component, i.e. gnome-shell, and then hunt
the logs to find out which other packages are missing.
So, what about creating groups for the various desktop environments which
pull in basesystem + xorg + mesa drivers + displaymanager + bare desktop
Advantages I see are:
* Users can quickly set up test environments for various desktop
* It would make side-by-side installation of desktop environments more
* It might help considering enabling the yum option
"clean_requirements_on_remove=1" by default, since even if something goes
wrong, the user will not end up with a missing desktop next time he or she
* It might help fixing some package dependencies
The Fedora Packaging Committee has one open seat and is accepting
submissions from interested candidates to serve on the FPC.
The FPC would like to thank Rex Dieter for his service, as he is
stepping down after several years.
This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also rewriting drafts
(sometimes from scratch) to resolve the issue in a more acceptable
fashion. Additionally, the FPC reviews bundling exceptions (and UID/GID
soft static assignment). The FPC meets on IRC weekly, Wednesdays at 1600
UTC, for approximately an hour. FPC members serve for as long as they
are willing, there are currently no term limits. All decisions are voted
on using a +1 (for), 0 (abstain), and -1 (against) mechanism, and all
decisions must be approved by a majority (+5). FPC Meetings do not
happen if quorum (5) is not present.
Candidates who are interested should provide the following details to
the FPC for consideration, by emailing it directly to me
(tcallawa(a)redhat.com). The FPC will consider all candidates, but
strongly prefers candidates who have extensive experience packaging in
Fedora. We will accept applications for the next week (deadline
Wednesday Apr 24, 2013).
Main area of packaging interest/expertise:
Reason(s) for wanting to join the FPC:
Thanks in advance,
devel-announce mailing list
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