• unbreaking LibreOffices tests on at least release architectures

    From Rene Engelhard@21:1/5 to All on Sun Jun 18 09:40:01 2023

    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/msg00001.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/msg00000.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...



    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
    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 remaining normal tests are in progress
    and there are 5 edus to do
    17:28 < ansgar> Excellent :-) Then we might be ready much earlier than
    for bullseye, even though we started later.
    17:29 < aurel32> as a porter, i would appreciate if maintainers do no
    expect that porters 1) use 100% of the packages in the archive 2) read
    100% of the build logs
    17:30 < Ganneff> wait what, you dont read each and every log?
    17:30 < aurel32> asking for help, or failing a build log in case of real problem would be appreciatedBus error (core dumped)
    17:31 < aurel32> ignoring issues during the build but then later
    complaining that nobody fix them is not appreciated
    17:31 < _rene_> aurel32: for 2) they know, it was part of the upstream
    17:32 < _rene_> aurel32: and whoever the debian risc64 guy was also
    knows since he was closely working with that guy using the upstream work
    17:33 -!- Magician24 [~oftc-webi@] has joined #debian-release 17:34 < aurel32> ok *one* of the porters probably knows. Personally I
    didn't until now
    17:34 < _rene_> aurel32: and for the others: do you really believe I
    didn't try to talk to mips*, s390x, ...
    17:35 < _rene_> (or for that matter, i386)
    17:35 < aurel32> Ganneff: ansgar: speaking of riscv64, when can we get
    the architecture into the archive?
    17:36 < _rene_> aurel32: but we can try, I'll make all architectures
    fatal then...
    17:37 < Ganneff> aurel32: i havent followed anything relating to new architectures, so currently know nothing about it. But if ansgar doesn't
    have time/energy soon for it, I can start taking a look.
    17:37 < ansgar> aurel32: I guess fairly soon?
    17:37 < Ganneff> good
    17:38 -!- Magician24 [~oftc-webi@] has quit [Quit: Page
    17:39 < elbrus> aurel32: just to confirm, I also think you as a porter
    also don't expect maintainers to fix all issues on official architectures
    17:39 < elbrus> so it's a matter of communication
    17:39 < _rene_> elbrus, aurel32: https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/5f0da7fd088ef81cef4e7a31ec40eb34281342c3
    17:39 < elbrus> if there's an architecture specific issue, pull porters
    in for help
    17:40 < elbrus> and try to figure it out together
    17:40 < elbrus> if the problem is too difficult (for the time being)
    dropping the architecture (for the time being) is an acceptable solution
    17:40 < _rene_> oh, wait OOO_CHECK_ARCHS, too (those get the tests not
    run at all)
    17:46 < _rene_> elbrus, aurel32: uploaded, thanks. Let's see.
    17:47 < elbrus> _rene_: don't forget to request removal of binaries in
    unstable for architectures where your build fails but passed in the past
    17:47 < elbrus> because that doesn't happen automatically
    17:48 < _rene_> and all their r-deps....
    17:49 < elbrus> uhm, yes, that too
    17:49 < _rene_> (since libreoffice is not a leaf package, it has stuff (build)-depending on it)
    17:49 < _rene_> even unrelated stuff like R stuff
    17:49 < _rene_> (for .doc conversion)
    17:50 < elbrus> reminds me of my own package (winff) (or did I orphan
    that already)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rob Landley@21:1/5 to Rene Engelhard on Mon Jun 19 00:00:01 2023
    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,

    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rene Engelhard@21:1/5 to All on Sat Jul 22 14:40:01 2023

    Am 22.07.23 um 14:25 schrieb Andreas Schwab:
    On Jul 22 2023, Rene Engelhard wrote:

    Just not registering or unregistering *any* extension.
    What does that mean? I haven't seen any errors about extensions.

    Do you run the testsuite?

    Especially the smoketest?

    And you are replying to exactly a thread which (later) talks about
    extensions being broken. So I wonder why you didn' t take the previous
    mails into account?

    https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for
    manual thing. And the IRC log shows that even libreoffice-lightproof-en
    etc don't appear as bundled extensions.

    https://lists.debian.org/debian-riscv/2023/07/msg00001.html is for the smoketest (that one's mips64el, but same symptom on riscv64)



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Schwab@21:1/5 to Rene Engelhard on Sat Jul 22 16:10:01 2023
    On Jul 22 2023, Rene Engelhard wrote:

    Does opensuse have some public git/$VCS?


    (Though I would more bet of some system evironment thingy)

    Perhaps it is a matter of using a good java. Have you tried java 19 or

    Andreas Schwab, schwab@linux-m68k.org
    GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
    "And now for something completely different."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to rene@debian.org on Sat Jul 22 19:30:01 2023
    On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard <rene@debian.org> wrote:

    Am 22.07.23 um 14:02 schrieb Andreas Schwab:
    On Jun 18 2023, Rene Engelhard wrote:

    For riscv64 I already pointed that out in the thread starting at
    https://lists.debian.org/debian-riscv/2023/06/msg00000.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.
    Libreoffice is actually basically working on riscv64.

    Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile
    says, though)

    Be careful of -Os. I test one of my C++ libraries with it in the
    library's test suite. Based on unexplained crashes with -Os, I believe
    GCC produces bad code with -Os on occasion.

    I do not recommend using -Os in production based on my experience.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)