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

Re: 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, rene@rene-engelhard.de wrote:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>:
>>> 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".


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

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




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

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

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



Reply to: