abrt version: 1.1.17 architecture: x86_64 cmdline: python /usr/bin/meld ./security/nss component: meld executable: /usr/bin/meld kernel: 2.6.38-0.rc8.git0.1.fc15.x86_64 package: meld-1.5.0-1.fc15 reason: tree.py:121:set_state:TypeError: value is of the wrong type for this column release: Fedora release 15 (Lovelock) time: 1300142614 uid: 12570 backtrace ----- tree.py:121:set_state:TypeError: value is of the wrong type for this column Traceback (most recent call last): File "/usr/share/meld/meld/vcview.py", line 269, in on_vc_change self._set_location(self.vc.root) File "/usr/share/meld/meld/vcview.py", line 283, in _set_location self.model.set_state(it, 0, tree.STATE_NORMAL, isdir=1) File "/usr/share/meld/meld/tree.py", line 121, in set_state self.set_value(it, STATE, state) TypeError: value is of the wrong type for this column Local variables in innermost frame: isdir: 1 TINT: 4 name: 'nss' TEXT: 2 self: <VcTreeStore object at 0x2236be0 (meld+vcview+VcTreeStore at 0x2342b30)> state: 2 it: <GtkTreeIter at 0x2343b00> STATE: 1 pane: 0 fullname: '/home/emaldona/mozilla/NSS/mozilla/security/nss' ICON: 3 comment ----- Other way to cause the crash: checkout a project (e.g. nss) from cvs or git make some modifications meld path-to directory-with-modified-files How to reproduce ----- 1. created two directories to extract srpm's into and compare results 2. downloaded nss-3.12.9-6.el6.src.rpm fronm brew 3. downnloaded nss-3.12.9-14.f14.src.rpm fron koji 4. extrarcted one dor directory 1 and the other to directory 2 5. from dir2 invoked meld ../dir1 . 6. crash happened
Created attachment 484325 [details] File: backtrace
Package: meld-1.5.0-1.fc15 Architecture: x86_64 OS Release: Fedora release 15 (Lovelock) How to reproduce ----- 1. Directory comparison functionality still broken in Meld 1.5.0 :-(
Package: meld-1.5.0-1.fc15 Architecture: x86_64 OS Release: Fedora release 15 (Lovelock) How to reproduce ----- 1. Configured mercurial to use meld as mentioned here http://mercurial.selenic.com/wiki/ExtdiffExtension 2. Ran the command `hg meld` 3.
(In reply to comment #2) > 1. Directory comparison functionality still broken in Meld 1.5.0 :-( Could you elaborate this a little? Works fine here.
Hello Christoph, 1. Launch Meld under GNOME 3. 2. Click "Start a New Comparison" icon on toolbar. 3. Click "Directory Comparison" tab. 4. Browse to select file paths for the "Original" and "Mine" fields. 5. Click "Okay." 6. At this point, the directory selection dialogue box is NOT dismissed and abrt reports the error logged above. Hope this information is of help. Please let me know if I can provide anything else. Thanks, David
Dupe of #682064
(In reply to comment #5) > 1. Launch Meld under GNOME 3. > 2. Click "Start a New Comparison" icon on toolbar. > 3. Click "Directory Comparison" tab. > 4. Browse to select file paths for the "Original" and "Mine" fields. > 5. Click "Okay." > 6. At this point, the directory selection dialogue box is NOT dismissed and > abrt reports the error logged above. I just tried on F15 alpha and it works fine.
Christoph, Good news. I had to reinstall F15 yesterday and I just tested it again and I can confirm that it is now working for me as well. Whatever the problem was, the reinstall seems to have fixed it. Thanks for investigating this, David
No problem. We still need to look into the crash this bug is about, but I want to wait until bugzilla.gnome.org is up again. Additionally, meld lacks the menu icon. I'll fix both this weekend.
Okay, thanks. Also, I'll let you know if I reproduce the issue with my reinstall.
Christoph, I am not reproducing the issue but I am finding that the Directory Comparison feature is now giving me a lot of "false positive" results. Compared files are being marked in red, indicating that they are different, but when I actually open them, Meld says that they are identical. I will provide some screenshots in a moment. I am still running version meld-1.5.0-1.fc15.noarch
Created attachment 490115 [details] The directory comparison feature alerts me that the two "classloading.xmlt" files are different.
Created attachment 490116 [details] However, when I click on the "classloading.xmlt" files to open them, Meld tells me that they are, in fact, identical.
Please try 1.5.1 from https://admin.fedoraproject.org/updates/meld-1.5.1-1.fc15
Just trying it now and I am still reproducing the error. :-(
*** Bug 682064 has been marked as a duplicate of this bug. ***
Hi David, for your identical-file issue: Can you exclude there maybe are different line breaks? I've just reproduced a similar issue with different line breaks: % cp -rp test test2 % unix2dos test2/file1 unix2dos: Datei test2/file1 wird ins DOS-Format konvertiert ... % file test/file1 test/file1: ASCII text % file test2/file1 test2/file1: ASCII text, with CRLF line terminators Running `meld test test2` then, behaves exactly the same as you described. file1 is listed in red, but opening it shows "Files are identical". Regards, Dominic
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