Switch to spidermonkey/mozjs 78

[mkg20001]

The Firefox ESR 52 is no longer maintained, as such it likely contains unfixed security vulnerabilities.

Firefox ESR 60 is the next ESR, which is currently maintained.

Could CJS be updated to support mozjs60?

[clefebvre]

Yes, nothing new here. CJS needs to bump towards a new mozjs now and then. The next bump is likely to be towards mozjs60. CJS 4.4 is using mozjs52, that won't change. The bump could happen for 4.6 in the next development cycle or failing that in 4.8.

[jtojnar]

By that time we should make it mozjs68 https://gitlab.gnome.org/GNOME/gjs/issues/270

[norbusan]

Hi @clefebvre

Debian maintainer of Cinnamon here.

Yes, nothing new here. CJS needs to bump towards a new mozjs now and then. The next bump is likely to be towards mozjs60. CJS 4.4 is using mozjs52, that won't change. The bump could happen for 4.6 in the next development cycle or failing that in 4.8.

Do you have plans to implement the switch for 4.8? On the Debian side we are now phasing out the old mozjs and the switch is becoming a serious bug.

Thanks for all your work

Norbert

[Fantu]

An update from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908234:

Neither is mozjs60, and it has been removed from Debian. All other mozjs-dependent packages are now using mozjs68, based on Firefox 68 ESR.

Additionally, as a warning for the future: the upstream development branch for GNOME/gjs has moved to the JavaScript engine from Firefox 78, which will be packaged in Debian as mozjs78, for GNOME 3.38. This hasn't happened in Debian yet (see #968341 to track progress), but based on the GNOME release schedule and the Debian freeze plans, I expect we will ship bullseye with GNOME 3.38 and mozjs78.

[norbusan]

Update 2020-09

And another Firefox ESR release cycle. We now have mozjs78 in unstable and in use by gjs; this is the version that GNOME will be using in Debian 11 'bullseye', unless the freeze happens much later than expected.

This means we now have:

mozjs52: cjs (mozjs60 removed) mozjs68: a libproxy plugin that doesn't actually work (probably removed soon) mozjs78: gjs, policykit-1/experimental

We hope to remove mozjs68 soon, leaving only mozjs52 (for cjs) and mozjs78 (for gjs and policykit-1).

Any chance for an update here?

[Fantu]

https://github.com/linuxmint/cjs/pull/84 (thanks to leigh123linux) fedora 34 seems already using it: https://src.fedoraproject.org/rpms/cjs/c/e92a7f16437e29a296621103a4f9daff7142e185?branch=master If I'll have time next weekend I'll test it in debian unstable

about CI failing is for not related error, @clefebvre can you take a look please?:

  Error pulling image linuxmintd/mint20-amd64: error pulling image configuration: unknown blob... retrying
  image cache not found on this host, downloading linuxmintd/mint20-amd64
latest: Pulling from linuxmintd/mint20-amd64

1f796a1e: Already exists 
ea53ad12: Already exists 
71e02073: Already exists 
17bbf772: Already exists 
665c555b: Pulling fs layer 
90346da7: Pulling fs layer 
eb728a8a: Pulling fs layer 
4f53d3aa: Pulling fs layer 
e5bae1da: Pulling fs layer 
ab57eb86: Pulling fs layer 
218f1484: Pulling fs layer 
40121a67: Pulling fs layer 
a26d395c: Pulling fs layer 
e3eb6afc: Waiting >s layer 

error pulling image configuration: unknown blob

[mkg20001]

I'm currently rebuilding cinnamon on nixOS with the PR, I'll post an update once I have some results

[norbusan]

@Fantu @mkg20001 thanks. I have taken a look at this PR, but a about 400 files and tens of thousands of lines touched, that looks - well - interesting. Let us hope. I will give it a try here, too.

[leigh123linux]

84 (thanks to leigh123linux)

fedora 34 seems already using it: https://src.fedoraproject.org/rpms/cjs/c/e92a7f16437e29a296621103a4f9daff7142e185?branch=master If I'll have time next weekend I'll test it in debian unstable

about CI failing is for not related error, @clefebvre can you take a look please?:

  Error pulling image linuxmintd/mint20-amd64: error pulling image configuration: unknown blob... retrying
  image cache not found on this host, downloading linuxmintd/mint20-amd64
latest: Pulling from linuxmintd/mint20-amd64

1f796a1e: Already exists 
ea53ad12: Already exists 
71e02073: Already exists 
17bbf772: Already exists 
665c555b: Pulling fs layer 
90346da7: Pulling fs layer 
eb728a8a: Pulling fs layer 
4f53d3aa: Pulling fs layer 
e5bae1da: Pulling fs layer 
ab57eb86: Pulling fs layer 
218f1484: Pulling fs layer 
40121a67: Pulling fs layer 
a26d395c: Pulling fs layer 
e3eb6afc: Waiting >s layer 

error pulling image configuration: unknown blob

I switched cinnamon for f34 to use gjs

https://src.fedoraproject.org/rpms/cinnamon/commits/master

The change to cjs was to keep it in stasis so it doesn't get retired, also a couple of third-party applets use cjs. I have tested the cjs port and it seems ok.

The cjs port also requires some changes to cinnamon code

https://leigh123linux.fedorapeople.org/pub/patches/new_cjs.patch

[leigh123linux]

FTR I believe @clefebvre intends to use mozjs68 for Mint. The thought of maintaining mozjs68 for the next 4 years horrifies me, hence the switch.

[norbusan]

@leigh123linux I agree!

[mkg20001]

I got some warnings during session start

Sep 28 14:58:55 nixos .cinnamon-wrapp[1164]: JS LOG: [LookingGlass/info] Cinnamon.AppSystem.get_default() started in 600 ms
Sep 28 14:58:55 nixos .cinnamon-wrapp[1164]: Some code tried to set a deprecated GObject property.
                                             0 start() ["/nix/store/2s0m1lfi32qzp3jdvgvhj2wbs6x187ql-cinnamon-common-4.6.1/share/cinnamon/js/ui/main.js":330:4]
                                             1 <TOP LEVEL> ["<main>":1:46]

Sep 28 14:58:55 nixos .cinnamon-wrapp[1164]: JS LOG: [LookingGlass/info] added icon directory: /run/current-system/sw/share/themes/Mint-Y-Dark/cinnamon
Sep 28 14:58:55 nixos .cinnamon-wrapp[1164]: Some code accessed the property 'BackgroundManager' on the module 'backgroundManager'. That property was defined with 'let' or 'const' inside the module. This was previously supported, but is not correct according to the ES6 standard. Any symbols to be exported from a module must be defined with 'var'. The property access will work as previously for the time being, but please fix your code anyway.

Sep 28 14:58:58 nixos .cinnamon-wrapp[1164]: JS LOG: [LookingGlass/info] Loaded applet sound@cinnamon.org in 790 ms
Sep 28 14:58:59 nixos .csd-power-wrap[980]: abs_to_percentage: assertion 'max > min' failed

Besides that seems to work with @leigh123linux cjs & cinnamon patch

[Fantu]

I suppose that clem didn't switch to newer mozjs because want a mozjs present in both latest mint version, mint20 based on focal have mozjs 52 and 68, lmde 4 based on buster that have mozjs 52 and 60, then mozjs 52 is the only present on both. So if we want to see cjs updated upstream before the next debian and ubuntu lts releases (instead of keeping large cjs and cinnamon patches maintained by fedora, debian (and other distros) I suppose we have to give clem very good reasons for moving to new mozjs and the easier/faster way to get it in buster and focal (or put in mint20 and lmde4)

[leigh123linux]

@mkg20001

This one is new

                                             0 start() ["/nix/store/2s0m1lfi32qzp3jdvgvhj2wbs6x187ql-cinnamon-common-4.6.1/share/cinnamon/js/ui/main.js":330:4]
                                             1 <TOP LEVEL> ["<main>":1:46]

The ES6 standard warnings were present in the virgin code.

[mkg20001]

@leigh123linux Ok, seems like it's just a warning tho for now, at least didn't see anything broken

Also there's a PR for nixOS to use the patched version for the time being, so we are at least no longer depending on the insecure mozjs52 https://github.com/NixOS/nixpkgs/pull/99008

[leigh123linux]

I suppose that clem didn't switch to newer mozjs because want a mozjs present in both latest mint version, mint20 based on focal have mozjs 52 and 68, lmde 4 based on buster that have mozjs 52 and 60, then mozjs 52 is the only present on both. So if we want to see cjs updated upstream before the next debian and ubuntu lts releases (instead of keeping large cjs and cinnamon patches maintained by fedora, debian (and other distros) I suppose we have to give clem very good reasons for moving to new mozjs and the easier/faster way to get it in buster and focal (or put in mint20 and lmde4)

I believe I've seen at least a 15% decrease in cinnamon startup time with mozjs78 using gjs or cjs.

Gjs-Message: 10:06:11.162: JS LOG: [LookingGlass/info] Cinnamon took 2093 ms to start

[mkg20001]

before:
Sep 28 16:19:08 nixos .cinnamon-wrapp[1169]: JS LOG: [LookingGlass/info] Cinnamon took 5128 ms to start

after:
Sep 28 16:17:27 nixos .cinnamon-wrapp[1175]: JS LOG: [LookingGlass/info] Cinnamon took 4546 ms to start

similar results here

[ItzSwirlz]

Let's just try to make the switch, I'll try to build with mozjs78

Clem, I don't know if you are staying with 52 because it's in Ubuntu Focal and you can put it in Mint Repos, but I suggest that everyone as a whole, who packages Cinnamon and uses it for any distros other than Mint, such as leigh123linux for Fedora, need to get this fixed ASAP before this becomes project suicide.

[leigh123linux]

@eli-schwartz

[leigh123linux]

@Fantu @mkg20001 thanks. I have taken a look at this PR, but a about 400 files and tens of thousands of lines touched, that looks - well - interesting. Let us hope. I will give it a try here, too.

If that cjs patch is too large there is another path, use gjs instead.

https://src.fedoraproject.org/rpms/cinnamon/blob/master/f/switch_to_gjs.patch

[Fantu]

remove a fork too little maintained it would be beautiful but unfortunately if cinnamon is not keep updated for the compatibility of gjs versions as soon as they come out there is a risk of more problems, so keep the fork (but upstream and not only single distros patches, for less waste of collective time and better results) I suppose it is necessary to have less risk of bugs/unexpected events, especially for rolling releases distro (or similar)

[eli-schwartz]

Arch is not planning to remove either mozjs52 or cinnamon at the moment.

I've been watching this issue for ~6 months and I'm happy to see there's movement to getting this resolved as I'd quite like to consolidate on one recent mozjs too. But I'd really like to see the PR merged before packaging it, and I'm disinclined to apply a distro-specific patch. Even if the patch is specific to more than one distro.

This needs to be fixed properly rather than requiring every distro to maintain out of tree patches.

[eli-schwartz]

What are the advantages and disadvantages of using gjs directly? If it's simple to do, I'm a bit curious why cinnamon ended up forking it to cjs back in the day...

[leigh123linux]

What are the advantages and disadvantages of using gjs directly? If it's simple to do, I'm a bit curious why cinnamon ended up forking it to cjs back in the day...

gjs used to break abi every release so cjs was forked to solve this, since then gjs change between releases seems to have slowed/stopped. The patch for cinnamon to use gjs supports many releases gjs >= 1.56.0

[norbusan]

Lot if going on, I'll answer more completely later. Concerning the two options: 1) patch/update cjs, and 2) use gjs, it is really difficult.

I'm thinking about long term maintainability for distributors, and both seem to be suboptimal. The big patch of option 1) might be hard to update/maintain when upstream cjs changes. OTOH, switching to gjs is opening a Pandora box. Every single piece of Gnome related software I know had gratuitously broken apis, ignored third party projects, all for the sake of progress. Relying on this is a dangerous step I don't want to take.

For Debian I tend to use the big patch approach 1), which is already available in experimental.

What would be a nice idea to have a community "distribution fork" of cjs where we try together to accommodate cjs upstream changes to new mozjs until upstream switches. This repository could be the source of patches for various distribution packages.

[norbusan]

gjs used to break abi every release so cjs was forked to solve this, since then gjs change between releases seems to have slowed/stopped.

Yes indeed, that was the problem, and we don't know when it starts again. It is Gnome.

[ItzSwirlz]

I think we should go straight for GJS.

For a while Cinnamon Debian Team has had the idea of sharing GNOME back-end tools like GJS.

The thing is-if we DID switch to GJS we may have to rewrite like, nearly all the JS code.

Currently we have @leigh123linux 's patch in experimental, so for LM 20/Ubuntu 20.10 you don't need to worry about it-but thi will become more of a problem as we move into late October/November.

Is there any direct issues just slapping GJS on Cinnamon without say, doing anything? Because eventually cjs may just not be worth the time.

MATE for example doesn't use any JS apps, they are primarily C, but to keep the traditional design they forked everything from GNOME. So that also depends-what style of a Desktop are we looking for? I view it as "Traditionally Modern", but if we're just going to keep using GNOME tools then you minus well just switch to GJS, it won't hurt.

But yes-the problem with GNOME and GTK, is that it's well-known for not being so easy. Of course forking GTK is pointless but then you might want to just fork GJS so it's with Cinnamon.

But I'm sure we could just.. port it? The latest version of mozjs is a bit complicated via pkgconfig though. But no matter what, it will be deprecated.

For realsies, we use GJS and stick with it, or we continue CJS, but it's time for LM to leave Cinnamon out of their bubble and let it flow with ALL Distro standards.

A branch as Norbert said however, would possibly be sufficient, so I give a +1 on that.

[leigh123linux]

gjs used to break abi every release so cjs was forked to solve this, since then gjs change between releases seems to have slowed/stopped.

Yes indeed, that was the problem, and we don't know when it starts again. It is Gnome.

When Clem rebases cjs to the version he chooses it will require many of the changes (80%+) in the cinnamon gjs patch I'm using for fedora. Maybe keeping up with gjs is an easier task than keeping mozjs68 alive for at least 4 years with multiple gcc, glib and whatever lib changes.

[leigh123linux]

What would be a nice idea to have a community "distribution fork" of cjs where we try together to accommodate cjs upstream changes to new mozjs until upstream switches. This repository could be the source of patches for various distribution packages.

You would still be subjected the gjs changes when they occur and cinnamon would need to adapt to them.

[ItzSwirlz]

I just think GJS and get it over with.

[eli-schwartz]

The proper way to support both older distros with old mozjs versions and newer distros trying to target new mozjs versions is to ifdef the code and build for both.

Here's a thought -- can cinnamon somehow target both gjs and cjs, but require a specific range of versions for gjs and if that is not found, require cjs instead? Then as new gjs versions are known to still work okay, they can be whitelisted in configure.ac, and cjs can catch up at its leisure.

Cinnamon updates for newer mozjs/gjs apis wouldn't affect the blessed cjs implementation immediately, but could be tested by people building against gjs and eventually reduce the effort needed when it comes time to upgrade cjs.

[Fantu]

whatever the future choice I think it is better that it is applied upstream and shared by the distro otherwise more collective time would be wasted and there is risk of more bugs/unexpected cases

@clefebvre could you please give your opinion on what you would like to do upstream and which one(s) of possibilities would be acceptable to you?

[mkg20001]

Btw, nixOS unstable is now using the patch by @leigh123linux https://github.com/NixOS/nixpkgs/pull/99008

[ptomato]

Hi, GJS maintainer here. Several years ago I had discussed with Jason (who I thought I heard is no longer working on Cinnamon though) about unifying GJS and CJS. I would welcome this, even if for no other reason, because GJS got some very good contributions from Jason and I'd be happy to see more Cinnamon people continuing that.

It may be helpful information for your decision, to read in GJS's roadmap about the policy on breaking changes. tl;dr — sometimes it is unavoidable because a SpiderMonkey upgrade forces us to, and there are some grey areas, but otherwise we do not make changes that break existing code.

[worldofpeace]

@ptomato That's very great to hear :+1:

[norbusan]

Thanks @ptomato for your comment, this sounds very reassuring. Let us hope that cinnamon and gjs could find a better way together (again).

[norbusan]

whatever the future choice I think it is better that it is applied upstream and shared by the distro otherwise more collective time would be wasted and there is risk of more bugs/unexpected cases

Agree in principle, but distributors have to do something now, and cannot wait for whatever might come at an unspecified time in the future. So for now I think the update as mentioned is necessary, at least for some here.

[Fantu]

for cinnamon itself from what i have read so far it seems better switch to gjs. about applets and desklets I have not looked well but even from quick search at least some seem "forced" on cjs, if the change occurs upstream for the next version applets/desklets will be modified for compatibility with new cinnamon version otherwise they risk not working with the distros that will remove cjs. ( https://github.com/linuxmint/cinnamon-spices-desklets https://github.com/linuxmint/cinnamon-spices-applets )

[Fantu]

I did some tests:

cinnamon using cjs with mozjs52 (debian unstable, same of upstream): info t=2020-10-02T12:05:46Z Cinnamon took 972 ms to start (without additional applets)

cinnamon using updated cjs with mozjs78 (debian experimental, using patches from leigh123linux): info t=2020-10-02T11:33:37Z Cinnamon took 743 ms to start (without additional applets) no additional warning/errors in melange (including some additional applets I had installed)

cinnamon using gjs (deb https://www.preining.info/debian unstable cinnamon main, using patches from leigh123linux) and removing cjs: info t=2020-10-02T11:49:09Z Cinnamon took 776 ms to start (without additional applets) no additional warning/errors in melange (including some additional applets I had installed) but there are some applets or it parts (seems few) that call additional js files launching them with cjs, for example multicore-sys-monitor preferences didn't working without cjs because... this.childProcessHandler = new SpawnProcess.ProcessSpawnHandler(this.metadata.path, ['cjs', 'prefs.js', currentPreferences]); I suppose would be good to warn applets developers where there are parts that force cjs to modify them (for not have issues on future return to gjs, or if some distro will do it recently) and add in the readme of the repository with the instructions for the developers a note to avoid this in future applets

@clefebvre can you say something please? If for example you want chooice to accept the cjs update but you don't have time to prepare mozjs78 backports for buster and focal (for upload in mint20 and lmde4) maybe I have time this weekend to make the necessary changes to the packages and test their build; similar for the case of gjs switch, where in focal gjs is enough new and would be needed only the the backports of gjs/mozjs in buster

thanks for any reply and sorry for my bad english

[norbusan]

Thanks @Fantu for the detailed testing. I think the case that applets rely on cjs being present can be worked around by cinnamon conflicting with cjs, and shipping a cjs link to gjs.

[lestcape]

This is just my opinion and not more, but as i mentioned more less the same in gjs, i think now is time to said it here.

I think it is possible to continue trying to convince someone who apparently don't want to be convinced or instead probably the best is contribute to port cjs to the last gjs code, but that without to lost support for the Mint spidermonkey active version. In that way should be reduced the number of changes that are need as all of that was included with enough time in the master branch. That move will also help to port cjs to a new version of gjs when Mint decide, because what will be needed was already included in cjs and all package that depend of it like the spices (extensions).

As it's important reduce the difference between cjs and gjs as possible, one way of how this could be done is if all different code between both can be assimilated by gjs and/or by cjs in the best way for both. Also, when something can not be assimilate in gjs or cjs, the best could be inject the difference in the Cinnamon shell instead of modify the cjs package. For example, this is used in Cinnamon to override some Gio functionalities that some GNOME developers don't want to change: https://github.com/linuxmint/cinnamon/blob/master/js/ui/overrides.js#L58-L98

But exactly this code is not needed anymore because gjs assimilated it and create a much robust solution than what it is in cjs actually. Unfortunately no one ported the robust solution of gjs back to cjs and this is the kind of things that shouldn't happen, because it is a thing that was already done and then it only create a difference between the two package just for nothing.

There are a lot of change that are coming and they should be prevented with enough time: https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/324

[clefebvre]

Hi everyone,

Thanks for raising this issue and contributing to this discussion. Sorry for the time it took me to join you. We're going to prioritize this issue and resolve it ASAP and for everybody.

I'd like to thank @ptomato also for his message and talk a little bit about GJS. CJS is not a "real" fork. It's a fork of course, but in terms of project, it has no ambition to be any different than GJS. None of the changes which were added to CJS were envisioned or planned when the fork first occurred, some of them were ported upstream, and those which weren't can be put in Cinnamon directly. CJS has also been rebased quite a few times on GJS. It doesn't deviate from it, it just catches up. So when it comes to "differences" between GJS and CJS, they don't matter to us per se. We don't need our own interpreter. What we need is our own "version" of the interpreter. Let me try and explain this a little bit, it's quite important.

When a distribution ships a new version of GNOME it includes a version of GJS which is appropriate and which works with that version of GNOME. When it ships a new version of Cinnamon is ships with the CJS interpreter of the same version.

In the past, when Cinnamon used GJS directly, new versions of Cinnamon were designed with the version of GJS used in Linux Mint and LMDE in mind. So although Cinnamon worked very well in these distributions, it could break in distributions which shipped newer or older versions of GJS, and these distributions could not upgrade or downgrade or freeze their version of GJS because that version was required by the version of the GNOME they shipped with.

Even if CJS was 100% identical to GJS (and it could be), what it really brings to the table is this: It allows us to know that a particular version of Cinnamon runs with the same interpreter in all distributions. It doesn't matter who's running a brand new GJS and who's running a really old one, when the new Cinnamon comes out, there's a matching CJS and everybody can use that. Distributions can ship with GNOME, Cinnamon, GJS, CJS and two versions of mozjs, what they cannot do is ship with two versions of GJS.

Now, in terms of our own targets, in addition to yours, we have the following:

• LMDE 4 (based on Buster): mozjs60, gjs 1.54
• Mint 20 (based on Focal): mozjs68, gjs 1.64

I assume in rolling distributions we're looking at mozjs78 and gjs 1.66 and if we were to look at compatibility with the current LTS (thankfully we're not but it's relevant all the same) we'd be looking at mozjs52 and gjs 1.52.

If we switch to GJS we become more flexible but we risk seeing issues and behavior which differ between distributions and which we might not always be able to reproduce or even fix for everybody. If we jump to mozjs78 we fix the issue for all distributions, old and new, and ensure everyone can run the next version of Cinnamon without running in specific issues. The problem then of course is that although that solves the problem for now, we'll be having the same problem again next year.

Moving to GJS is a risk in terms of compatibility because of that. Even if GJS itself tries to minimize the impact on GNOME and Cinnamon, it's not just up to them, moving to a newer mozjs can mean mandatory code changes and unlike GNOME we're not just worried about having our latest version run on the latest mozjs, we'd have to juggle with both old and new here and work with different versions if we want to port the latest Cinnamon to LMDE/Debian and Mint/Ubuntu. With CJS the version of mozjs is the same everywhere, whether that's an old 52 or the brand new 78 and that allows us to run the upcoming Cinnamon anywhere we want.

[jbicha]

Just a brief comment:

Although it's not really taking place yet in all distros, I believe the goal for GNOME developers is for gjs updates to be backported to LTS distributions. So both GNOME Shell and a Cinnamon-GJS would need updates to continue working with the supported version of GJS. This is because mozjs, as a part of Firefox, is only supported for about one year.

[ptomato]

I believe the goal for GNOME developers is for gjs updates to be backported to LTS distributions.

Just a minor note; while this is a worthy goal, I do want to be clear that I and the other upstream GJS contributors don't have enough bandwidth to support this, so this is really up to the LTS distributions themselves.

[eli-schwartz]

The other potential approach to ensuring every distro can use the same gjs/mozjs version for cinnamon, would be to make gjs capable of having multiple versions of gjs coexist and properly versioning itself based on semantic versioning + "when you need mandatory code changes". Currently, libgjs uses the soname "0.0.0" and every other file is installed to a "1.0" namespace. I'm not actually sure what the point of this "1.0" namespace is if it actually does break compatibility though. ;)

One could then depend on old versions of vanilla gjs and package them just like, currently, multiple versions of mozjs get packaged. In spirit this is even what cjs is.

[clefebvre]

I believe the goal for GNOME developers is for gjs updates to be backported to LTS distributions.

Just a minor note; while this is a worthy goal, I do want to be clear that I and the other upstream GJS contributors don't have enough bandwidth to support this, so this is really up to the LTS distributions themselves.

Same here, we wouldn't be updating past Cinnamon releases to switch to newer versions of mozjs. That said, if newer versions of mozjs were backported in Debian stable and Ubuntu LTS we would definitely switch to them faster.

[Fantu]

@clefebvre you say in past you wan't use -backports (for example this caused a wait of 2 years for another thing), so you could exactly tell which one(s) solution would you accept (for a possible solution upstream in a short time) please? from your reply seems to me you prefer remain with cjs and for update it you want newer mozjs available in both buster and focal repository or you will wait (long time) for future debian and ubuntu lts versions, or I'm wrong? and about upload mozjs78 in mint/lmde repository if someone (probably I) will prepare and test the packages building with buster and focal (without use -backports) will be ok for you? (for add leigh123linux cjs/cinnamon patches for cinnamon 4.8) wait one year or more for an update/change upstream with many distro that will use patches for use gjs (or updated cjs) and/or create a cinnamon fork seems a collective waste of time that I think is preferable to avoid

[jbicha]

Ok, I guess the backporting gjs thing is just a Ubuntu LTS idea that's been on a wishlist for 2 years and no one is working on it yet.

[clefebvre]

hi @Fantu

No, we're not waiting on anyone. We'll be fixing this ASAP in preparation for Cinnamon 4.8.

We're testing both scenarios (sorry, I just can't get used to the Latin plural form). You're right, I prefer the CJS solution but I'm also interested in seeing if we can use GJS and even if we don't, if we can reduce the difference and make it easier to switch.

Right now we're preparing mozjs78 builds for LMDE 4 and Mint 20. We'll then make a PR to port CJS (and possibly Cinnamon if code changes are needed) to it.

[Fantu]

@clefebvre big thanks for your work trying to solve it fast about mozjs78 packages I did a fast look, if you fork debian packaging https://salsa.debian.org/gnome-team/mozjs (debian/78/master branch) seems only to be needed revert these patches for have it working (I not have time to test it now) in buster and focal without -backports and update of other packages:

• debian: Use debhelper 13 variables sobstitution in *.install files
• debian/control: Bump dependency on dh 13
• debian/control: build-depend on the first ICU version with fixed likely subtags