gpart scans a drive trying to guess the location of partitions when an
MBR partition table is lost [1]. However the tool is unmaintained,
takes hours or days of 100% CPU time to scan a drive and provides no
progress indication [2][3][4]. We keep recommending killing the gpart
process and using TestDisk [5] instead.
Therefore remove Device > Attempt Data Rescue and the use of gpart from
GParted.
[1] Gpart
https://github.com/baruch/gpart
[2] Have you had a good or bad experience with Dev->Attempt Data Rescue?
http://gparted-forum.surf4.info/viewtopic.php?id=17992
No good, only bad experiences using gpart were reported.
[3] Gparted does not say anything
http://gparted-forum.surf4.info/viewtopic.php?id=17749
Forum user reported waiting 48 hours with no progress indication.
We recommended using TestDisk.
[4] How cancel Data Rescue process?
http://gparted-forum.surf4.info/viewtopic.php?id=18143
Forum user reported it will take 3 days to scan their external 480GB
drive. We recommended using TestDisk instead.
[5] TestDisk, Data Recovery
https://www.cgsecurity.org/wiki/TestDiskCloses!118 - Remove Attempt Data Rescue and use of gpart
[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
Alan Mortensen