"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "ChangeLog" between
gparted-1.1.0.tar.gz and gparted-1.2.0.tar.gz

About: GParted is a graphical partition editor for creating, reorganizing, and deleting disk partitions (using GNU libparted).

ChangeLog  (gparted-1.1.0):ChangeLog  (gparted-1.2.0)
# Generated by Makefile. Do not edit. # Generated by Makefile. Do not edit.
2021-01-25 Curtis Gedak <gedakc@gmail.com>
========== gparted-1.2.0 ==========
2021-01-25 Curtis Gedak <gedakc@gmail.com>
Update copyright years
2021-01-24 Rūdolfs Mazurs <rudolfs.mazurs@gmail.com>
Update Latvian translation
2021-01-23 Fabio Tomat <f.t.public@gmail.com>
Update Friulian translation
2021-01-22 Philipp Kiemle <philipp.kiemle@gmail.com>
Update German translation
2021-01-21 Marek Černocký <marek@manet.cz>
Updated Czech translation
2021-01-20 Thibault Martin <mail@thibaultmart.in>
Update French translation
2021-01-19 Мирослав Николић <miroslavnikolic@rocketmail.com>
Update Serbian translation
2021-01-19 Daniel Mustieles <daniel.mustieles@gmail.com>
Updated Spanish translation
2021-01-18 Rafael Fontenelle <rafaelff@gnome.org>
Update Brazilian Portuguese translation
2021-01-18 Rafael Fontenelle <rafaelff@gnome.org>
Update Brazilian Portuguese translation
2021-01-18 Daniel Șerbănescu <daniel@serbanescu.dk>
Update Romanian translation
2021-01-17 Piotr Drąg <piotrdrag@gmail.com>
Update Polish translation
2021-01-16 Anders Jonsson <anders.jonsson@norsjovallen.se>
Update Swedish translation
2021-01-16 Yuri Chornoivan <yurchor@ukr.net>
Update Ukrainian translation
2021-01-11 Mike Fleetwood <mike.fleetwood@googlemail.com>
White space tidy-up of Utils::get_filesystem_software()
Put colon directly after case value and list cases in enumeration order.
2021-01-13 Mike Fleetwood <mike.fleetwood@googlemail.com>
Add unit testing of GParted exFAT interface (!30)
Install exfatprogs into the CentOS 7 GitLab CI image, enabling unit
testing of GParted's use of exFAT programs. Exfatprogs is not yet
available for Ubuntu 20.04 as used in the Ubuntu GitLab CI image, only
for Ubuntu 20.10 so far.
Closes !30 - Add exFAT support
2021-01-11 Mike Fleetwood <mike.fleetwood@googlemail.com>
Set the partition type for exFAT correctly (!30)
Libparted only allows selection of the partition type indirectly by
specifying the type of the file system it will contain [1] and so far
doesn't know about the exFAT file system. Therefore when GParted is
creating a new exFAT partition, it gets the GParted default of 83
(Linux file system) on MBR partition tables.
Example operation details:
Create Primary Partition #1 (exfat, 512.00 MiB) on /dev/sdb
* create empty partition
* clear old file system signatures in /dev/sdb1
* set partition type on /dev/sdb1
new partition type: ext2
* create new exfat file system
fdisk report:
# fdisk -l /dev/sdb
Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa2aab629
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1050623 1048576 512M 83 Linux
However the "exFAT file system specification" says:
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specificatio
n
"10.2 Partition Tables
To ensure interoperability of exFAT volumes in a broad set of usage
scenarios, implementations should use partition type 07h for MBR
partitioned storage and partition GUID
{EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} for GPT partitioned storage.
"
Fix this.
[1] ped_partition_new(..., const PedFileSystemType* fs_type, ...)
https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca
75880f9e0c3ce57f7a4b72faf5
ped_partition_set_system(..., const PedFileSystemType* fs_type)
https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca
75880f9e0c3ce57f7a4b72faf5
Closes !30 - Add exFAT support
2021-01-11 Mike Fleetwood <mike.fleetwood@googlemail.com>
Add exFAT support (!30)
With exfatprogs (https://github.com/exfatprogs/exfatprogs) installed the
following operations on exFAT file systems are supported:
- Creation
- Checking
- Labelling
As of the current exfatprogs 1.0.4 the following are not supported:
- Reading usage
- Resizing
- Updating the UUID
Closes !30 - Add exFAT support
2021-01-10 Mike Fleetwood <mike.fleetwood@googlemail.com>
Exclude snap /dev/loop file system image mounts (#129)
On Ubuntu the gparted shell wrapper still attempts to mask lots of
non-block device based file systems. Remove the --quiet option from the
systemctl --runtime mask command to see:
$ gparted
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-66.mou
nt -> /dev/null.
Created symlink /run/systemd/system/snap-core-10583.mount -> /dev/null.
Created symlink /run/systemd/system/boot-efi.mount -> /dev/null.
Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1514.mo
unt -> /dev/null.
Created symlink /run/systemd/system/snap-core-10577.mount -> /dev/null.
Created symlink /run/systemd/system/snap-core18-1944.mount -> /dev/null.
Created symlink /run/systemd/system/run-user-1000-doc.mount -> /dev/null
.
Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1506.mo
unt -> /dev/null.
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-128.mo
unt -> /dev/null.
Created symlink /run/systemd/system/snap-snap\x2dstore-518.mount -> /dev
/null.
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-145.mo
unt -> /dev/null.
Created symlink /run/systemd/system/snap-core18-1932.mount -> /dev/null.
Created symlink /run/systemd/system/snap-snap\x2dstore-467.mount -> /dev
/null.
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-60.mou
nt -> /dev/null.
Created symlink /run/systemd/system/-.mount -> /dev/null.
GParted 1.0.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
The gparted shell wrapper is currently looking for non-masked Systemd
mount units where the 'What' property starts "/dev/". However Ubuntu
also uses snap packages which are mounted file images via loop devices:
$ grep '^/dev/' /proc/mounts | sort
/dev/fuse /run/user/1000/doc fuse rw,nosuid,nodev,relatime,user_id=1000,
group_id=1000 0 0
/dev/loop0 /snap/core/10583 squashfs ro,nodev,relatime 0 0
/dev/loop10 /snap/snap-store/518 squashfs ro,nodev,relatime 0 0
/dev/loop11 /snap/snap-store/467 squashfs ro,nodev,relatime 0 0
/dev/loop12 /snap/gtk-common-themes/1506 squashfs ro,nodev,relatime 0 0
/dev/loop1 /snap/core/10577 squashfs ro,nodev,relatime 0 0
/dev/loop3 /snap/core18/1944 squashfs ro,nodev,relatime 0 0
/dev/loop4 /snap/core18/1932 squashfs ro,nodev,relatime 0 0
/dev/loop5 /snap/gnome-3-34-1804/66 squashfs ro,nodev,relatime 0 0
/dev/loop6 /snap/gnome-3-28-1804/128 squashfs ro,nodev,relatime 0 0
/dev/loop7 /snap/gnome-3-34-1804/60 squashfs ro,nodev,relatime 0 0
/dev/loop8 /snap/gnome-3-28-1804/145 squashfs ro,nodev,relatime 0 0
/dev/loop9 /snap/gtk-common-themes/1514 squashfs ro,nodev,relatime 0 0
/dev/sda1 /boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,
iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
Fix by excluding:
1. Device name "/dev/fuse" because it's a character not a block device
and the mount point is associated with snap,
2. Device names starting "/dev/loop" and where the mount point starts
"/snap/" [1]. This is to allow for use of GParted with explicitly
named loop devices.
[1] The system /snap directory
https://snapcraft.io/docs/system-snap-directory
Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding
anyway
2021-01-04 Mike Fleetwood <mike.fleetwood@googlemail.com>
Only mask Systemd mounts on block devices (#129)
The gparted shell wrapper masks Systemd mount units to prevent it
automounting file systems while GParted is running [1], excluding
virtual file system which GParted isn't interested in [2]. The problem
is that there are a lot of virtual file systems and they have changed
between Fedora 19 and 33 so now the exclusion list is out of date.
Run GParted on Fedora 33 and query the mount units while it is running:
$ systemctl list-units -t mount --full --all
UNIT LOAD ACTIVE SUB DESCRIPTION
-.mount loaded active mounted Root Mount
* boot.mount masked active mounted /boot
dev-hugepages.mount loaded active mounted Huge Pages File
System
dev-mqueue.mount loaded active mounted POSIX Message Qu
eue File System
* home.mount masked active mounted /home
* proc-fs-nfsd.mount masked inactive dead proc-fs-nfsd.mou
nt
proc-sys-fs-binfmt_misc.mount loaded inactive dead Arbitrary Execut
able File Formats File System
run-user-1000-gvfs.mount loaded active mounted /run/user/1000/g
vfs
* run-user-1000.mount masked active mounted /run/user/1000
* run-user-42.mount masked active mounted /run/user/42
sys-fs-fuse-connections.mount loaded active mounted FUSE Control Fil
e System
sys-kernel-config.mount loaded active mounted Kernel Configura
tion File System
sys-kernel-debug.mount loaded active mounted Kernel Debug Fil
e System
* sys-kernel-tracing.mount masked active mounted /sys/kernel/trac
ing
* sysroot.mount masked inactive dead sysroot.mount
* tmp.mount masked active mounted /tmp
* var-lib-machines.mount masked inactive dead var-lib-machines
.mount
* var-lib-nfs-rpc_pipefs.mount masked active mounted /var/lib/nfs/rpc
_pipefs
* var.mount masked inactive dead var.mount
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SU
B.
SUB = The low-level unit activation state, values depend on unit type
.
19 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
So it masked these virtual file systems which didn't need to be masked:
* proc-fs-nfsd.mount masked inactive dead proc-fs-nfsd.mou
nt
* run-user-1000.mount masked active mounted /run/user/1000
* run-user-42.mount masked active mounted /run/user/42
* sys-kernel-tracing.mount masked active mounted /sys/kernel/trac
ing
* var-lib-machines.mount masked inactive dead var-lib-machines
.mount
* var-lib-nfs-rpc_pipefs.mount masked active mounted /var/lib/nfs/rpc
_pipefs
Lines from /proc/partitions for some of these virtual file systems:
$ egrep '/run/user|/sys/kernel/tracing|/var/lib/nfs/rpc_pipefs' /proc/m
ounts
tmpfs /run/user/42 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656k,
nr_inodes=50664,mode=700,uid=42,gid=42,inode64 0 0
tmpfs /run/user/1000 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656
k,nr_inodes=50664,mode=700,uid=1000,gid=1000,inode64 0 0
none /sys/kernel/tracing tracefs rw,seclabel,relatime 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,
user_id=1000,group_id=1000 0 0
And for contrast the lines from /proc/mounts for disk backed file systems:
$ egrep '^/dev/' /proc/mounts
/dev/sda1 /boot ext4 rw,seclabel,relatime 0 0
/dev/sda2 / btrfs rw,seclabel,relatime,space_cache,subvolid=258,subvol=/
root 0 0
/dev/sda2 /home btrfs rw,seclabel,relatime,space_cache,subvolid=256,subv
ol=/home 0 0
Going back to first principles GParted cares that Systemd doesn't
automount file systems on block devices. So instead only mask mount
units which are on block devices. Where the 'What' property starts
"/dev/".
Systemd maintains hundreds of properties for each unit.
$ systemctl show boot.mount | wc -l
221
The properties of interest for all mount units can be queries like this:
$ systemctl show --all --property=What,Id,LoadState '*.mount'
...
What=sunrpc
Id=var-lib-nfs-rpc_pipefs.mount
LoadState=masked
What=/dev/sda1
Id=boot.mount
LoadState=masked
...
[1] 4c109df9b59e55699bd42023cf4007ee359793e9
Use systemctl runtime mask to prevent automounting (#701676)
[2] 43de8e326a9f6f099e5274619f16039bdc20c1a4
Do not mask virtual file systems when using systemctl (#708378)
Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding
anyway
2021-01-04 Mike Fleetwood <mike.fleetwood@googlemail.com>
Don't try to mask non-existent Systemd \xe2\x97\x8f.service (#129)
With Systemd 246 on Fedora 33, running GParted reports this error and no
longer masks the system mount units:
$ gparted
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
GParted 1.1.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
$ systemctl list-units -t mount --full --all --no-legend
-.mount loaded active mounted Root Mount
boot.mount loaded active mounted /boot
dev-hugepages.mount loaded active mounted Huge Pages Fi
le System
dev-mqueue.mount loaded active mounted POSIX Message
Queue File System
home.mount loaded active mounted /home
proc-fs-nfsd.mount loaded inactive dead NFSD configur
ation filesystem
proc-sys-fs-binfmt_misc.mount loaded inactive dead Arbitrary Exe
cutable File Formats File System
run-user-1000-gvfs.mount loaded active mounted /run/user/100
0/gvfs
run-user-1000.mount loaded active mounted /run/user/100
0
run-user-42.mount loaded active mounted /run/user/42
sys-fs-fuse-connections.mount loaded active mounted FUSE Control
File System
sys-kernel-config.mount loaded active mounted Kernel Config
uration File System
sys-kernel-debug.mount loaded active mounted Kernel Debug
File System
sys-kernel-tracing.mount loaded active mounted Kernel Trace
File System
* sysroot.mount not-found inactive dead sysroot.mount
tmp.mount loaded active mounted Temporary Dir
ectory (/tmp)
var-lib-machines.mount loaded inactive dead Virtual Machi
ne and Container Storage (Compatibility)
var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File
System
* var.mount not-found inactive dead var.mount
^
[Unicode Black Circle character (U+25CF) replaced with star to avoid
making this this commit message Unicode.]
Currently the gparted shell wrapper lists the Systemd mount units and
takes the first space separated column as the unit name. If the LOAD
status of the unit is not "loaded" then Systemd prefixes the name with
an optional Black Circle. Prior to Systemd 246 these extra 2 characters
at the start of the line, including the optional Black Circle, were
suppressed by the --no-legend option, but with Systemd 246 this no
longer happens. As the mount unit names no longer start in the first
character of the line no units are masked. Instead the Unicode Black
Circle character, UTF-8 byte sequence E2 97 8F, is found at the start of
highlighted lines which results in this error:
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
Fix by adding the --plain option to suppress the optional Black Circle
in the systemctl output. Confirmed this option is available in the
oldest supported distributions with Systemd.
RedHat / CentOS 7 Systemd 219 systemctl has --plain option.
Ubuntu 16.04 LTS Systemd 229 systemctl has --plain option.
Closes #129 - Unit \xe2\x97\x8f.service does not exist, proceeding
anyway
2021-01-10 Jordi Mas <jmas@softcatala.org>
Update Catalan translation
2021-01-01 Jordi Mas <jmas@softcatala.org>
Update Catalan translation
2020-11-28 Аляксей <alexey_razumov@tutanota.com>
Update Belarusian translation
2020-11-13 Curtis Gedak <gedakc@gmail.com>
Set default partition alignment to cylinder for amiga partition table (#116)
Closes #116 - Fails to create partitions on disks with Amiga partition
tables using default settings
2020-11-02 Jordi Mas <jmas@softcatala.org>
Update Catalan translation
2020-10-13 Dušan Kazik <prescott66@gmail.com>
Update Slovak translation
2019-12-23 Mike Fleetwood <mike.fleetwood@googlemail.com>
Remove unneeded #include <vector> from TreeView_Detail.h
std::vector<> is no longer used in TreeView_Detail.h since this commit
replaced them:
fae909897e92b55aed0624ec8ccf221806e23ef4
Use PartitionVector class throughout the code (#759726)
2020-09-17 Mike Fleetwood <mike.fleetwood@googlemail.com>
Fix CentOS 7 CI test job failures from empty /etc/machine-id (!62)
Since August 2020, GitLab Continuous Integration test jobs have been
failing on the CentOS 7 image like this from
tests/test_SupportedFileSystems.log:
process 6319: D-Bus library appears to be incorrectly set up; failed to
read machine uuid: UUID file '/etc/machine-id' should contain a hex string of le
ngth 32, not length 0, with no other text
See the manual page for dbus-uuidgen to correct this issue.
D-Bus not built with -rdynamic so unable to print a backtrace
Running main() from test_SupportedFileSystems.cc
DISPLAY=":99"
/usr/bin/xvfb-run: line 181: 6319 Aborted (core dumped)
DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1
Not sure why this has just started failing in the CentOS 7 CI image now,
but the error is widely known [1][2][3][4]. Use
systemd-machine-id-setup to generate a machine ID [5][6]; rather than
dbus-uuidgen [7] as it's designed to integrate into VMs and does the
right thing if a valid machine ID already exists.
[1] Red Hat Bug 598200 - D-Bus library appears to be incorrectly set up;
failed to read machine uuid: UUID file '/var/lib/dbus/machine-id'
https://bugzilla.redhat.com/show_bug.cgi?id=598200
[2] Free Desktop Bug 13194 - When machine-id not found, dbus should not
abort
https://bugs.freedesktop.org/show_bug.cgi?id=13194
[3] D-Bus library appears to be incorrectly set up
https://unix.stackexchange.com/questions/117741/d-bus-library-appears-to
-be-incorrectly-set-up
[4] Generate uuid for container
https://xpra.org/trac/wiki/Usage/Docker/CentOS
[5] CentOS / RHEL 7 : How to Change the machine-id
https://www.thegeekdiary.com/centos-rhel-7-how-to-change-the-machine-id/
[6] man systemd-machine-id-setup
https://man7.org/linux/man-pages/man1/systemd-machine-id-setup.1.html
[7] man dbus-uuidgen
https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html
Closes !62 - Fix CentOS 7 CI test job failures because of zero sized
/etc/machine-id
2020-09-11 Fabio Tomat <f.t.public@gmail.com>
Update Friulian translation
2020-09-06 Aurimas Černius <aurisc4@gmail.com>
Updated Lithuanian translation
2020-08-30 Boyuan Yang <073plan@gmail.com>
Update Chinese (China) translation
2020-07-12 Piotr Drąg <piotrdrag@gmail.com>
Update Polish translation
Fixes https://gitlab.gnome.org/Teams/Translation/pl/-/issues/8
2020-06-26 Baurzhan Muftakhidinov <baurthefirst@gmail.com>
Update Kazakh translation
2020-05-31 Daniel Șerbănescu <daniel@serbanescu.dk>
Update Romanian translation
2019-12-19 Mike Fleetwood <mike.fleetwood@googlemail.com>
Add missing includes into Devices module
2020-05-23 Mike Fleetwood <mike.fleetwood@googlemail.com>
Exclude PipeCapture read NUL byte unit tests in GitLab CI jobs (!60)
These PipeCapture unit tests are also failing, preventing the
ubuntu_test CI job passing:
PipeCaptureTest.ReadEmbeddedNULCharacter
PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character
These tests are also failing locally in both Ubuntu 20.04 LTS and
Fedora 32 VMs, but not in Ubuntu 18.04 LTS or Fedora 31 VMs. As this is
not specifically a Ubuntu docker image update related issue, temporarily
exclude these failing tests.
Closes !60 - Fix GitLab CI job failures following Ubuntu docker image
updates
2020-05-23 Mike Fleetwood <mike.fleetwood@googlemail.com>
Add C++ compiler into GitLab CI Ubuntu image (!60)
Next the Ubuntu image CI job is failing without a C++ compiler like
this:
checking whether to enable maintainer-specific portions of Makefiles...
yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether the C++ compiler works... no
configure: error: in `/builds/mfleetwo/gparted':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
...
ERROR: Job failed: exit code 1
The published "Ubuntu" docker image has been updated to Ubuntu 20.04 LTS
and must no longer include the build tools by default, or not be a
dependency of any of the other installed packages. Explicitly install
build-essential to get the C++ compiler [1]. Also don't list make as
build-essential includes it.
[1] Installing the GNU C compiler and GNU C++ compiler
https://help.ubuntu.com/community/InstallingCompilers
Closes !60 - Fix GitLab CI job failures following Ubuntu docker image
updates
2020-05-22 Mike Fleetwood <mike.fleetwood@googlemail.com>
Prevent tzdata install hang in GitLab CI Ubuntu image (!60)
The Ubuntu based GitLab CI jobs have recently started being terminated
after the default 1 hour timeout. Installing / updating packages in the
image is updating the tzdata package which is prompting for input which
it will never receive, hence the hang. The end of output from the job
looks like this:
Setting up tzdata (2020a-0ubuntu0.20.04) ...
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
Configuring tzdata
------------------
Please select the geographic area in which you live. Subsequent configur
ation
questions will narrow this down by presenting a list of cities, represen
ting
the time zones in which they are located.
1. Africa 4. Australia 7. Atlantic 10. Pacific 13. Etc
2. America 5. Arctic 8. Europe 11. SystemV
3. Antarctica 6. Asia 9. Indian 12. US
Geographic area:
...
ERROR: Job failed: execution took longer than 1h0m0s seconds
This is a well known issue [1][2][3]. Probably occurring now because of
a new release of tzdata not included in the base Ubuntu image we are
using. Fix by telling the underlying dpkg tools this installation is
non-interactive.
[1] Avoiding user interaction with tzdata when installing certbot in a
docker container
https://askubuntu.com/questions/909277/avoiding-user-interaction-with-tz
data-when-installing-certbot-in-a-docker-contai
[2] How to install tzdata on a ubuntu docker image?
https://serverfault.com/questions/949991/how-to-install-tzdata-on-a-ubun
tu-docker-image
[3] apt-get install tzdata noninteractive
https://stackoverflow.com/questions/44331836/apt-get-install-tzdata-noni
nteractive
Closes !60 - Fix GitLab CI job failures following Ubuntu docker image
updates
2020-05-24 Yi-Jyun Pan <pan93412@gmail.com>
Update Chinese (Taiwan) translation
2020-05-04 Dušan Kazik <prescott66@gmail.com>
Update Slovak translation
2020-03-03 Mike Fleetwood <mike.fleetwood@googlemail.com>
Replace TRUE #define with C++ true literal
Everywhere else in the code the lower case true C++ boolean literal is
used. Change this one place where upper case TRUE #define was used to
match.
2020-03-10 Mike Fleetwood <mike.fleetwood@googlemail.com>
Add /dev/disk/by-id/ symlink in CI for test_BlockSpecial
This previous commit [1] excluded unit test
BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches because GNOME
GitLab Docker CI images don't have /dev/disk hierarchy and so no
symbolic links to block devices.
Create the /dev/disk/by-id directory and a symlink for this unit test to
use in the new tests/makedev.sh script.
[1] fe2fc33e67980f0b4a5bba958d257be54715f301
Exclude unit test which fails in Docker CI image (!4)
2020-03-11 Mike Fleetwood <mike.fleetwood@googlemail.com>
Exclude unit tests needing losetup in Docker CI image (!59)
test_SupportedFileSystems is another unit test that has been failing
since 23-Feb-2020 in GNOME GitLab Continuous Integration test jobs.
Fragments from tests/test-suite.log from a failed test CI job:
FAIL: test_SupportedFileSystems
===============================
...
[ RUN ] My/SupportedFileSystemsTest.Create/lvm2pv
test_SupportedFileSystems.cc:387: Failure
Failed
create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSyst
ems.img'
losetup: test_SupportedFileSystems.img: failed to set up loop device: No
such file or directory
create_loopdev(): Losetup failed with exit status 1
create_loopdev(): Failed to create required loop device
Error: Could not stat device - No such file or directory.
test_SupportedFileSystems.cc:446: Failure
Value of: lp_device != NULL
Actual: false
Expected: true
test_SupportedFileSystems.cc:490: Failure
Value of: m_fs_object->create(m_partition, m_operation_detail)
Actual: false
Expected: true
Operation details:
lvm pvcreate -M 2 '' 00:00:00 (ERROR)
WARNING: Failed to connect to lvmetad. Falling back to device scanning
.
Device not found.
detach_loopdev(): Execute: losetup --detach ''
losetup: /dev/: detach failed: Inappropriate ioctl for device
detach_loopdev(): Losetup failed with exit status 1
detach_loopdev(): Failed to detach loop device. Test NOT affected
[ FAILED ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam()
= 20 (64 ms)
...
[ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs
test_SupportedFileSystems.cc:387: Failure
Failed
create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSyst
ems.img'
losetup: test_SupportedFileSystems.img: failed to set up loop device: No
such file or directory
create_loopdev(): Losetup failed with exit status 1
create_loopdev(): Failed to create required loop device
Error: Could not stat device - No such file or directory.
test_SupportedFileSystems.cc:446: Failure
Value of: lp_device != NULL
Actual: false
Expected: true
test_SupportedFileSystems.cc:503: Failure
Value of: m_fs_object->create(m_partition, m_operation_detail)
Actual: false
Expected: true
Operation details:
mkfs.btrfs -L '' '' 00:00:00 (ERROR)
btrfs-progs v4.9.1
See http://btrfs.wiki.kernel.org for more information.
ERROR: failed to check size for : No such file or directory
detach_loopdev(): Execute: losetup --detach ''
losetup: /dev/: detach failed: Inappropriate ioctl for device
detach_loopdev(): Losetup failed with exit status 1
detach_loopdev(): Failed to detach loop device. Test NOT affected
[ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where
GetParam() = 7 (11 ms)
All the test_SupportedFileSystems unit tests which need a loop device
are failing when running losetup like this:
losetup: <IMAGE_NAME>: failed to setup loop device: No such file or dire
ctory
losetup uses /dev/loop-control [1][2] which no longer exists in the
Docker image. However even after creating /dev/loop-control in the
image, losetup continues to fail. Also tried stracing losetup but that
fails like this, presumably because it is not allowed inside the Docker
image:
$ strace losetup --find --show /tmp/disk.img
strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted
+++ exited with 1 +++
For now I have run out of ways to investigate and resolve this, so just
exclude the 12 tests which required loop devices. All the tests still
execute when run locally outside the restricted GNOME GitLab CI Docker
setup.
Closes !59 - Fix GNOME GitLab CI test job failures because of missing
/dev entries
2020-03-08 Mike Fleetwood <mike.fleetwood@googlemail.com>
Create block special devices needed by test_BlockSpecial in GitLab CI jobs (
!59)
From 23-Feb-2020 onwards, GNOME GitLab Continuous Integration test jobs
have been failing running unit tests which previously succeeded. With
some extra debugging added into test_BlockSpecial to print 'bname' and
'bs' values in the failing tests, here are fragments from
tests/test-suite.log for the the test_BlockSpecial failures in a test CI
job:
FAIL: test_BlockSpecial
=======================
...
[ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice
bname="/dev/sr0"
bs=BlockSpecial{"/dev/sr0",0,0}
test_BlockSpecial.cc:218: Failure
Value of: bs.m_major > 0 || bs.m_minor > 0
Actual: false
Expected: true
[ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice (0 ms)
...
[ RUN ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices
bname1="/dev/sr0"
bname2="/dev/sda"
bs1=BlockSpecial{"/dev/sr0",0,0}
bs2=BlockSpecial{"/dev/sda",0,0}
test_BlockSpecial.cc:250: Failure
Value of: bs1.m_major != bs2.m_major || bs1.m_minor != bs2.m_minor
Actual: false
Expected: true
[ FAILED ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices (1
ms)
Contents of /proc/partitions inside the Docker image when this test CI
job failed:
$ cat /proc/partitions
major minor #blocks name
11 0 1048575 sr0
8 0 573367448 sda
8 1 573366407 sda1
And the listing of /dev/:
$ ls -l /dev/
total 0
lrwxrwxrwx 1 root root 11 Mar 3 09:00 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Mar 3 09:00 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Mar 3 09:00 full
drwxrwxrwt 2 root root 40 Mar 3 09:00 mqueue
crw-rw-rw- 1 root root 1, 3 Mar 3 09:00 null
lrwxrwxrwx 1 root root 8 Mar 3 09:00 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 Mar 3 09:00 pts
crw-rw-rw- 1 root root 1, 8 Mar 3 09:00 random
drwxrwxrwt 2 root root 40 Mar 3 09:00 shm
lrwxrwxrwx 1 root root 15 Mar 3 09:00 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Mar 3 09:00 tty
crw-rw-rw- 1 root root 1, 9 Mar 3 09:00 urandom
crw-rw-rw- 1 root root 1, 5 Mar 3 09:00 zero
See how the test_BlockSpecial fixtures are getting major=0 and minor=0
for the block special devices they are testing with. This is happening
because there aren't any entries in /dev for those disks and partitions
listed in /proc/partitions. Assume that Docker in GNOME GitLab has
changed and that unneeded and unwanted devices in /dev are no longer
being created inside images.
In the test CI jobs execute new script, tests/makedev.sh, to create just
the first two block special devices mentioned in /proc/partitions needed
by test_BlockSpecial.
Closes !59 - Fix GNOME GitLab CI test job failures because of missing
/dev entries
2020-01-03 Mike Fleetwood <mike.fleetwood@googlemail.com>
Delete old Fill txtview_device_info_buffer comment
Seems to be referring to how Fill_Label_Device_Info() worked in the
past, but from history before the beginning of the GIT repository.
Remove out of date comment.
2020-02-29 Mike Fleetwood <mike.fleetwood@googlemail.com>
Reliably detect running gpartedbin using pidof (!54)
Debian user reported a bug [1] that when they had PS_FORMAT environment
variable set it prevented GParted running:
# export PS_FORMAT='ruser,uid,pid,ppid,pri,ni,%cpu,%mem,vsz,rss,stat,tty
,start,time,command'
# gparted
The process gpartedbin is already running.
Only one gpartedbin process is permitted.
# echo $?
1
Using ps column 'command' includes the command and all it's arguments,
rather than just the command name as ps displays by default. Thus the
shell wrapper finds the grep command it's using when searching for the
gpartedbin executable.
# ps -e | grep gpartedbin
root 0 26114 14777 19 0 0.0 0.0 112712 940 S+ pts/0
10:42:02 00:00:00 grep --color=auto gpartedbin
Fix by searching for running processes using pidof. pgrep does regular
expression matching where as pidof checks program name is the same [2].
Therefore use of pidof is preferred over pgrep [3].
[1] Debian bug #864932 - gparted fails if PS_FORMAT options are
specified
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864932
[2] Difference between pidof and pgrep?
https://stackoverflow.com/questions/52151698/difference-between-pidof-an
d-pgrep
[3] [PATCH] gparted.in: Use reliable way of detecting gpartedbin process
existence
https://git.alpinelinux.org/aports/tree/community/gparted/gparted.in-Use
-reliable-way-of-detecting-gpartedbin-.patch
Closes !54 - Fix gparted not launching when PS_FORMAT environment
variable set
2020-02-16 Mike Fleetwood <mike.fleetwood@googlemail.com>
Rename local variables to mke2fs_*_ver
To better reflect that they represent the version of mke2fs executable
from the e2fsprogs package, even though the executable is called as
mkfs.ext4.
$ ls -il /sbin/mke2fs /sbin/mkfs.ext*
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mke2fs
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext2
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext3
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext4
$ mkfs.ext4 -V
mke2fs 1.42.9 (28-Dec-2013)
Using EXT2FS Library version 1.42.9
$ mke2fs -V
mke2fs 1.42.9 (28-Dec-2013)
Using EXT2FS Library version 1.42.9
2020-02-14 Mike Fleetwood <mike.fleetwood@googlemail.com>
Simplify sscanf("mke2fs ...") text match
With removal of support for RHEL / CentOS 5 and it's e4fsprogs package
[1][2] it is no longer necessary to accept:
mke4fs 1.41.12 (17-May-2010)
only:
mke2fs 1.42.9 (28-Dec-2013)
[1] 6c4ab5dc28a14f3bef2d1c1a24da219381d513f0
Remove checks for e4fsprogs commands (#794253)
[2] de6e70d933286f3c65187470c9852fb6d8a60a7d
Simplify ext2::get_filesystem_support() with regard ext4 support (#79425
3)
2020-02-16 Mike Fleetwood <mike.fleetwood@googlemail.com>
Raise minimum supported dosfstools to 3.0.18 (!57)
This earlier commit [1] from 2013 recognised the new names for programs
in dosfstools >= 3.0.18, specifically mkfs.fat and fsck.fat. Now that
the oldest supported distributions use dosfstools >= 3.0.18 it is no
longer necessary to support using the old names of mkdosfs and dosfsck,
so remove that code.
Oldest supported Dosfstools
distributions Version
Debian 8 3.0.27
RHEL / CentOS 7 3.0.20
SLES 12 3.0.26
Ubuntu 14.04 LTS 3.0.26
[1] 1ae03dee953f512c0c664369db2d5e5db80b4058
Recognise new dosfstools program names (#704629)
Closes !57 - Raise minimum support dosfstools to 3.0.18 released
2013-06-06
2020-02-04 Mike Fleetwood <mike.fleetwood@googlemail.com>
Remove unused udevinfo from README
Missed removing mention of udevinfo from README when this earlier commit
removed it's use by GParted.
3f15a66291af1f2db142edfe2a9219da219a29d5
Drop use of long ago removed udevinfo
2020-02-03 Mike Fleetwood <mike.fleetwood@googlemail.com>
Wait for udev change on /dev/DISK when erasing signatures (#83)
A user reported that formatting a whole disk device with a file system
failed like this:
Format /dev/sdd as ext4 (ERROR)
+ calibrate /dev/sdd (SUCCESS)
path: /dev/sdd (device)
start: 0
end: 15633407
size: 15633408 (7.45 GiB)
+ clear old file system signatures in /dev/sdd (SUCCESS)
+ write 512.00 KiB of zeros at byte offset 0 (SUCCESS)
+ write 4.00 KiB of zeros at byte offset 67108864 (SUCCESS)
+ write 512.00 KiB of zeros at byte offset 8003780608 (SUCCESS)
+ write 4.00 KiB of zeros at byte offset 8004239360 (SUCCESS)
+ write 8.00 KiB of zeros at byte offset 8004296704 (SUCCESS)
+ flush operating system cache of /dev/sdd (SUCCESS)
+ create new ext4 file system (ERROR)
+ mkfs.ext4 -F -O ^64bit -L '' '/dev/sdd' (ERROR)
mke2fs 1.44.1 (24-Mar-2018)
/dev/sdd is apparently in use by the system; will not make a filesys
tem here!
Opening the whole disk block device exclusively causes mkfs.ext4 to
report that error like this:
# python
>>> import os
>>> f = os.open('/dev/sdb',os.O_RDONLY|os.O_EXCL)
>>> ^Z
[1]+ Stopped python
# mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb'
mke2fs 1.42.9 (28-Dec-2013)
/dev/sdb is apparently in use by the system; will not make a filesystem
here!
# echo $?
1
I have not been able to reproduce this error, but with debugging and
sleeping in GParted, stracing GParted and using 'udevadm monitor' to
watch udev events the following sequence of events is seen:
gparted |format(partition, operationdetail)
gparted | erase_filesystem_signatures(partition, operationdetail)
gparted | get_device(device_path="/dev/sdb", lp_device, flush=false)
gparted | ped_device_get("/dev/sdb")
libparted | open("/dev/sdb", O_RDONLY) = 11
libparted | close(11)
gparted | ped_device_open(lp_device)
libparted | open("/dev/sdb", O_RDWR) = 11
gparted | ped_device_sync(lp_device)
libparted | ioctl(11, BLKFLSBUF)
gparted | ped_device_close()
libparted | close(11)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| UDEV change /devices/.../sdb (block)
gparted | set_partition_type(partition, operationdetail)
gparted | create_filesystem(partition, operationdetail)
gparted | ext2::create(partition, operationdetail)
gparted | FileSystem::execute_command("mkfs.ext4 -F -O ^64bit -L '
' '/dev/sdb')
So it is assumed that the processing of the udev change rule after
closing the block device in erase_filesystem_signatures() overlaps with
the execution mkfs.ext4 and causes the seen error. Fix by waiting for
those udev events to complete as was previously done by commits [1][2]
[3].
Also note that this is specific to creating file systems on and
formatting unpartitioned whole disk devices because set_partition_type()
is a no-operation. Where as on a partitioned device
set_partition_type() calls commit() which already waits for udev rules
to complete [3].
[1] 50c8924a8e4d9cc96a2ea45f13291114402affee
Wait for udev to recreate /dev/PTN entries when querying partition
FSs (!46)
[2] 4f6c312e3bc68cafb5e6035fd4a5b5bbbfcea992
Wait for udev change on /dev/DISK when querying whole device FS
(!46)
[3] 2f53876c0fc8bceddabe739c298e19e7939d9ad7
Wait for the kernel and udev to settle partitions for a second time
(#790418)
Closes #83 - /dev/sdd is apparently in use by the system; will not make
a filesystem here!
2020-02-25 Daniele Forsi <dforsi@gmail.com>
Fix formatting directive in it.po (!58)
Fixes:
(gpartedbin:78003): glibmm-WARNING **: 22:55:05.465: invalid
substitution "%s" in fmt string "percorso: %1 (%s)"
Closes !58 - Fix formatting directive in it.po (!58)
2020-02-26 Nathan Follens <nfollens@gnome.org>
Update Dutch translation
2020-02-23 Daniel Korostil <ted.korostiled@gmail.com>
Update Ukrainian translation
2020-02-04 Daniel Mustieles <daniel.mustieles@gmail.com>
Updated Spanish translation
2020-01-29 Dušan Kazik <prescott66@gmail.com>
Update Slovak translation
2020-01-20 Curtis Gedak <gedakc@gmail.com>
Append -git to version for continuing development
Also fix minor whitespace mistake in NEWS
2020-01-20 Curtis Gedak <gedakc@gmail.com> 2020-01-20 Curtis Gedak <gedakc@gmail.com>
========== gparted-1.1.0 ========== ========== gparted-1.1.0 ==========
2020-01-20 Curtis Gedak <gedakc@gmail.com> 2020-01-20 Curtis Gedak <gedakc@gmail.com>
Update copyright years Update copyright years
2020-01-19 A S Alam <amanpreet.alam@gmail.com> 2020-01-19 A S Alam <amanpreet.alam@gmail.com>
 End of changes. 1 change blocks. 
0 lines changed or deleted 1074 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)