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 → Install/Update → no update ?
im just checking if there is anything wrong with my machine or pacman
is there no single package update for more than a month in stable repo ?
Same experience here.
They are working on multiple things right now, don't worry, your system should be secure for a while.
But yeah, I understand you might be confused,
They are working on HyperbolaBSD, Hyperbola's 0.4 release and a host of other things on the legal end for other purposes.
Don't sweat it, I am hopeful things will get better. 
well its a bit obscure without announcement or something
now i can wait peacefully
They are working on multiple things right now, don't worry, your system should be secure for a while.
But yeah, I understand you might be confused,
They are working on HyperbolaBSD, Hyperbola's 0.4 release and a host of other things on the legal end for other purposes.
Don't sweat it, I am hopeful things will get better.
Thanks, but a little bit more communication here or some kind of announcement would be also helpful. Especially what will be part of version 0.4 as part of the roadmap. Besides: What "things on the legal end" are done? Just to be curious.
zapper wrote:They are working on multiple things right now, don't worry, your system should be secure for a while.
But yeah, I understand you might be confused,
They are working on HyperbolaBSD, Hyperbola's 0.4 release and a host of other things on the legal end for other purposes.
Don't sweat it, I am hopeful things will get better.
Thanks, but a little bit more communication here or some kind of announcement would be also helpful. Especially what will be part of version 0.4 as part of the roadmap. Besides: What "things on the legal end" are done? Just to be curious.
Yeah, I know... as for the legal end, its stuff for a store they planning I believe. I cannot say much more beyond that till I ask him.
0.4 has been slowed slightly because two devs got sick due to covid. I think they recovering mostly though.
Also, they removing dbus, and a bunch of other redhat services at once, so it may take a few months. I have no idea...
Just sayin... 
Yeah, I know... as for the legal end, its stuff for a store they planning I believe. I cannot say much more beyond that till I ask him.
0.4 has been slowed slightly because two devs got sick due to covid. I think they recovering mostly though.
Also, they removing dbus, and a bunch of other redhat services at once, so it may take a few months. I have no idea...
Just sayin...
Woah thank you: Please, everyone stay safe and healthy as much as possible.
The pandemic has shown where major problems are and a good way is emapthy and solidarity. So a good and complete recovery for the devs. <3
zapper wrote:Yeah, I know... as for the legal end, its stuff for a store they planning I believe. I cannot say much more beyond that till I ask him.
0.4 has been slowed slightly because two devs got sick due to covid. I think they recovering mostly though.
Also, they removing dbus, and a bunch of other redhat services at once, so it may take a few months. I have no idea...
Just sayin...
Woah thank you: Please, everyone stay safe and healthy as much as possible.
The pandemic has shown where major problems are and a good way is emapthy and solidarity. So a good and complete recovery for the devs. <3
Unlike the hard times related to COVID-19 and the health of our members, it should be considered that 16 hours by developing everyday is not easy, independent of getting ways to survive such as working at Libreware in the extra time (we are preparing a new ecommerce soon).
We are developing 8 hours for HyperbolaBSD and 8 hours packaging for 0.4 that is being based on Debian's BullsEye. Maybe you could help us by looking for new volunteers to send us git patches or PKGBUILDs to complete 0.4 as fast as possible while we could put total focus on the HyperbolaBSD. It could ease our lives and we get our new version of 0.4 ready and speed up the HyperbolaBSD development.
throgh wrote:zapper wrote:Yeah, I know... as for the legal end, its stuff for a store they planning I believe. I cannot say much more beyond that till I ask him.
0.4 has been slowed slightly because two devs got sick due to covid. I think they recovering mostly though.
Also, they removing dbus, and a bunch of other redhat services at once, so it may take a few months. I have no idea...
Just sayin...
Woah thank you: Please, everyone stay safe and healthy as much as possible.
The pandemic has shown where major problems are and a good way is emapthy and solidarity. So a good and complete recovery for the devs. <3Unlike the hard times related to COVID-19 and the health of our members, it should be considered that 16 hours by developing everyday is not easy, independent of getting ways to survive such as working at Libreware in the extra time (we are preparing a new ecommerce soon).
We are developing 8 hours for HyperbolaBSD and 8 hours packaging for 0.4 that is being based on Debian's BullsEye. Maybe you could help us by looking for new volunteers to send us git patches or PKGBUILDs to complete 0.4 as fast as possible while we could put total focus on the HyperbolaBSD. It could ease our lives and we get our new version of 0.4 ready and speed up the HyperbolaBSD development.
btw, i sent our current progress in the HyperbolaBSD's kernel development -> https://forums.hyperbola.info/viewtopic … 2386#p2386
Unlike the hard times related to COVID-19 and the health of our members, it should be considered that 16 hours by developing everyday is not easy, independent of getting ways to survive such as working at Libreware in the extra time (we are preparing a new ecommerce soon).
We are developing 8 hours for HyperbolaBSD and 8 hours packaging for 0.4 that is being based on Debian's BullsEye. Maybe you could help us by looking for new volunteers to send us git patches or PKGBUILDs to complete 0.4 as fast as possible while we could put total focus on the HyperbolaBSD. It could ease our lives and we get our new version of 0.4 ready and speed up the HyperbolaBSD development.
Thanks for the feedback!
Hey, of course, do you have some plans up ahead for the packages being back into the repositories? I'd like to help in regards for the packages. Therefore my question earlier for the roadmap towards 0.4.
And this was not meant to be sarcastic, Emulatorman. Going therefore to help with the packages. Solidarity and empathy for the team and help if needed.
Remember everyone: There is the possibility to help out on Libregit!
my deepest regret if it sounded like sarcasm
im just checking if there is something broken within pacman, but given the current status of the dev im sorry if this become something like annoyance
Emulatorman wrote:Unlike the hard times related to COVID-19 and the health of our members, it should be considered that 16 hours by developing everyday is not easy, independent of getting ways to survive such as working at Libreware in the extra time (we are preparing a new ecommerce soon).
We are developing 8 hours for HyperbolaBSD and 8 hours packaging for 0.4 that is being based on Debian's BullsEye. Maybe you could help us by looking for new volunteers to send us git patches or PKGBUILDs to complete 0.4 as fast as possible while we could put total focus on the HyperbolaBSD. It could ease our lives and we get our new version of 0.4 ready and speed up the HyperbolaBSD development.
Thanks for the feedback!
Hey, of course, do you have some plans up ahead for the packages being back into the repositories? I'd like to help in regards for the packages. Therefore my question earlier for the roadmap towards 0.4.And this was not meant to be sarcastic, Emulatorman. Going therefore to help with the packages. Solidarity and empathy for the team and help if needed.
Remember everyone: There is the possibility to help out on Libregit!
I doubt we could back all 14k of packages in the next version (0.4) because we don't have enough man power like Arch for that (remember that 90% of those packages were synced from Arch for our current stable version), however we will try do our best to maintain the most important. Also we removed all Linux kernel frameworks in the next version (PAM, DBus, elogind, etc), so we should looking for a lightweight gtk-based desktop environment as Lumina, because Lumina is qt-based, so in this case we could distribute 2 DE alternatives for our community.
Since we want to be a KISS distro, it should be applications (DEs, WEs, browsers, tools, etc) based on minimalism and lightweight as possible, and try to avoid repeat a lot of applications for a same task (eg. avoid add 10 browser applications). It only delay our versions releases and overload our development, so for that reason we should reduce the size of packages on our repos too.
my deepest regret if it sounded like sarcasm
im just checking if there is something broken within pacman, but given the current status of the dev im sorry if this become something like annoyance
Don't worry diaksp2, it means that you, zapper, throgh and active community here are interested for Hyperbola Project, so thank you for your support. Maybe it was my fault don't feedback our progress for lacking time, but don't worry, i will try do my best to reporting our progress in forums.
Currently we have some headaches to make work our pacman with our latest bash pushed in 0.4, the issue is something like it:
| ==> Starting package_linux-libre-lts-headers()...
| rm: cannot remove '/logdest/logpipe.PuNQLqMx': No such file or directory
| ==> ERROR: A failure occurred in package_linux-libre-lts-headers().
| Aborting... I will try to backport some changes in the latest pacman to see if works. At least for now https://git.archlinux.org/pacman.git/co … 2dc5b1ee19 seems one of the Bash 5 fixes. Also there are some another changes such as https://git.archlinux.org/pacman.git/co … c87cc90b81 (logpipe) and https://git.archlinux.org/pacman.git/co … c5786c7a46 (modify wait)
Since pacman is so dependant of bash, we will try to remove bashisms in hyperman (the nextgen package manager for HyperbolaBSD) to make compatible with another shells. Pure POSIX should be the way
Thanks for the input, Emulatorman! <3
Nice one for a really lightweight distribution at all - yes some headaches included for interesting and helpful applications like Kdenlive oder K3b, but I think better to focus already and decide what matters. The orientation towards the lightweight desktop-environments is another good focus and decision. Don't want to use this thread but just taking a proposal as quick first idea:
JWM
IceWM
i3
Lumina
We could also do this in another thread as this topic is just too important getting that into sideways.
I was shocked back in the last year to discover that there are some really nice looking but also lightweight environments out there being more or less ignored.
Thanks for the input, Emulatorman! <3
Nice one for a really lightweight distribution at all - yes some headaches included for interesting and helpful applications like Kdenlive oder K3b, but I think better to focus already and decide what matters. The orientation towards the lightweight desktop-environments is another good focus and decision. Don't want to use this thread but just taking a proposal as quick first idea:
JWM
IceWM
i3
LuminaWe could also do this in another thread as this topic is just too important getting that into sideways.
I was shocked back in the last year to discover that there are some really nice looking but also lightweight environments out there being more or less ignored.
+1, I think those WMs and Lumina as our main DE are the way for now. Let me know when you create a thread about it. Thank you for those suggestions.
throgh wrote:Thanks for the input, Emulatorman! <3
Nice one for a really lightweight distribution at all - yes some headaches included for interesting and helpful applications like Kdenlive oder K3b, but I think better to focus already and decide what matters. The orientation towards the lightweight desktop-environments is another good focus and decision. Don't want to use this thread but just taking a proposal as quick first idea:
JWM
IceWM
i3
LuminaWe could also do this in another thread as this topic is just too important getting that into sideways.
I was shocked back in the last year to discover that there are some really nice looking but also lightweight environments out there being more or less ignored.+1, I think those WMs and Lumina as our main DE are the way for now. Let me know when you create a thread about it. Thank you for those suggestions.
I opened a new thread about it, please let me know if you have new ideas or proposals while we are in the process of packaging in Milky Way v0.4 and development in HyperbolaBSD.
Big thanks! Having a look into it. <3
Do you have plans for the applications in userland? So looking into some like VLC, smplayer, Handbrake, Gimp, Inkscape and Audacity. Yeah, most of them are more or less the known "open-source" examples, but I have more in mind how to help with libraries being shared also into BSD and therefore being more easy for the migration. So perhaps as community we could help here in the same way as 0.3: Showing our usecases, of course also with the knowledge to find possibilities.
Meaning also having lost Wine in some way. But hey: That's okay when looking onto creative ways in helping each other.
Big thanks! Having a look into it. <3
Do you have plans for the applications in userland? So looking into some like VLC, smplayer, Handbrake, Gimp, Inkscape and Audacity. Yeah, most of them are more or less the known "open-source" examples, but I have more in mind how to help with libraries being shared also into BSD and therefore being more easy for the migration. So perhaps as community we could help here in the same way as 0.3: Showing our usecases, of course also with the knowledge to find possibilities.Meaning also having lost Wine in some way. But hey: That's okay when looking onto creative ways in helping each other.
Yes, those applications are planned to be included in v0.4 and HyperbolaBSD, however we could use GIMP 2.8 for now, because it is the latest version available to disable D-Bus, the latest one available in GIMP forces it. Maybe we could create a patch based on the 2.8 version to make work the latest version without D-Bus, however the best way is send a feature request to the GIMP guys to disable it as option. Could you do that?
Yes, those applications are planned to be included in v0.4 and HyperbolaBSD, however we could use GIMP 2.8 for now, because it is the latest version available to disable D-Bus, the latest one available in GIMP forces it. Maybe we could create a patch based on the 2.8 version to make work the latest version without D-Bus, however the best way is send a feature request to the GIMP guys to disable it as option. Could you do that?
Will try to contact the team and create a feature-request onto this.
Emulatorman wrote:Yes, those applications are planned to be included in v0.4 and HyperbolaBSD, however we could use GIMP 2.8 for now, because it is the latest version available to disable D-Bus, the latest one available in GIMP forces it. Maybe we could create a patch based on the 2.8 version to make work the latest version without D-Bus, however the best way is send a feature request to the GIMP guys to disable it as option. Could you do that?
Will try to contact the team and create a feature-request onto this.
Cool, thank you so much for your contribution.
Hope there will be an answer: https://gitlab.gnome.org/GNOME/gimp/-/issues/5955
Coming back onto that!
There is a first reaction:
How does it work on the other BSD (OpenBSD, FreeBSD, etc.)? GIMP is available on all the other main BSDs and it works fine AFAIK. Isn't DBus available there either?
Generally we are happy with updating GIMP code to make it work on more platforms. But it requires well thought contributions by the people caring for GIMP on said platform because most of us have no idea exactly what is required there, what would be the best replacement code, etc. In other words: patch welcome. 😉
For instance, one of D-Bus main usage is to keep a single instance of GIMP opened (if you try to open a new image in GIMP while another GIMP process is running, the new process will just send the image information to the older process so that the new image is opened in running GIMP). On Windows, this is replaced by specific Windows API code instead of DBus. How would you do this on HyperbolaBSD?
There is a first reaction:
How does it work on the other BSD (OpenBSD, FreeBSD, etc.)? GIMP is available on all the other main BSDs and it works fine AFAIK. Isn't DBus available there either?
Generally we are happy with updating GIMP code to make it work on more platforms. But it requires well thought contributions by the people caring for GIMP on said platform because most of us have no idea exactly what is required there, what would be the best replacement code, etc. In other words: patch welcome. 😉
For instance, one of D-Bus main usage is to keep a single instance of GIMP opened (if you try to open a new image in GIMP while another GIMP process is running, the new process will just send the image information to the older process so that the new image is opened in running GIMP). On Windows, this is replaced by specific Windows API code instead of DBus. How would you do this on HyperbolaBSD?
It is my response:
First of all, HyperbolaBSD is focused to be a minimalist operating system, so automatization is not welcomed here. Second, freedom of choice should be respected because is a way to give the option for users and distributions make the better choice under their own point of views, so force D-Bus is not the way because it's like treating us like cattle.
Independent of those points cited above, there are another issues related to D-Bus:
Bloated and over-engineered: Its C API is very annoying to use and requires writing large amounts of boilerplate code. In fact, the pure C API is so annoying that its own API documentation states: “If you use this low-level API directly, you're signing up for some pain.”
Absurd bugs and and conceptional problems: The bugs range from uncontrolled memory usage, over silent dropping of messages, to dead-locks by design, unsolved for up to 7 years. Looking closer, most of them simply cannot be solved without breaking guarantees long given by dbus-daemon(1), the reference implementation.
D-Bus leaks machine-id across applications which causes privacy and fingerprinting concerns.
Further details:
Thanks will take that back into the ticket. Is it okay to have also noted in another posting, how they had realized the singleton application-instance in earlier versions?
Thanks will take that back into the ticket. Is it okay to have also noted in another posting, how they had realized the singleton application-instance in earlier versions?
I found something that I think might work as well as gimp:
https://github.com/bgrabitmap/lazpaint/
for my needs it works at least, I searched for gimp alternatives and found this, tell me if it has what you guys need and whatever it doesn't have, feel free to mention.
Actually this one might also work: https://github.com/glimpse-editor/Glimpse
But lazpaint requires way less depends thats why I mentioned that one first.
HyperForum → Install/Update → no update ?
Powered by PunBB, supported by Informer Technologies, Inc.