ReillyBrogan Last time I used Wayland for screen capture has been a few months. Yes I used the Pipewire API and it stutters a lot so I ditched it. But I'm glad you explain it to me, so I can be sure my problems were never a Wayland problem, but components around Wayland. So I can say the infrastructure around Wayland is unusable for me yet? I don't really know why I can't click during a game.
Sync Updates for Week 30, 2023
ReillyBrogan Which file do you want? .profile?
Fanmion Run the following command sudo journalctl -b0 > issues.log
. Remind me, what issue did you have? There's a 156 posts in this thread now and I may have gotten you confused with someone else I asked.
It would be incredibly helpful if someone experiencing the issue with swap partitions not mounting or the boot getting stuck at the rescue console could hop onto the Solus Matrix tomorrow between 4PM and 11PM UTC tomorrow for some debugging. I'm hoping to have this figured out before I do kernel builds tomorrow so the fix rolls out in the next sync (oh btw, the next sync is including kernel 6.4).
ReillyBrogan Is it save posting the log file here? Cause of sensible data or something else
I'm not Reilly, but if you don't post the data he asked for, he likely can't help you.
I'm going to suggest that you are the best judge of whether anything you see in the log is "safe" enough for being posted in public. If in doubt, you can always view it in a text editor before posting it here.
Best of luck.
I will post it into our matrix server, because I can't upload files =(
Fanmion I will post it into our matrix server, because I can't upload files =(
You can open the file by navigating to your home folder with your file manager, open the file with a graphical text editor application like KWrite/Kate/Gedit etc., mark all the text, copy it to the system clipboard and then paste it here enclosed in triple backticks like this:
```
(paste the stuff you copied here)
```
Do you think you could do that?
dassuan This should be fixed now in Unstable; at the very least, Unicode input should work again with Ctrl+Shift+U.
Sorry nothing changed. installed from unstable * tpm2-tss 3.2.0-2-1-x86_64 is , rebooted twice, but no dice. Unicode input does not work.
Update: I believe I have fixed the swap issue and the boot issue in unstable. This fix will roll out for the next sync. However, if you want this working now you can edit /etc/systemd/system.conf
and change:
#DefaultTimeoutStartSec=5s
To:
DefaultTimeoutStartSec=30s
And:
#DefaultDeviceTimeoutSec=5s
To:
DefaultDeviceTimeoutSec=30s
Note the removal of the #
symbol. This should fix it immediately and things should work again on the next boot.
- Edited
I tried to revert the last update but could not do so because
at-spi2-atk 2.38.0-25-1-x86_64
libatk 2.38.0-27-1-x86_64
packages were removed. As I understand it, those packages got something to do with accessibility. So I wonder if this touches the unicode input problem. Just an unqualified idea.
BTW: When I boot from the ISO everthing works fine.
for
cat /etc/fstab
:
https://pastebin.mozilla.org/aidGDaoX#L1for
sudo mount
:
https://pastebin.mozilla.org/p4PVLBaf#L1for
sudo blkid
:
https://pastebin.mozilla.org/d2wpgR0k#L1
alexxtasi Thanks, but I'm pretty sure I've already figured out the issue and it actually had nothing to do with the UUIDs and everything to do with the default timeouts having been set too low. This issue will be fixed in the sync today, or you can follow the instructions here
dassuan So I wonder if this touches the unicode input problem
No, the unicode input issue has already been figured out and is an issue in ibus. A fixed version of ibus will be rolling out in the sync shortly.
- Edited
If you had the swap or boot issue please post on the NEW sync thread if your issue is resolved. I was never able to reproduce the issue locally but I am pretty sure I fixed it based off what I think is happening in the logs.
Locking this one since this is no longer the current sync period.