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

2023-01-11 Thread John Paul Adrian Glaubitz

Hi!

On 1/11/23 19:45, John Paul Adrian Glaubitz wrote:

Attaching a patch which modifies debian/rules accordingly so that the build 
dependencies
are corrected after running "debian/rules debian/control".

Please consider including it for the next upload.


Oops, I just realized I forgot to add the line for "llvm". Please find an 
updated patch.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig	2022-12-29 23:21:43.0 +
+++ debian/rules	2023-01-11 18:53:56.537857661 +
@@ -688,7 +688,7 @@
 else
   ifeq "$(ALLOW_CLANG)" "y"
 ifeq "$(CLANG_VERSION)" "default"
-	  BUILD_DEPS += , llvm [$(OOO_LE_ARCHS)]
+	  BUILD_DEPS += , llvm [$(filter-out alpha ia64,$(OOO_LE_ARCHS))]
 else
 	  BUILD_DEPS += , llvm-$(CLANG_VERSION)-linker-tools [$(OOO_LE_ARCHS)]
 endif
@@ -766,7 +766,7 @@
   ifeq "$(CLANG_VERSION)" "default"
 	export LO_CLANG_CC=clang
 	export LO_CLANG_CXX=clang++
-	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))]
+	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))]
 	# see #963162, #963167 which apparently don't exist on 11
 	BUILD_DEPS += , clang (>= 1:11) [armel]
   else


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

2023-01-11 Thread John Paul Adrian Glaubitz

Control: tags -1 +patch

Hi!

Attaching a patch which modifies debian/rules accordingly so that the build 
dependencies
are corrected after running "debian/rules debian/control".

Please consider including it for the next upload.

Thanks a lot!
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig	2022-12-29 23:21:43.0 +
+++ debian/rules	2023-01-11 18:40:30.535026543 +
@@ -766,7 +766,7 @@
   ifeq "$(CLANG_VERSION)" "default"
 	export LO_CLANG_CC=clang
 	export LO_CLANG_CXX=clang++
-	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))]
+	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))]
 	# see #963162, #963167 which apparently don't exist on 11
 	BUILD_DEPS += , clang (>= 1:11) [armel]
   else


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

2020-06-23 Thread Skye
> Why do I need to be helpful to dead architectures unless it's a LO issue?

Because it is what we do as maintainers.  So much of what we do, in this case 
don't do, has knock-on consequences across open source.

Cheers

Skye


-Original Message-
From: r...@rene-engelhard.de [mailto:r...@rene-engelhard.de] 
Sent: Tuesday, June 23, 2020 4:34 AM
To: Helge Deller; John Paul Adrian Glaubitz
Cc: 963...@bugs.debian.org; debian-al...@lists.debian.org; debian-ia64
Subject: Re: Bug#963109: libreoffice: Please drop clang from build-dependencies 
for alpha and ia64

Hi,

Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller :
>Hello Rene,
>
>I'm one of the maintainers for the hppa/parisc architecture

Which didn't build since 2018. And is constantly bd-uninststallable.

>On 19.06.20 19:12, Rene Engelhard wrote:
>> Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
>>> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
>>>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
>:
>>> 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.
>
>Sure does it needs to be maintained.
>And for that reason it's important to get libreoffice built on the
>non-release architectures.

No, why?

And please maintain your port wrt installabity of packages before me accusing 
of not caring, thanks.

>> 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).
>
>Yes, I'm sure Adrian will fix lots of issues in libreoffice for those
>architectures

I am not.

You haven't even remotely looked at the link did you? Look at how long alpha is 
broken?

>He did in the past together with the ports maintainers.
>Speaking for hppa, libreoffice was fixed in 2017, then cleanly compiled
>until 2018:
>https://buildd.debian.org/status/logs.php?pkg=libreoffice=hppa

Wow, 2018. We are mid-2020.

I know he contributed patches for some Arch's (e.g. m68k), that does not change 
e.g. the alpha situation.

>[...]
>
>>> 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.
>
>It would be really nice and helpful for the debian-ports platforms if
>you would
>merge those, unless they break the release architectures.

Why do I need to be helpful to dead architectures unless it's a LO issue?

It is not a new architecture where I could understand this until it's 
up-to-date - it's dead ones.

Regards

Rene



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

2020-06-23 Thread Helge Deller
On 23.06.20 13:22, r...@rene-engelhard.de wrote:
> Am 23. Juni 2020 13:07:42 MESZ schrieb Helge Deller :
>>> Which didn't build since 2018. And is constantly bd-uninststallable.
>>
>> If you apply Adrian's patch which drops dependency on clang,
>> then it maybe get's bd-installable again?
>
> No?
> Read the buildd page (for sid) and do a minimal research. You have no clue 
> what you are talking about
>  It's not clang here. And the clang thing is new since done days, not years.

That was an example. For hppa it's fontforge now. Before it was java stuff. 
Whatever.
The point is: If we provide patches, we need your willingness to apply patches.

Helge



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

2020-06-23 Thread rene
Am 23. Juni 2020 13:07:42 MESZ schrieb Helge Deller :
>Hello Rene,
>
>On 23.06.20 12:33, r...@rene-engelhard.de wrote:
>> Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller :
>>> I'm one of the maintainers for the hppa/parisc architecture
>>
>> Which didn't build since 2018. And is constantly bd-uninststallable.
>
>If you apply Adrian's patch which drops dependency on clang,
>then it maybe get's bd-installable again?

No?

Read the buildd page (for sid) and do a minimal research. You have no clue what 
you are talking about 

 It's not clang here. And the clang thing is new since done days, not years.

Regards,

Rene



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

2020-06-23 Thread Helge Deller
Hello Rene,

On 23.06.20 12:33, r...@rene-engelhard.de wrote:
> Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller :
>> I'm one of the maintainers for the hppa/parisc architecture
>
> Which didn't build since 2018. And is constantly bd-uninststallable.

If you apply Adrian's patch which drops dependency on clang,
then it maybe get's bd-installable again?


>> On 19.06.20 19:12, Rene Engelhard wrote:
>>> Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
 On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
>> :
 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.
>>
>> Sure does it needs to be maintained.
>> And for that reason it's important to get libreoffice built on the
>> non-release architectures.
>
> No, why?

It's a chain of package dependecies. If one fails, all other behind that
package fail too.

> And please maintain your port wrt installabity of packages before me accusing 
> of not caring, thanks.

For that we need your help.
E.g. there is no plan to support clang on hppa.

>>> 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).
>>
>> Yes, I'm sure Adrian will fix lots of issues in libreoffice for those
>> architectures
>
> I am not.

That's ok.
You don't need to, unless you want to.
The ask is, that you accept correct patches if they don't hurt you.

> You haven't even remotely looked at the link did you? Look at how long alpha 
> is broken?

Does it matter?
There are people who want to fix things and need your help.

>> He did in the past together with the ports maintainers.
>> Speaking for hppa, libreoffice was fixed in 2017, then cleanly compiled
>> until 2018:
>> https://buildd.debian.org/status/logs.php?pkg=libreoffice=hppa
>
> Wow, 2018. We are mid-2020.
>
> I know he contributed patches for some Arch's (e.g. m68k), that does not 
> change e.g. the alpha situation.

Adrian contributes a LOT for all non-ports architectures.
Patches for m68k often fix other ports too.

>> [...]
>>
 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.
>>
>> It would be really nice and helpful for the debian-ports platforms if
>> you would
>> merge those, unless they break the release architectures.
>
> Why do I need to be helpful to dead architectures unless it's a LO issue?
> It is not a new architecture where I could understand this until it's 
> up-to-date - it's dead ones.

Because some people still do care.
If it doesn't hurt you, why should you worry?

Helge



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

2020-06-23 Thread rene
Hi,

Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller :
>Hello Rene,
>
>I'm one of the maintainers for the hppa/parisc architecture

Which didn't build since 2018. And is constantly bd-uninststallable.

>On 19.06.20 19:12, Rene Engelhard wrote:
>> Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
>>> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
 Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
>:
>>> 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.
>
>Sure does it needs to be maintained.
>And for that reason it's important to get libreoffice built on the
>non-release architectures.

No, why?

And please maintain your port wrt installabity of packages before me accusing 
of not caring, thanks.

>> 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).
>
>Yes, I'm sure Adrian will fix lots of issues in libreoffice for those
>architectures

I am not.

You haven't even remotely looked at the link did you? Look at how long alpha is 
broken?

>He did in the past together with the ports maintainers.
>Speaking for hppa, libreoffice was fixed in 2017, then cleanly compiled
>until 2018:
>https://buildd.debian.org/status/logs.php?pkg=libreoffice=hppa

Wow, 2018. We are mid-2020.

I know he contributed patches for some Arch's (e.g. m68k), that does not change 
e.g. the alpha situation.

>[...]
>
>>> 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.
>
>It would be really nice and helpful for the debian-ports platforms if
>you would
>merge those, unless they break the release architectures.

Why do I need to be helpful to dead architectures unless it's a LO issue?

It is not a new architecture where I could understand this until it's 
up-to-date - it's dead ones.

Regards

Rene



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

2020-06-23 Thread Helge Deller
Hello Rene,

I'm one of the maintainers for the hppa/parisc architecture

On 19.06.20 19:12, Rene Engelhard wrote:
> Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
>> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
>>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz 
>>> :
>> 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.

Sure does it needs to be maintained.
And for that reason it's important to get libreoffice built on the non-release 
architectures.

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

Yes, I'm sure Adrian will fix lots of issues in libreoffice for those 
architectures.
He did in the past together with the ports maintainers.
Speaking for hppa, libreoffice was fixed in 2017, then cleanly compiled until 
2018:
https://buildd.debian.org/status/logs.php?pkg=libreoffice=hppa


[...]

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

It would be really nice and helpful for the debian-ports platforms if you would
merge those, unless they break the release architectures.

Thanks!
Helge



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

2020-06-19 Thread Rene Engelhard
Hi,

Am 19.06.20 um 19:19 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 7:12 PM, Rene Engelhard wrote:
>> 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.
> 
> I'll ask the CTTE then.

lol.

> No idea why you have to turn such a simple request into
> such a drama.

*You* turn it in a drama.

I asked for a very simple and modest change and your only answer
> is to turn this into such a long pointless discussion basically telling me I
> shouldn't be doing what I'm doing.

*You* started the debate. I (implicitely, even before, by the comment in
rules and in a message explicity) said I will stay with upstream here,
you continued and trolled about debian/patches when I did so.

Some times you just need to accept maintainers' decisions and not waste
their times with this (indeed) useless discussion.

Regards,

Rene



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

2020-06-19 Thread John Paul Adrian Glaubitz
On 6/19/20 7:12 PM, Rene Engelhard wrote:
> 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.

I'll ask the CTTE then. No idea why you have to turn such a simple request into
such a drama. I asked for a very simple and modest change and your only answer
is to turn this into such a long pointless discussion basically telling me I
shouldn't be doing what I'm doing.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



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

2020-06-19 Thread Rene Engelhard



Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz 
>> :
>>> 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



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

2020-06-19 Thread John Paul Adrian Glaubitz
On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz 
> :
>> 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".

 Not sure why you want to enforce architectures off libreoffice when
 it’s technically not necessary.
>>>
>>> Read the comment.
>>
>> That's just your personal way of implementing it. It's not mandatory to
>> do it
>> this way. You can just create a simple whitelist where clang is always
>> enabled
>> and disabled on any other architecture. It's not really rocket science.
> 
> 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.

>> 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. There is no paragraph in the Debian 
Policy
to base this decision on nor are there any technical reasons.

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

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



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

2020-06-19 Thread rene
Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz 
:
>So nothing that keeps us from using GCC in cases where clang is not
>available.

Correct. Except staying as close as possible with upstream.

>>> Not sure why you want to enforce architectures off libreoffice when
>>> it’s technically not necessary.
>> 
>> Read the comment.
>
>That's just your personal way of implementing it. It's not mandatory to
>do it
>this way. You can just create a simple whitelist where clang is always
>enabled
>and disabled on any other architecture. It's not really rocket science.

Trust me, I know. I do this for all kind of stuff in rules (e.g. for skia 
itself, see below)

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

Regards

Rene



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

2020-06-19 Thread John Paul Adrian Glaubitz
On 6/19/20 10:08 AM, r...@rene-engelhard.de wrote:
> Am 19. Juni 2020 09:58:34 MESZ schrieb John Paul Adrian Glaubitz 
> :
> 
>> clang isn’t required to build libreoffice [1], it’s just recommend.
> 
> I know. That is even documented:
> 
> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/debian-experimental-7.0/rules
> 
> Line 617ff.

So nothing that keeps us from using GCC in cases where clang is not available.

>> Not sure why you want to enforce architectures off libreoffice when
>> it’s technically not necessary.
> 
> Read the comment.

That's just your personal way of implementing it. It's not mandatory to do it
this way. You can just create a simple whitelist where clang is always enabled
and disabled on any other architecture. It's not really rocket science.

> Besides that it is obsolete non-release architectures. It's not armel where
> I might need to think of a plan b given the FTBFS...
Asking me (and the other porters) to port LLVM to a given architecture when it's
actually a tremendous work effort because you insist on using clang even if 
there
are no valid technical reasons, is not what I consider to be cooperative and
fair in an open-source community.

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.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



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

2020-06-19 Thread rene
Am 19. Juni 2020 09:58:34 MESZ schrieb John Paul Adrian Glaubitz 
:
>
>Not sure why you want to enforce architectures off libreoffice when
>it’s technically not necessary.

And besides what I said earlier those architectures are already forcing them 
off *themselves*.

alpha: https://buildd.debian.org/status/logs.php?pkg=libreoffice=alpha

No alpha porter in any way coming up with anything. 

Regards

Rene



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

2020-06-19 Thread rene
Hi,

Am 19. Juni 2020 09:58:34 MESZ schrieb John Paul Adrian Glaubitz 
:

>clang isn’t required to build libreoffice [1], it’s just recommend.

I know. That is even documented:

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/debian-experimental-7.0/rules

Line 617ff.

>Not sure why you want to enforce architectures off libreoffice when
>it’s technically not necessary.

Read the comment.

Besides that it is obsolete non-release architectures. It's not armel where I 
might need to think of a plan b given the FTBFS...

Regards

Rene



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

2020-06-19 Thread John Paul Adrian Glaubitz


> On Jun 19, 2020, at 9:53 AM, r...@rene-engelhard.de wrote:
> 
> severity 963109 wishlist
> tag 963109 + wontfix
> thanks
> 
> Am 19. Juni 2020 08:24:57 MESZ schrieb John Paul Adrian Glaubitz 
> :
>> I just noticed that src:libreoffice 7.x has added a build dependency on
>> clang
>> for alpha and ia64. However, clang is unfortunately no longer available
>> on
>> these targets which causes libreoffice to become BD-Uninstallable.
> 
> No.
> 
> The correct solution would be to get clang available.
> 
> (Or simply ignore those obsolete architectures)

clang isn’t required to build libreoffice [1], it’s just recommend.

Not sure why you want to enforce architectures off libreoffice when it’s 
technically not necessary.

Thanks,
Adrian

> [1] 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=647499ef8151d9383983f89230a970edcb44b5bb

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

2020-06-19 Thread rene
severity 963109 wishlist
tag 963109 + wontfix
thanks

Am 19. Juni 2020 08:24:57 MESZ schrieb John Paul Adrian Glaubitz 
:
>I just noticed that src:libreoffice 7.x has added a build dependency on
>clang
>for alpha and ia64. However, clang is unfortunately no longer available
>on
>these targets which causes libreoffice to become BD-Uninstallable.

No.

The correct solution would be to get clang available.

(Or simply ignore those obsolete architectures)

Regards

Rene



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

2020-06-19 Thread John Paul Adrian Glaubitz
Source: libreoffice
Version: 1:7.0.0~beta2-1
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha ia64

Hello!

I just noticed that src:libreoffice 7.x has added a build dependency on clang
for alpha and ia64. However, clang is unfortunately no longer available on
these targets which causes libreoffice to become BD-Uninstallable.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913