- Feb 10, 2024
-
-
- Feb 08, 2024
-
-
... because it is not necessary and clutters the code.
-
As the AppStream 1.0 [1] specification no longer describes them as appdata files, but instead as metainfo files, rename the Makefile.am variables for consistency with the name of the standard. [1] AppStream 1.0 https://www.freedesktop.org/software/appstream/docs/index.html Closes #241 - Move appstream metadata out of legacy path -
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) gnome-system-monitor@43dc0577 [5] [Evince] build: Install appstream metadata to non-deprecated location evince@8cae24ea Closes #241 - Move appstream metadata out of legacy path
-
- Feb 07, 2024
-
-
- Jan 30, 2024
-
-
Daniel Mustieles García authored
-
- Jan 26, 2024
-
-
- Jan 20, 2024
-
-
- Dec 28, 2023
-
-
- Nov 30, 2023
-
-
- Oct 29, 2023
-
-
Closes !119 - Tidy-ups for file system interface classes
-
Closes !119 - Tidy-ups for file system interface classes
-
Closes !119 - Tidy-ups for file system interface classes
-
Closes !119 - Tidy-ups for file system interface classes
-
... code pattern. This is to make the code easier to understand by not having to remember if condition context for indented code over longer distances. This has been done before. Here are just 2 examples: [1] 75bda733 Refactor run_blkid_load_cache() into if fail return early (#131) [2] 407e0ac6 Refactor fat16::read_label() into if fail return early pattern (!104) Closes !119 - Tidy-ups for file system interface classes
-
Now those member variables are unused remove them. Closes !119 - Tidy-ups for file system interface classes
-
Restructure the variable parsing code into "if leading text found then scan the number" pattern. Closes !119 - Tidy-ups for file system interface classes
-
Restructure the variable parsing code into "if leading text found then scan the number" pattern. Anchor leading text matches to the start of a new line in the output. Closes !119 - Tidy-ups for file system interface classes
-
Restructure the variable parsing code into "if leading text found then scan the number" pattern. Closes !119 - Tidy-ups for file system interface classes
-
And restructure the variable parsing code into "if leading text found then scan the number" pattern. Anchor leading text matches to the start of a new line in the output. Closes !119 - Tidy-ups for file system interface classes
-
Closes !119 - Tidy-ups for file system interface classes
-
FileSystem member variables T, N & S are being used like local variables in many of the file system specific set_used_sectors() methods. They are only used within each set_used_sectors() call and not used to represent persistent information of a FileSystem interface class or to pass information between separate methods. Therefore stop using them and replace them with local variables instead. This block of code finds a field in the output and scans the number: Glib::ustring::size_type index = output.find("Block count:"); if (index >= output.length() || sscanf(output.substr(index).c_str(), "Block count: %lld", &T) != 1) T = -1; The if statement says "if leading text is not found or scanning the number fails then assign -1". A sequence of two negatives leading to assigning an error value is hard to understand. Instead this an equivalent block from btrfs::set_used_sectors(): long long total_bytes = -1; Glib::ustring::size_type index = output.find("\ntotal_bytes"); if (index < output.length()) sscanf(output.substr(index).c_str(), "\ntotal_bytes %lld", &total_bytes); This assigns a default error value and the if statement says "if leading text found then scan the number". Much simpler to understand. Therefore change the code around to use this same pattern. Anchor the leading text matches to the start of a new line in the output where possible. Just because it's what some of the other file system's set_used_sectors() methods do (btrfs, reiser4 and xfs) and it seems like more robust text matching. Closes !119 - Tidy-ups for file system interface classes -
Replace floating point calculation to convert size and space figures from file system block sized units to sectors with an integer calculation. Do this for the same reasons discussed in commit "Stop using floating point calculations in FS resize() methods" earlier in this patchset. This will limit the largest file system that GParted can read the usage of to 8 EiB - 1 bytes. There is still a floating point calculation in btrfs::set_used_sectors() which is being left because that is apportioning used space figure between multiple devices. Closes !119 - Tidy-ups for file system interface classes
-
So that it is similar to other calls to execute_command() and for grep friendliness. Closes !119 - Tidy-ups for file system interface classes
-
Pass string literal containing the nilfs2 resize command to execute_command() rather than a string variable containing the same command. This makes it the same as how most of the other calls to execute_command() are written and it makes it more grep friendly. Before: $ grep execute_command src/nilfs2.cc if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -L " + Glib::shell_quote( partition.get_filesystem_label() ) + if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -U " + Glib::shell_quote( Utils::generate_uuid() ) + return ! execute_command( "mkfs.nilfs2 -L " + Glib::shell_quote( new_partition.get_filesystem_label() ) + success &= ! execute_command( "mount -v -t nilfs2 " + Glib::shell_quote( partition_new.get_path() ) + >> success &= ! execute_command( cmd, operationdetail, EXEC_CHECK_STATUS ); success &= ! execute_command( "umount -v " + Glib::shell_quote( mount_point ), After: $ grep execute_command src/nilfs2.cc if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -L " + Glib::shell_quote( partition.get_filesystem_label() ) + if ( ! Utils::execute_command( "nilfs-tune -l " + Glib::shell_quote( partition.get_path() ), return ! execute_command( "nilfs-tune -U " + Glib::shell_quote( Utils::generate_uuid() ) + return ! execute_command( "mkfs.nilfs2 -L " + Glib::shell_quote( new_partition.get_filesystem_label() ) + success &= ! execute_command( "mount -v -t nilfs2 " + Glib::shell_quote( partition_new.get_path() ) + >> success &= ! execute_command("nilfs-resize -v -y " + Glib::shell_quote(partition_new.get_path()) + size, success &= ! execute_command( "umount -v " + Glib::shell_quote( mount_point ), Closes !119 - Tidy-ups for file system interface classes -
A number of the file system specific resize() methods use floating point calculations to convert from the new partition size in sectors to the new file system size to be passed to the resize command in bytes or kibibytes. This is bad because there could be rounding errors converting from integer to floating point, performing the calculation and converting back. Replace with integer only multiply and divide calculations. Integer division always truncates [1] which is exactly what is needed. The largest integer will be the size of the file system in bytes held in a signed 64-bit long long, or Sector or Byte_Value typedef of the same type. This will limit the size that a file system can be shrunk to, to 8 EiB - 1 byte. [1] C++ Arithmetic operators https://en.cppreference.com/w/cpp/language/operator_arithmetic "the algebraic quotient of integer division is truncated towards zero (fractional part is discarded)" Closes !119 - Tidy-ups for file system interface classes
-
- Oct 22, 2023
-
-
- Oct 21, 2023
-
-
- Oct 19, 2023
-
-
- Oct 12, 2023
-
-
- Oct 05, 2023
-
-
- Oct 04, 2023
-
-
The GUI displays the file system of an open encrypted file system as "[Encrypted] FSTYPE" [1]. However saved details just writes the file system type as "luks". Update saved details writing code to use the same method the GUI currently uses [2]. [1] commit cb3cc505 Display "[Encrypted] FSTYPE" in the File System column (#760080) [2] commit bd6fc67a Provide virtual Partition::get_filesystem_string() method (#774818)
-
-
Keep the paragraph discussing photorec and move just after testdisk is mentioned in the Recovering Partition Tables section. Closes !118 - Remove Attempt Data Rescue and use of gpart
-
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/TestDisk Closes !118 - Remove Attempt Data Rescue and use of gpart
-
- Sep 23, 2023
-
-
When compiling the tests, this warning is reported: $ make check ... warning: ...: INSTANTIATE_TEST_CASE_P is deprecated, please use INSTANTIATE_TEST_SUITE_P [-Wdeprecated-declarations] static_assert(::testing::internal::InstantiateTestCase_P_IsDeprecated(), \ ^ test_SupportedFileSystems.cc:625:1: note: in expansion of macro 'INSTANTIATE_TEST_CASE_P' Google Test 1.10.0 release notes [1] say: High Level Changes: This release deprecated "....TEST_CASE" API in favor of "....TEST_SUITE". In a nutshell if you have code that uses something like "INSTANTIATE_TYPED_TEST_CASE_P " - this and all other "*_TEST_CASE " are now deprecated in favor of more standard _TEST_SUITE. Replace the deprecated API with the new API. [1] Google Test release v1.10.0 https://github.com/google/googletest/releases/tag/release-1.10.0 Closes !117 - Require C++11 compilation -
So far GParted includes Google Test 1.8.1 [1], which was the latest release which supported pre-C++11 compilers [2]. Now that GParted requires C++11 compilation, update to Google Test 1.10.0. Replace the following files and directories from Google Test 1.10.0: LICENSE README.md include/ src/ Note the LICENSE file is identical, where as the other files have changed. This includes file additions and removals, hence the change to Makefile.am too. Even though Google Test releases up to and including 1.12.1 are compilable with C++11 compilers [3], it is not possible to upgrade beyond Google Test 1.10.0 at this time because later releases fail to compile on on still supported RHEL / CentOS 7 with this error: $ cd lib/gtest $ make check ... ./include/gtest/gtest-matchers.h:414:12: error: 'is_trivially_copy_constructible' is not a member of 'std' std::is_trivially_copy_constructible<M>::value && ^ This failur... -
Closes !117 - Require C++11 compilation
-
In C++11, nullptr [1] is the strongly typed value to use instead of the macro NULL [2]. Use everywhere [3][4]. [1] nullptr, the pointer literal (since C++11) https://en.cppreference.com/w/cpp/language/nullptr [2] NULL https://en.cppreference.com/w/cpp/types/NULL [3] Bjarne Stroustrup's C++ Style and Technique FAQ, Should I use NULL or 0? https://www.stroustrup.com/bs_faq2.html#null "In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days. If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyw...
-