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
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
[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
4fd6821324Closes!107 - Migrate from intltool to gettext translation
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
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
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
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
'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
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
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
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
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)
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.
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
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
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
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
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
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
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
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
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
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
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.htmlCloses!103 - Fix make distcheck failure found in GitLab CI job
unbuntu_test
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/406321Closes!103 - Fix make distcheck failure found in GitLab CI job
unbuntu_test
Mike Fleetwood