Few days ago I started to get very usefull notifications that my
critical package, mingetty-1.08-6.fc13, `has been in 'testing' status
for over 2 weeks, and has yet to be approved.'
I doubt such mails help me as the package maintainer, because according
current Updates policy
<https://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path...>, I can only wait to some (proven) testers to test my package.
I think better place to send such allerts is proven-testers mailing list
/ alias (does not exist amazingly) or
<test-announce(a)lists.fedoraproject.org> mailing list.
I'd like to request persons reposnsible for forcing and implementing
Update Policy and bodhi notification system to re-eavaluate current
configuration in spot of this concerns and to make package update
process more friendly for all involved people.
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