Arch Linux User Repository

Using an AUR helper such as yay to build packages including backintime is HIGHLY discouraged. The recommended build method is to use a clean chroot. See: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

I wrote a script that automates much of that called clean-chroot-manager offered here in the AUR.

Please stop posting build failures because you insist on building with yay or other AUR helpers.

@dev_aryoda I do not have oxygen-icons installed on my headless server, and I can build/test fine. (I got some D-Bus warnings, but no errors.) I also tried to uninstall oxygen-icons on my desktop, but I could still build/test fine.

Regarding the failing unit test with QPainter... and QWidget::render... warnings:

The workaround is to install oxygen-icons since the bug is caused by a missing BiT icon (that is why it does not occur on every installation but only where no icon set is installed that is supported by BiT).

For details see: https://github.com/bit-team/backintime/issues/1404#issuecomment-1418180261

I am working an a universal fix for all known (missing/blank) app icon and system tray icon issues and the installation of above icon set is the recommended work-around so far until my fix is released.

Please report here or in the linked Github issue if this works... THX!

@graysky If the users confirm the work-around It would be best to add oxygen-icons to the required dependencies.

@leonardof @scaramanga

Could you please follow these instructions to give me more context about your system which helps me to narrow down the "QWidget::render: Cannot render with an inactive painter" bug? THX a lot!

https://github.com/bit-team/backintime/issues/1404#issuecomment-1416155380

I have opened a new issue at the BiT Github site:

https://github.com/bit-team/backintime/issues/1404

This "ghost" bug was first reported in 2019 and is haunting us since then sporadically (for more details follow above issue)...

Please help to collect more evidences and ways to reproduce it since I still cannot reproduce it (but am quite sure it is related to trying to show the systray icon which is not possible in a console or special DE configurations.

Good news: BiT does still work correctly since the additional Qt5 output ("Cannot render with an inactive painter") is just an INFO but no ERROR...

TLDR:

I cannot reproduce the failing unit test on my Arch VM. Does the unit test still fail when building the package (incl. the check to trigger the unit tests)?

If yes

• please install without executing the unit tests (e. g. via makepkg -sL --nocheck) and

• open a new issue at https://github.com/bit-team/backintime and append the output of backintime --diagnostics and backintime-qt --debug so that I can dig deeper and try to find out what is different to my Arch VM installation

THX a lot!

---- long version ----

Building the latest version 1.3.3-2 throws this unit test error:

FAIL: test_local_snapshot_is_successful (test.test_backintime.TestBackInTime) ... File "/home/myuser/.cache/paru/clone/backintime/src/backintime-8495f9dc3953343a0352bb3ffbdcfab7f93c10ad/common/test/test_backintime.py", line 147, in test_local_snapshot_is_successful AssertionError: ...

The assertion error is caused by an additional unexpected output in the unit test:

QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter

This is a warning that is related to Qt5. Perhaps some dependency is missing...

graysky commented on 2022-12-18 21:43 (UTC) @dev_aryoda - if I build https://github.com/bit-team/backintime/commit/3a56a4cf5ad6185b7d44d5a65ee1c07ae1ef6610 using this PKGBUILD, I see not errors with tests.

If I build BiT directly using the Github clone and our BiT release version (tag v1.3.3 - this is the same version referenced above) with our configure/make/make test procedere I also get NO unit test error.

yochananmarqos commented on 2023-01-10 23:50 (UTC)

The tests work fine for me skipping the test_tools.py unit test:

THX! Strange, the error message is thrown in another unit test file (test_backintime.py). Either an unwanted side effect or not related. Can you still produce the error when executing the test_tools.py again (please provide the stack trace then).

are you building with makepkg or some aur unhelper?

Not using any helper, just git/makepkg/pacman. I have the same error. I'm using yay as AUR helper. I have the same error I'm using pikaur as AUR helper

I have created a fresh Git clone and makepkg -sL succeeds without any check() error (only the expected warnings)...

But I did NOT update my arch installation before that (still on Linux arch-generic 6.0.2-arch1-1 in my VM)...

After updating to arch-generic 6.1.9-arch1-1 `makepkg -SL still succeeds (runs the unit tests successfully)

I even tried it with X11 and wayland...

What I get on wayland is a segmentation fault when exiting backintime-qt (core dumpled) but this looks like another known (but still unsolved) issue with a Qt5 module.

Sorry for being MIA, forgot to turn notifications on. I was using Paru, but makepkg also only worked with the --nocheck flag. That solution is good enough for me right now :)

In general I'm not sure, why tests are run during this build anyway. Thanks for your help.

Thanks @dev_aryoda. Just to confirm, I'm not 100% sure it's dbus; that's just a wild guess since the tests fails via ssh.

I installed BiT fine locally, and then tried to build/test again over ssh. This again failed, so not sure what's going on there.

If you have trouble reproducing any of this, I'm happy to test for you in the future. If you prefer, happy to continue this conversation at Github.

=EDIT= Not sure that it's just ssh. Tested on another system via ssh and tests pass fine.

I investigated this issue more, and there was the suggestion (by @dev_aryoda?) that dbus permissions might be to blame.

Yes, the DBus chicken-egg bug may be to blame but I thought I have already fixed this.

Background:

Some unit tests required that the BiT DBus service is already installed and running to succeed but the BiT DBus service is only installed AFTER running the unit tests.

If you install anyhow (ignoring the failing test) and run the unit tests again they should work. Any further update should also work because the BiT DBus service is still running so this unit test problem occurred only for first time installations.

Your failing unit test is still on my TODO list (pos 5 currently on my dynamic list ;-) to identify and fix the problem (if not already done).

I didn't think it was a good idea to install backup software that was failing tests, so I wanted to make sure they all passed. I investigated this issue more, and there was the suggestion (by @dev_aryoda?) that dbus permissions might be to blame. I had previously been sshing into the laptop I was attempting to upgrade, but I tried building directly from the machine itself. This solved the problem for me.

The tests work fine for me skipping the test_tools.py unit test:

  cd "$_pkgname-$_commit/common"

  # Skip test_tools.py unit test
  sed -i '/test_tools.py/d' Makefile

  # Set HOME to isolate some tests, which accesses files in ~/.ssh/, etc.
  HOME=tmp make test-v