Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#7235 - Pacman Locale Problem
Attached to Project:
Pacman
Opened by Alper Kanat (T-u-N-i-X) - Tuesday, 22 May 2007, 13:14 GMT
Last edited by Dan McGee (toofishes) - Saturday, 09 June 2007, 16:16 GMT
Opened by Alper Kanat (T-u-N-i-X) - Tuesday, 22 May 2007, 13:14 GMT
Last edited by Dan McGee (toofishes) - Saturday, 09 June 2007, 16:16 GMT
|
DetailsPacman has again problem with the Turkish locale. It can't parse pacman.conf file.. I'm using tr_TR.UTF-8 when it doesn't work.. If I set it to C locale, it works successfully..
A few months ago, there has been the same problem which I have again reported.. It was solved with the next minor release.. |
This task depends upon
Closed by Dan McGee (toofishes)
Saturday, 09 June 2007, 16:16 GMT
Reason for closing: Fixed
Additional comments about closing: (inadvertently) fixed in 3.1
Saturday, 09 June 2007, 16:16 GMT
Reason for closing: Fixed
Additional comments about closing: (inadvertently) fixed in 3.1
http://bugs.archlinux.org/task/6755
debug: config: new section 'options'
debug: returning error 54 from alpm_parse_config : syntax error in config file
error: failed to parse config (syntax error in config file)
LogFile = /var/log/pacman.log
original_key = "LogFile"
key = "LOGFILE" (uppercase of original_key)
if original_key == "LogFile" or key == "LOGFILE"
... carry on ...
the uppercase version will fail in the turkish locale, but the proper-cased version should not - and this did fix it before, correct?
Hmmm, perhaps this change was lost somewhere in the shuffle... I will check.
#
# GENERAL OPTIONS
#
[options]
LogFile = /var/log/pacman.log
HoldPkg = pacman glibc
.....................
$ locale
LANG=tr_TR.UTF-8
LC_CTYPE="tr_TR.UTF-8"
LC_NUMERIC="tr_TR.UTF-8"
LC_TIME="tr_TR.UTF-8"
LC_COLLATE=C
LC_MONETARY="tr_TR.UTF-8"
LC_MESSAGES="tr_TR.UTF-8"
LC_PAPER="tr_TR.UTF-8"
LC_NAME="tr_TR.UTF-8"
LC_ADDRESS="tr_TR.UTF-8"
LC_TELEPHONE="tr_TR.UTF-8"
LC_MEASUREMENT="tr_TR.UTF-8"
LC_IDENTIFICATION="tr_TR.UTF-8"
LC_ALL=
$ pacman -Ss asm
current/nasm 0.98.39-1
80x86 assembler designed for portability and modularity
extra/libgnomecanvasmm 2.16.0-2
A C++ wrapper for libgnomecanvas.
extra/rasmol 2.7.3-2
A program for molecular graphics visualisation (aka openrasmol)
community/yasm 0.6.0-1
Yasm is a complete rewrite of the NASM assembler designed from the ground up to allow for multiple assembler syntaxes to be supported (eg, NASM, TASM, GAS, etc.)
I can't duplicate this bug after setting my locale, so this is real hard to debug for me. I'm running 3.0.4-3.
Index: lib/libalpm/alpm.c
===================================================================
RCS file: /home/cvs-pacman/pacman-lib/lib/libalpm/alpm.c,v
retrieving revision 1.128
diff -u -r1.128 alpm.c
--- lib/libalpm/alpm.c 4 Apr 2007 03:59:36 -0000 1.128
+++ lib/libalpm/alpm.c 8 Jun 2007 21:14:19 -0000
@@ -939,7 +939,7 @@
RET_ERR(PM_ERR_CONF_BAD_SYNTAX, -1);
}
_alpm_strtrim(key);
- strncpy(origkey, key, min(255, strlen(key)));
+ strncpy(origkey, key, min(255, strlen(key)+1));
key = _alpm_strtoupper(key);
if(!strlen(section) && strcmp(key, "INCLUDE")) {
RET_ERR(PM_ERR_CONF_DIRECTIVE_OUTSIDE_SECTION, -1);
toofishes fixed it when moving parseconfig from alpm to the client :
http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commitdiff;h=65662315b6d180f7066f6578c55a9feec7250114#patch3
Now it's : upperkey = strtoupper(strdup(key));