mpfr-3.0.0 is now build to rawhide branch and soname is bumped to 4.0.0
MPFR 3.0.0 is binary incompatible with previous versions and also is not
completely API compatible.
The most important changes from versions 2.4.* to version 3.0.0
* MPFR is now distributed under the GNU Lesser General Public
License version 3 or later (LGPL v3+).
* Rounding modes GMP_RNDx are now MPFR_RNDx (GMP_RNDx kept for
* A new rounding mode (MPFR_RNDA) is available to round away from zero.
* Functions mpfr_random and mpfr_random2 have been removed.
* mpfr_get_f and mpfr_get_z now return a ternary value.
* a lot of new functions
full list of changes is on:
The packages which depends on mpfr should be rebuild against the new
versio. The list is:
Ivana Hutarova Varekova
After yesterday's updates, on login to Gnome a error message shows up
saying that "CPU Frequency scaling is unsupported", and claims either
misconfiguration or just isn't supported. It used to word fine before
that. In /var/log/messages nothing shows up.
Intel(R) Core(TM)2 Duo CPU T5670(a)1.80GHz, stepping 13.
I tried my older kernels (kernel-2.6.36-2.fc15.x86_64,
kernel-2.6.36-4.fc15.x86_64, kernel-2.6.36-5.fc15.x86_64 here) and
downgraded gnome-settings daemon (only thing that looked remotely relevant
in the updates), no changes.
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
Currently the nfs-utils-lib package has two libraries,
libnfsidmap and librpcsecgss. librpcsecgss is no longer
needed since it was functionally replaced by libtirpc and
now that I'm the upstream maintainer of libnfsidmap,
I would like make that its own standalone package.
So what/where are the steps I need to take to retire
nfs-utils-lib and create a new libnfsidmap package...
Presenting wicked network configuration
This is the first public release of wicked, an experimental framework
for network configuration.
You may ask, don't we have enough of those already? Don't we have
NetworkManager, connman, netcf, and a few more?
The point I started from was the desire to unify what is usually provided
through the traditional ifup script kudzu, with some of the more desktop
oriented services provided by facilities like NetworkManager. I also
wanted to move towards a more powerful set of functionality written in
C, which is able to subsume functionality provided by ifconfig, ip(8),
brctl, vconfig, ethtool, etc, and be able to drive these through an
extensible XML representation of the network configuration.
Kind of the Grand Unified Theory of network configuration :-)
Right now, this implementation uses a daemon service and a command
line utility. These two communicate securely via a local UNIX socket,
allowing the server to validate the client's user id.
The server offers a REST interface to various aspects of network
configuration. The client application uses REST calls to retrieve
interface configuration and status, or to reconfigure interfaces.
The path space used by the API can be extended to cover other aspects
of network configuration as well, such as reading, writing and restoring
the resolv.conf file.
After having hacked on this for a while, I want to release this to
the community for feedback.
If you're interested in finding out more, you will find a README
and several manpages in the source code, which is available from
Olaf Kirch <okir(a)suse.de>
Neo didn't bring down the Matrix. SOA did. (soafacts.com)
Olaf Kirch - Director Server (okir(a)novell.com)
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
Yesterday I tagged a large number of my builds into dist-f14-updates.
These were all builds that had no changes from the previous stable build
except for buildroot content. These will be "live" as of the next
(which may have already happened) updates push.
The remaining packages which need builds are:
ghostscript - twaugh - Build in updates-candidate
libglade-java - kasal - failed build
libgnome-java - kasal - failed build
libgtk-java - kasal - failed build
python - dmalcolm - build in updates-candidate
syncevolution - pbrobinson - build in updates-testing
So we need maintainer movement on ghostscript and python, and we also
need some help getting the three -java packages to build.
At this point I'm going to turn over this project to Dennis Gilmore to
follow up on.
Fedora -- Freedom² is a feature!
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet
installed by default as part of @base, nor is it used by anaconda, but
those changes will come over the next few days.
biosdevname, on at least Dell 10G and newer, and HP 6G and newer
servers, provides "better" BIOS-suggested names for embedded NIC
ports, and NIC ports on add-in PCI cards. If you have existing names,
as defined in /etc/udev/rules.d/70-persistent-net.rules, those names
will continue to be used, and biosdevname won't ever be invoked.
Likewise, if you have device names assigned to MAC addresses in
/etc/sysconfig/network-scripts/ifcfg-eth*, biosdevname won't be
invoked. But going forward, on new installs, biosdevname _will_ be
used to change the names.
The naming scheme is thus:
Embedded ports: em<port>
PCI cards: pci<slot>#<port>_<virtual function> (the latter on SR-IOV
and soon Network Partitioned (NPAR) devices).
If you have a Dell or HP server, and would like to try it out, please:
# yum install biosdevname
# rm /etc/udev/rules.d/70-persistent-net.rules
# sed -i -e '/^HWADDR=/d' /etc/sysconfig/network-scripts/ifcfg-eth*
# rmmod <your ethernet drivers>
# modprobe <your ethernet drivers>
(or reboot instead)
# ifconfig -a
will show all the devices with the new naming scheme.
Dell | Office of the CTO
I'm orphaning awstats, a web log file analyzer.
If anyone's interested...
http://aurelien.bompard.org ~~~~ Jabber : abompard(a)jabber.fr
In God we Trust. All others must submit an X.509 certificate.
It's that time of year again, although there seems to be an off-by-one bug
in the calendar system causing some inconsistency in the timing wrt last
Anyway, before going to beta and starting the inevitable Fedora Feature
process, we'd like some extra preliminary testing to catch out any major
issues early on.
The alpha isn't supposed to eat your system alive or anything, but proceed
with appropriate cauting, backing up the rpmdb etc, as usual.
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
and Fedora compatible SRPM(s) can be found at
In particular, I'm interested in feedback on the new, pluggable and
enhanced dependency extration system. Documentation is scarce at the
moment but some background and examples can be found here:
Note that the current SRPM is missing gstreamer plugin, cups driver
and automatic "devel-symlink" dependency generation, on purpose: the
highly application-domain specific gstreamer + cups bits can now be fully
moved out of rpm to gstreamer-devel etc, eliminating the need for
embedding python inside /bin/sh scripts and such to avoid extra
dependencies. The devel-symlink generation will stay in rpm but will
probably change somewhat, it can be handled in a more generic fashion now.
Please report any oddities found, preferably to rpm.org Trac
at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific
P.S. Pjones, before you ask ;) The much wanted ordering-only feature is
not in the alpha, but is likely to make it into beta. The patch itself is
fairly trivial and non-intrusive, we're just trying to figure sane spec
syntax for it (discussion ongoing on rpm-maint)
- Panu -