This is an issue with the upstream project that must be appropriately relayed to them and resolved
Thu, Jul 30
Tue, Jul 28
Fri, Jul 24
1st workaround - switching to strongswan works properly.
Thu, Jul 23
@g66925 As your link mentioned, you can try switching to strongswan. You can do that with the following commands:
Wed, Jul 22
Thx! I did update:
@g66925 Just so you know, the patches have been landed. You should be able to find them in the unstable repo now.
Tue, Jul 21
@g66925 They have not been landed. It would be better if you test them and verify that they work as expected before landing these patches. If you feel comfortable, I can build these packages and send the resulting eopkg file for you to test. It is also understandable if you prefer to build it yourself. In the latter case, you can download the aforementioned patches and build them locally. This is a very good introduction to setting up solbuild: https://www.youtube.com/watch?v=rlPnHjUBpJ8
I need a bit of support. I did not found relevant packages in unstable repo, so I presume that I should build them by myself?
Wed, Jul 15
There is. Explained right in the first post. However, I can just build 13.0 myself like I've done so far. I just wished this could've been worked around which would benefit other people who use PulseEffects.
Please, we don't need this re-opened. There's nothing we can do about this and it's clearly an upstream issue that is already resolved upstream, at the cost of other more serious issues.
Tue, Jul 14
I do not mind to test update, as I can connect to L2TP/IPsec endpoint.
I guess I can try updating this but my employer has since changed to use openVPN so I won't be able to test things as I did before.
Yea this is an upstream issue that they resolved in git but don't have any new releases with this change in:
Mon, Jul 13
Thank you, this is most helpful. I tested both workarounds - kernel 5.6.18-156.current is working stable.
Caps Lock LED blinking
Jun 24 2020
sounds a lot like this https://bugs.kde.org/show_bug.cgi?id=354802 some have posted a solution to fix it for them, which you could try but I see reports about this issue from time to time. Sometimes it is fixed and gets breaked on the next update
Jun 18 2020
Maybe you are looking in the wrong place? I sometimes loose middle click when pressing both buttons. So I enable it with xinput at every boot.
So you could try typing xinput, then finding name of your touchpad and doing something like xinput list-props "AlpsPS/2 ALPS DualPoint TouchPad".
Then you set a property like xinput set-prop "AlpsPS/2 ALPS DualPoint TouchPad" "libinput Middle Emulation Enabled" 1
Your problem still might be Plasma specific, but it is worth a try.
mmh k, doesn't help that even Nate hasn't an idea what could cause this. could you try running the next update via terminal and run after completion sudo usysconf run -f to see if this maybe fixes it? I cannot trigger it with my Notebook
Jun 17 2020
Yes by every update, Solus kde is fully updated right now and it happens since first time I installed it, from the very begging with the first update until the last one. Is the kde edition without any additions for example even if its an update of a single package the problem happens and remains until reboot. The netbook is a hp stream 11.
Submitted a patch for easyssh and also reported the issue upstream (https://github.com/muriloventuroso/easyssh/issues/97)
@akrenz you build it by replacing public with protected
Just throw this in https://github.com/muriloventuroso/easyssh/issues/95
File this with the upstream dev....
File this with the upstream dev.,
Jun 16 2020
but the question is, does it happen
- by every update?
- Framework ?
- application ?
May 28 2020
Did you really just upload a 280MB archive? Please Don't.
May 20 2020
Thanks for the updates!
May 19 2020
Sorry. I was 99% sure v2 was required by 245 when I wrote that. Had completely forgotten about EFI changes.
No, this has nothing to do with systemd 245. The reason we reverted from 245 was due to EFI changes for default boot loaders (see here, which would cause breakage during the booting process since it'd be selecting old, outdated kernels with potentially missing modules), not anything related to cgroup heirarchy. That already exists and is something we set to legacy already via the kernel's cmdline. This has to do with the fact that multiple pieces of software do not support cgroups v2, as highlighted by T8609. None of the mentioned issues referenced in T8609 have been resolved and as such, we cannot drop our use of legacy cgroups v2 without imposing unnecessary and undesired breakage and requirements of configuration for users.
There is no workaround. Newer versions of Snap require the newer versions of systemd. Until we are able to update systemd to 245, it's a moot point.
Sorry to dig up closed tickets, but thought it was worth mentioning as I have also come up against this bug.
As per the discussion on github, it appears that this issue isn't caused by bad AppArmor profiles within the snaps, but rather a change in snapd itself, as is described in the following PR:
@JoshStrobl Thanks for your work on this fix! I can confirm that the latest patch in the unstable repository fixed the issue for me. Also I did not have budgie-desktop-branding-livecd installed on my system.
May 18 2020
Okay, for whatever reason I have budgie-desktop-branding-livecd still installed on my laptop, just not on my desktop. I'm guessing my issue was just caused by testing a bunch of stuff during prior GNOME stack upgrades and not doing proper cleanup on that system. That had a lock-enabled set to false which rightfully preventing it from locking. After uninstalling it, the issue is resolved. I'd double check that you also don't have this installed (you shouldn't but you never know). Marking this as resolved since I can now properly lock while suspending and there are no crashes.
Okay so I did a sync with git, added a VT1 patch to GDM, and disabled all extensions. Still doesn't actually lock on suspend. I'm not getting anything related to segfaults anymore but it does make me question whether or not they're even calling to lock before suspending in the first place.
Seems it may be an issue upstream. Even though we don't use gTile at all, I'm able to reproduce it however not able to reproduce any "fix" by disabling specific extensions, or all extensions. I'm going to see about merging https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/d3934bd6854aa0b655437d443e59396dfb0c0945, which isn't in any of the latest releases, to see if that resolves the issue.
May 17 2020
This seems to be an issue with Electron 8: https://dev.getsol.us/D8774#141938
May 14 2020
Not sure if "acpi=off" is the same as "acpi=noirq" but it also allows the system to boot, discovered that via MX Linux.
Just tested it and it is working fine now.
Okay after further testing, the PR referenced that the dev claims fixes it doesn't in fact do so. Additional details should be provided once telepathy-mission-control and new polari are synced into stable (if the individual that tested this against Solus 4.1 P.S. it isn't Solus 4 and reported the issue wants to follow up). Going to add the patch in regardless, but marking this as an upstream issue.
This was an upstream bug with telepathy-mission-control that breaks it:
May 7 2020
Well this is a surprise, while adding "noapic" or "nomodeset" to the Kernel line in Grub does not work and "apic=debug" does nothing, it turns out using "acpi=noirq" does allow the system to boot the current Solus 4.1 iso.
May 5 2020
This should be filed with the GNOME developers: https://gitlab.gnome.org/GNOME/gnome-control-center