In D10309#169239, @JoshStrobl wrote:

2.5.9 is considered a beta release by upstream, is there a specific reason we should be updating to this? https://github.com/mupen64plus/mupen64plus-core/releases/tag/2.5.9

yeah so for one thing, those are the old repositories, it's under a new github organization currently, but as for explaining why it's still on github, I'll leave that to the administrating team to give their reasons.

Forgot to mention this goes with D8566 but that should be fairly obvious.

I'm not happy with this, chances are I'll revisit, but with a more generic update instead of a full on change with splash.

@JoshStrobl Gotcha, I'm barely awake when I did this, just pushed a new build to the build server with the fixes.

In this case. This is a windows only game, in which it makes use of the proton runtime. I'd check which proton version you're using within steam. And if none of those options work, make a report over at https://github.com/ValveSoftware/Proton/issues

Helped if I actually searched the repo

• Added the startup script
• Forgot to include the package.yml changes
• Add default config, it's not quite working on nvidia binary drivers just yet though
• forgot the abi report and pspec

Added test plan

• dracut can't find plymouth-initrd because it's looking for it in /usr/lib/ and not /usr/lib/plymouth.

as per Josh and Bryan, reclaiming this and will be extending things as well as some new test cases

In D4689#75220, @JoshStrobl wrote:

None really needed

Factually incorrect. A test plan is always needed. You would need to enable the services, validate it across LightDM, KDM, GDM, etc.
There's also no summary.

I would be willing to test among the different environments. In fact I've even been testing out a simple solus theme for Plymouth to use as a potential default when users install the package. But there's a lot more to test I'll admit than I initially put in. For now package is updated and it does work, but the flicker free experience I'm still trying to fine tune.

So I'm going to say this, there are some use cases for keeping it. I'm not saying using it by default but there are some use cases for those that do want it.
My laptop for instance. Piece of garbage that it is, while uses UEFI is also a very slow boot process. I've been toying with using it there. And I'm sure others wouldn't mind toying with it too if they so choose. Please keep this.

• Updated plymouth package.yml with the proper service modules

• The actual needed service files for seemless lightdm for uefi systems
• Service files required added, will be adding the install routines soon.

So this does work, however tray icon under budgie panel does not show for some reason, but in other environments like plasma, mate and gnome shell it does without a doubt. Gonna try and investigate it, but there is an in program switch to not use tray icon that users can toggle. But ideally I would like to try and figure this out.
So 3/4 desktop environments it works with the tray icon enabled and shows a visible icon.

Look no further D2278 it's in the works. And it does work, I'll fix the minor issues when I get home

In T6828#128217, @JoshStrobl wrote:

Closing as resolved. I'd like to see more consideration be put in from the VBA-M devs in ensuring existing configurations more gracefully upgrade / are supported for newer releases. Having our users experience these issues is not ideal.

Well it's resolved on my end as far as I can tell, if @nekoseam can confirm that would be great.

This was updated by @DataDrake as of https://dev.solus-project.com/R3137:409d711a9841f96e547830edd996597e90006023
Not sure if it was thrown on the build server yet

• edited package.yml licenses and install as per Josh and added desktop launcher and icon

testing will be done once unstable is more stable

• edited package.yml licenses and install as per Josh and added desktop launcher and icon

• edited package.yml licenses and install as per Josh

I'll update this weekend

Keep asking and you'll always get the answer. "When it's done."

@hersh or you could be patient. I was discussing this with Josh and there will be something soon.

It was done given ikey had mentioned that he may investigate the use of light-locker as a replacement for gnome-screensaver

Just because it's in git doesn't mean it's in the binary repository. My primary purpose is to try and get the backlog of accepted packages completed for repo acceptance.

Considering technically lightscreen was already accepted and in the git repositories, just needed a fix to build properly.

add systemd enablement

Patch submitted to D2373

updated rundeps for m64py

T4012 - Add rundep to package and make sure testing works from being able to run a rom and make sure settings are configurable from a user standpoint.

and Josh is saying to submit package.yml you need to submit it the proper way, hosting it else where isn't the proper way.
Please take the time to read https://solus-project.com/articles/packaging/submitting-a-package/en and submit it that way.

In T5010#105357, @bwat47 wrote:

if the visual refresh of MATE will use adapta (like the budgie version) I noticed the brisk menu looks kind of wonky with adapta: https://github.com/solus-project/brisk-menu/issues/83

Thanks for updating us on this.

We've sinec then had several and also a major update to mate, is this still largely an issue or is it resolved?

We've since then have had several mate updates, including a major updated. Can you confirm this is still an issue?

Due to not hearing a response from the original post author, I'm closing this.

It's basically what @feskyde said, The reason why we don't package up the assets as that they don't version it. For now it's done using the online updater for assets in retroarch. I won't mark resolved just yet or anything else.

VLC has since been updated to 3.0, mind checking to see if this is still an issue, please and thank you.

I'm fairly certain this most likely would be a no, due to the fact you can switch between os's from within the uefi menu fairly easily. But I'll leave the final say to ikey.

So, I'll claim this task, but due to the nature of the beast and since it is only available as a Deb/rpm. A few others and myself think this would be a prime candidate as a snap. So I'll work on snap package in which can be installed and used via snapd

fixed in https://dev.solus-project.com/D2278 just waiting for review

At the moment especially if you have an nvidia card, there needs to be cuda support in place. For the time being that's currently a blocker till cuda support is landed. Or I would think. @ikey would probably be best to answer that I think or someone else on the team.

I totally didn't forget the abi files, nosiree

I guess this issue can be closed. Kernel 4.12 was landed in unstable.

I see no value add to this, lutris essentially does the same thing and more and is already in the repository

@vdemir the way you packaged won't be acceptable for inclusion. Please follow the official way for packaging as set by our help center
https://solus-project.com/articles/packaging/guide/en/

@ikey Just one more thing to add in maybe. Cuda for the nvidia binary driver, iirc it was missing some bits still.

• disable static libs from being made
• Package rel and bumping

@ikey
This patch should work.

Thanks, I'll take a look when I get home.

The upgrade was put in place.

Mate edition so far, I've setup using arc red theme and the default cursor for mate. But that's just my setup. As for wallpaper. That's I dunno. So many good options.

I'm definitely interested in being a maintainer for more than the one package, And to be honest this setup would definitely streamline a lot of things once we get it implemented.

since the source code is in a tarball format, it should be built properly and not extracted from a debian package. Also for future reference, do not assign Josh to the report, it isn't good practice, he has enough on his plate as is to have another thing shoved on.

Versioned tarballs are inside the zip file.

No those a pre-compiled binaries inside those zip files, debs and rpm's and standalone zip files. That isn't a proper versioned tarball. It isn't even a source tarball.

So I'm gonna weigh in. Ikey of course has the final say.
But no versioned tarballs of any sort of than when clicking the linux link it just downloads a zip file with no versioning what so ever. If anything the patches they use should be upstreamed into openvpn where the rest of the world can benefit and on top of that you, technically one can import the openvpn configs into openvpn itself or the network-manager openvpn plugin.
I honestly don't see much value in a openvpn wrapper like this.

Updated patch.