The LUN.target_id parameter points to a NVMe Namespace which starts from
1 and not 0. Fix the document to reflect the same while addressing a
nvme device in the boot parameters
This fixes a bug in the CSS Grid when there is a column and/or row gap,
as previously it would take the index of the incorrect column when
finding the `AvailableSize`.
There is a mild complication in the GridFormattingContext as the
OccupationGrid does not take into account the gap columns and rows that
later appear in the `Vector<TemporaryTrack>` columns and rows. The
PositionedBoxes are kind of a connection between the two, and so it's
now more explicit whether you would like to refer to a column by its
position taking into the gap columns/rows or not.
These symlinks' only purpose was to be copied into the rootfs along with
the rest of Base. Instead of storing symlinks to files that either
don't exist in the Base directory, or point to an absolute path outside
of the serenity folder, move these symlinks into the
build-root-filesystem.sh script.
🏻 - U+1F3FB LIGHT SKIN TONE
🏼 - U+1F3FC MEDIUM-LIGHT SKIN TONE
🏽 - U+1F3FD MEDIUM SKIN TONE
🏾 - U+1F3FE MEDIUM-DARK SKIN TONE
🏿 - U+1F3FF DARK SKIN TONE
This was added in d1de7f7782, but these are not the right code points
(missing U+200D), and we already have a BLACK CAT emoji with the right
code points.
Before, the shading of the Presenter icons was the wrong way round and
the external contrast was not as good as it could be. This has been
rectified and the icons are now light on the left- and dark on the
right-side. Also, they now use the same gray colors as other system
icons, making them sit much more nicely together, and have been
generally improved.
We currently aren't parsing the last line of emoji-serenity.txt because
Core::Stream does not think the last line is readable. We should, of
course, fix Core::Stream. But keeping a trailing newline here is nice
anyways.
This subdirectory is meant to hold all constant data related to the
kernel. This means that this data is never meant to updated and is
relevant from system boot to system shutdown.
Move the inodes of "load_base", "cmdline" and "system_mode" to that
directory. All nodes under this new subdirectory are generated during
boot, and therefore don't require calling kmalloc each time we need to
read them. Locking is also not necessary, because these nodes and their
data are completely static once being generated.
👂 - U+1F442 Ear
Improve + bring colors in line with other body part emojis
👃 - U+1F443 Nose
Improve + bring colors in line with other body part emojis
👅 - U+1F445 Tongue
🤌 - U+1F90C Pinched Fingers
🤘 - U+1F918 Sign of the Horns
The patch also contains modifications on several classes, functions or
files that are related to the `JPGLoader`.
Renaming include:
- JPGLoader{.h, .cpp}
- JPGImageDecoderPlugin
- JPGLoadingContext
- JPG_DEBUG
- decode_jpg
- FuzzJPGLoader.cpp
- Few string literals or texts
Found using git grep -FIn $'\u00a0'
I just got bit by this type of bug in a different project, and was
wondering whether Serenity has this problem, too. See also:
https://dhwthompson.com/2019/my-favourite-git-commit
Currently when trying to use the right-shift on the pt-br layout
it prints a "?" on key-down on top of applying the shift modifier.
This patch removes the unwanted "?".
This filesystem is based on the code of the long-lived TmpFS. It differs
from that filesystem in one keypoint - its root inode doesn't have a
sticky bit on it.
Therefore, we mount it on /dev, to ensure only root can modify files on
that directory. In addition to that, /tmp is mounted directly in the
SystemServer main (start) code, so it's no longer specified in the fstab
file. We ensure that /tmp has a sticky bit and has the value 0777 for
root directory permissions, which is certainly a special case when using
RAM-backed (and in general other) filesystems.
Because of these 2 changes, it's no longer needed to maintain the TmpFS
filesystem, hence it's removed (renamed to RAMFS), because the RAMFS
represents the purpose of this filesystem in a much better way - it
relies on being backed by RAM "storage", and therefore it's easy to
conclude it's temporary and volatile, so its content is gone on either
system shutdown or unmounting of the filesystem.
