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)

  • lemmyvore@feddit.nlEnglish
    412·
    2 years ago

    So what if they’re behind. AUR packages have dependency requirements too. They won’t install if dependencies are not met. Unless you force it — but that wouldn’t be their fault.

    So how can an AUR package break something if it’s not installed?

      • lemmyvore@feddit.nlEnglish
        24·
        2 years 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.

          • lemmyvore@feddit.nlEnglish
            22·
            2 years 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?

      • yianiris@kafeneio.social
        03·
        2 years 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