Re: unbreaking LibreOffices tests on at least release architectures
On Sunday 2023-06-18 23:37, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. That may be a general problem not specific to Libreoffice, or any one particular project. As software grows to accomodate more features, it reaches a size where it is "good enough" for users that they no longer feel a need to invest time anymore as their needs are already satisfied, while at the same time, it has become so large for others to not want to touch it anymore. Chromium sucks to touch. On the other hand, the Linux kernel has evermore developers each round, and Linux distros have more packages than ever before. So not all seems to be bad? Modularization seems key, and that may just be what separates projects.
Re: unbreaking LibreOffices tests on at least release architectures
On 6/18/23 15:19, Rene Engelhard wrote: > Besides that it would also have been clear from actually reading the IRC > log which incidentially also says Good to know what the expectations for participation are. >> This is the same GPLv3 package that Red Hat just dropped support for? > > As I said in my other reply, even if it was GPLv3 it wouldn't be > relevant at all. > > LibreOffice is not GPLv3 though and never was. I paid close attention to the project's launch back in the day. Back when LibreOffice forked away Oratroll's acquisition of Sun in 2010, they used (L)GPLv3 to prevent OpenOffice from merging their changes. Then OpenOffice got unloaded on apache.org after the fact, and it all got weirdly political. Then Google bought Writely and did google docs which could edit and save a word file which scooped up most of the userbase, and LibreOffice decided it should also run in a web browser... https://lwn.net/Articles/637830/ I know they regretted their GPLv3 stance early on, and were talking about NEW code being in a different license: https://lwn.net/Articles/498898/ But last I'd heard, while Apache's version had audited to relicense LibreOffice had not yet done a full audit: https://lwn.net/Articles/927096/ *shrug* I acknowledge I'm out of date here. If you say they're not v3 anymore, good for them. Seems I'm not the only one who hadn't heard about it, though. The last couple cubicle farms I consulted at still had LibreOffice on their "not allowed" lists, but the most recent of those was 2021 so that's old news. I only spoke up on the perception you were advocating for the removal of architectures I care about. Glad to hear that's not the case. Back to lurking... Rob
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On 6/18/23 14:58, Rene Engelhard wrote: >> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and >> the AGPL have been rejected soundly by most developers" and talked about how >> he >> regretted the move and the damage it had done to the project, >> https://archive.org/details/copyleftconf2020-allison > > Can we please talk about the actual issue at and - that is not the license. The issue is the number of developers engaging with this package have declined to the point problems have gone unnoticed and unfixed for a long time. >> How long has the problem you're treating as a crisis been brewing? > > Far too long, as I said it was swept under the carpet for too long. Because the developers went away. Rob
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
On 6/18/23 03:45, Rene Engelhard wrote:> Am 18.06.23 um 10:32 schrieb Rene Engelhard: I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... >>> You want Debian to drop support for all architectures except amd64 and >>> arm64 >>> because a single package doesn't pass its testsuite on the other >>> architectures? >> >> If the "porters" of those architectures don't care about the tests, yes, >> this would be the ultimate result. >> >> And as the release team agrees with me... > > Well, actually I was too tired still. But the tone from my initial mail > was quite clear. I know you WANT to misread that and I fell into that trap No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. > Of course I mean "getting those architectures removed from unstable" > *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? https://lwn.net/Articles/933525/ When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison How long has the problem you're treating as a crisis been brewing? Rob
Re: unbreaking LibreOffices tests on at least release architectures
> Le 18 juin 2023 à 13:37, Steve McIntyre a écrit : > > On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >> Hi, >> >>> Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >>> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: Also note I am not talking about the debian-ports architectures. Those I forgot and I have no problems making them stay into "testsuite ran but results ignored" set. >>> Why did you send this mail exclusively to debian-ports then? >> >> I (obviously) wrongly assumed that this was the magic address which >> duplicates to every port. >> >> Must have misremembered. > > It still does - I got this copy via the debian-arm list... > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > "This dress doesn't reverse." -- Alden Spiess > Same for me, I received it through the Debian-ppc list -someone
Re: unbreaking LibreOffices tests on at least release architectures
On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >Hi, > >Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: >> > Also note I am not talking about the debian-ports architectures. Those I >> > forgot and I have no problems making them stay into "testsuite ran but >> > results ignored" set. >> Why did you send this mail exclusively to debian-ports then? > >I (obviously) wrongly assumed that this was the magic address which >duplicates to every port. > >Must have misremembered. It still does - I got this copy via the debian-arm list... -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: unbreaking LibreOffices tests on at least release architectures
Hi again. Am 18.06.23 um 10:32 schrieb Rene Engelhard: I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? If the "porters" of those architectures don't care about the tests, yes, this would be the ultimate result. And as the release team agrees with me... Well, actually I was too tired still. But the tone from my initial mail was quite clear. I know you WANT to misread that and I fell into that trap Of course I mean "getting those architectures removed from unstable" *for libreoffice*. (which again should be obvious), not removing those architectures from unstable alltogether. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: Also note I am not talking about the debian-ports architectures. Those I forgot and I have no problems making them stay into "testsuite ran but results ignored" set. Why did you send this mail exclusively to debian-ports then? I (obviously) wrongly assumed that this was the magic address which duplicates to every port. Must have misremembered. Right now, the only architectures where the test actually work (ignoring the occassional breakage on arm64 which is fixed upstream since they do aarch64 flatpak builds) is amd64 and arm64. (...) I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? If the "porters" of those architectures don't care about the tests, yes, this would be the ultimate result. And as the release team agrees with me... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hello! On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: > Also note I am not talking about the debian-ports architectures. Those I > forgot and I have no problems making them stay into "testsuite ran but > results ignored" set. Why did you send this mail exclusively to debian-ports then? > Right now, the only architectures where the test actually work (ignoring > the occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > (...) > I don't really like sweeping it under the carpet again and would > actually pursue the "getting those architectures removed from unstable" > way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
unbreaking LibreOffices tests on at least release architectures
Hi, I originally wanted to send the mail after all the architectures got result but now even after 6d mips64el didn't try it so I send it now. Prompted by riscv64 supposed to be added to the archive and even as a release arch for trixie - see https://lists.debian.org/debian-devel-announce/2023/06/msg1.html - I looked at the libreoffice tests and thought was quite miserable). Which prompted a discussion in #debian-release, too - see [1]. Since the that upload its tests (expectedly) fail: https://buildd.debian.org/status/package.php?p=libreoffice (which is expected, yee below) For riscv64 I already pointed that out in the thread starting at https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the other architectures there is the mail now. riscv64 is different because the failures are even more big than any other down below and it's actually a new architecture anyway. Also note I am not talking about the debian-ports architectures. Those I forgot and I have no problems making them stay into "testsuite ran but results ignored" set. Right now, the only architectures where the test actually work (ignoring the occassional breakage on arm64 which is fixed upstream since they do aarch64 flatpak builds) is amd64 and arm64. With various different 32-bit, endian and whatever else breakage ppopping up the other architectures constantly were moved in the set where the testsuite was run but the results were ignored. For s390x, where the macros tests hangs it even was in the set where the tests even were not ran, since a hang then also ends up in "E: Build killed with signal TERM after 150 minutes of inactivity". This was sweeping under the carpet for sure, but this was needed due to it being a release architecture :( Can the porters please have a look at libreoffice in their favourite port(s) and fix it? I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes (though to limited space there one needs to apply some space-saving hacks like -g1 or no -g or disable -nogui and whatever). I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... Regards, Rene [1] 17:18 < _rene_> elbrus: uargs, could that riscv64 thingy be announced with a message that porters actually have to care about their port then? 17:18 < elbrus> jmw: I'm amazed at what you're able to comment on today; thanks for your help 17:18 < elbrus> _rene_: please elaborate? 17:19 < _rene_> elbrus: (which is not the case for "let's port, we know the test breaks miserably, but let's fix that later)" 17:19 < _rene_> where later is probably "never" 17:19 < _rene_> (as for libreoffice and riscv64) 17:20 < elbrus> if the test breaks your build, your package doesn't build on the architecture and you might not care until a porter fixes it? 17:20 < _rene_> test results are ignored (for now). 17:20 < elbrus> only on that arch? 17:21 < elbrus> why not let it fail the build? 17:21 < _rene_> if I would do that (which would be correct) I would also loose s390x, mips*, ... 17:21 < elbrus> until the test is fixed? 17:21 < elbrus> yes, and...? 17:21 < _rene_> been there, done that, no porter actions 17:21 < elbrus> you're only trouble is that for those archs you'd need to remove existing binaries 17:22 < elbrus> for a *new* architecture, if you never build in the official archive, there's nothing "broken" 17:22 < elbrus> it's not a bad thing if you package FTBFS always on an architecture 17:22 < elbrus> as long as it never passes to buidl 17:22 < elbrus> build 17:23 < elbrus> arch:all needs to build on amd64 though 17:23 < _rene_> sure 17:23 < _rene_> the other archs where the tests are fatal right now is amd64 and arm64 :) 17:23 < _rene_> s/other/only/ 17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64 17:25 < smcv> next best thing would be make them fatal everywhere except selected known-bad architectures where the failures are known not to be a big deal 17:25 < smcv> (we do that in gnome sometimes) 17:25 < elbrus> that's close to what I mean 17:26 < _rene_> 17:25 < elbrus> extreme case you only ship on amd64 and arm64 17:26 < _rene_> that's what would be the outcome, yes 17:26 < elbrus> point being, with my Release Team member hat on here, I want porters to be more active in fixing architecture specific issues 17:26 < smcv> so, pseudocode: if ! tests-passed && arch not in (mipsel, s390x, armhf): ftbfs 17:26 < _rene_> even i386 and armhf would be at risk then 17:27 < elbrus> fine with me 17:27 < smcv> if libreoffice doesn't work on those archs then those archs can ship without libreoffice 17:27 <@jmw> looks like we are within striking of image testing; all live stuff is in progress, 2/5
