gdm3 or wayland or both broken after apt autoremove

[DerCaveman]

Hi!

I recently downgraded mesa packages which I had built from padoka ppa using thisand that information.
I had to persuade apt to do so (by providing all dependencies from official debian packages by hand), but in the end every package built by myself was "downgraded" to official Debian packages.
Apt shown no missing or broken packages, but some lib*-packages that could be autoremoved.

I did so and now my machine freezes with no error thrown when loading gdm3.

In recovery mode I switched to lightdm, which loads and can start a gnome session- but only an X session. The wayland session is gone. So I think that at least one of the autoremoved libs was needed by wayland and now wayland is broken.

Using this I reinstalled gdm3 and its dependencies which did not help.

Any ideas?

Thx!

[Wheelerof4te]

Your problem is that you tried installing a critical system componend from a PPA designed for Ubuntu. Even Ubuntu folk shouldn't update mesa from PPA, those are made to backport new versions of applications. Only reinstall can truly fix Frankendebian.
Don't worry, a lot of people have been there.

[GarryRicketson]

Suggested reading:

https://wiki.debian.org/DontBreakDebian

[DerCaveman]

Your problem is that you tried installing a critical system componend from a PPA designed for Ubuntu.

No, I used the "recipe" from the Ubuntu-PPA to bake me a new debian package (https://wiki.debian.org/CreatePackageFromPPA). And I installed it with Debian's package manager.
For me it looks like there is some missing dependency in Debian's packages.
And why gdm3 freezes(!) without any error output...

[Wheelerof4te]

Instead from a PPA, why didn't you backport new mesa from Testing by building package from source?
https://wiki.debian.org/BuildingTutorial
That is the proper procedure, aside from official Debian backports repository. But as I've said, installing new mesa *will* create instability in your system, as it depends on a lot of system-critical packages.
In hindsight, someone really needs to remove that wiki page for debianizing PPA packages, or at least put big warning text there "THIS WILL LIKELY BREAK EVERYTHING".
EDIT: Very first sentence:

If a package is available in an Ubuntu PPA but not in Debian, you can easily create a Debian version of it.

AFAIK, mesa is in Debian repos...

[DerCaveman]

But as I've said, installing new mesa *will* create instability in your system, as it depends on a lot of system-critical packages.

System was stable, everything worked.
Even now mesa works.

[Wheelerof4te]

^Well, good luck then. Until the next mesa (security) upgrade

[bw123]

Your problem is that you tried installing a critical system componend from a PPA designed for Ubuntu.

No, I used the "recipe" from the Ubuntu-PPA to bake me a new debian package (https://wiki.debian.org/CreatePackageFromPPA). And I installed it with Debian's package manager.
For me it looks like there is some missing dependency in Debian's packages.
And why gdm3 freezes(!) without any error output...

You said, "every package built by myself was "downgraded" to official Debian packages."

But you didn't say whether you purged the configuration of the (newer?) ppa-based pkgs before "downgrading" them.

Sounds complicated.

And why gdm3 freezes(!) without any error output... ? Well, that's the way stuff freezes, you hardly ever see a log entry that says, "Going to freeze up now."

I don't think the autoremove is the issue, like said above, it's the ppa stuff. Why, why, why? do people keep doing these things and then claiming it's a problem in debian, or apt, or something else?

[stevepusser]

Well, interesting...I did a test a few days ago when I found out how to keep the OBS workers from running out of RAM during heavy builds like for llvm and mesa: https://build.opensuse.org/project/show ... h-backport

Ths was just a test, so I did not do the backport versioning for most of the packages, instead I just downloaded and uploaded the source files from Buster to save time.

One of the mesa builds finished in only 786 seconds! The point is that a PPA source is only if you can't find it in Debian.

You can also check /var/log/apt/history.log to see what you autoremoved.

[DerCaveman]

I have checked "/var/log/apt/history.log" and found some "suspicious" autoremoved packages which I reinstalled:

gcc-6-base:i386
libegl-mesa0:i386
libegl1-mesa:amd64
libegl1-mesa:i386
libegl1:i386
libgl1-mesa-dri:i386
libgl1-mesa-glx:i386
libgl1:i386
libgles2-mesa:i386
libgles2:i386
libglx-mesa0:i386
libglx0:i386
libwayland-egl1-mesa:i386
mesa-common-dev:i386

GDM3 and wayland are working again

I don't think that the 32bit versions did the trick, so there is libegl1-mesa:amd64 left.

But you didn't say whether you purged the configuration of the (newer?) ppa-based pkgs before "downgrading" them.

No, I didn't.

And why gdm3 freezes(!) without any error output... ? Well, that's the way stuff freezes, you hardly ever see a log entry that says, "Going to freeze up now."

OK, I should have asked why there is no error output and a freeze instead of...

Why, why, why? do people keep doing these things and then claiming it's a problem in debian, or apt, or something else?

So why was the stuff needed by gdm3 "automatically" removed?

[bw123]

libegl-mesa0:i386
So why was the stuff needed by gdm3 "automatically" removed?

That's a good question, my best guess would be, because testing is tricky to maintain? Also, the multiarch might be an issue. You didn't mention either in your problem description. Manually adding pkgs with dpkg, and/or removing packages "manually" obviously confuses the "automatically installed" logic that apt uses. Throw in some "home-rolled" ppa2deb up/downgrade confusion and you have a pretty interesting mix of... why, why, why?

I haven't used testing/sid, but I know enought to never use "autoremove" on it. There looks to be a major change in some of the packaging between mesa 13 and mesa 17 in testing/sid.

http://packages.debian.org/libegl-mesa0

You'll notice this pkg isn't available for stretch, which is on mesa 13. There is probably a good reason mesa 17 hasn't been backported to stretch, It might be the packaging issues.

There's a pretty good wiki here, probably might help other testing users who don't want to play, "guess what I did?"
https://wiki.debian.org/DebianTesting

Please, have a look at the best practices for Testing/Unstable users, and consider implementing them.
https://wiki.debian.org/DebianUnstable# ... d_users.3F

[DerCaveman]

Being on (near) bleeding edge is a trade-off, I know.

The tip with "/var/log/apt/history.log" is a good one to bear in mind

Thank you all