Descriptors get checked out by AppHarbor with <LF>

[m3dwards]

AppHarbor builds from source which I don't think will work if OpenWrap isn't installed on the build machine. I have tried removing the Symlink folder of openwrap from the wraps directory and copying in the files manually but still got a build error.

Not really sure what the solution would be, it may be that they are not compatible and that's that but thought I would raise it here in-case there is a simple step which I'm missing.

[serialseb]

Nah theres nothing that prevents appharbor from building stuff from openwrap.

The commit should contain /wraps/_.wrap and /wraps/openwrap, and not commit /wraps/__. Then you can point appharbor to any csproj and it will just build.

Can you be more specific with what issue you're seeing?

[m3dwards]

This is what I'm getting https://appharbor-logs.s3.amazonaws.com/c2/fa38eb-8878-4edb-839c-a06e016da0ca/275345.msbuild.txt?AWSAccessKeyId=AKIAJDP3GVM5BQG2W7HA&Expires=1340204654&Signature=CwfSfXUVSbLZKkByyQhzR5M9XD8%3D

For this repo: https://github.com/maxwe789/Todo

[serialseb]

I get an access denied on this

[m3dwards]

http://pastebin.com/m9U4142J

[serialseb]

Ok I debugged it, the files descriptor files themselves ought to be in CRLF line endings, yours seem to me to be in LF. Note also that wraps/_cache should not be committed.
OpenWrap 2.0 tells you about LF as being an error. We could normalize those automatically and relax the parsing rules, but doing it just because git is being stupid about this stuff is quite frustrating. I'm keeping this open till we decide what the best course of action is.

[m3dwards]

I have removed the _cache files from the commit, what are the descriptor
files and how did they get LF endings? Did git cause this?

On Wed, Jun 20, 2012 at 4:33 PM, Sebastien Lambla <
reply@reply.github.com

wrote:

Ok I debugged it, the files descriptor files themselves ought to be in
CRLF line endings, yours seem to me to be in LF. Note also that
wraps/_cache should not be committed.
OpenWrap 2.0 tells you about LF as being an error. We could normalize
those automatically and relax the parsing rules, but doing it just because
git is being stupid about this stuff is quite frustrating. I'm keeping this
open till we decide what the best course of action is.

---

Reply to this email directly or view it on GitHub:
#332 (comment)

[serialseb]

Yes, git messes with line endings, so if you commit files its gonna by default go and turn crlf into lf, which is no good.

Sebastien Lambla

On 20 Jun 2012, at 16:44, "maxwe789" reply@reply.github.com wrote:

I have removed the _cache files from the commit, what are the descriptor
files and how did they get LF endings? Did git cause this?

On Wed, Jun 20, 2012 at 4:33 PM, Sebastien Lambla <
reply@reply.github.com

wrote:

Ok I debugged it, the files descriptor files themselves ought to be in
CRLF line endings, yours seem to me to be in LF. Note also that
wraps/_cache should not be committed.
OpenWrap 2.0 tells you about LF as being an error. We could normalize
those automatically and relax the parsing rules, but doing it just because
git is being stupid about this stuff is quite frustrating. I'm keeping this
open till we decide what the best course of action is.

---

Reply to this email directly or view it on GitHub:
#332 (comment)

---

Reply to this email directly or view it on GitHub:
#332 (comment)

[m3dwards]

Thanks so much for this, I'll look to fix that.

On Wed, Jun 20, 2012 at 4:47 PM, Sebastien Lambla <
reply@reply.github.com

wrote:

Yes, git messes with line endings, so if you commit files its gonna by
default go and turn crlf into lf, which is no good.

Sebastien Lambla

On 20 Jun 2012, at 16:44, "maxwe789" reply@reply.github.com wrote:

I have removed the _cache files from the commit, what are the descriptor
files and how did they get LF endings? Did git cause this?

On Wed, Jun 20, 2012 at 4:33 PM, Sebastien Lambla <
reply@reply.github.com

wrote:

Ok I debugged it, the files descriptor files themselves ought to be in
CRLF line endings, yours seem to me to be in LF. Note also that
wraps/_cache should not be committed.
OpenWrap 2.0 tells you about LF as being an error. We could normalize
those automatically and relax the parsing rules, but doing it just
because
git is being stupid about this stuff is quite frustrating. I'm keeping
this
open till we decide what the best course of action is.

---

Reply to this email directly or view it on GitHub:
#332 (comment)

---

Reply to this email directly or view it on GitHub:
#332 (comment)

---

Reply to this email directly or view it on GitHub:
#332 (comment)

[m3dwards]

Looking at the git documentation it suggests that having "* text=auto" in .gitattributes will change CRLF to LF when stored but will change it back to CRLF on checkout. Is this not happening?

[m3dwards]

I forced it to use CRLF by setting * eol=crlf in the .gitattributes file but this feels dirty because mac and linux users would also get crlf.

Now getting another build problem, any ideas what this one is? http://pastebin.com/Hx5rZcTv

[serialseb]

You should be able to set eol per file type.

Sebastien Lambla

On 20 Jun 2012, at 18:30, "maxwe789" reply@reply.github.com wrote:

I forced it to use CRLF by setting * eol=crlf in the .gitattributes file but this feels dirty because mac and linux users would also get crlf.

Now getting another build problem, any ideas what this one is? http://pastebin.com/Hx5rZcTv

---

Reply to this email directly or view it on GitHub:
#332 (comment)

[serialseb]

No idea. Is that dll committed?

Sebastien Lambla

On 20 Jun 2012, at 18:30, "maxwe789" reply@reply.github.com wrote:

I forced it to use CRLF by setting * eol=crlf in the .gitattributes file but this feels dirty because mac and linux users would also get crlf.

Now getting another build problem, any ideas what this one is? http://pastebin.com/Hx5rZcTv

---

Reply to this email directly or view it on GitHub:
#332 (comment)

[serialseb]

Afaik AppHarbor exports as LF always.

Sebastien Lambla

On 20 Jun 2012, at 18:11, "maxwe789" reply@reply.github.com wrote:

Looking at the git documentation it suggests that having "* text=auto" in .gitattributes will change CRLF to LF when stored but will change it back to CRLF on checkout. Is this not happening?

---

Reply to this email directly or view it on GitHub:
#332 (comment)

[m3dwards]

I think the problem with the .dll was git trying to normalise a binary's line endings.

I updated my gitattributes to tell git that .dll files are not text files, please leave them alone.

( * eol=crlf + *.dll -text )

Now I have another build error... sorry! http://pastebin.com/M6uj9Jmp

[serialseb]

Hmm. I'd recommit the packages, one zip file is obviously invalid.

Sebastien Lambla

On 20 Jun 2012, at 19:38, "maxwe789" reply@reply.github.com wrote:

I think the problem with the .dll was git trying to normalise a binary's line endings.

I updated my gitattributes to tell git that .dll files are not text files, please leave them alone.
*.dll -text

• eol=crlf

Now I have another build error... sorry! http://pastebin.com/M6uj9Jmp

---

Reply to this email directly or view it on GitHub:
#332 (comment)