Dear Maintainer,

Your package gnote 51~beta-2 failed to build on ppc64el on the buildd
with below build log:

https://buildd.debian.org/status/fetch.php?pkg=gnote&arch=ppc64el&ver=51%7Ebeta-2&stamp=1790190921&raw=0

The test gnote:gnote_unit_tests was killed by SIGABRT. The last
line of the log is:


4/4 gnote:gnote_unit_tests FAIL            0.15s   killed by signal 6
SIGABRT
――――――――――――――――――――――――――――――――――――― ✀
―――――――――――――――――――――――――――――――――――――
stderr:

** (process:1070): WARNING **: 20:15:19.389: Can't set the global locale
to the user's preferred locale.
    locale::facet::_S_create_c_locale name not valid
    The environment variable LANG may be wrong.

file:///tmp/gnotetestnotes81T1V3/manifest.xml:1: parser error : Start
tag expected, '<' not found
=====
^
file:///tmp/gnotetestnotes74S1V3/manifest.xml:1: parser error : Start
tag expected, '<' not found
=====
^
Entity: line 1: parser error : Premature end of data in tag sync line 1
d00cae25f3" rev="2"/>  <note id="1006a78a-6e61-4492-b5cc-a42f62d0a9ef"
rev="0"/>

       ^
(70366686865344) ERROR: error_handler - XML error: Document is empty

*** longjmp causes uninitialized stack frame ***: terminated


I could not reproduce the failure locally on ppc64el:
A clean sbuild of gnote 51~beta-2 in a sid ppc64el chroot succeeded,
including the test suite.

Since the failure does not reproduce, it may be intermittent or caused
by a build-dependency difference on that buildd at that time.
Could you request a give-back on ppc64el to see whether it recurs? If it
does, I can help collect a backtrace.


Thanks,
Trupti

The error is similar to what is seen on armhf and i386.

Do you use ppc64el?

The pass rate for that build test on Debian's buildds is bad. I had
gnote removed earlier this year on ppc64el because of the Debian
buildd failures:
https://buildd.debian.org/status/logs.php?pkg=gnote&arch=ppc64el

Thank you,
Jeremy Bícha

   Yes, I am using ppc64el system.

I can see ppc64el is now showing as Installed for 51.0-1. Did the new
upstream release and disabling parallel tests fix the issue?

If so, should we close bug #1148857?


Regards,

I assume we got lucky that it built this time on ppc64el and it will
likely fail the next time we want to update the gnote packaging. The
same or similar build failure is also seen on armhf, i386 and s390x .
If it fails to build on ppc64el next time, I will likely have the
package removed from ppc64el as I'm doing with the other
architectures. Sorry, but if I don't remove it, then gnote would be
removed from Testing for every architecture. I don't have the extra
time or interest to debug this issue much further.

Thank you,
Jeremy Bícha

GNOME software quality doesn't seem to be anymore what it used to be.

I don't like the trend that what used to be cross-platform is slowly
getting exclusive to x86_64 and ARM. "Works on my computer" shouldn't
become the norm.

Adrian

I think your criticism of GNOME is misplaced. This build failure is
seen because we are running build tests more regularly that we used
to. Also, gnote technically isn't GNOME Software because it is neither
part of core GNOME nor in GNOME Circle. This year, we moved packages
like this to the Debian GNOME Extras team to help make this more clear
to people looking at Debian packages.

This is yet another case where build tests are failing on
architectures that I don't own. Furthermore, this is an app that I
don't even use. We could ignore the tests but how do we know the
packages work on those architectures?

Maybe the build test failure is actually triggered by a behavior
change or bug in libxml2 earlier this year?

Thank you,
Jeremy Bícha

Hi,

Also, this is usually a sign of something that is dependent on
microarchitecture behaviour that is not guaranteed anywhere including
the machines where it "works."

This is especially true for software that don't even have a reason for
architecture-specific hacks, like a note-taking app.

Basically, thousands of apps work fine on all architectures, and this
one doesn't, so this is clearly a bug in the app. Whether it really
works on x86, we don't know, it might just not trigger the problem in a
detectable way, and when released to users, silently lose their data.

Removal from testing is entirely warranted, IMO.

    Simon

Hi Simon,

Fully agreed. Testsuite failures often, not always, but often are exposing
bugs that actually exist on x86_64 as well but they might not be as easy
to trigger there.

Architectures like SPARC are like the canary coal mine as they are super-
sensitive to alignment issues and other bugs which should be dealt with.

Agreed.

Adrian