Bug#338117: Bug#338090: Broken python binding
This is a followup for Debian bug http://bugs.debian.org/338117. Hi Joe, On Tue, Jan 31, 2006, Joe Wreschnig wrote: I've proposed a relevant solution on [EMAIL PROTECTED] that lets Python modules provide shlibs-like data to generate dependencies/conflicts at build-time. It could be used to force things built with pygtk 2.8 to conflict with 2.6 (and vice versa) -- in fact, that's my example case, since this broke python-gst. After re-reading the bug, I'm not sure how the solution you propose would solve the issue: codegen generates code dynamically, and I don't see how it would gain conscience that it is being used from within a Debian build and hence should set some substvar. Do you have pointers to the solution you've proposed and how I would use it? Bye, -- Loïc Minier [EMAIL PROTECTED]
Bug#338117: Bug#338090: Broken python binding
On Tue, 2006-07-18 at 22:47 +0200, Loïc Minier wrote: This is a followup for Debian bug http://bugs.debian.org/338117. Hi Joe, On Tue, Jan 31, 2006, Joe Wreschnig wrote: I've proposed a relevant solution on [EMAIL PROTECTED] that lets Python modules provide shlibs-like data to generate dependencies/conflicts at build-time. It could be used to force things built with pygtk 2.8 to conflict with 2.6 (and vice versa) -- in fact, that's my example case, since this broke python-gst. After re-reading the bug, I'm not sure how the solution you propose would solve the issue: codegen generates code dynamically, and I don't see how it would gain conscience that it is being used from within a Debian build and hence should set some substvar. Do you have pointers to the solution you've proposed and how I would use it? The idea was to do it only semi-automatically, with the building package required to declare that it needed to have the pydeps from the other package. dh_python would then grab the dependency information from the desired package and push the substvar itself. Like shlibs deps, the maintainer of the package would be responsible for updating the pydeps file. http://lists.debian.org/debian-python/2006/01/msg00151.html contains the full patch to dh_python, though undoubtedly it will no longer apply. In the current Python climate I think pushing for this change is totally out of the question. -- Joe Wreschnig [EMAIL PROTECTED]
Bug#338117: Bug#338090: Broken python binding
Hi Loïc, I've proposed a relevant solution on [EMAIL PROTECTED] that lets Python modules provide shlibs-like data to generate dependencies/conflicts at build-time. It could be used to force things built with pygtk 2.8 to conflict with 2.6 (and vice versa) -- in fact, that's my example case, since this broke python-gst. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#338117: Bug#338090: Broken python binding
On Tue, Jan 31, 2006, Joe Wreschnig wrote: I've proposed a relevant solution on [EMAIL PROTECTED] that lets Python modules provide shlibs-like data to generate dependencies/conflicts at build-time. It could be used to force things built with pygtk 2.8 to conflict with 2.6 (and vice versa) -- in fact, that's my example case, since this broke python-gst. I'm happy to read that! Thanks for caring, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Bug#338090: Broken python binding
clone 338090 -1
reassign -1 python-gtk2-dev 2.8.0-1
retitle -1 pygtk-codegen-2.0 from 2.8's pygtk generates code incompatible with
python 2.3
severity -1 important
thanks
Hi,
On Mon, Nov 07, 2005, Manish Singh wrote:
Due to a bug upstream (http://bugzilla.gnome.org/show_bug.cgi?id=320931)
a python/vte.c generated for pygtk 2.8 is distributed with the tarball.
Since the date is newer than the other source files, it's not
regenerated, and the resultant binary does not work
Thanks for your report, I've already forwarded a couple of reports on
this matter upstream, namely Debian bugs #334001 and #334668, and this
is discussed at:
http://bugzilla.gnome.org/show_bug.cgi?id=313454
I noted that this is specific to Python 2.3, and rebuilding python-vte
with Python 2.4 will make it import like a charm.
If I understand you correctly, python/vte.c is generated automatically
(it seems via pygtk-codegen-2.0) and the resulting code is not suitable
for Python 2.3. This seems to imply that this script has to be
carefully split out in a python 2.3 and a python 2.4 version, or get
some flags added to run in 2.3 compatibility mode.
Hence, I removed vte.c and ran in a clean sid chroot (with pygtk
2.6.3-2):
bee% pygtk-codegen-2.0 -p pyvte -o vte.override --register
/usr/share/pygtk/2.0/defs/gtk-types.defs --register
/usr/share/pygtk/2.0/defs/gdk-types.defs --register
/usr/share/pygtk/2.0/defs/pango-types.defs vte.defs vte.override
vte.c
Could not write method VteTerminal.forkpty: No ArgType for 'char**'
Could not write method VteTerminal.match_check: No ArgType for 'int*'
***INFO*** The coverage of global functions is 100.00% (3/3)
***INFO*** The coverage of methods is 97.26% (71/73)
***INFO*** There are no declared virtual proxies.
***INFO*** There are no declared virtual accessors.
***INFO*** There are no declared interface proxies.
and the result is the attached vte.c file which has only minor
modifications beside this one:
@@ -1548,7 +1546,6 @@
}
-#line 1552 vte.c
+#line 1550 vte.c
pygobject_register_class(d, VteTerminal, VTE_TYPE_TERMINAL,
PyVteTerminal_Type, Py_BuildValue((O), PyGtkWidget_Type));
-pyg_set_object_has_new_constructor(VTE_TYPE_TERMINAL);
}
... which suggest the problem will be fixed.
Do you have any suggestion on fixing the root problem (ie.
pygtk-codegen-2.0)?
Should all packages be examined against this problem?
Cheers,
--
Loïc Minier [EMAIL PROTECTED]
/* -- THIS FILE IS GENERATED - DO NOT EDIT *//* -*- Mode: C; c-basic-offset: 4 -*- */
#include Python.h
#line 4 vte.override
#include Python.h
#include pygtk/pygtk.h
#include pygobject.h
#include gtk/gtk.h
#include ../src/vte.h
#line 14 vte.c
/* -- types from other modules -- */
static PyTypeObject *_PyGdkPixbuf_Type;
#define PyGdkPixbuf_Type (*_PyGdkPixbuf_Type)
static PyTypeObject *_PyGtkMenuShell_Type;
#define PyGtkMenuShell_Type (*_PyGtkMenuShell_Type)
static PyTypeObject *_PyGtkWidget_Type;
#define PyGtkWidget_Type (*_PyGtkWidget_Type)
/* -- forward type declarations -- */
PyTypeObject PyVteTerminal_Type;
/* --- VteTerminal --- */
static int
_wrap_vte_terminal_new(PyGObject *self, PyObject *args, PyObject *kwargs)
{
GType obj_type = pyg_type_from_object((PyObject *) self);
static char* kwlist[] = { NULL };
if (!PyArg_ParseTupleAndKeywords(args, kwargs, :vte.Terminal.__init__, kwlist))
return -1;
self-obj = g_object_newv(obj_type, 0, NULL);
if (!self-obj) {
PyErr_SetString(PyExc_RuntimeError, could not create %(typename)s object);
return -1;
}
pygobject_register_wrapper((PyObject *)self);
return 0;
}
#line 75 vte.override
static PyObject *
_wrap_vte_terminal_fork_command(PyGObject * self, PyObject * args,
PyObject * kwargs)
{
gchar **argv = NULL, **envv = NULL;
gchar *command = NULL, *directory = NULL;
static char *kwlist[] = { command, argv, envv, directory,
loglastlog, logutmp, logwtmp,
NULL };
PyObject *py_argv = NULL, *py_envv = NULL,
*loglastlog = NULL, *logutmp = NULL, *logwtmp = NULL;
int i, n_args, n_envs;
pid_t pid;
if (!PyArg_ParseTupleAndKeywords(args, kwargs, |sOOsOOO:fork_command,
kwlist, command, py_argv, py_envv,
directory,
loglastlog, logutmp, logwtmp)) {
return NULL;
}
if (py_argv != NULL py_argv != Py_None) {
if (!PySequence_Check(py_argv)) {
PyErr_SetString(PyExc_TypeError,
argv must be a sequence);
return NULL;
}
n_args = PySequence_Length(py_argv);
argv = g_new(gchar *, n_args + 1);
for (i = 0; i n_args; i++) {
PyObject *item = PySequence_GetItem(py_argv, i);
Py_DECREF(item); /* PySequence_GetItem INCREF's */
argv[i] = PyString_AsString(item);
}
argv[n_args] = NULL;
}
if (py_envv != NULL py_envv != Py_None) {
if (!PySequence_Check(py_envv)) {
PyErr_SetString(PyExc_TypeError,
envv must be a
Bug#338090: Broken python binding
On Tue, Nov 08, 2005, Loic Minier wrote: ... which suggest the problem will be fixed. I don't get the same import vte error, but it still fails: import vte Traceback (most recent call last): File stdin, line 1, in ? ImportError: could not import gtk._gtk (This is with python2.3-gtk2 installed, and I called python-2.3.) I straced python, and it tries to open /usr/lib/python2.3/site-packages/gtk-2.0/stdin and similar directories, and I do have the following file: /usr/lib/python2.3/site-packages/gtk-2.0/gtk/_gtk.so Any idea? -- Loïc Minier [EMAIL PROTECTED] What do we want? BRAINS!When do we want it? BRAINS!
Bug#338090: Broken python binding
On Tue, Nov 08, 2005 at 11:42:24AM +0100, Loic Minier wrote: On Tue, Nov 08, 2005, Loic Minier wrote: ... which suggest the problem will be fixed. I don't get the same import vte error, but it still fails: import vte Traceback (most recent call last): File stdin, line 1, in ? ImportError: could not import gtk._gtk (This is with python2.3-gtk2 installed, and I called python-2.3.) I straced python, and it tries to open /usr/lib/python2.3/site-packages/gtk-2.0/stdin and similar directories, and I do have the following file: /usr/lib/python2.3/site-packages/gtk-2.0/gtk/_gtk.so Any idea? I just apt-get source python-vte, rm'd python/vte.c from the tree, and ran dpkg-buildpackage. This made a working python module for me, and I'm using python 2.3 and pygtk 2.6. I think something is wrong with your specific setup. Probably the whole strace will give me some clues. There isn't anything python 2.4 specific about what any version of pygtk-codegen-2.0 generates. -Yosh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338090: Broken python binding
Package: python-vte Version: 0.11.15-2 Severity: grave Due to a bug upstream (http://bugzilla.gnome.org/show_bug.cgi?id=320931) a python/vte.c generated for pygtk 2.8 is distributed with the tarball. Since the date is newer than the other source files, it's not regenerated, and the resultant binary does not work: [EMAIL PROTECTED]:~$ python Python 2.3.5 (#2, Aug 30 2005, 15:50:26) [GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2 Type help, copyright, credits or license for more information. import vte Traceback (most recent call last): File stdin, line 1, in ? ImportError: /usr/lib/python2.3/site-packages/gtk-2.0/vtemodule.so: undefined symbol: pyg_set_object_has_new_constructor Until the bug is fixed in a new upstream release, a simple workaround would be to remove python/vte.c via debian/rules or some other mechanism. -Yosh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
