-
-
Notifications
You must be signed in to change notification settings - Fork 5.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
Pkg.add("ParallelAccelerator") results in dirty state #17610
Comments
I've noticed the executable bit keeps getting set on some files. Does this show up in GitHub PRs and I'm just not noticing? (Very likely.) Or is it from someone pushing straight to master? Of relevance for using this as a test case, I just unset the executable flag in all Images.jl files (sorry). I'm tempted to use |
It does show up in PR's, ref https://github.com/timholy/Images.jl/pull/516/files#diff-af28e1ea7bb1f554f483a8671aab187b - so if you make a new tag this might not be the best test case any more, but we could do |
I am on the verge of tagging a new Images, but as you say the previous version should work as a test case. |
@wildart I suspect this is a libgit2 bug with executable permissions. |
I'm not sure, but I use default settings for checked out files: Lines 109 to 110 in c389aa3
|
How do we track down where in either libgit2 at the C level or in our bindings this is going wrong? Having packages not be updatable or removable (without manual fixes first) if they have any executable files in them would be pretty bad. |
|
yeah we can put in place fixes for packages where we know this is happening if they don't actually need the executable bits, but for miscellaneous scripts etc it may help to have the ability to do so without things going wrong. not a bad theory that it might be cache (bare clone) related. |
Cache is not a problem. Apparently, something funny is going when checking out particular commit. Because another file |
As I've made additional commits I've unset executable bits in Images, so it might be me doing the unsetting. I am sure I am not doing the setting, but I am not the only one contributing to that repo. |
Well, you already committed |
Maybe I pulled someone else's branch and then pushed? If it would help to debug, I can try to figure it out. Which commit turned it on? (The commit linked by @tkelman above was me turning it off.) |
It's probably the good thing that this happened, cause the bug was found. No need for further investigation, I can reproduce it. |
thank pkgeval - very strange versions being tested or failing to install wound up due to requirements conflicts happening because of this bug |
@wildart where in libgit2 do file permissions get handled? |
Still investigating, it's not trivial It looks like upstream problem. |
Any update here? Not absolutely release blocking but would be ideal to fix before final if we can. |
The original test case doesn't cause this at the moment, but ParallelAccelerator does:
This is a really nasty bug that causes packages to be dirty as soon as they're installed, so they never get updated again until the user notices the problem. |
fixed by #20916 |
Apparently this one was happening on Windows, interestingly enough. |
Due to one of the files having executable permissions in git, but something wrong happening with the libgit2 clone or checkout. The executable permissions are removed in the working copy, and strangely that change is staged? The package being dirty is very bad, as it means Pkg won't upgrade or remove it unless you go in and manually reset the change.
The text was updated successfully, but these errors were encountered: