buildscripts fail (404) requesting these files from download.devkitpro.org about buildscripts HOT 7 CLOSED

The best way to obtain the ancillary files and indeed the rest of the libraries we supply is via pacman - the devkitPPC package doesn't contain devkitppc-rules but rather has it as a dependency. devkitPro-pacman should really be buildable as is on FreeBSD. Pacman won't replace your system package manager, we use it simply to maintain the packages we distribute within /opt/devkitpro (some 276 packages in all).

If you're willing to help sort out building pacman for FreeBSD we can sort out toolchain packages fairly easily.

from buildscripts.

Please excuse the churn, dropped my phone.

from buildscripts.

I too am building on FreeBSD. I can use pacman, mostly just for the libraries so I don't have to build all the things from scratch. Unfortunately, I do need to build the toolchains myself.

@WinterMute: You should really move away from self hosting these kind of things. For one, it technically adds a little layer of concern, for example: what if the downloads server got hacked? Of course for pacman this isn't a biggy, but for these archives it is since there isn't any protection in place. Also all the issues here are just 404's..... just point to the archives themselves, those are generally designed to always be up (as least stay up longer than your packages tend to)

Call my bluff, but part of me is somewhat skeptical of this project. Why do the latest releases result in 404's anyway? You mention many times that you encourage everyone to use the binary packages, even when the 404's occur and I can't see any other reason other than manual deletion of the archives from the download server. Sorry for the extreme jump of skepticism, but even the whole trademarking stuff has always left me on the edge whenever I use this project. I'm sure you probably also have no harmful intent and you indeed work very hard on providing all these binaries, but overall you can see why it leads me to such a blind conclusion. You draw people away from building manually quite a lot, but some people really do like building and may need to build if they want to provide, say, *BSD or Slackware ports of software which fetch and do the magic on their own.

If English isn't your native language I think I can understand and I apologies, but the way everything is worded regarding this project, even the wiki, is very harsh against building these tools and instead encouraging people to use binaries themselves. People will always be skeptical of binary packages from very small communities, and most tend to trust their (linux) distributions more. I'm probably not the only person who always seems skeptic

from buildscripts.

These files aren't missing

--2023-10-29 09:38:01--  http://downloads.devkitpro.org/devkitppc-rules-1.1.2.tar.gz
Resolving downloads.devkitpro.org (downloads.devkitpro.org)... 104.21.2.51, 172.67.128.184, 2606:4700:3033::ac43:80b8, ...
Connecting to downloads.devkitpro.org (downloads.devkitpro.org)|104.21.2.51|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://downloads.devkitpro.org/devkitppc-rules-1.1.2.tar.gz [following]
--2023-10-29 09:38:01--  https://downloads.devkitpro.org/devkitppc-rules-1.1.2.tar.gz
Connecting to downloads.devkitpro.org (downloads.devkitpro.org)|104.21.2.51|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github.com/devkitpro/devkitppc-rules/archive/refs/tags/v1.1.2.tar.gz [following]
--2023-10-29 09:38:01--  https://github.com/devkitpro/devkitppc-rules/archive/refs/tags/v1.1.2.tar.gz
Resolving github.com (github.com)... 140.82.121.4
Connecting to github.com (github.com)|140.82.121.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/devkitPro/devkitppc-rules/tar.gz/refs/tags/v1.1.2 [following]
--2023-10-29 09:38:01--  https://codeload.github.com/devkitPro/devkitppc-rules/tar.gz/refs/tags/v1.1.2
Resolving codeload.github.com (codeload.github.com)... 140.82.121.9
Connecting to codeload.github.com (codeload.github.com)|140.82.121.9|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1717 (1.7K) [application/x-gzip]
Saving to: ‘devkitppc-rules-1.1.2.tar.gz’

devkitppc-rules-1.1.2.tar.gz            100%[=============================================================================>]   1.68K  --.-KB/s    in 0s      

2023-10-29 09:38:02 (4.28 MB/s) - ‘devkitppc-rules-1.1.2.tar.gz’ saved [1717/1717]```

from buildscripts.

@nekobbbbbbit Clearly 404s on latest sources are because we haven't uploaded them yet.

All the packages are signed and pacman checks these signatures.

We discourage people from building manually and providing anything that "does the magic on their own" because it results in outdated and/or broken tools which are of course detrimental to our users. There are endless projects out there with instructions to install old toolchains and libraries over the top of existing installations which ultimately results in people not being able to build anything at all. We hear about this eventually but often the users affected don't have the experience to understand why everything is broken and blame us.

Your cynicism is misdirected.

from buildscripts.

@WinterMute I was quite tired last night, I apologize for the cynicism, i probably sounded a bit schizophrenic. But anywhom, you didn't dispute my claims here properly

These files aren't missing

That packages missing for me were a binutils, using the latest release of this buildscripts

All the packages are signed and pacman checks these signatures.

Not the package here though. I'm not sure whats happening but v41 binutils kept failing to fetch with a 404, even through a web browser.

because it results in outdated and/or broken tools which are of course detrimental to our users.

Please explain to me how this happens when i just want to build the compiler. Do you think that people who compile manually aren't prolific enough to handle any "updates" on their own?

You do realize I can theoretically still use Pacman (which helps me stay up to date on packages) without breaking trust or builds since im only downloading libraries I need, plus while still linking using my compiler that devkit pacman provides?

What is a user to you? I can probably understand that when working in the homebrew dev field you have lots of people who probably couldn't, say, build or relocate a tool chain on their own and just want to make a little game. But at the same time, you have a convenient solution for said users, I don't see why you should be against manual buildings

Anyway I don't want to slapfight, I have some advice for you maybe to clear this and such cases up:

1. For advice, I would instead word "discouraging" messages about building toolchains to instead say "FOR EXPERTS ONLY", or something like that. This is fairly commonly done with these sort of projects. Don't pull people away from building manually, just hint that support isn't provided at all. For systems like *BSD and maybe nicher systems people use for fun, this message should be very clear. (I'd personally love to work with you for providing FreeBSD and OpenBSD packages though, if you'd like)
2. Don't point tar archives to your downloads archive, in fact, never do that unless you're certain a package will or is dead. Instead, point to the GNU servers. You're only asking for more 404 issues and possible security issues (these are NOT signed)

from buildscripts.

As I said earlier "Clearly 404s on latest sources are because we haven't uploaded them yet."

This issue is reporting problems with devkitppc-rules-1.1.2.tar.gz which aren't missing. It's not appropriate to hijack this issue for other files and other problems you may have with how we distribute our binaries.

Do you think that people who compile manually aren't prolific enough to handle any "updates" on their own?

We've being doing this for.a while now. We know users who insist on building manually & opening issues here will often cause issues down the line. They all think they're experts. We don't have the time or energy to help them with the 101 issues people encounter while building and while using binaries they've built themselves.

GPL requires we keep our own copies of the source we use.

We aren't interested in spending our time arguing about this. It takes time away from other, more productive things.

from buildscripts.