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.

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?

I did a full upgrade, reinstalling pam or doing eopkg check does nothing. Only clue I have is to how the end of /etc/security/limits.conf looks like.:

@Girtablulu That's exactly what I did, the output is

@JoshStrobl After deleting all lines I added to those files and updating Systemd the limit is still 10000. I have no idea why

So this is first time since I started packaging that it correctly does system builds. By default it uses almost all system libraries, apart from A52, FFMPEG and its reverse dependencies.
This is the first time that I can actually force it to use system libraries even for those, but I don't know if this would be the right way. They are key components and there probably is a reason the devs forced them to remain static even for system builds. We are often in front or behind with FFMPEG compared to what they are shipping (currently 4.2, us 4.2.1), and they have to blacklist specific effects that aren't compatible with each new version of FFMPEG.
Should I try to force more system libraries, which will mean more testing and possible problems when FFMPEG gets updated, or should I stick with what we currently have?

Yeah, I know. Static libvpx also causes a few other libs to build.
I know this is not optimal solution and I should wait for patch, but the current version in the repo is also affected (can't render VP8 and VP9, nor use them for proxies). I'm sorry I missed that during my testing.

I have tested it for a few weeks, this is ready to be accepted!

You didn't include a feature introduced in 1.2, which is fish autocompletion. Here is mine package.yml{F5130896}

Sorry if I wasn't clear enough. I simply need this to update cinelerra-gg. At least I think this is what I need

So FFMPEG got updated, but what about this?

@Girtablulu

This will need a lot of rebuilds, so I'd guess it would be best updated with FFMPEG to 4.2

I know, that's why I hoped it would get updated with FFMPEG, as I need both to update Cinelerra. Unless I want to use bundled dependencies and build it with static.

Has there been any progress with that? I need it to update Cinelerra-GG.

If so do you want to include Python one over Rust? After using it for 2 weeks I simply think it lacks autocomplete. But I can post the diff of Python one right away.

Could you please consider accepting this? In the original request many people showed interest in a TLDR client, not specifically on python one. And most people agreed that Rust one is superior.
You have agreed to include the other one and this has simplier build process, has no runtime dependencies and has any build documentation.
As Solus needs only one TLDR client could you accept inclusion of one that most deemed superior?

I have now packaged both Python and Rust client, now the choice is up to you. Terminal output of both is the same, so next to no difference to the end user.
Python:
+ used by Arch and Fedora
+ allows caching

• no build instructions, had to make use of Arch and Fedora build scripts

Rust:
+ autocomplete for Bash (and Fish in next release)
+ static package, no need for additional dependencies

What I meant about more actively maintained is number of commits and features they bring. I don't know why they haven't tagged a new release yet, I need to bother them about it.
Yeah, speed is probably not a factor.
I forgot to mention the reason I prefer Rust client over Python one - autocompletion, which the latter lacks.

Both my 7 years old XPS with i5-3317U and my netbook with Intel Atom Kaby Lake CPU have that issue, so this would seem that this problem only affects devices with i915 driver and not newer ones supported by "Iris" Gallium driver. But I might be totally wrong.

I'm also new to Rust, but I think it is a small static binary, so no need to install Rust. After all you have Firefox on your system that is partially written in Rust, but don't need Rust.
I packaged this client because according to tests it is the fastest out of all.

I created a diff of Rust client Tealdeer, works just fine. Only lacking feature is fish autocomplete which is git but not yet in any release.
So we are only waiting for this task to get accepted, unless somebody wants to package different TLDR client.

Removed indentation on line 3 in MAINTAINERS.md

Added MAINTAINERS.md and rebuilt so it is release 1 in pspec_x86_64.xml.
Thanks Josh!

Updated package, because I've waited for so long for review, another (monthly) version has been released. Please, somebody just review it!

Removed 3 additional dependencies that other distros need to build it but solbuild doesn't

Fixed a mistake I made while deleting reverse dependencies, sorry, I swear this is the last one

Updated package to newest version, removed redundand dependencies, adjusted styling to Josh's standards

7th iteration of Initial commit of Cinelerra-GG

6th iteration of Initial commit of Cinelerra-GG

5th revision of initial commit of Cinelerra-GG

Removed redundand dependencies

Initial commit of Cinelerra-GG

Corrected worst possible mistake

I have packaged it and created a diff: https://dev.getsol.us/D6439

The only problem I noticed is a weird problem with waking up from hibernation. The whole desktop is unresponsive, but in a weird way. Notifications work, I can use shortcuts to e.g. disable touchpad and change brightness and get an according popup, but I can neither move the mouse nor use keyboard to navigate, so no ALT + TAB or Budgie Menu via Windows/Super key. And CTRL + ALT + F2 and then CTRL + ALT + F7 doesn't help, more so, I don't get login prompt when CTRL + ALT + F2.
So I don't know if that's important as my laptop has had pretty broken suspend anyways

That blocker is no longer valid! So previously they kept older versions, but changed url form /pkgs/src to /old_pkgs/src.
After exchanging a few emails they agreed to keep older version on the same url, so it won't need an update of package.yml.
So now as you can see, they are keeping both current and previous package in the same directory
https://www.cinelerra-gg.org/download/pkgs/src/cin_5.1.20190331-src.tgz
https://www.cinelerra-gg.org/download/pkgs/src/cin_5.1.20190430-src.tgz
They release new version on first of every month and keep the previous version for one more month. I hope it will be enough to include it in the repos.
So is anybody interested in packaging it, if not I can do it after 2 weeks (20th May).

@DataDrake I really care about this package, and I could at least ask the author to change something. Would you agree to add it to the repos if he just kept old tarballs, or would he need to change more?

In T7902#149331, @JoshStrobl wrote:

Yea, just re-run usysconf: sudo usysconf run -f

Issue with Papirus icon set.
A lot of Gnome apps (terminal, system monitor, disk usage, screenshot, etc,) use default Icons instead of Papirus.

It does work now perfectly, no errors. Thanks!