On 5/14/07, Andrew Fyfe wrote:

Dan McGee wrote:

...

Date: Monday, April 16, 2007 @ 23:56:52 Author: dan Path: /home/cvs-pacman/pacman-lib/scripts

Modified: makepkg (1.69 -> 1.70)

makepkg: unset one more language variable

<snip>

...

# some applications (eg, blackbox) will not build with some languages - unset LC_ALL LANG + unset LC_ALL LC_MESSAGES LANG umask 0022

I don't like this fix/hack, why was LC_MESSAGES added, other than blackbox what breaks when LC* is set? These should really be unset in the PKGBUILDs effected and the problem reported upstream.

Is blackbox the only violator? We don't even support it anymore, and I tend to agree with you that this is a nasty hack- software should be able to build with any language. Other opinions? I'm all for removing this whole languages unsetting thing; it can be done in the offending PKGBUILDs if necesssary. -Dan

On 5/14/07, Roman Kyrylych wrote:

2007/5/14, Dan McGee :

...

On 5/14/07, Andrew Fyfe wrote:

...

Dan McGee wrote:

...

Date: Monday, April 16, 2007 @ 23:56:52 Author: dan Path: /home/cvs-pacman/pacman-lib/scripts

Modified: makepkg (1.69 -> 1.70)

makepkg: unset one more language variable

<snip>

...

# some applications (eg, blackbox) will not build with some languages - unset LC_ALL LANG + unset LC_ALL LC_MESSAGES LANG umask 0022

I don't like this fix/hack, why was LC_MESSAGES added, other than blackbox what breaks when LC* is set? These should really be unset in the PKGBUILDs effected and the problem reported upstream.

Is blackbox the only violator? We don't even support it anymore, and I tend to agree with you that this is a nasty hack- software should be able to build with any language.

Other opinions? I'm all for removing this whole languages unsetting thing; it can be done in the offending PKGBUILDs if necesssary.

Seems fair to me. +1 for removal that unsetting thing completely.

Agreed. Keeeeeel eeet!

On Mon, May 14, 2007 at 11:41:17AM -0400, Dan McGee wrote:

On 5/14/07, Aaron Griffin wrote:

...

On 5/14/07, Roman Kyrylych wrote:

...

2007/5/14, Dan McGee :

...

On 5/14/07, Andrew Fyfe wrote:

...

Dan McGee wrote:

...

Date: Monday, April 16, 2007 @ 23:56:52 Author: dan Path: /home/cvs-pacman/pacman-lib/scripts

Modified: makepkg (1.69 -> 1.70)

makepkg: unset one more language variable

<snip>

...

# some applications (eg, blackbox) will not build with some languages - unset LC_ALL LANG + unset LC_ALL LC_MESSAGES LANG umask 0022

I don't like this fix/hack, why was LC_MESSAGES added, other than blackbox what breaks when LC* is set? These should really be unset in the PKGBUILDs effected and the problem reported upstream.

Is blackbox the only violator? We don't even support it anymore, and I tend to agree with you that this is a nasty hack- software should be able to build with any language.

Other opinions? I'm all for removing this whole languages unsetting thing; it can be done in the offending PKGBUILDs if necesssary.

Seems fair to me. +1 for removal that unsetting thing completely.

Agreed. Keeeeeel eeet!

Done locally, and I'm merging most of Andrew's fakeroot patches now.

Is it just me, or does GIT provide no easy way to sign off on a pulled branch? I'm looking at each patch as I go, and I wanted to sign off but it seems this is not a normal thing to do. Anyone that has figured this out, let me know.

-Dan

My understanding is that a git pull can't modify patches. Signing off on a patch modifies it. git-am can signoff for sure. Jason

On Mon, May 14, 2007 at 08:02:29PM -0400, Dan McGee wrote:

On 5/14/07, Jason Chu wrote:

...

On Mon, May 14, 2007 at 11:41:17AM -0400, Dan McGee wrote:

...

Is it just me, or does GIT provide no easy way to sign off on a pulled branch? I'm looking at each patch as I go, and I wanted to sign off but it seems this is not a normal thing to do. Anyone that has figured this out, let me know.

-Dan

My understanding is that a git pull can't modify patches. Signing off on a patch modifies it. git-am can signoff for sure.

Jason

Yeah, I wasn't looking so much for it on the git-pull, but things like git-rebase actually modify the patches. Why isn't there some sort of git-rebase --sign <branch> ?

-Dan

I think it's because the sign off was created to track patches as they pass through mailboxes. Once something is in a git repo, a git pull already has the name of the person who commited it. Applying that logic, git rebase just applies patches onto a different head, so it doesn't make sense to sign-off them. The author stays the same. Jason