Updated Galician translations
Prevent crash from pressing Esc in dialogs with number entry (#682658)

Steps to reproduce:
1) Open any of these dialogs: Create New Partition, Resize/Move or
   Paste;
2) Update any of the following numeric entry fields to a different value
   using the keyboard: Free space preceding, New size or Free space
   following;
3) Press [Esc] key;
Gparted crashes.

What is happening is that the [Esc] key is leading to the dialog being
closed and calling the ~Dialog_Base_Partition() destructor.  However
after this the GTK widget is calling the on_spinbutton_value_change()
registered callbacks for the change to the other two values, on the now
just deleted object.

Fix by disconnecting the change notification callbacks in the
destructor.

Closes bug #682658 - GParted crash by pressing Esc in dialogs with
                     number entry
Add creation of LVM2 PVs (#670171)

Add creation of Physical Volumes specifying LVM2 metatdata format:
    lvm pvcreate -M 2 /dev/DEVICE

Also set the partition type to identify its contents as LVM.  Note that
libparted treats every partition type as a file system except LVM which
it treats as a flag, hence GParted displaying "lvm" in the Manage Flags
dialog.  Never the less libparted set the partition types correctly.
For MBR partitioning the type is 8e "Linux LVM" and for GPT partitioning
the type is E6D6D379-F507-44C2-A23C-238F2A3DF928.  Setting the partition
type as LVM is not strictly required as LVM2 scans the contents of all
partitions looking for PVs, but it is best practice.

Bug #670171 - Add LVM PV read-write support
Enable LVM2 VG activation / deactivation (#670171)

In the Partition menu enable activation / deactivation of the LVM2
Volume Group of which the Physical Volume is a member.

Bug #670171 - Add LVM PV read-write support
Add LVM2 PV resize, check and move operations (#670171)

Copy operation for LVM2 Physical Volumes is deliberately not implemented
because it doesn't fit with how LVM2 works and is not safe in the
general case without an understanding of its internals.  See comment in
lvm2_pv::copy() for more details.

Bug #670171 - Add LVM PV read-write support
Add file system specific remove() methods (#670171)

This commit only adds a remove() method to every file system and an
optional call to it in the relevant operations.  All remove() methods
are no operations and not enabled.

The remove() method provides explicit controlled removal of a file
system before the partition is deleted or overwritten by being formatted
or pasted into.  When implemented, it appears as an extra step in the
relevant operation.  The file system specific remove() method is
explicitly allowed to fail and stop the operations currently being
applied.

This is different to the existing erase_filesystem_signatures() which
wipes any previous file system signatures immediately before a new file
system is written to ensure there is no possibility of the partition
containing two or more different file system signatures.  It never fails
or reports anything to the user.

NOTE:
Most file systems should NOT implement a remove() method as it will
prevent recovery from accidental partition deletion.

Bug #670171 - Add LVM PV read-write support
Implement LVM2 PV remove() method (#670171)

Implement remove() method so that the LVM2 metadata is updated to
reflect the removal of the LVM2 Physical Volume as well as removing the
signature from the PV before the partition is deleted or overwritten.
    lvm pvremove /dev/DEVICE

Also specifically force the removal of the PV when it is a member of a
Volume Group so that it will succeed.

RATIONAL:

If the PV was not removed before the partition was deleted or
overwritten, LVM2 would be left in a broken state with metadata
describing missing PVs for any partially deleted VGs.  This leaves the
user needing to perform recovery of a lost PV, which required in depth
understanding of LVM2 and is beyond the scope of what GParted can
currently provide.

The alternative is to use the pvremove command to instruct LVM2 to
remove the PV and update LVM2 metadata to reflect the removal of the PV.
For PVs which are a member of a VG this includes forcing the removal.
This has the impact of making recovery from accidental deletion of a
partition containing a PV irrecoverable.  GParted is not able to recover
this situation anyway because Device -> Attempt Data Rescue, using the
gpart command, is not able to detect the signature of an LVM2 PV.

Choose to remove the PV, forcibly if required, rather than potentially
leave LVM2 with missing PVs.

Bug #670171 - Add LVM PV read-write support
Add LVM2 VG member details to the Information dialog (#670171)

For LVM2 Physical Volumes display the Volume Group name and all the
members in the Information dialog.

Bug #670171 - Add LVM PV read-write support
Add warning dialog when deleting non-empty LVM2 PVs (#670171)

When attempting to delete a non-empty LVM2 Physical Volume (one which is
still a member of a Volume Group) display a warning dialog which
includes the VG name and a list of the PV members to allow the user to
make an informed choice whether to go ahead and perform the deletion or
cancel to the operation.  This dialog is displayed when a partition
containing a PV is being deleted or being overwritten by being
reformatted or pasted into.

Bug #670171 - Add LVM PV read-write support
Add fallback implementation to new delete LVM2 PV warning dialog (#670171)

The new delete non-empty LVM2 Physical Volume warning dialog uses
Gtk::MessageDialog::get_message_area() in the display of Volume Group
members.  This function was new in gtkmm 2.22, released September 2010,
which is not available in a number of current distributions including:
Unbuntu 10.04 LTS, RHEL 6.3, SLES 11-SP2, Debian 6.0.

Implement fallback method to display the VG name and member PVs in the
warning dialog for when get_message_area() is not available.

Bug #670171 - Add LVM PV read-write support
Rename *toggle_swap_mount* -> *toggle_busy*

Rename functions and a variable to use a generic term for the menu item
which changes the busy state of partitions now that it also activates
and deactivates LVM2 Physical Volumes as well as mounting and unmounting
file systems and enables and disables swap partitions.
Only lookup LVM2 VG name once in Display_Info()

For LVM2 Physical Volumes the Volume Group name was looked up multiple
times, sometimes from the secondary location of the mount point and at
other times from the primary location in the LVM2_PV_Info class.  Just
lookup the VG name once from the primary location.
Remove redundant lines from LVM2_PV_Info functions

Splitting of each cache string on comma "," is performed in
get_pv_attr_by_row() and not needed in the caller functions.
Update declarations of some LVM2_PV_Info member functions

Add const qualifier to get_pv_attr_by_path() and get_pv_attr_by_row() as
they only access member variables read-only.

Make lvm2_pv_attr_to_num() a static member function as it doesn't access
any member variables.
New LVM2_PV_Info::bit_set() testing VG and LV attribs "bits"

Abstract repeated code used to test the setting of individual LVM Volume
Group and Logical Volume "bits" attributes into bit_set() function.
Remove outdated FIXME comment from active_partitions_on_device_count()

Active LVM2 PVs have the partition class busy member set in
GParted_Core::set_device_partitions() just as mounted file systems do.
This is a basic requirement for GParted so that it only manipulates
partitions and contained file systems when they are not in use.
Remove full stops from the end of primary text in dialogs

The GNOME HIG, 3.4.1 "Alert Text" states:

    ...  The primary text is punctuated in 'newspaper headline' style,
    that is, it has no terminating period, but it may have a terminating
    question mark.

http://developer.gnome.org/hig-book/3.0/windows-alert.html.en#alert-text
Correctly show multiple "unknown device" LVM2 VG members (#670171)

If an LVM2 Volume Group has two or more missing Physical Volumes, the VG
is displayed as only having one "unknown device" because
get_vg_members() only adds unique names to the list of members.

    # lvm pvcreate /dev/sda11 /dev/sda12 /dev/sda13
    # lvm vgcreate Test-VG1 /dev/sda11 /dev/sda12 /dev/sda13
    # wipefs -a /dev/sda12
    # wipefs -a /dev/sda13
    View partition information in GParted

The simplest fix would be to include the PV's UUID in the cache of LVM2
information and add PV names based on unique UUIDs being a member of the
relevant VG.  Unfortunately "lvm pvs" seems to have a bug when
displaying Logical Volume attributes, and there are two or more missing
PVs, which causes one of the PVs to be displayed multiple times, rather
than displaying each PV once.

Without LV attributes, every PV is listed:

    # lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr 2> /dev/null
      PV,PV UUID,VG,Attr
      /dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-
      unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-
      unknown device,1ESORF-7wlR-0tnO-fy2z-nOL1-MrnJ-2O5yjK,Test-VG1,wz-pn-

With LV attributes, one missing PV is repeated:

    # lvm pvs --nosuffix --separator , --units b -o pv_name,pv_uuid,vg_name,vg_attr,lv_name,lv_attr 2> /dev/null
      PV,PV UUID,VG,Attr,LV,Attr
      /dev/sda11,pJ3R51-AOPP-rKlr-CKCT-nfPS-G5FP-B5Vyjm,Test-VG1,wz-pn-,,
      unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,
      unknown device,Y72oSm-uBcE-ktZL-OIFA-Q129-Uv1B-x5IsrA,Test-VG1,wz-pn-,,

Also "lvm vgs" and "lvm lvs" don't display anything when including both
VG and LV attributes.

Instead query the LVM2 information in two separate commands, one
querying PV attributes and one querying VG and LV attributes, saving the
results in lvm_pv_cache and lvm_vg_cache respectively.

Bug #670171 - Add LVM PV read-write support
Implement common LVM2_PV_Info cache search and index functions

Create common cache search and index functions get_attr_by_name() and
get_attr_by_row() as the existing ones, get_pv_attr_by_*() and
get_vg_attr_by_*(), only differ from each other by the string vector
they use.
Disallow resizing of LVM2 PVs which are members of exported VGs (#670171)

When an inactive LVM2 Volume Group is exported it makes it unknown to
the local system, ready for moving the member Physical Volumes to
another system, where the VG can be imported and used.  In this state a
PV can't be resized.

    # lvm pvresize /dev/sda10
      Volume group Test-VG1 is exported
      Unable to read volume group "Test-VG1".
      0 physical volume(s) resized / 1 physical volume(s) not resized
    # echo $?
    5

Fix this by preventing resizing of such a PV.  This has been coded in a
generic way using new function filesystem_resize_disallowed() to
determine whether a file system is allowed to be resized or not.  For
a file system which can be resized, but is currently not allowed to be
resized, the behaviour is as follows:

1)  Pasting into unallocated space is limited to creating a new
    partition which is the same size as the copied partition.

2)  Resizing the partition is disallowed, only moving the partition is
    allowed.

3)  Pasting into an existing partition will only copy the file system.
    If the destination partition is larger a warning will report that
    growing the file system is not currently allowed.

4)  Checking a partition will also report a warning that growing the
    file system is not currently allowed.

This is exactly the same behaviour as for a file system which does not
implement resizing, except for a different warning message.

Bug #670171 - Add LVM PV read-write support