Repositories for supported Debian, Raspbian, and Ubuntu releases

[stevenpusser]

I've got 32.2.0 built for the OBS repos for i386, amd64, and arm64 architectures, (will try the EOL Ubuntu 18.04 amd64 problem children tomorrow), but all the 32-bit ARM (armhf/armv71) builds are now failing during the configure process right at the start with a new Python 2.7 error message:

Code: Select all

 The error occurred while processing the following file:
[  498s] 
[  498s]     /usr/src/packages/BUILD/platform/js/src/moz.build
[  498s] 
[  498s] The error was triggered on line 653 of this file:
[  498s] 
[  498s]     UNIFIED_SOURCES += jit_ioncheck2_deunified_sources
[  498s] 
[  498s] An error was encountered as part of executing the file itself. The error appears to be the fault of the script.
[  498s] 
[  498s] The error as reported by Python is:
[  498s] 
[  498s]     ["NameError: name 'jit_ioncheck2_deunified_sources' is not defined\n"]
[  498s] 
[  498s] *** Fix above errors and then restart with\
[  498s]                "make -f client.mk build"

[Moonchild]

Try building with ac_add_options --disable-js-lto in mozconfig. I'm thinking it might not satisfy the config checks in place on ARM32

[jobbautista9]

The bustage will still occur even with --disable-js-lto, as JS_LTO is already not defined in non-Windows. For some reason JS_SIMULATOR_ARM isn't defined, which means this assignment never occurs:

Code: Select all

    if CONFIG['JS_SIMULATOR_ARM']:
        jit_ioncheck2_deunified_sources = [
            'jit/arm/Simulator-arm.cpp'
        ]
    elif CONFIG['OS_ARCH'] == 'Darwin':
        jit_ioncheck2_deunified_sources = [
            'jit/arm/llvm-compiler-rt/arm/aeabi_idivmod.S',
            'jit/arm/llvm-compiler-rt/arm/aeabi_uidivmod.S',
        ]

Which leaves jit_ioncheck2_deunified_sources undefined.

Weird that it succeeds in ARM64 though! Might want to find out why JS_SIMULATOR_ARM64 is being defined but not JS_SIMULATOR_ARM.

For now you can try fixing this temporarily by changing the following lines in js/src/moz.build from this:

Code: Select all

    if CONFIG['ENABLE_ION']:
        UNIFIED_SOURCES += jit_ioncheck2_deunified_sources

to this:

Code: Select all

    if CONFIG['ENABLE_ION'] and not CONFIG['JS_SIMULATOR_ARM']:
        UNIFIED_SOURCES += jit_ioncheck2_deunified_sources

Really wish I have an ARM machine right now...

[Moonchild]

JS_SIMULATOR_ARM would only be set if you're building on an ARM simulator (which is x86 only), not on ARM hardware. I'm guessing 64-bit would bail on not being x86...

You could also just make sure it's defined as an empty array beforehand? that way it's always defined even if nothing is added to it.

[jobbautista9]

JS_SIMULATOR_ARM would only be set if you're building on an ARM simulator (which is x86 only), not on ARM hardware. I'm guessing 64-bit would bail on not being x86...

That makes sense.

You could also just make sure it's defined as an empty array beforehand? that way it's always defined even if nothing is added to it.

Good thinking, I will do that!

[jobbautista9]

Created PR Issue #2248 (UXP). stevepusser, can you test if that fixes building for armhf?

[stevenpusser]

I'll take a whack at it. At least the error is right at the start, instead of deep in the compilation, which takes hours in the emulated arm 32 machines.

To be sure, I'm not building on any ARM hardware myself. If I understand it correctly, the OBS build farm is also emulating ARM hardware on what is probably x86-64 hardware using QEMU.

[Moonchild]

If I understand it correctly, the OBS build farm is also emulating ARM hardware on what is probably x86-64 hardware using QEMU.

That wouldn't make a difference here -- for the build system it would seem to be running on ARM hardware; whether that hardware is emulated under the hood or not doesn't matter. The "simulator" stuff in the build system seems to be something run inside an existing intel environment, but I have no knowledge otherwise of it.

[stevenpusser]

The fix worked, so I will merge the two commits into one patch so it looks more like I know what I am doing, and upload updated sources to the OBS later this morning.

[stevenpusser]

And also the separate 32.2.0 Ubuntu Bionic packages are built, but the users will probably have to "go to the download repository" manually to get the deb.

[Mæstro]

I had got today an upgrade from a first to another version of v32·2 today in Mint Upgrade. Is there some bug in the first one, or is this ‘upgrade’ safe to skip?

[stevenpusser]

You can safely ignore that update if you are really concerned with bandwidth, as the update just has the patch to fix the armhf architecture builds.

I also see that Ubuntu 18.0.4 can't be considered dead now until 2028...https://ubuntuhandbook.org/index.php/20 ... es-ubuntu/

[Pentium4User]

I also see that Ubuntu 18.0.4 can't be considered dead now until 2028...https://ubuntuhandbook.org/index.php/20 ... es-ubuntu/

If you really want to support such old systems, feel free, but most developers stop it because ESM is only available in certain situations and must be paid except for private people with a small amount of machines.

[stevenpusser]

Uploaded sources for 32.2.1 to the OBS. Except for the Ubuntu 18.04 ones, will try to make time for those tomorrow, but am pretty darn busy with helping MX 23 development.

Intel x86_64 and x86 packages as usual should be done within an hour, with ARM taking several times longer. I've built Debian 11-based MX 21 64-bit and 32-bit packages locally already on my laptop, now am doing the same for Debian 10 MX 19. Letting the OBS do all the ARM ones and MX 23 ones overnight, I gotta quit for the day soon.

[stevenpusser]

Ubuntu 18.04 packages should now be available. Trying to fix builds for last three Ubuntu releases now, plus upstream Debian...

[Drugwash]

Steven, thank you for continuing to work on the 18.04/Bionic packages.

[stevenpusser]

Steven, thank you for continuing to work on the 18.04/Bionic packages.

Bionic packages for 32.3.0 have successfully built, as well as for most of the released Ubuntu and Debian versions. Debian testing and Sid are failing, though. Sid recently switched to gcc-13 by default, but Trixie (testing) still has the gcc-12 that is working elsewhere. Will have to do some forensics later.

[Drugwash]

Great news about Bionic, thank you! Gotta fire up the updater as it's set to manual.
Hope you manage to fix the remaining ones soon. Good luck!

[Moonchild]

Steve, be aware we'll be having another release this coming week (32.3.1) to address some pretty important issues with the platform. If some target platforms aren't building at the moment you may want to hold off to the point release.

[stevenpusser]

Got it!