gitea: 1.5.1 -> 1.5.2 #48128
gitea: 1.5.1 -> 1.5.2 #48128
Conversation
|
Maintainer: @disassembler |
|
@GrahamcOfBorg build gitea |
|
Failure on aarch64-linux (full log) Attempted: gitea Partial log (click to expand)
|
|
Unexpected error: command failed with exit code 1 on x86_64-darwin (full log) Attempted: gitea Partial log (click to expand)
|
|
aarch64 failure looks like a builder issue, we can try again later. |
|
Success on x86_64-linux (full log) Attempted: gitea Partial log (click to expand)
|
c0bw3b
added
1.severity: security
9.needs: port to stable
|
@GrahamcOfBorg build gitea |
|
Unexpected error: command failed with exit code 1 on x86_64-darwin (full log) Attempted: gitea Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: gitea Partial log (click to expand)
|
|
Failure on aarch64-linux (full log) Attempted: gitea Partial log (click to expand)
|
|
builds fine on aarch64 when issued with @NixOS/darwin-maintainers Any idea why @ElvishJerricco posted the following on IRC: |
|
My first guess is that it's due to macOS's case sensitive file system, but I haven't confirmed that the repo actually has any collisions. |
|
Doesn't appear to have obvious case collisions on this macOS, so I'm not sure why it fails. Furthermore, I'm on macOS, and: I'm not running a case-sensitive filesystem so I'm puzzled. |
|
@ElvishJerricco I can't get the other store path, but perhaps you can unpack and diff the two trees on your linux box? |
Maybe something unicode related? I'm on sierra, if that matters. |
|
Ah yes, some of the unicode normalization of combining pairs (whether to store them as two characters or one) behavior can be weird. Not really sure what to do about that, other than to add a |
|
@copumpkin @ElvishJerricco does any of you have the time to implement test it? I do not have a Mac to test it and never used one. Would probably take me 10x just to figure that out with always going through ofBorg 😕 |
|
Here is a previous occurrence of the same issue. If subdirs vendor and integrations are not necessary to the build process, then you can do: src = fetchFromGitHub {
owner = "go-gitea";
repo = "gitea";
rev = "v${version}";
sha256 = "<hash>";
extraPostFetch = "rm -rf $out/integrations && rm -rf $out/vendor";
}; |
|
@c0bw3b you'll need to update the sha256 there. |
|
Yes indeed that hash needs to be re-computed. I edited the code block. |
|
Thank you all for taking a look at this, I was really lost at how it could possibly be the case that MacOS computes a different checksum than on Linux. As one could expect from their names, I just verified that For further testing / discussion, I pushed a new version with a extraPostFetch that deletes offending files and still seems to work for me. Some kind of automatic mechanism in the fetch function would still help though, so that this won't return on the next release, and |
|
Could someone with the appropriate permissions please trigger a |
|
@GrahamcOfBorg build gitea |
|
Failure on aarch64-linux (full log) Attempted: gitea Partial log (click to expand)
|
|
Works fine on my mac. |
|
Success on x86_64-darwin (full log) Attempted: gitea Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: gitea Partial log (click to expand)
|
|
Thanks! 😃 |
samueldr
removed
the
9.needs: port to stable
Motivation for this change
https://blog.gitea.io/2018/10/gitea-1.5.2-is-released/
“This is a smaller release, with only 12 merged PRs, but it contains several security related fixes and so we recommend upgrading whenever possible.”
Should therefore be safe to backport to 18.09, and required to get the security fixes.
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)