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.world
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    1
    ·
    edit-2
    8 months ago

    It’s called a -bin AUR package being complied against the latest dependencies, but when run it finds an old version that makes the program in question have undefined behavior.
    Not even single AUR package has >= requirements defined properly in the PKGBUILD, it’s just the nature of the AUR.
    There’s all kinds of bugs that can & do occur when a package expects one thing, but finds another. It’s really just that simple.
    Not only that, the Manjaro base packages often aren’t even built with the same flags as the Arch base packages; which is probably what happened here.
    I’ve even had to create special patching mechanisms myself do to flag incompatibilities in base packages.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      4
      ·
      8 months ago

      If an installed AUR package breaks due to distro binary package shift, you rebuild it and that’s it.

      If it’s an AUR package that downloads a binary, those binaries are typically made to work on a wide variety of environments.

      Not even single AUR package has >= requirements defined properly in the PKGBUILD, it’s just the nature of the AUR.

      “What if the package has incorrect dependencies” — seriously, that’s your argument?

      Well it would have been a crappy package anyway, no? It will break sooner or later, on Arch or Manjaro or any distro. You rebuild it and move on.

      • Rustmilian@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        ·
        edit-2
        8 months ago

        If an installed AUR package breaks due to distro binary package shift, you rebuild it and that’s it.

        Not going to work if the flags of the base packages are incompatible. You’d have to recompile the base package too.
        For example, I literally had to create a special patching mechanism because the qt package base has an incompatible flag making a qt-6 calamaris build spit out a fucked up package that wouldn’t launch.
        And that’s the best case scenario, it can go a lot worse then a failed build or failed launch.

        “What if the package has incorrect dependencies” — seriously, that’s your argument?

        No. Not incorrect depends, incorrect or undefined versioning of those depends. Version requirements is not properly enforced in the AUR unlike the official/Manjaro repos.
        Also you’re way more likely to get breakage using older packages because most things are forward compatible, not backwards.

        Well it would have been a crappy package anyway, no?

        I’ve written and adopted quite a large number of AUR packages at this point and read a shit load more. They’re often a lot more crappy than you realize; they’re community written, and I’m dead serious when I say there’s a lot of people who don’t fully read the guidelines or read them once 10y ago.
        Anyone can whip up a PKGBUILD a in matter of minutes and get it onto the AUR. The only thing that matters is that the package compiles and works on Arch, any other distro that’s not using the official repos is an unsupported case, full stop.
        Nobody who’s writing AUR packages wants to put in extra work to support the special edge cases of Manjaro. That’s just how it is.

        • lemmyvore@feddit.nl
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          2
          ·
          8 months ago

          Anyone can whip a PKGBUILD up in matters of minutes and get it onto the AUR. The only thing that matters is that the package compiles and works on Arch, any other distro that’s not using the official repos is an unsupported case, full stop.

          But nobody checks that the package “compiles and works on Arch”. It’s not a prerequisite for putting things on AUR. The fact is that any AUR package, on any distro including Arch, may be just plain broken at any given time.

          Even if the maintainer has successfuly built and ran the package it may be due to a particular circumstance specific to their system. There’s no guarantee that they did it on a reference Arch system. There’s no guarantee they did it on Arch. There’s no guarantee they did it at all. Even if they did, any similarity to your current system may be purely coincidental.

          Running a non-Arch distro may increase the odds of something going wrong. But maybe it decreases them. Short of testing all 87k AUR packages how can you tell? You’ve run into trouble with one package. I haven’t run into trouble with 75 packages. If my experience is not statistically significant than how’s yours, at one less order of magnitude?

          Don’t you think it’s disingenuous to present this as if it were a constant, pressing issue with Manjaro?

          • Rustmilian@lemmy.world
            link
            fedilink
            English
            arrow-up
            5
            ·
            edit-2
            8 months ago

            I’ve actually never run into any issues on Arch. ◉⁠‿⁠◉
            Like I said, I read the PKGBUILDS.
            Everything single one I’ve ever installed, which is several hundred.
            No amount of reading PKGBUILDs is going to save you from that one package that’s incompatible with Manjaro package base flags and configuration. It’s just not something immediately apparent.
            Infact, the only AUR related thing I’ve ever had problems with is pamac. Why? Well, clearly it’s not meant for Arch; no amount of recompiling pamac made it work any better.
            Also, you kinda need an Arch derivative at the least to sign up to the AUR because of the ever changing verification they have. There’s literally a command that you have to run that spits out the correct answer only if you’re using Arch or a derivative.
            What’s funny is Manjaro is the only derivate that often fails the check because of the packages being behind.

    • yianiris@kafeneio.social
      link
      fedilink
      arrow-up
      0
      arrow-down
      3
      ·
      8 months ago

      First of all generalizing about this is totally wrong, depending on what software/libraries a program depends on for build makes a huge difference. If it is good old C that is backwards compatible (hence the size of glibc) it will work all the time. Show me one debian or arch official package that is written in C and says for glibc >=2.35

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

      @Rustmilian @lemmyvore

      • Rustmilian@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        ·
        edit-2
        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.world
            link
            fedilink
            English
            arrow-up
            4
            ·
            edit-2
            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.