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/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...
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 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
change
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@50.230.184.210] 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@50.230.184.210] has quit [Quit: Page
closed]
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)
