Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 1:08 PM, [email protected] wrote:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz <[email protected]>:
>>> So nothing that keeps us from using GCC in cases where clang is not
>>> available.
>>
>> Correct. Except staying as close as possible with upstream.
> 
> While at the same time, the source contains 20+ patches:
> 
>> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/tree/debian-experimental-7.0/patches
> 
> I wouldn't consider that "close to upstream".

*Shrugs*

That shows you haven't even cared to actually have looked at the patch
names but just counting. That is not sensible and just a pure trolling
attempt.

Some patches are needed for proper packaging.

Some patches are requires by policy.

Some patches fix bugs.

Some patches fix FTBFSes.

Some patches are simply minor.

Where a difference to upstream is not actually needed, why do one?

>>>> and disabled on any other architecture. It's not really rocket scien
>>
>> Trust me, I know. I do this for all kind of stuff in rules (e.g. for skia itself, see below)
> 
> This isn't a technical argument though.

*You* said it's not rocket science and implied I wouldn't be able to do so.

>>> It's also not a given that clang generates faster code on _any_ given
>>> architecture,
>>> it might be true for x86_64, but not necessarily for armhf or s390x.
>>
>> s390x doesn't matter here at all as it is be and skia doesn't support be at all. Thus we get --disable-skia and thus no clang usage.
>>
>> But generally you're right, but I am trying to stay as close upstream as possible here.
> 
> Again, this isn't a compelling technical argument. There is no additional workload
> involved if you allow building LO with GCC on non-clang architectures and it also
> does not cause harm any of the release architectures. You are not required to fix
> any code that doesn't build on a non-release architecture, that's what we porters
> are for.
[...]
> I have honestly no clue why you would deny porters to build
LibreOffice on non-release
> architectures given these circumstances.

It is. That line needs to be maintained.

Ah, right, so you fix the stuff?

- alpha broken for ages
- hppa broken for ages
- sparc64 BD-Unistallable for ages due to KDE
- kfreebsd-* BD-Uninstallable for ages

See

https://buildd.debian.org/status/package.php?p=libreoffice

(sid).

Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
m68k even didn't yet do a ICU rebuild or at least make stuff being
rebuildable.

You mean on alpha where you even were not able to keep it building for a
long time? Don't blame your non-action here.

Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
m68k even didn't yet do a ICU rebuild or at least make stuff being
rebuildable.

> Would it be okay if I send a pull request to make the necessary changes?

I am perfectly able to implement what you want. But whatever.

You can send any pull request.

That doesn't mean I'll merge it.

Regards,

Rene