Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 29 de julio de 2018 22:45:38 -03 John David Anglin escribió:
> On 2018-07-29 4:53 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Looking again the call to llvm-config seems to not be fatal, so it should
> > be as simple as doing something like it's already done in the dh_install
> > override for archs without qt webview.
> 
> Yes.  I had a successful build on hppa with the attached patch:
> https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src=h
> ppa=5.11.1-3=1532903616=0
> 
> The no webview hunk needs a different regexp which I didn't work out.

Maybe reversing the logic works it out? I mean something on the line of:

cat debian/qttools5-dev-tools.in > debian/qttools5-dev-tools.install

if(qwebview arch)
  echo /usr/${DEB_HOST_MULTIARCH}/qt5/qwebview >>  debian/qttools5-dev-
tools.install
if(qdoc arch)
  echo qdoc >> debian/qttools5-dev-tools.install

Or did I mis understood the problem?

> It remains to be seen what the impact of losing qdoc will be.  The hard
> part will be generating
> the documentation packages.

Well, better than nothing I guess.

Please pretty please ping me about this after the transition ends, in case I 
happen to forget it.



-- 
Without us [Free Software developers], people would study computer science
and programming without ever having seen a real program in its entirety.
That's like becoming writers without ever having read a complete book.
  Matthias Ettrich, founder of the KDE project.
  http://www.efytimes.com/efytimes/25412/news.htm

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[John David Anglin]

On 2018-07-29 4:53 PM, Lisandro Damián Nicanor Pérez Meyer wrote:

Looking again the call to llvm-config seems to not be fatal, so it should be
as simple as doing something like it's already done in the dh_install override
for archs without qt webview.


Yes.  I had a successful build on hppa with the attached patch:
https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src=hppa=5.11.1-3=1532903616=0

The no webview hunk needs a different regexp which I didn't work out.

It remains to be seen what the impact of losing qdoc will be.  The hard 
part will be generating

the documentation packages.

Dave

--
John David Anglin  dave.ang...@bell.net

--- rules.save  2018-07-29 21:35:07.393423169 -0400
+++ rules   2018-07-29 15:38:51.476671623 -0400
@@ -32,6 +32,7 @@
dh_auto_build -- docs
 
 ifeq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH))
+ifeq (,$(filter alpha hppa ia64 m68k powerpcspe riscv64 sh4 x32, 
$(DEB_HOST_ARCH)))
 override_dh_auto_build-arch: build-doc-tools
# Rebuild the internal assistant.qch which is used as a resource
cd src/assistant/assistant/doc/internal; qmake
@@ -39,6 +40,7 @@
mv doc/assistant.qch src/assistant/assistant/assistant.qch
dh_auto_build
 endif
+endif
 
 override_dh_auto_install-arch:
dh_auto_install
@@ -56,7 +58,11 @@
 ifeq ($(DEB_HOST_ARCH),$(findstring $(DEB_HOST_ARCH), $(no_qwebview_archs)))
grep -v qwebview debian/qttools5-dev-tools.install.in >> 
debian/qttools5-dev-tools.install
 else
+ifeq (,$(filter alpha hppa ia64 m68k powerpcspe riscv64 sh4 x32, 
$(DEB_HOST_ARCH)))
cp debian/qttools5-dev-tools.install.in 
debian/qttools5-dev-tools.install
+else
+   grep -v qdoc debian/qttools5-dev-tools.install.in >> 
debian/qttools5-dev-tools.install
+endif
 endif
dh_install --fail-missing
 

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 29 de julio de 2018 14:11:41 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> Hi Dave!
> 
> El domingo, 29 de julio de 2018 11:46:32 -03 John David Anglin escribió:
> > Here is log for an attempted build on hppa with Adrian's patch:
> > https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src
> > =h ppa=5.11.1-3=1532832160=0
> 
> As expected, as it is a hard dependency. So the patch needs to avoid
> building qdoc too.

Looking again the call to llvm-config seems to not be fatal, so it should be 
as simple as doing something like it's already done in the dh_install override 
for archs without qt webview.

By the way, I have just sent this to Qt's development mailing list:



My idea is to know if some other submodule maintainer is thinking in adding 
llvm as a dependency.


-- 
Must it be assumed that because we are engineers beauty is not
our concern, and that while we make our constructions robust
and durable we do not also strive to make them elegant?
Is it not true that the genuine conditions of strength always
comply with the secret conditions of harmony?
 Gustave Eiffel, 1887

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#904948: kate is not installable

[Nicolas Patrois]

Package: kate
Version: kate
Severity: normal

Dear Maintainer,

kate is not installable, as many other KDE packages (calibre convertall
gwenview hplip-gui k3b k4dirstat konqueror konsole krename kstars kubrick
okular pyzo qarte soundkonverter spyder systemsettings).

Here is the interesting part of the error message:
 libkf5xmlgui5 : Depends: qtbase-abi-5-10-0 which is a virtual package and is
not provided by any available package



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.3.0-1-686-pae (SMP w/3 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kate depends on:
pn  kate5-data   
ii  kio  5.47.0-1
pn  ktexteditor-katepart 
ii  libc62.27-5
ii  libkf5activities55.47.0-1
pn  libkf5bookmarks5 
ii  libkf5completion55.47.0-1
ii  libkf5configcore55.47.0-1
ii  libkf5configgui5 5.47.0-1
ii  libkf5configwidgets5 5.47.0-1
ii  libkf5coreaddons55.47.0-1
ii  libkf5crash5 5.47.0-1
ii  libkf5dbusaddons55.47.0-1
ii  libkf5guiaddons5 5.47.0-1
ii  libkf5i18n5  5.47.0-1
ii  libkf5iconthemes55.47.0-1
pn  libkf5itemmodels5
ii  libkf5jobwidgets55.47.0-1
ii  libkf5kiocore5   5.47.0-1
pn  libkf5kiofilewidgets5
ii  libkf5kiowidgets55.47.0-1
pn  libkf5newstuff5  
pn  libkf5parts5 
pn  libkf5plasma5
ii  libkf5service-bin5.47.0-1
ii  libkf5service5   5.47.0-1
pn  libkf5texteditor5
ii  libkf5textwidgets5   5.47.0-1
pn  libkf5threadweaver5  
ii  libkf5wallet-bin 5.47.0-1
ii  libkf5wallet55.47.0-1
ii  libkf5widgetsaddons5 5.47.0-1
ii  libkf5windowsystem5  5.47.0-1
pn  libkf5xmlgui5
ii  libqt5core5a 5.11.1+dfsg-6
ii  libqt5dbus5  5.11.1+dfsg-6
ii  libqt5gui5   5.11.1+dfsg-6
ii  libqt5sql5   5.11.1+dfsg-6
ii  libqt5widgets5   5.11.1+dfsg-6
ii  libqt5xml5   5.11.1+dfsg-6
ii  libstdc++6   8.2.0-1
pn  plasma-framework 
ii  qml-module-org-kde-kquickcontrolsaddons  5.47.0-1
ii  qml-module-qtquick-layouts   5.11.1-4
ii  qml-module-qtquick2  5.11.1-4

Versions of packages kate recommends:
ii  sonnet-plugins  5.47.0-1

Versions of packages kate suggests:
pn  darcs
ii  exuberant-ctags  1:5.9~svn20110310-12
ii  git  1:2.18.0-1
pn  khelpcenter  
pn  konsole-kpart
ii  mercurial4.6.1-1
ii  subversion   1.10.0-2

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[John Paul Adrian Glaubitz]

On 07/29/2018 09:12 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Interesting, I have always used them inside the binary itself[1].
> 
> [1] 
> 
> But thanks to your comment I noted that indeed one can keep the resource file 
> out of the main binary.

I have actually never seen anyone compile them into the binary, not even
on Windows. I'm surprised people still do that. Anyway.

>> Do you have a link on that? I have my doubts that it's actually not possible
>> to separate the QDoc building from compiling the actual C++ code.
> 
> 
> Well, I am thinking in this workflow:
> 
> - Generate QDoc documentation using qdoc.
> 
> - Add the resulting files to a resource.
> 
> - Access the documentation with QFile as usual, but using the name of the 
> resource to start the URL. like ":/images/cut.png"

Qt applications normally will just find these files if you put them into
/usr/share/$APPNAME. My own Qt application "qhimdtransfer" from the linux-
minidisc project does that.

> Now I don't think many packages will go this route, as it's not 
> straightforward to set up. But it should be doable. And still better than 
> nothing.
> 
> Of course having LLVM/clang available in all archs would be just better :-/

Porting LLVM to a new target isn't something that is done over night, it's
a bit of an effort. But there are already out-of-tree ports for Alpha, IA64
and m68k. All of them are not in a usable state though, but we will be getting
there. I want to make LLVM available on more architectures in order to get
Rust support there. Once LLVM support is there, adding support in Rust is
rather simple.

But that's a different story.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[John David Anglin]

On 2018-07-29 2:39 PM, John Paul Adrian Glaubitz wrote:

I have my doubts that it's actually not possible
to separate the QDoc building from compiling the actual C++ code.
It appears to me from the build log that the install needs to be 
modified when qdoc isn't built.


It seems unlikely that it can be built without clang.  For windows, 
there is FORCE_MINGW_QDOC_BUILD.


qt_find_clang.prf says:

    equals(QMAKE_HOST.os, Windows):gcc:isEmpty(FORCE_MINGW_QDOC_BUILD) {
    log("QDoc build is disabled on MinGW in Qt 5.11.0, because 
of a missing feature in the release infrastructure.")

    log("You can enable it by setting FORCE_MINGW_QDOC_BUILD")
    break()
    }

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 29 de julio de 2018 15:39:51 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/29/2018 07:11 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Adrian: I have just remembered that there is actually a case in which
> > building documentation can be rightfully in a binary build: when it's
> > embedded in the application itself by using Qt's resources system. That's
> > definitely not a bug, and those apps will surely FTBFS.
> 
> From what I remember from my times of professional Qt development, I'm
> pretty sure that even those resource files are generated as separate files.
> I don't remember anything actually compiled into the resulting binary. All
> those resource files were always separate.

Interesting, I have always used them inside the binary itself[1].

[1] 

But thanks to your comment I noted that indeed one can keep the resource file 
out of the main binary.

> > I don't have the least idea of the number of apps that might be using that
> > mechanism though.
> 
> Do you have a link on that? I have my doubts that it's actually not possible
> to separate the QDoc building from compiling the actual C++ code.


Well, I am thinking in this workflow:

- Generate QDoc documentation using qdoc.

- Add the resulting files to a resource.

- Access the documentation with QFile as usual, but using the name of the 
resource to start the URL. like ":/images/cut.png"

Now I don't think many packages will go this route, as it's not 
straightforward to set up. But it should be doable. And still better than 
nothing.

Of course having LLVM/clang available in all archs would be just better :-/

-- 
If little green men land in your back yard, hide any little green women
you've got in the house.
  Mike Harding, "The Armchair Anarchist's Almanac"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[John Paul Adrian Glaubitz]

On 07/29/2018 07:11 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Adrian: I have just remembered that there is actually a case in which 
> building 
> documentation can be rightfully in a binary build: when it's embedded in the 
> application itself by using Qt's resources system. That's definitely not a 
> bug, and those apps will surely FTBFS.

>From what I remember from my times of professional Qt development, I'm pretty
sure that even those resource files are generated as separate files. I don't
remember anything actually compiled into the resulting binary. All those
resource files were always separate.

> I don't have the least idea of the number of apps that might be using that 
> mechanism though.

Do you have a link on that? I have my doubts that it's actually not possible
to separate the QDoc building from compiling the actual C++ code.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Lisandro Damián Nicanor Pérez Meyer]

Hi Dave!

El domingo, 29 de julio de 2018 11:46:32 -03 John David Anglin escribió:
> Here is log for an attempted build on hppa with Adrian's patch:
> https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src=h
> ppa=5.11.1-3=1532832160=0

As expected, as it is a hard dependency. So the patch needs to avoid building 
qdoc too.

Adrian: I have just remembered that there is actually a case in which building 
documentation can be rightfully in a binary build: when it's embedded in the 
application itself by using Qt's resources system. That's definitely not a 
bug, and those apps will surely FTBFS.

I don't have the least idea of the number of apps that might be using that 
mechanism though.

Regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[John David Anglin]

Here is log for an attempted build on hppa with Adrian's patch:
https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src=hppa=5.11.1-3=1532832160=0

Dave

--
John David Anglin  dave.ang...@bell.net