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
---------+ makepkg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Index: pacman-lib/scripts/makepkg diff -u pacman-lib/scripts/makepkg:1.69 pacman-lib/scripts/makepkg:1.70 --- pacman-lib/scripts/makepkg:1.69 Mon Apr 16 21:49:06 2007 +++ pacman-lib/scripts/makepkg Mon Apr 16 23:56:52 2007 @@ -881,7 +881,7 @@ msg "Starting build()..."
# some applications (eg, blackbox) will not build with some languages - unset LC_ALL LANG + unset LC_ALL LC_MESSAGES LANG umask 0022
# ensure CFLAGS and CXXFLAGS are used
Dan McGee wrote:
Date: Monday, April 16, 2007 @ 23:56:52Author: 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.
Andrew
On 5/14/07, Andrew Fyfe andrew@neptune-one.net wrote:
Dan McGee wrote:
Date: Monday, April 16, 2007 @ 23:56:52Author: 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
2007/5/14, Dan McGee dpmcgee@gmail.com:
On 5/14/07, Andrew Fyfe andrew@neptune-one.net wrote:
Dan McGee wrote:
Date: Monday, April 16, 2007 @ 23:56:52Author: 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.
On 5/14/07, Roman Kyrylych roman.kyrylych@gmail.com wrote:
2007/5/14, Dan McGee dpmcgee@gmail.com:
On 5/14/07, Andrew Fyfe andrew@neptune-one.net wrote:
Dan McGee wrote:
Date: Monday, April 16, 2007 @ 23:56:52Author: 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 5/14/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 5/14/07, Roman Kyrylych roman.kyrylych@gmail.com wrote:
2007/5/14, Dan McGee dpmcgee@gmail.com:
On 5/14/07, Andrew Fyfe andrew@neptune-one.net wrote:
Dan McGee wrote:
Date: Monday, April 16, 2007 @ 23:56:52Author: 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
On Mon, May 14, 2007 at 11:41:17AM -0400, Dan McGee wrote:
On 5/14/07, Aaron Griffin aaronmgriffin@gmail.com wrote:
On 5/14/07, Roman Kyrylych roman.kyrylych@gmail.com wrote:
2007/5/14, Dan McGee dpmcgee@gmail.com:
On 5/14/07, Andrew Fyfe andrew@neptune-one.net wrote:
Dan McGee wrote:
Date: Monday, April 16, 2007 @ 23:56:52Author: 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 5/14/07, Jason Chu jason@archlinux.org 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
On Mon, May 14, 2007 at 08:02:29PM -0400, Dan McGee wrote:
On 5/14/07, Jason Chu jason@archlinux.org 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
pacman-dev@lists.archlinux.org