bat (from bacula-console-qt package) behaves strangly, showing menus missing
information etc, and it goes away after some clicking, but is nevertheless
very annoying.

For example, you select a "Media" on the left pane, and enter some search
filter at the top and click "apply" button to get a list of media.  Double
click on one media and new "Media Info" subwindows opens.  If you right-click
on that "Media Info" in right pane, you get only submenu giving only "Undock
Media Info Window" option. That is wrong, you should also get "Close Page"
option in addition in that submenu.

If you however left-click first on "Media" and then right-click on "Media Info",
you will get both options.

That happens with a lot of other options too. According to posts on bacula
users lists, it is probably due to wrong version of Qt used. Bat will
apperently build seemlessly OK, but it will function is such broken
behaviours.

"Release Notes for Bacula 5.0.1" on http://www.bacula.org/en/?page=news say

"For Packagers:
[...]

3.  Bat should be built on every platform that is capabable of running Qt.
However, the Qt code is changing rather quickly and is not always
compatible from version to version.  We have built and verified bat on Qt
4.3.4.  We strongly recommend that you do not build and distribute bat with
any other version of Qt unless you personally test it.  To build against Qt
4.3.4, download the depkgs-qt package from the Bacula Source Forge download
location, read the README file and follow the instructions.

If you are building for Bacula version 5.0.0, please ensure that you do not
have qmake-qt4 loaded on your system.  If you do, either remove it or
rename it before trying to build bat.  If you do not, bat will probably be
built using the shared objects on your system.  For Bacula 5.0.1 and later,
this problem (bug) does not exist.

depkgs-qt does not install Qt on your system, nor does it interfere with
you having any other version of Qt installed on your system.  Once you
build bat with depkgs-qt, it should *not* use the Qt shared objects, but
rather they will be linked into the program.  After fully installing bat
(make install), you can run "ldd bat" to see what shared objects it will
use.  If any Qt shared objects are referenced, something has gone wrong."

So bacula-console-qt should probably be built as explained statically against
Qt 4.3.4, instead of Qt 4.6.3 (or the code should be fixed to work correctly
with different Qt versions).

tags 593732 upstream help

Debian doesn't ship qt 4.3.4  at all, just 4.6.3.  Statically linking
against an old version would be a significant nightmare, and would have
concerns relating to availability of security and bugfix updates.  I
certainly don't want to go down that road.

Really, the qt console ought to be fixed to work with 4.6.3.  I don't
have the time to do that myself, though, and really it's an upstream
bug.  It would probably be best if they hear this from a user such as
yourself.  They will have to do this sometime anyhow, as qt 4.3 will
become increasingly difficult to find in the future.

Upstream claims in https://gitlab.bacula.org/bacula-community-edition/bacula-community/-/issues/2248
that this problem is gone.

If the problem reappears, please reopen the bug and also reopen the
upstream bug (or file a new one).

Chris

Hi Chris,

Chris Hofstaedtler wrote:

thanks for triaging bugs. If you (or someone else) want(s) to help with
this bug, please confirm it's status by following the steps to reproduce
it.

At the time upstream closed the bug, I considered it to be very unlikely
that it's fixed, because there were no changes to bat between 9.0.7 and
9.0.8 and we were using a newer version of QT than upstream (4.8
vs. 5.10.1). See the upstream bug for context. Therefore I consider that
the bug is still there until confirmed otherwise.

Regards,

Carsten

Hello Carsten,

thank you for the feedback.

With this explanation I would suggest removing the "forwarded"
status, as at least I understand it to mean: upstream was informed
about the bug and will hopefully do something about it.
Given upstream closed it, I find this unlikely, and as you said,
action on the Debian-side is needed.

Chris

Hi Chris,

Chris Hofstaedtler <zeha@debian.org> writes:

if we remove the forwarded status, information about the corresponding
upstream bug will be less readily available. I think we now have enough
context in the debian bug so that readers can understand the current
status.

Regards

Carsten