"Resetting" neon to standard sources

I have fiddled around with custom repositories over time (added them, removed them etc.)

Now I sometimes have dependency problems (like xwayland-dbgsym not being able to be installed because the installed version of xwayland is 22.1.1-1ubuntu0.6 instead of just 22.1.1-1.

So, how do I check whether there are any unwanted “residues” from custom repositories?

The one I am most concerned about is that I tried to install the AMD gpu driver because I wanted to see whether the official driver is supported by stable diffusion (which it isn’t, it still used the cpu). I think that deinstalling the gpu driver left some residues that messed up my dependencies.

Oh here is the list of my repos from discover:

So, there are two databases you want to look at - the dpkg data (/var/lib/dpkg) that records which packages are currently installed on your system, their version and other metadata; and the APT data (/var/lib/apt/lists) which records which packages are available from repositories that your system knows about (and have cached their “Packages” files).

You can use the command line tool apt-cache to query both databases - by running (in a terminal) apt-cache showpkg <PACKAGENAME> you’d get a long output describing what APT knows about that package - it will list for each version of the package that APT knows about, from which repository cache it comes (in the form of a cached “Packages” file with a path like /var/lib/apt/lists/<repository-hostname>_<dist-name>_<pocket-name>_<architecture>_Packages) and whether that specific version is also what dpkg knows about, by listing /var/lib/dpkg/status as a “repository” for that version. You can then tell if a package you have installed is of a version that does not exist in any repository by seeing that the version that comes from /var/lib/dpkg/status does not have any /var/lib/apt/lists source.

Generally you can run apt-cache showpkg "*" (the double quotes are important) to get apt-cache to show you all the packages, and scour that very very long document for such package versions.

Or, we can script it:

Here’s a script that uses dpkg-query to list all the packages dpkg knows about and their installed version, then we filter the output of apt-cache showpkg for that package by looking for the version line that has the dpkg/status label and seeing if it also has apt/list label - and if it doesn’t, we print it out with the current version.

dpkg-query --show -f '${Package} ${Version}\n'| while read pkg ver; do
  apt-cache showpkg $pkg | grep "$ver .*\(/var/lib/dpkg/status\)" | \
      grep -q apt/lists || echo $pkg=$ver

If I run this script and it generates this list of packages with their version number, what exactly can I see there. Or, what are my next steps if I now know all of these packages?

(I’m asking because I have a similar issue I described here )

These are the packages that are the “residue” - as you’ve put it. They are installed even though no repository owns them.

Its really up to you what you want to do with these, and I think it should depend on why these packages are listed:

  1. It could be that it is a package from a PPA or something like that, that was an “alternative” to packages from one of the base repo. you can run apt policy <PACKAGENAME> to see which repositories know about that package, and upgrade or downgrade to the “supported” version. Due to dependencies, this may be difficult as you’d need to update multiple packages at once, possibly each to a different version. apt install PACKAGE=VERSION OTHERPACKAGE=OTHERVERSION is the syntax to use, but it is a practice in frustration and patience.
  2. It could be a package that you clearly no longer want - it should be safe to remove, and if not - APT will complain.
  3. It could be a package you downloaded of the internet (for example I have the commercial 1Password application installed that way) so you may want to just keep it.
1 Like

Yea, this is basically my point (1) above. I will try to answer there with more specific instructions.

1 Like

It looks like Ubuntu’s xwayland-dbgsym has a broken dependency list, since this happens in *buntu 22.04 as well.

To add to the confusion, here are some info about debug symbols in Ubuntu, with some conflicting info:

I don’t know where to find or file a bug on dbgsym packages, but if they are using Debuginfod, this situation simply may not have come up or be reported.

Your sources list seems fine to me, if you are using GDB or some other debugger, you may not need the dbgsym packages at all, and probably can disable them if you wish.

Actually, I think I may know why.

The instructions most places provide for adding debug symbols also includes adding the “proposed” pocket, which are so-called “pre-release updates”.

if xwayland and xwayland-dbgsym have packages in Proposed for testing before being released as official updates, your ddebs repo is ahead of your normal repos, as they don’t include the “proposed” pocket.

xwayland-dbgsym IS at version 22.1.1-1 in Proposed, while the normal package for xwayland is 22.1.1-1ubuntu0.6 in the normal repos.

To get them to match, you could enable the "proposed’ pocket on your standard repos (NOT recommended!)
disable the ddebs line in Discover that shows “ddebs.ubuntu.com Jammy Proposed”, update, and try again. The version for the dbgsym package(s) should now match the regular packages.

1 Like

Thanks a lot for your script. I ran it, found out a few problems and was able to fix them. Now the only thing that remains is libruby2.7 and libssl1.1 that cannot be uninstalled because neon-settings-2 depends on ruby, which is not going to be installed.
Of course ruby is installed, and libruby3.0 is there, so the problem has to be somewhere else. Same for libssl, libssl3.0 is installed.
How can I fix this? I tried apt-get -f remove libruby2.7, but it doesn’t work either.

Thanks a lot for this hint, it helped with resolving some of the issues.