Can you reproduce it with a nightly image? Haiku 64-bit | Haiku Files
The repo data for Haiku comes in fact from wasabi, may that be it? Try this one:
curl -vL https://eu.hpkg.haiku-os.org/haiku/r1beta4/x86_64/current/repo.sha256
That redirects me to https://s3.wasabisys.com/haiku-repositories-us/r1beta4/x86_64/r1-beta4_hrev578_92/repo.sha256 to correctly fetch the current hash.
For some reason that redirects me to https://s3.wasabisys.com/haiku-repositories-us/r1beta4/x86_64/r1-beta4_hrev56578_92/repo.sha256 (mind the difference in revision), and that after installing with the latest nighty build iso which is hrev57332.
My mistake for typing instead of copy-pasting. That’s correct. Thing is, did it retrieve the hash or was there some error?
I did install the latest nightly build, but unfortunately there is no change concerning the Haiku repository - it is still unusable right from the beginning. However, things are a lot better otherwise. I can now install whatever package I want from HaikuPorts without issues, something that wasn’t possible before for most packages.
This opened a whole lot of options. I could install all the libraries and apps I needed, and even build some of my own libraries - with very little changes in my Makefiles. Then I realized Haiku has its own way to deal with system directories. If I understand well, I need to make my own Haiku packages, because that seems to be the only way to install my own libraries in system/develop/headers and system/develop/lib (or /boot/system/lib ?). This is quite different than what I am used to from GNU/LInux and BSD but, now that I’m thinking of it, the Haiku’s way makes more sense.
As a first step, I installed some of my own C/C++ and Fortran 2018 libraries in ~/config/non-packaged. All test programs for said libraries worked like a charm. I essentially moved a big part of my development stuff to Haiku pretty easily, and I don’t expect issues for the rest.
Of course, Haiku is its own thing - and that’s good. It certainly looks like Unix in many ways (especially BSD I’d say) but it is also very different in other ways, so there is a lot to learn.
All in all, I’m impressed how snappy the system is (even with a USB stick installation), and how far I went finding my way in Haiku in just two days. It certainly justified a proper installation in a SSD partition and further maintaining of the installation.
Thank you all for your support. But beware, I’m sure I will have more questions in the future, because like I said there is a lot to learn. 
Be sure you have a new user and advocate.
9 Likes
The biggest change in here is how PREFIX is setup, in most linux’s you find it posting to /usr/local or the like, in Haiku this points to /boot/system, so for anything using --prefix= --libdir= you can Haiku’s equivelants in recipes like --prefix=$prefix --libdir=$libDir etc, when using configure there is a tool called runConfigure that sets this up for you without having the need to mention them in the recipe one by one.
For makefiles this would be PREFIX=$prefix etc …
And for cmake projects there is $cmakeDirArgs …
EDIT: @Pap this is when you are working with haikuporter to create packages for your sources, from Terminal it would be enough to use make PREFIX=/boot/home/config/non-packaged or something like ./configure --prefix=/boot/home/config/non-packaged
I think @madmax is onto something here. Could be a regional fluke on S3 services?
@Pap, if you’re still having this issue, please try:
curl -vL https://eu.hpkg.haiku-os.org/haiku/r1beta4/x86_64/current/repo.sha256
and if that works, do:
curl -vL https://s3.wasabisys.com/haiku-repositories-us/r1beta4/x86_64/r1~beta4_hrev56578_92/repo.sha256
adjusting that URL to match with the output you got from the first curl.
I get c42ce52dec8d3a304126bf23e019056f850c1fdc6738e829c9d075b42bf8b62b from the last command (after removing the verbose parts, of course :-D).
Hi, @BiPolar, thank you for the hint. The first curl command doesn’t seem to like wasabisys:
~> curl -vL https://eu.hpkg.haiku-os.org/haiku/r1beta4/x86_64/current/repo.sha256
* Trying 206.189.242.242:443...
* Connected to eu.hpkg.haiku-os.org (206.189.242.242) port 443 (#0)
....
* Connection #0 to host eu.hpkg.haiku-os.org left intact
* Issue another request to this URL: 'https://s3.wasabisys.com/haiku-repositories-us/r1beta4/x86_64/r1~beta4_hrev56578_92/repo.sha256'
* Could not resolve host: s3.wasabisys.com
* Closing connection 1
curl: (6) Could not resolve host: s3.wasabisys.com
So it looks like a DNS problem. Do you know what DNS provider you’re using? You can change them in Network preferences, maybe try removing the ones that are there, and add addresses from OpenDNS for example: https://use.opendns.com/ or pick something from a list like https://public-dns.info/
Then see if the curl error goes away or changes, and once that error is gone, try the pkgman commands again
1 Like
Success! 
I changed DNS using the ones from OpenDNS, then curl succeeded. Also, updating the system finally sees the Haiku repo for the first time:
~> pkgman update
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done. //THIS!
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
Nothing to do.
Just to be sure, I installed haiku_extras (which is available from Haiku repo) and it worked.
It is the first time I had to do something like that, however. And it’s clearly not a Haiku issue, as the curl command fails even on my GNU/Linux daily driver. For some weird reason, wasabisys.com really dislikes my original DNS. I’ve never seen something like that before.
Thank you all for the valuable help! Now time to go back learning more about the Haiku API.
5 Likes
Not that wasabisys dislikes your provider DNS, but the inverse. Here, with Telefonica provided lines, we also have to use google´s DNS or many sites will “not exist” or fail randomly.
Some DNS servers will filter out some websites, sometimes for legal reasons (in some countries there are laws that allow the state to ask them to do so, it can pe used to block illegal content, but what is blocked is more or less wide depending on the country), sometimes because they decide to do their own filtering (to block malware for example).
Since wasabisys is a CDN and serve files for many things, itws possible some malware or illegal file was found being distributed through their servers and so they were blocked.
If we had more mirrors, you could have just tried another one (and we could use DNStricks to do that automatically, I think?), but currently, we don’t have signature verification on packages, so we don’t want to deploy mirrors without that integrity check in place.
Just a random suggestion,seeing that some people unfortunately still use Google services 
There are many public and free DNS services nowadays that don’t spy on you.
Some even make sure that advertising and tracker domains “don’t exist” by filtering out all the evil stuff.
I can’t recommend Dismail DNS or AdGuard enough in that context:
- Dismail.de DNS is hosted in Germany,logs nothing and discloses which filter lists they use: Service Info | dismail.de
- AdGuard is bigger and so probably more failsafe,they also don’t log IP addresses but “other metrics”,still thousand times better than Google: Connect to public AdGuard DNS server
Or if you don’t care about ads and trackers on the internet,there’s Quad9 which provides unfiltered DNS (except for malware) and also doesn’t log IPs and is based in the European Union,so the GDPR applies to them: https://quad9.net
2 Likes
Seems you mention it because of my statement about using google dns ?
While I understand that they are not that “good”, and will probably try those you suggested, not every situation can be solved by those. Many people here use the Telefonica DNSs, and it is hard to diagnose problems ( well, after we got used to the problem being their dns servers, we just instruct people to try google´s. If things work then, it is obvious to people where the problem is ).
But using other dns or search sites sometimes not help. I´ve tried, and most times, duckduckgo doesn´t return the site I want ( and google does ) . For some not-so-important things, one can be exigent, but sometimes we just need something to work correctly. A search engine that doesn´t search correctly ( for some definition of search ) is not useful. Same as a dns server, if one cannot trust it to return the correct site´s address. how would I know if the site exists ?
( i mean normal sites, technical blogs, development ones, etc. You try to open the link in a forum post, it doesn´t exist. Change dns, it magically appears. ) .
I find a pi-hole using google dns´s works ok for ads, and brings the benefit to work for the entire network without needing to add browser extensions.
I totally understand your situation,but you can simply use and instruct people to use 9.9.9.9 instead of 8.8.8.8.
Things will also just magically start to work then,but without giving up on privacy.
While there are differences in search result quality for sure,there are absolutely no quality differences when it comes to big public DNS resolvers.
2 Likes
As I said, I will try those providers you suggested. But I mean that , if the google ones provide better results, even if some people would dislike using them, it ends up being better.
I don´t mean for the kind of people that prefer browsers without javascript, but for those users that just want to use their computer on the internet, and that will not listen or understand about this “google is bad” thing. For most people, “internet == google”. Same as people that do not understand the whatsap is not the unique communication means possible.