Any sort of compilation fully expects that you install the system.devel component per our Help Center documentation.

I think we've gotten a lot better about this process stuff in the past 6 months. Any software-specific issues should be separately reported.

Marking as Wishlist because that is what this is, not because I think it is low priority.

It is not really a problem to have to wait for a patch to be committed. I think IRC is a mandatory place for packagers. When for some reasons you want a patch to be committed immediately you must explain why and check if there are not conflicts with others on-going activities like a stack update or a kernel rollback. The way of asking things on IRC does matters. If you ask something when everyone in the core team is away/busy you request will most likely be lost in the flow. Every week before the sync ikey asks if there are still things that should get in. This is, imo, a good time for requesting such things. If the impact is big, you can cancel announce it in advance. This is what I usually do and it works fine.

I can't really say much because my experience in such topic is extremely limited, but I want to make my 2 cents worth something: I agree that often packages await for inclusion for a long time, even if the diff isn't that "deep" (like for a minor release). Revision process should be speeded up.

@kyrios, it's a year later and I still don't what we are supposed to do to close this. So I'm going to close it. If you have specific grievances, feel free to reach out to us on IRC and we can find a way forward. Thanks.

If we need more servers, we'll get more servers. If you are looking for ways to donate compute time for the common good I suggest:

@BamTime Solus already builds packages inside a chroot called solbuild.

I think that would have to happen in a container because we might not want all dependencies to be installed on out live systems, I'd rather want it to build inside of a container to keep my system clean.

1. Unless the maintainers give a preference to a specific toolkit, prefer the more functional or at least better looking framework for each package on a case by case basis.

Alright cheers lad - sorry about that though :(

Okay, let's close it then.
I got used the way it works and nobody else reacted on this showing there is no interest.

Doesn't actually seem to be a way to do that