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

updated dmtcp major versions #5229

Closed
wants to merge 2 commits into from
Closed

updated dmtcp major versions #5229

wants to merge 2 commits into from

Conversation

bbarker
Copy link
Contributor

@bbarker bbarker commented Dec 5, 2014

The default dmtcp should really be updated to a more recent version, as it is now a major version behind (and more). I'm a nix newbie, but I needed to use this soon so it seemed like a good chance to test out nix-build. So there are a few possible issues:

  • My new --replace commands may or may not be working correctly. Without these, a python expression trying to access $USER (e.g. os.environ['USER']) fails; it seems like USER is not being set correctly in the build environment. I attempted to hardcode it to the first build user for now (I guess this would work if it is possible to disable parallel builds). However, I have not checked that this works correctly because specifying nix-build -A -K dmtcp does not seem to leave the directory around, even though it now fails much later in the check phase.
  • Five out of forty checks will still fail if doCheck = true. I haven't investigated these yet, but dmtcp seems to work well enough in general. I will try to investigate these more. Part of the problem could be I'm running in virtualbox for the moment.

@bbarker
Copy link
Contributor Author

bbarker commented Dec 5, 2014

I just saw #183, which may be considered when updating this package.

@peti
Copy link
Member

peti commented Dec 12, 2014

If the build needs $USER to be defined, then you can do that in the preConfigure hook, i.e. by adding the attribute

preConfigure = "export USER=nobody";

to the expression. Generally speaking, builds should not depend on the name of the user that's running them, IMHO, and I have time imagining what valid use case that script could have for such a check. It might be worthwhile to bring this topic up to the authors.

@vcunat vcunat closed this in d013149 Jan 20, 2015
@vcunat
Copy link
Member

vcunat commented Jan 20, 2015

I believe you tested that the package works. I pushed a squash of this with some fixes of mine (and tested it builds).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants