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).
For the first time, Fedora release name have non-ascii and pelican
Could we consider change release name from "Schrödinger's Cat" to
"Schrodingers Cat" or other name that not have this additional
Sérgio M. B.
Just today i check updates, gnome-desktop3 was there, i didn't notice it but
it is following the gtk3 naming scheme, and, what i think is happening more
than desired, a lot of packages just kept going doing it.
I see an overuse or exploit or package names vs versions, which both terms are
very well defined, so should/might do it rpm.
I stated a problem, the solution is open.
I am proposing a rpm tag:
- Coexists: package-major
- Coexists: package-major.minor.bugfix
(whatever fill the technical details),
in the same spirit that Requires:.
I assume that tag does not exist, otherwise gnome-desktop3 would have a
coexist with gnome-desktop-2.* and package could be the same.
That fist writing got me to the issue that that would need 2 gnome-desktop.spec
(just counting 2.x and 3.x) which does not seems right. So the issue may/seems
deeper and is to be addressed at another level like keeping one gnome.spec but
being able to provide 2 coexisting versions.
The problem is stated again, the solution is open, hence the post.
Ugly to the eyes as gnome-desktop3 is, should not only be taken aesthetical,
but highlighting an issue. I hope fedora gets in a direction, hence rpm i
guess, where packages does not go name weird. Note, an user like me would do
rpm -qi gnome-desktop and see nothing, yet, guess rpm -qi gnome-desktop3, and
other lot of nightmares i can seem to oversee at a sight.
Perhaps, gnome-desktop3 will replace gnome-desktop (2.x implicit) i guess,
perhaps not, funny the package that triggers that discussion is one with such
a different paradigm that one might want to have both coexisting, fedora could
take a long time until getting rid of gtk2 or gtk3 naming cause of coexisting.
What do you think, worth the rethinking? Or good reasons to keep like that?
Just my ramblings, thanks.
I need some help/guidance on how to re-build a (normally) distributed
package (net-snmp) using the latest Fedora spec file, but using the
latest (upstream git head) version of the source; or alternatively,
the current Fedora version _with my_ fix applied.
You see, it may be some time before upstream 'officially' releases
the next version, let alone when Fedora (RHEL, SUSE, etc.) release
a new package too... but my production systems need the fixes now!
Who is the net-snmp package maintainer?
I was curious what is the most buggy  package in Fedora and I made
Click on "Total" and you get it sorted from most buggy to least buggy.
(I do not know if this sort flag can be made part of URL).
Lazy to click? Here is Top 10:.
Component NEW ASSIGNED TOTAL
Package Review 943 384 1327
kernel 884 118 1002
gnome-shell 619 15 634
anaconda 463 85 548
xorg-x11-server 439 15 454
yum 335 14 349
python 334 5 339
tracker 294 8 302
control-center 205 1 206
rhythmbox 202 1 203
And most overloaded assignee is:
again click on "Total".
Lazy to click? Here is Top 10:
Assignee NEW ASSIGNED TOTAL
nobody(a)fedoraproject.org 871 37 908
kernel-maint(a)redhat.com 680 63 743
xgl-maint(a)redhat.com 704 14 718
bnocera(a)redhat.com 635 20 655
otaylor(a)redhat.com 637 15 652
tbzatek(a)redhat.com 476 20 496
rstrode(a)redhat.com 460 28 488
mclasen(a)redhat.com 398 25 423
dakingun(a)gmail.com 373 9 382
dmalcolm(a)redhat.com 358 7 365
 I know there can be plenty of metrics, I just used this one.
Red Hat Systems Management Engineering
-----BEGIN PGP SIGNED MESSAGE-----
it was requested in https://fedorahosted.org/fesco/ticket/1004 that
we do a mass rebuild for Fedora 19 for
Additionally we will be mass patching config.guess and config.sub to
support aarch64 in preperation for 64 bit arm support
we will start the mass rebuild on 2013-02-12
This is a heads up that it will be done in a side tag and moved over
when completed. We will be running scripts to output failure stats.
please be sure to let releng know if you see any bugs in the reporting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
devel-announce mailing list
XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let inode numbers creep past 2^32 as well.
While most applications don't care one bit about st_ino returned from a stat() call, the sad fact is that you'll get EOVERFLOW from stat32 if the inode number is too big to fit in 32 bits, even if you just wanted to get the file size.
I have a script (http://sandeen.net/misc/summarise_stat.pl) which Greg Banks wrote; it can check a path or list of filenames for binaries which contain non-64bit-safe stat calls. A quick look over my F18 install finds the situation to be only slightly in favor of executables using 64-bit variants:
# ./summarize-stat.pl /usr
270229 91.5% are scripts (shell, perl, whatever)
22633 7.7% don't use any stat() family calls at all
913 0.3% use 32-bit stat() family interfaces only
1335 0.5% use 64-bit stat64() family interfaces only
73 0.0% use both 32-bit and 64-bit stat() family interfaces
and it's not just weird obscure packages:
# ./summarize-stat.pl `rpm -ql sendmail`
69 78.4% are scripts (shell, perl, whatever)
2 2.3% don't use any stat() family calls at all
17 19.3% use 32-bit stat() family interfaces only
Anyway, if you want to check your package(s) and maybe make them 64-bit-stat safe, the perl script above might help. It's more than just -DFILE_OFFSET_BITS=64, since you'll need to be sure not to overflow any large values you get back from stat64 etc.
Might be nice to get out ahead of this before, say, btrfs comes into wide use. I don't know if there could be any more of a formal effort in this direction?
p.s. here's a list of what was on my system that turned up hits:
Firstly, Please CC me into replies as I'm not subscribed to this list.
I'm trying to confirm that Fedora 18 has enabled trim for XFS
filesystems. I have added discard to the mount options in /etc/fstab -
however I do not see it when looking at the output of 'mount':
UUID=b95a7b45-d197-45c0-a7d6-c13f930a38b3 / xfs
defaults,discard 0 1
/dev/sda2 on / type xfs (rw,relatime,attr2,inode64,noquota)
fstrim shows that trim is at least enabled, but I am unable to confirm
if it is done in realtime, or I am required to run fstrim manually.
# fstrim -v /
/: 48919015424 bytes were trimmed
Can anyone share some insight into this?
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299