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

[Dmitry Shachnev]

On Wed, Jan 02, 2019 at 06:36:45PM +0100, John Paul Adrian Glaubitz wrote:
> > What do you think of splitting qdoc into a separate package?
> >
> > This way the packages that need it might explicitly build-depend on that
> > package and dep-wait instead of getting build failures on some 
> > architectures.
>
> That would be awesome. Thanks a lot for that.
>
> [...]
>
> I'm fine waiting for the qttools upload taking longer if it has to go
> through NEW. If I know the issue is being worked on, I can continue
> applying the temporary fix in Debian Ports.

Thanks Adrian, James and Lisandro for your feedback!

I have just uploaded the fix, it will land in the binNEW queue soon.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

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

[Lisandro Damián Nicanor Pérez Meyer]

El miércoles, 2 de enero de 2019 14:31:07 -03 Dmitry Shachnev escribió:
> Hi Adrian and Lisandro!
> 
> On Thu, Dec 27, 2018 at 10:35:25PM +0100, John Paul Adrian Glaubitz wrote:
> > Hello!
> > 
> > Would it be possible that the patch from David [1] gets included in the
> > next upload with the dependencies adjusted in debian/control for the
> > affected architectures?
> > 
> > I know the patch isn't perfect, but it helps us unblocking the reverse
> > dependencies of qttools. Currently, I have manually build qttools with
> > the patch and re-upload every the Qt team uploads a new qttools version
> > which feels like a sisyphos task [2].
> 
> What do you think of splitting qdoc into a separate package?
> 
> This way the packages that need it might explicitly build-depend on that
> package and dep-wait instead of getting build failures on some
> architectures.
> 
> Also we will be able to use the Architecture: field and a proper install
> file instead of this hack in debian/rules.

I like the idea. Please go ahead.
 
> If you want we can upload the patch as-is now and then do a follow-up upload
> to the NEW queue introducing the new package.

An upload to NEW due to a splitted package normally does not takes long to be 
processed, and we can ping ftp masters to check it if needed.
 
> (Or maybe we can add Provides: qt5-qdoc [arch1 arch2…] which should be the
> same with regards to Build-Depends: field of other packages. But I like
> splitting more.)

I prefer splitting too.


-- 
Mi experiencia me dice que lo que la gente quiere y necesita -en Indonesia, en
Turquía, en Italia, en los Estados Unidos, en Brasil, en la Argentina o donde
sea- es básicamente lo mismo. La gente quiere comida en la mesa, una vivienda
básica, un gobierno que funcione, que en las fuerzas de seguridad haya
personas confiables, a las que no tengan que tenerles miedo, educación y
salud. ¡La gente de todo el mundo quiere lo mismo!
  Padre Thomas Michel, jesuita, especialista en diálogo interreligioso,
  en una entrevista de Elisabetta Piqué para La Nación, 27/09/2006.
  http://www.lanacion.com.ar/844069

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

[James Clarke]

On 2 Jan 2019, at 17:31, Dmitry Shachnev  wrote:
> 
> Hi Adrian and Lisandro!
> 
> On Thu, Dec 27, 2018 at 10:35:25PM +0100, John Paul Adrian Glaubitz wrote:
>> Hello!
>> 
>> Would it be possible that the patch from David [1] gets included in the
>> next upload with the dependencies adjusted in debian/control for the
>> affected architectures?
>> 
>> I know the patch isn't perfect, but it helps us unblocking the reverse
>> dependencies of qttools. Currently, I have manually build qttools with
>> the patch and re-upload every the Qt team uploads a new qttools version
>> which feels like a sisyphos task [2].
> 
> What do you think of splitting qdoc into a separate package?
> 
> This way the packages that need it might explicitly build-depend on that
> package and dep-wait instead of getting build failures on some architectures.
> 
> Also we will be able to use the Architecture: field and a proper install file
> instead of this hack in debian/rules.

That's personally how I think it should be done. We can have the -dev package
Depend: qdoc [arches] during the transitional period until everything needing
qdoc explicitly (Build-)Depends on it.

James

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

[John Paul Adrian Glaubitz]

Hi Dmitry!

On 1/2/19 6:31 PM, Dmitry Shachnev wrote:
>> I know the patch isn't perfect, but it helps us unblocking the reverse
>> dependencies of qttools. Currently, I have manually build qttools with
>> the patch and re-upload every the Qt team uploads a new qttools version
>> which feels like a sisyphos task [2].
> 
> What do you think of splitting qdoc into a separate package?
> 
> This way the packages that need it might explicitly build-depend on that
> package and dep-wait instead of getting build failures on some architectures.

That would be awesome. Thanks a lot for that.

> Also we will be able to use the Architecture: field and a proper install file
> instead of this hack in debian/rules.
> 
> If you want we can upload the patch as-is now and then do a follow-up upload
> to the NEW queue introducing the new package.

I'm fine waiting for the qttools upload taking longer if it has to go
through NEW. If I know the issue is being worked on, I can continue
applying the temporary fix in Debian Ports.

> (Or maybe we can add Provides: qt5-qdoc [arch1 arch2…] which should be the
> same with regards to Build-Depends: field of other packages. But I like
> splitting more.)

Feel free to use the option which suits you best. And thanks again for working
on that. Much appreciated!

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

[Dmitry Shachnev]

Hi Adrian and Lisandro!

On Thu, Dec 27, 2018 at 10:35:25PM +0100, John Paul Adrian Glaubitz wrote:
> Hello!
>
> Would it be possible that the patch from David [1] gets included in the
> next upload with the dependencies adjusted in debian/control for the
> affected architectures?
>
> I know the patch isn't perfect, but it helps us unblocking the reverse
> dependencies of qttools. Currently, I have manually build qttools with
> the patch and re-upload every the Qt team uploads a new qttools version
> which feels like a sisyphos task [2].

What do you think of splitting qdoc into a separate package?

This way the packages that need it might explicitly build-depend on that
package and dep-wait instead of getting build failures on some architectures.

Also we will be able to use the Architecture: field and a proper install file
instead of this hack in debian/rules.

If you want we can upload the patch as-is now and then do a follow-up upload
to the NEW queue introducing the new package.

(Or maybe we can add Provides: qt5-qdoc [arch1 arch2…] which should be the
same with regards to Build-Depends: field of other packages. But I like
splitting more.)

--
Dmitry Shachnev


signature.asc
Description: PGP signature

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

[Lisandro Damián Nicanor Pérez Meyer]

(Adrian: sorry for the double post, adding the rest of the CCed people now).

El jueves, 27 de diciembre de 2018 18:35:25 -03 John Paul Adrian Glaubitz 
escribió:
> Hello!
> 
> Would it be possible that the patch from David [1] gets included in the
> next upload with the dependencies adjusted in debian/control for the
> affected architectures?
> 
> I know the patch isn't perfect, but it helps us unblocking the reverse
> dependencies of qttools. Currently, I have manually build qttools with
> the patch and re-upload every the Qt team uploads a new qttools version
> which feels like a sisyphos task [2].
> 
> I have to do it again now :-(.

As said in :

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

Well, I did forget it and we started a transition yesterday. Doing it now will 
simply not help to achieve the transition, so please ping me after we finished 
it.

Thanks, Lisandro.

-- 
En los momentos de crisis, la imaginación es mas importante que el
conocimiento.
 Albert Einstein

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]

Hello!

Would it be possible that the patch from David [1] gets included in the
next upload with the dependencies adjusted in debian/control for the
affected architectures?

I know the patch isn't perfect, but it helps us unblocking the reverse
dependencies of qttools. Currently, I have manually build qttools with
the patch and re-upload every the Qt team uploads a new qttools version
which feels like a sisyphos task [2].

I have to do it again now :-(.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904688#142
> [2] https://en.wikipedia.org/wiki/Sisyphus

-- 
 .''`.  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]

El martes, 31 de julio de 2018 17:54:55 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/31/2018 09:16 PM, Sune Vuorela wrote:
> >  - not embedding the resources on all platforms gives quite bigger
> >  deployment> 
> > issues on some platforms. (windows, mac, some mobile targets)
> 
> macOS always puts the resource files into separate folders inside the app
> bundle (which is just a folder). At least when I did professional Qt
> development.

Only if you don't compile it as part of the binary. Yes, you can do that.

> >  - on some platforms, embedding resources gives faster startup and
> >  resource
> > 
> > access. (Especially windows)
> 
> I think that difference is negligible. 

Not what upstreams says actually (but I have no way to check nor will lose 
time on that).

> Plus, we're also not talking about
> Windows or macOS here, so the situation is not comparable. On Debian, we
> do have multiple versions of the same binary and storing the resource
> files is explicitly desired as it makes a difference in disk space when
> we're talking about hundreds or thousands of packages.

I agree with you, but multi platform developers disagree. And we are talking 
about multi platform projects here.

> > So embedding resources if you target cross platformness, and your
> > resources
> > aren't too big and not actually shared with others often the easiest and
> > cheapest way forward. It costs mirroring linux distributions a slight disk
> > overhead, but I don't think that is too big of a problem.
> 
> You're basically using the arguments for the Windows and macOS versions
> on Debian. In Debian, saving disk space through redundancy does defnitely
> make a difference.

Then you need to convince every upstream out there of this. Having a switch 
would indeed be desirable.

> > But, more and more are going to need libclang. Given libclang is mostly a
> > c++ parser, I don't see why it shouldn't be buildable on most platforms ?
> > Can't the compiler bits be stripped from the llvm source package on some
> > archs?
> That has to be seen. As I said, we're working on it. But it takes some
> time.

I think that will be better spent that the whole rest :-/ It would not surpise 
me if any other part of Qt gains a hard dependency on llvm due to it's parser. 
It makes developers waste much less time than making your own.


-- 
Nearly all men can stand adversity, but if you want to test a man's
character, give him power.
  Abraham Lincoln

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

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 31 de julio de 2018 20:04:39 -03 Thorsten Glaser escribió:
> John Paul Adrian Glaubitz dixit:
> >Resource files (docs, images etc) are normally architecture-independent, so
> >they should be separable from the binary packages.
> 
> True. MuseScore does that too, but not from qdoc AFAICT.
> 
> Can we unbundle the resources but still make them available
> in a way that the ":/filename" access form works (i.e. still
> create something like the resource bundle, but build it as
> part of build-indep and ship it separately)?

You can, but you need to register it when the application starts (check the 
link I sent before in this thread about Qt resources).

That being said I think nothing warrants it to be arch-independent.

> Otherwise I fear
> it would be patching way too much, in that specific case,
> which does not strictly need it.
> 
> As for the qdoc ones… sucks, but we still need to have
> something to go forward from here. Options, as far as
> I saw them, are (not necessarily orthogonal):
> 
> • patch qttools itself and two other packages to keep the
>   resources external

Let's try to avoid that.

> • make an older qdoc available on those architectures

Won't happen from our side.

> • see if the clang parser can be built without having
>   an LLVM target, i.e. unbundled from the LLVM+Clang
>   toolchain that targets the native architecture
>   (might require an intrusive package split on clang side)

This is indeed the preferred solution. Above any of the others we discussed.

-- 
...man had always assumed that he was more intelligent than dolphins because
he had achieved so much -- the wheel, New York, wars and so on -- whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man -- for precisely the same reasons.
  Douglas Adams, "The hitchhikers' guide to the galaxy"

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

[Thorsten Glaser]

John Paul Adrian Glaubitz dixit:

>Resource files (docs, images etc) are normally architecture-independent, so
>they should be separable from the binary packages.

True. MuseScore does that too, but not from qdoc AFAICT.

Can we unbundle the resources but still make them available
in a way that the ":/filename" access form works (i.e. still
create something like the resource bundle, but build it as
part of build-indep and ship it separately)? Otherwise I fear
it would be patching way too much, in that specific case,
which does not strictly need it.

As for the qdoc ones… sucks, but we still need to have
something to go forward from here. Options, as far as
I saw them, are (not necessarily orthogonal):

• patch qttools itself and two other packages to keep the
  resources external

• make an older qdoc available on those architectures

• see if the clang parser can be built without having
  an LLVM target, i.e. unbundled from the LLVM+Clang
  toolchain that targets the native architecture
  (might require an intrusive package split on clang side)

My Qt/C++ skills are not very good, but if I can help any…

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

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

[John Paul Adrian Glaubitz]

On 07/31/2018 09:16 PM, Sune Vuorela wrote:
>  - not embedding the resources on all platforms gives quite bigger deployment 
> issues on some platforms. (windows, mac, some mobile targets)

macOS always puts the resource files into separate folders inside the app bundle
(which is just a folder). At least when I did professional Qt development.

>  - on some platforms, embedding resources gives faster startup and resource 
> access. (Especially windows)

I think that difference is negligible. Plus, we're also not talking about
Windows or macOS here, so the situation is not comparable. On Debian, we
do have multiple versions of the same binary and storing the resource
files is explicitly desired as it makes a difference in disk space when
we're talking about hundreds or thousands of packages.

> So embedding resources if you target cross platformness, and your resources 
> aren't too big and not actually shared with others often the easiest and 
> cheapest way forward. It costs mirroring linux distributions a slight disk 
> overhead, but I don't think that is too big of a problem.

You're basically using the arguments for the Windows and macOS versions
on Debian. In Debian, saving disk space through redundancy does defnitely
make a difference.

> But, more and more are going to need libclang. Given libclang is mostly a c++ 
> parser, I don't see why it shouldn't be buildable on most platforms ? Can't 
> the compiler bits be stripped from the llvm source package on some archs?

That has to be seen. As I said, we're working on it. But it takes some
time.

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

[Sune Vuorela]

On Tuesday, July 31, 2018 8:48:42 PM CEST John Paul Adrian Glaubitz wrote:
> It's still a bad practice, in my personal opinion, because it adds
> redundancy.

It is kind of - from an upstream POV - what kind of situation you optimize 
for. 

 - embedding the resources in the executable or library  might add redundancy 
if someone distributes several versions, but disk space is cheap in these 
sizes.
 - not embedding the resources on some platforms gives different code paths. 
Code paths are quite expensive from a testing POV.
 - not embedding the resources on all platforms gives quite bigger deployment 
issues on some platforms. (windows, mac, some mobile targets)
 - embedding resources make the resources harder to hack/modify on disk. Some 
think it is an advantage. Others a disadvantage.
 - on some platforms, embedding resources gives faster startup and resource 
access. (Especially windows)

So embedding resources if you target cross platformness, and your resources 
aren't too big and not actually shared with others often the easiest and 
cheapest way forward. It costs mirroring linux distributions a slight disk 
overhead, but I don't think that is too big of a problem.

But, more and more are going to need libclang. Given libclang is mostly a c++ 
parser, I don't see why it shouldn't be buildable on most platforms ? Can't 
the compiler bits be stripped from the llvm source package on some archs?

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

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

[John Paul Adrian Glaubitz]

On 07/31/2018 08:40 PM, Dmitry Shachnev wrote:
> There is an example in *this* package (qttools-opensource-src) — Qt Assistant
> bundles its own help as a resource:
> 
> https://code.qt.io/cgit/qt/qttools.git/tree/src/assistant/assistant/assistant.qrc
> 
> Codesearch tells me that “aseba” and “speedcrunch” packages may be doing
> a similar thing:
> 
> https://codesearch.debian.net/search?q=%5C.qch+path%3A.*%5C.qrc

It's still a bad practice, in my personal opinion, because it adds redundancy.

Resource files (docs, images etc) are normally architecture-independent, so
they should be separable from the binary packages.

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]

On Tue, 31 Jul 2018 at 15:45, Dmitry Shachnev  wrote:
>
> On Sun, Jul 29, 2018 at 09:17:30PM +0200, John Paul Adrian Glaubitz wrote:
> > 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.
>
> There is an example in *this* package (qttools-opensource-src) — Qt Assistant
> bundles its own help as a resource:
>
> https://code.qt.io/cgit/qt/qttools.git/tree/src/assistant/assistant/assistant.qrc

Mmm, I wonder how we did not step into this yet :-/

> Codesearch tells me that “aseba” and “speedcrunch” packages may be doing
> a similar thing:
>
> https://codesearch.debian.net/search?q=%5C.qch+path%3A.*%5C.qrc

Well, two more packages wouldn't be much of an issue, but qttools in
itself is :-/

Thanks Dmitry!

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

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

[Dmitry Shachnev]

On Sun, Jul 29, 2018 at 09:17:30PM +0200, John Paul Adrian Glaubitz wrote:
> 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.

There is an example in *this* package (qttools-opensource-src) — Qt Assistant
bundles its own help as a resource:

https://code.qt.io/cgit/qt/qttools.git/tree/src/assistant/assistant/assistant.qrc

Codesearch tells me that “aseba” and “speedcrunch” packages may be doing
a similar thing:

https://codesearch.debian.net/search?q=%5C.qch+path%3A.*%5C.qrc

--
Dmitry Shachnev


signature.asc
Description: PGP signature

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

[Thorsten Glaser]

John David Anglin dixit:

> On 2018-07-29 9:59 PM, Lisandro Damián Nicanor Pérez Meyer wrote:

>> 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

> That looks like it will work.

It will however cause bugreports to pop up because qttools5-dev-tools’
content will not be the same across architectures (and, as it would
affect only d-ports architectures, likely ignored).

Perhaps splitting off qdoc into a separate package could help?

(Incidentally, that would make qdoc available on at least x32 by
foreign Multi-Arch as it could just run the i386 or amd64 version.
Of course not on the buildds, and this is no general solution for
other architectures, but users could use that. It’s not a priority,
of course.)

Another option might be to ask upstream whether there’s a chance
to support qdoc on non-llvm/clang architectures, perhaps a variant
of the last version to not require it.

After all, this does not only affect “obscure” platforms but also
new ones in general, such as arm64 for a while, riscv64 for now,
and porting LLVM is quite the task (GCC would already exist at the
point of them being added to Debian, but there are much more worthy
targets than LLVM in regards to making available, such as OpenJDK
and even GHC…).

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

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

[John David Anglin]

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

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

That looks like it will work.

Thanks,
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 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#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

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

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 27 de julio de 2018 20:45:04 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/28/2018 01:41 AM, Manuel A. Fernandez Montecelo wrote:
> > I was using codesearch.d.n and there are 83 that match "qdoc":
> > https://codesearch.debian.net/search?q=%5CWqdoc%5CW
> 
> Wait a minute. How can there be 83 packages already using qdoc when
> Lisandro just uploaded the version of qttools to unstable which first
> contained the qdoc utility. I am confused.

qdoc is a really old utility, comes from qt4 at very least.


-- 
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/28/2018 02:06 AM, Manuel A. Fernandez Montecelo wrote:
> The packages matching the search contain code matching *.qdoc for
> example, not all necessarily invoke qdoc.  Maybe one can restrict the
> query to calls of qdoc from d/rules, but I think that there will be
> indirect ways to use qdoc (like "make" in docs dir or something).

>From what I understood, QDoc parses the source code and generates
the documentation from the sources and additional comments placed
into it. So, I guess the *.qdoc files you see there might be something
else and it's just a naming clash.

> Anyway, maybe I am misunderstanding the problem, but as I understand
> it (don't know for sure) is that qdoc was there for a long time, it's
> not a new thing, and what changed is that it now uses llvm/clang to
> parse and generate doc instead of some internal code or other external
> parsers.  And the breakage for some ports is that not all of them have
> support in llvm/clang, whereas presumably what they used before was
> OK.

Well, then we could hack something together using the old QDoc for
Ports. But again, I don't think we need to build documentation in
binary-arch targets.

>>> Probably not all of these will actually use it for building (maybe
>>> they will only test if available, and will generate an empty package
>>> or something), others might do it only on -indep as Adrian says.
>>> Almost certainly it will break some package.
>>
>> It shouldn't break any package. Again, building documentation in the
>> binary-arch target should be considered a bug and get fixed.
> 
> That's more or less what I said, in other words.  I am convinced that
> it will cause some breakage, because not all packages are perfect or
> because of corner cases, only that uncovering the breakage is probably
> a good thing in most or all cases, alerting about wrong practices.

I agree. That's also one very good reason why having many different
architectures in Debian are a good thing. It's tremendously useful
to find obscure bugs which might not show on every target.

-- 
 .''`.  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

[Manuel A. Fernandez Montecelo]

2018-07-28 1:45 GMT+02:00 John Paul Adrian Glaubitz
:
> On 07/28/2018 01:41 AM, Manuel A. Fernandez Montecelo wrote:
>> I was using codesearch.d.n and there are 83 that match "qdoc":
>> https://codesearch.debian.net/search?q=%5CWqdoc%5CW
>
> Wait a minute. How can there be 83 packages already using qdoc when
> Lisandro just uploaded the version of qttools to unstable which first
> contained the qdoc utility. I am confused.

The packages matching the search contain code matching *.qdoc for
example, not all necessarily invoke qdoc.  Maybe one can restrict the
query to calls of qdoc from d/rules, but I think that there will be
indirect ways to use qdoc (like "make" in docs dir or something).

Anyway, maybe I am misunderstanding the problem, but as I understand
it (don't know for sure) is that qdoc was there for a long time, it's
not a new thing, and what changed is that it now uses llvm/clang to
parse and generate doc instead of some internal code or other external
parsers.  And the breakage for some ports is that not all of them have
support in llvm/clang, whereas presumably what they used before was
OK.


>> Probably not all of these will actually use it for building (maybe
>> they will only test if available, and will generate an empty package
>> or something), others might do it only on -indep as Adrian says.
>> Almost certainly it will break some package.
>
> It shouldn't break any package. Again, building documentation in the
> binary-arch target should be considered a bug and get fixed.

That's more or less what I said, in other words.  I am convinced that
it will cause some breakage, because not all packages are perfect or
because of corner cases, only that uncovering the breakage is probably
a good thing in most or all cases, alerting about wrong practices.

-- 
Manuel A. Fernandez Montecelo 

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

[John Paul Adrian Glaubitz]

On 07/28/2018 01:41 AM, Manuel A. Fernandez Montecelo wrote:
> I was using codesearch.d.n and there are 83 that match "qdoc":
> https://codesearch.debian.net/search?q=%5CWqdoc%5CW

Wait a minute. How can there be 83 packages already using qdoc when
Lisandro just uploaded the version of qttools to unstable which first
contained the qdoc utility. I am confused.

> Probably not all of these will actually use it for building (maybe
> they will only test if available, and will generate an empty package
> or something), others might do it only on -indep as Adrian says.
> Almost certainly it will break some package.

It shouldn't break any package. Again, building documentation in the
binary-arch target should be considered a bug and get fixed.

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

[Manuel A. Fernandez Montecelo]

2018-07-27 14:48 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
:
> El viernes, 27 de julio de 2018 09:24:46 -03 Manuel A. Fernandez Montecelo
> escribió:
>
> [snip]
>> This page states that:
>>
>>   http://doc.qt.io/qt-5/gettingstarted.html
>>
>>   Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++
>>   header and source files, and for parsing the function signatures in
>>   \fn commands. See Installing clang for QDoc for details.
>>
>> However, if it can be built without these doc tools, for example using
>> Adrian's patch, it would be very nice to try.
>>
>> Not sure if it will break many packages (for these arches), packages
>> might assume that qdoc tools are there, but the alternative is at least
>> equally bad, and potentially worse.
>
> It will also mean that we Qt maintainers will start receiving valid bugs.
> Considering the ratio of work and manpower we have now it's not something we
> would like to deal with. Now if you can somehow chime in here, well, we can
> make an arrangement of some type I guess.
>
> Maybe by opening a bug due to qdoc removal on some archs might help, you could
> subscribe there if needed.

OK, sounds fair, whatever the solution is implemented.

I was using codesearch.d.n and there are 83 that match "qdoc":
https://codesearch.debian.net/search?q=%5CWqdoc%5CW

Probably not all of these will actually use it for building (maybe
they will only test if available, and will generate an empty package
or something), others might do it only on -indep as Adrian says.
Almost certainly it will break some package.

At that point we can intervene and explain to maintainers, or provide
patches, for them to build it as -indep, so it's a win also for the
wide Debian project (building -indep when possible, saving resources,
etc).

-- 
Manuel A. Fernandez Montecelo 

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

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 27 de julio de 2018 10:56:49 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/27/2018 03:51 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> >> I'm 99% sure it's not a hard dependency. It's a documentation utility.
> > 
> > Which is then used by many packages, please check the other mail I have
> > just sent.
> 
> For building documentation in binary-arch packages? Again, we should not
> allow that. It's a waste of disk space and buildd capacity, it's also
> something that the QA tests will complain about.
> 
> > [snip]
> > 
> >>> If for some reason a package build it's doc on an arch-specific build it
> >>> will FTBFS.
> >> 
> >> Then this package is clearly buggy. Documentation is arch-independent and
> >> should never be built per architecture.
> > 
> > You have a point here.
> 
> Ok, so you agree.

Agreed on: packages should not be using qdoc while building arch:any packages. 
Yes, I agree.

Let's wait for your build, but I think you will need to patch the build system 
too.

By the way, qtcreator will start requiring clang too in the next upload. They 
ditched they internal parser in favor of clang, which is clearly better and 
more supported. As I understand this is a plugin, but I don't know how easy 
would be to turn it off, and if the previous parser will still be available.

> > Mm, just noticed you sign as Adrian and not as John, will try to remember
> > that.
> 
> Yes, I go by Adrian despite the order. Don't ask why. My mother thought
> it was funny :P.

I have three names and two surnames, so believe me I have the feeling I 
understand you ;-)


-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

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/27/2018 03:51 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
>> I'm 99% sure it's not a hard dependency. It's a documentation utility.
> 
> Which is then used by many packages, please check the other mail I have just 
> sent.

For building documentation in binary-arch packages? Again, we should not
allow that. It's a waste of disk space and buildd capacity, it's also
something that the QA tests will complain about.

> [snip]
>>> If for some reason a package build it's doc on an arch-specific build it
>>> will FTBFS.
>>
>> Then this package is clearly buggy. Documentation is arch-independent and
>> should never be built per architecture.
> 
> You have a point here.

Ok, so you agree.

> Mm, just noticed you sign as Adrian and not as John, will try to remember 
> that.

Yes, I go by Adrian despite the order. Don't ask why. My mother thought
it was funny :P.

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]

El viernes, 27 de julio de 2018 10:33:48 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/27/2018 02:22 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Don't get me wrong: I also don't like build depending on LLVM [1], but it
> > became a hard dependency. Again, I haven't looked at the code yet (I'm
> > over
> > the transition now), so I'm purely guiding myself from what one of my co
> > maintainers did (and he happens to be in vac).
> > 
> > But what can we do if it became a hard dependency?
> 
> I'm 99% sure it's not a hard dependency. It's a documentation utility.

Which is then used by many packages, please check the other mail I have just 
sent.
 
[snip]
> > If for some reason a package build it's doc on an arch-specific build it
> > will FTBFS.
> 
> Then this package is clearly buggy. Documentation is arch-independent and
> should never be built per architecture.

You have a point here.

> > But on a second thought you might want to tackle those packages yourself.
> > If you like that idea well, we need a patch to disable qdoc compilation
> > probably.
> You don't need to disable QDoc completely. Just use it in a reasonable
> way.
> 
> >>> The only way around I see is submitting patches upstream to avoid clanf
> >>> usage. Remember they need to go directly to upstream, we can't forward
> >>> then
> >>> except for very small changes.
> >> 
> >> Strange policy. Lots of people here take patches from the bugtracker and
> >> forward them upstream. In fact, that's what the official Debian
> >> documentation says.
> > 
> > Yes, but upstream has a CLA in which you don't give copyright permissions
> > *but* allow the Qt Company to use the submitted code in their proprietary
> > version, your code remaining FLOSS for every other aspect.
> 
> *sigh* CLAs suck

Yes, they do.

> > The way they enforce that is by making the real coders push their work to
> > their gerrit instance, for which you previously have to agree to the CLA.
> 
> Yes. I know the deal.
> 
> >> Either way, there are plans to make LLVM available on more targets, there
> >> are already branches working on alpha, m68k, riscv64 and more. Until
> >> then,
> >> it would be nice if Qt wouldn't have a hard dependency on it solely to
> >> build documentation.
> > 
> > Again: I would *love* to. But to the best of my knowledge now, we can't.
> > Of
> > course, I'll be delighted to learn I'm wrong :-)
> 
> I will take care of that - like always :P.

I like that :-)
 
> Adrian

Mm, just noticed you sign as Adrian and not as John, will try to remember 
that.

-- 
Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer
a la comunidad SL como una sarta de fanáticos que viven dentro de un
tupperware.
 Pablo Di Noto - GrULiC

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

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 27 de julio de 2018 10:28:20 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/27/2018 02:48 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It will also mean that we Qt maintainers will start receiving valid bugs.
> > Considering the ratio of work and manpower we have now it's not something
> > we would like to deal with. Now if you can somehow chime in here, well,
> > we can make an arrangement of some type I guess.
> 
> I'm not sure what problem you are seeing here but I don't think that a
> missing documentation generation tool will have any negative impact on
> binary-only builds.
>
> qttools itself is only using qdoc in its binary-arch-indep target why should
> that be any different for any of the other Qt packages?

qdoc is generated two times: one during the binary build in order to ship it 
so other packages can create .qch documentation, and the other during the 
indep build in order to generate qttool's own .qch documentation.


> > Maybe by opening a bug due to qdoc removal on some archs might help, you
> > could subscribe there if needed.
> 
> I'm not sure I understand this statement. If qdoc is not there in the first
> place, how can it be removed?

Does the explanation above solves this? Please do not hesitate in asking me 
again, I want this to be clear.
 
> >> I think that this is similar to the case discussed in #897667, not being
> >> able to build qt4-x11 makes big portions of the archive unbuildable,
> >> many thousands of packages.  Not being able to build
> >> qttools-opensource-src will have a similar effect, I think.
> > 
> > Yes, I'm afraid so. But first we would need patches. I doubt John's patch
> > will work as I think Dmitry built the package first, FTBFS and then he
> > added the llvm dependency. And if qdoc is not being built the .install
> > files need also adjustment.
> 
> The debian/rules file is already written such that it will not build any
> documentation when DEB_HOST_ARCH != DEB_BUILD_ARCH, so unless Dmitry put
> these statements there without any testing, I'm sure you can build qttools
> without qdoc.

Right, qttools but not the other docs.

> > But again, I'll be happy to be shown otherwise.
> 
> Working on it. Waiting for the build dependencies to get built.

Excellent :-)

-- 
perezmeyer: Gus no tiene inet :-(
PabloOdorico: oh
perezmeyer: te mando una copia de lo que hagamos esta noche
PabloOdorico: de ultima mandame un loro del parque con una flash en la pata ;)

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/27/2018 02:22 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Don't get me wrong: I also don't like build depending on LLVM [1], but it 
> became a hard dependency. Again, I haven't looked at the code yet (I'm over 
> the transition now), so I'm purely guiding myself from what one of my co 
> maintainers did (and he happens to be in vac).
> 
> But what can we do if it became a hard dependency?

I'm 99% sure it's not a hard dependency. It's a documentation utility.

>>> I haven't looked at the code but it seems that this dependency is now
>>> required in order to build qdoc, so reducing the severity to wishlist.
>>
>> Well, it's a documentation tool. It should just be possible to disable
>> the documentation tool on the affected architectures.
> 
> It's the tool to generate documentation.

Exactly. And documentation is built in arch:all only anyway.

>>> I don't know if it's possible at all to build everything but qdoc. And the
>>> effect of this could be many packages starting to FTBFS.
>>
>> Unlikely. I don't know any project that has a hard dependency on
>> documentation.
> 
> No no, not the documentation itself, but the tool to create it!

Yes, but you can (and should(!)) build documentation in the binary-arch-indep
target.

> If for some reason a package build it's doc on an arch-specific build it will 
> FTBFS.

Then this package is clearly buggy. Documentation is arch-independent and
should never be built per architecture.

> But on a second thought you might want to tackle those packages yourself. If 
> you like that idea well, we need a patch to disable qdoc compilation probably.

You don't need to disable QDoc completely. Just use it in a reasonable
way.

>>> The only way around I see is submitting patches upstream to avoid clanf
>>> usage. Remember they need to go directly to upstream, we can't forward
>>> then
>>> except for very small changes.
>>
>> Strange policy. Lots of people here take patches from the bugtracker and
>> forward them upstream. In fact, that's what the official Debian
>> documentation says.
> 
> Yes, but upstream has a CLA in which you don't give copyright permissions 
> *but* allow the Qt Company to use the submitted code in their proprietary 
> version, your code remaining FLOSS for every other aspect.

*sigh* CLAs suck

> The way they enforce that is by making the real coders push their work to 
> their gerrit instance, for which you previously have to agree to the CLA.

Yes. I know the deal.

>> Either way, there are plans to make LLVM available on more targets, there
>> are already branches working on alpha, m68k, riscv64 and more. Until then,
>> it would be nice if Qt wouldn't have a hard dependency on it solely to
>> build documentation.
> 
> Again: I would *love* to. But to the best of my knowledge now, we can't. Of 
> course, I'll be delighted to learn I'm wrong :-)
I will take care of that - like always :P.

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 Paul Adrian Glaubitz]

On 07/27/2018 02:48 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> It will also mean that we Qt maintainers will start receiving valid bugs. 
> Considering the ratio of work and manpower we have now it's not something we 
> would like to deal with. Now if you can somehow chime in here, well, we can 
> make an arrangement of some type I guess.

I'm not sure what problem you are seeing here but I don't think that a missing
documentation generation tool will have any negative impact on binary-only
builds.

qttools itself is only using qdoc in its binary-arch-indep target why should
that be any different for any of the other Qt packages?

> Maybe by opening a bug due to qdoc removal on some archs might help, you 
> could 
> subscribe there if needed.

I'm not sure I understand this statement. If qdoc is not there in the first
place, how can it be removed?

>> I think that this is similar to the case discussed in #897667, not being
>> able to build qt4-x11 makes big portions of the archive unbuildable,
>> many thousands of packages.  Not being able to build
>> qttools-opensource-src will have a similar effect, I think.
> 
> Yes, I'm afraid so. But first we would need patches. I doubt John's patch 
> will 
> work as I think Dmitry built the package first, FTBFS and then he added the 
> llvm dependency. And if qdoc is not being built the .install files need also 
> adjustment.

The debian/rules file is already written such that it will not build any
documentation when DEB_HOST_ARCH != DEB_BUILD_ARCH, so unless Dmitry put
these statements there without any testing, I'm sure you can build qttools
without qdoc.

> But again, I'll be happy to be shown otherwise.
Working on it. Waiting for the build dependencies to get built.

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]

El viernes, 27 de julio de 2018 09:24:46 -03 Manuel A. Fernandez Montecelo 
escribió:
> Hi,

Hi Manuel!

[snip]
> This page states that:
> 
>   http://doc.qt.io/qt-5/gettingstarted.html
> 
>   Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++
>   header and source files, and for parsing the function signatures in
>   \fn commands. See Installing clang for QDoc for details.
>
> However, if it can be built without these doc tools, for example using
> Adrian's patch, it would be very nice to try.
>
> Not sure if it will break many packages (for these arches), packages
> might assume that qdoc tools are there, but the alternative is at least
> equally bad, and potentially worse.

It will also mean that we Qt maintainers will start receiving valid bugs. 
Considering the ratio of work and manpower we have now it's not something we 
would like to deal with. Now if you can somehow chime in here, well, we can 
make an arrangement of some type I guess.

Maybe by opening a bug due to qdoc removal on some archs might help, you could 
subscribe there if needed.
 
> I think that this is similar to the case discussed in #897667, not being
> able to build qt4-x11 makes big portions of the archive unbuildable,
> many thousands of packages.  Not being able to build
> qttools-opensource-src will have a similar effect, I think.

Yes, I'm afraid so. But first we would need patches. I doubt John's patch will 
work as I think Dmitry built the package first, FTBFS and then he added the 
llvm dependency. And if qdoc is not being built the .install files need also 
adjustment.

But again, I'll be happy to be shown otherwise.

Cheers, Lisandro.


-- 
I must confess, I was born at a very early age.
 -- Groucho Marx

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

[Lisandro Damián Nicanor Pérez Meyer]

Hi John!

El viernes, 27 de julio de 2018 07:34:16 -03 John Paul Adrian Glaubitz 
escribió:
> > Control: severity -1 wishlist
> 
> Setting a bug which breaks multiple architectures is somewhat of an
> understatement.

Don't get me wrong: I also don't like build depending on LLVM [1], but it 
became a hard dependency. Again, I haven't looked at the code yet (I'm over 
the transition now), so I'm purely guiding myself from what one of my co 
maintainers did (and he happens to be in vac).

But what can we do if it became a hard dependency?

[1] Except some day they keep their API/ABI stable...

> > I haven't looked at the code but it seems that this dependency is now
> > required in order to build qdoc, so reducing the severity to wishlist.
> 
> Well, it's a documentation tool. It should just be possible to disable
> the documentation tool on the affected architectures.

It's the tool to generate documentation.
 
> > I don't know if it's possible at all to build everything but qdoc. And the
> > effect of this could be many packages starting to FTBFS.
> 
> Unlikely. I don't know any project that has a hard dependency on
> documentation.

No no, not the documentation itself, but the tool to create it!

If for some reason a package build it's doc on an arch-specific build it will 
FTBFS.

But on a second thought you might want to tackle those packages yourself. If 
you like that idea well, we need a patch to disable qdoc compilation probably.

> > The only way around I see is submitting patches upstream to avoid clanf
> > usage. Remember they need to go directly to upstream, we can't forward
> > then
> > except for very small changes.
> 
> Strange policy. Lots of people here take patches from the bugtracker and
> forward them upstream. In fact, that's what the official Debian
> documentation says.

Yes, but upstream has a CLA in which you don't give copyright permissions 
*but* allow the Qt Company to use the submitted code in their proprietary 
version, your code remaining FLOSS for every other aspect.

The way they enforce that is by making the real coders push their work to 
their gerrit instance, for which you previously have to agree to the CLA.

So, as we are not the real coders behind patches submitted to us, we can't 
forward them *except* when the patch is so small that it is not 
copyrighteable (a few lines of obvious code, for example).

> Either way, there are plans to make LLVM available on more targets, there
> are already branches working on alpha, m68k, riscv64 and more. Until then,
> it would be nice if Qt wouldn't have a hard dependency on it solely to
> build documentation.

Again: I would *love* to. But to the best of my knowledge now, we can't. Of 
course, I'll be delighted to learn I'm wrong :-)

Regards, Lisandro.

-- 
The POP3 server service depends on the SMTP server service, which
failed to start because of the following error:
The operation completed successfully.
  -- Windows NT Server v3.51

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

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 27 de julio de 2018 07:55:19 -03 John Paul Adrian Glaubitz 
escribió:
> On 07/27/2018 12:34 PM, John Paul Adrian Glaubitz wrote:
> >> I don't know if it's possible at all to build everything but qdoc. And
> >> the
> >> effect of this could be many packages starting to FTBFS.
> > 
> > Unlikely. I don't know any project that has a hard dependency on
> > documentation.
> This part of debian/rules is already written such qdoc is not build for
> cross-builds, so why shouldn't it be possible to disable it for some
> architectures either?

This part is used to build qttools' documentation in a build-indep build. For 
this you need qdoc which is part of the same source package, so you need to 
build it. In the cross build case you can't because you need the build arch's 
qdoc.

But then you also need to build qdoc to be shipped in the binary packages too. 
And that's where the problem begins.

-- 
Programming is really just the mundane aspect of expressing a solution to a
problem. There are talents that are specifically related to actually coding,
but the real issue is being able to grasp problems and devise solutions that
are detailed enough to actually be coded.
  John Carmack answers on Slashdot,
  http://slashdot.org/games/99/10/15/1012230.shtml

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

[Manuel A. Fernandez Montecelo]

Hi,

2018-07-26 21:48 Lisandro Damián Nicanor Pérez Meyer:

Control: severity -1 wishlist

Hi Thorsten!

El jue., 26 de jul. de 2018 14:03, Thorsten Glaser  escribió:


Source: qttools-opensource-src
Version: 5.11.1-3
Severity: important
Justification: fails to build from source (but built successfully in the
past), on d-ports arches

https://buildd.debian.org/status/package.php?p=qttools-opensource-src

LLVM/clang simply is not available for many Debian architectures
as it’s not portable. Please drop the B-D for these architectures.




I haven't looked at the code but it seems that this dependency is now
required in order to build qdoc, so reducing the severity to wishlist.

I don't know if it's possible at all to build everything but qdoc. And the
effect of this could be many packages starting to FTBFS.


This page states that:

 http://doc.qt.io/qt-5/gettingstarted.html

 Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++
 header and source files, and for parsing the function signatures in
 \fn commands. See Installing clang for QDoc for details.

However, if it can be built without these doc tools, for example using
Adrian's patch, it would be very nice to try.

Not sure if it will break many packages (for these arches), packages
might assume that qdoc tools are there, but the alternative is at least
equally bad, and potentially worse.

I think that this is similar to the case discussed in #897667, not being
able to build qt4-x11 makes big portions of the archive unbuildable,
many thousands of packages.  Not being able to build
qttools-opensource-src will have a similar effect, I think.


Cheers.
--
Manuel A. Fernandez Montecelo 

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

[John Paul Adrian Glaubitz]

On 07/27/2018 12:55 PM, John Paul Adrian Glaubitz wrote:
> This part of debian/rules is already written such qdoc is not build for 
> cross-builds,
> so why shouldn't it be possible to disable it for some architectures either?
I will test this patch later. Have to wait for the build dependencies for 
qttools
to be built.

Patch:

diff -Nru old/qttools-opensource-src-5.11.1/debian/control 
new/qttools-opensource-src-5.11.1/debian/control
--- old/qttools-opensource-src-5.11.1/debian/control2018-07-25 
11:41:01.0 +0200
+++ new/qttools-opensource-src-5.11.1/debian/control2018-07-27 
12:58:15.968968584 +0200
@@ -10,11 +10,11 @@
Dmitry Shachnev ,
Simon Quigley 
 Build-Depends: debhelper (>= 11),
-   libclang-dev,
+   libclang-dev [!alpha !hppa !ia64 !m68k !powerpcspe !riscv64 
!sh4 !x32],
libqt5opengl5-dev (>= 5.11.1+dfsg~),
libqt5sql5-sqlite (>= 5.11.1+dfsg~),
libqt5webkit5-dev (>= 5.212.0~alpha2-11~) [!m68k !sparc64],
-   llvm-dev,
+   llvm-dev [!alpha !hppa !ia64 !m68k !powerpcspe !riscv64 !sh4 
!x32],
pkg-kde-tools,
qtbase5-private-dev (>= 5.11.1+dfsg~),
qtdeclarative5-private-dev (>= 5.11.1~),
diff -Nru old/qttools-opensource-src-5.11.1/debian/rules 
new/qttools-opensource-src-5.11.1/debian/rules
--- old/qttools-opensource-src-5.11.1/debian/rules  2018-07-25 
11:41:01.0 +0200
+++ new/qttools-opensource-src-5.11.1/debian/rules  2018-07-27 
13:00:34.712090723 +0200
@@ -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

-- 
 .''`.  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 Paul Adrian Glaubitz]

On 07/27/2018 12:34 PM, John Paul Adrian Glaubitz wrote:
>> I don't know if it's possible at all to build everything but qdoc. And the
>> effect of this could be many packages starting to FTBFS.
> 
> Unlikely. I don't know any project that has a hard dependency on 
> documentation.

This part of debian/rules is already written such qdoc is not build for 
cross-builds,
so why shouldn't it be possible to disable it for some architectures either?

override_dh_auto_clean:
dh_auto_clean
rm -fv .qmake.cache
rm -fv debian/qttools5-dev-tools.install

build-doc-tools:
# Build qdoc, qhelpgenerator and qtattributionsscanner tools

  
cd src; qmake CONFIG+=disable_external_rpath
dh_auto_build -- -Csrc sub-qdoc sub-qtattributionsscanner
cd src/assistant; qmake
dh_auto_build -- -Csrc/assistant sub-qhelpgenerator

override_dh_auto_build-indep: build-doc-tools
cd src/qdoc; qmake
cd src/assistant/help; qmake
dh_auto_build -- docs

ifeq ($(DEB_HOST_ARCH),$(DEB_BUILD_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
dh_auto_build -- -Csrc/assistant/assistant/doc/internal docs
mv doc/assistant.qch src/assistant/assistant/assistant.qch
dh_auto_build
endif

The actual documentation is only generated in override_dh_auto_build-indep
using the build tools generated in build-doc-tools. But if we're not
building any documentation in a binary-arch build, why should we build
the documentation tools either?

For openjdk-X, the documentation is generated using pandoc which isn't
available on every architecture either, yet the binary-arch target of
openjdk-X builds on every architecture.

So, I'm convinced the problem can be solved with better packaging.

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 Paul Adrian Glaubitz]

> Control: severity -1 wishlist

Setting a bug which breaks multiple architectures is somewhat of an
understatement.

> I haven't looked at the code but it seems that this dependency is now
> required in order to build qdoc, so reducing the severity to wishlist.

Well, it's a documentation tool. It should just be possible to disable
the documentation tool on the affected architectures.

> I don't know if it's possible at all to build everything but qdoc. And the
> effect of this could be many packages starting to FTBFS.

Unlikely. I don't know any project that has a hard dependency on documentation.

> The only way around I see is submitting patches upstream to avoid clanf
> usage. Remember they need to go directly to upstream, we can't forward then
> except for very small changes.

Strange policy. Lots of people here take patches from the bugtracker and
forward them upstream. In fact, that's what the official Debian documentation
says.

Either way, there are plans to make LLVM available on more targets, there are
already branches working on alpha, m68k, riscv64 and more. Until then, it
would be nice if Qt wouldn't have a hard dependency on it solely to build
documentation.

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]

Control: severity -1 wishlist

Hi Thorsten!

El jue., 26 de jul. de 2018 14:03, Thorsten Glaser  escribió:

> Source: qttools-opensource-src
> Version: 5.11.1-3
> Severity: important
> Justification: fails to build from source (but built successfully in the
> past), on d-ports arches
>
> https://buildd.debian.org/status/package.php?p=qttools-opensource-src
>
> LLVM/clang simply is not available for many Debian architectures
> as it’s not portable. Please drop the B-D for these architectures.
>


I haven't looked at the code but it seems that this dependency is now
required in order to build qdoc, so reducing the severity to wishlist.

I don't know if it's possible at all to build everything but qdoc. And the
effect of this could be many packages starting to FTBFS.

The only way around I see is submitting patches upstream to avoid clanf
usage. Remember they need to go directly to upstream, we can't forward then
except for very small changes.

Regards, Lisandro.

>

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

[Thorsten Glaser]

Source: qttools-opensource-src
Version: 5.11.1-3
Severity: important
Justification: fails to build from source (but built successfully in the past), 
on d-ports arches

https://buildd.debian.org/status/package.php?p=qttools-opensource-src

LLVM/clang simply is not available for many Debian architectures
as it’s not portable. Please drop the B-D for these architectures.