leftover conffile forces GNOME is software rendering

I have figured out the problem: the installer removed nux-tools, left over from unity, but did not purge it. This left a start up script in /etc/X11/Xsession.d which interfered with gnome. Purged that and the problem was gone.

So this is a dependency bug in the nux-tools package (or perhaps some mistakenly identified changed file which turned into evil cruft). Sigh. Took me a long time to find this.

Status changed to 'Confirmed' because the bug affects multiple users.

I've purged nux-tools but the problem is still there for me.

Emiliano: the problem file is '/etc/X11/Xsession.d/50_check_unity_support'. You might want to confirm that this is gone with the purge.

That file was gone before the reboot, verified.

On Mon, May 21, 2018, 15:00 Martin D. Weinberg <email address hidden>
wrote:

> Emiliano: the problem file is
> '/etc/X11/Xsession.d/50_check_unity_support'. You might want to confirm
> that this is gone with the purge.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1768610
>
> Title:
> No acceleration after upgrading to 18.04: gnome-session-check-
> accelerated incorrectly picks llvmpipe
>
> Status in gnome-session package in Ubuntu:
> Confirmed
>
> Bug description:
> After an upgrade from 17.10 to 18.04, I noticed that all gnome windows
> animations were gone. After some digging, it seems that gnome-session
> incorrectly assumes that my graphics has no acceleration, when in fact
> it does: it's a i5-2520M CPU @ 2.50GHz with Intel integrated graphics
> (i915 driver).
>
> I've tried this with and without the xserver-xorg-video-intel package
> (a.k.a. Intel driver) with the same behavior.
>
> The output of gnome-session-check-accelerated is: llvmpipe (LLVM 6.0,
> 256 bits) however the system should have DRM 2.0 capability.
>
> GL checks (e.g. glxinfo, glxgears produce the expected output from a
> working DRM system).
>
> mesa-utils and mesa-utils-extra are both installed.
>
> I can't find a work around. Perhaps there is something wrong with my
> install/upgrade?
>
> Everything else works fine, although the graphical transitions are no
> longer smooth. But it would be nice to restore the expected behavior.
>
> I have attached the log of 'journalctl -b0'
>
> ProblemType: Bug
> DistroRelease: Ubuntu 18.04
> Package: gnome-session 3.28.1-0ubuntu2
> ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
> Uname: Linux 4.15.0-20-generic x86_64
> ApportVersion: 2.20.9-0ubuntu7
> Architecture: amd64
> CurrentDesktop: ubuntu:GNOME
> Date: Wed May 2 13:06:00 2018
> EcryptfsInUse: Yes
> InstallationDate: Installed on 2016-04-22 (739 days ago)
> InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64
> (20160420.1)
> ProcEnviron:
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: gnome-session
> UpgradeStatus: Upgraded to bionic on 2018-04-27 (5 days ago)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1768610/+subscriptions
>

I'm not an expert, but you might want to see if you can gain some insight from the output of 'journalctl -b0'.

E.g. is your system using the framebuffer driver "fbcon: xxx" or "[drm] ..." during boot up?

In the 'journalctl -b0' output I posted above,you can see that it's using the frame buffer. That is what lead me to track down system configuration issues.

mei 21 17:05:15 titanarum kernel: fbcon: inteldrmfb (fb0) is primary device

Emiliano: I'm grabbing at straws, but try checking for other files in '/etc/X11/Xsession.d/' that might be setting 'export LIBGL_ALWAYS_SOFTWARE=1' in the environment. E.g. 'grep -H LIBGL /etc/X11/Xsession.d/*'

I truly appreciate the grasping. I've ran

find /etc/X11/ -type f -exec grep -il always_soft {} \;

and I'm getting 0 results.

grep -H LIBGL /etc/X11/Xsession.d/*

same results (being none)

Well, this sounds like a different problem. The problem I reported was very clearly the result of an incomplete package upgrade/removal resulting in a failed test for unity compatibility leading to setting that environment variable for software gl.

You might consider opening an new bug report with a complete system info. E.g. you didn't report your video chipset, but I have heard that there are nuances with nvidia.

I've opened a new bug at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1772366

(I'm on intel hd 520 BTW, which is how I git to this bug report)

I look a quick look at your posted data. It does seem odd that your system starts out configuring the drm and then uses fb. Do you have anything custom on your boot line, like some video parameters? E.g. 'cat /proc/cmdline'. More grabbing at straws.

P.S. I also note that you are using wayland. No reason to think it will matter, but just of of curiosity, have you tried the xorg session?

/proc/cmdline:

BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=3f2f5445-3b08-4786-b00a-1d79abd0f707 ro quiet splash vt.handoff=1

I alternate between Wayland and Xorg now. I'd prefer to use Xorg; under Wayland I see the intel card being used, under xorg I see llvmpipe.

Did I submit under Wayland. That's dumb. Can I send my logs again?

Yes, I would make a new comment to your bug report with the logs under xorg session. I hope that one of the Ubuntu developers have a clue about this. I'm curious myself.

I thought I did send it under X11, but have verified I'm on x11, and have sent new logs using apport-collect.

I see BTW that intel recommends kernel 4.16 in its stack (https://01.org/linuxgraphics/downloads/2018q1-intel-graphics-stack-recipe). Could that be an issue? I have 4.15, I don't think a newer kernel is available in Ubuntu.

If you want to try that, you can grab a more recent kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/ but I doubt that this will fix your issue. I'd bet on a configuration thing, but not sure what. You don't, by any chance, have a custom xorg.conf (in /etc/X11 or /usr/share/X11)? I think that working under Wayland but not Xorg is an important clue.

$ find /etc/X11 -iname xorg.conf

and

$ find /usr/share/X11 -iname xorg.conf

both return 0 files

Can I somehow reset the xorg conf (and expect it to work)?

xorg.conf has been replaced by the rules in /usr/share/X11/xorg.conf.d. You can see if there is some older cruft in there.

There is a single file there called 20-intel-graphics.conf which contains

Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "TripleBuffer" "true"
   Option "TearFree" "true"
   Option "DRI" "false"
EndSection

*smacks forehead* it's the DRI false, right? I've commented out that file and rebooted and I see the intel card being used now.

The issue there is a that nux-tools has a conffile that does
" /usr/lib/nux/unity_support_test || export LIBGL_ALWAYS_SOFTWARE=1"

When the package is removed but not purged the command fails and software rendering is enabled wrongly

Marco could you have a look, we should probably fix the script to not export the env if the helper is missing

Sebastien: Yes, that is precisely the issue! Took me an afternoon of sleuthing to figure it out.

Emiliano: You might want to find out if any package is providing that file (e.g. dpkg -S 20-intel-graphics.conf) and delete that file if it turns out to be orphaned. I do not that file, but I do have xserver-xorg-video-intel installed.

Nothing on the dpkg -S, but I've tried so much that it's very conceivable I put it there.

(I did at one point have the 50_check_unity_support; I probably was toying with 20-intel-graphics.conf from scrounged sources before I removed the 50_check_unity_support file.

I've set the duplicate the other way round because the original bug is already milestoned.

I'm adding a mesa task, as this bug also needs to be fixed for people who *already* removed the package without purging it. I suggest mesa, because that's the package that LIBGL_ALWAYS_SOFTWARE=1 acts on (mostly?) - so fixing it there will fix for everybody whereas ubuntu-desktop or whatever might miss some people. But it's a matter for Marco and the mesa maintainers really.

(you can reassign that task from mesa to something else if it's going to be fixed elsewhere)

This bug was fixed in the package nux - 4.0.8+18.10.20180613.3-0ubuntu1

---------------
nux (4.0.8+18.10.20180613.3-0ubuntu1) cosmic; urgency=medium

  * debian/50_check_unity_support:
    - various changes to fix (LP: #1768610):
      + export LIBGL_ALWAYS_SOFTWARE=1 only on command failure
      + run only when called inside an unity session

 -- Marco Trevisan (Treviño) <mail@3v1n0.net> Wed, 13 Jun 2018 12:20:53 +0000

I'm happy to do it in any package postinst, I was thinking more to keep it somehwere under the desktop team control, as it's something we should care about, while I prefer to have it fixed at least to anyone who has installed ubuntu-desktop.

But I agree it's wrong also for other people using desktop under X11 (and who might have just tried unity in the past), so staying lower is fine.

If mesa is fine to accept this, I'm happy to do it.

It seems to me that the most likely area of SRU regression would be an accidental functional change in 50_check_unity_support in the case of a user using a previous release. For SRU verification, in addition to the test case, please could you also check that the previous release correctly sets LIBGL_ALWAYS_SOFTWARE in the four cases of Unity vs. not-Unity and unity_support_test and !unity_support_test?

Hello Martin, or anyone else affected,

Accepted nux into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nux/4.0.8+18.04.20180613.5-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Martin, or anyone else affected,

Accepted nux into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nux/4.0.8+17.10.20180613.3-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Martin, or anyone else affected,

Accepted nux into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nux/4.0.8+16.04.20180613.1-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I've playing with this a bit more to get the fix for the currently affected users who already upgraded to bionic and removed nux-tools, but I don't think there's a solution which works if we keep this marked as a Conffile by dpkg.

In fact, using the various rm_conffile or just removing the file from a maintainer script in any other package, then if the user will try to reinstall unity (and then nux-tools), this config file won't be reinstalled, as it's still there according to dpkg.

If anyone know a solution in how we can manipulate the dpkg status from a maintainer script, that's the way, otherwise I've no other idea than going back to the solution I proposed in the last night's MPs of removing this conffile from nux-tools itself, storing it in /usr and then symlinking it (with new name) to /etc [1] as mentioned (although for other scenarios) in maintainers guide. So at that point any reinstall will just work, and no purge will affect it.

PS: other *ugly* option would be instead to make this other-package (mesa?) to replace in a maintainer script the content of this file with the fixed one, but really I don't want to go in that way.

[1] https://bazaar.launchpad.net/~3v1n0/nux/x11-conffile-on-unity-only/revision/893

On a 2nd thinking, if that nux-tools reinstall will happen after this nux SRU landed (and of course assuming that this will be after the "fixing-package" containing the maintainer script has ran too), since the content of the config file will mismatch (being deleted), debhelper will ask to reinstall a new version with the classic:

Configuration file '/etc/X11/Xsession.d/50_check_unity_support'
 ==> Deleted (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.

However, I'm not either a fan of having this around since it's something the distro caused, not the user.

This is the solution that I proposed to you in private. It is a fix to mesa (a "common" package) and a followup to nux-tools.

It needs some testing. In particular I don't think I picked the right mesa package to use, and we also need to check with the mesa maintainer. There are various version numbers in there that need to be correct for the target release.

A basic test worked OK though (libegl1-mesa is because I had it in an even more wrong package at the time). Remove nux-tools, broken conffile is left around, upgrade mesa, it's fixed, install new nux-tools and it's installed with the right content and no prompt:

root@nux-tools-test:~# apt remove nux-tools
...
root@nux-tools-test:~# ls /etc/X11/Xsession.d/50_check_unity_support
/etc/X11/Xsession.d/50_check_unity_support
root@nux-tools-test:~# sudo apt full-upgrade
...
Broken /etc/X11/Xsession.d/50_check_unity_support and removed nux-tools found, moving aside...
root@nux-tools-test:~# sudo apt install nux-tools
Found saved /etc/X11/Xsession.d/50_check_unity_support.mesa-save file, moving it back in place...
Unpacking nux-tools (4.0.8+18.04.20180613.5-0ubuntu2) ...
Setting up nux-tools (4.0.8+18.04.20180613.5-0ubuntu2) ...
Installing new version of config file /etc/X11/Xsession.d/50_check_unity_support ...
root@nux-tools-test:~# cat /etc/X11/Xsession.d/50_check_unity_support
# This file is sourced by Xsession(5), not executed.
# If the hardware does not pass unity_support_test, fall back to LLVMpipe
# which does.

if [ "x$DESKTOP_SESSION" = "xubuntu" ] && [ -x "/usr/lib/nux/unity_support_test" ]; then
    (
        IFS=':'
        for d in $XDG_CURRENT_DESKTOP; do
            if [ "x$d" = "xUnity" ] || [ "x$d" = "xUnity7" ]; then
                return 0
            fi
        done
        return 1
    )

    if [ $? = 0 ]; then
        /usr/lib/nux/unity_support_test || export LIBGL_ALWAYS_SOFTWARE=1
    fi
fi

Yeah, I basically did the same too, but honestly I didn't want to change nux again with another SRU (I preferred to fix this with just one on that side); and most importantly in a such way. As it would now include some checks that depends on changes done in other packages, making from my POV things even more hackish and annoy to matain and easy to be broken.

Not that other solutions wouldn't involve the other package (say mesa) to act on nux file, but that should be in a way that nux is not aware of that, creating any kind of "inter-dependency" in between them.

I'm trying the bionic version of the proposed nux-tools (4.0.8+18.04.20180613.5-0ubuntu1) and it works fine so far.

Marco, I don't think there is a solution that satisfies all the requirements and doesn't involve nux cooperating in some way. I've given you mostly-working debdiffs now - can we please move forward with them?

I'd rather put it in x11-common (src:xorg), which already is full of distro specific things and is installed on every system

also, it actually ships stuff in /etc/X11/Xsession.d

Added scripts in in x11-common (debdiff) and nux-tools (see attached MPs)

Status changed to 'Confirmed' because the bug affects multiple users.

Cheers!

My nux-tools review comments apply to x11-common too. The following are for x11-common:

What's the reason for doing this in preinst rather than postinst configure? It's fine in this case but usually we do things in postinst where possible.

What about adding a "Breaks: nux-tools (<< 4.0.8+18.04.20180613.5-0ubuntu1)" to x11-common, and making the script not do the fix up if we're upgrading from the new version ("if dpkg --compare-versions "${2}" lt 1:7.7+19ubuntu8; then do stuff; fi")?

I think it's a good idea generally to make fix up actions in maintainer scripts strictly limited to certain package versions and this will mean if you still have nux-tools installed you have to upgrade it to the fixed version, so the removal can only have happened earlier than x11-common 1:7.7+19ubuntu8.

> What's the reason for doing this in preinst rather than postinst configure?

Well, I just wanted to make sure this happened as early as possible, since this is not related to what the package installs, I thought it was better to handle this in preinst, so that this can be also just removed at later times.

> What about adding a "Breaks"...

Done. Agree.

--

New debdiff. Updated MPs too.

> Well, I just wanted to make sure this happened as early as possible, since this is not related to what the package installs, I thought it was better to handle this in preinst, so that this can be also just removed at later times.

The thing about the preinst is that it runs super early, you can't even rely on the package's dependencies being installed. In this case we don't use any non-Essential tools, so it's OK, but often this is a problem. We don't *need* to use the preinst, since either the pkg is removed or not removed before we even start installing x11-common - at postinst time it's going to still be removed or it's going to get upgraded to the fixed version.

There's a bug in x11-common. If the preinst check triggers twice (like on a xenial dist-upgrade and then again when you upgrade to bionic), the upgrade fails:

Preparing to unpack .../x11-common_1%3a7.7+19ubuntu7.1_all.deb ...
Moving obsolete conffile /etc/X11/Xsession.d/50_check_unity_support to /etc/X11/Xsession.d/50_check_unity_support.x11-back...
mv: cannot stat '/etc/X11/Xsession.d/50_check_unity_support': No such file or directory
dpkg: error processing archive /var/cache/apt/archives/x11-common_1%3a7.7+19ubuntu7.1_all.deb (--unpack):
 new x11-common package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/x11-common_1%3a7.7+19ubuntu7.1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Fixed that by adding a [ -f ] check, and then I made the same fixes as on the MP, expanded the changelog a bit, and uploaded to the silo (3299) for all releases. Please check my diffs - particularly the versions.

Could you add some testcases for this please? Like

 - remove nux-tools from bionic-release (pre-sru), upgrade, reinstall nux-tools (no prompt)
 - remove nux-tools from bionic-proposed/updates (sru), upgrade, reinstall nux-tools (no prompt)
 - modify config file, remove nux-tools, upgrade, reinstall nux-tools (should prompt)
 - install nux-tools, upgrade, no prompt

You end up with either no /etc/X11/Xsession.d/50_check_unity_support, its new contents or you are asked what to do if you've changed it before. Never the old content.

They're all uploaded now. To the SRU team - these are quite delicate SRUs. I think they're right, but more eyes would be appreciated.

The essence is that when nux-tools is removed-not-purged at a buggy version, the leftover conffile is harmful. So we picked a core package, x11-common, and made it stash the conffile away. Then nux-tools will pick it up if it's reinstalled and upgrade it to the fixed version in the normal way.

This bug was fixed in the package xorg - 1:7.7+19ubuntu8

---------------
xorg (1:7.7+19ubuntu8) cosmic; urgency=medium

  * x11-common.preinst:
    - Rename nux config leftovers which might change the environment
      even when not running an unity session (LP: #1768610)
  * debian/control:
    - x11-common breaks nux-tools (<< 4.0.8+18.04.20180613.5-0ubuntu1) - this
      version contains the fixed conffile; if it's installed on the system we
      need people to be upgraded to the new version.

 -- Marco Trevisan (Treviño) <email address hidden> Thu, 21 Jun 2018 11:37:03 +0100

This bug was fixed in the package nux - 4.0.8+18.04.20180613.5-0ubuntu1

---------------
nux (4.0.8+18.04.20180613.5-0ubuntu1) bionic; urgency=medium

  * debian/50_check_unity_support:
    - various changes to fix (LP: #1768610):
      + export LIBGL_ALWAYS_SOFTWARE=1 only on command failure
      + run only when called inside an unity session

 -- Marco Trevisan (Treviño) <mail@3v1n0.net> Wed, 13 Jun 2018 12:20:33 +0000

The verification of the Stable Release Update for nux has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Hello Martin, or anyone else affected,

Accepted nux into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nux/4.0.8+18.04.20180622.2-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Martin, or anyone else affected,

Accepted xorg into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xorg/1:7.7+19ubuntu7.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Martin, or anyone else affected,

Accepted nux into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nux/4.0.8+16.04.20180622.2-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Martin, or anyone else affected,

Accepted xorg into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xorg/1:7.7+13ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Tested in a Xenial machine, upgrading packages to:

x11-common:
  Installato: 1:7.7+13ubuntu3.1
  Candidato: 1:7.7+13ubuntu3.1
  Tabella versione:
 *** 1:7.7+13ubuntu3.1 500
        500 http://ppa.launchpad.net/ci-train-ppa-service/3303/ubuntu xenial/main amd64 Packages
        500 http://ppa.launchpad.net/ci-train-ppa-service/3303/ubuntu xenial/main i386 Packages
        100 /var/lib/dpkg/status
     1:7.7+13ubuntu3 500
        500 http://it.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        500 http://it.archive.ubuntu.com/ubuntu xenial/main i386 Packages
nux-tools:
  Installato: 4.0.8+16.04.20180622.2-0ubuntu1
  Candidato: 4.0.8+16.04.20180622.2-0ubuntu1
  Tabella versione:
 *** 4.0.8+16.04.20180622.2-0ubuntu1 500
        500 http://ppa.launchpad.net/ci-train-ppa-service/3303/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status
     4.0.8+16.04.20170816-0ubuntu1 500
        500 http://it.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
     4.0.8+16.04.20160209-0ubuntu2 500
        500 http://it.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

Running unity works propery, after upgrade, nux-tools is kept and file not run... After autoremove, it gets removed and gnome-shell runs properly.

This bug was fixed in the package xorg - 1:7.7+19ubuntu7.1

---------------
xorg (1:7.7+19ubuntu7.1) bionic; urgency=medium

  * x11-common.preinst:
    - Rename nux config leftovers which might change the environment
      even when not running an unity session (LP: #1768610)
  * debian/control:
    - x11-common breaks nux-tools (<< 4.0.8+18.04.20180613.5-0ubuntu1) - this
      version contains the fixed conffile; if it's installed on the system we
      need people to be upgraded to the new version.

 -- Marco Trevisan (Treviño) <email address hidden> Thu, 21 Jun 2018 11:48:13 +0100

This bug was fixed in the package nux - 4.0.8+18.04.20180622.2-0ubuntu1

---------------
nux (4.0.8+18.04.20180622.2-0ubuntu1) bionic; urgency=medium

  * debian/control: update Vcs
  * debian/nux-tools.preinst:
    - Restore backup config files before installing nux-tools, so that they
      will be updaded with the fixed versions (LP: #1768610)
  * debian/rules:
    - build tests using LIBGL_ALWAYS_SOFTWARE env var to fix build crash
      on launchpad builders (there are memory errors in the hw drivers).

 -- Marco Trevisan (Treviño) <mail@3v1n0.net> Fri, 22 Jun 2018 13:05:07 +0000

This bug was fixed in the package xorg - 1:7.7+13ubuntu3.1

---------------
xorg (1:7.7+13ubuntu3.1) xenial; urgency=medium

  * x11-common.preinst:
    - Rename nux config leftovers which might change the environment
      even when not running an unity session (LP: #1768610)
  * debian/control:
    - x11-common breaks nux-tools (<< 4.0.8+16.04.20180613.1-0ubuntu1) - this
      version contains the fixed conffile; if it's installed on the system we
      need people to be upgraded to the new version.

 -- Marco Trevisan (Treviño) <email address hidden> Thu, 21 Jun 2018 12:04:37 +0100

This bug was fixed in the package nux - 4.0.8+16.04.20180622.2-0ubuntu1

---------------
nux (4.0.8+16.04.20180622.2-0ubuntu1) xenial; urgency=medium

  * debian/control: update Vcs
  * debian/nux-tools.preinst:
    - Restore backup config files before installing nux-tools, so that they
      will be updaded with the fixed versions (LP: #1768610)

 -- Marco Trevisan (Treviño) <mail@3v1n0.net> Fri, 22 Jun 2018 13:16:40 +0000