Install Mesa 18.1.1 on Ubuntu 18.04 LTS with Unity DE lest go.
Iām running off the oibaf PPA on mesa 18.2-dev and I can say Iāve noticed Unity to be smooth 100% of the time when triggering expose, which typically gets sluggish after a while.
Very good iĀ“m user oibaf ppa i hope cant user effect window blur this oibafPPa
Only i cant user nvidia driver.
I installed Unity without that ppa just added it for testing. Everything seems fine and nothing is broken, I just uninstalled freepats. Some of the unity settings arenāt translated, they appear in english like Security & Privacy and Sharing.
Edit: Ohhā¦ and Online Accounts is using the wrong icon if you use another icon theme. Papirus is using credentials-preferences.svg for Online Accounts, I donāt know if thatās the upstream naming pattern.
Can someone confirm issues with mounting iso or img files with nautilus? When I try to mount one it asks me for the sudo password, but that never happened in previous releases. Iām also not able to properly unmount them, only after a restart the entries disappear, then I tried nemo and it worked fine.
I think itās an upstream issue, cause I installed Ubuntu 18.04 in a VM without installing Unity and in Gnome-Shell the same issue appears. I should mention that I only used the minimal install option on both installs, maybe thatās the reason.
If it is an upstream issue, can someone please file a bug report, cause I have no idea where and how.
The diff isnāt file managers, itās Archive Mounter vs. Disk Image Mounter. The later requires auth as set by org.freedesktop.udisks2.loop-modify-others
You can edit that if desiredā¦ (- /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy
2 Likes
Ok thank you but it isnāt working as intended. If you press the Cancel button at the authorization dialog itās mounting the file too and if you unmount them, the entries donāt disappear until he next restart. Installed Fedora 28 to check it and there are the same issues.
Unlike previous post this behaviour can be confirmed (dismissing auth mounts anyway, after unmounting entry remains)
So file a bug on gnome-disk-utility and or udisks2
(- as mentioned if that action, (udisks2) is set to <allow_active>yes</allow_active> then this poor behaviour canāt happen with Disk Image Mounter
2 Likes
Thank you for conforming it. The strange thing is, I installed 17.10.1 in a VM and mounted an iso file and there is no auth needed and they get properly unmounted (disappear from nautilus). Checked the settings of org.freedesktop.UDisks2.policy in both 17.10.1 and 18.04 for loop, they are identical, also checked the groups of the users, they are also identical.
The bug seems to be already reported, I will add my info there and thanks again, cause I didnāt know thatās an issue with gnome-disk-utility and not nautilus. I would have never found it. 
https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues/82
I guess this has also to do with it:
On a bit further thought (never use this option myself so was a little āfooledā) donāt think there is any real bug here. There is no auth needed to mount, the dialogue is just asking for auth to modify the ādeviceā. Itās possible in the past that occurred after mounting when accessing the ādeviceā?
So now itās just taking care of that right away.
No in the past you never had to auth for mounting iso files. Seems to be a bug in udisks as mentioned in the bugreport:
By the way, being asked for the password to mount the filesystem on the loop device was a UDisks regression and will be resolved in the next update.
Hope this gets fixed in Ubuntu too then.
Hi all,
I wanted to put this out there for a little feedback to the way I approach testing. Iām trying to develop procedures that are easily repeatable. Please take a look at my attached document and let me know if this is something you guys want to proceed with.
Thank you,
Pete
2 Likes
It seems you arenāt able to differentiate between mounting a loop device & modifying a loop device. The auth requested is for modifying. Maybe the act of mounting shouldnāt presume the intent to modify, if not thatās the bug. Mounting still occurs with no auth requested or required.
Thatās possible. 
I donāt know it isnāt clear in the bugreport what the problem was and what they fixed, but at least it should be fixed and thatās the important part. 
One problem Iāve found while using Unity with patched Nemo is that upon changing the desktop background, compiz seems to hard-freeze. Not even restarting lightdm can one get out of it, either go down to to ttyx and kill -s9 compiz, or reboot.
I believe this might be related to changing the background for the user at lightdm, as it reverts back to the default image (I do have the gsetting btw), whereas if I switch back to Nautilus it works OK.
Any movement with getting Unity fully integrated into Bionic? Iāve been playing with it in VirtualBox but it isnāt as fully functional as it is in Xenial. 18.04.1 will be released any day now, I imagine and I have to decide whether to stay on Xenial, upgrade to Bionic and hope I donāt find the Unity integration too annoying in its current state, or just switch over to Linux Mint.
I am not sure what you mean, have been running unity on 18.04 since release, it is as fully functional and integrated as I can remember and a lot smoother and more stable than default genome shell . VB is not a way to test Unity or any 3d desktop for that matter , most graphic effects wonāt work because VB only has very basic graphic driver.
Biggest issue seems to be Nautilus. On 16.04 there seems to be a running instance always in the background so right-clicking on the āFilesā icon in the launcher gives you a choice of multiple folders you can launch directly. In 18.04, right-clicking on āFilesā pretty much only allows you to launch it initially into your home directory. Once it has been launched, however, the icon in the launcher behaves the way it used to. Also, in 16.04, Ctrl+H only shows you the hidden files in the active nautilus window. In 18.04, it displays the hidden files in ALL of the open windows.