backtrace

(gdb) bt
#0  0x0000556e81d050a8 in user_change_automatic_login_authorized_cb (daemon=0x556e83376bc0 [Daemon], user=0x556e83396e40 [User], context=0x7f3524002e40 [GDBusMethodInvocation], data=0x1) at ../src/user.c:2662
#1  0x0000556e81d01148 in check_auth_cb (authority=<optimized out>, res=<optimized out>, data=0x556e83398530) at ../src/daemon.c:1683
#2  0x00007f354a3ee33f in g_simple_async_result_complete (simple=0x556e833bb3e0 [GSimpleAsyncResult]) at ../gio/gsimpleasyncresult.c:804
#3  0x00007f354a196264 in  () at /usr/lib/libpolkit-gobject-1.so.0
#4  0x00007f354a402ae4 in g_task_return_now (task=task@entry=0x556e8339a890 [GTask]) at ../gio/gtask.c:1309
#5  0x00007f354a4037cd in g_task_return (type=<optimized out>, task=0x556e8339a890 [GTask]) at ../gio/gtask.c:1378
#6  g_task_return (task=0x556e8339a890 [GTask], type=<optimized out>) at ../gio/gtask.c:1335
#7  0x00007f354a46d91e in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x556e8339a890) at ../gio/gdbusproxy.c:2571
#8  0x00007f354a402ae4 in g_task_return_now (task=task@entry=0x556e8339a320 [GTask]) at ../gio/gtask.c:1309
#9  0x00007f354a4037cd in g_task_return (type=<optimized out>, task=0x556e8339a320 [GTask]) at ../gio/gtask.c:1378
#10 g_task_return (task=0x556e8339a320 [GTask], type=<optimized out>) at ../gio/gtask.c:1335
#11 0x00007f354a461013 in g_dbus_connection_call_done (source=0x556e83373070 [GDBusConnection], result=<optimized out>, user_data=0x556e8339a320) at ../gio/gdbusconnection.c:5887
#12 0x00007f354a402ae4 in g_task_return_now (task=task@entry=0x556e8339a3e0 [GTask]) at ../gio/gtask.c:1309
#13 0x00007f354a402b19 in complete_in_idle_cb (task=0x556e8339a3e0) at ../gio/gtask.c:1323
#14 0x00007f354a2051c0 in g_main_dispatch (context=0x556e83366f80) at ../glib/gmain.c:3460
#15 g_main_context_dispatch (context=context@entry=0x556e83366f80) at ../glib/gmain.c:4200
#16 0x00007f354a2055b9 in g_main_context_iterate (context=0x556e83366f80, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4276
#17 0x00007f354a20587f in g_main_loop_run (loop=loop@entry=0x556e83367190) at ../glib/gmain.c:4479
#18 0x0000556e81cff1d3 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:283

Can confirm it's borked on gnome

I'm getting a segfault when trying to activate auto login

I'm on unstable. I tested it and it still doesn't do anything on X11 session. I don't know if this will help, but i notice in Manjaro this
/org/gnome/settings-daemon/plugins/xsettings/overrides doesn't have default value while Solus do.

Manually unlocking the keyring is expecting behavior if you have auto-login enabled. If you login with a PW then the keyring will unlock automatically with that PW if the PW is the same. When you don't have to login then you will need to manually unlock the keyring

I see similar behavior, but not the same, on a Budgie VM running unstable, updated. It was created with the 4.4 ISO.
After rebooting, I see "Unlock Login Keyring"

This should resolve the issue, however it'll need some testing. If you're on unstable you can update and give it a try.

Assigning to the maintainer.

I forgot an important piece of info but maybe it's better be added here:

Just a comment:
I would also like to check any connection to the OLD, FIXED language indicator crash/empty non responding panel successfully fixed by last sync and last Ibus 1.5.28-28's revision by Ebon Jaeger, and to the logs from the PAST, OLD, resolved issue.

After the update that was released on 4 August, this is still unresolved, but it has changed, indicating that Oracle may be working on it. Whereas before, when a VM went to full screen during a Wayland session, it would immediately lock up, and be unresponsive. Since, at full screen, it then covered the host's display, the host was also locked up, for all practical purposes.

In T8061#203196, @TClark77 wrote:

I have been able to connect to calls in Element with my bluetooth earbuds without experiencing this particular issue. I've experienced a slightly different, maybe similar issue with pipewire on Plasma.

Steps to reproduce:

• Connect to bluetooth earbuds
• Use the system tray sound icon to choose the "handsfree" setting for the earbuds rather than high-fidelity (handsfree allows both mic input and audio output)
• Start Element
• Join a call

The mic input was fine, but the output volume is at 0% in the system tray volume applet. I have to manually set the output volume to something above 0% every time I have a call.

I have been able to connect to calls in Element with my bluetooth earbuds without experiencing this particular issue. I've experienced a slightly different, maybe similar issue with pipewire on Plasma.

So, after rebooting with 1.11.37, Element connected just fine. Updated the system (including Element 1.11.38) and no problems since. Closing the task.

Much appreciated - Can confirm host sees all available cpus.

Oh, and can you update to the latest Element (1.11.38)?

A couple of things to look at:

https://dev.getsol.us/R3571:39fd7666ddbf3f0f2b94162273de321294e63f11 and https://dev.getsol.us/R1966:c2a30b68f7b831ec3eebdfb5a7dc159bc2403914

Hm, I cannot reproduce this problem, either on latest stable or unstable...

After the latest sync, the auto login doesn't work again. Should I open another ticket? The lightdm folder still exists and has a lightdm.conf in it with an autologin-user set

@ReillyBrogan : Do we want to switch this to 128?

incapable of doing stuff ulimit, as i have switched to arch linux as i am one to do, should be default. However, i can confirm that i have 16gb system ram and swap available, but I was trying to copy a hundred gigs or more, (my entire home folder with a few steam games installed). Rsync and Rclone may both work but have separate issues.

@anoraktrend: Ping? See above.

Do you want us to disable your account then?

Thanks for the report.

It does not but at the very least you won't receive those emails anymore.

I guess you are requesting to update cava, right?

It looks like Fedora is using the beta version of Tweaks 42. Solus is using the last stable, which is 40.10. I wonder if this is something that changed in the beta version.

Moved screenshot to hosted services

The screenshots you attached. It looks like the files are restricted.

Sorry, what is not showing?

Unfortunately those screenshots are not showing.

Possibly, do you know if disabling one's account notifies/signals to others trying to @ someone in a conversation that this person is no longer around/not to expect a response?

AIUI, the way phabricator works makes it a _Bad Idea™_ to outright delete an account, as deleting an object in the store has all sorts of bad side effects.

@TClark77 I stopped using Solus a number of years ago due to a few of these bugs. I don't know if it is still prevalent in the modern version of the distribution. If you have access to an HDA-Intel card you might be able to test if you can open up Element or Slack and attempt a video call.

Sure, this is what i'm talking about
{F10975279}
Fresh after install, I toggle off maximize and minimize button, also toggle "left" for placement as as shown in screenshot. Changing the setting on Tweaks it doesn't do anything. If i do it via dconf-editor, this happens.
{F10975305}
Recently, after using gnome-session-shell-experimentall and login to wayland session, all of that problem just solved. I can change titlebar button via Tweaks.
{F10975317}
Though it seems, the setting doesn't persist between sessions (X11 and Wayland). If i change the setting on wayland then logout and login to X11, the setting doesn't get adhered and sometimes causes crashes.

Can you provide a screenshot of what's happening and with the options you selected?

Update. all above activity was with X11. I just noticed that I can choose Wayland desktop instead of X11 at login on the lower left.
When I'm using Wayland the HDMI display is 100% stable. It was flickering when I was on the login screen but after I chose Wayland and logged in, the issue was resolved. This is ok to close, but If you want to further triage X11 you can keep it open and let me know if you have any updates I can test. Thanks! ~S

Full 8nstall still flickers. {F10963376}

Hi Reilly -- I tested the live ISOs with a different display and cable at work and encountered the same problems on gnome and budgie, and it seemed less dramatically flickery on kde. All attached files are at first bootup.
One other thing I did was since my work screen is in portrait orientation I changed the display config in each to portrait for the extended display and the problem seemed to go away (I did this in gnome and kde and there was still some intermittent flickering on kde)

Tracked at https://github.com/getsolus/solus-installer/issues/13

Does KDE have the same behavior? Also does it go away if you install Solus and then update it?

Ah. I see. I have lightdm-settings installed, which creates the config at that path. This also isn't knew; as far as I know, this may never have worked.

One last thing creating the directory fixes it:

I should also add that /etc/lightdm doesn't exist.

Yes, I am getting:

I cannot reproduce this. Is there anything in journalctl -xe when you do change the toggle switch or re-enter the Users tab?

I don't know whether I've mentioned this before, but in a Wayland session, I can successfully maximize a VM within the host window's client area. This does not lock up the VM or the host, but it's still not full-screen. And some distros/DEs do not automatically resize to fit within that client area, but display scroll bars instead, making it very difficult to use both OSs without a lot of manual scrolling.. Solus MATE is an example of that.

Now that Solus 4.4 has been released, and I still cannot take a VM to full-screen while in a Wayland session, I thought I'd ask about it again here.

Vivaldi is a proprietary browser we just have permission to repackage and distribute it. We have not made any changes that would suddenly cause this to occur so if Vivaldi is not setting ozone-platform to auto that is something Vivaldi should address.

Passing to Harvey for evaluation

FALSE ALARM: I checked the account settings again, and discovered that I hadn't checked the { X } Use HTML property on that account's settings. The text box entries were all nearly identical, but not the checkbox.

This Thunderbird instance supports three email accounts. So there are three entries in the Account Settings, all of them using the same method to define a signiture. After I created this report, it occurred to me to check whether the other accounts are working.