A theme is supposed to be placed in $HOME/.config/bashtop/themes or $HOME/.config/bashtop/user_themes But actually, bashtop seems to look in HOME/.config/bashtop

Makes sense. Thanks.

Oh, ok, so it is supposed to specify a prefix. color_theme="themes/default_black"

Ok. Thanks.

If I set a theme in ~/.config/bashtop/bashtop.cfg color_theme="default_black"

Here:

    494         #* Check if theme set in config exists and source it if it does
    495         if [[ -n ${color_theme} && ${color_theme} != "Default" && -e "${config_dir}/${color_theme%.theme}.theme" ]]; th        en 
    496                 # shellcheck source=/dev/null
    497                 source "${config_dir}/${color_theme%.theme}.theme"
    498                 sourced=1
    499         else
    500                 color_theme="Default"
    501         fi

A theme is supposed to be placed in $HOME/.config/bashtop/themes or $HOME/.config/bashtop/user_themes But actually, bashtop seems to look in HOME/.config/bashtop

GNOME 3.36.3 on Fedora.

The window title bar is black.

Oh, solution was pretty simple: cat /dev/null > data/application.css before building.

Thanks. It works.

GNOME 3.36.3 on Fedora.

The window title bar is black.

On Fedora 31, building beta4, I get

../src/API/VersionInfo.vala:17.26-17.35: error: The name `parse' does not exist in the context of `uint'
            info.major = uint.parse(parts[0]);
                         ^^^^^^^^^^
../src/API/VersionInfo.vala:20.26-20.35: error: The name `parse' does not exist in the context of `uint'
            info.minor = uint.parse(parts[1]);
                         ^^^^^^^^^^
../src/API/VersionInfo.vala:23.26-23.35: error: The name `parse' does not exist in the context of `uint'
            info.patch = uint.parse(parts[2]);
                         ^^^^^^^^^^

beta3 was building fine.

As reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1843398

On Fedora 32, let's assume a rule like this:

$ firewall-cmd --zone=FedoraWorkstation --permanent --add-rich-rule='rule source mac="11:22:33:44:55:66" reject' success

But reloading with firewall-cmd --reload lead to a series of errors as per the attached file, starting with

Error: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: Could not process rule: No such file or directory

The same steps on Fedora 31 seem to work.

$ sudo firewall-cmd --zone=FedoraWorkstation --list-rich-rules rule source mac="11:22:33:44:55:66" drop

In addition, inserting that rule, firewalld is unable to restart. The only way to solve the issue is manually editing the zone file in /etc/firewalls/zones

Here attached some more outputs, including versions of packages.

root.log build.log

=================================== FAILURES ===================================
_____________ TestNumpy_PaletteColor.test_invalid_bit_depth_raises _____________

self = <pydicom.tests.test_handler_util.TestNumpy_PaletteColor object at 0x7f017d5c1df0>

    def test_invalid_bit_depth_raises(self):
        """Test that an invalid bit depth raises an exception."""
        ds = dcmread(PAL_08_256_0_16_1F)
        ds.RedPaletteColorLookupTableDescriptor[2] = 15
        msg = (
            r'data type "uint15" not understood'
        )
        with pytest.raises(TypeError, match=msg):
>           apply_color_lut(ds.pixel_array, ds)

pydicom/tests/test_handler_util.py:951: 
...
self = <pydicom.tests.test_handler_util.TestNumpy_PaletteColor object at 0x7f017d5c1df0>

    def test_invalid_bit_depth_raises(self):
        """Test that an invalid bit depth raises an exception."""
        ds = dcmread(PAL_08_256_0_16_1F)
        ds.RedPaletteColorLookupTableDescriptor[2] = 15
        msg = (
            r'data type "uint15" not understood'
        )
        with pytest.raises(TypeError, match=msg):
>           apply_color_lut(ds.pixel_array, ds)
E           AssertionError: Pattern 'data type "uint15" not understood' does not match "data type 'uint15' not understood"

pydicom/tests/test_handler_util.py:951: AssertionError

Describe the bug test_storescu.py test failed

I get a bunch of

E: Bad DICOM file: /home/user/dev/pynetdicom-1.5.0/pynetdicom/apps/tests/../../__init__.py
E: Bad DICOM file: /home/user/dev/pynetdicom-1.5.0/pynetdicom/apps/tests/../../__main__.py
...

It seems because LIB_DIR = os.path.join(APP_DIR, '../') points to /home/user/dev/pynetdicom-1.5.0/pynetdicom/apps/tests/../../ instead of /home/user/dev/pynetdicom-1.5.0/pynetdicom/apps/tests/../../tests/dicom_files

Expected behavior Test passed

Steps To Reproduce pytest -k "test_storescu.py"

Describe the bug Almost all of the test_qrscp_echo.py fail.

pynetdicom/apps/tests/test_qrscp_echo.py:103: AssertionError
...
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) unable to open database file
(Background on this error at: http://sqlalche.me/e/e3q8)

Expected behavior Test passed.

Steps To Reproduce Run pytest -k test_qrscp_echo.py

Your environment Fedora 32.

platform linux -- Python 3.8.3, pytest-4.6.9, py-1.8.0, pluggy-0.13.0 -- /usr/bin/python3
using: pytest-4.6.9 pylib-1.8.0
setuptools registered plugins:
  pyfakefs-3.5.8 at /usr/lib/python3.8/site-packages/pyfakefs/pytest_plugin.py

Linux-5.6.14-300.fc32.x86_64-x86_64-with-glibc2.2.5

Python  3.8.3 (default, May 15 2020, 00:00:00) 
[GCC 10.1.1 20200507 (Red Hat 10.1.1-1)]

pydicom  2.0.0

pynetdicom  1.5.0

While middle click works on Fedora 31 with terminator-1.92 The same issue is still present on Fedora 32