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".
*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
Reply to: