[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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/

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


Reply to: