Update gjs to 1.48.5

[Jeremy Bícha]

This is an exceptional microrelease update, documented at https://wiki.ubuntu.com/StableReleaseUpdates/GNOME

Impact
------
1.48.5 is a new bugfix release in the stable 1.48 series, associated with the GNOME 3.24 stable series. 17.04 currently has 1.48.3.

https://git.gnome.org/browse/gjs/log?h=gnome-3-24
https://git.gnome.org/browse/gjs/tree/NEWS?h=gnome-3-24

This update fixes a crash of GNOME Shell on Wayland. When GNOME Shell is run on Wayland, a crash will completely destroy the session (unlike on X where GNOME Shell tries to restart itself) so this is a high priority fix.

Test Case
---------
GNOME Shell is written in gjs so let's test GNOME Shell. After installing the update, reboot.

Also check some of these apps:
gnome-characters
gnome-documents
gnome-maps
gnome-sound-recorder
gnome-sushi
gnome-weather
polari

All of them except for gnome-sound-recorder and polari are included in Ubuntu GNOME and Ubuntu Budgie.

Regression Potential
--------------------
If gjs has a problem, it could leave Ubuntu GNOME users unable to log in to their computer at all since gdm uses part of gnome-shell to work. All GNOME 3.24 distros will be including this update though.

There was a regression identified in 1.48.4 but it was quickly fixed (in about 2 days).

Other Info
----------
gjs 1.48.3 got stuck in phased-updates but the underlying issue was actually in gnome-maps which has already been fixed in 17.04 now. This gjs update should clear Phased Updates then.

https://people.canonical.com/~ubuntu-archive/phased-updates.html

[Launchpad Janitor (janitor)]

This bug was fixed in the package gjs - 1.48.4-0ubuntu1

---------------
gjs (1.48.4-0ubuntu1) artful; urgency=medium

  * New upstream release (LP: #1698553)

 -- Jeremy Bicha <email address hidden> Sat, 17 Jun 2017 11:10:04 -0400

[Robie Basak (racb)]

Thank you for preparing this update! This presumably falls under: https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases

Could you detail what automatic testing is available please, with reference to the requirements in that section of the policy? It would probably be worth adding that to the bug description and to your template for future updates.

[Robie Basak (racb)]

> It would probably be worth adding that to the bug description...

Actually the policy requires it: "The upstream QA process must be documented/demonstrated and linked from the SRU tracking bug."

[Jeremy Bícha (jbicha)]

gjs is one of the better tested parts of GNOME. We run its build tests as part of the build and we use autopkgtest to run its installed tests (autopkgtests pass on all architectures except s390x). I talked briefly with the gjs maintainer today and he said that he estimates the test coverage at about 65%. He also tries to add tests when regressions are identified and fixed. (Although in this case, he had difficulty reproducing the gnome-shell crashes and therefore wasn't able to add much tests for them.)

But let me speak more about GNOME SRUs in general.

GNOME SRUs are regularly accepted without needing to have automatic testing. This is good because much of GNOME does not have test coverage. Where tests exist, we do try to run them. Ubuntu runs more GNOME tests now than it did a year ago because of switching from cdbs to dh (with dh_auto_test) and as checked during the recent set of MIRs.

There used to be a standing release exception from the Tech Board (TB) for GNOME microreleases but this explicit exception was dropped when the TB simplified the SRU policy in September 2015.

https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev1=231&rev2=232
https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=diff&rev1=59&rev2=60

I don't think it's good for our users to block reasonable microreleases for GNOME because tests do not exist. Is there a problem with how GNOME SRUs have been handled recently?

[Robie Basak (racb)]

Hi Jeremy,

> There used to be a standing release exception from the Tech Board (TB) for GNOME microreleases but this explicit exception was dropped when the TB simplified the SRU policy in September 2015.

I was not aware of this. Thank you for pointing it out.

The current SRU policy is quite clear that a TB member must approve a micro release update where "such upstream automatic testing is not available". Based on your description I think this update falls under this TB approval requirement.

The thread at https://lists.ubuntu.com/archives/technical-board/2012-June/001286.html makes it quite clear that the TB did consider the QA side of the GNOME MRE at the time.

It seems to me that:

1. TB approved GNOME MRE having considered the QA requirements[1][2].

2. TB developed more general MRE requirements to save each MRE having to be individually approved by the tech board, and so dropped the previously documented MREs.

3. It wasn't noticed at the time that the GNOME MRE didn't meet the new generalised MRE requirements, so the GNOME MRE can't be approved by the SRU team on its own as the policy is written because it no longer meets the requirements.

However, I think it's clear that we should consider the GNOME MRE "grandfathered" and already accepted by the TB in their original acceptance of the MRE.

I've documented this at https://wiki.ubuntu.com/StableReleaseUpdates#GNOME and https://wiki.ubuntu.com/StableReleaseUpdates/GNOME. I suggest we link all GNOME SRU tracking bugs to https://wiki.ubuntu.com/StableReleaseUpdates/GNOME to avoid any holdups by unfamiliar SRU team members.

[1] https://lists.ubuntu.com/archives/technical-board/2012-June/001327.html
[2] https://lists.ubuntu.com/archives/technical-board/2012-June/001298.html

[Robie Basak (racb)]

The diff looks fine to me, except for one part of the m4 autoreconf noise:

-x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \

There are some other ppc related changes as well which I think are all part of the same thing.

Will this cause issues for ppc64el and/or powerpc, and does it matter for GNOME packages? It looks like the packaging uses autoreconf, so perhaps this makes no difference? I don't know, so I'd like someone knowledgeable in this area to review please.

Apart from that, +1 to accept into Zesty.

[Robie Basak (racb)]

> It looks like the packaging uses autoreconf...

Actually, looks like it previously did (prior to Zesty), but no longer does?

[Jeremy Bícha (jbicha)]

Robie, thanks for being thorough and looking through this bug more.

Having the GNOME microrelease exception documented again is a big help for SRUs.

gjs now uses debhelper compat 10 which runs autoreconf by default

https://lintian.debian.org/tags/useless-autoreconf-build-depends.html
https://manpages.debian.org/stretch/debhelper/debhelper.7.en.html#COMPATIBILITY_LEVELS

By the way, GNOME is switching many modules to meson for 3.26 and 3.28. One advantage is that once autotools support is dropped, the diffs for microreleases will be a lot easier to read without all that autotools noise.

https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

[Robie Basak (racb)]

09:26 <xnox> looks like the tarball was generated with non-patched / out of date config.sub; rebuilding now with extra debug to see if autoreconf is actually done or not.

09:28 <xnox> dh_update_autotools_config

09:28 <xnox> dh_autoreconf are both run.

09:29 <xnox> cat config.sub, shows timestamp='2016-11-04' so all is good.

09:29 <xnox> still a bit sad that a point release tarball is generated with very old configury.

09:33 <rbasak> xnox: so it's all in config.sub, and I know what to look at to confirm this for next time. Thank you for your help!

[Robie Basak (racb)]

Hello Jeremy, or anyone else affected,

Accepted gjs into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gjs/1.48.5-0ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Ubuntu Foundations Team Bug Bot (crichton)]

The fix for this bug has been awaiting testing feedback in the -proposed repository for zesty for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

[Jeremy Bícha (jbicha)]

I apologize for not fully verifying this sooner. I did test things out months ago with no problems but didn't reply here.

Today, I installed libgjs0f 1.48.5-0ubuntu0.1 on Ubuntu GNOME 17.04. After rebooting, I verified that gnome-shell, gnome-characters, gnome-maps, gnome-sushi, and gnome-weather all work fine.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gjs - 1.48.5-0ubuntu0.1

---------------
gjs (1.48.5-0ubuntu0.1) zesty; urgency=medium

  * New upstream release (LP: #1698553)

 -- Jeremy Bicha <email address hidden> Wed, 21 Jun 2017 15:15:36 -0400

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for gjs has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.