You are not logged in. Please login or register.
We are very pleased and happy to announce the newest release of Hyperbola GNU/Linux-libre with v0.4.4.
See our official news for further details.
HyperForum → Packages → Proposals for package-integration
Hey sinumade, some of your proposals contain bloatware and questionable packages.
That's right.
I should have checked the dependencies beforehand.
I'm sorry I put you to more work.
And thank you very much. I never really knew what risks I was exposed to.
I'm pretty sure the actual distro may want Otter Browser integrated anyway; it suffers a bug that cycles through other tabs while changing window titles rapidly. During testing when I tried modifying some stuffs and building it sometimes.
otter-browser: https://git.hostux.net/HarvettFox96/hyp … r-browser/
Thanks, have worked within the last days myself on otter-browser and will integrate all files from your build as well if this is no problem for you, HarvettFox96. Please give a short note about that! 
I mentioned this to rachad once, but can claws-mail be added?
Also with spamassassin and its needed depends.
I should also mention, otter-browser may need some tweaks to do certain things, like videos, etc...
Unless that has been fixed in the newest build.
Appreciate you taking my thoughts regarding otter browser seriously given the mozilla and palemoon drama.
You get the point why I stay as long as possible towards UXP and our concurrent projects: We won't be able to fix problems with the so-called media-foundation and we cannot do that for every package being added. The version 0.4 would be forever kept impossible to be released as our small team would face so many problems. So we can only provide otter-browser in its concurrent state as "tweaks" include even more upstream has not solved for now.
Again to say: Hyperbola GNU/Linux-libre 0.4 is for sure a promising system and idea, but we need also more work and people behind for adding and testing packages.
Thanks, have worked within the last days myself on otter-browser and will integrate all files from your build as well if this is no problem for you, HarvettFox96. Please give a short note about that!
You're welcome.
--------------------
Alright now, folks. I just took some hours of making a package build script file for AQEMU on the stressful day because virt-manager has numerous dependencies.
About the actual distro when Hyperbola came out the stable version 0.3.1 on the Saudi national day two years ago.
Woah, this sounds quite outstanding. Thanks for the buildout. Will try that later on. Are there other dependencies needed to get this running for virtual environments? Short asked: Do it actual connect right now towards? Or is libvirtd also needed? We can remove virt-manager therefore from the TODO-list when ready and be another step towards 0.4. 
Woah, this sounds quite outstanding. Thanks for the buildout. Will try that later on. Are there other dependencies needed to get this running for virtual environments? Short asked: Do it actual connect right now towards? Or is libvirtd also needed? We can remove virt-manager therefore from the TODO-list when ready and be another step towards 0.4.
I think virt-manager is usually better and more flexible, except it also has a lot of dependencies, so its your call, hyperbola devs.
Qemu works just fine for me anyways...
I should also mention, hplip is another package I still currently desire.
If you can, I mean...
Will be doing for sure as it is on the listing to get printing done for sure. Perhaps there was / is a chance to test sane and scanning? When entering the BETA-phase in the near future we will be also onto runit as next step. But first we need to solve the base problems and also some parts missing until now like tauthon being unable to take onto spidermonkey and therefore 0ad for now.
Will be doing for sure as it is on the listing to get printing done for sure. Perhaps there was / is a chance to test sane and scanning? When entering the BETA-phase in the near future we will be also onto runit as next step. But first we need to solve the base problems and also some parts missing until now like tauthon being unable to take onto spidermonkey and therefore 0ad for now.
Ah, okay, yes, runit is also good to work on, perhaps more important at this time for me personally...
but so what you gotta do,
Alright now, folks. I just took some hours of making a package build script file for AQEMU on the stressful day because virt-manager has numerous dependencies.
I have read the code of aqemu. It has some hardcore dependencies on QtDbus. I do not think it will work well straightaway as you have in your PKGBUILD. Check the file named Service.cpp under src directory.
I have read the code of aqemu. It has some hardcore dependencies on QtDbus. I do not think it will work well straightaway as you have in your PKGBUILD. Check the file named Service.cpp under src directory.
Have checked the last tagged version as release: There is no QtDbus within (https://github.com/tobimensch/aqemu/arc … 9.2.tar.gz). So the version Debian is using also don't use this dependency. This must have been added later on as aqemu did not any further stable release after 2016.
0ad requires fmt and gloox in the alpha version 0.0.25b, so I made one of gloox only.
As for you, throgh, will you determine something and make a package build script file of fmt?
Please remember: We cannot pack newer versions of 0ad as it using Rust now for compilation and abondoned spidermonkey for that. So at best we only make use of the last version without that, will look later on the version and edit this posting right then. But the complications got in about tauthon being unable to build spidermonkey. For a tryout the version from AUR: https://aur.archlinux.org/packages/spidermonkey
The problem is the version of python2-virtualenv residing in as I have tried multiple approaches until now.
Have checked the last tagged version as release: There is no QtDbus within (https://github.com/tobimensch/aqemu/arc … 9.2.tar.gz). So the version Debian is using also don't use this dependency. This must have been added later on as aqemu did not any further stable release after 2016.
Damn yes! So stupid! Why would the dev add a dependency on dbus though?! 2016 code should work.
throgh wrote:Have checked the last tagged version as release: There is no QtDbus within (https://github.com/tobimensch/aqemu/arc … 9.2.tar.gz). So the version Debian is using also don't use this dependency. This must have been added later on as aqemu did not any further stable release after 2016.
Damn yes! So stupid! Why would the dev add a dependency on dbus though?! 2016 code should work.
If I had to guess, its probably because dbus was getting in the way of aqemu or something like that and also, that the devs don't understand bloat sucks.
Just a small guess...
So to put it bluntly, I agree with you, but also, I think the redhat devs are trying very hard even before the IBM acquisition to force their coke on everyone.
This is the same reason, I finally ditched Trisquel, and eventually devuan...
Devuan is better in my opinion then Trisquel, but let's be honest, Hyperbola is the one that is willing to not always do everything the easy way to make things truly secure, stable, private, etc.
Anywho, I feel ya... people are not always bright.
That being said, I say, Thank God For Hyperbola!
I think trust is a good thing, but also the opposite is okay. So for that to say and write: I don't think Red Hat or the developers working onto that have nothing enforced. It is the way on-going: For sure chaotic, for sure not onto privacy or security the whole way down. But I also think we have all the right to fail in some way. So please be honest with failures, for yourself, for us and also for many others. At last no one has some evil to do, not intentional and as writing that I'm just to make sure that we don't invest time having some enemy-pictures. There are none!
More or less the combination of chaotic combinations and chosen relevance of some overbloated interfaces, libraries and whole applications or middleware make the difference. Not good, but as everyone can see we are also not perfect in removing all problems at the first time. We need to work together and identify problems for that so we can reach out for a system being friendly and for sure not in any some kind of harm for the users. Rest is up to everyone by learning and free decision.
And please: Red Hat maybe for some a problem in many ways. At best to ignore that and stay friendly: The relevant enemy we have is the one within us telling more about false projections outside. Better to ignore that and stop for searching. Yes, many projects and teams decide the other way. So that's their right to do and our right to decide the other way. For sure it will get even more problematic, but that will be another decision perhaps even to stop for using some applications as example? Freedom to do so, but also the freedom of all others. The interaction is also a point where it can be a problem. But that can be solved with friendly communication, even a friendly NO is okay.
Several failed attempts that building SpiderMonkey under Tauthon is way impossible.
No matter what another incoming game package of Transcend we just made that isn't in repo.
Yes, that's the problem. Nevertheless we should try further and I think also create an issue for some proposals of Tauthon-developers. Perhaps there are some possible workarounds? Not the best way in development, I know. But when having 0ad finished we have also all games on the listing included and are there finished for now.
For the new one: Will look onto and integrate as soon as possible. Thank you!
I think trust is a good thing, but also the opposite is okay. So for that to say and write: I don't think Red Hat or the developers working onto that have nothing enforced. It is the way on-going: For sure chaotic, for sure not onto privacy or security the whole way down. But I also think we have all the right to fail in some way. So please be honest with failures, for yourself, for us and also for many others. At last no one has some evil to do, not intentional and as writing that I'm just to make sure that we don't invest time having some enemy-pictures. There are none!
More or less the combination of chaotic combinations and chosen relevance of some overbloated interfaces, libraries and whole applications or middleware make the difference. Not good, but as everyone can see we are also not perfect in removing all problems at the first time. We need to work together and identify problems for that so we can reach out for a system being friendly and for sure not in any some kind of harm for the users. Rest is up to everyone by learning and free decision.
And please: Red Hat maybe for some a problem in many ways. At best to ignore that and stay friendly: The relevant enemy we have is the one within us telling more about false projections outside. Better to ignore that and stop for searching. Yes, many projects and teams decide the other way. So that's their right to do and our right to decide the other way. For sure it will get even more problematic, but that will be another decision perhaps even to stop for using some applications as example? Freedom to do so, but also the freedom of all others. The interaction is also a point where it can be a problem. But that can be solved with friendly communication, even a friendly NO is okay.
Well, just to be clear, I Wasn't saying they were trying to be evil here. They seem to be greedy, was what I meant.
I don't trust their software whatsoever, but yeah, they aren't alone probably. There are other vendors of problematic software to look out for too anyhow.
But if you would like me to keep my thoughts out of the forum, regarding this, I can try.
Sometimes I don't know what I should say and what I shouldn't.
On a more on topic related question though, I was curious on % towards completion.
If its too much to ask though, feel free to tell me its not a good time.
Quick note btw, for 0.4 or 0.5 or something like that, the following packages will be wanted by me:
Bibletime though it is not a huge issue, because I figured out how to install for now. so 0.5 is fine,
hplip, would be nice asap, but if you have enough work already feel free to ignore till you have time.
multiload-ng: it is awesome for jwm and measures cpu load and temperature, etc... It is easy to install so I can easily want till maybe 0.5 if needed.
That should be it for now.
Well, just to be clear, I Wasn't saying they were trying to be evil here. They seem to be greedy, was what I meant.
I don't trust their software whatsoever, but yeah, they aren't alone probably. There are other vendors of problematic software to look out for too anyhow.
But if you would like me to keep my thoughts out of the forum, regarding this, I can try.
Sometimes I don't know what I should say and what I shouldn't.
On a more on topic related question though, I was curious on % towards completion.
If its too much to ask though, feel free to tell me its not a good time.
Not wanting from anyone to keep thoughts.
To be more clear: Same are only my thoughts to be focussed onto the system itself. The situation is complex and to point out for anyone does not make it right easier. So I think it is good to write down the thoughts so we can come to common understandings and there is no need to be harsh or anything else. Just to say: Better to ignore Red Hat completely as to ignore most of the single-sided parts and frameworks. It is leaving us with frustration and others keep on with finger-pointing just like "Look they hate us!". I know that this is not true and I don't want anyone being into that situation here. So at best: We do our thing and bring Hyperbola further. Whatever others do is their thing to do! And perhaps we can get towards a situation where it is up to the user to decide about INIT-system, about components and libraries being not installed and so on further.
About the current state:
Working on printer-interface, working on solving numptyphysics and some parts libraries. Outcome for applications being unfinished:
blender
libreoffice
0ad
Will test aqemu later on, but don't know if only the application is sufficient for now having some virtualization-solution. More or less we need to be faster for sure. So if anyone is up to blender and dependencies here, please help.
aqemu is not well functional for now: The application starts so far, but there is no further connection towards any virtualization-daemon and therefore many segmentation faults when trying to adjust further parts of any created VM. So this needs further testing and for sure any kind of libvirtd added. Definitely not ready for being added into the repositories for now as the application is not able to be exited correctly also over the menu. Needs more work to be done and for sure also the corresponding service-framework or qemu-discovery being fixed.
Just a quick note for anyone who feels like adding it:
https://codeberg.org/JWMKit/JWM_Kit/releases
JWMKit gives certain features to joe's window manager, such as logout, poweroff, suspsend via a menu and also an application menu which can be opened. It also doesn't change the amount of ram or cpu usage by that much.
PS, JWMKit is officially stable! According to the above link,
It has some weird, mentions of dbus and other things in it, but I have figured out how to remove those pretty darn easily. In previous releases, so I am completely certain they are meaningless for the most part.
Aka, you don't need a lot of insane dependencies to run JWMKit, it runs regardless of the freedesktop.org names within it.
They are optional.
These are the only hard dependencies!
alsa-utils (for pop up volume control) Well, this one might be optional for you guys. I doubt it will be too hard to change!
python3
python3-gi
gir1.2-gtk-3.0
I mentioned to rachad about this, you can tell him its STABLE! Whenever he has time or feels like it.
That being said, I am in no real hurry. I know how to install it locally.
Letting you know, is all I am doing.
Zapper. Thank you for suggesting my software "JWM Kit" ( packaged as jwmkit ) for package-integration.
Yes, I am the author of JWM Kit, and I have communicated with Zapper before on another forum and on JWM Kit’s issue tracker. Unless this Zapper is an imposter
I’ve provided a working PKGBUILD example for JWM Kit on my sourceforge page. It should be a good start for anyone wishing to maintain the package. Take it and do as you wish with it.
https://sourceforge.net/projects/jwmkit … UILD/Arch/
I just want to make sure the information provided to the public about JWM Kit is correct. Allow me to clear up a few things by providing more detailed information. I guess some time has past since Zapper configured his system and does not remember things perfect. For instance JWM Kit’s logout prompt is over simplified and does not have this option. I’m sure he has confuse another solution he uses with JWM Kit.
The dependencies Zapper listed are Debian names. (which is how they are listed on the website.) For an arch system you need : "python" "alsa-utils" "python-gobject"
As Zapper said you could make alsa-utils optional, but you would not be able to use the volume icon. I’d advise against it, but then many people do use their own choice of volume icon. The nice thing about JWM Kit’s volume icon is it does not run in the background, it only works when it receive input (mouse action).
About the "weird mentions of dbus and other things" mentioned.
JWM Kit strives to provide freedom of choice. This means JWM Kit try not to force any unwanted dependencies or services on the user, but at the same time provides support them. JWM Kit does not depend on dbus, consolekit, elogind, SystemD but the features provided by these services are available for those who wish to use them.
The good news is configuring these settings is easy as the First Run tool can help the user configure JWM Kit on the initial install. @zapper this easy configuration option was introduced after you first installed JWM Kit.
As stated before I only wanted to make sure the info provided here was correct. I also find it odd that with all the many things this software can do you’d mention the features of the logout prompt. Different strokes for different folks.
Sorry for the long message
HyperForum → Packages → Proposals for package-integration
Powered by PunBB, supported by Informer Technologies, Inc.