EDIT: I kinda solved it by installing Wayland (with Nvidia card, Ouch!) to replace Xorg. Not sure if this is gonna last though. Perhaps Manjaro is the one I’m gonna throw out FIRST if anything happens from now on.

What should be the first line of defense? Timeshift?

This happened after I installed AUR package masterpdfeditor and 2 applications from github (some hashing algorithm programs, I think they were “Dilithium” and “Latice-based-cryptography-main”, one of them was provided by NIST.)

If using GUI: I login, black screen for few seconds, then back at login screen.

If going to ctrl+alt+f2, login successful, then startx, see picture provided (higher quality).

I tried adding a new user, but result is the same.

I have a live usb to do the Timeshift. (I can also chroot if necessary… But I’m not extremely professional)

  • Rustmilian@lemmy.worldEnglish
    5·
    8 months ago

    On other software proposing a library to be >=ver-xxx means the packager speculates that future editions will NOT break the build

    No shit Sherlock. >= means forward compatible, not backwards. Manjaro has older packages, not newer, e.g. lessthan= not greaterthan=. If the package says glibc (greaterthan)>=2.35 and Manjaro has glibc<=2.32 it’s 1. not going to install because the versioning requirements are properly defined in that case and 2. if it wasn’t properly defined you’d either get a failed or junk build which is my entire point.
    >= is put there for cases where older versions than what is defined DO break the build.

    For example Glibc needs linux-api-headers>=4.10 , what do you think happens if Manjaro only has linux-api-headers<=4.9?
    That’s right, it doesn’t install because Manjaro’s outdated package doesn’t meet minimum requirements.
    Now think what happens if Glibc needs linux-api-headers>=4.10 but it isn’t properly defined as such in the PKGBUILD/.PKGINFO as what happens with a crap ton of AUR packages, but again Manjaro only has linux-api-headers<=4.9?
    It installs it despite Manjaro not meeting minimum requirements which in turn causes undefined bad behavior; this is why proper dep versioning is strictly enforced in the official/Manjaro repos; this is where the AUR is different, proper dep versioning is an after thought & it’s assumed you’ll always have the latest Arch packages.
    If the AUR package is being compiled against a lesser version then it’s minimum requirements you’d either get a failed build, or a broken junk build that’ll install and potentially cause damage.

    You’re thinking it’s about the forward compatibility, when actually it’s the opposite, it’s about the backwards compatibility.
    Does that make sense now?

      • Rustmilian@lemmy.worldEnglish
        4·
        8 months ago

        calamaris and a bunch more.
        At one point I was maintaining a large number of KDE git packages before I passed them off to others too.
        here are the ones I’m currently maintaining, some of which I’ve written from scratch; including the previously mentioned calamaris package which if you look is very nonstandard and even makes great use of >=.

        or are you just criticizing thousands for their work without any evidence

        I’m not even criticizing anyone, I’m just telling you straight and as bluntly as possible how the AUR works.
        There’s no guideline that say you have to provide proper dependency versioning. That’s just not something that’s enforced in the AUR.

        I’ve said it before and I’ll say it again :

        1. Most AUR maintainers assume you’re always going to have the latest or at least close to the latest Arch base packages available to you.
        2. Nobody who maintains AUR packages give enough of a rats ass to put in extra work to support the special edge cases that arise from Manjaro. That includes myself, I’m not going to put in extra work because Manjaro wants to be quirky and use their own flag combination with their package base, nor am I going to provide special back porting. It’s just not going to happen.