AppData files always were a subset of the AppStream specification
[1][2]. AppStream 0.12 specification [3] onwards says the metainfo
files will be found when placed in /usr/share/metainfo/ *AND* that
/usr/share/appdata/ is a legacy location *AND* a future release of
AppStream will likely drop support for it [4].
Debian 10, RHEL 7 and Ubuntu 18.04 LTS distributions all have the
/usr/share/metainfo/ directory containing application .appdata.xml and
.metainfo.xml files. Ubuntu 16.04 LTS does not have the directory
despite the AppStream specification [3] claiming it does. As old
supported distributions do have the directory, unconditionally update
this.
For reference are these commits in projects GNOME System Monitor [4] and
Evince [5] from 2017 making the same change.
[1] AppData Specification [circa 2016]
https://web.archive.org/web/20160903181519/https://people.freedesktop.org/~hughsient/appdata/
"Rather than create a new schema from scratch, we'll be using a
subset of the AppStream metadata proposal.
Applications wishing to have long descriptions, screenshots and
other useful things are required to ship one or more files in
/usr/share/appdata/%{id}.appdata.xml.
"
[2] AppStream 0.4, 2.2 AppData XML files [circa 2013]
https://web.archive.org/web/20131204004054/http://www.freedesktop.org/software/appstream/docs/sect-AppStream-Metadata-AppData.html
[3] AppStream 0.12, 2.1.2 Filesystem locations [circa 2020]
https://web.archive.org/web/20200615042130/https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
"2.1.2 Filesystem locations
Upstream projects can ship one or more metainfo files in
/usr/share/metainfo/%{id}.metainfo.xml, where id is a unique
identifier of this specific component.
(>) Note
Component metadata of type desktop-application as described in
Section 2.2, "Desktop Applications" can be installed with an
.appdata.xml extension as well for historical reasons. AppStream
implementations will read the XML files as long as they end up in
the right location on the filesystem.
(!) Important: Legacy Path
AppStream tools scan the /usr/share/appdata/ path for legacy
compatibility as well. It should not be used anymore by new
software though, even on older Linux distributions (like RHEL 7 and
Ubuntu 16.04 LTS) the metainfo path is well supported. Support for
the legacy path will likely be dropped completely with a future
AppStream 1.0 release.
"
[4] [GNOME System Monitor] Install appdata to the new location
(bgo#790146)
43dc057771
[5] [Evince] build: Install appstream metadata to non-deprecated
location
8cae24ea48Closes#241 - Move appstream metadata out of legacy path
[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
Executables which are not intended for execution by users, but by other
programs, should be installed into /usr/libexec [1][2]. gpartedbin
falls into this category. Update it's installation accordingly.
Standard Autotools details: gpartedbin will be installed into
EPREFIX/libexec by default. To install gpartedbin into a different
directory set libexecdir when configuring the build system. Like this
from git:
./autogen.sh --libexecdir=DIR
or like this from tar release:
./configure --libexecdir=DIR
[1] Filesystem Hierarchy Standard, version 3.0,
4.7. /usr/libexec : Binaries run by other programs (optional)
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
"/usr/libexec includes internal binaries that are not intended to be
executed directly by users or shell scripts.
"
[2] GNU Coding Standards, June 12, 2020,
7.2.5 Variables for Installation Directories
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
"libexecdir
The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
/usr/local/libexec, but write it as $(exec_prefix)/libexec. (If you
are using Autoconf, write it as '@libexecdir@'.)
"
Closes#85 - Please install gpartedbin under /usr/libexec instead of
/usr/sbin
Details of old GNOME 2 gnome-doc-utils:
Migrating your documentation to gnome-doc-utils
https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo
First part is to stop using gnome-doc-utils to build and install the
documentation. Also since updating the OMF catalog was only needed for
GNOME 2 yelp, use of scrollkeeper is completely removed too.
Closes!24 - Port to GNOME 3 yelp-tools documentation infrastructure
GParted fails to display when run under Wayland [1][2][3]. This is
because by intentional design Wayland doesn't allow applications with
root privileges access to the display [4].
As an interim workaround make the gparted shell wrapper use xhost to
grant root access to the X11 server if root doesn't already have access,
but only when configured. Granting root access must be explicitly
enabled when building GParted like this:
./configure --enable-xhost-root
It defaults to disabled. When gpartedbin binary ends the shell wrapper
revokes root access only if it granted such access.
[1] GNOME Bug 776437 - GParted fails to run as root under Wayland
https://bugzilla.gnome.org/show_bug.cgi?id=776437
[2] Ubuntu Bug 1652282 - GParted does not work in GNOME on Wayland
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1652282
[3] Fedora Bug 1397103 - gparted not working under Wayland
https://bugzilla.redhat.com/show_bug.cgi?id=1397103
[4] Common Fedora 25 bugs
Running graphical apps with root privileges (e.g. gparted) does not
work on Wayland
https://fedoraproject.org/wiki/Common_F25_bugs#wayland-root-apps
Bug 776437 - GParted fails to run as root under Wayland
Only install the GParted polkit action file when pkexec is being used as
the root privilege escalation program.
Bug 776437 - GParted fails to run as root under Wayland
An action file is always needed with polkit to describe the privileged
actions that are available to the subject (client program). For GParted
the only available action is to run the gparted shell script as root.
Note that the polkit action file will be installed into location
$(prefix)/share/polkit-1/actions. This is required by the GNU Coding
Standards [1] and to prevent 'make distcheck' from failing [2]. However
polkit only uses /usr/share/polkit-1/actions for it's action files [3].
This dilemma was discussed in this Bugzilla bug 776437 and on the
general Automake discussion email list [4]. The solution is to simply
document in the README file that a manual additional installation step
may be required.
The action file is marked as translatable with the underscore (_) of the
_description and _message tags identifying the string to be translated.
Use of INTLTOOL_POLICY_RULE in Makefile.am to merge translations into
the polkit action file necessitates increasing the minimum version of
intltool to 0.36.0 where it was first introduced in intltool.m4. This
will prevent GParted building on RedHat/CentOS 5 which only has intltool
0.35.0. But that doesn't matter because RedHat/CentOS 5 reached end of
life on 31st March 2017.
[1] GNU Coding Standards, 7.2.5 Variables for Installation Directories
https://www.gnu.org/prep/standards/standards.html#Directory-Variables
[2] Automake Manual, 27.10 Installing to Hard-Coded Locations
https://www.gnu.org/software/automake/manual/automake.html#Hard_002dCoded-Install-Paths
"My package needs to populate the installation directory of another
package at install-time. I can easily compute that installation
directory in configure, but if I install files therein,
'make distcheck' fails. How else should I do?"
[3] polkit(8), Declaring Actions
https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html#polkit-declaring-actions
"A mechanism need to declare a set of actions in order to use
polkit. Actions correspond to operations that clients can request
the mechanism to carry out and are defined in XML files that the
mechanism installs into the /usr/share/polkit-1/actions directory."
[4] Not installing to hard-coded locations vs polkit's fixed location
http://lists.gnu.org/archive/html/automake/2017-08/msg00015.html
Bug 776437 - GParted fails to run as root under Wayland
Now that the gparted script is intended to be run by ordinary users, as
well as root, install it into directory $prefix/bin rather than
$prefix/sbin.
Bug 776437 - GParted fails to run as root under Wayland
Running ./autogen.sh reports this suggestion:
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Add suggested setting as it causes no difference and silences the
suggestion.
The Libtool Manual, 5.5.1 Invoking libtoolize
https://www.gnu.org/software/libtool/manual/html_node/Invoking-libtoolize.html
"If libtoolize detects an explicit call to AC_CONFIG_MACRO_DIRS (see
The Autoconf Manual in The Autoconf Manual) in your configure.ac, it
will put the Libtool macros in the specified directory.
In the future other Autotools will automatically check the contents
of AC_CONFIG_MACRO_DIRS, but at the moment it is more portable to
add the macro directory to ACLOCAL_AMFLAGS in Makefile.am, which is
where the tools currently look. If libtoolize doesn't see
AC_CONFIG_MACRO_DIRS, it too will honour the first '-I' argument in
ACLOCAL_AMFLAGS when choosing a directory to store libtool
configuration macros in. It is perfectly sensible to use both
AC_CONFIG_MACRO_DIRS and ACLOCAL_AMFLAGS, as long as they are kept
in synchronisation.
ACLOCAL_AMFLAGS = -I m4
"
Now 'make check' will additionally build and run the test suites in the
./tests directory. Add initial always successful dummy test suite.
This is done using Automake support for testing.
Automake Manual, 15 Support for test suites
https://www.gnu.org/software/automake/manual/automake.html#Tests
./tests/Makefile.am takes some influence from the same file in the
minimal-gtest-autotools template project.
654848ec01/tests/Makefile.am
Bug 781978 - Add Google Test C++ test framework
This closely follows the minimal-gtest-autotools template project.
https://github.com/octol/minimal-gtest-autotools
Now 'make check' will additionally build the Google Test C++ test
framework libraries.
Bug 781978 - Add Google Test C++ test framework
Use AC_ARG_ENABLE() and AS_HELP_STRING() macros to improve handling of
the --disable-doc option.
Change the names, and sence, of the Autoconf and Automake definitions
used to control building of the help documentation. Reasons are:
(1) Switch from negative to positive statements which are more natural
to comprehend.
(2) Insert HELP in the names from *_DOC to *_HELP_DOC as they control
building of the documentation in the help subdirectory, not the
manual page in the doc directory.
Autoconf: HAVE_DISABLE_DOC -> ENABLE_HELP_DOC
Automake: DISABLE_DOC -> BUILD_HELP_DOC
Bug #734076 - Autodetect parted online partition resizing capability
Enhance Makefile.am to add 'git log' entries to the ChangeLog
after the release of gparted-0.4.4. This is performed by a dist-hook
target only on release. E.g., make dist
Thanks to Sebastion Kraft for designing the icons.
Thanks to Michael Monreal for the small patch to make use of themed app icon from hicolor.
svn path=/trunk/; revision=909
- Removed gparted-disable-automount.fdi handling.
- Renamed gparted binary to gpartedbin to permit a calling script to be named gparted.
- Added new calling script gparted.in to permit using hal-lock to acuiqre device locks to prevent automounting while executing gpartedbin.
- Renamed gparted.desktop.in to gparted.desktop.in.in to permit parsing installdir.
svn path=/trunk/; revision=826
* include/GParted_Core.h,
include/Partition.h,
src/Dialog_Partition_Info.cc,
src/GParted_Core.cc,
src/Partition.cc,
src/TreeView_Detail.cc: store flags in a list instead of a string.
* Makefile.am,
src/Makefile.am: cleanups
* removed INSTALL
* compose/.cvsignore,
compose/Makefile.am,
Makefile.am,
configure.in,
include/Makefile.am: some fixes to make 'make dist' work (thanks to Daniel Holbach)
* Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and
adding support for other filesystems should be a piece of cake now (hope that's true :P)
It still needs a lot of love, but the foundations are laid =)
Mike Fleetwood