Created attachment 512119 [details] error message (Traceback) Description of problem: When I try to remove dasher by giving the command "sudo yum remove dasher" while the system language is set to Turkish, it gives a bunch of errors and doesn't remove the application. However, it is removed successfully when I change the system language to US English. Version-Release number of selected component (if applicable): Package Arch Version ============================================== dasher x86_64 4.10.1-3.fc15 How reproducible: Every time. Steps to Reproduce: 1. Install dasher 2. Set system language to Turkish 3. Try to remove dasher Actual results: Application removal unsuccessful. Expected results: Should be successfully removed. Additional info: The same behaviour applies also other packages. Maybe the source of error is yum?
Wow, yeh, using: % LANG=tr_TR.UTF-8 sudo yum rm <anything> ...results ins: File "/usr/lib/python2.7/site-packages/yum/history.py", line 821, in beg self.trans_with_pid(pid) File "/usr/lib/python2.7/site-packages/yum/history.py", line 711, in trans_with_pid VALUES (?, ?)""", (self._tid, pid)) File "/usr/lib/python2.7/site-packages/yum/sqlutils.py", line 168, in executeSQLQmark return cursor.execute(query, params) sqlite3.IntegrityError: trans_with_pkgs.tid may not be NULL
So, debugging this more there appears to be a problem in sqlite unless I'm missing something: % cat /tmp/t.py #! /usr/bin/python -t import locale import os import sqlite3 as sqlite locale.setlocale(locale.LC_ALL, '') # locale.setlocale(locale.LC_TIME, 'C') try: os.unlink("/tmp/bz-720209-turkish.sqlite") except: pass conn = sqlite.connect("/tmp/bz-720209-turkish.sqlite") cur = conn.cursor() res = cur.execute("""\ CREATE TABLE foo ( tid INTEGER PRIMARY KEY, timestamp INTEGER NOT NULL, rpmdb_version TEXT NOT NULL, loginuid INTEGER);\ """) conn.commit() cur = conn.cursor() res = cur.execute("""\ INSERT INTO foo (timestamp, rpmdb_version, loginuid) VALUES (1310411703, "fo:o", 400);\ """) print 'last row id', cur.lastrowid conn.commit() % LANG=en_US.utf-8 /tmp/t.py last row id 1 % sqlite3 /tmp/bz-720209-turkish.sqlite 'SELECT * from foo' 1|1310411703|fo:o|400 % LANG=C /tmp/t.py last row id 1 % sqlite3 /tmp/bz-720209-turkish.sqlite 'SELECT * from foo' 1|1310411703|fo:o|400 % LANG=tr_TR.UTF-8 /tmp/t.py last row id None % sqlite3 /tmp/bz-720209-turkish.sqlite 'SELECT * from foo' 1|1310411703|fo:o|400 ...now I'm not 100% sure this is an sqlite problem, and not a python problem or something ... but sqlite is the obvious choice...
That's interesting. Did a quick check for all locales supported on Fedora. Failing ones are: az_AZ az_AZ.utf8 crh_UA crh_UA.utf8 ku_TR ku_TR.iso88599 ku_TR.utf8 tr_CY tr_CY.iso88599 tr_CY.utf8 tr_TR tr_TR.iso88599 tr_TR.utf8 tt_RU.utf8@iqtelif tt_RU@iqtelif turkish
I had a hunch that this was a case problem, and just having tested it, if I replace "INSERT INTO" with "insert into", the problem goes away. I guess that sqlite is lower-casing the SQL; in Turkish, "I" is lower cased to a dotless "ı" (rather than "i"). I've not tested outside Python, but looking at the source code for Python's sqlite3 module [1], I think that the call to tolower in the detect_statement_type function is causing the problem. "INSERT" isn't matched to "insert", which looks like it will lead the execute command to commit the transaction straight away. [1] http://hg.python.org/cpython/file/c4b6d9312da1/Modules/_sqlite/cursor.c#l41 (Technical note: I'm testing on an Ubuntu system, not Fedora - I don't think it should affect this)
Submitted a Python issue: http://bugs.python.org/issue13099
A fix has been committed, which should resolve it for Python 3.3, and the next point releases 2.7.3 and 3.2.3.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping