The following was filed automatically by anaconda: anaconda 15.20.1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/pyanaconda/iw/datacombo.py", line 43, in append self.store[iter] = (text, data) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/lvm_dialog_gui.py", line 269, in createPEOptionMenu peCombo.append(val, curpe) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/lvm_dialog_gui.py", line 1345, in __init__ self.peCombo = self.createPEOptionMenu(self.vg.peSize * 1024) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1749, in editLVMLogicalVolume lv.vg, isNew = False) File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1640, in editCB self.editLVMLogicalVolume(lv = device) TypeError: value is of wrong type for this column
Created attachment 482523 [details] Attached traceback automatically from anaconda.
Joachim, thanks for reporting the bug. What F15 build did you use to reproduce this? (just paste the url please). Thanks, Ales
Error occurred with a live spin built by means of livecd-tools-15.5-1.fc15 and fedora-livecd-desktop.ks from fedora-kickstarts-0.15.2-1.fc15 including repositories "fedora" and "updates-testing", thus a bit ahead of the latest nightly builds.
Issue persists after rebuilding and installing anaconda-15.20.1-1.fc15 during a live session of the fully updated live spin. Compilation succeeds without any problem, thus it is not a matter of simply building anaconda against some updated Python package from updates-testing or the like.
Ales - it might be this simple: --- a/pyanaconda/iw/lvm_dialog_gui.py +++ b/pyanaconda/iw/lvm_dialog_gui.py @@ -266,7 +266,7 @@ class VolumeGroupEditor: actualPE.append(curpe) val = self.prettyFormatPESize(curpe) - peCombo.append(val, curpe) + peCombo.append(val, str(curpe)) # First try to set the combo's active value to the default we're # passed. If that doesn't work, just set it to the first one to Worth checking anywhere else we pull out values from that combo. It's expecting a (string, string) to be stored in it.
> actualPE.append(curpe) > val = self.prettyFormatPESize(curpe) > > - peCombo.append(val, curpe) > + peCombo.append(val, str(curpe)) > > # First try to set the combo's active value to the default we're > # passed. If that doesn't work, just set it to the first one to > > Worth checking anywhere else we pull out values from that combo. It's > expecting a (string, string) to be stored in it. That's what I thought but I tried to reproduce this by having a sandboxed DataCombo and appended some integer values into it, without a traceback. So I am wondering if the GTK api changed in the recent F15s (and why I can't see the change). But your fix should be sufficient, I just want to make sure I know why it happens.
Reporter, I can't reproduce this using the http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-i386-20110308.00.iso Can you please try the official nightly build above (or a more recent version) and write here if you can reproduce it? (with the steps to do so). Thanks.
(In reply to comment #7) Nightly desktop spin desktop-i386-20110308.00.iso behaves correctly, which is understandable as it does not take into account the significant number of available builds in repository updates-testing. However, packages in repository fedora are far from immutable at the present time. I would hence prefer to leave this report open. If somebody updates the running live system which I frequently do and launches liveinst afterwards then he will probably encounter exactly this issue. Due to some other issue, my live system freezes before applying all updates despite a largely sufficient amount of system memory.
(In reply to comment #8) > (In reply to comment #7) > Nightly desktop spin desktop-i386-20110308.00.iso behaves correctly, which is > understandable as it does not take into account the significant number of > available builds in repository updates-testing. However, packages in repository > fedora are far from immutable at the present time. I would hence prefer to > leave this report open. Can you please retest once you can run the live install builds (I talked to Fedora QA and there are known bugs that won't allow you to log into the system, some of it can remedied by removing all at-spi- packages and restarting X on the livecd). But you are completely right, this could be caused some tighter type checking in a new GTK. Ales
(In reply to comment #9) As stated earlier, this issue at present -only- affects local desktop spins of fedora -plus- updates-testing repositories. It applies to the latest anaconda-15.22-1.fc15, too. I will try to update packages of the latest official nightly spin successively in order to nail down the culprit and report back.
Let's keep this in needinfo until then. If you can reproduce please mention the version of gtk and pygtk2 packages in this BZ.
Issue is caused by the ABI change from pygobject2-2.27.91-1.fc15 to pygobject2-2.28.0-1.fc15. Updating this and only this package in a live session launched from desktop-i386-20110308.00.iso causes anaconda to throw the exception reported above. As a consequence, for all official nightly desktop builds beyond 2011-03-09 when pygobject2-2.28.0-1.fc15 had been pushed to repository "fedora", the liveinst installer will crash at least when trying to edit an existing LVM setup. I have verified this failure for desktop-i386-20110311.07.iso. Installed packages include: - anaconda-15.20.1-1.fc15 - gtk3-3.0.2-1.fc15 * pygobject2-2.28.0-1.fc15 - pygtk2-2.22.0-2.fc15
Thanks Joachim. Reassigning to GTK, it is too late for ABI changes now.
Discussed at 2011-03-18 blocker review meeting. Our understanding of the impact of this bug is that it triggers any time you hit the custom partitioning screen when the current proposed layout has LVMs in it. Please correct us if this is not the case. Given that impact, this is a clear Final blocker under the criterion "# The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above". We also accept it as Beta NTH. We are also worried about Beta criterion "# The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot ", given that the default partition layout involves LVMs. We intend to do some testing to see exactly how hard it is to avoid this issue. If it significantly impairs the ability to access the custom partitioning step in order to create software RAID arrays, we may upgrade this to a Beta blocker.
*** Bug 689650 has been marked as a duplicate of this bug. ***
*** Bug 684283 has been marked as a duplicate of this bug. ***
*** Bug 689774 has been marked as a duplicate of this bug. ***
Matthias, do you own this now? Can you give us an update on where this stands?
We shouldn't have ABI changes in the pygoibject2 static bindings so this is a bug. What is the actual column type and what being passed (e.g. what is the output of type(curpe))?
Note that if you can reproduce this with a small test app I should be able to fix it pretty quickly.
I did a little more investigation and I think I see the issue: @@ -848,10 +889,15 @@ pyg_value_from_pyobject(GValue *value, PyObject *obj) g_value_set_double(value, PyFloat_AsDouble(obj)); break; case G_TYPE_STRING: - if (obj == Py_None) + if (obj == Py_None) { g_value_set_string(value, NULL); - else if ((tmp = PyObject_Str(obj))) { - g_value_set_string(value, PYGLIB_PyUnicode_AsString(tmp)); +#if PY_VERSION_HEX < 0x03000000 + } else if (PyString_Check(obj)) { + g_value_set_string(value, PyString_AsString(obj)); +#endif + } else if (PyUnicode_Check(obj)) { + tmp = PyUnicode_AsUTF8String(obj); + g_value_set_string(value, PYGLIB_PyBytes_AsString(tmp)); Py_DECREF(tmp); } else { PyErr_Clear(); We changed tmp = PyObject_Str(obj) to PyString_Check(obj) which of course makes it stricter as the object has to be a string instead of being converted to a string via __str__. I'll whip up a patch and do a build in Fedora by noon tomorrow.
Created attachment 486926 [details] This should fix the issue I have this ready to go. It passes tests in both python 2 and python 3 so I'm going to do a pygobject release later tonight and build it into F15.
Created attachment 486944 [details] Attached traceback automatically from anaconda.
pygobject2-2.28.2-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pygobject2-2.28.2-1.fc15
Created attachment 486998 [details] Attached traceback from anaconda. Exception occurs for a current desktop spin of fedora plus updates-testing repositories including packages: - anaconda-15.24-1.fc15 - pygobject2-2.28.2-1.fc15
Hmm, for some reason the python error code is being set even though it looks like we succeed in converting an int to a string. Debugging now.
Ok, my fault. Rolling new release. I was using the passed in object when converting, not the tmp_str I created with PyObject_Str()
pygobject2-2.28.2-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pygobject2-2.28.2-2.fc15
(In reply to comment #28) > pygobject2-2.28.2-2.fc15 has been submitted as an update for Fedora 15. > https://admin.fedoraproject.org/updates/pygobject2-2.28.2-2.fc15 Updated boot.iso that includes the newer pygobject2 is available for testing at http://jlaska.fedorapeople.org/boot.iso
Upgrading to pygobject2-2.28.2-2.fc15 on a fully updated desktop live spin allows to edit an existing LVM layout as expected.
Please don't close the bug until the update is pushed. In fact, don't close it manually at all, Bodhi will do that. Closing the bug while the update is still in updates-testing has the potential to badly screw up the blocker process, in fact :)
Moving to VERIFIED based on comment#30 and my testing.
pygobject2-2.28.3-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pygobject2-2.28.3-1.fc15
Added a new build from an upstream release which incorporates the patch from 2.28.2-2.fc15. Please karma this from bodhi so it gets pushed to stable.
pygobject2-2.28.2-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Tested with an updated boot.iso. LVM and RAID create/edit works without error during installation
Can I expect a working installation from boot.fedoraproject.org any soon to test further?
(In reply to comment #36) > Tested with an updated boot.iso. LVM and RAID create/edit works without error > during installation James - What boot.iso did you test with? I just ran into this with the images from http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/development/15/x86_64/os/images/pxeboot/ (initrd.img dated 24-Mar-2011). My setup is LVM over multiple MD RAID-1 devices. (It would sure be nice to go a release or two without breaking this.)
Ian, see comment #29
(In reply to comment #39) > Ian, see comment #29 Thanks! ... And it looks like that image is able to successfully grok my setup. w00t!
*** Bug 690967 has been marked as a duplicate of this bug. ***
pygobject2-2.28.3-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 488453 [details] Attached traceback automatically from anaconda.