-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build error for nim-git #17907
Comments
I've left a comment on the |
OK, So I tried:
which looked OK until: Now that is caused by this line: and the reason for that is because build.sh in csources_v1 lacks executable permissions, so I wonder if that should be changed in csources_v1, or whether the PKGBUILD should simply chmod it first? But you would sort of expect a file called build.sh to be an executable script I suppose. |
You can just call the shell interpreter to run the script: |
Yes, certainly, but the file permissions have changed from the last version:
So if that's left unchanged then every other distro's build scripts are going to encounter this. It just looked like an oversight unless it's been done deliberately for some reason. (Windows doesn't use this sort of permission so some people might not have seen this.) |
This seems to build and work, also I've noticed recent versions of nim-git seem to lack nimfind too, at least the PKGBUILD can't find it:
So I got nim-git-1:1.4.6.r1281.78e2d299d-1-x86_64.pkg.tar.xz which now causes a new Pakku toHashSet build error! |
I also encountered this when using |
the portable way to build nim from sources from any version moving forward is:
this allows forward/backward compatibility and building nim from source from any version moving forward even if csources repo/url/hash gets updated in the future anything else is an implementation detail subject to change, in particular this is not future proof:
because is there a way you can you one of those 2 approaches? if not, what is missing, so that we can add support for it? links |
Using git submodules might allow you to link to other repos in a more flexible way: |
using submodules for that in nim repo has been discussed before several times and rejected, you can search for it in github issues |
it seems like this issue should belong in |
Unless I am experiencing Git user problems HEAD on this repo has been changed to an older commit: |
well the problem will resurface once you update the commit to a newer one. there are a few things in https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nim-git that IMO should be changed if you want it to keep working with future nim versions. I see you're avoiding if so, at least start from this:
which defines (for now) those variables:
then you can use those urls/hashes to at least build the correct version of csources (more future proof) other than this, ok to close this issue since it looks like nim-git specific? (unless you have a specific suggestion for adding other APIs to |
Great! So I am not the only one facing this issue. I was finally finding some time to fix my long broken nim devel builds on Travis. I thought my workaround for #15843 would work, but now am gated by this same error there: travis fail log |
Thanks for this tip by @timotheecour in nim-lang/Nim#17907 (comment).
I wasn't using them out of ignorance, honestly. I've updated the PKGBUILD using the suggestions you've provided: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nim-git |
i see you're now using:
up to you but config/build_config.txt is meant to be source-able, so that you can instead use: . config/build_config.txt
hash=$nim_csourcesHash or similar |
Sourcing PKGBUILD's was one of the reasons yaourt was deprecated, it's best avoided for security reasons, also other practical reasons like name space collisions or other unforseen accidental stuff: |
how about: local -r hash="$(grep 'Hash' config/build_config.txt | grep -Eio '[0-9a-z]{40}')" that way if other hash are later added, it'll still work |
Building nim-git with Pakku just now resulted in this, tried with a recent nim-git also a 1.4 release.
Possibly related to
3192995
#16646
(It builds OK at the previous commit)
The text was updated successfully, but these errors were encountered: