Here is this week's change to the Fedora Packaging Guidelines:
The systemd guidelines on naming unit files have been amended to tell
packagers how to make compatibility symlinks for alternate service names
should their service have had a different name in the past.
These guidelines (and changes) were approved by the Fedora Packaging
Many thanks to the Fedora Community, and all of the members of the FPC,
for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
devel-announce mailing list
My name is Andrew Nixon from Birmingham UK. I am looking to get involved in
helping to package for Fedora. I have a particular interest in scientific
applications / packages. I work in a small computer science group in a local
hospital, where we do not specialize therefore I have experience of
programming (mostly Java, C, Bash, and Python) as well as systems deployment
I am mostly involved in administering Solaris systems at work, although we
do work with some RHEL and Fedora systems as well. I have had a linux
install pretty much constantly at home for the last 10 years or so, all
though have never really contributed to the wider community (up until now).
In trying to report a bug about the totem-upnp package not working in
F15, I found that someone had already filed a bug report:
In it, the reason for it not working was totem-upnp was an *empty*
package. I checked on koji and while the build of totem and it
subpackages were completed, the build process seemed to have disabled
the upnp plugin because of a problem PyGTK vs. pygobject issue and
built an empty package.
I can understand the whole build not being killed over an optional
plugin. However, should koji build an empty package? I would think
that koji should just not make that subpackage at all. Then at least
people will not be tricked into updating a working package to an empty
one should this slip though QA/testing ... which I am guessing this
particular package has.
Maybe even some indication that there was a successful build but with
some caveats listed on the package build page:
Are there other empty packages out there?
some minutes ago i tried a dist-upgrade F14->F15 per yum on
a virtual machine with 512 MB RAM
not enough memory?
something goes terrible wrong here if yum needs hardware
with > 512 MB RAM without GUI, well since this is a test-machine
i can raise the memory, but there are many usecases for servers
with 512 MB they can not be updated with DVD/Preupgrade and
not need more memory for normal operations
Setting up and reading Presto delta metadata
| 2.5 MB 00:01
| 54 kB 00:00
Processing delta metadata
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in <module>
File "/usr/share/yum-cli/yummain.py", line 258, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 196, in main
return_code = base.doTransaction()
File "/usr/share/yum-cli/cli.py", line 456, in doTransaction
problems = self.downloadPkgs(downloadpkgs, callback_total=self.download_callback_total_cb)
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1756, in downloadPkgs
File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 183, in run
func(conduitcls(self, self.base, conf, **kwargs))
File "/usr/lib/yum-plugins/presto.py", line 581, in predownload_hook
(problems, more) = downloadPkgs(conduit, pinfo, download_pkgs)
File "/usr/lib/yum-plugins/presto.py", line 303, in downloadPkgs
delta = getDelta(po, presto, conduit, conf_mp)
File "/usr/lib/yum-plugins/presto.py", line 226, in getDelta
if not verifyDelta(delta['sequence'], po.arch):
File "/usr/lib/yum-plugins/presto.py", line 60, in verifyDelta
"-C", "-s", sequence], close_fds=True):
File "/usr/lib64/python2.7/subprocess.py", line 486, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/lib64/python2.7/subprocess.py", line 672, in __init__
File "/usr/lib64/python2.7/subprocess.py", line 1111, in _execute_child
self.pid = os.fork()
OSError: [Errno 12] Nicht genügend Hauptspeicher verfügbar
Mit besten Grüßen, Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / software-development / cms-solutions
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/http://www.thelounge.net/signature.asc.what.htm
On 05/25/2011 04:30 AM, Albert Strasheim wrote:
> Hello all
> It seems the openfabrics.org people are planning their OFED 1.6
> release which includes most of the useful InfiniBand packages for
> middle of September 2011.
> This seems to coincide nicely with the Fedora 16 release schedule.
> The InfiniBand packages in Fedora currently seem to be quite a bit
> behind the packages that will be included in OFED 1.6.
> What is the way forward to get the latest InfiniBand packages into Fedora 16?
I just need some time to get updates in. However, that being said, I
totally ignore OFED. I pull packages from upstream and I do *not* get
anything from OFED. They shipped a custom hacked, incompatible
libibverbs for over 2 years before their custom hacks were reviewed and
then modified and then accepted upstream. That ended my relationship
with their offerings.
Doug Ledford <dledford(a)redhat.com>
GPG KeyID: CFBFF194
Infiniband specific RPMs available at