As this is under active development, can it now be accepted for inclusion? Last diff by @eyecreate had to be abandoned because of lack of development, but that is no longer the case

This was already talked about in T4194, even @eyecreate provided working diffs. So there is some demand.

Reorder builddeps and move .rules file to correct location.

Reorder builddeps and turn off static.

Add patterns.

Solus team can't do much if there isn't driver for it. So the best thing you can do is to monitor support for it on any linux distribution, and if there are things that need to be changed to make it work, you could report them here.
For example it could happen that necessary drivers make their way into the kernel, but they need to be enabled in Solus's kernel config.

You can't use AUR on Solus because they are completely different systems, and many instructions are different. You can sometimes use them as a guide for creating a package for Solus, but that is not necessary here.
So unfortunately there it seems they won't package Chromium for Solus because Google needs api key, so you have 3 options:

This is proton i made to be used from withing Steam and tutorials and guides mention only that. I just wanted to add that it also can be used from within Lutris, but that's just a bonus.
And I just said this is not system wide to clarify this is not replacement for Wine, and that it is gaming-focused and Steam-only

So the desktop would need use V-Sync when no full screen app is running, so that the screen is refreshing at it maximum rate?

Also the current driver doesn't work with some devices using exFAT (like PS VIta), while the Samsung driver and Windows work just fine.

Could you please consider accepting it? It is under active development, stable and I've working package.yml for it.
Only reason against including it is how easy it is to install it using pip.

They found a few fixes for similar issues here, including forcing a language or running through Lutris https://forum.manjaro.org/t/rise-of-the-tomb-raider-does-not-launch/136930/18
Hope it helps

I don't have any other idea, but do you have 32bit driver installed? Depending on your driver version this is nvidia-glx-driver-32bit or nvidia-beta-driver-32bit

Is this the only Steam game that causes problems?
Has this game worked before for you?
Could you try launching whole Steam from the command line and launch the game from there?

You could uninstall the current drivers and try with nvidia beta current or nvidia developer current.

Changed the description to please IDoS

Description and cosmetic changes to package.yml

Switch pkgconfig of gtk-2-devel

Removed leftover comment

Fix the MAINTAINERS.md

I built using this package.yml and verified it works with Steam games, so this is ready to be accepted into the repos

1. This is distributed as a Debian package and not as a source code, which is not ideal and rarely accepted to the repos.
2. Does the license permit redistribution and repackaging? If not this would need to be added to the 3rd party section, and Core Team usually doesn't want to do that.

So this could be hard to accept into the repos, maybe you could give more explanation of what it does?

What I meant that by default we will have 2 different mouse hover behaviours - active screens will switch, but active windows will not. Still it is up to others to decide

Remember that there also is "Activate window on mouse hover" or something like that, which is disabled by default. So one thing would be changed by hovering the mouse, and one not. This might lead to some confusion.
But I personally agree with what you suggest.

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.

It has been 3 years since the initial release, it is actively developed and is a re-implementation of author's previous version from 10 years ago. Also the only feature missing is terminal apperance configuration.
And I haven't had any problems for last few months. But obviously the choice is up to you.

Thank you so much for your answer! What I was lacking was /etc/modules-load.d/kvmgt.conffile, which I didn't found in any documentation, maybe I missed it. Now it does work just fine.
Only peculiar thing is I still get i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x161e_rid_0x09.golden_hw_state failed with error -2 in dmesg.

To remove redundant dependencies you need to go through each one and look at reverse dependencies. Here is the process:

Are you saying that compiz-plugins-extra package still doesn't include all the plugins you need?

You should be more specific, what errors? One easy thing you could try to check if Legacy Boot is set to on or off. If you disable it you will force the system to boot in EFI mode (instead of BIOS), which should be the default for all modern hardware.

I'm on Budgie and I haven't encountered a single problem, and even noticed an improvement. Automatic screen rotation used to be wery smooth on Gnome, and on Budgie the screen went black for a second and then the entire interface spasmed out. Now it is really smooth

I think this package can stay as it is, but if next time I would need newer versions of some dependencies, then what steps should I take:

1. Create a package update requests for each dependency, one for all or can I straight up post the updated diffs?
2. If other packages depending on it (like Ardour and Audacity on suil) need a bump to be rebuilt, should I also post a diff for all them, or you will take care for that?

Rebase properly and up the version number

But this will create a new diff on phabricator, won't it?

@kyrios123 Do I need to make a new diff? Any tips would be helpful

Rebased and incremented the build number
I hope I did it correctly

• Update Cinelerra-GG to 2020.02.29

I'm working on it

Oh, phabricator didn't submit my comment from 5 days ago...
So what should I do? Can we proceed like it is, or should I update those 3 dependencies so Cinelerra is less static? Will I need to create a local repo for that?

Light sensor is now working correctly, thank you so much!

Fixed the email

It would be great if you did. I know my sensor is supported by the kernel, because it works on Ubuntu out of the box.
Also I'm on unstable so I will test it when you rebuild the kernel.

For my Toshiba Portege Z20t-b:

This update also brings support for more other sensors, like light sensor in my Toshiba Portege Z20t.
Could I post a diff as I have a device with both accelerometer and light sensor, so I could verify that this package works?
Oh, and they have moved from Github to Gitlab: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/

There is 5.5 kernel in unstable already, so it will probably come with friday sync. But updating might be tricky for you, as Solus only keeps 2 kernels, so if you update you will be stuck with 5.4 and 5.5.
It might fix your problems. Also have stutters of different king, the interface (task bar, avaiable networks, volume controll) hangs, I hope this will get fixes too.

In T8629#164500, @JoshStrobl wrote:

In T8629#164499, @Jacek wrote:

With the Software Centre change could you have all the updates checked by default? Now when somebody goes to updates and presses update, it will only install necessary updates. And if all were checked, all would be install. This could slightly raise the number of fully up to date systems and save a few clicks for most users.

It's going to be a list view, there isn't going to be anything to check.

With the Software Centre change could you have all the updates checked by default? Now when somebody goes to updates and presses update, it will only install necessary updates. And if all were checked, all would be install. This could slightly raise the number of fully up to date systems and save a few clicks for most users.

I don't know how you could do that, somebody from the core team would need to help you with that. Best way I can think of is to run that AppImage off of Solus 4.0 LiveUSB, or just installing Solus 4.0 and not updating it. Trying on any other distro with new kernel could also point in the right direction.
Again you could do a Memtest, stresstest and check if you are not running out of RAM before crashing.

So do you get problems with both Appimage and version from the repos?
What CPU and GPU are you running? New kernel/systemd might cause problems with your hardware.
Things you can try doing:

1. Do sudo eopkg check and see if any packages are broken (udisks will report as broken, but what about everything else?)
2. Check system monitor or htop if you have any SWAP - maybe the new installation didn't give you any, and this would for sure cause problems with photo editing or 3D modelling
3. Try older Krita by using older Appimage - this might be tedious, as the stalls are random
4. Just to be sure, are you sure you are not overclocked? Maybe it crashes while using Krita and Blender because they are the only programs pushing your system to the limit, and it isn't stable. Memtest or any stress test might be a good idea.

"We don't do ETAs" - Joshua Strobl, 2019

After some playing it doesn't seem too hard to package. But other distros do a lot of configuration, add packages and modules. So all people who used ROOT should list what modules or configuration they needed over the base package. For example I need integration with Jupyter Notebook, and this will probably need additional configuration.
Also ROOT uses Python 2.7, and knowing CERN they won't upgrade it soon. I think solus wanted to deprecate Python 2, so it also needs to be researched.

So how can you disable the need of inputing password after reboot? I used to do that , but then I still had to input password when launching an app that uses Gnome Keyring to unlock it, Vivaldi for example

First, I strongly suggest the next release to be called Solus 4.0.9999.
On Dell XPS L421x (2012) with i5-3517U, GT630 and 2 hard drives:

1. Installation alongside Windows 10 went fine and super fast (3minutes excluding partitioning),
2. Udisks was the only broken package (I know it isn't actually broken, but eopkg's derp)

but

3. Swap was not created. The space for Solus was tiny (15GB), but was this really on purpose? I wouldn't use a system without swap
4. The installer only saw 1 ESP, which was on the other drive to which it automagically suggested to install the system (suggested automatic install on Windows drive, but bootloader in Solus 4.0's ESP). I know you know about it but is no less problematic, especially in laptops where you can't just take the drive out.
5. In CLR-Boot-Manager the system name is still Solus 4.0 Fortitude, don't forget to change it for the final ISO.

Thanks Josh, deleting that file caused eopkg to throw errors (something with pam), and after reboot I couldn't log in.
After booting with LiveISO i found limits.conf.newconfig with the patched contents. After renaming it everything works now, and the limits are increased.
So thank you very much, I hope it'll go smoothly for others.
Solus 4.0.9999 (or whatever you call it) should get good gaming revievs!

I am, with newest systemd and pam. But I I had jacek hard nofile 524288 at the end of that file, and I only deleted that line after the update. Is that why the file didn't get patched?