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 → System → What programs can I install on Hyperbola?
Hi all . Please tell me what programs I can install in Hyperbola so as not to spoil the distro from the point of view of freedom and so that they work correctly taking into account remote programs and daemons (for example, d-bus, etc.)?
Or build.
Can you give an example?
At the moment I am missing various programs and, as I read on here, they will not be added since all efforts are aimed at creating HyperbolaBSD.
Thank you for your answer . I understand this, I asked (clarified) to figure it out, for example, recently a user tried to assemble lightdm (Display Manager) and during assembly the required program was not found.
I would like to build some kind of graphical IRC client, I think it will be useful for many.
Please tell me how you would do this to avoid conflicts with Hyperbola and lack of programs?
List of IRC clients and other information => https://github.com/davisonio/awesome-irc
You can use hexchat for example being part of Hyperbola for a long time and I again underline that you can search the repositories with different toolsets:
Using the link for packages in your browser: https://www.hyperbola.info/packages/
Using the commandline with doas pacman -Ss [SEARCH]
Using the package tkpacman (also part of the repositories)
And there is no lack of programs. Either a software runs with the given tools or you have to rebuild your environment for your purpose. The issue with lightdm is also that it depends on further bloated frameworks Hyperbola is not offering. Please read therefore this wiki-article: https://wiki.hyperbola.info/doku.php?id … e_packages
So I repeat: This is not about missing programs, it is about incompatible frameworks as Hyperbola rejects them out of clear reasoning and purpose.
So if you want to create your own PKGBUILDs, feel free doing so. Hyperbola is free, libre software and you can always add or change something as you like! And as I have again the impression that this is mistaken: No, Hyperbola is not only having support with IRC. There are all possible ways in usage and we have an issue-tracker: https://issues.hyperbola.info/
Hello Throgh. Thank you very much for your detailed answer. I understand what you mean, I'll clarify my question a little.
Yes, you're right, the repositories have almost everything you need. I understand and share Hyperbola's position regarding programs and packages.
I like such rigor but reasonable)) I think that you understand this very well!
My question is related to the correct, correct assembly of a program that is not in the repositories. Or as you wrote: you will have to rebuild the environment for your purposes. As practice has shown, even experienced users are faced with the fact that they did not find the package they needed.
For example, I or another user wants to build a GUI version of the XMPP client https://github.com/bluszcz/awesome-xmpp or the IRC client https://github.com/davisonio/awesome-irc or another program he needs. Let's say I don't like Hexchat.
When I asked you about building Qemu from the official source, version 8.2.0 https://www.qemu.org/download/ and not 5.2
wget https://download.qemu.org/qemu-8.2.0-rc3.tar.xz
tar xvJf qemu-8.2.0-rc3.tar.xz
cd qemu-8.2.0-rc3
./configure
make
doas make installYou suggested that I build from the testing-branch directory. I did everything, everything works fine.
But what if I want to install a program or package on Hyperbola that is not in the repositories but has all the dependencies to build
the program I need.
I can't connect another repository -oK
Or does the user have no choice and is forced to use only those programs that are in the repositories?
For example, what if I want to build and install Quassel IRC client -GUI, it is not in the HP repositories,
can I use for example the Parabola repository https://www.parabola.nu/packages/?sort= … p;flagged=
Or for example, I want to put together a program to listen to the radio https://github.com/haecker-felix/gradio
First to underline again - as I have posted already: No one is forced to use the programs and packages Hyperbola provides. You can always modify your own environment you want. But you need then to support your environment the way you want. You can create also your own repositories and package the software. Coming therefore to the point: No, you should not use Parabola as Hyperbola is not Parabola and also not supporting the packaging-format. When people want packages from Parabola, they can also install Parabola then. Same for Arch GNU/Linux, Manjaro or others. Mixing is not possible as Hyperbola is an independent, complete different system with also other focus. If you do so, you will damage the system. Therefore then: If people want packages from named other systems, they can install them and decide to remove Hyperbola. No issue with that.
If you want to compile and try quassel you can package it as you like: Building an own PKGBUILD is always possible. But this is the next point: You should not just "install" compiled sources via "doas make install" as afterwards you have no further version-control. Packaging is here the better way doing.
In the summary: When Hyperbola 0.4 was in the making we have checked many of the listed packages already. And most of them were not compatible as of the already given reasonings. So even when you manage to compile quassel (without KDE-dependencies) it could be possible you won't be able to run it out of possible enforced D-Bus.
The last point, closing the circle: Every package and program you want to add is on your own responsibility. This means you can try to build and port / patch it the way you want. But you are responsible for running it. Finally underline again: It is fact that majority of projects do not support the way Hyperbola is onwards, also not supporting complete free, libre dependencies from many and inclusion of questionable interfaces or even using questionable programming-languages resulting in foul compromises. That's a question of the perspective how hard free, libre software is seen, Hyperbola is doing that based on hard and strict principles.
And the listings you are linking also links questionable projects like "Swift" for example, so you should look very close and with care on the sources you want to use. All your answers are also here:
https://wiki.hyperbola.info/doku.php?id … sd_roadmap
https://wiki.hyperbola.info/doku.php?id=en:project:fhs
https://wiki.hyperbola.info/doku.php?id … positories
https://wiki.hyperbola.info/doku.php?id … e_packages
https://wiki.hyperbola.info/doku.php?id … c_failures
https://wiki.hyperbola.info/doku.php?id … ble_system
https://wiki.hyperbola.info/doku.php?id … guidelines
You can also try the PKGBUILD and inbound files from Parabola for quassel: https://git.parabola.nu/abslibre.git/tr … l/PKGBUILD
But already to warn:
You will not be able to build it because of non-free qt5-webengine (includes chromium-parts), you will have massive missing dependencies building and possible risk for D-bus also. You can therefore see that those comparisons are not working. Better would be a clear new and fresh rework of quassel for packaging. But also here: When those mentioned dependencies are mandatory you have no further choice and chance. Also to warn that Qt as framework is of high doubts since version 6.0 and beyond and Hyperbola has frozen dependencies in that region also with reasoning. Freedom of choice is also freedom of responsibility, jim. And when frameworks and environment-packages restrict the freedom they can be no longer called "free and libre software", just "somewhat open-source". The vague term is not without reasoning given and making the difference. And gradio is a project being no longer maintained (packaging-guidelines), while its successor shortwave is completely incompatible with Hyperbola out of the reasoning for mandatory based and developed in Rust. Free software is living from its altruistic perspective, so you can always step up as the new maintainer for gradio, create a fork and work in it. But also there are enough logic flaws and fails in many projects as they are only seen under the proclaimed description of "progress at any costs". And this "progress at any costs" is also including pragmatic evaluation and addition of dependencies, resulting in questionable results with new versions. Your example of qemu is such as we have our version here in the repositories working and building. We do not know for the moment if the new version is also following the same syntax, the same dependencies and also do not include even more needed, mandaotry dependencies we possibly do not want ever having here. That to be said: If you want to update, your choice. If you want to build, do as you like. But Hyperbola is not following the "newest development", that is not our focus and will never be.
To underline:
We are NOT a common GNU/Linux-distribution and system-distribution.
We are NOT a common Linux-oriented system (any longer since release of v0.2.x).
We provide a system-base with surely as much as possible packages and software for usage.
We provide NOT a full-packaged base as many projects and softare is NOT providing that amount of freedom and choice we think is needed.
And no user has to accept that and can modify own installations to own likings. But we also cannot provide support therefore. Yes, this makes Hyperbola surely not very attractive in the eyes of convinience-searching users. Also that: This is and was never our common goal. We are going to be a BSD-compliant and based operating-system, with inclusion of SOME utilities from GNU-spheres later on, but with main focus on BSD only system-base. Our GNU/Linux-libre system is already following that approach, so we are clear on the side of the FSDG, taking them serious and strict. The answer for adding software is just: When possible, try to compile. When compilation is not working, patch it and create your own port or even your own fork fitting your liking. Just to mention: Please do not await support when you build own packages. That is not possible!
And about gradio: That package is building and possible to install but nevertheless complete malfunctional as already said no one is maintaining it: https://forums.hyperbola.info/viewtopic … 7150#p7150
That's the reasoning why we do not add those packages any longer and reject to maintain them. Either their sources are addressing too old functions and interfaces or the URLs used are no longer existing. And we have no time and interest to debug those. In that case gradio is using radio-browser.info and parse a resultset. But the website has developed further and is no longer working with the requests that application is sending. That is why we deny adding applications depending on questionable services. If you demand that for your own, do so. But this is not working for Hyperbola itself. So you would need to patch this application! And that's the reasoning why we also do not add other packages using a needed internet-service for functioning. This is something nobody wins.
Btw, somewhat unrelated, but if anyone used jwmkit and the time wasnt making sense, the dev behind jwmkit mentioned that:
%l:%m %p
was why the clock looked wrong. %m = month, not minute!
Throgh ,thanks for your detailed answer.
So we have this situation, to summarize))
a) Add a third-party repository to Hyperbola - Impossible!
b) Use other repositories to build programs, even if they are similar to Archie - Impossible!
c) Build your program and install it in Hyperbola - Not recommended in 99% of cases due to the large number of missing dependencies and strict policies.
I would like to inform you that Qemu version 8.2 from the official website was assembled the first time without errors, the only thing required was to install ninja.
I need a hint. For example, I see an application that I would like to install, I look in the dependency repository, everything is there, can I then compile and install the program or have you already searched through all possible program options?
Cynicfm hello, I understand you, but I wouldn’t waste time and effort if I didn’t like Hyperbola, the question is related to adaptation.
I correct you:
a) Add a third-party repository to Hyperbola - Possible when community is active and / or people are interested doing so (creating own repositories), possible!
b) Use other repositories to build programs, even if they are similar to Arch - Based on the decision of the user but we won't recommend doing that when non-free or problematic software is included, possible!
Please read careful again: Hyperbola is a build-base also. And it is your and everyone's choice. But Hyperbola is NOT designed to be a common Linux-system including thousands of packages. That is not our goal. We want to build an operating-system and for this you can always add your own software.
I'm surely interested to support what is possible and therefore 0.4.5 will include also a mirror-option for everyone creating a local installation and to preserve Hyperbola at any point on. With this also I'm interested in making it possible to create own repositories more easy, perhaps with guidance later on. But with all that tasks I'm surely a bit overworked and need time for everything. Nevertheless: If somebody seeks a comparison, Hyperbola would be something like Minetest (older versions): Giving a base and from there handing out the full creativity enabled.
So with this I have a wonderful image coming to your last point: No, definite not checked all programs or / and projects. We have tried the most known ones and even today I find with surprise others. Therefore also making gradio possible to compile. Only the issue: Most of those programs using web-services are inbound in a fast development-cycle. Only some querystrings changed, only a slight enhancement of any API-call on the webservice and the full client-implementation breaks. That's also the issue on behalf other projects like yt-dlp. Aside from this that's also a non-free service surely not to be included and so we have removed hypervideo with 0.4.2 and beyond. If you relate to your listings linked: Yes, those are checked and most of them do not work.
Summary: See above corrections / additions and also ... not all projects existing whereever checked. When you find some, you can always ask and / or try your own building local first. The PKGBUILD for gradio was / is also meant as demonstration! 
But I have now the impression that you want to make some checklists why Hyperbola is that possible or not. This is not working and within my perspective also very strange way: Every user with a bit experience in compilation and patching, including also shellscripts can go on here being creative. So this is not a question of adaption, more about if people are interested or not. This brings me back to the point: People create PPA-repositories for Ubuntu, DEB-packages for Debian (and derivates), clone repositories and adapt their own. Hyperbola has just the same point possible, just that only people need to be interested doing so. There is no difference to other systems in that, only it needs engagement and possible approaches forward. And you can compile what you want for your usage. It is just the point: You want to share the information? Or you don't want to share? And with HyperbolaBSD the point for any repository is also going in a complete different direction as we then would speak not only about repositories but also about ports.
Thank you for your answer.
a)Add a third-party repository.
You write what is possible, it won’t be difficult for you to write an example here to make it clear how it works. I think this will be useful for everyone who reads this topic and looks for a question to this answer.
Usually one correct example is better than 10 explanations))
b) Use other repositories to build programs, even if they are similar to Arch.
Please show me the correct example, I will implement it.
Regarding the number of packages, I have read and understand that if the program works correctly and safely, then you do not try to update it because there is no point in doing so.
Regarding the compilation of lists)) This is a mistake. I don’t think, as you wrote, it’s possible or not possible, I’m thinking about how to correctly configure the system to fully use Hyperbola for everyday tasks, regardless of whether I’m a professional programmer or an ordinary user, so I compiled a list of programs and also wrote short instructions on how to install Hyperbola so that those who I came here without wasting my time searching. Everyone has a different experience, this needs to be taken into account. You can’t be arrogant about this if you don’t have experience and you can’t, you’re not with us)) This is digital discrimination! (this is an example; you don’t need to try this example on yourself))
Yesterday I tried to build the latest version of gradio, but I couldn’t find it in the log4cpp repositories, I tried to build log4cpp, the system says that you need automake 1.6.1))
I also wanted to ask you (you have more experience) whether it is possible to build a graphical XMPP client, if possible, I will do this, which option in your opinion is preferable from those that are available for assembly. Not all of our friends know how or do not want to use the terminal
and we have no right to force them))
Dino => https://github.com/dino/dino https://openbsd.app/?search=dino
Gajim => https://gajim.org/
CoyIM => https://coy.im/ https://omemo.top/ tells us that this client does not use omemo
Other possible options..
Dependencies dino 0.4.3-4
https://www.hyperbola.info/packages/
gdk-pixbuf2 -Ok
glib-networking -Ok
glib2-Ok
gpgme -Ok
gspell Have not found
gst-plugin-gtk Have not found
gst-plugins-base -Ok
gst-plugins-good Ok
gstreamer -Ok
gtk4 Have not found
libadwaita Have not found
libgcrypt -Ok
libgee -Ok
libnice -Ok
libsignal-protocol-c Have not found
libsoup -Ok
libsrtp -Ok
qrencode -Ok
sqlite -Ok
webrtc-audio-processing -libfilteraudio | I don't know if this is a replacement?
cmake (make) -Ok
git (make) -Ok
ninja (make) -Ok
vala (make) -Ok
I have now tried to explain multiple times that you are all alone responsible for building the application and its dependencies, jim. And I have pointed out that I try best to support. And you mention now digital discrimination? Surely everyone has different levels of experience. I don't know what you are up to here:
gspell - we do not include this bloated library
gst-plugin-gtk - https://www.hyperbola.info/packages/gst-plugin-gtk
gtk4 - we do not support gtk4 for the moment, also no plans doing so
libadwaita - we do not include this bloated library
libsignal-protocol-c - https://wiki.hyperbola.info/doku.php?id … nd_removed
webrtc-audio-processing - https://wiki.hyperbola.info/doku.php?id … nd_removed
So everyone gets her help, jim. But I underline now: There is no such thing like "digital discrimination" here and also there is no such thing existing. Please stop using those words immediately in this kind of discussion: Accusations do not help and are also misplaced here. Hyperbola is about technical emancipation, giving back the control into the hand of its users. Most of the libraries you count into for compiling dino do exactly the opposite of that: Let's take webrtc. This is a corporate project from Google, so you have only free, permissive (alike) licensing for source-code in some way. Trademarks and the rest is at Google, patents same. So whenever Google (or Alphabet) have no further interest opening that up they close down and all others have serious issues when libraries and dependencies for applications get removed. Hyperbola does not include them exactly for this reasoning. If you want that you will need to build it on your own for your needs and system. Yes, Google (Alphabet) won't remove them that fast as they have interest to develop them further without paying that much. So what is the best way? Yes, let's have the people work on this without paying anything. That's pure ignorance and arrogance, and that's coming way near your mentioned "digital discrimination" (besides that wording is not existing nevertheless). For Hyperbola speaking: Everything can be learned. You want to look into possible tools for repositories? Here: https://git.hyperbola.info:50100/staging/dbscripts.git/
You can also look further in the git-repositories as everything is there, including all removed packages.
I have mentioned already that gradio is not able to fulfill any request as of now being not supported. When you have a different repository you should link it here.
About XMPP and clients listed: Gajim is not possible to build as of mandatory need for D-Bus and there is no omemo-implementation aside of libsignal-protocol in C / C++. So we also do not support this. We had dino included in an older version, but also removed the application / package out of reasoning demanding non-supported APIs and libraries in newer versions. That's exactly what I have described before: You cannot await inclusion for more packages as Hyperbola is oriented on the opposite. Rest is up to you, building it for your purpose as you like.
About creating own repositories: I have said that I want to do that if there is interest. Not that I do this direct within this thread. And I won't do that also here: A wiki-guide is needed then.
Thank you for your answer .
As for sponsors and financial support, I understand, you have said this many times here on the forum, why are you repeating it again))
You and all developers need to conduct analytics to understand why Hyperbola is not so popular among users and developers and why there is no money to develop and pay for servers.
There is no need to be afraid of constructive criticism.
I don’t agree with your example about studying, my argument is this: let’s imagine that your wife washes your family’s things with her hands instead of putting them in the washing machine or dishes in the dishwasher. If it is possible to use these tools, let’s call it that, to achieve a goal and it is effective, then it should be done! Why learn to wash by hand like a washing machine?))
Regarding program control by the Hyperbola team, I agree with this, but my question is not related to this. You already wrote this!
Everything that you wrote about self-development, motivation is correct for a developer, for a standard user this is not necessary, when you take a pill for a disease that you bought at the pharmacy, the doctor doesn’t tell you that you need to become part of medicine, come up with a pill better than what you just took.
As for the Dino compilation, you write: Dino, they do the exact opposite: let's take webrtc. This is a Google corporate project...
And a few years ago, Hyperbola used all these programs and packages on an ongoing basis (dbus, NetworkManager https://wiki.hyperbola.info/doku.php?id … _packages, etc.) it turns out you only realized this a few years later?
Hyperbola used: flatpak ,gajim ,glib-networking ,gnome-bluetooth,go,java-common wayland etc
So let's go back to my questions that you answered.
a) Add a third-party repository.
You write what is possible, it won’t be difficult for you to write an example here to make it clear how it works. I think this will be useful for everyone who reads this topic and looks for a question to this answer.
Usually one correct example is better than 10 explanations))
b) Use other repositories to build programs, even if they are similar to Arch.
Please show me the correct example, I will implement it.
I don’t agree with your example about studying, my argument is this: let’s imagine that your wife washes your family’s things with her hands instead of putting them in the washing machine or dishes in the dishwasher. If it is possible to use these tools, let’s call it that, to achieve a goal and it is effective, then it should be done! Why learn to wash by hand like a washing machine?))
Why do you use such strange comparisons? And I don't want to start doing the same here, as in my point of view this is not helping in any way. Coming more below!
As for the Dino compilation, you write: Dino, they do the exact opposite: let's take webrtc. This is a Google corporate project...
And a few years ago, Hyperbola used all these programs and packages on an ongoing basis (dbus, NetworkManager https://wiki.hyperbola.info/doku.php?id … _packages, etc.) it turns out you only realized this a few years later?
Development is not a linear process, jim. Hyperbola has and had no influence many projects included before have taken now. Also to underline: There was and is a break between 0.1, 0.2, 0.3 and finally 0.4 in the cycle. Hyperbola started once with a taken snapshot from Arch GNU/Linux. That's absolute correct. But even in 0.2 and 0.1 taking a different route by removal of biggest issues. We are doing the same route now with HyperbolaBSD and its components in development. First you need a base working, than you optimize it following your plans and route. Hyperbola was never planned as a common GNU/Linux-oriented system-distribution fully. It was first even most oriented for server-usage.
So I count in now the historical development:
0.1 -> snapshot from Arch GNU/Linux, systemd and many more included
0.2 -> removal of systemd, already based on the snapshot taken
0.3 -> LibreSSL and Xenocara got into
0.4 -> complete rebuild from scratch
And as I have said: 0.4.x is a rebuild from scratch. All packages are ours here now, nothing is left from any snapshot.
Hyperbola used: flatpak ,gajim ,glib-networking ,gnome-bluetooth,go,java-common wayland etc
You may look above? Hyperbola used as of based on the snapshot. We have removed that out of reasoning. When you want all of them, please take into account to have either doing that on your own or choose different solutions you like.
So let's go back to my questions that you answered.
a) Add a third-party repository.
You write what is possible, it won’t be difficult for you to write an example here to make it clear how it works. I think this will be useful for everyone who reads this topic and looks for a question to this answer.
Usually one correct example is better than 10 explanations))
b) Use other repositories to build programs, even if they are similar to Arch.
Please show me the correct example, I will implement it.
Jim, I have named already an example here. You can really do the following: Copy the content (code) in a PKGBUILD-file (it needs to have this name) and use the following command in the folder you have saved it (recommendation: only this file nothing more):
makepkgThat is the elementary first point to go further to create package on your own. As I have underlined I try the best possible to support, but while maintaining, packaging, writing documentation and more this is not very easy to do that all at once.
Last but not least: You demand something out of the financials, which would again collide. Who should do that in a team with three persons? You are not the only person and with the amount of financial suppot (there is nothing more as of now listed here. If you want Hyperbola to be something like Devuan, you should also grant Hyperbola the possible number of persons behind Devuan. I repeat again: We do not have them. If you are not okay with that, it is up to you for finding an outcome, not for Hyperbola or us as small team to constantly justify us here.
We are interested in constructive discussions and proposals to optimize at every given time. But what you are doing here is like demanding some more justification for anything. That is nothing we are doing! When you need some already mentioned packages for your workflow, we are absolutely okay with your decision. No issue with that, but Hyperbola has also a right for taking its own course. So coming to a possible proposal:
You can always update, modify or change any PKGBUILD and rebuild it. Making own proposals. For qemu, here is the list of files for building your very own version: https://git.hyperbola.info:50100/packag … /tree/qemu
So you said that you have updated to the newest released version, can you perhaps share your built package-sources? Others can review them, optimize and rework (work) with them. That's how Hyperbola is intended to work. And you have now also an explanation why the community is not that big. Because free, libre software is NOT gratis, it is:
- learning together
- working together
- failing also sometimes together
- learn again from this together
... and cheering up together when something finally builds and works like planned. And it is also (optimum) financial independent, so either the community is supporting with time and / or money, or some sponsors without demands. But the last scenario is not only uncommon, it won't happen as every other bigger system-distribution is NOT financial independent and the derivates are seen the same depending on corporate financials and money.
And I have also started once the same way like mentioned before with creating a PKGBUILD-file and use makepkg, on Parabola. I saw that I can build my package on my own way. But when you want a complete guideline here, you should please first try the absolute minimum. You said yourself that guidance is starting step by step.
Thank you for your answer .
I’m skipping some of my answers so that we don’t write a book here with so many letters with our reasoning and views on different topics))
And I return to the technical issue of assembly.
You write that...copy the contents (code) into a PKGBUILD file (it should have that name), etc.
I understood this and already did it, I even told you that you can build a new version of Qemu without errors, and I found updates that you also changed PKGBUILD for version 5.2 -Ok
My question was different from the very beginning. Once again, please write the answer to these questions!
a) Add a third-party repository.
You write what is possible, it won’t be difficult for you to write an example here to make it clear how it works. I think this will be useful for everyone who reads this topic and looks for a question to this answer.
?????
b) Use other repositories to build programs, even if they are similar to Arch.
Please show me the correct example, I will implement it.
????
When I assembled Qemu 8.2, you wrote that I needed a different path and said that I didn’t need to do that, now you’re asking me to share the build, I can’t understand your logic.
You can also use the qemu from testing-branch direct. Here: https://git.hyperbola.info:50100/packag … /tree/qemu etc
In order for me to build other programs just like Qemu, I need you to show an example.
After assembly I will tell you the result.
Okay, for the own repository I will sit down surely and get all details together and post them when having. For the logic about compilation packages:
All packages have their respective folder, listing them:
core https://git.hyperbola.info:50100/packag … .git/tree/
extra https://git.hyperbola.info:50100/packag … .git/tree/
So you can clone the git-repositories local:
git clone https://git.hyperbola.info:50100/packages/core.git
git clone https://git.hyperbola.info:50100/packages/extra.git/
With those you have really ALL packages in their respective build-plan. What I have asked: When updating a PKGBUILD and its other files like qemu you can also share what you have done: Like within a git-repository or here in the forums (example: https://forums.hyperbola.info/viewtopic … 50#p7150). With this you can also share back updates, or even later build your own ones.
Respective example: You see a useful CLI-project you like? Okay, look for Debian packages, perhaps there are some more hints. Look elsewhere, including the project itself and go building your PKGBUILD (and patches when needed). So I have build gradio. You can see there is no PKGBUILD elsewhere. And that is possible to be shared. The steps I would underline:
1. Build (rebuild) from repositories of Hyperbola.
2. Patch and renew own build, sharing back. <- We are here (in this thread)
3. Try for own builds and build-plan (PKGBUILD)
4. Building in clean chroot
5. Go for package-maintainer possible with more enhancements and tricks
But also to underline: You need many parts of the steps I have scribbled down. A clean chroot is needed for the guarantee your package is building and also possibly rebuilds outside in a clean environment. Without that you would have issues for others rebuilding your package-plan (PKGBUILD).
I don't mention this for making you or anyone else angry. It is common point and best practice for having a clean working package later on. So we need to go through steps, really step by step. And sharing back your buildscripts is not bad, in fact it helps you also direct.
So let's assume you have created your own packages and you are okay with them building: You need the compressed package-archives in a folder. Let's assume this folder is called mypkgs and is under /var/lib/repos. Concluding:
/var/lib/repos/mypkgsYou can copy each package-archive into this:
cp *.pkg.tar.lz /var/lib/repos/mypkgsHINT: The permission for files and folders is not part of the notes here.
You enter the folder /var/lib/repos/mypkgs and:
# repo-add mypkgs.db.tar.lz *.pkg.tar.lzExample output:
# repo-add mypkgs.db.tar.lz *.pkg.tar.lz
==> Adding package 'arx-libertatis-1.2.1-1-x86_64.pkg.tar.lz'
-> Computing checksums...
-> Creating 'desc' db entry...
-> Creating 'files' db entry...
==> Creating updated database file 'mypkgs.db.tar.lz'I have chosen now one entry manual. But that's the point: Your repository needs to be:
- consistent offering packages and all package-dependencies
- sharing clean builds
That's all I have mentioned already before. And after you have created your package-repository, you are also able to share it:
- File
- HTTP / HTTPS
- Rsync
Your choice and you can check it here: https://mirror.fsf.org/hyperbola/gnu-pl … a/os/i686/
And now I have shown you the information you have demanded, jim. But to point out: Most of this was there before. I repeat: Please share at best your qemu-modifications as you have pointed out:
I would like to inform you that Qemu version 8.2 from the official website was assembled the first time without errors, the only thing required was to install ninja.
It is wrong to compile it only local and use doas make install. That is the quick and dirty way without package-management. And without package-management you will have much work removing files later on when you possible install a newer version. Therefore using a clean chroot-environment is the only way forward - as already pointed out multiple times. And for this there is also a way and notes: https://forums.hyperbola.info/viewtopic.php?id=632
Great, thank you, now I have a lot of useful information.
Continuing the search for a program for listening to the radio, I found this option => Pyradio https://github.com/coderholic/pyradio/b … README.md, assembled it on Devuan, everything works (I’m just letting you know, I’m not comparing, don’t scold me)) I had to check it
Didn't find it in the python3-rich repositories
All other packages are available for possible assembly:
Requirements
python 2.7/3.5+ -Ok
python3-setuptools -OK
python3-wheel -Ok
python3-requests -Ok
python3-dnspython -Ok
python3-psutil -Ok
python3-rich -No https://github.com/Textualize/rich
python-dateutil (python3-typeshed) -No
python3-netifaces(optional) -No
MPV, MPlayer or VLC installed and in your path -Ok
You would need to go the whole depedency-tree, as for python-rich: https://archlinux.org/packages/extra/any/python-rich/
Also you can check earlier versions: https://gitlab.archlinux.org/archlinux/ … mmits/main
You can then build every package missing from the one fitting upwards. So you are doing some kind of puzzle-solving.
There are no problems with qtcreator I get an error when I run it in the terminal:
$ qtcreator
qtcreator: symbol lookup error: /usr/bin../lib/qtcreator/libUtils.so.4: undefined symbol: qt_resourceFeatureZstd, version Qt_5Ah, thanks for reporting. So again zstd. Another recompile!
Oh let me explain this a bit more deep: To have a system-base for 0.4 all common packages were added and build including zstd also. So this is nothing Facebook / Meta is repsonsible of. This concrete example is surely our problem and some partly pacman. You know: When setting up a clean chroot nevertheless groups like base are taken into account and zstd was part of this group before 0.4.3. When building all packages are looked at, so packages building on that base include surely zstd.
Concluding: Yes, that is initially our problem here including zstd. But that was and is for having a base. The problem of indirect linking is the issue of the projects also. It should be done explicite instead of implicite. Meaning here: Instead of taking all into account a configuration or build-systems like cmake, meson and others should definite ignore not mentioned or inactive features. Facebook / Meta is offering zstd, sure. But the issue is at the projects not having zstd optional or leaving here a possible alternative. And the fault exactly here is ours. So I surely repair that!
But that is also a concrete example of two issues.
- implicite inclusion without asking by configuration or build-system
- projects not respecting minimalism approach and instead have growing lists of dependencies with every version
Hello Throgh . I tried to build this program radiotray-qt https://github.com/ErikLethDanielsen/radiotray-qt , since all the dependencies are in Hyperbola, and I received this error. Please write when you fix qtcreator, I will try again.
I also wanted to clarify with you (to find out your opinion) about Gajim, it was in version 0.3 https://git.hyperbola.info:50100/packag … y-way-v0.3
I tried to compile it, but the file contains a link to version 16.9, which is not found here https://ftp.debian.org/debian/pool/main/g/gajim/ and here https://gajim.org/downloads/1.6/, would it be difficult for you to tell me which version should be specified in PKGBUILD?
gajim needs Python in version 2 for running in that version. Many of those packages have ceased to exist since then and to recreate is not impossible but also not very easy. You would need to port them all towards Tauthon then.
And again: We have tried gajim and I repeat ... it is not possible to build without D-Bus!
I cannot tell you any version possible to build as gajim is not working without D-Bus and you would need to rebuild that exact older version without any guarantee for more as also the inbound plugin-distribution has ceased to exist for anything older.
qt-creator will not be rebuild until 0.4.5 therefore. But if you insist you can always rebuild it on your own: https://git.hyperbola.info:50100/packag … /qtcreator
It just needs a rebuild and you do it on your own now already. We won't hold a whole release-schedule just for qtcreator as this is not a critical package.
You can surely try, but as I have said: The whole Linux-system is damaged to the ground when you want real independence. It is not working and too many projects demand bloated frameworks. gajim draws a line of many, really many python-packages as dependencies and there is no guarantee that they work the way needed.
HyperForum → System → What programs can I install on Hyperbola?
Powered by PunBB, supported by Informer Technologies, Inc.