Skip to content
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

Apple filesystem issues with abuild #21

Closed
clandmeter opened this issue May 24, 2019 · 5 comments
Closed

Apple filesystem issues with abuild #21

clandmeter opened this issue May 24, 2019 · 5 comments
Labels
bug Something isn't working

Comments

@clandmeter
Copy link
Member

When you try to build a package which uses special filesystem features on MacOS abuild with error.
To reproduce one can build bash and it will error.

@mor1
Copy link
Collaborator

mor1 commented May 31, 2019

Have reproduced. Looking into it.

@mor1 mor1 added the bug Something isn't working label Jun 21, 2019
@mor1
Copy link
Collaborator

mor1 commented Jul 12, 2019

This appears to be only with the untarring of the source tarball -- subsequent to that, the package builds just fine (except for some failing tests). Still investigating...

@mor1
Copy link
Collaborator

mor1 commented Jul 12, 2019

Ok. Problem appears to be that the ordering of files in the tarball has the symlink bash-5.0/ChangeLog -> bash-5.0/CWRU/changelog before bash-5.0/CWRU/changelog. Both files appear to be untarred ok, but (presumably) some syscall is invoked to set the utime on bash-5.0/ChangeLog when it's created, before its target exists, and that fails. Subsequent runs do see both files, including a valid symlink and so the utime can be set and everything can build just fine.

Will look into what's actually triggering the Cannot utime error next.

@mor1
Copy link
Collaborator

mor1 commented Jul 12, 2019

Right. This is a result of the tar extraction getting an error on the first run through and the build stopping there. Appears to be when it tries to set the mtime of a symlink whose target does not yet exist. Once the target exists, the build runs to completion.

A hacky workaround for this package might be to create the target by hand during the prepare phase in the APKBUILD, but that's a bit grim. (Or tell abuild to ignore errors during build and carry on regardless?)

I'm following up to see if there's an underlying bug somewhere else.

@mor1
Copy link
Collaborator

mor1 commented Dec 29, 2019

The suspicion is that this is a bug in the D4M filesystem interface code. I didn't manage to track it down, but did speak with a (now ex-) colleague at Docker about it and I understand that there's work in the pipeline that might fix it. Am going to close this issue now as it's out of my hands -- I don't think there's anything I can do to work around it automatically.

@mor1 mor1 closed this as completed Dec 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants