foobar's questions

I know how to read the status in dpkg -l (first letter is desired state, second is actual state). For example ii means "should be installed and actually is installed" and rc means "should be removed but config files are still there".

For me these ic packages are example-content, pppconfig, pppoeconf and unity-lens-applications (I'm on Ubuntu 19.10).

But what exactly does ic mean? Formally it means it is installed, but only the configuration files are there. Why does apt-get not install/fix the packages if they are not ii? How do I interpret this state? Should I do something about this?

Or do these packages only consist of configuration files? (shouldn't they still have ii then because they are installed correctly?)

Using Ubuntu 19.10 which was upgraded throughout the years (starting with 16.04). I just disovered that I have multiple versions of gcc installed and wondered why (I do not develop/compile C/C++ on the device). When doing

dpkg -l | grep gcc

I get gcc-5 to gcc-9 (+ some libs and -base). When simulating a purge with

apt-get -s purge gcc-5

(and for all the others numbers as well) only gcc-9 seems to have actual important dependants (Virtual Box for me, which I use). The others only render other lib or cpp packages obsolete.

Why are they even there anyways without manual installation by me? Or not removed when they became an obsolete dependency (not even deborphan -a lists them)? I already did apt-get autoremove --purge.

Can I remove the old versions without loss of important packages/features?

I just upgraded from Ubuntu 19.04 to Ubuntu 19.10. This made that my second internal HDD show up in the launcher bar or Ubuntu Dock, which it did not before.

I read that I should mount it to /mnt instead of /media, but this device was auto-mounted years ago (I believe in Ubuntu 16.04 or so) and I have a lot of symlinks and other references to the path in /media already.

How can I remove the icon from the dock without unmounting it or having to mount it to a different location? I can not even move it to another location on the bar.

For years I'm using Ubuntu (currently on 18.10) to develop PHP applications on domains like foo.bar.localhost for local testing. These domains were resolved to 127.0.0.1 and handled by Apache 2.4. This always worked. The line 127.0.0.1 localhost is in my /etc/hosts like it always was.

Today morning I turned my device on and this did not work anymore. ping localhost is still working, but ping foo.bar.localhost is not (it still was working yesterday). Surprisingly Chromium is still resolving foo.bar.localhost, I assume it's not using the OS for DNS resolving. But I'm mainly using Firefox, which also stopped resolving localhost subdomains.

I didn't change any system-related settings yesterday, but I remember some package updates from yesterday, so I assume there were some changes to some network-related things. Is there any way to get dpgk to list install/update dates so that I can find out the exact packages that were updated?

What settings could I check to make resolving subdomains work again system-wide? Are there any known bugs?

Additional information: In /var/log/dpkg.log I found a recent entry upgrade resolvconf:all 1.79ubuntu10 1.79ubuntu10.18.10.1 which sounds relevant. This and the following subsequent lines are the only lines containing the term "resolv" (found with cat /var/log/dpkg.log | grep resolv). So, in the last hours this DNS-relevant package was updated.

Another information: the manual man systemd-resolved has the following line:

The hostnames "localhost" and "localhost.localdomain" (as well as any hostname ending in ".localhost" or ".localhost.localdomain") are resolved to the IP addresses 127.0.0.1 and ::1.

So this well-defined behaviour stopped working. I also can not remember changing anything related to this lowlevel DNS stuff myself.

The exact message when doing ping foo.bar.localhost is

ping: foo.bar.localhost: Name or service not known

Apparently the only bug "fixed" in the new version of resolvconf was this: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1817903 which is related to local resolving.