Which was the exact issue with ffmpeg?

Until version 0.4.4 release we have frozen git-repositories in master and 0.4. Afterwards release for 0.4.4 the following packages will be removed with work on 0.4.5 starting:

libgtop
libwnck
alltray
intel-gpu-tools
peg
xstarfish
gpick
gcolor2
gcolor3
trayer

Why is 0.4.5 going to have starfish removed? Do you need to fix something? Just curious.

About the next release 0.4.4: We had to move the release-date out of much work. It can be also that we even have to move it again as now there are also personal points with the chance to make it more complicated. No, not financial but as said personal ones. We will keep this updated as soon as possible as we need the whole team for the tasks: Synchronizing, creating and testing the ISO.

Why bitlbee and od2txt? They are useful on small machines.

We will also completely remove windowmaker, all additional packages around. And blackbox additional packages. Again to underline: We can't and won't provide more packages any longer, as we also don't receive more support for the moment. The added and now removed packages are not completely gone: Their PKGBUILDs are saved for everyone to see, rebuild and change at any time. Please refer also here: https://wiki.hyperbola.info/doku.php?id … philosophy

We cannot provide more packages, maintain, update and fix them the whole time while we need to focus. If there is need for those packages: Please provide repositories on your own, share your PKGBUILDs and modify what you like and share it with the community. We have clearly demonstrated what is possible, but we also clear communicated that we need to reduce and we are doing that. We inform for sure before and do that always as of transparency. But we have no time to discuss for every single package and the reasonings behind why it is removed. When you want to support: Please do so and we can preserve and maintain more. Otherwise we will follow our roadmap given and this means for sure that we want to port as much as possible, but not on the price of months for more discussions as we had for our release 0.4. So as democratic point it is only fair that interested community-members take over.

I hope that is understandable. Also that it is exhausting to debate endless about really every single package while it is mostly simple:

Non-free data included? Non-free services?
Package is not possible to include plain direct, only with more work striping the problematic data out and patching the code.

Problematic languages and frameworks?
Package is not possible to include.

Package is not clearly licensed or only giving some hints?
Package is only possible to be included with more work or even contact with authors, more time.

Software is developing in a different direction (unknown at every point)?
We end again in removal later on.

So that would look like Hyperbola is going really unstable from the outside and that's the point why we concluded to go in releases instead of having steady additions or / and removals in between. But it is also the call for the community itself: Support means not alone financial, but can be done aside different. And as underlined: Do it yourself is part of Hyperbola's perspective.

We won't discuss the removals. They partly even happened now in the git-repositories already. And when you read you can see the reasoning: We have no time to discuss every single package now in that listing. Imagine this please: Every added package needs time for maintenance, time for fixing and updating. The more we remove and hand out to the community - this is the point we are doing with 0.4.5 - the more we have time for: Documentation, development and more. I think it is very clear described as problem: We will keep a subset of packages. This maybe one of the biggest part of removals now and for the future to come. But we need to do that. We cannot keep packages and are confronted with demands to update and / or add. This don't and won't happen any longer!

For example: dwm is mostly building local for many users past and now. So why should we keep one single version? Just for convinience? That's not Hyperbola's point. And conky-manager? conky was even on the listing before I rebuild and rework the package. And conky-manager was only a nice meant package for too long while we even had to put conky now on hold. So this is the point where we we get an even better system. 0.4.4 is another good milestone, but 0.4.5 will even more focus. All packages are saved and possible for local building, it is not our mission-statement to offer a common GNU/Linux system-distribution.

We would keep the packages, when we receive more support. That's the most important point: More support (not only financial) means more hands to keep up good work. No more support? No more packages and more time for us to keep up good work with the packages we want to keep. No one is loosing anything here, but winning just more. And ranger and clifm? Well, build them and provide updates with your builds for the community as Hyperbola is a good meant work with the community. As said: We will port what is there and try best for. But better remove the marked packages, some of them are only done with Linux-focus alone.

I also write down again Hyperbola's points and philosophy:

• KISS: The shortform for Keep It Simple and Stupid means that all parts in Hyperbola's repositories and software is oriented on minimalism and strict reduced dependencies.

• DIY: The shortform for Do It Yourself means that Hyperbola has no interest to deliver and distribute all favorite packages. If users want some part software, they can surely port and package it on their own, sharing also the result for the community and get more feedback for improvals.

• DRY: The shortform for Don't Repeat Yourself means that we avoid maintenance many redundant dependencies within our system itself. This principle is a best practice in software development that recommends software engineers to do something once, and only once.

Throgh, question for you, is the reason you removed vulkan due to it being bloated as a whole? I just wanted to clarify the specifics.

Also, regarding qt6, I assume this won't be added, because you have limited resources and it would be too much for you all to figure out how to make it work properly without going through a lot of hellish bugs/fixes, etc...

Ao qt6 was removed because you are already loaded with tasks then?

That makes sense as for vulkan, that supports most 64 bit interfaces I thought.

i686 aka 32 bit probably doesn't.

Anywho, at least i have some idea now why

Point taken, I should have said, qt6 won't ever be implemented because that would be too much work, etc...

Btw, didn't know vulkan was that problematic.

Supposedly, I had heard it works for Ivy Bridge or newer, but yeah, not a big deal, to not have it.

No worries for me anyways.

Fair point... I recall seeing that once when I used wine to load non-free stuff awhile back.

But my point remains, qt6  won't be implemented because it would take too much time? Or top corporate?

Alright, that was what I suspected. I just wanted to know your actual thoughts. Now I do...