Due to the requirement for contributors to sign the FPCA by Thursday of last
week, certain package owners who haven't yet signed will be removed from the
packager group soon. When that happens, the packages that they own will be
To try and minimize the problems this could cause, I'm publishing the
current list of packages to be orphaned and will start reassigning owners if
someone asks to take them over. We want to make sure that important
packages are not going to be orphaned by this change. We're planning on
removing people from packager and orphaning packages on Thursday if all goes
The list of packages being orphaned are listed below and the list of
packages with first level dependencies will be attached. Note that the
dependency list could be incomplete in two ways:
1) Since I'm using source package names, we don't capture things that dep on
2) The list does not follow the dep chain out to see if something relies on
something that relies on something that relies on a package that's being
Please reply to this thread if you'd like to take any packages or ping me on
IRC and I'll reply to this thread with what packages have been taken.
(Needed since we aren't orphaning in the pkgdb until Thursday so you need
a cvsadmin to reassign ownership for now).
I've just pushed python-argparse-1.2.1 to EPEL5 and EPEL6. This should be
a backwards compatible change. It does, however, change licensing from
Apache-2.0 to Python. Python license is more permissive than Apache license
and is GPLv2 compatible (where Apache is not) so this shouldn't cause anyone
problems. If you had a GPLv2+ program that had to be distributed as GPLv3+
because it used python-argparse on EPEL-5 and EPEL-6 you can re-evaluate
the licensing situation now.
Note, this update isn't shipped in Fedora 14+ as argparse is part of
python-2.7's stdlib. The stdlib is already licensed under the Python
license so this is just making the licensing situation more consistent
across our supported releases.
I've recently been packaging applications for the fedora medical
initiative. There are quite a few of them. If you have some time to
spare, please review a few (or just one). Even if you're not a sponsored
packager, I encourage you to please review them unofficially. It will
improve your understanding of the guidelines, and also pick out quite a
few errors and help me :)
Of course, if you accept a ticket, I will review a package for you in
Please have a look at the following url:
The ones needing reviews are the ones in the "depends on" field.
A better link to look at would be this one:
Arindam Ghosh wants to stay in better touch using some of Google's coolest new
If you already have Gmail or Google Talk, visit:
You'll need to click this link to be able to chat with Arindam Ghosh.
To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Arindam Ghosh, visit:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
that are relevant to the content of your messages
All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
We're working hard to add new features and make improvements, so we might also
ask for your comments and suggestions periodically. We appreciate your help in
making our products even better!
The Google Team
To learn more about Gmail and Google Talk, visit:
(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).
Join us on Friday to celebrate July with another in our series of VFADs!
This is an awesome opportunity to participate in improving support for
ARM processors, and to learn about architecture bootstrap. Last week, we
successfully added a number of new packages to our bootstrap filesystem
image and got closer to having a working F15 environment we can use to
build official RPMs with hard floating point, on ARMv7 systems.
It's never too soon or too late to help, and you can participate at any
time, by following the instructions linked below - no need to wait for
us, just let us know when you've got bits we can pull into the official
rootfs (which is managed in git) we are building to bootstrap the rest.
Don't forget that you can find out a lot more about the Fedora ARM
project, and about getting involved by visiting the wiki:
Which also contains links to canned images you can use to drop onto your
own ARM system and hit the ground running without any installation time.
--- Fedora ARM hardfp activity days ---
We are hosting another Fedora 15 hardfp Virtual Fedora Activity Day on
Friday, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this
session is to co-ordinate the bootstrap of F15 hardfp (hardware floating
point). Going forward, the proposal is that these be on Fridays.
You can find a lot more detail here, along with all the pre-reqs/bits:
That page contains links to the general instructions on:
Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME
or group name branch so that we can track who is doing what, and more
easily back out changes if you/we discover a problem with your setup.
I have release 3.0-0.rc3.git0.3.fc16.x86_64-3.0.0 Version Code 196608
running on a Gateway netbook LT3101u CPU - AMD ATHLON 64 ATI Radeon graphic
I am getting Mircocode : CPU0: family 15 not supported the udevd is in an
endless loop burning CPU and Virtual memory resouces
How can I add the module to support the CPU and end the loop. while one of
the udev rules initiates the device
One of the package review guideline says
MUST: The sources used to build the package must match the
upstream source, as provided in the spec URL. Reviewers should use
md5sum for this task.
Past couple of days, I've been reviewing the python grapefruit package
at - https://bugzilla.redhat.com/show_bug.cgi?id=716808
and the thing is, the spec file provides an - $ svn export -r 31 ... - command to pull the sources and create a tarball using $ tar -czvf ...
But as it turns out, it seems, if you create a tarball from the *very same* sources on two different machines, they don't match. As in the md5sum for the two tarball differs.
Please try this simple test
$ echo 'Hello, world' > 1
$ tar -cjf 1.tar.bz2 1
$ scp 1.tar.bz2 to a different machine.
$ ssh to that same machine
$ tar -xjf 1.tar.bz2 -C .
$ tar -cjf 2.tar.bz2 1
$ md5sum 1.tar.bz2 2.tar.bz2
Could someone suggest how to fix this glitch? Or the guideline above??