Those are not always present in the device string.
Guidance was taken from the usage on vendor websites.
NVIDIA actually has the rights to GTX™ but doesn’t seem to use it,
in contrast to RTX™.
This made everything AMD lower case after the second word
and is likely unintentional for something like EPYC™.
e.g. was
AMD Ryzen threadripper 1950x 16-core processor
AMD Radeon rx 580 series
Ignored in Meson < 0.60.0, deprecated since 0.60.1 and fatal since 0.61.0.
panels/applications/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/background/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/camera/meson.build:10:5: ERROR: Function does not take positional arguments.
[...]
The part where this (currently disabled) test is added, is currently
hidden behind #if 0, so hide the test function as well. Otherwise the
compiler complains that the function isn't used.
Sometimes ninja decides to compile tests/interactive-panels/main.c,
which requires shell/resources.h, before shell/resources.h is generated.
The fix is to use 'sources' argument of declare_dependency to properly
declare the dependency on generated headers.
A fix for tests/datetime and panels/datetime is also included in the
commit to fix a similar problem.
Closes https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/472
This is solely used for filtering by unittest, however, if it is
missing, then unittest will fail. So generate a reasonable name (which
is unfortunately not identical to the real name of the attribute).
The purpose of this interactive test is to be able to
prototype new features for CcPanel without having to
adapt existing panels.
Three test panels were added as part of this initial
patch:
* Dynamic panels: panel exercising the ability to
show and hide itself at runtime.
* Header: panel that embeds a header widget.
* Static Initializer: panel that sets a static init
function to run at startup.
They're broken on my computer, and Python does a really
terrible job at communicating why. So after 8 hours of
debugging, I decided this is just a lost battle to me
and not important enough.
The timezone information is allocated with `tz_info_from_location` but
never deallocated.
LeakSanitizer complains about this memory leak.
```
Direct leak of 13568 byte(s) in 424 object(s) allocated from:
/build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:95
#1 0x7f63899bab21 in g_malloc0 (/usr/lib/libglib-2.0.so.0+0x51b21)
../tests/datetime/test-timezone-gfx.c:30
#3 0x7f63899dc76a (/usr/lib/libglib-2.0.so.0+0x7376a)
```
The directory opened with `g_dir_open` is never closed, so LeakSanitizer
complains about a memory leaks.
```
Direct leak of 8 byte(s) in 1 object(s) allocated from:
/build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7f2012908ac9 in g_malloc (/usr/lib/libglib-2.0.so.0+0x51ac9)
#2 0x7f2012922aac in g_memdup (/usr/lib/libglib-2.0.so.0+0x6baac)
#3 0x7f20128ed2d5 (/usr/lib/libglib-2.0.so.0+0x362d5)
#4 0x7f20128ed338 in g_dir_open (/usr/lib/libglib-2.0.so.0+0x36338)
../tests/datetime/test-endianess.c:29
#6 0x7f201292a76a (/usr/lib/libglib-2.0.so.0+0x7376a)
#7 0x7f201292a69a (/usr/lib/libglib-2.0.so.0+0x7369a)
(/usr/lib/libglib-2.0.so.0+0x73951)
#9 0x7f201292a972 in g_test_run (/usr/lib/libglib-2.0.so.0+0x73972)
#10 0x560ad630cbff in main ../tests/datetime/test-endianess.c:66
```
Python isn't always installed in /usr/bin. If we hard-code the path,
these tests will fail on *BSD because they install python in different
prefixes such as /usr/local and /usr/pkg.
Also wait for the connection-added signal instead of only waiting for the
property notification for the connections. While not neccessary, this is
more correct.
