Cannot log in with microsoft on the latest supported version.

[cakePhone]

So I just bought Minecraft for Android specifically to be able to play on my linux machine for now, while I wait to buy my android phone, and I get the error code "Creeper" every single time I try to log into my microsoft account in-game. Can anybody help me here? Is there a discord for faster responses?

MC Version: 1.18.12.01 Launcher Version: 0.3.4 (build 688)

[awuioebhjnd]

try deleting your cache that fixed mine

[mohdyusuf]

I am seeing this problem too - but on latest version as speaking now 1.19.51.01.

I did clear all the mpelauncher files and data and start over, the Microsoft Log In button is still not working.

[ChristopherHX]

I am seeing this problem too - but on latest version as speaking now 1.19.51.01.

That's a different problem, see here for a workaround https://github.com/flathub/io.mrarm.mcpelauncher/issues/90#issuecomment-1368405838

The problem with xbox login on 1.19.51.01, will be fixed in the next update (no eta)

[mohdyusuf]

I am seeing this problem too - but on latest version as speaking now 1.19.51.01.

That's a different problem, see here for a workaround flathub/io.mrarm.mcpelauncher#90 (comment)

The problem with xbox login on 1.19.51.01, will be fixed in the next update (no eta)

Thank you so much!! Appreciate your hard work. I was able to use the workaround for now.

[mdaffailhami]

I am seeing this problem too - but on latest version as speaking now 1.19.51.01.

That's a different problem, see here for a workaround flathub/io.mrarm.mcpelauncher#90 (comment)

The problem with xbox login on 1.19.51.01, will be fixed in the next update (no eta)

I can't sign in with Microsoft account only when I use certain wifi, but I use another wifi I can

[SummerSeeker]

I have the same problem I am in the version: 1.20.32.03

[pigong]

Same problem with 1.20.41.02 on a Raspberry Pi IV using Bookworm, mcpelauncher 0.11.4, Bookworm and Jammy debs tested, exact same behavior. It's a real pitty, because we cannot play online. I have a nitrado server with "online-mode" switched off, in theory a login should not be necessary, yet MS client-side insists on the login. So a missing MS login disables any online activities even though the server list displays in the client... I went back down to MC 1.17 for every major version, and never got a working login. I've been trying for 4 days - it's hard to imagine that MS wouldn't fix such a big problem in 4 days. 1.19.4 differs from 1.20 in that it loads the Marketplace - but once you try to purchase something it says: "cannot complete purchase, check internet connection". On 1.20 instead of marketplace on the respective button you get "Playfab environment mismatch - Discovery=prod/20CA2, Playfab=Production/"

[ChristopherHX]

I've been trying for 4 days - it's hard to imagine that MS wouldn't fix such a big problem in 4 days.

The microsoft servers are at least in Germany working, even with this launcher. I can login on ubuntu 22.04 on my intel gen8 laptop.

This launcher doesn't use the same code for the full login flow than actual Android devices. All the Java Code is replaced by c++, some of them are using java cryptography replaced by hopefully equivalent c++ and openssl calls.

On 1.20 instead of marketplace on the respective button you get "Playfab environment mismatch - Discovery=prod/20CA2, Playfab=Production/"

Clear your gamedata and only keep your worlds and avoid switching a lot between major releases of the game. This error was the first thing I saw after fixing access to the marketplace.

I think a mod to mirror the external server entries to your lan play tab should be possible, this would bypass the silly login requirement. (All the local network traffic goes throw this launcher c and fake java wrappers).

If your problem is not mcpelauncher-webview, like you described in a far far away issue then your issue is very complex.

• can be a connection problem caused by your isp. Have you checked using the Hotspot of your Smartphone?
• can be a os/arch issue e.g. streamos fails after OS update. Have you tried this on a ubuntu 22.04 desktop on a intel laptop / pc? (If this works, it's not your isp, but your os/arch)

I had to try sign in 3 times (hey, I don't like to touch this xbox live shit as long it works for me)

• first time
  • webview opened
  • signed in successfully in the webview
  • webview opened (allows to change the account)
  • Stuck on connecting...
  • closed
• second time
  • game tried to sign in
  • crash.txt
• third time
  • game logged me out due to the crash
  • webview opened
  • signed in successfully in the webview
  • webview opened (allows to change the account)
  • connecting for a couple of seconds
  • success

Yeah this launcher is buggy as a hell, but all alternatives are too slow / hard to setup on my weak hardware

[ChristopherHX]

I have a nitrado server with "online-mode" switched off, in theory a login should not be necessary, yet MS client-side insists on the login.

@pigong You can bypass this easily, by redirecting udp packets

That's easier than telling you to debug the launcher, because I cannot reproduce your xbox problems.

This c++ snipped (g++ -g lanconnect.cpp -o lanconnect)

#include <sys/socket.h>
#include <netinet/udp.h>
#include <sys/types.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <unistd.h>
#include <string.h>
#include <thread>
#include <iostream>

int main(int argc, char**argv) {
    if(argc != 3) {
        std::cout << "Usage: " << argv[0] << " <ipv4 server addr> <port>\n";
        return 1;
    }
    int sock = socket(AF_INET, SOCK_DGRAM, 0);
    sockaddr_in addr;
    auto ad = inet_addr("127.0.0.1");
    addr.sin_family = PF_INET;
    memcpy(&addr.sin_addr, &ad, sizeof(addr.sin_addr));
    addr.sin_port = htons(19132);
    auto ret = bind(sock, (sockaddr*)&addr, sizeof(addr));

    int sockb = socket(AF_INET, SOCK_DGRAM, 0);
    sockaddr_in addrb;
    addrb.sin_family = PF_INET;
    addrb.sin_addr.s_addr = INADDR_ANY;
    addrb.sin_port = 0;
    ret = bind(sockb, (sockaddr*)&addrb, sizeof(addrb));

    bool started = false;

    sockaddr_in addrc;
    addrc.sin_family = PF_INET;
    addrc.sin_addr.s_addr = inet_addr(argv[1]);
    addrc.sin_port = htons((short)atoi(argv[2]));

    while(true) {
        sockaddr_in remoteaddr;
        char buf[4096 * 1024];
        socklen_t size = sizeof(remoteaddr);
        auto len = recvfrom(sock, buf, sizeof(buf), 0, (sockaddr*)&remoteaddr, &size);
        if(!started) {
            started = true;
            std::thread([sock, sockb, xdest = remoteaddr, &rdest=remoteaddr]() {
                while(true) {
                    sockaddr_in remoteaddr;
                    char buf[4096 * 1024];
                    socklen_t size = sizeof(remoteaddr);
                    auto len = recvfrom(sockb, buf, sizeof(buf), 0, (sockaddr*)&remoteaddr, &size);
                    if(buf[0] == 0x1c) {
                        char str[] = "MCPE;Tunnel;600;1.0.0;0;3;12321196102327825775;Tunnel level;Survival;1;19132;19133;0;";
                        int lena = buf[33] << 8 | buf[34];
                        int lenb = sizeof(str) - 1;
                        buf[33] = lenb >> 8;
                        buf[34] = lenb;
                        memcpy(buf + 35, str, lenb);
                    }
                    len = sendto(sock, buf, len, 0, (sockaddr*)&rdest, size);
                }
            }).detach();
        }
        len = sendto(sockb, buf, len, 0, (sockaddr*)&addrc, size);
    }
}

Usage: ./lanconnect <ipv4 server addr> <port>

Then connect to the tunnel lan server

[pigong]

@ChristopherHX just as a quick reply before I look into this more carefully on Sunday: I installed Fedora 39 today on a X86_64 and could instantly connect to MS. That's within the same LAN, but of course a different machine. Unfortunately also launcher 0.11.5 rather than 0.11.4. Looks like it's either the launcher version or the architecture ;-) Thanks for all your suggestions! I am not sure I have the patience to set up a build system and try to debug: the problem is, while I've done stuff like that before, I don't really understand what I am doing...

[ChristopherHX]

ubuntu18.04 appimage ok ubuntu18.04 deb failure, lan play is broken too. (I couldn't remember that it was broken, I used them a couple of months ago just fine)

this is a buggy mess

[pigong]

Yes, I can confirm your own observation, and it now looks consistent to me. Just to be clear, both my systems are arm64 (rpi and opi5+): on Ubuntu 22.04 (running on the OPI5+) the deb is broken and (as I just confirmed) the AppImage works (i.e. all the logins work, playstore, network play etc all fine!). Also the lack of snappiness I observed in the flatpak Ubuntu installer does not occur, the arm64 Appimage must somehow be using hardware-gpu-support. This AppImg is 0.11.4 too, but there is a minor version difference, right, the AppImage is 721, the deb is 6... something.

Unfortunately the AppImage doesn't work on Rpi5-bookworm, the problem was discussed in the other thread (pi-apps). But it strongly looks like the particular login-problem would be solved implicitly, if the AppImage could be made to work on the Raspberry Pi.

I won't be able to try and properly debug the situation in a build-system, but I'll install Debian Bookworm on a x86_64 system, just to see if the AppImage problem is gone there...

[pigong]

So I just had the launcher run on a live System of Debian Bookworm on a x86_64 (Lenovo X1 Yoga, i7 8th gen), and both variations, deb and AppImage worked. Unfortunately though it were newer versions than the ones that appear from the arm64 repo, even the nightly one. The x86_64 deb installed 0.11.5 - running flawlessly without a hickup an all logins - and the AppImage installed 0.11.4.721 which had several problems like the ones you described (having to restart, getting non-fatal error-messages, etc), but ultimately it allowed to login both in Google and MS.

So unfortunately I couldn't compare any pair: same-version - different architecture, but when it worked, the 0.11.5 debs were clearly the cleanest ;-) RPI users will be etearnally gratefull if you provide arm64 debs of version 0.11.5, and once the rpi5 is readily available, that could become a pretty popular platform, as MC Bedrock, even in the most recent versions, should perform decently at a really affordable price.

[ChristopherHX]

RPI users will be etearnally gratefull if you provide arm64 debs of version 0.11.5

Hmm 0.11.5 are only nightly builds and that also have the arm64 build bug. See https://minecraft-linux.github.io/pkg/index.json for what's under https://minecraft-linux.github.io/pkg/, I use that config to rebuild the deb repo via GitHub Actions (rebuilding drops old nightly prebuilds)

The current nightly 0.11.5 will become 0.12.0 once released. (due to enhanced game version compatibility)

For rpi5, don't we need 16k page size support first? E.g. parts of the arm64 (m1) code if runtime pagesize is not 4k.

Can you try the armhf 0.11.5 nightly version? Does it have the same bug? I mean the build script is basically copied from arm64, but the arm64 is mostly copied from the AppImage script aswell.

I'm still surprised how I can build the same code on the same distro twice, once with working xbl and another time without.

[bagong]

For rpi5, don't we need 16k page size support first? E.g. parts of the arm64 (m1) code if runtime pagesize is not 4k.

I guess so, unfortunately I don't even know what that means. I read somewhere however, that rpi4 doesn't have the large page size. I don't have an rpi5 yet, and won't get one before January. It's @theofficialgman who understands that level.

I can only test stuff on hardware that is likely not available to you. I'll try the 32-bit builds, AppImage and deb, in the next days...

[theofficialgman]

For rpi5, don't we need 16k page size support first? E.g. parts of the arm64 (m1) code if runtime pagesize is not 4k.

While it would be nice to have Linux 16K pagesize support (for stock Pi5 on PiOS and Asahi Linux which default to 16K pagesize kernels), for the Pi5 it isn't a dealbreaker. Pi5 can run a 4K pagesize kernel just fine (albeit with very marginally slower performance) with a simple change in the config.txt (bootloader config) file to use the 4K pagesize kernel. There is enough incompatible software with 16K pagesize kernels that for now that is what I am doing https://github.com/raspberrypi/bookworm-feedback/issues/107

[theofficialgman]

I read somewhere however, that rpi4 doesn't have the large page size.

That is correct, all the other Pi use 4K pagesize kernels. I was told by Gordon Hollingworth (RPi Ltd chief technology officer) that for the Pi4 and the other older models they have no intention of shipping 16K pagesize kernels. His words were that they were incompatible but, if true, that must be in reference to their GPUs and other hardware design. Every ARMv8 core (like the ones in Pi3/Pi4/Pi5) "should" be compatible with 4K/16K/64K pagesize.

[pigong]

@ChristopherHX so I went through the 32-bit hf-options on bookworm/rpi4: deb and appimage: 32-bit debs cannot install, because the qt6 qml and webengine related dependencies are not available in armhf bookworm. So no way to get it working. I am almost curious, how you provide those in the appimage, the ui starts and google-login works when using the not yet updated version + the "QT_QUICK_BACKEND=software"-trick and some trial and error, but once trying to start actual Minecraft it crashes X/Wayland instantly and horribly ;-), you are prompted for a new login (I think I am seeing the same as @theofficialgman saw when trying the appimage for pi-apps, likely wayland related crash).

Bookworm arm64 does provide the qt6-dependencies, and the debs seem not to have the wayland-related problem, so 0.11.5 arm64 seems the most likely candidate to work. I am pretty sure all rpi-users that try to "zocken" on an rpi use the 64-bit os ;-), so my guess is that a 64-bit build is actually more useful than a 32-hf one, even if the later is the "classical" version.

[pigong]

@ChristopherHX - I was going to try to build the latest version, but I found that the build description still lists the qt5 packages. Is there an updated list somewhere?

[ChristopherHX]

because the qt6 qml and webengine related dependencies are not available in armhf bookworm

@pigong No, you are not using bookworm if these are not available.

How do you think I built the armhf version here on bookworm?: https://github.com/minecraft-linux/pkg/actions/runs/6846983794/job/18614453120#step:3:1

Is there an updated list somewhere?

Look at the pipeline behind the deb ci I linked above.

[ChristopherHX]

apt install -y docker.io libfuse-dev:arm64 wget texinfo apt-transport-https vim-common qemu-user chrpath libstdc++-11-dev:arm64 libatomic1:arm64 wget cmake g++-arm-linux-gnueabihf g++-aarch64-linux-gnu patchelf git cmake pkg-config libssl-dev:arm64 libcurl4-openssl-dev:arm64 libpng-dev:arm64 libx11-dev:arm64 libxcursor-dev:arm64 libxinerama-dev:arm64 libxi-dev:arm64 libxrandr-dev:arm64 libssl-dev:arm64 libudev-dev:arm64 libevdev-dev:arm64 libegl1-mesa-dev:arm64 libgl1-mesa-dev:arm64 libssl-dev:arm64 libuv1-dev:arm64 libzip-dev:arm64 libprotobuf-dev:arm64 protobuf-compiler jq curl binutils desktop-file-utils squashfs-tools libssl-dev:arm64 libpulse-dev:arm64 qt6-base-dev:arm64 libqt6opengl6-dev:arm64 qt6-webengine-dev:arm64 qt6-webengine-dev-tools:arm64 qt6-declarative-dev:arm64 qml6-module-qtquick:arm64 qml6-module-qtquick-layouts:arm64 qml6-module-qtquick-controls:arm64 qml6-module-qtquick-window:arm64 qml6-module-qtquick-dialogs:arm64 qml6-module-qt-labs-settings:arm64 qml6-module-qt-labs-folderlistmodel:arm64 qml6-module-qtwebengine:arm64 qt6-base-dev:arm64 libqt6opengl6-dev:arm64 qt6-webengine-dev:arm64 qt6-declarative-dev:arm64 libqt6svg6-dev:arm64 qml6-module-qtquick-layouts:arm64 qml6-module-qtquick-controls:arm64 qml6-module-qtquick-controls:arm64 qml6-module-qtquick-dialogs:arm64 qml6-module-qt-labs-settings:arm64 qml6-module-qt-labs-folderlistmodel:arm64

apt-get install -y --no-install-recommends g++ clang cmake make git ca-certificates libssl-dev libpng-dev libx11-dev libxcursor-dev libxinerama-dev libxi-dev libxrandr-dev libcurl4-openssl-dev libudev-dev libevdev-dev libegl1-mesa-dev libssl-dev libasound2 qt6-base-dev libqt6opengl6-dev qt6-webengine-dev qt6-declarative-dev qml6-module-qtquick qml6-module-qtquick-layouts qml6-module-qtquick-controls qml6-module-qtquick-window qml6-module-qtquick-dialogs qml6-module-qt-labs-settings qml6-module-qt-labs-folderlistmodel qml6-module-qtwebengine libssl-dev libcurl4-openssl-dev libuv1-dev libzip-dev libprotobuf-dev protobuf-compiler qt6-base-dev libqt6opengl6-dev qt6-webengine-dev qt6-declarative-dev libqt6svg6-dev qml6-module-qtquick-layouts qml6-module-qtquick-controls qml6-module-qtquick-controls qml6-module-qtquick-dialogs qml6-module-qt-labs-settings qml6-module-qt-labs-folderlistmodel

[pigong]

because the qt6 qml and webengine related dependencies are not available in armhf bookworm

@pigong No, you are not using bookworm if these are not available.

How do you think I built the armhf version here on bookworm?: https://github.com/minecraft-linux/pkg/actions/runs/6846983794/job/18614453120#step:3:1

Well, as I said, I was intrigued. Maybe you got it from qt-company? Or I do something wrong, but this is what it looks like for me:

pi@raspberrypi:~ $ lsb_release -d
No LSB modules are available.
Description:    Raspbian GNU/Linux 12 (bookworm)

.... and:

sudo apt install mcpelauncher-manifest mcpelauncher-ui-manifest msa-manifest
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mcpelauncher-manifest : Depends: qml6-module-qtwebengine but it is not installable
                         Depends: libqt6webenginewidgets6 but it is not installable
 mcpelauncher-ui-manifest : Depends: qml6-module-qtwebengine but it is not installable
                            Depends: libqt6webenginewidgets6 but it is not installable
 msa-manifest : Depends: qml6-module-qtwebengine but it is not installable
                Depends: libqt6webenginewidgets6 but it is not installable
E: Unable to correct problems, you have held broken packages.

I then did an apt search and got nothing returned containing qt6 webengine and qml.

Ah, and thanks for the list, I hope I find time tomorrow to give it a try.

[ChristopherHX]

What about these pages https://packages.debian.org/bookworm/qml6-module-qtwebengine, https://packages.debian.org/bookworm/libqt6webenginewidgets6 you can download the armhf deb there. Nothing missing for armhf.

I then did an apt search and got nothing returned containing qt6 webengine and qml.

It depends on what apt sources you have configured, but debian bookwork has these packages.

As I mentioned before "raspbian armhf was not a full debian, they removed webengine from there repos". I had to either mix raspbian with real debian (aka frankendebian) or create an AppImage with the files from real debian.

This means the pi-apps from @theofficialgman can never use armhf apt packages, thank you raspberry pi os distro owners.

[pigong]

Well, to be fair, Raspbian existed, before Debian even provided armhf (I think ;-) ). Rpi osses were always Debian based, but initially self compiled from bottom up. Since the switch to 64-bit they're gradually shifting to Debian, but it's a difficult process.

It might however be possible to add armhf Debian sources to Raspbian, or find some other way to provide the dependencies for the debs? I remember the pi-apps scripts contained some tricks, at least in the past.

On Mon, 13 Nov 2023, 12:30 ChristopherHX, @.***> wrote:

What about these pages https://packages.debian.org/bookworm/qml6-module-qtwebengine, https://packages.debian.org/bookworm/libqt6webenginewidgets6 you can download the armhf deb there. Nothing missing for armhf.

I then did an apt search and got nothing returned containing qt6 webengine and qml.

It depends on what apt sources you have configured, but debian bookwork has these packages.

As I mentioned before "raspbian armhf was not a full debian, they removed webengine from there repos". I had to either mix raspbian with real debian (aka frankendebian) or create an AppImage with the files from real debian.

This means the pi-apps from @theofficialgman https://github.com/theofficialgman can never use armhf apt packages, thank you raspberry pi os distro owners.

— Reply to this email directly, view it on GitHub https://github.com/minecraft-linux/mcpelauncher-manifest/issues/709#issuecomment-1807981578, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFJH4NPJPSIGIJWKEWXKC3YEIAENAVCNFSM55FTZBRKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQG44TQMJVG44A . You are receiving this because you were mentioned.Message ID: @.***>

[pigong]

@ChristopherHX - how can I build using qt6? All three modules ask for "FindQt5.cmake"... Is it another branch, or a cmake argument?

[ChristopherHX]

branch qt6 is for qt6 of UI and launcher.

branch ng is for qt5 of UI and launcher.

Both branches are kept in sync by GitHub Actions.

Only msa-manifest has a cmake flag, because I didn't migrate that to qt6 myself

[theofficialgman]

I then did an apt search and got nothing returned containing qt6 webengine and qml.

It depends on what apt sources you have configured, but debian bookwork has these packages.

As I mentioned before "raspbian armhf was not a full debian, they removed webengine from there repos". I had to either mix raspbian with real debian (aka frankendebian) or create an AppImage with the files from real debian.

they did not "remove" webengine from the repo. Thats not how raspbian works. Every single package from debian has to be rebuilt so that is compatible with armv6+VFP CPUs like the ones in the pi1 (BCM2835), all other Pis which use BCM2836/2837/2711/2712 are either armv7 or armv8 and are compatible with standard debian armhf. qt6-webengine has simply been failing to build and you can see that in the public logs http://buildd.raspbian.org/status/logs.php?pkg=qt6-webengine

dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/libqt6webenginecore6/DEBIAN/symbols doesn't match completely debian/libqt6webenginecore6.symbols

a raspbian maintainer has to go any manually correct that package so that it can build

[ChristopherHX]

a raspbian maintainer has to go any manually correct that package so that it can build

Still means package is not available and this software cannot be installed as armhf deb file.

This software is technically unable to run on armv6, due to android system requirements.

How to proceed? A bookworm AppImage?

based on your list of 16k kernel defects is a qt6 AppImage a requirement

No replacing qt webengine is not practical for me

Did qtwebengine ever built for 32bit Raspberry Pi OS? I gave it up waiting for it in 2019 and created an AppImage, then moved on to ubuntu.

[pigong]

@ChristopherHX , I am at the build, and msa went through quite well (just dependency libxkbcommon-dev was missing).

Currently trying to configure mcpelaunder and running into the following problem: I can checkout branch qt6, however I get en error missing "FindQt5" for the submodule mcpe-launcher-webview. If I try a git submodule update I get an errormessage that the required hash isn't available remotely:

You're German, no problem with the terminal language right:

pi@pigong:~/Projects/mcpelauncher $ git submodule update
Submodul-Pfad 'mcpelauncher-errorwindow': 'dd34ad134f0f2954ebaa8a5d82b97300f9e4f28e' ausgecheckt
Schwerwiegend: Fehler am anderen Ende: upload-pack: not our ref 9eb948778aeee9c580d48779b012280157a40fda
Schwerwiegend: "fetch" in Submodul-Pfad 'mcpelauncher-webview' ausgeführt, aber enthielt nicht 9eb948778aeee9c580d48779b012280157a40fda. Direktes Anfordern dieses Commits ist fehlgeschlagen.

Maybe you didn't commit the submodule update hash? Or have another tip how to get on? Currently the cmake run ends like so:

-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found UDEV: /usr/lib/aarch64-linux-gnu/libudev.so  
-- Found EVDEV: /usr/lib/aarch64-linux-gnu/libevdev.so  
CMake Error at mcpelauncher-webview/CMakeLists.txt:17 (find_package):
  By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5" with any of
  the following names:

    Qt5Config.cmake
    qt5-config.cmake

  Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
  to a directory containing one of the above files.  If "Qt5" provides a
  separate development package or SDK, be sure it has been installed.

-- Configuring incomplete, errors occurred!
See also "/home/pi/Projects/mcpelauncher/build/CMakeFiles/CMakeOutput.log".
See also "/home/pi/Projects/mcpelauncher/build/CMakeFiles/CMakeError.log".

[ChristopherHX]

The easierst way is to delete the clone and type git clone --recursive https://github.com/minecraft-linux/mcpelauncher-manifest -b qt6. (git version 2.34.1). Switching between ng and qt6 branches might be a bit more complex.

mcpelauncher-webview changed it's url, the qt6 submodule has moved. Run git submodule sync && git submodule update --init --recursive

My system is not as far localized to german than yours, my git speaks english.

[pigong]

@ChristopherHX , thanks, that did it! Build went through, but I get a weird error now on package-creation (I prefer using packages, as it should allow me to uninstall easily), it speaks of architecture i386 ???:

cpack --config mcpelauncher-client/CPackConfig.cmake
...
sudo dpkg -i ./mcpelauncher-client-3a464db-Linux.deb 
dpkg: Fehler beim Bearbeiten des Archivs ./mcpelauncher-client-3a464db-Linux.deb (--install):
 Paket-Architektur (i386) passt nicht zum System (arm64)
Fehler traten auf beim Bearbeiten von:
 ./mcpelauncher-client-3a464db-Linux.deb

PS: not sure why you propose to combine dpkg -i with sudo apt install in the build instructions, but the error is the same.

PPS: well, I changed the variable in the CpackConfig.cmake from i386 to amr64, and that seems to have done it. But maybe it shouldn't have read i386 in the first place... Anyhow, on I go...

PPPS: I am doing this on my kids RPI4, it speaks German. My own computers speak English ;-)

[ChristopherHX]

not sure why you propose to combine dpkg -i with sudo apt install in the build instructions, but the error is the same.

I added an outdated notice to the wiki of "Compiling the game launcher", that's really old stuff from 2019. The launcher was packaged only for i386 on x86_64 hardware. Armhf required to built manually after adding submoudules.

The outdated notice is from 2021. Installing these debs will result in missing binaries.

I'm neither the creator of the original wiki nor the original mcpelauncher from 2019

[pigong]

@ChristopherHX , this feels promising, though I am not there yet. The builds of the three modules went through and I can actually start mcpelauncher-ui-qt, login to google, download the apk and start the game. The only thing that doesn't work is MS login ;-) (that was the main reason for me to try the build on arm64).

As to networking, it's not exactly the same as the official nightly 0.11.5.712 install: I do get the marketplace stuff and also the skins chooser, in the nightly deb I get this weird error message. But if I press login, I first get the MS-offer to login, and if I chose to log in, nothing happens for a while, and then, I get a new MS Error-message: Drowned (in the official deb it was: Creeper).

I have one suspicion/hope: in the other thread you asked me to run mcpelauncher-webview https://google.com test://exit in a terminal - so in the default install, mcpelauncher-webview is accessible systemwide. That's currently not the case in my install up to now. I can run mcpelauncher-webview https://google.com test://exit in the folder build/mcpelauncher-webview, and it works as expected, but the binary has not been installed to the system.

Do I need to install mcpelauncher-webview via make install? Are there other things, the use of the debs I created following the build instructions might have missed?

[ChristopherHX]

Do I need to install mcpelauncher-webview via make install?

Add the build folder to PATH that's all you need to do.

Are there other things, the use of the debs I created following the build instructions might have missed?

No idea, these cpack targets are deprecated for 2 years for now. I don't use them, minecraft-linux/pkg using a different method of creating a deb e.g. one package per big repo.

[pigong]

EDIT: Eh, I didn't see your answer before I typed this, sorry:

@ChristopherHX - to answer my own (core) question: yes, that's it: once I copied mcpelauncher-webview to a location in the system-path, the MS login worked, and I could reach my Nitrado server without being asked to login again. Fabulous! My kids will really be happy!

Compared to the Appimage I used to use in the previous Debian version, this does feel significantly snappier, I would say, snappier than MC Java on the RPI4. While I generally prefer MC Java, my kids want Bedrock to be able to play with friends using Switch or Xbox... so this is great now: faster than before, and working nicely.

All in all this build went much smoother than I expected, I think you're not entirely just to yourself, this feels a lot more stable than in the past. I still remember the days when I'd be scared to to die each time I entered water ;-). Congratulations!

If you want me to try out stuff or test something, just let me know. As the build system is working now, it shouldn't be much work.

[ChristopherHX]

If you want me to try out stuff or test something, just let me know. As the build system is working now, it shouldn't be much work.

The xbox live problem in the deb's is more complex than I thought...

For example if we start the AppImage it works, but if I start the AppRun file after running file.AppImage --appimage-extract it behaves exactly the same as the deb file.

The exact binary is broken and working at the same time, only the AppImage/(flatpak) environment makes it to work on arm64.

After a close look defining APPDIR make xbox live working in the manually run AppRun file.

So this patch is also required for the deb https://github.com/minecraft-linux/appimage-builder/blob/f94fd0e6077fca26ca6e43d223f08e39b2ea6498/curlappimageca/curl/curl.h#L7-L8 ? The custom libcurl must have a issue to find the ca bundle of the distro or think ms is invalid, however only on arm64. Linux is a sandbox with weirds things.

The remaining mystery why did a non cross compiled deb work without issues? GitHub doesn't provide me native arm64 builders. However I could look up the distro specfic ca bundle path...

A working bookworm appimage is here: https://github.com/minecraft-linux/appimage-builder/actions/runs/6883033738

Qtwayland works too, just the native wayland game client (like in flatpak) is missing to run without xwayland.

[ChristopherHX]

This cmake line of curl causes the issue https://github.com/curl/curl/blob/17162dcb27be7bc9c033147836637f331eefd1f3/CMakeLists.txt#L1002C10-L1002C30

It has an cross compile detection, which get's triggered by my ci. AppImage has a fallback to hide the consequences.

flatpak uses an arm64 builder provided by them for free.