Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: