Discovered with Clang’s scan-build tool:

    ../../../src/fr-window.c:3301:3: warning: Value stored to 'archive' is never read [deadcode.DeadStores]
                    archive =  private->archive_file;
                    ^          ~~~~~~~~~~~~~~~~~~~~~

The reference was removed with statusbar https://gitlab.gnome.org/GNOME/file-roller/-/commit/fd4d0c0af39bbdbbf68df65cccfe38b63ac19185

Automatically converted using https://gitlab.gnome.org/jtojnar/glib-refactoring/-/blob/0a59526c84bd8cc06c5c6e01189ff3b056ef37c8/patches/glib/autocleanup.cocci and then manually cleaned up the coding style.

Define auto-cleanup functions, taken from https://github.com/fwupd/fwupd/blob/4df0d2176be4c3439d95310a974d8077ae40dbe0/libfwupdplugin/fu-archive.c#L326-L357
Although I removed the close functions since we want to capture the error when close fails.

Discovered with Clang’s scan-build tool:

    ../../../src/fr-application.c:273:37: warning: Access to field 'data' results in a dereference of a null pointer (loaded from variable 'file_list') [core.NullDereference]
                            destination = g_file_get_parent (G_FILE (file_list->data));
                                                             ^~~~~~~~~~~~~~~~~~~~~~~~

Would occur when empty destination URI was passed to Compress D-Bus method.

Introduced in https://gitlab.gnome.org/GNOME/file-roller/-/commit/34b64f3a897c4b4e8e180c028f326bc921eb08ec

Clang’s scan-build tool complains:

    ../../../src/fr-window.c:7320:10: warning: Access to field 'data' results in a dereference of a null pointer (loaded from field 'history_current') [core.NullDereference]
                    return private->history_current->data;
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But we are already calling `fr_window_history_add` on the previous line,
which updates the `history_current` with the new location.

Clang’s scan-build tool complains:

    ../../../src/dlg-update.c:152:20: warning: Access to field 'data' results in a dereference of a null pointer (loaded from field 'file_list') [core.NullDereference]
                    OpenFile *file = data->file_list->data;
                                     ^~~~~~~~~~~~~~~~~~~~~

But if `file_list` was NULL, the g_list_length would return 0 and so the `n_files == 1` branch would not be entered.

In some cases, libarchive does not initialize the `offset` attribute
to `archive_read_data_block` for RAR5, often causing `_g_output_stream_add_padding`
to write up to exabytes of padding to extracted file, to reach the random
unitialized value in `int64_t target_offset`.

This will be fixed by https://github.com/libarchive/libarchive/pull/1745
but until a new version is released and widely available,
let’s initialize the value ourselves.

Fixes: https://gitlab.gnome.org/GNOME/file-roller/-/issues/46

- Add shebang
- Make executable
- Add locale to force consistent collation
  Suggested by https://gitlab.gnome.org/GNOME/file-roller/-/issues/97
- Drop packages.match.in template since it only really has header
  and causes extra final new line to be included.
- Run grep directly by find.

(cherry picked from commit c425404f4d3427bcff34877c84a119940e1a469f)

Ran the following with some manual clean-ups.

for f in (fd meson.build) meson_options.txt
  muon fmt -i -c muon_fmt.ini "$f"
end

It is recommended by Meson.