A few days ago I upgraded my main workstation to F21 and I've noticed a few
annoying glitches, but I don't know if they are all worth reporting and
against which components they should be reported.
1. Window size and position:
While some applications start with their last window size and placement,
others do not; among them, most notable is firefox. It usually starts
maximized and then switches to something like a 7:2 ratio. When it is
maximized and then unmaximized, it never returns to its original size.
2. Random rearrangement of icons on the desktop:
I have organized my current projects and things to do in a dozen folders on
my desktop, arranged in a grid. So far, this has happened to me three
times: Upon logging in, some of them were taken out of the grid and
randomly placed all over the desktop.
3. Icon inconsistencies in the message tray:
Some icons are 48x48, others 22x22 and others are not displayed at all. In
there are actually 8 icons: a seahorse notification that a signature was
good, solaar, dropbox (I don't know if our package is to blame or theirs),
mail-notification, spideroak, gnote, nut monitor and easystroke.
Now, I know I should report this to the maintainer of each package and some
have already been reported in BZ, but given the upcoming change to GNOME's
notification system, will these issues persist? Is it worth their time?
4. Settings migration was inconsistent:
While most of my settings from the previous version of GNOME were preserved
after the upgrade to 3.14.2, others were not; e.g. the window action key
was preserved, middle click on the titlebar to lower a window wasn't.
I plan to upgrade libicu to 54.1 in rawhide end of this week or next
week, which as usual comes with a soname bump. David Tardon will help
with rebuilding the dependent packages.
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
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.