Note that changing the default branch to master is important, you'll have to fix your commit after you submit your diff if you forget that step.

In T10451#199625, @stalebrim wrote:

Doesn't it need a repo construction by someone with adequate permissions, though? I might be misremembering.

In T10451#199602, @algent wrote:

I think this is OK for inclusion. Normally if an existing package requires a new dependency there is no need to request it for inclusion.

I think this is OK for inclusion. Normally if an existing package requires a new dependency there is no need to request it for inclusion.

Thanks

Actually this package is deprecated in Solus Repos because at the time was a Qt4 package and python.
But now looks like it is switched to Python3 and Qt5.

I have the package for this working now.

Please use this template to do a proper package request.

Getting xone fixed for older gamepads is going to be a bit more of a headache than I initially thought. xpad-noone doesn't have any tags or releases, and the maintainer for it (and xone) has apparently disappeared. I'm going to open a new task for this so that we can keep our discussion organized.

In T8641#199412, @ReillyBrogan wrote:

I wonder if it might be better to just bundle the xpad-noone kernel module in the xone package

That one looks a bit problematic, what happens if a user installs xone and then removes it for whatever reason? They'll still have xpad-noone installed which means that xbox one+ controllers won't work. I wonder if it might be better to just bundle the xpad-noone kernel module in the xone package so that removing xone correctly removes the xpad-noone ko as well.

@ReillyBrogan the xpadneo folks are recommending we package xpad-noone as well, as it fixes some xone issues when people are using both older Xbox controllers and new Xbox One / Series S / Series X controllers. I'll put up a package request for that shortly, and once packaged I'll add it as a runtime dependency for xone.

I just talked to the folks on the xpadneo discord. We should be able to add this with no conflicts. I'll do some testing this afternoon.

I'll take a look at it. The xone and xpadneo guys actually work pretty closely together, but I think these two drivers may conflict in some areas. It would definitely be nice to have working rumble via wired & Bluetooth though.

@infinitymdm FYI someone re-requested this on the Solus reddit, any interest in taking on this package as well?

https://dev.getsol.us/R5651:18174f85993388a9f441ecb0b31c4257c6c833dd

Also, I am willing to maintain this, I'll probably start working on packaging it very soon.

For now I've opted to revert the configuration change that made pipewire try and fail to load x11-bell.

Ah, that makes much more sense then. That's what I get for checking in on tasks at 3 AM on my phone :D

Oh wait we do package libcanberra already

In T10437#199172, @Staudey wrote:

The x11-bell module was never part of our pipewire. I wonder why it suddenly started complaining. I don't really want to add it "just because", especially since it seems it uses libcamera (for some reason) which we also don't have active. Gonna take a look tomorrow.

I see, didn't know it would complicate other things. I suppose instead of a package request I should have just opened a bug report, but I opened it because getting it on the Arch repo was simple so I thought it'd be a quick solution. I'd prefer to see it just stop complaining than to get the package anyway

The x11-bell module was never part of our pipewire. I wonder why it suddenly started complaining. I don't really want to add it "just because", especially since it seems it uses libcamera (for some reason) which we also don't have active. Gonna take a look tomorrow.

Looks like I'm getting these too, since Nov 14. This is probably the relevant change: https://dev.getsol.us/R4226:8f1e28fe4361bd3f6bb05f8b95fdd96f031059d6

Thanks, that's great.

Currently blocked by T10368

Just to update status here: I have a working package for this, and I've also submitted a tentative patch to subliminal to swap it over to this package.

Just spent a few minutes cleaning up the build recipe a bit. I'll be watching out for those kernel commits :)

Again, my stance still stands. I rather not have duplicated gnome text editors, until gedit is properly deprecated, I don't see a need to have gnome-text-editor included in solus currently. Especially when the icons and naming schemes are relatively close to each other.

Don't create the diff for this until after I update the kernels early next week.

The license in github is BSD-2-Clause. I think we are fine with it.

On reddit I was asked to add a comment saying that I would be willing to support this package.

Working link to the homepage: https://apps.gnome.org/app/org.gnome.TextEditor/

Depends on T10431

After some discussion on IRC, it looks like it will be a better bet to change all the revdeps of pysrt over to srt instead. Luckily, by "all the revdeps" I'm only referring to one package: subliminal. I've started working on a patch for that, and it doesn't seem too extensive. I'm not sure who the audience is to test it though - it's certainly not the sort of software that I have an immediate need for.

It seems that manim has a dependency on [[ https://pypi.org/project/srt/ | srt ]], which by default provides a binary named srt. This conflicts with our current python-pysrt package, which provides a binary with the same filename. Both libraries accomplish similar functions - dealing with .srt files - but have distinct APIs.

I'd be glad to take another look at this. I find myself in a spot where I'm going to need to explain some complex math/electronics stuff to people who have never worked with electronics, and this is basically the ideal software for making the kind of animations I want.

In T10421#198833, @infinitymdm wrote:

I currently have a functional package based on citra-nightly that is ready to upload. Just waiting on this task to be accepted for inclusion, and I'll be glad to submit a diff.

Note that this requires icestorm as a prerequisite. See T10425

I currently have a functional package based on citra-nightly that is ready to upload. Just waiting on this task to be accepted for inclusion, and I'll be glad to submit a diff.

Thanks! Yes I followed the steps in Building a Package, I'll take a look at the Submitting section and get to work on that. Thanks again!

@Icosahunter: Always happy to see a new contributor! ?

I'm wiling to maintain this. With some help from the forum I just got a package build working, I've also got the MAINTAINER.md. What next steps do I need to take? Thanks!

Taking a look at what's needed to build a package for this now. It looks like we'll want citra-nightly, as that repository has regular releases similar to yuzu-mainline. I'll post when I have a working package.

I'd be glad to take a crack at packaging Citra.

thank you. i sent a donation to the opencollective. (high fives entire team) (high fives Staudley & Ebon twice)

For now I have decided not to integrate it into the main package, but simply to provide it as a separate install. Might reconsider in the future. I was just happy to finally get it to work, after realizing that I had the big dumb (and also that it needed nvidia-drm.modeset=1 to work, but that was the minor issue ?)

Right now gedit is still being maintained, until it is no longer maintained, I think we'll be keeping with gedit until it is no longer maintained. No need to have two similar looking and in function apps at the same time.

most people use the anaconda install script https://www.anaconda.com/products/distribution
I don't think this is worth investing time

I would also like to clarify that I have prepared the assembly instructions, and as soon as I get permission, I will send them.

One thing I note about portmaster

Bump

Bump