On Tue, 14 Aug 2018 at 22:50:50 +0100, Liam Wilson wrote:
> Sorry, not sure if I follow. Do you mean that this issue with mozjs24
> will not be fixed for stretch on armhf?
Closing the bug in the context of unstable has no influence on whether
it exists or will be fixed in stretch, but it makes it one less thing
to triage for people who are working on unstable. The reason I was
looking at mozjs24 bugs was to check whether any of them needed to be
cloned or reassigned to mozjs52 before mozjs24 is removed from unstable.
Release-critical or important bugs can be fixed in stretch if the benefit
of fixing them is greater than the risk of regressions. However, we have
to be conservative about what goes into stretch, because if we didn't,
there would be no benefit in making stable releases; for people with
more tolerance of regressions, there's testing/unstable.
> Also you
> appear to have disabled jsctypes in mozjs52 (which is a very useful
> FFI, which I happen to require).
The reason that mozjs52 was packaged by the GNOME team was for the
benefit of gjs and policykit-1, which as far as I know don't benefit from
jsctypes. If you propose a patch on a separate bug that enables jsctypes
without causing regressions for mozjs/gjs, that seems like something
that could be enabled in mozjs52 (or perhaps more likely mozjs60 at this
point). mozjs24 no longer exists in unstable, and feature enhancements are
out of scope for stable, so if it doesn't already have jsctypes enabled,
it probably never will.
I'm only working on these packages because they block inclusion of
newer versions of GNOME, and I don't really understand JavaScript, so
I'm really not the right person to be doing the cost/benefit analysis
here and would prefer to defer to people who know mozjs better.
> I think adding some compiler flags to disable problematic
> optimisations will resolve the issue. Adding the following lines to
> debian/rules seems to fix the crashes and test failures:
>
> export DEB_CFLAGS_MAINT_APPEND = -fno-schedule-insns2
> -fno-lifetime-dse -fno-delete-null-pointer-checks -fno-schedule-insns
> export DEB_CXXFLAGS_MAINT_APPEND = -fno-schedule-insns2
> -fno-lifetime-dse -fno-delete-null-pointer-checks -fno-schedule-insns
mozjs52 in unstable has similar options set, so that looks promising.
It's unfortunate that the mozjs24 packaging ignored build-time test
failures, which I think led to it being built but partially or entirely
non-functional on many architectures; we've been trying to do better
in mozjs52.
> When I was building test packages locally I tried to enable these
> flags conditionally, but I had trouble doing so (maybe something to do
> with being on Raspbian?). Any chance you can enable those compiler
> flags on stretch armhf?
Debian is not responsible for Raspbian: it is a separate (derivative)
distribution, built with a different architecture baseline. Any changes
made to a Debian package should have been tested on a Debian system.
(I believe all Raspberry Pi models can run Debian armel with a third-party
kernel, while the Raspberry Pi 2 and up can run Debian armhf, and the
Pi 3 should be able to run arm64. There are some shared machines where
Debian developers can test proposed patches, but they're rather slow.)
You might find the mozjs52 packaging in unstable helpful: it sets a lot
of architecture-conditional compiler options.
Sorry, I'm already at the limits of my JavaScript and compiler knowledge
with mozjs52 uploads in unstable, so I am certainly not the right person
to be backporting this to stable. Perhaps the mozjs24 package's maintainer
can help?
Alternatively, if this bug is more severe in Raspbian than it is in
Debian due to Raspbian's focus on armhf, you could see whether there are
Raspbian developers who could integrate changes there.
smcv
