Commit Graph

4076 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 ddd32e838c Migrate build from intltool to gettext translation (!107)
[0] GNOME Goal: Gettext Migration
    https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration

This goal from 2016 is to migrate away from using intltool to help
translate especially GNOME application related files, and instead use
gettext directly now that gettext can handle a lot more file formats
[1][2][3].

The GNOME Goal: Gettext Migration [0] says:
    "With gettext 0.19.8, there is really no need anymore to use
    intltool or GLib's dated gettext glue (AM_GLIB_GNU_GETTEXT and
    glib-gettextize)."

This version or later of gettext is available in the oldest supported
distributions except for SLES 12:
    Distribution       EOL        gettext -V
    Debian 10          2022-Aug   0.19.8.1
    RHEL / CentOS 7    2024-Jun   0.19.8.1
    Ubuntu 18.04 LTS   2023-Apr   0.19.8.1
    SLES 12 SP5        2024-Oct   0.19.2 [4][5]
As SLES 12 SP5 doesn't contain GParted and SLES 15 contains GParted
0.31.0 [6] loosing the ability to compile future GParted 1.5 release on
SLES 12 SP5 is acceptable.

Additionally the use of intltool and the associated GLib provided macro
AM_GLIB_GNU_GETTEXT was the source of the remaining warnings from
autoconf 2.71 seen in Fedora 36 and Ubuntu 22.04 LTS about the use of
obsolete macros:
    $ ./autogen.sh
    ...
    autoreconf: running: /usr/bin/autoconf --force
    configure.ac:59: warning: The macro `GLIB_GNU_GETTEXT' is obsolete.
    configure.ac:59: You should run autoupdate.
    aclocal.m4:426: GLIB_GNU_GETTEXT is expanded from...
>>  aclocal.m4:526: AM_GLIB_GNU_GETTEXT is expanded from...
>>  configure.ac:59: the top level
    configure.ac:59: warning: The macro `AC_TRY_LINK' is obsolete.
    configure.ac:59: You should run autoupdate.
    ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
    lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
    lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
    ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
    ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
    aclocal.m4:111: GLIB_LC_MESSAGES is expanded from...
    aclocal.m4:426: GLIB_GNU_GETTEXT is expanded from...
>>  aclocal.m4:526: AM_GLIB_GNU_GETTEXT is expanded from...
>>  configure.ac:59: the top level
    configure.ac:59: warning: The macro `AC_TRY_LINK' is obsolete.
    configure.ac:59: You should run autoupdate.
    ...

Note that use of AM_GLIB_GNU_GETTEXT was deprecated in GLib 2.47.5
released 2016-01-18 [7].  Newer versions of GLib are included in the
oldest supported distributions:

    Distro             Package containing   Version
                       glib-gettext.m4
    Debian 10          libglib2.0-dev-bin   2.58.3
    RHEL / CentOS 7    glib2-devel          2.56.1
    Ubuntu 18.04 LTS   libglib2.0-dev-bin   2.56.4
    SLES 12 SP5        glib2-devel          2.48.2

Therefore perform the migration described in the GNOME wiki documents
[0][1].  This involves:
1. Replacing the macros used in configure.ac;
2. Copying Makevars.template to po/Makevars and setting
   PO_DEPENDS_ON_POT and DIST_DEPENDS_ON_UPDATE_PO to "no";
3. Replace @INTLTOOL_*@ macros in Makefile.am with rules to use gettext
   to directly translate the relevent GNOME application files;
4. Removing (_) underscore marking translation prefixes from XML tags in
   GNOME application files as gettext understands which tags of which
   files need translating.
For reference are these commits in projects GNOME-System-Monitor [8],
Reversi [9] and Evince [10] making the same transition.

At this point "./autogen.sh && make" succeeds, at least on Ubuntu which
provides the instructions gettext needs to correctly translate .policy
files by default.  These:
    /usr/share/gettext/its/polkit.its
    /usr/share/gettext/its/polkit.loc
are included in the base policykit-1 package.

[1]  Migrating from Intltool to Gettext
     https://wiki.gnome.org/MigratingFromIntltoolToGettext
[2]  Using Modern Gettext
     https://blogs.gnome.org/mclasen/2016/07/21/using-modern-gettext/
[3]  On the killing of intltool
     https://blogs.gnome.org/mcatanzaro/2016/07/27/on-the-killing-of-intltool/
[4]  SUSE package search, SLES 12 SP5, gettext
     https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=12.5&arch=x86_64&query=gettext&module=
[5]  SUSE Long Term Service Pack Support
     https://links.imagerelay.com/cdn/3404/ql/f3a083e9bcd34c76addd096d7f60ec00/long_term_service_pack_support_flyer.pdf
[6]  SUSE package search, SLES 15, gparted
     https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=15&arch=x86_64&query=gparted&module=
[7]  Deprecate GLIB_GNU_GETTEXT macro, use upstream gettext instead
     6b577196ee
[8]  [GNOME-System-Monitor] Migrate from intltool
     9185b9c713
[9]  [Reversi] Gettext migration (bgo#793040)
     d22f560ac8
[10] [Evince] build: Migrate from Intltool to Gettext
     4fd6821324

Closes !107 - Migrate from intltool to gettext translation
2022-11-12 16:44:55 +00:00
Dušan Kazik 07382609b5 Update Slovak translation 2022-10-09 19:01:37 +00:00
Matej Urbančič b367bf912e Update Slovenian translation 2022-09-22 20:45:39 +00:00
Alan Mortensen 5429b13e91 Update Danish translation 2022-09-20 17:12:00 +00:00
Irénée THIRION bcbf2c09b7 Update French translation 2022-09-17 08:20:07 +00:00
Kukuh Syafaat 87cdafdaf8 Update Indonesian translation 2022-09-14 08:50:19 +00:00
Luna Jernberg 0819e7d0ec Update Swedish translation 2022-09-13 17:58:57 +00:00
Mike Fleetwood 5e2927f1ef Update AC_PROG_LIBTOOL to LT_INIT in configure.ac (!106)
Autoconf 2.71 on Fedora 36 and Ubuntu 22.04 LTS has started reporting
a number of warnings about configure.ac containing obsolete macros.  One
of them is this:
    $ ./autogen.sh
    ...
    Processing ./configure.ac
    configure.ac:17: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
    configure.ac:17: You should run autoupdate.
    m4/libtool.m4:99: AC_PROG_LIBTOOL is expanded from...
    configure.ac:17: the top level
    ...

AC_PROG_LIBTOOL is deprecated and the replacement is LT_INIT [1].
LT_INIT is available in all supported distributions, for example RHEL /
CentOS 7 has libtool 2.4.2 with LT_INIT defined in
/usr/share/aclocal/libtool.m4 serial 57.  The last known distribution
without LT_INIT was RHEL / CentOS 5 [2].

Update accordingly.

[1] Libtool Manual, 5.4.1 The LT_INIT macro
    https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html
    "Macro: LT_INIT(options)
    ...  AC_PROG_LIBTOOL and AM_PROG_LIBTOOL are deprecated names for
    older versions of this macro; autoupdate will upgrade your
    configure.ac files."
[2] 654cdc7335
    Update AM_PROG_LIBTOOL to AC_PROG_LIBTOOL in configure.ac (#734718)

Closes !106 - Update AC_PROG_LIBTOOL to LT_INIT in configure.ac
2022-09-13 16:01:25 +00:00
Yosef Or Boczko 7f956fb081 Update Hebrew translation 2022-09-11 04:48:31 +00:00
Muhammet Kara cf2abe2bb3 Update Turkish translation 2022-09-08 04:50:47 +00:00
Sabri Ünal 4d0026f4ba Update Turkish translation 2022-09-03 05:33:49 +00:00
Balázs Úr da5c188c4a Update Hungarian translation 2022-08-29 23:17:14 +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 13c08808ae Use btrfs inspect-internal dump-super to read usage (!105)
GParted has been using 'btrfs filesystem show' to report file system
usage but that doesn't work on a file system image so doesn't work in a
GitLab CI test job, as discussed earlier in this patchset.

There is 'btrfs inspect-internal min-dev-size' but:
1. That only works on a mounted file system and GParted isn't going to
   mount an unmounted file system just to query it's used space, so by
   extension won't work on image files.
2. It reports a figure which is almost the same as the chunk usage of
   the device within the btrfs file system.  However if some files have
   been deleted leaving chunks partially used, then 'btrfs filesystem
   resize' will successfully shrink a btrfs smaller than the reported
   minimum device size.

And there is also 'btrfs filesystem usage' but that also only works on a
mounted file system.

So instead use 'btrfs inspect-internal dump-super' to report some of the
figures previously obtained from 'btrfs filesystem show'.  For example
for a single device btrfs in an image file:
    $ truncate -s 256M /tmp/test.img
    $ mkfs.btrfs /tmp/test.img
    $ btrfs inspect-internal dump-super /tmp/test.img | egrep 'total_bytes|bytes_used|sectorsize|devid'
    total_bytes             268435456
    bytes_used              114688
    sectorsize              4096
    dev_item.total_bytes    268435456
    dev_item.bytes_used     92274688
    dev_item.devid          1

Comparing with results from 'btrfs filesystem show' for the same file
system, after adding a loop device to allow 'btrfs filesystem show' to
succeed:
    $ su -
    # losetup --find --show /tmp/test.img
    # btrfs filesystem show --raw /dev/loop0
    Label: none  uuid: 32a1eb31-4691-41ae-9ede-c45d723655a3
            Total devices 1 FS bytes used 114688
            devid    1 size 268435456 used 92274688 path /dev/loop0

This does bring a forced change in the calculation which affects multi-
device btrfs file systems.  'btrfs filesystem show' provided chunk
allocation information per device ("used" figure for each "devid").  The
file system wide used bytes ("FS bytes used") was apportioned according
to the fraction of the chunk allocation each device contained.  However
'btrfs inspect-internal dump-super' doesn't provide chunk allocation
information for all devices, only for the current device
("dev_item.bytes_used").  Instead the calculation now has to apportion
the file system wide used bytes ("bytes_used") according to the fraction
of the size of the current device ("dev_item.total_bytes") within the
total size ("total_bytes").

This can't make any difference to a single device btrfs file system as
both fractions will be 1.  It only affects how the file system wide used
bytes is distributed among multiple devices.

As an example to see the difference between calculation methods, create
a 2 GiB btrfs taking the defaults so getting duplicated metadata and
single data.  Add another 2 GiB partition and populate with some files.
    # mkfs.btrfs /dev/sdb1
    btrfs-progs v4.15.1
    See http://btrfs.wiki.kernel.org for more information.

    Label:              (null)
    UUID:               68195e7e-c13f-4095-945f-675af4b1a451
    Node size:          16384
    Sector size:        4096
    Filesystem size:    2.00GiB
    Block group profiles:
      Data:             single            8.00MiB
      Metadata:         DUP             102.38MiB
      System:           DUP               8.00MiB
    SSD detected:       no
    Incompat features:  extref, skinny-metadata
    Number of devices:  1
    Devices:
       ID        SIZE  PATH
        1     2.00GiB  /dev/sdb1

    # mount /dev/sdb1 /mnt/1
    # btrfs device add /dev/sdc1 /mnt/1
    # cp -a /home/$USER/programming/c/gparted/ /mnt/1/

Usage figures using the old calculation apportioning file system wide
usage according to chunk allocation per device:
    # btrfs filesystem show --raw /dev/sdb1
    Label: none  uuid: 68195e7e-c13f-4095-945f-675af4b1a451
            Total devices 2 FS bytes used 178749440
            devid    1 size 2147483648 used 239861760 path /dev/sdb1
            devid    2 size 2147483648 used 436207616 path /dev/sdc1

    sum_devid_used = 239861760 + 436207616
                   = 676069376

    sdb1 usage = 178749440 * 239861760 / 676069376
               = 63418277
    sdc1 usage = 178749440 * 436207616 / 676069376
               = 115331163

Usage figures using the new calculation apportioning file system wide
usage according to device sizes:
    # btrfs inspect-internal dump-super /dev/sdb1 | egrep 'total_bytes|^bytes_used'
    total_bytes             4294967296
    bytes_used              178749440
    dev_item.total_bytes    2147483648
    # btrfs inspect-internal dump-super /dev/sdc1 | egrep 'total_bytes|^bytes_used'
    total_bytes             4294967296
    bytes_used              178749440
    dev_item.total_bytes    2147483648

    sdb1 usage = 178749440 * 2147483648 / 4294967296
               = 89374720
    sdc1 usage = 178749440 * 2147483648 / 4294967296
               = 89374720

Both calculation methods ignore that btrfs allocates chunks at the
volume manager level.  So when fully compacted the last chunk for
metadata and data for each storage profile (RAID level) will be
partially filled and this is not accounted for.

Also for multi-device btrfs file systems the new calculation provides
different results.  However given that shrinking a device in a multi-
device btrfs file system can and does relocate extents to other devices
(redundancy requirements of chunks permitting) it's minimum size is
virtually impossible to calculate and may not restrict how small the
btrfs device can be shrunk anyway.  If it turns out that this new
calculation causes problems it's been made a separate commit from the
previous commit for easier reverting.

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 db5df60f22 Use btrfs filesystem show --raw to read usage (!105)
'btrfs filesystem show' only used to report rounded human readable size
figures.  Therefore the actual figure could have been anywhere within
the rounding limit.  GParted also applied a heuristic to snap the file
system size figure to the partition size if the partition size was
within the rounding limit of the reported file system size [1].

btrfs-progs v4.1 added the --raw option to print the figures in bytes
[2][3][4].
    # btrfs filesystem show --raw /dev/sdb1
    Label: none  uuid: 003a619e-856f-4b9c-bd29-4d0ae0296d66
            Total devices 2 FS bytes used 178765824
            devid    1 size 2147483648 used 239861760 path /dev/sdb1
            devid    2 size 2147483648 used 436207616 path /dev/sdc1

Since the oldest supported distributions now use btrfs-progs v4.5.3 and
later (see the distribution End-of-Life table in the previous commit
message), unconditionally use this to get accurate figures.

[1] 7fc16a1b69
    Handle btrfs tools rounding of figures (#499202)
[2] btrfs-progs: Allow "filesystem show" command to handle different units
    https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=15379fa2257bf937cf7830c0b1b79f2daf5df72c
[3] btrfs-progs: docs: new size options for fi show
    https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=81225f11d9ea58590476612e69211113ddb9b943
[4] Btrfs progs release 4.1
    https://lore.kernel.org/linux-btrfs/20150622150023.GX6761@twin.jikos.cz/

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 be895fb98e Use btrfs inspect-internal dump-super to read UUID (!105)
GParted so far uses 'btrfs filesystem show' to read the file system
UUID.  But this doesn't work on a file system image so doesn't work in
the GitLab CI test jobs, as discussed in the earlier commit "Use btrfs
filesystem label to read the FS label (!105)".
    $ truncate -s 256M /tmp/test.img
    $ mkfs.btrfs /tmp/test.img
    ...
    UUID:               5ea62f88-fef3-4ece-a726-b88f3d81fe1c
    ...
    $ btrfs filesystem show /tmp/test.img
    ERROR: not a valid btrfs filesystem: /tmp/test.img

Instead use 'btrfs inspect-internal dump-super' which works on image
files too.
    $ btrfs inspect-internal dump-super /tmp/test.img
    ...
    fsid                    5ea62f88-fef3-4ece-a726-b88f3d81fe1c
    ...

'btrfs inspect-internal dump-super' was added in btrfs-progs 4.5 [1][2]
so is available in the oldest supported distributions and can be used
unconditionally.
    Distro            EOL        btrfs --version
    Debian 10         2022-Jun   v4.20
    RHEL / CentOS 7   2024-Jun   v4.9.1
    Ubuntu 18.04 LTS  2023-Apr   v4.15.1
    SLES 12 SP5       2024-Oct   v4.5.3    [3][4]

Unfortunately it returns 0 status on failure so use non-empty stderr to
identify failure.
    $ rm /tmp/test.img
    $ truncate -s 256M /tmp/test.img
    $ btrfs inspect-internal dump-super /tmp/test.img 1> /dev/null
    ERROR: bad magic on superblock on /tmp/test.img at 65536
    $ echo $?
    0

[1] btrfs-progs: introduce inspect-internal dump-super
    https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=eaa93e3b0295fc94c774ec73056559a6b8c78b42
[2] Btrfs progs release 4.5
    https://lore.kernel.org/linux-btrfs/20160320235330.GG21722@suse.cz/
    "* new/moved commands
       * btrfs-show-super -> btrfs inspect-internal dump-super
    "
[3] SUSE Long Term Service Pack Support
    https://links.imagerelay.com/cdn/3404/ql/f3a083e9bcd34c76addd096d7f60ec00/long_term_service_pack_support_flyer.pdf
[4] SUSE package search
    https://scc.suse.com/packages?name=SUSE%20Linux%20Enterprise%20Server&version=12.5&arch=x86_64&query=btrfsprogs&module=

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 1fbc8988ff Extract repeated code into trim_trailing_new_line() (!105)
Create function to replace repeated code which optionally removes
trailing new line character from a string.

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 ee823b0be4 Use btrfs filesystem label to read the FS label (!105)
Until now GParted has run 'btrfs filesystem show' to read the file
system label.  This has a number of issues and limitations:
1.  Doesn't work on a file system image so can't be unit tested in the
    GitLab CI test job where a loop device can't be created [1] or as a
    non-root user.
2.  Reported failed exit status 1 when successfully showing a mounted
    btrfs, but only when using btrfs-progs v3.14 and 3.14.1 [2][3].
3.  Failed to distinguish between label set to "none" and no label
    reported as none, but only when mounted and with btrfs-progs v3.12
    [3].

As non-root user run btrfs read label unit test:
    $ tests/test_SupportedFileSystems --gtest_filter='*CreateAndReadLabel/btrfs'
    ...
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs
    test_SupportedFileSystem.cc:539: Skip test.  Not root to be able to create required loop device
    [       OK ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs (0 ms)

Even as root, 'btrfs filesystem show' fails to work on an image file:
    # truncate -s 256M /tmp/test.img
    # mkfs.btrfs /tmp/test.img
    # btrfs filesystem show /tmp/test.img
    ERROR: not a valid btrfs filesystem: /tmp/test.img
    # echo $?
    1
    # rm /tmp/test.img

Instead use 'btrfs filesystem label' to read the label.  It also works
on an image file, the exit status is informative and output is just the
label followed by a new line character [4] so very simple to parse.

Error case:
    $ truncate -s 256M /tmp/test.img
    $ btrfs filesystem label /tmp/test.img
    No valid Btrfs found on /tmp/test.img
    $ echo $?
    255

No label case:
    $ mkfs.btrfs /tmp/test.img
    $ btrfs filesystem label /tmp/test.img

    $ echo $?
    0
    $ btrfs filesystem label /tmp/test.img | hexdump -C
    00000000  0a                                                |.|
    00000001

Label case:
    $ mkfs.btrfs -L 'label with
    > new line and trailing space ' /tmp/test.img
    $ btrfs filesystem label /tmp/test.img
    label with
    new line and trailing space
    $ echo $?
    0
    $ btrfs filesystem label /tmp/test.img | hexdump -C
    00000000  6c 61 62 65 6c 20 77 69  74 68 0a 6e 65 77 20 6c  |label with.new l|
    00000010  69 6e 65 20 61 6e 64 20  74 72 61 69 6c 69 6e 67  |ine and trailing|
    00000020  20 73 70 61 63 65 20 0a                           | space .|
    00000028

Run 'btrfs filesystem label' always passing the block device as this
works for both mounted and unmounted file systems.  This is in
contrast to writing the label for a mounted btrfs where the mount
mount must be used [5].
    # mkfs.btrfs -L 'test label' /dev/sdb1
    # btrfs filesystem label /dev/sdb1
    test label
    # mount /dev/sdb1 /mnt/1
    # btrfs filesystem label /dev/sdb1
    test label

[1] 07ad43a107
    Create loop devices for BTRFS read file system interface tests (!49)
[2] 82c6265fa5
    Update parsing of btrfs filesystem show for the UUID (#733601)
[3] eca732fb0c
    Update parsing of btrfs filesystem show for the label (#733601)
[4] btrfs-progs v3.14, cmd_label() function
    https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/tree/cmds-filesystem.c?h=v3.14#n984
[5] eb034b1759
    Add labelling of mounted btrfs (#163)

Closes !105 - Update used btrfs file system commands, new minimum is
              btrfs-progs 4.5
2022-08-25 15:41:31 +00:00
Goran Vidović f30317477a Update Croatian translation 2022-08-13 16:29:09 +00:00
Mike Fleetwood bf5c6bb618 Fix typo in comment in xfs::write_label() 2022-07-04 17:50:25 +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 a46c0cbe80 Add clearing FS label to CreateAndWriteLabel unit test
For FAT16/32 and XFS file systems clearing the label uses different
command options and code path in file system specific ::write_label()
method.  Therefore extend this unit test to also test clearing the
label.
2022-07-04 17:50:25 +00:00
Mike Fleetwood b7ef1688b8 Stop clearing FAT16/32 label when setting a new UUID (!104)
Now fix the error with GParted clearing the label when setting a new
UUID on a FAT16/32 file system.  Reproduce the issue on the command
line:
    # mkfs.fat -F 16 -v -I -n TEST_LABEL /dev/sdb1
    # mdir -f -i /dev/sdb1 ::/
     Volume in drive : is TEST_LABEL
     Volume Serial Number is 5D4C-6E6E
    ...
    # mlabel -n -i /dev/sdb1 ::
    # mdir -f -i /dev/sdb1 ::/
     Volume in drive : has no label
     Volume Serial Number is 77BB-A883
    ...

This was broken by commit "Fix writing FAT16/32 FS UUID on Alpine Linux
(!104)" earlier in this patchset, which included this comment:
    "...  Also drop the '-s' option
    as showing the current label is unrelated to writing a new UUID."

It is not mentioned in the mlabel[1] manual page that option -s is
needed in order to avoid clearing the label when assigning a new UUID.
Anyway add the option back.

[1] mlabel(1)
    https://linux.die.net/man/1/mlabel
    "s     Shows the existing label, without prompting the user.
    n      Assigns a new (random) serial number to the disk
    "

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 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 7368f55a2f Fix writing FAT16/32 FS UUID on Alpine Linux (!104)
Unit test writing FAT16/32 file system UUIDs fails on Alpine Linux like
this:
    $ ./test_SupportedFileSystems --gtest_filter='*CreateAndWriteUUID/fat16'
    ...
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteUUID/fat16
    test_SupportedFileSystems.cc:616: Failure
    Value of: m_fs_object->write_uuid(m_partition, m_operation_detail)
      Actual: false
    Expected: true
    Operation details:
    mkfs.fat -F16 -v -I '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img'    00:00:00  (SUCCESS)
    ...
    mlabel -s -n :: -i '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img'    00:00:00  (ERROR)

    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:

    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndWriteUUID/fat16, where GetParam() = 13 (38 ms)

Using GParted on Alpine Linux to perform the same action produces the
same error in the operation results.  Reproduce this on the command
line:
    # mkfs.fat -F 16 -v -I /dev/sdb1
    # mlabel -s -n :: -i /dev/sdb1
    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:
    # echo $?
    1

Again fix the same way, by moving the non-option '::' drive
specification to the end of the command line.  Also drop the '-s' option
as showing the current label is unrelated to writing a new UUID.
    # mdir -f -i /dev/sdb1 ::/ | grep 'Volume Serial Number is'
     Volume Serial Number is B97E-59A3
    # mlabel -n -i /dev/sdb1 ::
    # echo $?
    0
    # mdir -f -i /dev/sdb1 ::/ | grep 'Volume Serial Number is'
     Volume Serial Number is 1552-96A6

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 7d8870d845 Fix reading FAT16/32 FS UUID on Alpine Linux (!104)
Unit test reading FAT16/32 file system UUIDs fails on Alpine Linux like
this:
    $ ./test_SupportedFileSystems --gtest_filter='*CreateAndReadUUID/fat16'
    ....
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16
    test_SupportedFileSystems.cc:581: Failure
    Expected: (m_partition.uuid.size()) >= (9U), actual: 0 vs 9
    test_SupportedFileSystems.cc:584: Failure
    Value of: m_partition.get_messages().empty()
      Actual: false
    Expected: true
    Partition messages:
    Drive '::' not supported
    Cannot initialize '::'
    Drive 'A:' not supported
    Cannot initialize 'A:'
    Drive 'A:' not supported
    Cannot initialize 'A:'

    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16, where GetParam() = 13 (28 ms)

This doesn't normally affect GParted because it uses blkid as first
choice to read file system UUIDs, only using file system specific
commands when blkid isn't available.  Reproduce this on the command
line:
    # mkfs.fat -F 16 -v -I /dev/sdb1
    # mdir -f :: -i /dev/sdb1
    Drive '::' not supported
    Cannot initialize '::'
    Drive 'A:' not supported
    Cannot initialize 'A:'
    Drive 'A:' not supported
    Cannot initialize 'A:'

Again, this is caused by having non-option '::' drive specification
before all the options on the mdir command line, which isn't supported
by the POSIX strict getopt(3) on Alpine Linux.  Apply the same fix of
moving the non-option argument to the end.
    # mdir -f -i /dev/sdb1 ::/
     Volume is drive : has no label
     Volume Serial Number is 7DC9-BCD9
    Director for ::/

    No files
    # echo $?
    0

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 ff177038e5 Refactor fat16::read_uuid() into if fail return early pattern (!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 54dbc87b3b Fix writing FAT16/32 FS labels on Alpine Linux (!104)
Unit test writing FAT16/32 file system labels fails on Alpine Linux like
this:
    $ ./test_SupportedFileSystems --gtest_filter='*CreateAndWriteLabel/fat16'
    ...
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndWriteLabel/fat16
    test_SupportedFileSystems.cc:601: Failure
    Value of: m_fs_object->write_label(m_partition, m_operation_detail)
      Actual: false
    Expected: true
    Operation details:
    mkfs.fat -F16 -v -I -n 'FIRST      ' '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img'    00:00:00  (SUCCESS)
    ...
    mlabel ::'SECOND     ' -i '/home/alpine/programming/c/gparted/tests/test_SupportedFileSystems.img'    00:00:00  (ERROR)

    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:

    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndWriteLabel/fat16, where GetParam() = 13 (29 ms)

Using GParted on Alpine Linux to perform the same action produces the
same error in the operation results.  Reproduce this on the command
line:
    # mkfs.fat -F 16 -v -I -n FIRST /dev/sdb1
    # mlabel ::SECOND -i /dev/sdb1
    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:
    # echo $?
    1

Again, this is because musl libc's getopt(3) is POSIX compliant and
stops parsing options at '::', the first non-option argument.  Apply the
same fix of moving the non-option argument to the end of the mlabel
command line:
    # mlabel -i /dev/sdb1 ::SECOND
    # echo $?
    0
    # mlabel -s -i /dev/sdb1
     Volume label is SECOND

And for the clearing label case:
    # mlabel -c -i /dev/sdb1 ::
    # echo $?
    0
    # mlabel -s -i /dev/sdb1
     Volume has no label

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 a48b29ba19 Fix reading FAT16/32 FS labels on Alpine Linux (!104)
Several of the FAT16/32 file system unit tests fail on Alpine Linux.  In
this commit we are just looking at the failure to read the label.  The
test fails like this:
    $ ./test_SupportedFileSystems --gtest_filter='*CreateAndReadLabel/fat16'
    ...
    [ RUN      ] My/SupportedFileSystemsTest.CreateAndReadLabel/fat16
    test_SupportedFileSystems.cc:551: Failure
    Expected equality of these values:
      fs_label
        Which is: "TEST_LABEL"
      m_partition.get_filesystem_label().c_str()
        Which is: ""
    test_SupportedFileSystems.cc:554: Failure
    Value of: m_partition.get_messages().empty()
      Actual: false
    Expected: true
    Partition messages:
    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:

    [  FAILED  ] My/SupportedFileSystemsTest.CreateAndReadLabel/fat16, where GetParam() = 13 (21 ms)

The same error can be seen by using GParted to display a FAT16 or FAT32
file system on Alpine Linux.  The Partition Information dialog displays
this warning:
    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:

Reproduce this on the command line:
    # mkfs.fat -F 16 -v -I -n TEST_LABEL /dev/sdb1
    # mlabel -s :: -i /dev/sdb1
    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:
    # echo $?
    1

The mlabel.c source [1] uses getopt(3) to parse the command line
arguments.  musl libc's [2] getopt(3) must be strictly POSIX compliant
[3][4] and stops reading options at the first non-option argument, '::'
in this case.  Move the non-option argument to the end of the command
line and it works:
    # mlabel -s -i /dev/sdb1 ::
     Volume label is TEST_LABEL

Where as GNU Libc's getopt(3) [5] says that by default it reorders argv
eventually moving all non-option arguments to the end, hence why this
has worked on every Linux distribution using GNU Libc.  This can be
broken on any Linux distribution using GNU Libc by enforcing strict
POSIX behaviour from getopt(3).  For example on Fedora 36:
    # mkfs.fat -F 16 -v -I -n TEST_LABEL /dev/sdb1
    # export POSIXLY_CORRECT=1
    # mlabel -s :: -i /dev/sdb1
    Mtools version 4.0.39, dated April 10th, 2022
    Usage: mlabel [-vscVn] [-N serial] drive:
    # echo $?
    1
    # mlabel -s -i /dev/sdb1 ::
    Hidden (2048) does not match sectors (63)
     Volume label is TEST_LABEL
    # echo $?
    0

Fix by moving the non-option (image file drive specification) '::' to
the end of the mlabel command line.

[1] Mtools
    https://www.gnu.org/software/mtools/
[2] musl libc
    https://musl.libc.org/
    "musl is an implementation of the C standard library built on top of
    the Linux system call API, including interfaces defined in the base
    language standard, POSIX, and widely agreed-upon extensions.
    "
[3] POSIX.1-2017, Functions, getopt
    https://pubs.opengroup.org/onlinepubs/9699919799/functions/getopt.html
[4] getopt(3p)
    https://man7.org/linux/man-pages/man3/getopt.3p.html
[5] getopt(3)
    https://www.man7.org/linux/man-pages/man3/getopt.3.html
    "By default, getopt() permutes the contents of argv as it scans, so
    that eventually all the nonoptions are at the end.  Two other
    scanning modes are also implemented.  If the first character of
    optstring is '+' or the environment variable POSIXLY_CORRECT is set,
    then option processing stops as soon as a nonoption argument is
    encountered.
    "

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 407e0ac6e3 Refactor fat16::read_label() into if fail return early pattern (!104)
Follows the "Return Early" design pattern making the code easier to
understand without having to remember cases for elses or cascading ifs.
Refactor before the following commit's fix so that capture of output on
failure can be confirmed as still working.

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
Rafael Fontenelle 81c0076362 Update Brazilian Portuguese translation 2022-06-27 15:46:00 +00:00
Jürgen Benvenuti b45b8cfb08 Update German translation 2022-06-24 14:44:08 +00:00
Jordi Mas 74545a50de Update Catalan translation 2022-06-24 09:30:40 +02:00
Hugo Carvalho c7e08ba6e9 Update Portuguese translation 2022-06-23 22:03:32 +00:00
Sergej A befdf75d7d Update Russian translation 2022-06-13 13:25:17 +00:00
Мирослав Николић 50264d46b1 Update Serbian translation 2022-06-12 20:56:38 +00:00
Mike Fleetwood 053691378c Resolve messages from configure in VPATH build (!103)
Even though this is fixed the execution of configure as part of make
distcheck outputs this:
    checking whether po/Makefile.in.in deletes intltool cache lock file... /usr/bin/grep: po/Makefile.in.in: No such file or directory
    /usr/bin/sed: can't read po/Makefile.in.in: No such file or directory
    /usr/bin/grep: po/Makefile.in.in: No such file or directory
    no

make distcheck [1] performs a VPATH build with a read-only srcdir and
a separate writable build directory with files split between the two.
The relevant layout looks like:
    ./gparted-1.4.0-git/configure
    ./gparted-1.4.0-git/po/Makefile.in.in
    ./gparted-1.4.0-git/_build/sub/

And make distcheck runs configure like this:
    cd ./gparted-1.4.0-git/_build/sub
    ../../configure --srcdir=../..

The file is ../../po/Makefile.in.in in this case, so not found by the
existing check.  A simple investigation technique is to run make
distcheck, kill it shortly after configure completes and examine the
build tree.  Definitely before make distcheck completes successfully and
deletes everything.

Fix by using $srcdir prefix to access the file.  Also handle the case of
po/Makefile.in.in not existing, although this doesn't now occur in the
scenario fixed by this commit.  And only patch the file if it's
writable, another case that doesn't occur in this scenario.

Relevant output line from configure run by make distcheck now looks
like:
    checking whether po/Makefile.in.in deletes intltool cache lock file... yes

[1] GNU Automake, 14.4 Checking the Distribution
    https://www.gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html

Closes !103 - Fix make distcheck failure found in GitLab CI job
              unbuntu_test
2022-06-07 16:38:20 +00:00
Mike Fleetwood 0bd636a34b Fix up intltool leaving .intltool-merge-cache.lock file behind (!103)
On Ubuntu 22.04 LTS make distcheck fails like this:
    $ make distcheck
    ...
    ERROR: files left in build directory after distclean:
    ./po/.intltool-merge-cache.lock
    make[1]: *** [Makefile:920: distcleancheck] Error 1
    make[1]: Leaving directory '/builds/GNOME/gparted/gparted-1.4.0-git/_build/sub'
    make: *** [Makefile:849: distcheck] Error 1

This was picked up by the GitLab ubuntu_test CI job after the Ubuntu
22.04 LTS release and the official Ubuntu docker image labelled latest
was updated to match, circa April 2022.  This is a known issue with
intltool >= 0.51.0-5.1 [1][2][3], first included in Ubuntu 22.04 LTS.

The pending proposed fix is to also delete the left behind
.intltool-merge-cache.lock along with the associated cache file itself
in the intltool provided Makefile.in.in [4].

Applying a fix to the GitLab ubuntu_test CI job does nothing for fixing
it for us maintainers on our distributions.  po/Makefile.in.in is not
part of the GParted git repository, instead it is copied from
/usr/share/intltool/Makefile.in.in by ./autogen.sh -> gnome-autogen.sh
-> intltoolize --force --copy --automake.  Add a configure check which
patches po/Makefile.in.in as needed.  This will fix it for those
building from git, and be a harmless check for those building from a tar
release.  Configure output line looks like:
    checking whether po/Makefile.in.in deletes intltool cache lock file... fixed

[1] Ubuntu bug 1712194 - Error when running make distcheck
    https://bugs.launchpad.net/intltool/+bug/1712194
[2] Debian bug #991623 - intltool: make distcheck broken
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991623
[3] Arch Linux bug FS#67098 - [intltool] latest patch for race condition
    breaks some builds
    https://bugs.archlinux.org/task/67098
[4] Remove cache lock file in mostlyclean
    https://code.launchpad.net/~danbnicholson/intltool/intltool/+merge/406321

Closes !103 - Fix make distcheck failure found in GitLab CI job
              unbuntu_test
2022-06-07 16:38:20 +00:00
Piotr Drąg 4b1c9badbc Update Polish translation 2022-06-05 14:16:59 +02:00