# Generated by Makefile. Do not edit.

2021-01-25  Curtis Gedak <gedakc@gmail.com>

    ==========   gparted-1.2.0   ==========

2021-01-25  Curtis Gedak <gedakc@gmail.com>

    Update copyright years

2021-01-24  Rūdolfs Mazurs <rudolfs.mazurs@gmail.com>

    Update Latvian translation

2021-01-23  Fabio Tomat <f.t.public@gmail.com>

    Update Friulian translation

2021-01-22  Philipp Kiemle <philipp.kiemle@gmail.com>

    Update German translation

2021-01-21  Marek Černocký <marek@manet.cz>

    Updated Czech translation

2021-01-20  Thibault Martin <mail@thibaultmart.in>

    Update French translation

2021-01-19  Мирослав Николић <miroslavnikolic@rocketmail.com>

    Update Serbian translation

2021-01-19  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2021-01-18  Rafael Fontenelle <rafaelff@gnome.org>

    Update Brazilian Portuguese translation

2021-01-18  Rafael Fontenelle <rafaelff@gnome.org>

    Update Brazilian Portuguese translation

2021-01-18  Daniel Șerbănescu <daniel@serbanescu.dk>

    Update Romanian translation

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

    Update Polish translation

2021-01-16  Anders Jonsson <anders.jonsson@norsjovallen.se>

    Update Swedish translation

2021-01-16  Yuri Chornoivan <yurchor@ukr.net>

    Update Ukrainian translation

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

    White space tidy-up of Utils::get_filesystem_software()
    
    Put colon directly after case value and list cases in enumeration order.

2021-01-13  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add unit testing of GParted exFAT interface (!30)
    
    Install exfatprogs into the CentOS 7 GitLab CI image, enabling unit
    testing of GParted's use of exFAT programs.  Exfatprogs is not yet
    available for Ubuntu 20.04 as used in the Ubuntu GitLab CI image, only
    for Ubuntu 20.10 so far.
    
    Closes !30 - Add exFAT support

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

    Set the partition type for exFAT correctly (!30)
    
    Libparted only allows selection of the partition type indirectly by
    specifying the type of the file system it will contain [1] and so far
    doesn't know about the exFAT file system.  Therefore when GParted is
    creating a new exFAT partition, it gets the GParted default of 83
    (Linux file system) on MBR partition tables.
    
    Example operation details:
        Create Primary Partition #1 (exfat, 512.00 MiB) on /dev/sdb
        * create empty partition
        * clear old file system signatures in /dev/sdb1
        * set partition type on /dev/sdb1
            new partition type: ext2
        * create new exfat file system
    
    fdisk report:
        # fdisk -l /dev/sdb
        Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors
        Disk model: VBOX HARDDISK
        Units: sectors of 1 * 512 = 512 bytes
        Sector size (logical/physical): 512 bytes / 512 bytes
        I/O size (minimum/optimal): 512 bytes / 512 bytes
        Disklabel type: dos
        Disk identifier: 0xa2aab629
    
        Device     Boot Start     End Sectors  Size Id Type
        /dev/sdb1        2048 1050623 1048576  512M 83 Linux
    
    However the "exFAT file system specification" says:
        https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
        "10.2 Partition Tables
    
        To ensure interoperability of exFAT volumes in a broad set of usage
        scenarios, implementations should use partition type 07h for MBR
        partitioned storage and partition GUID
        {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} for GPT partitioned storage.
        "
    
    Fix this.
    
    [1] ped_partition_new(..., const PedFileSystemType* fs_type, ...)
        https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5
        ped_partition_set_system(..., const PedFileSystemType* fs_type)
        https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5
    
    Closes !30 - Add exFAT support

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

    Add exFAT support (!30)
    
    With exfatprogs (https://github.com/exfatprogs/exfatprogs) installed the
    following operations on exFAT file systems are supported:
    - Creation
    - Checking
    - Labelling
    As of the current exfatprogs 1.0.4 the following are not supported:
    - Reading usage
    - Resizing
    - Updating the UUID
    
    Closes !30 - Add exFAT support

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

    Exclude snap /dev/loop file system image mounts (#129)
    
    On Ubuntu the gparted shell wrapper still attempts to mask lots of
    non-block device based file systems.  Remove the --quiet option from the
    systemctl --runtime mask command to see:
        $ gparted
        Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-66.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-core-10583.mount -> /dev/null.
        Created symlink /run/systemd/system/boot-efi.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1514.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-core-10577.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-core18-1944.mount -> /dev/null.
        Created symlink /run/systemd/system/run-user-1000-doc.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1506.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-128.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-snap\x2dstore-518.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-145.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-core18-1932.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-snap\x2dstore-467.mount -> /dev/null.
        Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-60.mount -> /dev/null.
        Created symlink /run/systemd/system/-.mount -> /dev/null.
        GParted 1.0.0
        configuration --enable-libparted-dmraid --enable-online-resize
        libparted 3.3
    
    The gparted shell wrapper is currently looking for non-masked Systemd
    mount units where the 'What' property starts "/dev/".  However Ubuntu
    also uses snap packages which are mounted file images via loop devices:
        $ grep '^/dev/' /proc/mounts | sort
        /dev/fuse /run/user/1000/doc fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
        /dev/loop0 /snap/core/10583 squashfs ro,nodev,relatime 0 0
        /dev/loop10 /snap/snap-store/518 squashfs ro,nodev,relatime 0 0
        /dev/loop11 /snap/snap-store/467 squashfs ro,nodev,relatime 0 0
        /dev/loop12 /snap/gtk-common-themes/1506 squashfs ro,nodev,relatime 0 0
        /dev/loop1 /snap/core/10577 squashfs ro,nodev,relatime 0 0
        /dev/loop3 /snap/core18/1944 squashfs ro,nodev,relatime 0 0
        /dev/loop4 /snap/core18/1932 squashfs ro,nodev,relatime 0 0
        /dev/loop5 /snap/gnome-3-34-1804/66 squashfs ro,nodev,relatime 0 0
        /dev/loop6 /snap/gnome-3-28-1804/128 squashfs ro,nodev,relatime 0 0
        /dev/loop7 /snap/gnome-3-34-1804/60 squashfs ro,nodev,relatime 0 0
        /dev/loop8 /snap/gnome-3-28-1804/145 squashfs ro,nodev,relatime 0 0
        /dev/loop9 /snap/gtk-common-themes/1514 squashfs ro,nodev,relatime 0 0
        /dev/sda1 /boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
        /dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
    
    Fix by excluding:
    1. Device name "/dev/fuse" because it's a character not a block device
       and the mount point is associated with snap,
    2. Device names starting "/dev/loop" and where the mount point starts
       "/snap/" [1].  This is to allow for use of GParted with explicitly
       named loop devices.
    
    [1] The system /snap directory
        https://snapcraft.io/docs/system-snap-directory
    
    Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding
                  anyway

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

    Only mask Systemd mounts on block devices (#129)
    
    The gparted shell wrapper masks Systemd mount units to prevent it
    automounting file systems while GParted is running [1], excluding
    virtual file system which GParted isn't interested in [2].  The problem
    is that there are a lot of virtual file systems and they have changed
    between Fedora 19 and 33 so now the exclusion list is out of date.
    
    Run GParted on Fedora 33 and query the mount units while it is running:
        $ systemctl list-units -t mount --full --all
          UNIT                          LOAD   ACTIVE   SUB     DESCRIPTION
          -.mount                       loaded active   mounted Root Mount
        * boot.mount                    masked active   mounted /boot
          dev-hugepages.mount           loaded active   mounted Huge Pages File System
          dev-mqueue.mount              loaded active   mounted POSIX Message Queue File System
        * home.mount                    masked active   mounted /home
        * proc-fs-nfsd.mount            masked inactive dead    proc-fs-nfsd.mount
          proc-sys-fs-binfmt_misc.mount loaded inactive dead    Arbitrary Executable File Formats File System
          run-user-1000-gvfs.mount      loaded active   mounted /run/user/1000/gvfs
        * run-user-1000.mount           masked active   mounted /run/user/1000
        * run-user-42.mount             masked active   mounted /run/user/42
          sys-fs-fuse-connections.mount loaded active   mounted FUSE Control File System
          sys-kernel-config.mount       loaded active   mounted Kernel Configuration File System
          sys-kernel-debug.mount        loaded active   mounted Kernel Debug File System
        * sys-kernel-tracing.mount      masked active   mounted /sys/kernel/tracing
        * sysroot.mount                 masked inactive dead    sysroot.mount
        * tmp.mount                     masked active   mounted /tmp
        * var-lib-machines.mount        masked inactive dead    var-lib-machines.mount
        * var-lib-nfs-rpc_pipefs.mount  masked active   mounted /var/lib/nfs/rpc_pipefs
        * var.mount                     masked inactive dead    var.mount
    
        LOAD   = Reflects whether the unit definition was properly loaded.
        ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
        SUB    = The low-level unit activation state, values depend on unit type.
    
        19 loaded units listed.
        To show all installed unit files use 'systemctl list-unit-files'.
    
    So it masked these virtual file systems which didn't need to be masked:
        * proc-fs-nfsd.mount            masked inactive dead    proc-fs-nfsd.mount
        * run-user-1000.mount           masked active   mounted /run/user/1000
        * run-user-42.mount             masked active   mounted /run/user/42
        * sys-kernel-tracing.mount      masked active   mounted /sys/kernel/tracing
        * var-lib-machines.mount        masked inactive dead    var-lib-machines.mount
        * var-lib-nfs-rpc_pipefs.mount  masked active   mounted /var/lib/nfs/rpc_pipefs
    
    Lines from /proc/partitions for some of these virtual file systems:
        $  egrep '/run/user|/sys/kernel/tracing|/var/lib/nfs/rpc_pipefs' /proc/mounts
        tmpfs /run/user/42 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656k,nr_inodes=50664,mode=700,uid=42,gid=42,inode64 0 0
        tmpfs /run/user/1000 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656k,nr_inodes=50664,mode=700,uid=1000,gid=1000,inode64 0 0
        none /sys/kernel/tracing tracefs rw,seclabel,relatime 0 0
        sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
        gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
    
    And for contrast the lines from /proc/mounts for disk backed file systems:
        $ egrep '^/dev/' /proc/mounts
        /dev/sda1 /boot ext4 rw,seclabel,relatime 0 0
        /dev/sda2 / btrfs rw,seclabel,relatime,space_cache,subvolid=258,subvol=/root 0 0
        /dev/sda2 /home btrfs rw,seclabel,relatime,space_cache,subvolid=256,subvol=/home 0 0
    
    Going back to first principles GParted cares that Systemd doesn't
    automount file systems on block devices.  So instead only mask mount
    units which are on block devices.  Where the 'What' property starts
    "/dev/".
    
    Systemd maintains hundreds of properties for each unit.
        $ systemctl show boot.mount | wc -l
        221
    
    The properties of interest for all mount units can be queries like this:
        $ systemctl show --all --property=What,Id,LoadState '*.mount'
        ...
    
        What=sunrpc
        Id=var-lib-nfs-rpc_pipefs.mount
        LoadState=masked
    
        What=/dev/sda1
        Id=boot.mount
        LoadState=masked
    
        ...
    
    [1] 4c109df9b59e55699bd42023cf4007ee359793e9
        Use systemctl runtime mask to prevent automounting (#701676)
    
    [2] 43de8e326a9f6f099e5274619f16039bdc20c1a4
        Do not mask virtual file systems when using systemctl (#708378)
    
    Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding
                  anyway

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

    Don't try to mask non-existent Systemd \xe2\x97\x8f.service (#129)
    
    With Systemd 246 on Fedora 33, running GParted reports this error and no
    longer masks the system mount units:
    
        $ gparted
        Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
        Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
        GParted 1.1.0
        configuration --enable-libparted-dmraid --enable-online-resize
        libparted 3.3
    
        $ systemctl list-units -t mount --full --all --no-legend
          -.mount                       loaded    active   mounted Root Mount
          boot.mount                    loaded    active   mounted /boot
          dev-hugepages.mount           loaded    active   mounted Huge Pages File System
          dev-mqueue.mount              loaded    active   mounted POSIX Message Queue File System
          home.mount                    loaded    active   mounted /home
          proc-fs-nfsd.mount            loaded    inactive dead    NFSD configuration filesystem
          proc-sys-fs-binfmt_misc.mount loaded    inactive dead    Arbitrary Executable File Formats File System
          run-user-1000-gvfs.mount      loaded    active   mounted /run/user/1000/gvfs
          run-user-1000.mount           loaded    active   mounted /run/user/1000
          run-user-42.mount             loaded    active   mounted /run/user/42
          sys-fs-fuse-connections.mount loaded    active   mounted FUSE Control File System
          sys-kernel-config.mount       loaded    active   mounted Kernel Configuration File System
          sys-kernel-debug.mount        loaded    active   mounted Kernel Debug File System
          sys-kernel-tracing.mount      loaded    active   mounted Kernel Trace File System
        * sysroot.mount                 not-found inactive dead    sysroot.mount
          tmp.mount                     loaded    active   mounted Temporary Directory (/tmp)
          var-lib-machines.mount        loaded    inactive dead    Virtual Machine and Container Storage (Compatibility)
          var-lib-nfs-rpc_pipefs.mount  loaded    active   mounted RPC Pipe File System
        * var.mount                     not-found inactive dead    var.mount
    
        ^
       [Unicode Black Circle character (U+25CF) replaced with star to avoid
       making this this commit message Unicode.]
    
    Currently the gparted shell wrapper lists the Systemd mount units and
    takes the first space separated column as the unit name.  If the LOAD
    status of the unit is not "loaded" then Systemd prefixes the name with
    an optional Black Circle.  Prior to Systemd 246 these extra 2 characters
    at the start of the line, including the optional Black Circle, were
    suppressed by the --no-legend option, but with Systemd 246 this no
    longer happens.  As the mount unit names no longer start in the first
    character of the line no units are masked.  Instead the Unicode Black
    Circle character, UTF-8 byte sequence E2 97 8F, is found at the start of
    highlighted lines which results in this error:
        Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
    
    Fix by adding the --plain option to suppress the optional Black Circle
    in the systemctl output.  Confirmed this option is available in the
    oldest supported distributions with Systemd.
        RedHat / CentOS 7   Systemd 219   systemctl has --plain option.
        Ubuntu 16.04 LTS    Systemd 229   systemctl has --plain option.
    
    Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding
                  anyway

2021-01-10  Jordi Mas <jmas@softcatala.org>

    Update Catalan translation

2021-01-01  Jordi Mas <jmas@softcatala.org>

    Update Catalan translation

2020-11-28  Аляксей <alexey_razumov@tutanota.com>

    Update Belarusian translation

2020-11-13  Curtis Gedak <gedakc@gmail.com>

    Set default partition alignment to cylinder for amiga partition table (#116)
    
    Closes #116 - Fails to create partitions on disks with Amiga partition
                  tables using default settings

2020-11-02  Jordi Mas <jmas@softcatala.org>

    Update Catalan translation

2020-10-13  Dušan Kazik <prescott66@gmail.com>

    Update Slovak translation

2019-12-23  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Remove unneeded #include <vector> from TreeView_Detail.h
    
    std::vector<> is no longer used in TreeView_Detail.h since this commit
    replaced them:
        fae909897e92b55aed0624ec8ccf221806e23ef4
        Use PartitionVector class throughout the code (#759726)

2020-09-17  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Fix CentOS 7 CI test job failures from empty /etc/machine-id (!62)
    
    Since August 2020, GitLab Continuous Integration test jobs have been
    failing on the CentOS 7 image like this from
    tests/test_SupportedFileSystems.log:
    
        process 6319: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text
        See the manual page for dbus-uuidgen to correct this issue.
          D-Bus not built with -rdynamic so unable to print a backtrace
        Running main() from test_SupportedFileSystems.cc
        DISPLAY=":99"
        /usr/bin/xvfb-run: line 181:  6319 Aborted                 (core dumped) DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1
    
    Not sure why this has just started failing in the CentOS 7 CI image now,
    but the error is widely known [1][2][3][4].  Use
    systemd-machine-id-setup to generate a machine ID [5][6]; rather than
    dbus-uuidgen [7] as it's designed to integrate into VMs and does the
    right thing if a valid machine ID already exists.
    
    [1] Red Hat Bug 598200 - D-Bus library appears to be incorrectly set up;
        failed to read machine uuid: UUID file '/var/lib/dbus/machine-id'
        https://bugzilla.redhat.com/show_bug.cgi?id=598200
    [2] Free Desktop Bug 13194 - When machine-id not found, dbus should not
        abort
        https://bugs.freedesktop.org/show_bug.cgi?id=13194
    [3] D-Bus library appears to be incorrectly set up
        https://unix.stackexchange.com/questions/117741/d-bus-library-appears-to-be-incorrectly-set-up
    [4] Generate uuid for container
        https://xpra.org/trac/wiki/Usage/Docker/CentOS
    [5] CentOS / RHEL 7 : How to Change the machine-id
        https://www.thegeekdiary.com/centos-rhel-7-how-to-change-the-machine-id/
    [6] man systemd-machine-id-setup
        https://man7.org/linux/man-pages/man1/systemd-machine-id-setup.1.html
    [7] man dbus-uuidgen
        https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html
    
    Closes !62 - Fix CentOS 7 CI test job failures because of zero sized
                 /etc/machine-id

2020-09-11  Fabio Tomat <f.t.public@gmail.com>

    Update Friulian translation

2020-09-06  Aurimas Černius <aurisc4@gmail.com>

    Updated Lithuanian translation

2020-08-30  Boyuan Yang <073plan@gmail.com>

    Update Chinese (China) translation

2020-07-12  Piotr Drąg <piotrdrag@gmail.com>

    Update Polish translation
    
    Fixes https://gitlab.gnome.org/Teams/Translation/pl/-/issues/8

2020-06-26  Baurzhan Muftakhidinov <baurthefirst@gmail.com>

    Update Kazakh translation

2020-05-31  Daniel Șerbănescu <daniel@serbanescu.dk>

    Update Romanian translation

2019-12-19  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add missing includes into Devices module

2020-05-23  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Exclude PipeCapture read NUL byte unit tests in GitLab CI jobs (!60)
    
    These PipeCapture unit tests are also failing, preventing the
    ubuntu_test CI job passing:
        PipeCaptureTest.ReadEmbeddedNULCharacter
        PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character
    
    These tests are also failing locally in both Ubuntu 20.04 LTS and
    Fedora 32 VMs, but not in Ubuntu 18.04 LTS or Fedora 31 VMs.  As this is
    not specifically a Ubuntu docker image update related issue, temporarily
    exclude these failing tests.
    
    Closes !60 - Fix GitLab CI job failures following Ubuntu docker image
                 updates

2020-05-23  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add C++ compiler into GitLab CI Ubuntu image (!60)
    
    Next the Ubuntu image CI job is failing without a C++ compiler like
    this:
    
        checking whether to enable maintainer-specific portions of Makefiles... yes
        checking for g++... no
        checking for c++... no
        checking for gpp... no
        checking for aCC... no
        checking for CC... no
        checking for cxx... no
        checking for cc++... no
        checking for cl.exe... no
        checking for FCC... no
        checking for KCC... no
        checking for RCC... no
        checking for xlC_r... no
        checking for xlC... no
        checking whether the C++ compiler works... no
        configure: error: in `/builds/mfleetwo/gparted':
        configure: error: C++ compiler cannot create executables
        See `config.log' for more details
        ...
        ERROR: Job failed: exit code 1
    
    The published "Ubuntu" docker image has been updated to Ubuntu 20.04 LTS
    and must no longer include the build tools by default, or not be a
    dependency of any of the other installed packages.  Explicitly install
    build-essential to get the C++ compiler [1].  Also don't list make as
    build-essential includes it.
    
    [1] Installing the GNU C compiler and GNU C++ compiler
        https://help.ubuntu.com/community/InstallingCompilers
    
    Closes !60 - Fix GitLab CI job failures following Ubuntu docker image
                 updates

2020-05-22  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Prevent tzdata install hang in GitLab CI Ubuntu image (!60)
    
    The Ubuntu based GitLab CI jobs have recently started being terminated
    after the default 1 hour timeout.  Installing / updating packages in the
    image is updating the tzdata package which is prompting for input which
    it will never receive, hence the hang.  The end of output from the job
    looks like this:
    
        Setting up tzdata (2020a-0ubuntu0.20.04) ...
        debconf: unable to initialize frontend: Dialog
        debconf: (TERM is not set, so the dialog frontend is not usable.)
        debconf: falling back to frontend: Readline
        Configuring tzdata
        ------------------
        Please select the geographic area in which you live. Subsequent configuration
        questions will narrow this down by presenting a list of cities, representing
        the time zones in which they are located.
          1. Africa      4. Australia  7. Atlantic  10. Pacific  13. Etc
          2. America     5. Arctic     8. Europe    11. SystemV
          3. Antarctica  6. Asia       9. Indian    12. US
        Geographic area:
        ...
        ERROR: Job failed: execution took longer than 1h0m0s seconds
    
    This is a well known issue [1][2][3].  Probably occurring now because of
    a new release of tzdata not included in the base Ubuntu image we are
    using.  Fix by telling the underlying dpkg tools this installation is
    non-interactive.
    
    [1] Avoiding user interaction with tzdata when installing certbot in a
        docker container
        https://askubuntu.com/questions/909277/avoiding-user-interaction-with-tzdata-when-installing-certbot-in-a-docker-contai
    [2] How to install tzdata on a ubuntu docker image?
        https://serverfault.com/questions/949991/how-to-install-tzdata-on-a-ubuntu-docker-image
    [3] apt-get install tzdata noninteractive
        https://stackoverflow.com/questions/44331836/apt-get-install-tzdata-noninteractive
    
    Closes !60 - Fix GitLab CI job failures following Ubuntu docker image
                 updates

2020-05-24  Yi-Jyun Pan <pan93412@gmail.com>

    Update Chinese (Taiwan) translation

2020-05-04  Dušan Kazik <prescott66@gmail.com>

    Update Slovak translation

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

    Replace TRUE #define with C++ true literal
    
    Everywhere else in the code the lower case true C++ boolean literal is
    used.  Change this one place where upper case TRUE #define was used to
    match.

2020-03-10  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Add /dev/disk/by-id/ symlink in CI for test_BlockSpecial
    
    This previous commit [1] excluded unit test
    BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches because GNOME
    GitLab Docker CI images don't have /dev/disk hierarchy and so no
    symbolic links to block devices.
    
    Create the /dev/disk/by-id directory and a symlink for this unit test to
    use in the new tests/makedev.sh script.
    
    [1] fe2fc33e67980f0b4a5bba958d257be54715f301
        Exclude unit test which fails in Docker CI image (!4)

2020-03-11  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Exclude unit tests needing losetup in Docker CI image (!59)
    
    test_SupportedFileSystems is another unit test that has been failing
    since 23-Feb-2020 in GNOME GitLab Continuous Integration test jobs.
    Fragments from tests/test-suite.log from a failed test CI job:
    
        FAIL: test_SupportedFileSystems
        ===============================
        ...
        [ RUN      ] My/SupportedFileSystemsTest.Create/lvm2pv
        test_SupportedFileSystems.cc:387: Failure
        Failed
        create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img'
        losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory
        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:490: Failure
        Value of: m_fs_object->create(m_partition, m_operation_detail)
          Actual: false
        Expected: true
        Operation details:
        lvm pvcreate -M 2 ''    00:00:00  (ERROR)
    
          WARNING: Failed to connect to lvmetad. Falling back to device scanning.
          Device  not found.
    
        detach_loopdev(): Execute: losetup --detach ''
        losetup: /dev/: detach failed: Inappropriate ioctl for device
        detach_loopdev(): Losetup failed with exit status 1
        detach_loopdev(): Failed to detach loop device.  Test NOT affected
        [  FAILED  ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam() = 20 (64 ms)
        ...
        [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs
        test_SupportedFileSystems.cc:387: Failure
        Failed
        create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img'
        losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory
        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:503: Failure
        Value of: m_fs_object->create(m_partition, m_operation_detail)
          Actual: false
        Expected: true
        Operation details:
        mkfs.btrfs -L '' ''    00:00:00  (ERROR)
        btrfs-progs v4.9.1
        See http://btrfs.wiki.kernel.org for more information.
    
        ERROR: failed to check size for : No such file or directory
    
        detach_loopdev(): Execute: losetup --detach ''
        losetup: /dev/: detach failed: Inappropriate ioctl for device
        detach_loopdev(): Losetup failed with exit status 1
        detach_loopdev(): Failed to detach loop device.  Test NOT affected
        [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7 (11 ms)
    
    All the test_SupportedFileSystems unit tests which need a loop device
    are failing when running losetup like this:
        losetup: <IMAGE_NAME>: failed to setup loop device: No such file or directory
    
    losetup uses /dev/loop-control [1][2] which no longer exists in the
    Docker image.  However even after creating /dev/loop-control in the
    image, losetup continues to fail.  Also tried stracing losetup but that
    fails like this, presumably because it is not allowed inside the Docker
    image:
        $ strace losetup --find --show /tmp/disk.img
        strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted
        +++ exited with 1 +++
    
    For now I have run out of ways to investigate and resolve this, so just
    exclude the 12 tests which required loop devices.  All the tests still
    execute when run locally outside the restricted GNOME GitLab CI Docker
    setup.
    
    Closes !59 - Fix GNOME GitLab CI test job failures because of missing
                 /dev entries

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

    Create block special devices needed by test_BlockSpecial in GitLab CI jobs (!59)
    
    From 23-Feb-2020 onwards, GNOME GitLab Continuous Integration test jobs
    have been failing running unit tests which previously succeeded.  With
    some extra debugging added into test_BlockSpecial to print 'bname' and
    'bs' values in the failing tests, here are fragments from
    tests/test-suite.log for the the test_BlockSpecial failures in a test CI
    job:
    
        FAIL: test_BlockSpecial
        =======================
        ...
        [ RUN      ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice
        bname="/dev/sr0"
        bs=BlockSpecial{"/dev/sr0",0,0}
        test_BlockSpecial.cc:218: Failure
        Value of: bs.m_major > 0 || bs.m_minor > 0
          Actual: false
        Expected: true
        [  FAILED  ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice (0 ms)
        ...
        [ RUN      ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices
        bname1="/dev/sr0"
        bname2="/dev/sda"
        bs1=BlockSpecial{"/dev/sr0",0,0}
        bs2=BlockSpecial{"/dev/sda",0,0}
        test_BlockSpecial.cc:250: Failure
        Value of: bs1.m_major != bs2.m_major || bs1.m_minor != bs2.m_minor
          Actual: false
        Expected: true
        [  FAILED  ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices (1 ms)
    
    Contents of /proc/partitions inside the Docker image when this test CI
    job failed:
    
        $ cat /proc/partitions
        major minor  #blocks  name
          11        0    1048575 sr0
           8        0  573367448 sda
           8        1  573366407 sda1
    
    And the listing of /dev/:
    
        $ ls -l /dev/
        total 0
        lrwxrwxrwx 1 root root   11 Mar  3 09:00 core -> /proc/kcore
        lrwxrwxrwx 1 root root   13 Mar  3 09:00 fd -> /proc/self/fd
        crw-rw-rw- 1 root root 1, 7 Mar  3 09:00 full
        drwxrwxrwt 2 root root   40 Mar  3 09:00 mqueue
        crw-rw-rw- 1 root root 1, 3 Mar  3 09:00 null
        lrwxrwxrwx 1 root root    8 Mar  3 09:00 ptmx -> pts/ptmx
        drwxr-xr-x 2 root root    0 Mar  3 09:00 pts
        crw-rw-rw- 1 root root 1, 8 Mar  3 09:00 random
        drwxrwxrwt 2 root root   40 Mar  3 09:00 shm
        lrwxrwxrwx 1 root root   15 Mar  3 09:00 stderr -> /proc/self/fd/2
        lrwxrwxrwx 1 root root   15 Mar  3 09:00 stdin -> /proc/self/fd/0
        lrwxrwxrwx 1 root root   15 Mar  3 09:00 stdout -> /proc/self/fd/1
        crw-rw-rw- 1 root root 5, 0 Mar  3 09:00 tty
        crw-rw-rw- 1 root root 1, 9 Mar  3 09:00 urandom
        crw-rw-rw- 1 root root 1, 5 Mar  3 09:00 zero
    
    See how the test_BlockSpecial fixtures are getting major=0 and minor=0
    for the block special devices they are testing with.  This is happening
    because there aren't any entries in /dev for those disks and partitions
    listed in /proc/partitions.  Assume that Docker in GNOME GitLab has
    changed and that unneeded and unwanted devices in /dev are no longer
    being created inside images.
    
    In the test CI jobs execute new script, tests/makedev.sh, to create just
    the first two block special devices mentioned in /proc/partitions needed
    by test_BlockSpecial.
    
    Closes !59 - Fix GNOME GitLab CI test job failures because of missing
                 /dev entries

2020-01-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Delete old Fill txtview_device_info_buffer comment
    
    Seems to be referring to how Fill_Label_Device_Info() worked in the
    past, but from history before the beginning of the GIT repository.
    Remove out of date comment.

2020-02-29  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Reliably detect running gpartedbin using pidof (!54)
    
    Debian user reported a bug [1] that when they had PS_FORMAT environment
    variable set it prevented GParted running:
    
        # export PS_FORMAT='ruser,uid,pid,ppid,pri,ni,%cpu,%mem,vsz,rss,stat,tty,start,time,command'
        # gparted
        The process gpartedbin is already running.
        Only one gpartedbin process is permitted.
        # echo $?
        1
    
    Using ps column 'command' includes the command and all it's arguments,
    rather than just the command name as ps displays by default.  Thus the
    shell wrapper finds the grep command it's using when searching for the
    gpartedbin executable.
    
        # ps -e | grep gpartedbin
        root         0 26114 14777  19   0  0.0  0.0 112712   940 S+   pts/0    10:42:02 00:00:00 grep --color=auto gpartedbin
    
    Fix by searching for running processes using pidof.  pgrep does regular
    expression matching where as pidof checks program name is the same [2].
    Therefore use of pidof is preferred over pgrep [3].
    
    [1] Debian bug #864932 - gparted fails if PS_FORMAT options are
                             specified
        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864932
    
    [2] Difference between pidof and pgrep?
        https://stackoverflow.com/questions/52151698/difference-between-pidof-and-pgrep
    
    [3] [PATCH] gparted.in: Use reliable way of detecting gpartedbin process
        existence
        https://git.alpinelinux.org/aports/tree/community/gparted/gparted.in-Use-reliable-way-of-detecting-gpartedbin-.patch
    
    Closes !54 - Fix gparted not launching when PS_FORMAT environment
                 variable set

2020-02-16  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Rename local variables to mke2fs_*_ver
    
    To better reflect that they represent the version of mke2fs executable
    from the e2fsprogs package, even though the executable is called as
    mkfs.ext4.
    
        $ ls -il /sbin/mke2fs /sbin/mkfs.ext*
        1978670 -rwxr-xr-x. 4 root root 96384 Aug  9  2019 /sbin/mke2fs
        1978670 -rwxr-xr-x. 4 root root 96384 Aug  9  2019 /sbin/mkfs.ext2
        1978670 -rwxr-xr-x. 4 root root 96384 Aug  9  2019 /sbin/mkfs.ext3
        1978670 -rwxr-xr-x. 4 root root 96384 Aug  9  2019 /sbin/mkfs.ext4
        $ mkfs.ext4 -V
        mke2fs 1.42.9 (28-Dec-2013)
                Using EXT2FS Library version 1.42.9
        $ mke2fs -V
        mke2fs 1.42.9 (28-Dec-2013)
                Using EXT2FS Library version 1.42.9

2020-02-14  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Simplify sscanf("mke2fs ...") text match
    
    With removal of support for RHEL / CentOS 5 and it's e4fsprogs package
    [1][2] it is no longer necessary to accept:
        mke4fs 1.41.12 (17-May-2010)
    only:
        mke2fs 1.42.9 (28-Dec-2013)
    
    [1] 6c4ab5dc28a14f3bef2d1c1a24da219381d513f0
        Remove checks for e4fsprogs commands (#794253)
    
    [2] de6e70d933286f3c65187470c9852fb6d8a60a7d
        Simplify ext2::get_filesystem_support() with regard ext4 support (#794253)

2020-02-16  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Raise minimum supported dosfstools to 3.0.18 (!57)
    
    This earlier commit [1] from 2013 recognised the new names for programs
    in dosfstools >= 3.0.18, specifically mkfs.fat and fsck.fat.  Now that
    the oldest supported distributions use dosfstools >= 3.0.18 it is no
    longer necessary to support using the old names of mkdosfs and dosfsck,
    so remove that code.
    
        Oldest supported   Dosfstools
        distributions      Version
    
        Debian 8           3.0.27
        RHEL / CentOS 7    3.0.20
        SLES 12            3.0.26
        Ubuntu 14.04 LTS   3.0.26
    
    [1] 1ae03dee953f512c0c664369db2d5e5db80b4058
        Recognise new dosfstools program names (#704629)
    
    Closes !57 - Raise minimum support dosfstools to 3.0.18 released
                 2013-06-06

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

    Remove unused udevinfo from README
    
    Missed removing mention of udevinfo from README when this earlier commit
    removed it's use by GParted.
        3f15a66291af1f2db142edfe2a9219da219a29d5
        Drop use of long ago removed udevinfo

2020-02-03  Mike Fleetwood <mike.fleetwood@googlemail.com>

    Wait for udev change on /dev/DISK when erasing signatures (#83)
    
    A user reported that formatting a whole disk device with a file system
    failed like this:
    
        Format /dev/sdd as ext4                                    (ERROR)
        + calibrate /dev/sdd                                       (SUCCESS)
            path: /dev/sdd (device)
            start: 0
            end: 15633407
            size: 15633408 (7.45 GiB)
        + clear old file system signatures in /dev/sdd             (SUCCESS)
          + write 512.00 KiB of zeros at byte offset 0             (SUCCESS)
          + write 4.00 KiB of zeros at byte offset 67108864        (SUCCESS)
          + write 512.00 KiB of zeros at byte offset 8003780608    (SUCCESS)
          + write 4.00 KiB of zeros at byte offset 8004239360      (SUCCESS)
          + write 8.00 KiB of zeros at byte offset 8004296704      (SUCCESS)
          + flush operating system cache of /dev/sdd               (SUCCESS)
        + create new ext4 file system                              (ERROR)
          + mkfs.ext4 -F -O ^64bit -L '' '/dev/sdd'                (ERROR)
            mke2fs 1.44.1 (24-Mar-2018)
            /dev/sdd is apparently in use by the system; will not make a filesystem here!
    
    Opening the whole disk block device exclusively causes mkfs.ext4 to
    report that error like this:
    
        # python
        >>> import os
        >>> f = os.open('/dev/sdb',os.O_RDONLY|os.O_EXCL)
        >>> ^Z
        [1]+  Stopped                 python
        # mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb'
        mke2fs 1.42.9 (28-Dec-2013)
        /dev/sdb is apparently in use by the system; will not make a filesystem here!
        # echo $?
        1
    
    I have not been able to reproduce this error, but with debugging and
    sleeping in GParted, stracing GParted and using 'udevadm monitor' to
    watch udev events the following sequence of events is seen:
    
      gparted    |format(partition, operationdetail)
      gparted    |  erase_filesystem_signatures(partition, operationdetail)
      gparted    |    get_device(device_path="/dev/sdb", lp_device, flush=false)
      gparted    |      ped_device_get("/dev/sdb")
      libparted  |        open("/dev/sdb", O_RDONLY) = 11
      libparted  |        close(11)
      gparted    |    ped_device_open(lp_device)
      libparted  |      open("/dev/sdb", O_RDWR) = 11
      gparted    |    ped_device_sync(lp_device)
      libparted  |      ioctl(11, BLKFLSBUF)
      gparted    |    ped_device_close()
      libparted  |      close(11)
      udev(async)|        KERNEL change /devices/.../sdb (block)
      udev(async)|        UDEV   change /devices/.../sdb (block)
      gparted    |  set_partition_type(partition, operationdetail)
      gparted    |  create_filesystem(partition, operationdetail)
      gparted    |    ext2::create(partition, operationdetail)
      gparted    |      FileSystem::execute_command("mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb')
    
    So it is assumed that the processing of the udev change rule after
    closing the block device in erase_filesystem_signatures() overlaps with
    the execution mkfs.ext4 and causes the seen error.  Fix by waiting for
    those udev events to complete as was previously done by commits [1][2]
    [3].
    
    Also note that this is specific to creating file systems on and
    formatting unpartitioned whole disk devices because set_partition_type()
    is a no-operation.  Where as on a partitioned device
    set_partition_type() calls commit() which already waits for udev rules
    to complete [3].
    
    [1] 50c8924a8e4d9cc96a2ea45f13291114402affee
        Wait for udev to recreate /dev/PTN entries when querying partition
        FSs (!46)
    [2] 4f6c312e3bc68cafb5e6035fd4a5b5bbbfcea992
        Wait for udev change on /dev/DISK when querying whole device FS
        (!46)
    [3] 2f53876c0fc8bceddabe739c298e19e7939d9ad7
        Wait for the kernel and udev to settle partitions for a second time
        (#790418)
    
    Closes #83 - /dev/sdd is apparently in use by the system; will not make
                 a filesystem here!

2020-02-25  Daniele Forsi <dforsi@gmail.com>

    Fix formatting directive in it.po (!58)
    
    Fixes:
        (gpartedbin:78003): glibmm-WARNING **: 22:55:05.465: invalid
        substitution "%s" in fmt string "percorso: %1 (%s)"
    
    Closes !58 - Fix formatting directive in it.po (!58)

2020-02-26  Nathan Follens <nfollens@gnome.org>

    Update Dutch translation

2020-02-23  Daniel Korostil <ted.korostiled@gmail.com>

    Update Ukrainian translation

2020-02-04  Daniel Mustieles <daniel.mustieles@gmail.com>

    Updated Spanish translation

2020-01-29  Dušan Kazik <prescott66@gmail.com>

    Update Slovak translation

2020-01-20  Curtis Gedak <gedakc@gmail.com>

    Append -git to version for continuing development
    
    Also fix minor whitespace mistake in NEWS

2020-01-20  Curtis Gedak <gedakc@gmail.com>

