Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64
2 views
Skip to first unread message
John Paul Adrian Glaubitz
Jun 19, 2020, 2:30:03 AM6/19/20
to
Source: libreoffice
Version: 1:7.0.0~beta2-1
Severity: normal
User: debian...@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 - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Version: 1:7.0.0~beta2-1
Severity: normal
User: debian...@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 - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
re...@rene-engelhard.de
Jun 19, 2020, 7:20:02 AM6/19/20
to
Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz <glau...@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.
>>> 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
>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
Rene Engelhard
Jun 19, 2020, 1:20:02 PM6/19/20
to
Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 1:08 PM, re...@rene-engelhard.de wrote:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz <glau...@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:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz <glau...@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.
>
>
>> 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.
>
> 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
Rene Engelhard
Jun 19, 2020, 1:30:02 PM6/19/20
to
Hi,
Am 19.06.20 um 19:19 schrieb John Paul Adrian Glaubitz:
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
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.
>> 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.
>
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
re...@rene-engelhard.de
Jun 23, 2020, 6:40:03 AM6/23/20
to
Hi,
Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller <del...@gmx.de>:
>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, re...@rene-engelhard.de wrote:
>>>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
><glau...@physik.fu-berlin.de>:
>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&arch=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.
>[...]
>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
Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller <del...@gmx.de>:
>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, re...@rene-engelhard.de wrote:
>>>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz
><glau...@physik.fu-berlin.de>:
>>> 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.
>LibreOffice on non-release
>>> architectures given these circumstances.
>>
>> It is. That line 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).
>
>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&arch=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
>>> 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.
>
>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
re...@rene-engelhard.de
Jun 23, 2020, 7:30:03 AM6/23/20
to
>On 23.06.20 12:33, re...@rene-engelhard.de wrote:
>> Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller <del...@gmx.de>:
>>> 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,
>> Am 23. Juni 2020 12:05:18 MESZ schrieb Helge Deller <del...@gmx.de>:
>>> I'm one of the maintainers for the hppa/parisc architecture....
>>
>> Which didn't build since 2018. And is constantly bd-uninststallable.
>
>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
Skye
Jun 23, 2020, 9:10:02 AM6/23/20
to
> 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
John Paul Adrian Glaubitz
Jan 11, 2023, 1:52:29 PM1/11/23
to
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!
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
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
John Paul Adrian Glaubitz
Jan 11, 2023, 2:10:05 PM1/11/23
to
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,
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.
Thanks,
0 new messages