The --get-dependencies switch never solved my problems.
What is the manpower issue? You dont want an “open repository”, open for download: sure. Uploading is different. Register all people, willing to upload. Find a few people willing to test the packages.
Cheers
“find a few people” is the manpower problem. The Haiku project will not do it, their goal is to develop the operating system, not take all the tasks that revolve around it. The OS itself is already enough to keep the few Haiku devs busy for a few dozen years.
If you want to do it, all you need is “a few people” and an HTTP(S) server. I would be very happy to see such an independant repo gain traction as the main source of Haiku software. As a developer of the OS, I could concentrate on the few packages that Haiku actually requires to run, and let other people run the repository for additional software. But so far, there does not seem to be such an “open to anyone” option, only repos run by individuals, each sharing their own packages (or maybe I missed something?).
Have a look at the blog post “Building packages with haikuporter”. I hope that helps. Everyone feel free to comment there with suggestions if there’s anything I can improve.
I would be willing to spend a few $$$$ and test packages that were uploaded, so I am willing to spend time.
Roland, what did you do for GTK? I am spending a little time building veejay and GTK is a dependency.
I also had a glib problem but temporarily solved it by setting 2 shell variables. My build is using configure so that was possible.
Nothing, every try I gave Haikuporter ended in some unsolved issues, like “this recipe has no signature”.
I noticed in the audacity recipe that it has dependencies on an alternative widget set. I can imagine that it works when you replace Gtk. It only makes me wonder, why there is no Gtk on Haiku, because its the mother of all widget sets on Linux.
Because no one has ported it. Porting a widget toolkit is not just running some scripts, it is a big undertaking and requires implementing a lot of things.
Moreover, the goal in Haiku is more to promote native software, rather than ported one, otherwise we would only be an inferior Linux (we can’t fight with the serious Linux distros on their own area). Even our Qt port is a relatively recent addition.
Thats a clear choice and vision 
I completely agree with this strategy. IMHO what sets Haiku apart from the plethora of Linux distros, UIs, toolkits is we have this vision of native software, one native widget set, one native look and feel, etc. etc.
All Haiku devs and many users may agree on preferring native apps - I know I do. But all it takes is someone who ports GTK or whatever, et voilá: potential access to a large set of new ports.
It’s irrelevant if we like it or not. The devs only have an influence on the OS itself, not on the software environment that develops around it. I know I’m stating the obvious.
The fun about Haiku: installing can be done in a few seconds.
I got it working: yeah. A quality check on recipeś would still be nice. mpg123 compiles nice but when you run it: error found no driver out of [dummy] working with the device default. Failure loading driver module.
Compiling code is one thing. A working binary is something different. I would propose that recipe’s can only be posted after they have proven to work with a completely clean install. This way, it works for people that just got started.
You are mixing things up. The things that should work for normal people are not recipes, but pre-built packages. There is a set of packages available in HaikuDepot already. There will be more once we automate the process a little more, and can get it running without draining too much manpower from other tasks.
The recipes are just a way to reliably build the packages. They are meant for developers and it is expected that there is some work needed to get them working. This is continuously improving, but it is a very large undertaking. If we only allowed fully working and tested recipes, people would have no place for their experiments. Putting a failing recipe in the haikuports repository allows to share your work with people and tell them “I went this far, but I don’t know how to go further”.
In order to support this, recipes can be marked as “broken” or “untested”, so people know what they are getting into. Help in quality-checking, however, is welcome: you can report your problems on the haikuports bug tracker.
Roland007, how would it help for mpg123?
It builds and installs just fine, right? There is no audio output plugin yet, but the recipe works just fine. It provides the libs for other programs, so it is ok. If you really need it, you can implement it hovewer: there is plenty example in the haikuports git.
Instead of complaining, you can check and compare the working and the broken recipes. I suppose you just have found an old-old recipe what needs to be updated to current standards.
There are examples, articles and IRC with helpful peoples.
Other side we are trying to keep the main programs in working state and update them, but it takes time and manpower, we cannot provide all your favorite programs without your help. It doesnt involve any magic.
I can understand if you don’t want to invest time and power into it, but then please do not insult the haikuports Team. They are simple humans like me and you.
Please create an issue at github for your problem and somebody will look into it. A “no signature” not enough. Which recipe, which platform, which Haiku version?
Thanks and take care.
miqlas
I am not trying to complain, because I realize its all work-in-progress. I thought, recipe’s were meant to be complete-ready-to-compiler. Well if thats not the case, my error.
Cheers
Okay, no problem, mate
I just looked into mpg123, let’s see, whats going on there:
Let’s see, what could we do here:
The recipe hovewer doesn’t define SDL as REQIRES and BUILD_REQUIRES, so we should add it. As HaikuPorter only can see and use libraries what defined in the recipe, we need to add them, it is not enough just to install them, we need define them in the recipe.:
To the REQUIRES add the following:
lib:libSDL$secondaryArchSuffix
And to the BUILD_REQUIRES add:
devel:libSDL$secondaryArchSuffix
Now make sure you have the SDL (and the devel) package installed for your favorite platform (x86_gcc2 or x86 or x86_64), and let HaikuPorter build it, so write in Terminal:
haikuporter --get-dependecies mpg123
for gcc2 and x86_64, or
haikuporter --get-dependecies mpg123_x86
for x86.
Hopefully it will work now and you will get the hpkg. Sorry, i cannot test and valide it right now, but i will update the recipe in the haikuports at the weekend.
Have fun!
–miqlas
Btw in the mean time you can check the mpd Port. Works nicely.
There is a reason for mpg123 not depending on SDL. It would bring the SDL dependency to all the things that use mpg123, and I think SDL itself uses it in some case (but I could remember wrong).
If adding it, we should make sure that the SDL-specific part is split into a separate package (mpg123_sdl? mpg123_tools?) and that the libraries can be used without the SDL dependency being pulled in.
Thanks! I also tried mpg321 and that works without a hitch. Haikuporter now runs and I can compile stuff.
I remember that mpg123 supports multiple sound back-ends: OSS, AH, SDL.
What would the problem be if SDL were to be a dependency for mpg123? Isnt that an explicit (implicit if the developer doesnt know) choice of the developer?
Just grepped the haikuports tree for the provides what defined in mpg123 recipe, and i cannot find any vital component what depends on mpg123 libs, but there could be an indirect dependency…