# Generated by Makefile. Do not edit.

2021-07-19  Curtis Gedak <gedakc@gmail.com>

    ==========   gparted-1.3.1   ==========

2021-07-15  Philipp Kiemle <philipp.kiemle@gmail.com>

    Update German translation

2021-07-14  Wolfgang Stöggl <c72578@yahoo.de>

    Update German translation

2021-07-14  Claude Paroz <claude@2xlibre.net>

    Updated French translation

2021-07-14  Ngọc Quân Trần <vnwildman@gmail.com>

    Update Vietnamese translation

2021-07-13  Daniel Șerbănescu <daniel@serbanescu.dk>

    Update Romanian translation

2021-07-13  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2021-07-12  Enrico Nicoletto <liverig@gmail.com>

    Update Brazilian Portuguese translation

2021-07-12  Baurzhan Muftakhidinov <baurthefirst@gmail.com>

    Update Kazakh translation

2021-06-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Copy XFS UUID when copying the file system (!85)
    
    For the same reason as in the previous commit, the UUID is copied when
    copying every file system type except for XFS, where a new XFS is
    created with a new UUID.
    
    Again preview of the copy operation expects the UUID to be copied.
    (Look in Partition > Information of the source and pasted partitions
    before the operation is applied).
    
    Fix as before by specifying the desired file system UUID when creating
    the new XFS as part of the copy operation.
    
    However there is an extra complication.  The XFS kernel driver refuses
    to mount a file system with a duplicate UUID of an already mounted XFS.
    
        # mkfs.xfs -L xfs_copy /dev/sdb1
        # mount /dev/sdb1 /mnt/1
        # tail -2 /var/log/messages
        Jun  3 21:41:24 localhost kernel: XFS (sdb1): Mounting V5 Filesystem
        Jun  3 21:41:24 localhost kernel: XFS (sdb1): Ending clean mount
    
        # /dev/sdb1: LABEL="xfs_copy" UUID="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" TYPE="xfs"
        # mkfs.xfs -L xfs_copy -m uuid="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" /dev/sdb2
        # mount /dev/sdb2 /mnt/2
        mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
               missing codepage or helper program, or other error.
    
               In some cases useful info is found in syslog - try
               dmesg | tail or so.
        # echo $?
        32
        # tail -1 /var/log/messages
        Jun  3 21:41:31 localhost kernel: XFS (sdb2): File system has duplicate UUID d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8 - can't mount
    
    Handle this specifying the needed option [1] when mounting the second
    XFS during the copy.
    
        # mount -o nouuid /dev/sdb2 /mnt/2
        # mount | grep /dev/sdb
        /dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
        /dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,noquota)
    
    Duplicating the UUID may seem troublesome, but it is being done:
    1.  To make the GParted copied XFS be as much a clone as possible, to
        match what is does with other file systems.
    2.  It has a valid use case; of cloning a Linux installation to a new
        drive or restoring a partition image backup.  In these cases it is
        much simpler if the UUID of the copy remains the same because it
        avoids having to edit GRUB2 configuration and fstab file system
        mounting which is nearly always done via UUID.
    3.  GParted has the new UUID operation, to change the UUID for cases
        when a copied file system needs to be mounted at the same time as
        the source.
    
    [1] xfs(5) - xfs - layout, mount options, and supported file attributes
        for the XFS filesystem
        https://man7.org/linux/man-pages/man5/xfs.5.html
        "MOUNT OPTIONS
        ...
        nouuid Don't check for double mounted file systems using the file
               system uuid.
        "
    
    Closes !85 - Make XFS copy duplicate the file system label and UUID

2021-05-27  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Copy XFS label when copying the file system (!85)
    
    As GParted performs block copy of partitions then the label, which is
    stored in the file system superblock, is also copied.  This is true for
    copies performed using the GParted internal block copy and for EXT2/3/4
    and NTFS which are copied using the file system specific commands
    e2image and ntfsclone respectively.  However when an XFS file system is
    copied the label is not copied because a new file system is created
    using mkfs.xfs and the files copied using xfsdump | xfsrestore.
    
    Preview of the copy operation in GParted also reflects the fact that the
    label will be copied.
    
    Fix this by simply specifying the desired label when creating the new
    destination XFS.
    
    Closes !85 - Make XFS copy duplicate the file system label and UUID

2021-05-29  Curtis Gedak <gedakc@gmail.com>

    Handle change in path for udisks2-inhibit executable (!84)
    
    Debian (and derived) distros with the udisks2 [1] repository and the
    additional 'udisks2-inhibit' executable had the location changed from:
        /usr/lib/udisks2/
    to:
        /usr/libexec/udisks2/
    with udisks2 version 2.8.4-2 and the following commit:
    
        f6744a33 - Move the daemons to /usr/libexec now that's allowed in the policy
        https://salsa.debian.org/utopia-team/udisks2/-/commit/f6744a3364eafdb07e3e78e329f202394804c574
    
    Distros such as Fedora and openSUSE are unaffected as the udisks [2]
    repository does not contain 'udisks2-inhibit'.
    
    [1] udisks2 Debian (and derived) repository
        https://salsa.debian.org/utopia-team/udisks2
    
    [2] udisks repository
        https://github.com/storaged-project/udisks
    
    Closes !84 - Handle change in path for udisks2-inhibit executable

2021-05-31  Andika Triwidada <atriwidada@gnome.org>

    Update Indonesian translation

2021-05-23  Rafael Fontenelle <rafaelff@gnome.org>

    Update Brazilian Portuguese translation

2021-05-23  Piotr Drąg <piotrdrag@gmail.com>

    Update Polish translation

2021-05-18  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Fix recognition of SD/MMC device names (!83)
    
    User reported that GParted didn't detect their eMMC drive [1].  Not
    recognised device name was /dev/mmcblk0.  Confirmed that the regression
    was introduced by this commit [2].  Fix the code and regular expression
    used to recognise SD/MMC device names.
    
    [1] GParted forum thread: eMMC drive not detected...?
        http://gparted-forum.surf4.info/viewtopic.php?id=17994
    
    [2] 52930f30ae8dc2c9dd1f64d2df654d9f1a1afb8a
        Refactor load_proc_partitions_info_cache() a bit (#131)
    
    Closes !83 - Fix recognition of SD/MMC device names

2021-05-19  Yuri Chornoivan <yurchor@ukr.net>

    Update Ukrainian translation

2021-05-18  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Update Swedish translation

2021-05-15  Curtis Gedak <gedakc@gmail.com>

    Replace deprecated gtk_show_uri() method for help window (!82)
    
    The gtk_show_uri() [1] method was deprecated as of gtk3 version 3.22 and
    has been replaced with gtk_show_uri_on_window [2].
    
    [1] https://developer.gnome.org/gtk3/stable/gtk3-Filesystem-utilities.html#gtk-show-uri
    [2] https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html#id-1.6.3.3.7
    
    Note that AppInfo::launch_uris() has been removed because with
    glib/glibmm >= 2.58 AppInfo::launch_uris() always reports success even
    when yelp is not launched and in such cases prevents the dialog
    reporting the error from being displayed.
    
    Closes !82 - Replace deprecated gtk_show_uri() method for help window

2021-05-17  Seong-ho Cho <shcho@gnome.org>

    Update Korean translation

2021-05-11  Ask Hjorth Larsen <asklarsen@gmail.com>

    Updated Danish translation

2021-05-04  Hugo Carvalho <hugokarvalho@hotmail.com>

    Update Portuguese translation

2021-05-03  Curtis Gedak <gedakc@gmail.com>

    Append -git to version for continuing development

2021-05-03  Curtis Gedak <gedakc@gmail.com>

    ==========   gparted-1.3.0   ==========

2021-05-01  Jiri Grönroos <jiri.gronroos@iki.fi>

    Update Finnish translation

2021-05-01  Piotr Drąg <piotrdrag@gmail.com>

    Update Polish translation

2021-04-27  Ngọc Quân Trần <vnwildman@gmail.com>

    Update Vietnamese translation

2021-04-26  Fran Dieguez <frandieguez@gnome.org>

    Update Galician translation

2021-04-26  Kukuh Syafaat <kukuhsyafaat@gnome.org>

    Update Indonesian translation

2021-04-26  Fran Dieguez <frandieguez@gnome.org>

    Update Galician translation

2021-04-26  Hannie Dumoleyn <hannie@ubuntu-nl.org>

    Update Dutch translation

2021-04-26  Hannie Dumoleyn <hannie@ubuntu-nl.org>

    Update Dutch translation

2021-04-26  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2021-04-26  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2021-04-26  Baurzhan Muftakhidinov <baurthefirst@gmail.com>

    Update Kazakh translation

2021-04-25  Claude Paroz <claude@2xlibre.net>

    Updated French translation

2021-04-25  Rafael Fontenelle <rafaelff@gnome.org>

    Update Brazilian Portuguese translation

2021-04-25  Daniel Șerbănescu <daniel@serbanescu.dk>

    Update Romanian translation

2021-04-25  Yuri Chornoivan <yurchor@ukr.net>

    Update Ukrainian translation

2021-04-25  Daniel Șerbănescu <daniel@serbanescu.dk>

    Update Romanian translation

2021-04-25  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Update Swedish translation

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Mark remaining get_filesystem_*() methods as returning const strings

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Comment differences between FileSystem::execute_command() methods

2021-04-02  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Report this LUKS passphrase request reason as resize (#59)
    
    So far when prompting for the LUKS passphrase the dialog always looks
    like this:
    
        +------------------------------------------------+
        |           LUKS Passphrase /dev/sdb1            |
        +------------------------------------------------+
        | Enter LUKS passphrase to open /dev/sdb1        |
        | Passphrase:    [                             ] |
        |                                                |
        |                                                |
        |                          [ Cancel ] [ Unlock ] |
        +------------------------------------------------+
    
    Specifically the first line of the dialog says the reason to provide the
    passphrase is to open the encryption mapping.  Now the passphrase may
    also be requested when resizing the encryption mapping, as part of a
    resize of check operation, show the appropriate reason in the password
    dialog.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-07  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Also prompt for LUKS password as required for check operation (#59)
    
    A check operation involves (1) checking the file system, (2) growing the
    encryption volume and (3) growing the file system.  Therefore prompt for
    the LUKS passphrase as required when composing a check operation too.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Pass LUKS password as needed when resizing open mapping (#59)
    
    This is the final piece which enables GParted to pass the LUKS
    passphrase when resizing an open LUKS encryption mapping when
    'cryptsetup resize' will prompt for it.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add ability for small writes to stdin of operation tracked child processes (#59)
    
    This is the equivalent to what was previously done when adding opening
    of LUKS mappings.  Namely to add a way to pass the LUKS passphrase to
    'cryptsetup luksOpen' via standard input.  Previously the functionality
    was added to Utils::execute_command() [1].  Now it is also needed to
    pass the LUKS passphrase to 'cryptsetup resize', which is executed as
    part of applying resize and check operations to an encrypted file
    system.  So add this functionality to FileSystem::execute_command().
    
    For now writing to stdin is only needed for the one variant of
    FileSystem::execute_command() which doesn't have progress tracking
    callbacks.  Writing to stdin can easily be added to the other progress
    tracking callback variants of execute_command() when needed.
    
    [1] 8dff80edc65b2923b400ddadebacf9bcf378d09f
        Add ability for small writes to stdin of child processes (#795617)
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Extract common code into generate_encryption_mapping_name() (#59)
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-03-26  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Ask for LUKS passphrase for resize operation as required (#59)
    
    When composing a resize operation on an open encryption mapping, use the
    existing LUKS password dialog to prompt for the passphrase, if and only
    if 'cryptsetup resize' will prompt and GParted doesn't already have a
    password.  'cryptsetup resize' will prompt for a LUKS passphrase when
    the passphrase was stored in the kernel keyring service,
    key_loc == KEYLOC_KeyRing.  See the previous commit "Capture LUKS
    mapping master encryption key location (#59)" for more details.
    
    As commented in the code GParted specifically doesn't support the case
    where the LUKS passphrase is changed while GParted is running and it
    knew the old passphrase.  When resizing an open encryption mapping
    GParted will just pass the old out of date passphrase it knows and the
    resize will fail like this:
    
        # cryptsetup status sdb2_crypt | egrep 'type|key location'
          type:         LUKS2
          key location: keyring
        # dmsetup table --target crypt
        sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
    
        # echo -n oldpassword | cryptsetup -v --size 491520 resize sdb2_crypt
        No key available with this passphrase.
        Command failed with code -2 (no permission or bad passphrase).
        # echo $?
        2
    
    To work around this either close and restart GParted or close and reopen
    the encryption mapping.  The former because GParted doesn't save
    passwords across a restart so will prompt and the latter because GParted
    will use the wrong old passphrase to try to open the mapping and then
    prompt for the correct passphrase until successfully opened.
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-03-26  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Capture LUKS mapping master encryption key location (#59)
    
    ISSUE OVERVIEW
    
    When GParted tries to resize an open LUKS encryption mapping and the
    volume (master) key was stored in the kernel keyring service [1] it
    fails like this:
    
        Check and repair file system ([Encrypted] ext4) on /dev/...(ERROR)
        + calibrate /dev/sdd1                                      (SUCCESS)
        + check file system on /dev/mapper/sdd1_crypt for errors...(SUCCESS)
        + grow encryption volume to fill the partition             (ERROR)
          + cryptsetup -v resize 'sdd1_crypt'                      (ERROR)
              Command failed with code -1 (wrong or missing parameters).
              Nothing to read on input.
    
    This error occurs with cryptsetup >= 2.0, kernel >= 4.10 and LUKS2
    format because the crypt Device-Mapper target no longer has the volume
    key so cryptsetup resize prompts for a passphrase, but GParted doesn't
    provide it.
    
    THIS COMMIT
    
    Additionally capture the location of the volume (master) key location
    for active encryption mappings.  Do this the using the same method that
    cryptsetup uses [2][3].  Namely if the first character of the KEY is a
    ":" then the key *was* stored in the kernel keyring service, otherwise
    it *is* store in the Device-Mapper crypt target as previously.
    
        # echo -n badpassword | cryptsetup luksFormat --type luks1 /dev/sdb1 -
        # echo -n badpassword | cryptsetup luksOpen /dev/sdb1 sdb1_crypt
        # cryptsetup status sdb1_crypt | egrep 'type|key location'
          type:         LUKS1
          key location: dm-crypt
    
        # echo -n badpassword | cryptsetup luksFormat --type luks2 /dev/sdb2 -
        # echo -n badpassword | cryptsetup luksOpen /dev/sdb2 sdb2_crypt
        # cryptsetup status sdb2_crypt | egrep 'type|key location'
          type:         LUKS2
          key location: keyring
    
        # dmsetup table --target crypt
        sdb1_crypt: 0 520192 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:17 4096
        sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
                                                   ^
    First character of the KEY field --------------'
    
    [1] Integration with the kernel keyring service
        https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/Keyring.txt
        "
        Starting with cryptsetup 2.0 we load [Volume Key] VK in kernel
        keyring by default for LUKSv2 devices ...
    
        In summary, the key description visible in dm-crypt table line is a
        reference to VK that usually no longer exists in kernel keyring
        service if you used cryptsetup to for device activation.
        "
    
    [2] cryptsetup/v2.3.5/lib/libdevmapper.c:_dm_target_query_crypt()
        https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/lib/libdevmapper.c#L2031
            if (key_[0] == ':')
                *act_flags |= CRYPT_ACTIVATE_KEYRING_KEY;
    
    [3] cryptsetup/v2.3.5/src/cryptsetup.c:action_status()
        https://gitlab.com/cryptsetup/cryptsetup/-/blob/v2.3.5/src/cryptsetup.c#L839
            log_std("  key location: %s\n", (cad.flags & CRYPT_ACTIVATE_KEYRING_KEY) ? "keyring" : "dm-crypt");
    
    Closes #59 - Resize of LUKS2 encrypted file system fails with "Nothing
                 to read on input"

2021-04-11  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Ignore libparted unrecognised disk label message from encryption mappings (#152)
    
    When GParted probes an open encryption mapping which is either blank or
    contains a file system which libparted doesn't recognise, such as:
    exfat, f2fs, lvm2 pv, minix or reiser4, then the partition also gets
    this warning message:
        /dev/mapper/sdb11_crypt: unrecognised disk label
    
    Clear the message so that it isn't shown in the GUI.
    
    Note that the message is still written to stderr by GParted, like all
    libparted exceptions are.  This is done by GParted's libparted exception
    handler:
        GParted_Core::ped_exception_handler()
          _ped_exception_handler()
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Reorder cases in set_device_and_disk() and use if fail return early (#152)
    
    The previous commit "Resolve empty drive displayed as blank minor logic
    issue (#152)" left the code in set_device_and_disk() some what
    unsightly.
    
    Refactor the whole function.  Use if fail return early pattern for
    failure of the get_device() call at the start of the function.  Reorder
    the 4 cases into a single depth if then else if chain.  Hopefully this
    is a little easier to follow.
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Resolve empty drive displayed as blank minor logic issue (#152)
    
    The previous commit "Remove coding landmine in get_disk() (#152)" made
    an empty drive without a disk label (partition table) display as
    nothing, instead of the normal single unallocated partition with warning
    "unrecognised disk label".
    
    The previous commit said:
        3. The two remaining direct calls to get_disk() where the strict
           parameter is explicitly set to false, from set_device_from_disk()
           and detect_filesystem_in_encryption_mapping(), are when scanning.
           As the pass strict=false they don't allow the PedDevice deletion
           to occur if no recognised disk label is found.
    
    This is true, but get_disk(..., strict=false) additionally returned true
    even if there was no disk label.  And in set_device_from_disk() the
    empty drive case is inside the if branch of the get_disk() call
    returning true.
    
    Simply fix this by calling get_disk(), ignoring the return value.
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Remove coding landmine in get_disk() (#152)
    
    get_disk() is the wrapper around libparted's ped_disk_new() which reads
    a disk label from the specified device and if successful creates the in
    memory PedDisk object to represent it.  In the case that libparted
    doesn't recognise a disk label or a file system, having get_disk() go
    and destroy the passed in PedDevice object via parameter lp_device is
    very unexpected behaviour hence describing it as a coding landmine.
    
    BACKGROUND
    
    1. Early on GParted only worked with devices with valid disk labels.
       FileSystem.h:open_device_and_disk() required both ped_device_get()
       and ped_disk_new() to succeed or neither to succeed.
    2. Commit [1] added support for devices which didn't yet have a disk
       label.  open_device_and_disk() had default parameter strict=true
       added.  While scanning strict=false was passed which allowed
       open_device_and_disk() to return success if only ped_device_get()
       succeeded and ped_disk_new() failed when the disk was empty.  All
       other times open_device_and_disk() was called with default
       strict=true, still requiring both or neither to succeed.
    3. Commit [2] added support for whole disk file systems.  The now named
       get_device_and_disk() had it's functionality split between
       get_device() and get_disk().  This result in the code landmine being
       left behind: get_disk() destroying the passed device object if
       default parameter strict=true and no disk label or file system was
       detected.
    
    ANALYSIS
    
    1. Since support for whole disk file systems [2] all current calls to
       get_device_and_disk() let the strict parameter default to true and
       are only called on known partitions within disk labels when applying
       a change to that partition.  Therefore they don't care about the
       behaviour of get_disk(), just that get_device_and_disk() maintains
       that both ped_device_get() and ped_disk_new() succeed or neither
       succeed.
    2. Two direct calls to get_disk() where the strict parameter defaults to
       true, from calibrate_partition() and erase_filesystem_signatures(),
       only do so on known partitions within disk labels as part of applying
       a change to that partition.  Therefore ped_disk_new() will succeed
       and so PedDevice isn't deleted when not wanted.
    3. The two remaining direct calls to get_disk() where the strict
       parameter is explicitly set to false, from set_device_from_disk() and
       detect_filesystem_in_encryption_mapping(), are when scanning.  As the
       pass strict=false they don't allow the PedDevice deletion to occur if
       no recognised disk label is found.
    
    FIX
    
    Remove the strict parameter from get_disk() and get_device_and_disk() as
    it's no longer needed.  Remove the code landmine by removing the side
    affect of destroying the PedDevice object if a disk label isn't found.
    Make sure get_device_and_disk() maintains the all or nothing behaviour.
    
    Also don't pass lp_device by reference to a pointer to get_disk() so the
    code can't change where lp_device points.
    
    [1] 038c5c5d99ad842f1a57f12222c884be29f4df4f
        P (special thanks to mantiena-baltix for bringing this issue to my
    
    [2] 51ac4d56489653854cd22787238a14bfa66a6ad4
        Split get_device_and_disk() into two (#743181)
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Correctly const and assert detect_filesystem() parameters (#152)
    
    As discussed in the previous commit "Don't crash probing libparted
    unrecognised encrypted file system (#152)", detect_filesystem() accepted
    a NULL lp_device pointer and dereferenced it leading to the crash.
    Document the requirement for lp_device parameter to be non-NULL via an
    assert and also correctly const the parameters.
    
    This forces needing to const the lp_partition parameter to
    get_partition_path() too.  Also assert it's non-NULL requirement.
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Don't crash probing libparted unrecognised encrypted file system (#152)
    
    Create a LUKS encrypted partition and open it.  Then either leave the
    contents blank or create a file system which libparted doesn't
    recognise, such as: exfat, f2fs, lvm2 pv, minix or reiser4.  When
    GParted probes the disk device it crashes.
    
        # echo -n badpassword | cryptsetup luksFormat /dev/sdb11
        # echo -n badpassword | cryptsetup luksOpen /dev/sdb11 sdb11_crypt
        # ./gpartedbin /dev/sdb
        GParted 1.2.0-git
        configuration (none)
        libparted 3.1
        /dev/mapper/sdb11_crypt: unrecognised disk label
        Segmentation fault (core dumped)
    
    Backtrace:
        #0  0x0000000000460f68 in GParted::GParted_Core::detect_filesystem(_PedDevice*, _PedPartition*, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
            (lp_device=0x0, lp_partition=0x0, messages=std::vector of length 0, capacity 0)
            at GParted_Core.cc:1235
        #1  0x00000000004615a6 in GParted::GParted_Core::detect_filesystem_in_encryption_mapping(Glib::ustring const&, std::vector<Glib::ustring, std::allocator<Glib::ustring> >&)
            (path=..., messages=std::vector of length 0, capacity 0)
            at GParted_Core.cc:1096
        #2  0x00000000004647c8 in GParted::GParted_Core::set_luks_partition(GParted::PartitionLUKS&)
            (this=this@entry=0x7fff43f974e0, partition=...)
            at GParted_Core.cc:1011
        #3  0x000000000046511b in GParted::GParted_Core::set_device_partitions(GParted::Device&, _PedDevice*, _PedDisk*)
            (this=this@entry=0x7fff43f974e0, device=..., lp_device=0x7efc780008c0, lp_disk=0x7efc78000d10)
            at GParted_Core.cc:883
        #4  0x00000000004658e3 in GParted::GParted_Core::set_device_from_disk(GParted::Device&, Glib::ustring const&)
            (this=this@entry=0x7fff43f974e0, device=..., device_path=...)
            at GParted_Core.cc:704
        #5  0x0000000000465fff in GParted::GParted_Core::set_devices_thread(std::vector<GParted::Device, std::allocator<GParted::Device> >*)
            (this=0x7fff43f974e0, pdevices=0x7fff43f96bc8)
            at GParted_Core.cc:266
        #6  0x00007efc99ba413d in call_thread_entry_slot ()
            at /lib64/libglibmm-2.4.so.1
        #7  0x00007efc97dc8555 in g_thread_proxy ()
            at /lib64/libglib-2.0.so.0
        #8  0x00007efc96ab4ea5 in start_thread () at /lib64/libpthread.so.0
        #9  0x00007efc967dd9fd in clone () at /lib64/libc.so.6
    
    The relevant sequence of events goes like this:
        detect_filesystem_in_encryption_mapping(path, ...)
          lp_device = NULL
          get_device(path, lp_device)
            lp_device = ped_device_get(path.c_str())
            return true
          lp_disk = NULL
          lp_partition = NULL
          get_disk(lp_device, lp_disk)  // + default parameter strict=true
            lp_disk = ped_disk_new(lp_device)
              // No libparted recognised disk label or file system found, so
              // NULL returned.
            destroy_device_and_disk(lp_device, lp_disk)
              ped_device_destroy(lp_device)
              lp_device = NULL
            return false
          detect_filesystem(lp_device, lp_partition, ...)
            path = lp_device->path
    
    The key points are:
    1. get_device() created a PedDevice object pointed to by lp_device;
    2. get_disk() didn't find a libparted recognised disk label or file
       system but also unexpectedly destroyed the PedDevice object and
       assigned NULL to lp_device;
    3. detect_filesystem() dereferenced lp_device assuming it was still
       valid.
    
    Implement the simplest possible fix by telling get_disk() to not
    destroy the needed PedDevice object when there's no recognised content.
    This is the same as how get_disk() is called in set_device_from_disk().
    
    Closes #152 - GParted crashed when trying to probe an encrypted
                  partition containing content that libparted doesn't
                  recognise

2021-04-14  Hugo Carvalho <hugokarvalho@hotmail.com>

    Update Portuguese translation

2021-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Also use libparted to probe for encrypted file systems (#148)
    
    Even though blkid is considered mandatory [1] GParted should still
    perform reasonably when blkid is not available, provided that is not too
    onerous a task.  Also use libparted file system identification inside
    encryption mappings.
    
    [1] 749a2495716a82a7287fad943109b6cfb927245c
        Document blkid command as a mandatory requirement (#753436)
    
    Closes 148 - Encrypted file systems are no longer recognised

2021-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Probe encryption mappings as needed using blkid (#148)
    
    GParted no longer recognises file systems inside LUKS encryption, apart
    from the few recognised by GParted's internal detection.  Bisected to
    this commit:
        8b35892ea59958aa1eec596a48a36b0fa7950dca
        Pass device and partition names to blkid (#131)
    
    Prior to this commit blkid was run querying all known block devices
    including active encryption mappings, hence prior recognition.  With
    this commit blkid was run only for named or found disk devices and
    associated found partitions from /proc/partitions, so no more
    recognition of encrypted file systems.
    
    Fix by running blkid on the encryption mapping just before querying for
    the file system.  This restores the level of functionality that existed
    before.
    
    Closes 148 - Encrypted file systems are no longer recognised

2021-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Extract some code into detect_filesystem_in_encryption_mapping() (#148)
    
    To avoid making set_luks_partition() more complicated extract the file
    system detection portion into a new function.
    
    Closes 148 - Encrypted file systems are no longer recognised

2021-03-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Make FS_Info (blkid) cache incrementally loadable (#148)
    
    Since changes for issue #131 "GParted hangs when non-named device is
    hung" FS_Info cache is initialised, cleared and loaded via one call to
    load_cache_for_paths().  It runs blkid for named or found disk devices
    and associated found partitions from /proc/partitions, rather than
    running blkid and letting it report for all block devices.
    
    To avoid the possibility of using blkid on an encryption mapping on a
    non-specified and possibly hung block device GParted can't just specify
    all encryption mappings.  Instead only encryption mappings which belong
    to the above identified block devices should be probed.  That requires
    identifying LUKS encryption data in the block devices first so will
    require subsequently loading additional data into the FS_Info cache and
    running blkid again.
    
    To accommodate this make the FS_Info cache incrementally loadable,
    rather than doing everything in a single call to load_cache_for_paths().
    Have a separate clear_cache() call which initialises and clears the
    cache and make load_cache_for_paths() just run blkid and insert data for
    the named paths.
    
    Closes 148 - Encrypted file systems are no longer recognised

2021-04-02  Nathan Follens <nfollens@gnome.org>

    Update Dutch translation

2021-03-27  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Update Swedish translation

2021-03-25  Hugo Carvalho <hugokarvalho@hotmail.com>

    Update Portuguese translation

2021-03-19  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Update HACKING file with coding style hints and tips

2021-03-20  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Explicitly read the reiser4 volume UUID when present
    
    Reiser4 has introduced new disk format which includes support for
    spanning the file system over multiple block devices (subvolumes)
    [1][2].  As such the output of the debugfs.reiser4 for the UUID has
    changed slightly.  So far the new reiser4progs package (version 2.0.x)
    is only available as a Debian experimental package.
    
    Using reiser4progs 1.2.1 the old output was like this:
    
        $ debugfs.reiser4 test.img
        debugfs.reiser4 1.2.1
        Format release: 4.0.2
        Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.
    
        Master super block (16):
        magic:          ReIsEr4
        blksize:        4096
        format:         0x0 (format40)
        uuid:           1116afce-99fd-4a6e-94cb-2d9f19c91d67
        label:          <none>
    
        ...
    
    With reiser4progs 2.0.4 the new output is like this:
    
        $ debugfs.reiser4 test.img
        debugfs.reiser4
        Package Version: 2.0.4
        Software Framework Release: 5.1.3
        Copyright (C) 2001-2005 by Hans Reiser, licensing governed by reiser4progs/COPYING.
        Master super block (16):
        magic:          ReIsEr4
        blksize:        4096
        volume:         0x1 (asym)
        distrib:        0x1 (fsx32m)
        format:         0x1 (format41)
        description:    Standard layout for logical volumes.
        stripe bits:    14
        mirror id:      0
        replicas:       0
        volume uuid:    9538bfa3-5694-4abe-864c-edc288a9d801
        subvol uuid:    d841c692-2042-49e6-ac55-57e454691782
        label:          <none>
    
        ...
    
    GParted happens to read the correct UUID just because the first matching
    "uuid" string in the output is the volume UUID.  Make the code more
    robust by explicitly reading the volume uuid when labelled as such.
    
    [1] Logical Volumes Howto
        https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Howto
    [2] Logical Volumes Background
        https://reiser4.wiki.kernel.org/index.php/Logical_Volumes_Background

2021-03-20  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Refactor reiser4::read_uuid() into if fail return early pattern

2021-03-18  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Ignore test failure when reiser4 reports null UUID (#145)
    
    The GitLab CI ubuntu_test job has occasionally been failing like this,
    perhaps once every few weeks or so.
    
        [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
        test_SupportedFileSystems.cc:569: Failure
        Expected: (m_partition.uuid.size()) >= (9U), actual: 0 vs 9
        [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4, where GetParam() = 24 (17 ms)
        [----------] 1 test from My/SupportedFileSystemsTest (17 ms total)
    
    Turns out there are 2 bugs in resier4progs.  One causes debugfs.reiser4
    to report a null UUID if the first byte of the UUID happens to be zero
    [1], and the other cases mkfs.resier4 to write a corrupted UUID,
    sometimes a null (all zeros) UUID [2].
    
    There is a 1 in 256 chance of getting a null UUID [2] when creating and
    reading a reiser4 file system, hence the occasional failure of the CI
    job.  The centos_test job isn't affected because CentOS doesn't have the
    reiser4progs package.
    
    Fix this by detecting when reiser4 reports a null UUID and assign a
    dummy UUID to make the test pass.  This does mean that there is a 1 in
    256 chance of not detecting a true failure.  However that still means
    there is a 255 in 256 chance of detecting a true failure.  That's good
    odds.  When a null UUID is detected for a reiser4 file system the test
    output looks like this:
    
        [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4
        test_SupportedFileSystems.cc:580: Ignore test failure of a null UUID.
        [       OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4 (46 ms)
    
    [1] https://github.com/edward6/reiser4progs/commit/4802cdb18ae03031d0e51a58b6655f3b99021ec2
        Fix up repair_master_print()
    
    [2] https://github.com/edward6/reiser4progs/commit/44cc024f398f60adef1519426d65f3f081ee826a
        Stop occasionally making file systems with null UUIDs
    
    Closes #145 - Sporadic failure of test case
                  My/SupportedFileSystemsTest.CreateAndReadUUID/reiser4

2021-03-13  Jordi Mas <jmas@softcatala.org>

    Update Catalan translation

2021-03-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Print kernel version, etc in GitLab CI (#147)
    
    Print the kernel version and supported file systems inside the GNOME
    GitLab CI jobs as a debugging aid.  Kernel version helps identify the
    CI job runner's distribution to identify kernel features.  Supported
    file systems identifies which ones can be mounted, should that be
    possible in future.  Print supported file systems before and after the
    tests because checking for support may load additional modules.  See
    calls to Utils::kernel_supports_fs() for: btrfs, jfs, nilfs2 and xfs.
    
    Closes #147 - GitLab CI test failure from *.CreateAndGrow/jfs

2021-03-08  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Exclude more GitLab CI file system tests needing loop devices (#147)
    
    For the first time ever the ubuntu_test GitLab CI job failed running the
    JFS grow test like this.  Fragment from tests/test-suite.log:
    
        [ RUN      ] My/SupportedFileSystemsTest.CreateAndGrow/jfs
        test_SupportedFileSystems.cc:387: Failure
        Failed
        create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img'
        losetup: cannot find an unused loop device
        create_loopdev(): Losetup failed with exit status 1
        create_loopdev(): Failed to create required loop device
        Error: Could not stat device  - No such file or directory.
        test_SupportedFileSystems.cc:446: Failure
        Value of: lp_device != NULL
          Actual: false
        Expected: true
        test_SupportedFileSystems.cc:649: Failure
        Value of: m_fs_object->create(m_partition, m_operation_detail)
          Actual: false
        Expected: true
        Operation details:
        mkfs.jfs -q -L '' ''    00:00:00  (ERROR)
        mkfs.jfs version 1.1.15, 04-Mar-2011
    
        The system cannot find the specified device.
    
        detach_loopdev(): Execute: losetup --detach ''
        losetup: : failed to use device: No such device
        detach_loopdev(): Losetup failed with exit status 1
        detach_loopdev(): Failed to detach loop device.  Test NOT affected
        [  FAILED  ] My/SupportedFileSystemsTest.CreateAndGrow/jfs, where GetParam() = 17 (24 ms)
    
    JFS can only be grown when mounted by the kernel and GParted only
    enables JFS grow support when, among other things, kernel support is
    detected.
    
    Unknowingly the JFS grow test had always previously been skipped, even
    in the ubuntu_test CI job which installs jfsutils, because the kernel
    didn't support JFS.  Capture of this test from another run of the
    ubuntu_test CI job:
    
        [ RUN      ] My/SupportedFileSystemsTest.CreateAndGrow/jfs
        test_SupportedFileSystems.cc:641: Skip test.  grow not supported or support not found
        [       OK ] My/SupportedFileSystemsTest.CreateAndGrow/jfs (0 ms)
    
    Plus additional debug added into the job based on what
    Utils::kernel_supports_fs() does to identify kernel support:
    
        $ fgrep jfs /proc/filesystems || true
        $ modprobe jfs || true
        modprobe: FATAL: Module jfs not found in directory /lib/modules/3.10.0-1160.11.1.el7.x86_64
        $ fgrep jfs /proc/filesystems || true
    
    Therefore until now every GitLab job runner machine kernel didn't
    support JFS, but for the first time ever this ubuntu_test job ran on a
    runner machine where the kernel did support JFS, hence the attempt to
    use losetup.
    
    Examining test_SupportFileSystems.cc there are 24 file system tests
    which specify SKIP_IF_NOT_ROOT_FOR_REQUIRED_LOOPDEV_FOR_FS(), but only
    17 exclusions in .gitlab-ci.yaml [1].  The 7 tests without exclusions
