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 <
[email protected]

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" [email protected] 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 <
[email protected]

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 <
[email protected]

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" [email protected] 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 <
[email protected]

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" [email protected] 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" [email protected] 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" [email protected] 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" [email protected] 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)

[m3dwards]

Recommitted and it builds!!! I am super happy with this. What pain git has caused, I'm sorry you got lumbered with debugging it.

This is my .gitattributes file I'm using http://pastebin.com/dPrqgsik

I wonder if just telling git not to change any line endings would be better. I just like the idea that I can jump into mac and use MonoDevelop with git to pull in the files and have them left with LF. Why can't the world just agree on one way to have a new line?!

To answer your previous question about how OpenWrap should behave I would just be done with it and accept LF as well as CRLF. Defensive programming and all. It's stupid but git exists and is popular so you know this isn't the last time this will rear its ugly head.

[serialseb]

You may be right, I'll keep this open so we can relax the rules.

Sebastien Lambla

On 20 Jun 2012, at 20:14, "maxwe789" [email protected] wrote:

Recommitted and it builds!!! I am super happy with this. What pain git has caused, I'm sorry you got lumbered with debugging it.

This is my .gitattributes file I'm using http://pastebin.com/dPrqgsik

I wonder if just telling git not to change any line endings would be better. I just like the idea that I can jump into mac and use MonoDevelop with git to pull in the files and have them left with LF. Why can't the world just agree on one way to have a new line?!

To answer your previous question about how OpenWrap should behave I would just be done with it and accept LF as well as CRLF. Defensive programming and all. It's stupid but git exists and is popular so you know this isn't the last time this will rear its ugly head.

---

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