bootgrid: maintain scrolling position for both datatree and command actions. Closes https://github.com/opnsense/core/issues/9151
The usage of scrollToRow has been considered, but this contains
too much magic causing all kinds of jumps in scroll position,
causing a user to lose track of the changes they made. The only
downside to this is that when a datatree is expanded at the bottom
of a grid, the associated rows aren't immediately visible until
manually scrolled to.
(cherry picked from commit 75e60e85194e7f2bf7e20e3891743ce801e05820)
dashboard:gauge improvements (#10063)
Closes: #8356
*Makes the disk widget become table/bars from grid 2 size onwards
*Adds disk free/used size on the gauge
*Removes parentheses from the memory widget
---------
Co-authored-by: Fabian Rodriguez <317514+MagicFab at users.noreply.github.com>
(cherry picked from commit 7f3bcf5b787145b7cf185854758c3cddefdf1971)
[OFFLOAD][L0] Remove dependence from level zero headers for dlopen build (#189120)
Adds the subset of the Level Zero headers necessary to compile the
plugin when built with dlopen support.
Disclaimer: The headers were mostly generated by Claude.
Scripts: widgets without endpoint access exist now
(Likely the right fix: just print as informational message)
(cherry picked from commit 4d3601d5ca9bf56ac852ad6cd9e120ee6f52fbd3)
bootgrid: set visibility hidden for base_bootgrid_table
Since the structure is used to initialize the bootgrid, we shouldn't render
the original structure possibly causing a flash of content.
(cherry picked from commit 9861da22a25bed9dedb5d577bc38d9bc7ed381a4)
unbound: limit duckdb to a single thread in write mode to reduce logger memory usage
After some testing, it seems the duckdb python API has a tendency to
leak (up to a cap), which seems to be mitigated when we limit to a single thread.
Further testing shows that the single logger.py process doesn't
use parallelization when appending dataframes to the db instance
and as such multiple threads are useless to begin with. The heavier
actions are the read actions, which are separate short-lived processes
and do not suffer from the same issue and likely do require duckdb
parallelism to perform properly, so apply the single thread only to
writers.
(cherry picked from commit 5e781d8321e7b10b0b627bd1e2917cd23a343830)
firmware: repeat the update after pkg reinstall
It appears that the package manager lost a number of tricks
over the years so now we add more manual labor to do what
we expect of it.
(cherry picked from commit c0d5331e1fe7d974a8a153b9d67239b4c3d251a0)
mvc: BaseField: add setValues() for generic use
A small follow-up to make setValues() work like getValues()
including stripping empty values. Works from everywhere now
and adds a few tests in order to make sure it will keep working.
(cherry picked from commit aefe80cdd8168f26401ab85456c6632c6a259830)
(cherry picked from commit 0f092c3d7d558fdae0925bc36fea616473277369)
mvc: BaseListField replace empty check with isSet so a 0 value is considered a non empty selection (#10047)
(cherry picked from commit fff53c467fca07dd43ccb0568f4702dc2ca42d87)
kea: move pool-in-subnet validation logic mostly to KeaPoolsField; closes #10040
While here use getValues() consistently and move the trim() calls to the
latest point in time to avoid generalized trimming of input (the subnet
notation isn't allowed to be trimmed).
An alternative would have been to allow " ?- ?" as a split-regex since the
trim() itself will allow the leading an trailing whitespaces of the pool line,
too.
Suggested by: @Astranox
(cherry picked from commit 9ed851330086919bb7f6e2185ff46a1ea0986a6e)
(cherry picked from commit f5c3fb7c75dd0ddc9d2205e7616ee6b65bdb51b2)
[LLD] [COFF] Fix crashes for conflicting exports with -export-all-symbols (#190492)
Commit adcdc9cc3740adba3577b328fa3ba492cbccd3a5 (since LLD 17) added a
warning message if there are conflicting attempts to export a specific
symbol.
That commit missed one source of exports, from the LLD specific
-export-all-symbols flag (which only has an effect in mingw mode).
To trigger this case, one needs to have an export set by a def file,
combined with the -export-all-symbols flag (which attempts to export all
global symbols, despite explicit exports through embedded directives or
a def file).
To trigger the warning (and the previous crash), one would have to have
some difference between the export produced by -export-all-symbols and
the one from the def file. That difference could be e.g. that the def
file contained an explicit ordinal, or that the def file lacked a DATA
marking for a symbol that the automatic export of all symbols decides to
[4 lines not shown]
[LLD] [COFF] Remove a now incorrect comment in a test. NFC. (#190489)
This comment was added in 26572002749ee2e7d734e4e0aed4cca0e1c623c3 in
2018. Later in 8f540dad6120d00e3ad896b98cd32bcf00623ccd in 2020, the
LLVM MC layer was adjusted to do essentially the same as GNU binutils
do.
Therefore, I think that this test now technically could be done with
object files generated by llvm-mc as well, instead of bundled binary
object files.
