Commit Graph

48 Commits

Author SHA1 Message Date
Mike Fleetwood 0e46d6a7de Stop installing intltool package into Alpine and CentOS CI images (!107)
... as the GParted build no longer uses it.  (Intltool is not explicitly
installed into the Ubuntu CI image).

However removing intltool from the GitLab CentOS Continuous Integration
image causes the build job to fail like this:
    $ ./autogen.sh
    ...
    **Warning**: I am going to run `configure' with no arguments.
    If you wish to pass any to it, please specify them on the
    `./autogen.sh' command line.
    Processing ./configure.ac
    Running autoreconf...
    autoreconf: Entering directory `.'
    autoreconf: running: autopoint --force
    Can't exec "autopoint": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 345.
    autoreconf: failed to run autopoint: No such file or directory
    autoreconf: autopoint is needed because this package uses Gettext

This is because on CentOS 7 autopoint is provided by the gettext-devel
package which was installed as a requirement for intltool.  Fix the
build by explicitly installing the package.

(On Alpine Linux the gettext-dev package is automatically installed and
on Ubuntu the autopoint package is automatically installed so those CI
images don't need to explicitly include the relevant package).

Closes !107 - Migrate from intltool to gettext translation
2022-11-12 16:44:55 +00:00
Mike Fleetwood 8450d8c605 Fix .policy file translation failure in CentOS CI image (!107)
Build in CentOS 7 CI job fails like this:
    $ make -j $nproc
    ...
    /usr/bin/msgfmt --desktop --template gparted.desktop.in -d ./po -o gparted.desktop
    /usr/bin/msgfmt --xml --template org.gnome.gparted.policy.in -d ./po -o org.gnome.gparted.policy
    /usr/bin/msgfmt: cannot locate ITS rules for org.gnome.gparted.policy.in
    make[2]: *** [org.gnome.gparted.policy] Error 1
    make[2]: *** Waiting for unfinished jobs....
    make[2]: Leaving directory `/builds/mfleetwo/gparted'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/builds/mfleetwo/gparted'
    make: *** [all] Error 2

As with Alpine Linux fixed in the previous commit, CentOS doesn't
install the needed rules files by default.  Add polkit-devel package to
CentOS CI image to fix this.

Closes !107 - Migrate from intltool to gettext translation
2022-11-12 16:44:55 +00:00
Mike Fleetwood 57ae8f888b Fix .policy file translation failure in Alpine Linux CI image (!107)
In the Alpine Linux 3.16 CI build job, file org.gnome.gparted.policy is
not translated with this warning:
    $ make -j $nproc
    ...
    /usr/bin/xgettext: warning: a fallback ITS rule file '/usr/share/gettext-0.21/its/metainfo.its' is used; it may not be in sync with the upstream
    /usr/bin/xgettext: warning: file 'org.gnome.gparted.policy.in.in' extension 'policy' is unknown; will try C

In my Alpine Linux 3.15 VM building GParted fails like this:
    $ make
    ...
    make[2]: Entering directory '/home/alpine/programming/c/gparted'
    sed -e 's,[@]libexecdir[@],/usr/local/libexec,g' -e 's,[@]bindir[@],/usr/local/bin,g' -e 's,[@]gksuprog[@],pkexec --disable-internal-agent,g' -e 's,[@]enable_xhost_root[@],no,g' < ./org.gnome.gparted.policy.in.in > org.gnome.gparted.policy.in
    /usr/bin/msgfmt --xml --template org.gnome.gparted.policy.in -d ./po -o org.gnome.gparted.policy
    /usr/bin/msgfmt: cannot locate ITS rules for org.gnome.gparted.policy.in
    make[2]: *** [Makefile:1059: org.gnome.gparted.policy] Error 1
    make[2]: Leaving directory '/home/alpine/programming/c/gparted'
    make[1]: *** [Makefile:617: all-recursive] Error 1
    make[1]: Leaving directory '/home/alpine/programming/c/gparted'
    make: *** [Makefile:451: all] Error 2

This is because gettext's msgfmt doesn't have rules for what elements to
translate in .policy XML files.  Add polkit-dev package to Alpine Linux
CI image to provide these files:
        /usr/share/gettext/its/policy.its
        /usr/share/gettext/its/policy.loc

Now the .policy file is translated successfully:
    $ make
    ...
    make[2]: Entering directory '/home/alpine/programming/c/gparted'
    /usr/bin/msgfmt --xml --template org.gnome.gparted.policy.in -d ./po -o org.gnome.gparted.policy
    make[2]: Leaving directory '/home/alpine/programming/c/gparted'

Closes !107 - Migrate from intltool to gettext translation
2022-11-12 16:44:55 +00:00
Mike Fleetwood d90be4e36b Install git into Alpine CI image to fix autopoint error (!107)
Alpine Linux build CI job fails like this:
    $ ./autogen.sh
    ...
    Running autoreconf...
    autoreconf: export WARNINGS=no-portability
    autoreconf: Entering directory '.'
    autoreconf: running: autopoint --force
    autopoint: *** git program not found
    autopoint: *** Stop.
    autoreconf: error: autopoint failed with exit status: 1

This is because gettext's autopoint command in Alpine Linux is built
with a git archive of application support files:
    $ autopoint --version
    /usr/bin/autopoint (GNU gettext-tools) 0.21
    Uses a versions archive in git format.
    ...
    $ ls -l /usr/share/gettext/archive*
    -rw-r--r-- 1 root root 752320 Jan 14 2021 /usr/share/gettext/archive.git.tar.gz

Where as for other distributions gettext's autopoint command uses plain
compressed tar archive, for example in Ubuntu 22.04 LTS:
    $ autopoint --version
    /usr/bin/autopoint (GNU gettext-tools) 0.21
    Uses a versions archive in dirxz format.
    ...
    $ ls -l /usr/share/gettext/archive*
    -rw-r--r-- 1 root root 407064 Mar 25 10:31 /usr/share/gettext/archive.dir.tar.xz

Fix by adding git to the packages installed into the Alpine Linux CI
docker image.

Closes !107 - Migrate from intltool to gettext translation
2022-11-12 16:44:55 +00:00
Mike Fleetwood 845b5341f5 Use apt to install packages on Debian and related distros
Apt is the modern recommended command to use when installing packages
these days on Debian and related distributions [1][2][3].  Convert the
Ubuntu GitLab CI jobs and update the README accordingly.

[1] What is the difference between apt and apt-get?
    https://askubuntu.com/questions/445384/what-is-the-difference-between-apt-and-apt-get
[2] Difference Between apt and apt-get Explained
    https://itsfoss.com/apt-vs-apt-get-difference/
[2] Apt and Apt-get - Which One to Use
    https://linoxide.com/apt-and-apt-get-which-one-to-use/
2022-08-25 15:41:31 +00:00
Mike Fleetwood 567bf01895 Automate exclusion of loop device tests from CI image (!105)
Avoid having to manually maintain the list of excluded File System tests
in the GitLab Docker CI image.  Scan the unit test source extracting
those tests marked with SKIP_IF_NOT_ROOT_FOR_REQUIRED_LOOPDEV_FOR_FS()
to automatically construct the setting for the GTEST_FILTER environment
variable.

Closes !105 - Update used btrfs file system commands, new minimum is
              btrfs-progs 4.5
2022-08-25 15:41:31 +00:00
Mike Fleetwood f6b253a2cf Allow execution of more btrfs CI unit tests (!105)
Now that reading btrfs usage, UUID and label can be performed on a file
system image remove the need for a loop device for the relevant unit
tests.

Closes !105 - Update used btrfs file system commands, new minimum is
              btrfs-progs 4.5
2022-08-25 15:41:31 +00:00
Mike Fleetwood bfea656209 Add unit testing of GParted exFAT interface to ubuntu_test CI job
Now that the docker image for ubuntu:latest has updated to Ubuntu 22.04
LTS [1] and exfatprogs is available [2] add the package to the CI job to
include it in the testing.

[1] Ubuntu Docker official image
    https://hub.docker.com/_/ubuntu/
    "Supported tags and respective Dockerfile links
    ...
    22.04, ..., latest, ...
    "
[2] Ubuntu > Packages > jammy (22.04LTS) > otherosfs > exfatprogs
    https://packages.ubuntu.com/jammy/exfatprogs
[3] 3783cb4173
    Add unit testing of GParted exFAT interface (!30)
2022-07-04 17:50:25 +00:00
Mike Fleetwood fde76a949f Add CreateAndWriteUUIDAndReadLabel unit test (!104)
During review and testing of this patchset it was discovered that using
GParted to set a new UUID on a FAT16 or FAT32 file system that there was
a new unwanted side effect of clearing the label.

Add unit test to cover this error scenario.  It does the following:
1. Creates a file system with a known label;
2. Writes a new UUID;
3. Reads the label and confirms it matches the initial label.

This new unit test captures the fault like this:
    $ ./test_SupportedFileSystems --gtest_filter='*CreateAndWriteUUIDAndReadLabel*'
    ...
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat16
    test_SupportedFileSystems.cc:645: Failure
    Expected equality of these values:
      fs_label
        Which is: "TEST_LABEL"
      m_partition.get_filesystem_label().c_str()
        Which is: ""
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat16, where GetParam() = 13 (21 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat32
    test_SupportedFileSystems.cc:645: Failure
    Expected equality of these values:
      fs_label
        Which is: "TEST_LABEL"
      m_partition.get_filesystem_label().c_str()
        Which is: ""
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndWriteUUIDAndReadLabel/fat32, where GetParam() = 14 (22 ms)

Don't forget to exclude this unit test for file systems which need a
loop device but which fails to be created inside the docker CI image.
Reference:
    39fdfe51da
    Exclude unit tests needing losetup in Docker CI image (!59)

Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues
              with FAT16/32
2022-07-04 17:50:25 +00:00
Mike Fleetwood b7f951bcb8 Fix make distcheck in Alpine Linux CI test job (!104)
The make distcheck step of the CI test job fails like this on Alpine
Linux:
    $ make distcheck
    ...
    make[1]: Leaving directory '/home/alpine/programming/c/gparted'
    if test -d "gparted-1.4.0-git"; then find "gparted-1.4.0-git" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -rf "gparted-1.4.0-git" || { sleep 5 && rm -rf "gparted-1.4.0-git"; }; else :; fi
    case 'gparted-1.4.0-git.tar.gz' in \
    *.tar.gz*) \
      eval GZIP= gzip --best -dc gparted-1.4.0-git.tar.gz | ${TAR-tar} xf - ;;\
    *.tar.bz2*) \
      bzip2 -dc gparted-1.4.0-git.tar.bz2 | ${TAR-tar} xf - ;;\
    *.tar.lz*) \
      lzip -dc gparted-1.4.0-git.tar.lz | ${TAR-tar} xf - ;;\
    *.tar.xz*) \
      xz -dc gparted-1.4.0-git.tar.xz | ${TAR-tar} xf - ;;\
    *.tar.Z*) \
      uncompress -c gparted-1.4.0-git.tar.Z | ${TAR-tar} xf - ;;\
    *.shar.gz*) \
      eval GZIP= gzip --best -dc gparted-1.4.0-git.shar.gz | unshar ;;\
    *.zip*) \
      unzip gparted-1.4.0-git.zip ;;\
    *.tar.zst*) \
      zstd -dc gparted-1.4.0-git.tar.zst | ${TAR-tar} xf - ;;\
    esac
    gzip: unrecognized option: best
    BusyBox v1.35.0 (2022-05-09 17:27:12 UTC) multi-call binary.

    Usage: gzip [-cfkdt123456789] [FILE]...

    Compress FILEs (or stdin)

            -1..9   Compression level
            -d      Decompress
            -c      Write to stdout
            -f      Force
            -k      Keep input files
            -t      Test integrity
    tar: short read
    make: *** [Makefile:844: distcheck] Error 1

Busybox gzip is erroring because it doesn't make sense to request best
compression when decompressing to stdout in this command:
    eval GZIP= gzip --best -dc gparted-1.4.0-git.tar.gz | ${TAR-tar} xf -

Fix by installing the GNU gzip package into Alpine Linux test CI job docker
image.

Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues
              with FAT16/32
2022-07-04 17:50:25 +00:00
Mike Fleetwood 1424b7a5f4 Avoid using += shell variable concatenation in CI test jobs (!104)
The test CI job on Alpine Linux fails like this:
    $ GTEST_FILTER+=':My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs'
    /bin/sh: eval: line 135: GTEST_FILTER+=:My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs: not found

This is because the busybox ash shell in Alpine Linux doesn't support +=
syntax for variable concatenation.  Use plain variable assignment
instead.

Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues
              with FAT16/32
2022-07-04 17:50:25 +00:00
Mike Fleetwood 50388033dd Add Alpine Linux CI test job (!104)
Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues
              with FAT16/32
2022-07-04 17:50:25 +00:00
Mike Fleetwood 7e1fef16ae Add Alpine Linux CI build job (!104)
There have been a number of GParted build issues [1][2] recently on
Alpine Linux because it uses musl libc [3] which is stricter to POSIX,
rather than the GNU C Library (glibc) which has numerous enhancements.
Glibc is used by most Linux distributions, including CentOS and Ubuntu
already used in the GNOME Continuous Integration jobs.  So add a GParted
build job on Alpine Linux to catch these issues in future.  Uses the
docker image of the latest Alpine Linux release.

[1] 3d4b1c1e7b
    Fix NULL == 0 assumption in call to ped_partition_flag_next() (!100)
[2] 45c00927b7
    Use POSIX basename() in BCache_Info.cc (!99)
[3] musl libc
    https://musl.libc.org/

Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues
              with FAT16/32
2022-07-04 17:50:25 +00:00
Mike Fleetwood 2ff4a4203f Print kernel and OS details first in the GitLab CI jobs
When the CentOS 7 CI jobs were failing on a subset of the job runners
[1] during March to May 2022, the docker image would hang even before
the packages were fully installed so cat /proc/version and cat
/etc/os-release were never run.  Move them to the first thing done in
the docker image.

[1] Hanging of GitLab CI jobs on a subset of job runners
    https://discourse.gnome.org/t/hanging-of-gitlab-ci-jobs-on-a-subset-of-job-runners/9931
2022-07-04 17:50:25 +00:00
Mike Fleetwood b3f5213207 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-11 16:44:50 +00:00
Mike Fleetwood 30ff497c6e 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
are:

    *.CreateAndReadLabel/lvm2pv
    *.CreateAndReadUUID/lvm2pv
    *.CreateAndWriteLabel/lvm2pv
    *.CreateAndWriteUUID/lvm2pv
    *.CreateAndGrow/jfs
    *.CreateAndGrow/nilfs2
    *.CreateAndShrink/nilfs2

For LVM2 PVs reading and writing of labels and UUIDs aren't implemented
(only reading of UUIDs could be supported as the others are impossible)
so those tests are always skipped.  Add unit test exclusions just for
completeness.

JFS grow is this case.  NILFS2 grow and shrink are more cases where
kernel support is needed.  Add unit test exclusions to stop attempting
to run JFS and NILFS2 resizing tests, which don't currently work because
losetup doesn't work in the GitLab CI docker images [1].

[1] 39fdfe51da
    Exclude unit tests needing losetup in Docker CI image (!59)

Closes #147 - GitLab CI job failure from *.CreateAndGrow/jfs
2021-03-11 16:44:50 +00:00
Mike Fleetwood b711bcbfd5 Re-enable PipeCapture read NUL byte unit tests in GitLab CI jobs (#136)
This reverts commit:
    e9223207e6.
    Exclude PipeCapture read NUL byte unit tests in GitLab CI jobs (!60)
now that PipeCapture has been fixed to read NUL characters again.

Closes #136 - 1.2.0: test suite is failing in test_PipeCapture
2021-02-22 16:14:35 +00:00
Mike Fleetwood 3783cb4173 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-15 19:55:17 +00:00
Mike Fleetwood 70db3469c5 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-18 16:00:44 +00:00
Mike Fleetwood e9223207e6 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-27 16:02:47 +00:00
Mike Fleetwood c5093b7d54 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-27 16:02:47 +00:00
Mike Fleetwood 5fecdbfc96 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-27 16:02:47 +00:00
Mike Fleetwood 19ba6df8f0 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] fe2fc33e67
    Exclude unit test which fails in Docker CI image (!4)
2020-03-14 15:31:37 +00:00
Mike Fleetwood 39fdfe51da 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-14 15:31:37 +00:00
Mike Fleetwood 57983b9fc2 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-03-14 15:31:37 +00:00
Mike Fleetwood ce18685dfa Save all files on CI job failure for investigation
Since patchset !49 "Add file system interface tests" was merged the
GitLab Continuous Integration jobs have sometimes failed executing
test_SupportedFilesystems.  So on failure save all files from the docker
image for 1 week for investigation.

Documentation:
* Introduction to job artifacts
  https://gitlab.gnome.org/help/user/project/pipelines/job_artifacts.md

* GitLab CI/CD Pipeline Configuration Reference, artifacts
  https://gitlab.gnome.org/help/ci/yaml/README.md#artifacts
2019-12-04 07:38:01 +00:00
Mike Fleetwood f2165fd44d Prevent file system tests core dumping in GitLab CI Ubuntu image (!49)
With the previous commit, execution of test_SupportedFileSystems is
failing in the GitLab CI Ubuntu image.  Fragment from file
tests/test-suite.log:

    FAIL: test_SupportedFileSystems
    ===============================

    Terminate called after throwing an instance of 'Glib::ConvertError'
    Aborted (core dumped)
    FAIL test_SupportedFileSystems (exit status: 134)

This core dump can be re-created locally by (1) removing modprobe from
the PATH, and (2) executing the test program in the C locale.

    $ LC_ALL=C ./test_SupportedFileSystems
    Running main() from test_SupportedFileSystems.cc
    terminate called after throwing an instance of 'Glib::ConvertError'
    Aborted
    $ echo $?
    134

Backtrace from gdb:
    (gdb) backtrace
    #0  0x00007f4f93002337 in __GI_raise (sig=sig@entry=6)
        at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
    #1  0x00007f4f93003a28 in __GI_abort () at abort.c:90
    #2  0x00007f4f93b2e7d5 in __gnu_cxx::__verbose_terminate_handler() ()
        at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
    #3  0x00007f4f93b2c746 in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>)
        at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38
    #4  0x00007f4f93b2c773 in std::terminate() ()
        at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
    #5  0x00007f4f93b2c993 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*))
        (obj=0x260d4b0, tinfo=0x7f4f966c1930 <typeinfo for Glib::ConvertError>, dest=0x7f4f96486fa0 <Glib::ConvertError::~ConvertError()>)
        at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:87
    #6  0x00007f4f96486e27 in Glib::ConvertError::throw_func(_GError*) (gobject=0x260bf90) at convert.cc:329
    #7  0x00007f4f9649b5d7 in Glib::Error::throw_exception(_GError*) (gobject=0x260bf90) at error.cc:175
    #8  0x00007f4f964a7155 in Glib::operator<<(std::ostream&, Glib::ustring const&)
        (os=warning: RTTI symbol not found for class 'std::ostream' ..., utf8_string=...) at ustring.cc:1430
    #9  0x000000000044d66f in GParted::Utils::execute_command(Glib::ustring const&, char const*, Glib::ustring&, Glib::ustring&, bool)
        (command=..., input=input@entry=0x0, output=..., error=..., use_C_locale=use_C_locale@entry=true)
        at ../src/Utils.cc:688
    #10 0x000000000044dae9 in GParted::Utils::kernel_supports_fs(Glib::ustring const&)
        (use_C_locale=true, error=..., output=..., command=...)
        at ../src/Utils.cc:659
    #11 0x000000000044dae9 in GParted::Utils::kernel_supports_fs(Glib::ustring const&) (fs=...)
        at ../src/Utils.cc:480
    #12 0x0000000000460008 in GParted::jfs::get_filesystem_support() (this=0x25e8e60)
        at ../src/jfs.cc:59
    #13 0x00000000004464f9 in GParted::SupportedFileSystems::find_supported_filesystems() (this=0x25e8690)
        at ../src/SupportedFileSystems.cc:120
    #14 0x0000000000412360 in GParted::SupportedFileSystemsTest::setup_supported_filesystems() ()
        at test_SupportedFileSystems.cc:278
    #15 0x00000000004151b0 in GParted::SupportedFileSystemsTest::get_supported_fstypes() ()
        at test_SupportedFileSystems.cc:256
    #16 0x00000000004152c0 in GParted::gtest_MySupportedFileSystemsTest_EvalGenerator_() ()
        at test_SupportedFileSystems.cc:495
    #17 0x000000000041c7d6 in testing::internal::ParameterizedTestCaseInfo<GParted::SupportedFileSystemsTest>::RegisterTests()
        (this=0x2528ac0) at ../lib/gtest/include/gtest/internal/gtest-param-util.h:549
    #18 0x0000000000479fb5 in testing::internal::UnitTestImpl::RegisterParameterizedTests() (this=0x25288d0)
        at ./include/gtest/internal/gtest-param-util.h:709
    #19 0x0000000000479fb5 in testing::internal::UnitTestImpl::RegisterParameterizedTests()
        (this=this@entry=0x2528800) at ./src/gtest.cc:2658
    #20 0x000000000048a001 in testing::internal::UnitTestImpl::PostFlagParsingInit() (this=0x2528800)
        at ./src/gtest.cc:4980
    #21 0x000000000049e399 in testing::internal::InitGoogleTestImpl<char>(int*, char**)
        (argc=argc@entry=0x7ffe9d208a3c, argv=argv@entry=0x7ffe9d208b38) at ./src/gtest.cc:5934
    #22 0x000000000048d285 in testing::InitGoogleTest(int*, char**)
        (argc=argc@entry=0x7ffe9d208a3c, argv=argv@entry=0x7ffe9d208b38) at ./src/gtest.cc:5952
    #23 0x0000000000410404 in main(int, char**) (argc=1, argv=0x7ffe9d208b38)
        at test_SupportedFileSystems.cc:557

The test program runs when executed in my locale and produces these
messages:

    $ ./test_SupportedFileSystems
    Running main() from test_SupportedFileSystems.cc
    Failed to execute child process “modprobe” (No such file or directory)
    Failed to execute child process “modprobe” (No such file or directory)
    [==========] Running 210 tests from 1 test case.
...

So the test program is aborting when trying to print the failed to
execute child process message, but only in the C locale.

This doesn't affect the CentOS GitLab CI image because that installs the
kmod package with modprobe by default, however the Ubuntu image doesn't
have the kmod package.

Fix this by explicitly installing the kmod package into both the CentOS
and Ubuntu GitLab CI images.

Closes !49 - Add file system interface tests
2019-11-09 17:18:34 +00:00
Mike Fleetwood 8f4edb0693 Extend tests to all fully supported file systems (!49)
Extend testing to all fully supported file systems, those with an
implemented FileSystem derived class.

Note that in main() GParted threading needs to now be initialised before
InitGoogleTest() because it calls INSTANTIATE_TEST_CASE_P() which in
turn calls get_supported_fstypes() which eventually constructs all the
individual file system interface objects and discovers available
support, some of which use execute_command().  Example call chain:
    InitGoogleTest()
      INSTANTIATE_TEST_CASE_P()
        get_supported_fstypes()
          setup_supported_filesystems()
            {SupportedFileSystems}->find_supported_filesystems()
              {btrfs}->get_filesystem_support()
                Utils::execute_command()

In the CentOS 7 GitLab CI image the EPEL (Extra Packages for Enterprise
Linux) repository is added to provide f2fs-tools and ntfsprogs.

23 of 210 tests fail on CentOS 7 and 22 on Ubuntu 18.04 LTS.  The
following commits will resolve these test failures.

    $ ./test_SupportedFileSystems
    Running main() from test_SupportedFileSystems.cc
    [==========] Running 210 tests from 1 test case.
    [----------] Global test environment set-up.
    [----------] 210 tests from My/SupportedFileSystemsTest
...
    [----------] 210 tests from My/SupportedFileSystemsTest (11066 ms total)

    [----------] Global test environment tear-down
    [==========] 210 tests from 1 test case ran. (11067 ms total)
    [  PASSED  ] 187 tests.
    [  FAILED  ] 23 tests, listed below:
    [  FAILED  ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam() = 20
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUsage/lvm2pv, where GetParam() = 20
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUsage/nilfs2, where GetParam() = 22
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUsage/ntfs, where GetParam() = 23
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs, where GetParam() = 7
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadLabel/nilfs2, where GetParam() = 22
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/btrfs, where GetParam() = 7
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16, where GetParam() = 13
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat32, where GetParam() = 14
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/jfs, where GetParam() = 17
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/nilfs2, where GetParam() = 22
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndWriteLabel/nilfs2, where GetParam() = 22
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndWriteUUID/nilfs2, where GetParam() = 22
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndCheck/lvm2pv, where GetParam() = 20
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndCheck/minix, where GetParam() = 21
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndRemove/lvm2pv, where GetParam() = 20
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndGrow/btrfs, where GetParam() = 7
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndGrow/lvm2pv, where GetParam() = 20
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndGrow/xfs, where GetParam() = 27
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndShrink/btrfs, where GetParam() = 7
    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndShrink/lvm2pv, where GetParam() = 20

    23 FAILED TESTS

Closes !49 - Add file system interface tests
2019-11-09 17:18:34 +00:00
Mike Fleetwood 0a23b631c3 Add testing of linux-swap using Value-Parameterised Google Tests (!49)
Use Google Test Value-Parameterised to call every test for both ext2
and linux-swap.
    https://github.com/google/googletest/blob/v1.8.x/googletest/docs/advanced.md#value-parameterized-tests

Running the test now looks like this:

    $ ./test_SupportedFileSystems
    Running main() from test_SupportedFileSystems.cc
    [==========] Running 20 tests from 1 test case.
    [----------] Global test environment set-up.
    [----------] 20 tests from My/SupportedFileSystemsTest
    [ RUN      ] My/SupportedFileSystemsTest.Create/0
    [       OK ] My/SupportedFileSystemsTest.Create/0 (97 ms)
    [ RUN      ] My/SupportedFileSystemsTest.Create/1
    [       OK ] My/SupportedFileSystemsTest.Create/1 (15 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUsage/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/0 (106 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUsage/1
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadUsage/1 (14 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadLabel/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadLabel/0 (95 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadLabel/1
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadLabel/1 (23 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUUID/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/0 (99 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUUID/1
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadUUID/1 (22 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteLabel/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndWriteLabel/0 (102 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteLabel/1
    [       OK ] My/SupportedFileSystemsTest.CreateAndWriteLabel/1 (22 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteUUID/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndWriteUUID/0 (101 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteUUID/1
    [       OK ] My/SupportedFileSystemsTest.CreateAndWriteUUID/1 (21 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndCheck/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndCheck/0 (153 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndCheck/1
    test_SupportedFileSystems.cc:424: Skip test.  check not supported or support not found
    [       OK ] My/SupportedFileSystemsTest.CreateAndCheck/1 (0 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndRemove/0
    test_SupportedFileSystems.cc:437: Skip test.  remove not supported or support not found
    [       OK ] My/SupportedFileSystemsTest.CreateAndRemove/0 (0 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndRemove/1
    test_SupportedFileSystems.cc:437: Skip test.  remove not supported or support not found
    [       OK ] My/SupportedFileSystemsTest.CreateAndRemove/1 (0 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndGrow/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndGrow/0 (266 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndGrow/1
    [       OK ] My/SupportedFileSystemsTest.CreateAndGrow/1 (32 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndShrink/0
    [       OK ] My/SupportedFileSystemsTest.CreateAndShrink/0 (111 ms)
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndShrink/1
    [       OK ] My/SupportedFileSystemsTest.CreateAndShrink/1 (28 ms)
    [----------] 20 tests from My/SupportedFileSystemsTest (1311 ms total)

    [----------] Global test environment tear-down
    [==========] 20 tests from 1 test case ran. (1342 ms total)
    [  PASSED  ] 20 tests.

Closes !49 - Add file system interface tests
2019-11-09 17:18:34 +00:00
Mike Fleetwood 8db9a83b39 Run test program under xvfb-run to satisfy need for an X11 display (!49)
Running test_ext2 in GitLab Continuous Integration environment fails like
this:
    (test_ext2:6338): Gtk-WARNING **: 09:06:17.576: cannot open display:
    Running main() from test_ext2.cc

Obviously the GitLab CI environment doesn't have an X11 display, but
unfortunately this test case code requires one.
Utils::execute_command() calls Gtk::Main::run() so requires a Gtk::Main
object constructing and therefore an X11 display, even though this
program never displays anything graphical.  The call chain is:
    main()                       test_ext2.cc
      Gtk::Main::Main()          gtkmm/gtk/src/main.ccg
        Gtk::Main::init()        [1]
          gtk_init()             gtk/gtk/gtkmain.c [2]
which exits with a non-zero exit status when the DISPLAY environment
variable is unset.

Looked at deriving from Gtk::Main class and writing a replacement init()
method which calls gtk_init_check() instead of gtk_init() but
Gtk::Main::instance_ is a private member so not accessible in a derived
class.

Tried using Glib::MainLoop instead of Gtk::Main, but that doesn't
initialise everything that Gtk::Main(), so the program crashes.

Therefore use xvfb-run [3][4] to run this test program against a virtual
X11 display when a real display isn't available.  Coded execution of
xvfb-run into this test program so that it can simply be executed on the
command line like the other test programs, without having to remember to
run "xvfb-run ./test_ext2 ...".

[1] Gtk::Main::init()
    https://gitlab.gnome.org/GNOME/gtkmm/blob/3.10.1/gtk/src/main.ccg#L287
[2] gtk_init()
    https://gitlab.gnome.org/GNOME/gtk/blob/3.10.9/gtk/gtkmain.c#L1000
[3] how to run gtk app on linux without an x server
    https://superuser.com/questions/624918/how-to-run-gtk-app-on-linux-without-an-x-server
[4] Using GTK without DISPLAY
    https://stackoverflow.com/questions/11694278/using-gtk-without-display

Closes !49 - Add file system interface tests
2019-11-09 17:18:34 +00:00
Mike Fleetwood a97c23c57c Add initial create ext2 only FileSystem interface class test (!49)
This is the first step of adding testing of the derived FileSystem
interface classes which call the file system specific executables.
Rather than mocking command execution and returned output the tests run
the real commands, effectively making this integration testing.

Test case setup determines the file system supported actions using
get_filesystem_support() and individual tests are skipped if a feature
is not supported, just as GParted does for it's actions.

Each test creates it's own sparse image file and a fresh file system,
performs a test on one FileSystem interface call and deletes the image
file.  This makes each test independent and allows them to run as a
non-root user, provided the file system command itself doesn't require
root.  Errors reported for a failed interface call will include the
GParted OperationDetails, which in turn includes the file system
specific command used and stdout and stderr from it's execution.

For example, temporarily breaking the test code to create a 10 KiB image
file instead of 256 MiB one produces this:

    $ ./test_ext2
    Running main() from test_ext2.cc
    [==========] Running 1 test from 1 test case.
    [----------] Global test environment set-up.
    [----------] 1 test from ext2Test
    [ RUN      ] ext2Test.Create
    test_ext2.cc:199: Failure
    Value of: s_ext2_obj->create(m_partition, m_operation_detail)
      Actual: false
    Expected: true
    Operation details:
    <b><i>mkfs.ext2 -F -L &apos;&apos; &apos;/home/centos/programming/c/gparted/tests/test_ext2.img&apos;</i></b>    00:00:00  (ERROR)
    <i></i>
    <i>mke2fs 1.42.9 (28-Dec-2013)
    /home/centos/programming/c/gparted/tests/test_ext2.img: Not enough space to build proposed filesystem while setting up superblock
    </i>

    [  FAILED  ] ext2Test.Create (25 ms)
    [----------] 1 test from ext2Test (25 ms total)

    [----------] Global test environment tear-down
    [==========] 1 test from 1 test case ran. (30 ms total)
    [  PASSED  ] 0 tests.
    [  FAILED  ] 1 test, listed below:
    [  FAILED  ] ext2Test.Create

     1 FAILED TEST
    $ echo $?
    1

Also as Utils:: and FileSystem::execute_command() are needed, this
requires linking with GParted_Core for GParted_Core::mainthread and
therefore with most of the non-UI classes in gpartedbin.

Closes !49 - Add file system interface tests
2019-11-09 17:18:34 +00:00
Mike Fleetwood 3140b76a80 Print OS details in the GitLab CI (!48)
Just a simple debugging aid to have the OS details printed in the GitLab
CI output.

Closes !48 - Remain with CentOS 7 for GitLab CI
2019-10-03 15:36:06 +00:00
Mike Fleetwood 22984637b0 Remain with CentOS 7 for GitLab CI (!48)
When GParted GitLab Continuous Integration was setup, CentOS 7 image was
used for a slow moving distribution and Ubuntu as a different, faster
moving distribution.

CentOS 8 has recently been released [1].  To avoid automatically
switching to it when an official CentOS 8 docker image is made available
[2], explicitly specify the CentOS 7 image.

[1] Release for CentOS Linux 8 and CentOS Streams (2019-09-24)
    https://lists.centos.org/pipermail/centos-announce/2019-September/023449.html

[2] Docker Official Images, The official build of CentOS
    https://hub.docker.com/_/centos/

Closes !48 - Remain with CentOS 7 for GitLab CI
2019-10-03 15:36:06 +00:00
Mike Fleetwood 83777932c6 Drop now unnecessary editing of xmllint command line in CI tests (!24)
GNOME 3's yelp doesn't use scrollkeeper or the OMF catalog, so the
constructed Makefile doesn't use xmllint to validate the scrollkeeper
DTD file.  Therefore remove attempted sed edit of that line which no
longer exists in the Makefile.

Note that help/Makefile.am's @YELP_HELP_RULES@ automake macro expansion
comes from /usr/share/aclocal/yelp.m4 [1].

Commit which previously needed to add the sed edit:
    cbb25a2511
    Stop xmllint scrollkeeper-omf.dtd fetch failure breaking CI tests (#9)

[1] Yelp > Yelp Tools > yelp.m4
    http://yelp.io/tools/yelp.m4.html

Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure
2019-03-01 16:46:56 +00:00
Mike Fleetwood a725921a22 Add use of new GNOME 3 yelp-tools documentation infrastructure (!24)
Second part is to use yelp-tools to build and install the documentation.
Have to rename the help Manual from help/C/gparted.xml to
help/C/index.docbook in accordance with this note from the GNOME Goal:
Port to New Documentation Infrastructure [1]:
    IMPORTANT: If this is for a DocBook document, the top-level DocBook
    file MUST be renamed to index.docbook.  Do a "git mv" and include
    index.docbook in HELP_FILES.

Commits from gucharmap [4] and totem [5], projects which have DocBook
documentation, making this same change are also useful references.

[1] GNOME Goal: Port To New Documentation Infrastructure
    https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure

[2] Yelp > Yelp Tools > yelp.m4
    http://yelp.io/tools/yelp.m4.html

[3] GNOME application developement overview / User help / Set up your
    build system
    https://developer.gnome.org/platform-overview/stable/dev-help-build.html.en

[4] gucharmap commit "Port to new documentation infrastructure"
    3e1526c056

[5] totem commit "Use new documentation infrastructure"
    59a6bd6064

Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure
2019-03-01 16:46:56 +00:00
Mike Fleetwood e62b352eed Remove use of GNOME 2 gnome-doc-utils documentation infrastructure (!24)
Details of old GNOME 2 gnome-doc-utils:
    Migrating your documentation to gnome-doc-utils
    https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo

First part is to stop using gnome-doc-utils to build and install the
documentation.  Also since updating the OMF catalog was only needed for
GNOME 2 yelp, use of scrollkeeper is completely removed too.

Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure
2019-03-01 16:46:56 +00:00
Luca Bacci cc0740148e port-to-gtk3: Switch to Gtkmm3 (#7)
Switch to Gtkmm3 in configure.ac.  Require version 3.0.0.

Also update the build instructions in README and the package list in
.gitlab-ci.yml.

Starting from version 3.18.0 Gtkmm requires C++11 compilation [1][2][3].
Add a check for Gtkmm >= 3.18.0 in configure.ac and enable C++11
compilation accordingly.

References:

[1] Gtkmm 3.18.1 NEWS
    "Changes in 3.18 ... Use, and require C++11, ..."
    https://gitlab.gnome.org/GNOME/gtkmm/blob/3.18.1/NEWS#L35

[2] Murray's Blog - "gtkmm now uses C++11"
    https://www.murrayc.com/permalink/2015/07/31/gtkmm-now-uses-c11

[3] Murray's Blog - "gtkmm 3.18 and glibmm 2.46"
    https://www.murrayc.com/permalink/2015/09/25/gtkmm-3-18-and-glibmm-2-46

Closes #7 - Port to Gtk3
2019-02-11 08:57:18 +00:00
Mike Fleetwood cbb25a2511 Stop xmllint scrollkeeper-omf.dtd fetch failure breaking CI tests (#9)
The GitLab Continuous Integration test stage jobs can fail like this:

    $ make check
    ...
    Making check in help
    make[1]: Entering directory `/builds/mfleetwo/gparted/help'
    ...
    xmllint --noout --xinclude --dtdvalid 'http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd' gparted-C.omf
    warning: failed to load external entity "http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd"
    Could not parse DTD http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd
    xmllint --noout --xinclude --dtdvalid 'http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd' gparted-cs.omf
    ...
    make[1]: *** [check-doc-omf] Error 2
    make[1]: Leaving directory `/builds/mfleetwo/gparted/help'
    make: *** [check-recursive] Error 1
    ERROR: Job failed: exit code 1

It fails when the scrollkeeper.sourceforge.net site reports that
SourceForge is undergoing maintenance or is temporarily unavailable.  I
have seen this occur on 3 separate occasions in the last 4 weeks since I
started experimenting with GitLab CI, which is rather too often.

Xmllint comes from the GNOME 2 gnome-doc-utils.make rules used to build
and validate GNOME 2 documentation.

Fragment of useful Debian bug report 730688:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730688
    --disable-scrollkeeper requieres scrollkeeper installed

    "You can reproduce the problem in mdbtoools version 0.7.1-1 with no
    network, and rarian-compat not installed.

    When the network is available, buildd downloads the DTD for checks.
    When there is no network, gnome-doc-utils fails.
    "

Fix by:
(1) adding the rarian-compat package to the CI Docker images, which
    provides a local copy of the scrollkeeper-omf.dtd file;
(2) adding the xmllint --nonet option to prevent fetching of DTDs
    remotely.

With reference to earlier commit:
    0eb9f1fcfb
    Reduce dependency on scrollkeeper (#743318)
That commit allowed GParted to be installed on GNOME 3 desktops without
requiring rarian-compat package to be installed.  This commit adds
rarian-compat to the CI images so that 'make check' can succeed without
accessing the Internet.  Just the intricate path to continue to build
and test a GNOME 2 application in a world of GNOME 3 desktops with
beginning to be reduced backward compatibility.

Closes #9 - CI test jobs occasionally fail with xmllint not loading
            external entity http://scrollkeeper.sourceforce.net/dtds/
            scrollkeeper-omf-1.0/scrollkeeper-omf.dtd
2018-07-24 22:32:36 +01:00
Mike Fleetwood 112f1d3e67 Stop parallelising make distcheck in GitLab CI test jobs (!6)
Unfortunately parallelising 'make distcheck' causes it to fail like
this:

    $ nproc=`grep -c '^processor' /proc/cpuinfo` || nproc=1
    $ echo nproc=$nproc
    nproc=8
    ...
    $ make -j $nproc distcheck
    ...
    make[1]: Entering directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub'
    ERROR: files left after uninstall:
    ./share/icons/hicolor/icon-theme.cache
    Makefile:896: recipe for target 'distuninstallcheck' failed
    make[1]: Leaving directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub'
    make[1]: *** [distuninstallcheck] Error 1
    make: *** [distcheck] Error 1
    Makefile:840: recipe for target 'distcheck' failed
    ERROR: Job failed: exit code 1

Therefore go back to serial 'make distcheck'.

Closes !6 - Reduce the time taken by the GitLab CI jobs
2018-07-23 18:21:35 +00:00
Mike Fleetwood ed06299c18 Parallelise building GParted in GitLab CI jobs (!6)
Reduce the time taken by the GitLab Continuous Integration jobs by
parallelising make to use all available CPUs in the Docker CI image
when it is building GParted code.  This includes 'make diskcheck'
because that also does a second build of the GParted code in a separate
subdirectory.

Closes !6 - Reduce the time taken by the GitLab CI jobs
2018-07-23 18:21:34 +00:00
Mike Fleetwood 8cd2181b49 Add CI job to test GParted on Ubuntu (!4)
Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-08 09:45:11 +01:00
Mike Fleetwood 391aebae93 Add CI job to build GParted on Ubuntu (!4)
Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-08 09:45:11 +01:00
Mike Fleetwood eb2435231b Parameterise CI config ready for also using a Ubuntu image (!4)
Prepare the GitLab Continuous Integration configuration for also
building and testing GParted on a Ubuntu image.  The definition of the
image and before_script, which so far specify the CentOS Docker image
and how to install the required RPM packages, need to move from being
top level nodes to being defined per job.  Namely within jobs
'centos_build' and 'centos_test'.

To avoid duplicating various nodes within multiple jobs, YAML anchors
(&LABEL) and references (*LABEL) are used.  They are defined in ignored
jobs, job names starting with a dot (.).

Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-08 09:44:57 +01:00
Mike Fleetwood a6b0a26c74 Rename CI jobs to reflect that they use a CentOS Docker image (!4)
Ready for adding additional Continuous Integration jobs using different
distribution Docker images.  Rename thus:
    build -> centos_build
    test  -> centos_test

Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-05 07:21:06 +01:00
Mike Fleetwood fe2fc33e67 Exclude unit test which fails in Docker CI image (!4)
Fragment of the tests/test-suite.log from the Docker CI image showing
details of the unit test failure:

    Running main() from gtest_main.cc
    [==========] Running 26 tests from 1 test case.
    [----------] Global test environment set-up.
    [----------] 26 tests from BlockSpecialTest
    ...
    [ RUN      ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches
    test_BlockSpecial.cc:137: Failure
    Failed
    get_link_name(): Failed to open directory '/dev/disk/by-id'
    test_BlockSpecial.cc:168: Failure
    Failed
    follow_link_name(): Failed to resolve symbolic link ''
    test_BlockSpecial.cc:255: Failure
    Expected: (lnk.m_name.c_str()) != (bs.m_name.c_str()), actual: "" vs ""
    [  FAILED  ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms)
    ...
    [==========] 26 tests from 1 test case ran. (1 ms total)
    [  PASSED  ] 25 tests.
    [  FAILED  ] 1 test, listed below:
    [  FAILED  ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches

     1 FAILED TEST

So the code is trying to find a symbolic link to a block device to use
in the test.  It is trying to read the directory /dev/disk/by-id to find
a symbolic link, but the directory doesn't exist in the Docker CI image.

The used directory was recently changed [1] to use one which existed on
all distributions.  Docker images don't even have the /dev/disk
directory.  Exclude just this specific test.

[1] 7fe4148074
    Use /dev/disk/by-id/ to get device symlink in test_BlockSpecial

Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-05 07:21:06 +01:00
Mike Fleetwood f5e161f698 Debug unit test failure in CI test job (!4)
Recursively list all the files below /dev as part of the 'test' job as
certain block device names are needed by the failing test_BlockSpecial
unit test.

The artifact captures all the files from the directory in which the CI
script runs to build and test GParted.  It creates a ZIP file which can
be downloaded after the job finishes, whether the job succeeds of fails.
This is to capture logs from the failure of the test_BlockSpecial unit
test.

Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-05 07:21:06 +01:00
Mike Fleetwood e76a3874af Add CI testing job on CentOS (!4)
Add GitLab Continuous Integration job named 'test' which runs the
GParted unit tests and distcheck.  Note that the job starts from a fresh
official CentOS Docker image so also has to rebuild GParted too.

So far this job fails on unit test test_BlockSpecial.  Fragment of the
CI job log:

    make  check-TESTS
    make[2]: Entering directory `/builds/mfleetwo/gparted/tests'
    make[3]: Entering directory `/builds/mfleetwo/gparted/tests'
    PASS: test_dummy
    FAIL: test_BlockSpecial
    PASS: test_PasswordRAMStore
    PASS: test_PipeCapture
    make[4]: Entering directory `/builds/mfleetwo/gparted/tests'
    make[4]: Nothing to be done for `all'.
    make[4]: Leaving directory `/builds/mfleetwo/gparted/tests'
    ============================================================================
    Testsuite summary for gparted 0.31.0-git
    ============================================================================
    # TOTAL: 4
    # PASS:  3
    # SKIP:  0
    # XFAIL: 0
    # FAIL:  1
    # XPASS: 0
    # ERROR: 0
    ============================================================================
    See tests/test-suite.log
    Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted
    ============================================================================

Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-05 07:21:05 +01:00
Mike Fleetwood 8fc4488fc2 Create initial GitLab CI job which builds on CentOS (!4)
Initial GitLab Continuous Integration configuration with a single job
named 'build' which just confirms GParted can be built and installed on
the latest official CentOS Docker image.

Closes !4 - Add GitLab CI jobs to build and test GParted
2018-07-05 07:20:59 +01:00