I notice that Debian recently [since July 2014] started to recommend
that packagers run autoreconf on build. Their reasons are given here
and seem to be good ones:
In the interests of fairness I can think of two drawbacks too:
- newer versions of (especially) automake have not always been
improvements, and some upstreams may wish to stick with older ones
- autoreconf is slow
Debian have probably hit most of the bugs by now, and I think this is
a good recommendation that perhaps Fedora packagers should be
encouraged to follow too. What do you think?
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
libmediaart in rawhide was upgraded to 1.9.0 (libmediaart-2.0) which
is an API/ABI incompatible break.
The dependencies - tracker and grilo-plugins have patches in upstream
git to adjust to the change and hopefully will be built for it in
rawhide later today.
I'll rebase TBB to 4.3u2 next week. A scratch build is here:
Client packages are as follows, their owners are CC'd.
The soname didn't change. I reviewed the actual changes using abidiff,
and the only thing reported that I think is an actual ABI violation is
insertion of one virtual method. I don't think that's real however:
So the current plan is to simply update TBB and not even bump and
rebuild clients, but if you could take your packages for a spin with the
scratch builds, and report back, that would be great.
= Proposed Self Contained Change: Vagrant =
Change owner(s): Josef Stribny <jstribny(a)redhat.com>
Provide Vagrant http://www.vagrantup.com/ with the libvirt provider
as a default.
== Detailed Description ==
Vagrant is an automation tool used to manage development environments
using virtualization and configuration management tools. It allows
developers and teams to work on their projects and test them in an
environment similar to production. Historically, Vagrant had a
dependency on VirtualBox, but the newer versions have a plugin system
allowing it to work with other virtualization technologies, including
libvirt. The plan is to package Vagrant with the support for libvirt
(coming as vagrant-libvirt plugin) replacing VirtualBox as a default
== Scope ==
* Proposal Owners: Initial work has been done in for Vagrant on F20
in a Copr repository. Patches and quick fixes should be cleaned up
or revisited. Also we need to depend on newer version of libvirt
through rubygem-fog. Some commits for that are already in upstream
repositories for vagrant-libvirt and fog. See upstream issue for
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
devel-announce mailing list
my name is Vojtech Trefny and I am from the Czech Republic. I have been
using Linux and OSS for nearly ten years now. I spent most of this time
in Ubuntu community doing non-development work (localisation,
documentation, advocacy...), but I switched to Fedora in 2013, joined
Red Hat later that year as an intern and finally last year's october
moved to the Installer team where I work on storage, mostly on a small
application called blivet-gui.