Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644566 - <app-backup/bacula-9.0.6-r1 optionally depends on deprecated Qt4
Summary: <app-backup/bacula-9.0.6-r1 optionally depends on deprecated Qt4
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Thomas Beierlein
URL:
Whiteboard:
Keywords:
Depends on: 651078
Blocks: qt4-removal qt4-r2-removal 655382
  Show dependency tree
 
Reported: 2018-01-14 16:23 UTC by Andreas Sturmlechner
Modified: 2018-05-11 17:51 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
INCOMPLETE Patch to bacula-9.0.6 ebuild to update to EAPI 6 and add support for building with Qt5 (bacula-9.0.6.ebuild.diff,5.78 KB, patch)
2018-02-07 19:15 UTC, Phil Stracchino (Unix Ronin)
Details | Diff
Patch to fix a missing include in src/qt-console/pages.h (bacula-9.0.6-fix-pages-h-qt-includes.patch,305 bytes, patch)
2018-02-09 14:36 UTC, Phil Stracchino (Unix Ronin)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sturmlechner gentoo-dev 2018-01-14 16:23:50 UTC
Qt4 is dead and going away, if upstream is not porting to Qt5 maybe it is time to drop that option.
Comment 1 Andreas Sturmlechner gentoo-dev 2018-01-14 16:35:40 UTC
Debian's bug is mentioning a Qt5 patch in upstream repository that is not yet ready:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874836#10
Comment 2 Thomas Beierlein gentoo-dev 2018-01-15 11:57:25 UTC
Yes, As far as I understood, the migration to QT5 is not quite ready. 

I will look into it and see what can be done.
Comment 3 Phil Stracchino (Unix Ronin) 2018-02-07 19:15:26 UTC
Created attachment 518498 [details, diff]
INCOMPLETE Patch to bacula-9.0.6 ebuild to update to EAPI 6 and add support for building with Qt5

Bacula-9.0.6 actually does have Qt5 support, with a couple of minor glitches, but the ebuild does not support it.  I have a 90% complete update of the bacula-9.0.6 ebuild which adds a qt5 USE and allows building against Qt5.  It also updates the ebuild to EAPI 6.

In the process, this ebuild update adds a patch to fix a missing include in src/qt-console/pages.h which causes a build failure against Qt5.

OUTSTANDING ISSUES:

1.  The build does not work properly unless QT_SELECT=5 is set in the environment.  I am uncertain of the correct way to do this.

2.  Something is going wrong with installation; the temporary libtool wrapper script src/qt-console/bat is never replaced in the install image with the actual bat binary src/qt-console/.libs/bat.  I have not fixed this because I have been unable to find where that replacement should actually be happening, and therefore do not know what the correct fix is.
Comment 4 Phil Stracchino (Unix Ronin) 2018-02-07 19:17:11 UTC
Forgot to add:

If src/qt-console/.libs/bat is moved to src/qt-console BEFORE executing the ebuild install phase, this DOES produce a fully functional Qt5 bat binary.
Comment 5 Phil Stracchino (Unix Ronin) 2018-02-09 14:36:21 UTC
Created attachment 518734 [details, diff]
Patch to fix a missing include in src/qt-console/pages.h

Forgot to add this patch the other day.  I have confirmation from elsewhere that this fixes the Qt5 qt-console compile problems on both Fedora and Debian as well as Gentoo.
Comment 6 Thomas Beierlein gentoo-dev 2018-02-10 16:02:41 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #3)
> Created attachment 518498 [details, diff] [details, diff]
> INCOMPLETE Patch to bacula-9.0.6 ebuild to update to EAPI 6 and add support
> for building with Qt5
> 
> Bacula-9.0.6 actually does have Qt5 support, with a couple of minor
> glitches, but the ebuild does not support it.  I have a 90% complete update
> of the bacula-9.0.6 ebuild which adds a qt5 USE and allows building against
> Qt5.  It also updates the ebuild to EAPI 6.
> 
Hi Phil,

thanks for looking into this.

> In the process, this ebuild update adds a patch to fix a missing include in
> src/qt-console/pages.h which causes a build failure against Qt5.
> 
I did pick up your patches with as well as without the migration to EAPI=6 for tests.

> OUTSTANDING ISSUES:
> 
> 1.  The build does not work properly unless QT_SELECT=5 is set in the
> environment.  I am uncertain of the correct way to do this.
>
It seems to work here without having QT_SELECT in the environment.
 
> 2.  Something is going wrong with installation; the temporary libtool
> wrapper script src/qt-console/bat is never replaced in the install image
> with the actual bat binary src/qt-console/.libs/bat.  I have not fixed this
> because I have been unable to find where that replacement should actually be
> happening, and therefore do not know what the correct fix is.

I can not reproduce this behaviour here. I see the bat wrapper in src/qt-console with around 6k size. There is the ~24M bat executable in .libs/bat and finally a ~1.5M stripped executable in the install image.

I still have to do further tests as the build script shows a compile against installed qt4 tools and headers. I am not sure if it is only a false flag.
Comment 7 Phil Stracchino (Unix Ronin) 2018-02-10 16:35:16 UTC
(In reply to Thomas Beierlein from comment #6)
> (In reply to Phil Stracchino (Unix Ronin) from comment #3)
> > Created attachment 518498 [details, diff] [details, diff] [details, diff]
> > INCOMPLETE Patch to bacula-9.0.6 ebuild to update to EAPI 6 and add support
> > for building with Qt5
> > 
> > Bacula-9.0.6 actually does have Qt5 support, with a couple of minor
> > glitches, but the ebuild does not support it.  I have a 90% complete update
> > of the bacula-9.0.6 ebuild which adds a qt5 USE and allows building against
> > Qt5.  It also updates the ebuild to EAPI 6.
> > 
> Hi Phil,
> 
> thanks for looking into this.
> 
> > In the process, this ebuild update adds a patch to fix a missing include in
> > src/qt-console/pages.h which causes a build failure against Qt5.
> > 
> I did pick up your patches with as well as without the migration to EAPI=6
> for tests.
> 
> > OUTSTANDING ISSUES:
> > 
> > 1.  The build does not work properly unless QT_SELECT=5 is set in the
> > environment.  I am uncertain of the correct way to do this.
> >
> It seems to work here without having QT_SELECT in the environment.
>  
> > 2.  Something is going wrong with installation; the temporary libtool
> > wrapper script src/qt-console/bat is never replaced in the install image
> > with the actual bat binary src/qt-console/.libs/bat.  I have not fixed this
> > because I have been unable to find where that replacement should actually be
> > happening, and therefore do not know what the correct fix is.
> 
> I can not reproduce this behaviour here. I see the bat wrapper in
> src/qt-console with around 6k size. There is the ~24M bat executable in
> .libs/bat and finally a ~1.5M stripped executable in the install image.
> 
> I still have to do further tests as the build script shows a compile against
> installed qt4 tools and headers. I am not sure if it is only a false flag.


Some of this — including the QT_SELECT issue — quite possibly occurs only if you have both Qt4 and Qt5 components installed.  Which I know is not an ideal situation, and I've been doing my very best to get rid of Qt4 entirely, but unfortunately even after this Bacula Qt5 fix I still have one package — app-mobilephone/qtadb — with hard dependencies on Qt4 that I cannot fix except by uninstalling it, and I need qtadb because there is no other adb client available on Linux for doing LineageOS installs.
Comment 8 Andreas Sturmlechner gentoo-dev 2018-02-10 16:39:19 UTC
Having Qt4 and Qt5 installed at the same time is a normal situation.

You can test this by 'export QT_SELECT=4' before build.
Comment 9 Thomas Beierlein gentoo-dev 2018-02-10 16:41:21 UTC
(In reply to Thomas Beierlein from comment #6)
> (In reply to Phil Stracchino (Unix Ronin) from comment #3)

A quick answer to my own questions.... See below.

> 
> > OUTSTANDING ISSUES:
> > 
> > 1.  The build does not work properly unless QT_SELECT=5 is set in the
> > environment.  I am uncertain of the correct way to do this.
> >
> It seems to work here without having QT_SELECT in the environment.
>  
Not quite. Without QT_SELECT it compiles against qt4 (reason below)

> 
> I still have to do further tests as the build script shows a compile against
> installed qt4 tools and headers. I am not sure if it is only a false flag.

The original configure script call qmake directly which is linked to qtchooser. The last one selects if build is done against qt4 or qt5 which is controlled by the above mentioned QT_SELECT.


And Phil QT_SELECT can be controlled from within the ebuild. We just have to add

 'export QT_SELECT=qt5' 

to src_prepare() function. I am just testing it.

Btw, as QT4 will go soon I will drop the qt4 support from the ebuild completely.
Comment 10 Phil Stracchino (Unix Ronin) 2018-02-10 16:53:27 UTC
(In reply to Thomas Beierlein from comment #9)

> Btw, as QT4 will go soon I will drop the qt4 support from the ebuild
> completely.

Yeah, I didn't quite want to go that far myself at this point until the other issues were resolved, though I thought about doing so.
Comment 11 Larry the Git Cow gentoo-dev 2018-02-10 19:11:48 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=832f2031321658a8fd0e896f51dd3a93dcf07d3f

commit 832f2031321658a8fd0e896f51dd3a93dcf07d3f
Author:     Thomas Beierlein <tomjbe@gentoo.org>
AuthorDate: 2018-02-10 19:03:54 +0000
Commit:     Thomas Beierlein <tomjbe@gentoo.org>
CommitDate: 2018-02-10 19:10:42 +0000

    app-backup/bacula: Switch to using Qt5
    
    - Drop Qt4 deps and switch to using Qt5
    - Switch to EAPI=6
    
    Thanks Phil Stracchino (phils@caerllewys.net) for providing the critical
    informations.
    
    Bug: https://bugs.gentoo.org/644566
    Package-Manager: Portage-2.3.24, Repoman-2.3.6

 app-backup/bacula/bacula-9.0.6-r1.ebuild           | 426 +++++++++++++++++++++
 .../bacula-9.0.6-fix-pages-h-qt-includes.patch     |  15 +
 2 files changed, 441 insertions(+)}
Comment 12 Thomas Beierlein gentoo-dev 2018-02-10 19:14:42 UTC
Fixed version 9.0.6-r1 in tree.

Phil, please test and report back. Thanks.
Comment 13 Phil Stracchino (Unix Ronin) 2018-02-10 20:40:25 UTC
(In reply to Thomas Beierlein from comment #12)
> Fixed version 9.0.6-r1 in tree.
> 
> Phil, please test and report back. Thanks.

Does not seem to be available to me yet.  Do I need to download directly?
Comment 14 Thomas Beierlein gentoo-dev 2018-02-10 20:55:57 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #13)
> (In reply to Thomas Beierlein from comment #12)
> > Fixed version 9.0.6-r1 in tree.
> > 
> > Phil, please test and report back. Thanks.
> 
> Does not seem to be available to me yet.  Do I need to download directly?

The sync process takes normally some 2..4 h. So please just do a sync in some hours and try again.
Comment 15 Phil Stracchino (Unix Ronin) 2018-02-10 21:25:11 UTC
OK, my automatic sync tonight ought to catch it and I'll check it out tomorrow morning.
Comment 16 Phil Stracchino (Unix Ronin) 2018-02-11 18:12:12 UTC
OK, so let's see.
Server 'narn', client only, Qt not used:  Clean build and merge, no issues.
Server 'minbar', client and director, Qt not used:  Clean build and merge, no issues.

Workstation 'babylon5', client, storage and qt-console, USE=Qt5:  Libtool temporary 'bat' script was installed instead of the stripped 'bat' binary.
Comment 17 Phil Stracchino (Unix Ronin) 2018-02-11 18:21:16 UTC
Ran a manual ebuild and confirmed that the 'bat' Qt console is built correctly, and *if manually copied* from src/qt-console/.libs to src/qt-console before the 'install' step, is correctly stripped and installed, but just running an emerge that copy/move operation does not happen.  If manually copied, the resulting binary is correctly built, correctly linked, and works perfectly.

Perhaps the ebuild should just manually perform that copy as the first step in install( ) ?
Comment 18 Thomas Beierlein gentoo-dev 2018-02-11 18:58:09 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #17)
> Ran a manual ebuild and confirmed that the 'bat' Qt console is built
> correctly, and *if manually copied* from src/qt-console/.libs to
> src/qt-console before the 'install' step, is correctly stripped and
> installed, but just running an emerge that copy/move operation does not
> happen.  If manually copied, the resulting binary is correctly built,
> correctly linked, and works perfectly.
> 
> Perhaps the ebuild should just manually perform that copy as the first step
> in install( ) ?

Very weird. I do not understand what is going on.
That copy by hand is not needed here. It installs the bat binary without problems. 

I will test on different machines tomorrow.

Can you please give me your emerge info for the machine which does not build correctly.
Comment 19 Phil Stracchino (Unix Ronin) 2018-02-11 19:13:56 UTC
babylon5:alaric:~:1 $ emerge --info
Portage 2.3.19 (python 3.5.4-final-0, default/linux/amd64/17.0/desktop, gcc-6.4.0, glibc-2.25-r10, 4.15.2-gentoo-babylon5 x86_64)
=================================================================
System uname: Linux-4.15.2-gentoo-babylon5-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.4.1
KiB Mem:    16402716 total,   1341356 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Sun, 11 Feb 2018 07:00:01 +0000
Head commit of repository gentoo: d2fa0efd4c23a0131cea1b5e7f8e850104079426
sh bash 4.4_p12
ld GNU ld (Gentoo 2.29.1 p3) 2.29.1
ccache version 3.2.4 [disabled]
app-shells/bash:          4.4_p12::gentoo
dev-java/java-config:     2.2.0-r3::gentoo
dev-lang/perl:            5.24.3::gentoo
dev-lang/python:          2.7.14-r1::gentoo, 3.5.4-r1::gentoo, 3.6.3-r1::gentoo
dev-util/ccache:          3.2.4::gentoo
dev-util/cmake:           3.9.6::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.4.1-r2::gentoo
sys-apps/openrc:          0.34.11::gentoo
sys-apps/sandbox:         2.12::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.11.6-r2::gentoo, 1.15.1-r1::gentoo
sys-devel/binutils:       2.29.1-r1::gentoo
sys-devel/gcc:            6.4.0-r1::gentoo
sys-devel/gcc-config:     1.8-r1::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1::gentoo
sys-kernel/linux-headers: 4.15::gentoo (virtual/os-headers)
sys-libs/glibc:           2.25-r10::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://minbar.caerllewys.net/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts:

alaric
    location: /var/lib/alaric
    masters: gentoo

brother-overlay
    location: /var/lib/layman/brother-overlay
    sync-type: laymansync
    sync-uri: https://github.com/stefan-langenmaier/brother-overlay.git
    masters: gentoo
    priority: 50

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=amdfam10 -O2 -pipe -mfpmath=sse -mcx16 -mpopcnt"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /var/bind /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=amdfam10 -O2 -pipe -mfpmath=sse -mcx16 -mpopcnt"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps=y --verbose-conflicts --keep-going"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://gentoo.cites.uiuc.edu/pub/gentoo                 http://gentoo.chem.wisc.edu/gentoo                 http://gentoo.osuosl.org                 ftp://mirrors.rit.edu/gentoo                 http://mirrors.cs.wmich.edu/gentoo                 "
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en_US en"
MAKEOPTS="-j6"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="3dnow 3dnowext X a52 aac acl acpi alsa amd64 bash-completion berkdb branding bzip2 cairo cdda cddb cdr cli consolekit crypt cups cxx dbus dri dts dvd dvdr emboss encode exif ffmpeg flac fltk fortran gdbm gif glamor gpm gtk iconv id3tag imagemagick ipv6 java jpeg jpeg2k lcms ldap libnotify mad mmx mmxext mng modules mp3 mp4 mpeg multilib mysql ncurses nls nptl nsplugin nvidia ogg opengl openmp opus pam pango pcre pcsc-lite pdf png policykit ppds qt3support qt5 readline sdl seccomp spell sse sse2 sse4 ssl startup-notification svg tcpd theora threads tiff tk tools truetype udev udisks unicode upower usb utils v4l v4l2 vdpau vorbis vpx wxwidgets x264 xattr xcb xml xpm xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="emu10k1 hda-intel" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-0" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" USERLAND="GNU" VIDEO_CARDS="nvidia v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 20 Thomas Beierlein gentoo-dev 2018-02-12 20:18:43 UTC
Thanks Phil for the info. Until now I do not see a difference to my configuration here.


I did some tests in the course of the day and compiled the package on 5 different systems. The first four worked without problems. But finally the last one showed the same problems as your system. So I have something to compare and test here. 

As far as I can see there seems to be some differences in the libtool handling of the bat file. I have to dig deeper into that.
Comment 21 Phil Stracchino (Unix Ronin) 2018-02-12 20:50:31 UTC
(In reply to Thomas Beierlein from comment #20)
> Thanks Phil for the info. Until now I do not see a difference to my
> configuration here.
> 
> 
> I did some tests in the course of the day and compiled the package on 5
> different systems. The first four worked without problems. But finally the
> last one showed the same problems as your system. So I have something to
> compare and test here. 
> 
> As far as I can see there seems to be some differences in the libtool
> handling of the bat file. I have to dig deeper into that.

I kinda had my suspicions it was some kind of libtool misfire.
Comment 22 Thomas Beierlein gentoo-dev 2018-02-13 15:59:52 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #21)
> (In reply to Thomas Beierlein from comment #20)
> > Thanks Phil for the info. Until now I do not see a difference to my
> > configuration here.
> > 
> > 
> > I did some tests in the course of the day and compiled the package on 5
> > different systems. The first four worked without problems. But finally the
> > last one showed the same problems as your system. So I have something to
> > compare and test here. 
> > 
> > As far as I can see there seems to be some differences in the libtool
> > handling of the bat file. I have to dig deeper into that.
> 
> I kinda had my suspicions it was some kind of libtool misfire.

Seems not quite to be true here.

In the generated bat.pro file (in qt-console) the LIBTOOL_INSTALL variable is correctly set.

The Makefile generated from it by qmake uses libtool as INSTALL_PROGRAM for the working machines.

On the machines where the script only gets installed there is a difference in the generated Makefile. It do not uses INSTALL_PROGRAM macro but QINSTALL which is set to
 
/usr/lib64/qt5/bin/qmake -install qinstall

And that command seems to have no idea about the libtool handling. 


The difference on my systems is teh version of Qt. The failing one uses the unstable   5.9.4 version. The other ones uses 5.7.1-r3.

Please can you check the Makefile in qt-console after configuration for the install program used for the 'install_bins:' section?

And please tell me your qtcore version.
Comment 23 Phil Stracchino (Unix Ronin) 2018-02-13 16:03:33 UTC
(In reply to Thomas Beierlein from comment #22)
> (In reply to Phil Stracchino (Unix Ronin) from comment #21)
> > (In reply to Thomas Beierlein from comment #20)
> > > Thanks Phil for the info. Until now I do not see a difference to my
> > > configuration here.
> > > 
> > > 
> > > I did some tests in the course of the day and compiled the package on 5
> > > different systems. The first four worked without problems. But finally the
> > > last one showed the same problems as your system. So I have something to
> > > compare and test here. 
> > > 
> > > As far as I can see there seems to be some differences in the libtool
> > > handling of the bat file. I have to dig deeper into that.
> > 
> > I kinda had my suspicions it was some kind of libtool misfire.
> 
> Seems not quite to be true here.
> 
> In the generated bat.pro file (in qt-console) the LIBTOOL_INSTALL variable
> is correctly set.
> 
> The Makefile generated from it by qmake uses libtool as INSTALL_PROGRAM for
> the working machines.
> 
> On the machines where the script only gets installed there is a difference
> in the generated Makefile. It do not uses INSTALL_PROGRAM macro but QINSTALL
> which is set to
>  
> /usr/lib64/qt5/bin/qmake -install qinstall
> 
> And that command seems to have no idea about the libtool handling. 
> 
> 
> The difference on my systems is teh version of Qt. The failing one uses the
> unstable   5.9.4 version. The other ones uses 5.7.1-r3.
> 
> Please can you check the Makefile in qt-console after configuration for the
> install program used for the 'install_bins:' section?
> 
> And please tell me your qtcore version.

Aaaaaah, so this is looking like a Qt-5.9.4 bug.  Yes, I'm running 5.9.4; I can try backing out to 5.7.1, but my recollection is that I updated because some package that I have required 5.9.3 or higher.

I will check into both of these.
Comment 24 Phil Stracchino (Unix Ronin) 2018-02-13 16:18:23 UTC
With 5.9.4:

install_bins: first FORCE
	@test -d $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin || mkdir -p $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin
	-$(QINSTALL_PROGRAM) /var/tmp/portage/app-backup/bacula-9.0.6-r1/work/bacula-9.0.6/src/qt-console/bat $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin/bat

QINSTALL_PROGRAM = /usr/lib64/qt5/bin/qmake -install qinstall -exe
Comment 25 Thomas Beierlein gentoo-dev 2018-02-13 16:40:18 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #24)
> With 5.9.4:
> 
> install_bins: first FORCE
> 	@test -d $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin || mkdir -p
> $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin
> 	-$(QINSTALL_PROGRAM)
> /var/tmp/portage/app-backup/bacula-9.0.6-r1/work/bacula-9.0.6/src/qt-console/
> bat $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin/bat
> 
> QINSTALL_PROGRAM = /usr/lib64/qt5/bin/qmake -install qinstall -exe

Ok. That is the problem. That program has no understanding of libtool files ans so it copies the wrong file.

I am checking atm at the platform with the problem a downgrade of Qt to 5.7.1 to verify that it is due to the Qt version.
Comment 26 Thomas Beierlein gentoo-dev 2018-02-13 17:11:12 UTC
(In reply to Thomas Beierlein from comment #25)
> (In reply to Phil Stracchino (Unix Ronin) from comment #24)
> > With 5.9.4:
> > 
> > install_bins: first FORCE
> > 	@test -d $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin || mkdir -p
> > $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin
> > 	-$(QINSTALL_PROGRAM)
> > /var/tmp/portage/app-backup/bacula-9.0.6-r1/work/bacula-9.0.6/src/qt-console/
> > bat $(INSTALL_ROOT)/$(DESTDIR)/usr/sbin/bat
> > 
> > QINSTALL_PROGRAM = /usr/lib64/qt5/bin/qmake -install qinstall -exe
> 
> Ok. That is the problem. That program has no understanding of libtool files
> ans so it copies the wrong file.
> 
> I am checking atm at the platform with the problem a downgrade of Qt to
> 5.7.1 to verify that it is due to the Qt version.

Downgrading to stable Qt 5.7.1 fixes the problem. 

I did some search on the web about the changes to newer Qt version but did not found any related information yet.
Comment 27 Phil Stracchino (Unix Ronin) 2018-02-13 18:27:16 UTC
I found the Qt-5.9 dependency:  app-mobilephone/heimdall.
Comment 28 Phil Stracchino (Unix Ronin) 2018-02-13 18:38:45 UTC
This is a bit of an 8-ball problem, actually.  I need two tools to be able to do LineageOS (formerly CyanogenMod) installs from Linux:  app-mobilephone/qtadb and app-mobilephone/heimdall.  qtadb's GUI portion, which I don't actually need but can't disable, has a forced dependency upon ten Qt4 modules, and Heimdall goes the other direction and requires Qt 5.9.

I may have to just resign myself to doing any future LineageOS installs from Windows instead...
Comment 29 Phil Stracchino (Unix Ronin) 2018-02-13 19:59:51 UTC
Well, I found *ONE* Qt 5.9 dependency.  It turns out I have quite a few others.  I've spent the last several hours trying without success to cleanly back out to Qt 5.7.1 in order to verify, so far without success even after uninstalling several packages (not just app-mobilephone/heimdall).
Comment 30 Thomas Beierlein gentoo-dev 2018-02-13 20:47:33 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #29)
> Well, I found *ONE* Qt 5.9 dependency.  It turns out I have quite a few
> others.  I've spent the last several hours trying without success to cleanly
> back out to Qt 5.7.1 in order to verify, so far without success even after
> uninstalling several packages (not just app-mobilephone/heimdall).

Maybe you can test it from one of your other systems. I am not sure if all needs the Qt5.9
Comment 31 Phil Stracchino (Unix Ronin) 2018-02-13 23:23:56 UTC
It turns out ONE of my other servers had no Qt previously installed at all, making it an ideal test case.  I just temporarily added USE=qt5 on that server, and it built with no problems and correctly installed /usr/sbin/bat.

So it looks as though there is a problem only with Qt 5.9.
Comment 32 Thomas Beierlein gentoo-dev 2018-02-14 16:14:25 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #31)
> It turns out ONE of my other servers had no Qt previously installed at all,
> making it an ideal test case.  I just temporarily added USE=qt5 on that
> server, and it built with no problems and correctly installed /usr/sbin/bat.
> 
> So it looks as though there is a problem only with Qt 5.9.

Thanks for confirmation. Now to find a way to solve the problem....
Comment 33 Thomas Beierlein gentoo-dev 2018-02-18 18:38:39 UTC
New bacula-9.0.6-r2 in tree fixes build problems for bat with >=Qt5.9.

Thanks for help kensington.
Comment 34 Phil Stracchino (Unix Ronin) 2018-02-19 14:38:23 UTC
Looks good to me.  r2 merged with no issues this morning with qt-console against Qt 5.9.4.
Comment 35 Thomas Beierlein gentoo-dev 2018-02-19 16:15:49 UTC
(In reply to Phil Stracchino (Unix Ronin) from comment #34)
> Looks good to me.  r2 merged with no issues this morning with qt-console
> against Qt 5.9.4.

Very well. Thanks for confirmation.

I will close the bug as resolved.
Comment 36 Andreas Sturmlechner gentoo-dev 2018-02-19 16:18:48 UTC
Thanks for your work! Let's keep this open until cleanup was done.
Comment 37 Thomas Beierlein gentoo-dev 2018-02-19 18:33:04 UTC
(In reply to Andreas Sturmlechner from comment #36)
> Thanks for your work! Let's keep this open until cleanup was done.

Very well. Sounds good.
Comment 38 Andreas Sturmlechner gentoo-dev 2018-03-17 12:07:04 UTC
Can we proceed with stabilisation of 9.0.6-r2?
Comment 39 Thomas Beierlein gentoo-dev 2018-03-17 18:42:19 UTC
(In reply to Andreas Sturmlechner from comment #38)
> Can we proceed with stabilisation of 9.0.6-r2?

There is one problem left about the broken libressl support in 9.0.6 - see bug #641492. There are some patches on the BSD bug tracker which I would try out. As I was away for the last two weeks I am not far with it.

I see the need for a quick stabilization to get rid of QT4 support. So how about dropping libressl from IUSE for 9.0.6-r2 and prepare a -r3 version with the new patches after stabilization of -r2?
Comment 40 Andreas Sturmlechner gentoo-dev 2018-03-17 20:02:03 UTC
Alternatively you could p.use.stable.mask ~9.0.6 so that you don't have to change the ebuild.
Comment 41 Thomas Beierlein gentoo-dev 2018-03-20 21:04:16 UTC
(In reply to Andreas Sturmlechner from comment #40)
> Alternatively you could p.use.stable.mask ~9.0.6 so that you don't have to
> change the ebuild.

Good idea. I tried to test it here, but the mask in p.use.stable.mask seems to get ignored. Putting it into p.use.mask works as expected. Any idea?
Comment 42 Andreas Sturmlechner gentoo-dev 2018-03-20 21:11:29 UTC
The mask needs to go into ${PORTDIR}/profiles/base/package.use.stable.mask.
It will only be effective on your system if you don't accept ~arch keyword.
Comment 43 Thomas Beierlein gentoo-dev 2018-03-21 05:45:53 UTC
(In reply to Andreas Sturmlechner from comment #42)
> The mask needs to go into ${PORTDIR}/profiles/base/package.use.stable.mask.
> It will only be effective on your system if you don't accept ~arch keyword.

Thanks that put me on the right track. I used the right file and I have a (mostly) stable system.
I overlooked that I had the package in p.accept_keywords for testing. After fixing that it just worked.
Comment 44 Larry the Git Cow gentoo-dev 2018-03-21 14:31:12 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee036bdf9f00cfe2b690151771f59d145e447b87

commit ee036bdf9f00cfe2b690151771f59d145e447b87
Author:     Thomas Beierlein <tomjbe@gentoo.org>
AuthorDate: 2018-03-21 08:53:31 +0000
Commit:     Thomas Beierlein <tomjbe@gentoo.org>
CommitDate: 2018-03-21 14:30:03 +0000

    profile: package.use.stable.mask - ~app-backup/bacula-9.0.6[libressl]
    
    - package does not compile with USE=libressl (bug #641492) do to changed
      SSL handling.
    - There are first fixes out there on BSD bug database but not ready
    - bacula-9.0.6-r2 should go stable soon to enable drop of USE=qt4
    
    Bug: https://bugs.gentoo.org/641492
    Bug: https://bugs.gentoo.org/644566

 profiles/base/package.use.stable.mask | 4 ++++
 1 file changed, 4 insertions(+)}
Comment 45 Thomas Beierlein gentoo-dev 2018-05-11 17:51:16 UTC
>    app-backup/bacula: Drop old versions depending on Qt4
    
>    ppc and sparc project gave ack for not having to wait for stabilization
>    of bacula-9.0.6-r2 (bug #651078, comment 4)