1. 12 Jul, 2020 1 commit
  2. 26 Jun, 2020 1 commit
  3. 31 May, 2020 1 commit
  4. 27 May, 2020 4 commits
    • Mike Fleetwood's avatar
      Add missing includes into Devices module · 201f5f2f
      Mike Fleetwood authored
      201f5f2f
    • Mike Fleetwood's avatar
      Exclude PipeCapture read NUL byte unit tests in GitLab CI jobs (!60) · e9223207
      Mike Fleetwood authored
      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
      e9223207
    • Mike Fleetwood's avatar
      Add C++ compiler into GitLab CI Ubuntu image (!60) · c5093b7d
      Mike Fleetwood authored
      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
      c5093b7d
    • Mike Fleetwood's avatar
      Prevent tzdata install hang in GitLab CI Ubuntu image (!60) · 5fecdbfc
      Mike Fleetwood authored
      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
      5fecdbfc
  5. 24 May, 2020 1 commit
  6. 04 May, 2020 1 commit
  7. 14 Mar, 2020 4 commits
    • Mike Fleetwood's avatar
      Replace TRUE #define with C++ true literal · b74b05f3
      Mike Fleetwood authored
      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.
      b74b05f3
    • Mike Fleetwood's avatar
      Add /dev/disk/by-id/ symlink in CI for test_BlockSpecial · 19ba6df8
      Mike Fleetwood authored
      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] fe2fc33e
          Exclude unit test which fails in Docker CI image (!4)
      19ba6df8
    • Mike Fleetwood's avatar
      Exclude unit tests needing losetup in Docker CI image (!59) · 39fdfe51
      Mike Fleetwood authored
      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
      39fdfe51
    • Mike Fleetwood's avatar
      Create block special devices needed by test_BlockSpecial in GitLab CI jobs (!59) · 57983b9f
      Mike Fleetwood authored
      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
      57983b9f
  8. 07 Mar, 2020 2 commits
  9. 28 Feb, 2020 3 commits
    • Mike Fleetwood's avatar
      Rename local variables to mke2fs_*_ver · 21a2da9e
      Mike Fleetwood authored
      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
      21a2da9e
    • Mike Fleetwood's avatar
      Simplify sscanf("mke2fs ...") text match · bfbd324d
      Mike Fleetwood authored
      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] 6c4ab5dc
          Remove checks for e4fsprogs commands (#794253)
      
      [2] de6e70d9
          Simplify ext2::get_filesystem_support() with regard ext4 support (#794253)
      bfbd324d
    • Mike Fleetwood's avatar
      Raise minimum supported dosfstools to 3.0.18 (!57) · a9015111
      Mike Fleetwood authored
      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] 1ae03dee
          Recognise new dosfstools program names (#704629)
      
      Closes !57 - Raise minimum support dosfstools to 3.0.18 released
                   2013-06-06
      a9015111
  10. 26 Feb, 2020 4 commits
    • Mike Fleetwood's avatar
      Remove unused udevinfo from README · b7dd5480
      Mike Fleetwood authored
      Missed removing mention of udevinfo from README when this earlier commit
      removed it's use by GParted.
          3f15a662
          Drop use of long ago removed udevinfo
      b7dd5480
    • Mike Fleetwood's avatar
      Wait for udev change on /dev/DISK when erasing signatures (#83) · 8ae9abad
      Mike Fleetwood authored
      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] 50c8924a
          Wait for udev to recreate /dev/PTN entries when querying partition
          FSs (!46)
      [2] 4f6c312e
          Wait for udev change on /dev/DISK when querying whole device FS
          (!46)
      [3] 2f53876c
          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!
      8ae9abad
    • Daniele Forsi's avatar
      Fix formatting directive in it.po (!58) · 24c0b81b
      Daniele Forsi authored
      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)
      24c0b81b
    • Nathan Follens's avatar
      Update Dutch translation · 2f9af895
      Nathan Follens authored
      2f9af895
  11. 23 Feb, 2020 1 commit
  12. 04 Feb, 2020 1 commit
  13. 29 Jan, 2020 1 commit
  14. 20 Jan, 2020 3 commits
  15. 19 Jan, 2020 1 commit
  16. 15 Jan, 2020 1 commit
  17. 14 Jan, 2020 1 commit
  18. 12 Jan, 2020 2 commits
  19. 11 Jan, 2020 2 commits
  20. 10 Jan, 2020 1 commit
  21. 04 Dec, 2019 4 commits