Bug#757289: stimfit: Please update to use wxwidgets3.0
Control: severity -1 serious Justification: Blocks two on-going transitions (wxwidgets3.0 and wxpython3.0) On Thu, Aug 07, 2014 at 11:08:54AM -0400, Yaroslav Halchenko wrote: On Thu, 07 Aug 2014, Christoph Schmidt-Hieber wrote: I'm unsure whether we should release 0.13.19 including these changes or use your NMU instead given that we've just uploaded 0.13.18 - Yaro, what do you think? I would not mind NMU at all - but you would need to not forget to ACK it in your next upload (so might end up more of work for you, depending on how easy/complex is to cut a new release). I think it's time we got a fix uploaded one way or the other - if we do it now, there's two months to find and fix any resulting issues before the jessie freeze, which is a comfortable margin. I infer from the above that you probably wouldn't object to an NMU, but I'd rather have a more explicit ACK (or a NACK if you're intending to make an upload yourself shortly). Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
On Fri, Aug 29, 2014 at 10:50:58PM -0300, Olly Betts wrote: Control: severity -1 serious Justification: Blocks two on-going transitions (wxwidgets3.0 and wxpython3.0) On Thu, Aug 07, 2014 at 11:08:54AM -0400, Yaroslav Halchenko wrote: On Thu, 07 Aug 2014, Christoph Schmidt-Hieber wrote: I'm unsure whether we should release 0.13.19 including these changes or use your NMU instead given that we've just uploaded 0.13.18 - Yaro, what do you think? I would not mind NMU at all - but you would need to not forget to ACK it in your next upload (so might end up more of work for you, depending on how easy/complex is to cut a new release). I think it's time we got a fix uploaded one way or the other - if we do it now, there's two months to find and fix any resulting issues before the jessie freeze, which is a comfortable margin. I infer from the above that you probably wouldn't object to an NMU, but I'd rather have a more explicit ACK (or a NACK if you're intending to make an upload yourself shortly). I'm putting together 0.13.19 for upload. How can I test Debian packaging with wx-3.0 on my local system? Currently pbuilder complains about unresolved dependencies. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
On Sat, Aug 30, 2014 at 04:01:47PM +0100, Christoph Schmidt-Hieber wrote: I'm putting together 0.13.19 for upload. Cool. How can I test Debian packaging with wx-3.0 on my local system? Currently pbuilder complains about unresolved dependencies. What's the exact error? It should just work - I just did a quick rebase of my nmudiff onto 1.3.18 and that builds fine for me in sbuild. I'd make sure your pbuilder unstable chroot is up-to-date, and perhaps try recreating it. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
@Yaro: stimfit 0.13.19, addressing this bug, has been uploaded to Debian mentors: https://mentors.debian.net/package/stimfit Thanks for uploading. On Sat, Aug 30, 2014 at 04:33:00PM +0100, Olly Betts wrote: On Sat, Aug 30, 2014 at 04:01:47PM +0100, Christoph Schmidt-Hieber wrote: I'm putting together 0.13.19 for upload. Cool. How can I test Debian packaging with wx-3.0 on my local system? Currently pbuilder complains about unresolved dependencies. What's the exact error? It should just work - I just did a quick rebase of my nmudiff onto 1.3.18 and that builds fine for me in sbuild. I'd make sure your pbuilder unstable chroot is up-to-date, and perhaps try recreating it. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
Control: tags -1 + pending On Sat, Aug 30, 2014 at 05:02:46PM +0100, Christoph Schmidt-Hieber wrote: @Yaro: stimfit 0.13.19, addressing this bug, has been uploaded to Debian mentors: https://mentors.debian.net/package/stimfit Thanks for uploading. Awesome. If Yaro's unable to sponsor it in a timely fashion, feel free to ping me. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
Awesome. If Yaro's unable to sponsor it in a timely fashion, feel free to ping me. building now... will upload later if everything is smooth Thanks Olly for staying guard! Cheers -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
uploading as is, but because you didn't take the route of alternatives, all backport builds are no longer good On Sat, 30 Aug 2014, Olly Betts wrote: Control: tags -1 + pending On Sat, Aug 30, 2014 at 05:02:46PM +0100, Christoph Schmidt-Hieber wrote: @Yaro: stimfit 0.13.19, addressing this bug, has been uploaded to Debian mentors: https://mentors.debian.net/package/stimfit Thanks for uploading. Awesome. If Yaro's unable to sponsor it in a timely fashion, feel free to ping me. Cheers, Olly -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
On Mon, Aug 11, 2014 at 06:19:46AM +0100, Olly Betts wrote: On Thu, Aug 07, 2014 at 11:08:54AM -0400, Yaroslav Halchenko wrote: On Thu, 07 Aug 2014, Christoph Schmidt-Hieber wrote: Applied upstream in https://github.com/neurodroid/stimfit/commit/db161956 https://github.com/neurodroid/stimfit/commit/3d9305ff why not just to use alternatives in the above commit? with two copies of control file it would be impossible to build neurodebian backports, and in general -- duplication is not good ;) You can still build backports, you just need to do this as part of the backporting process: cp debian/control-wx2.8 debian/control Yaroslav, as a regex ninja maybe you can come up with some sed line that generates control-wx2.8 from control to avoid duplication? I already outlined the issues with using alternatives - quoting: You can have alternates in Build-Depends, though the buildds will only try to install the first alternative. So you could have something like this which would work for uploads to unstable: Build-Depends: libwxgtk3.0-dev | libwxgtk2.8-dev, python-wxgtk3.0 | python-wxgtk2.8, python-wxgtk3.0-dev | python-wxgtk2.8 This would also allow you to manually install the 2.8 packages and build, but it wouldn't work for uploading to build against 2.8 in wheezy backports, and nothing ensures you get a matching set (e.g. libwxgtk3.0-dev + python-wxgtk2.8 satisfies this). For wheezy you'll just be able to backport as-is soon: For wheezy-backports, wxwidgets3.0 is already backported, and I'm intending to also provide a backport of wxpython3.0 shortly. I can't do this until wxpython3.0 migrates to testing though, which should happen in a day or two unless there's a serious problem discovered before then. I'm unsure whether we should release 0.13.19 including these changes or use your NMU instead given that we've just uploaded 0.13.18 - Yaro, what do you think? I would not mind NMU at all - but you would need to not forget to ACK it in your next upload (so might end up more of work for you, depending on how easy/complex is to cut a new release). A new upstream release would also benefit anyone else trying to use stimfit with wxWidgets 3.0 on Linux (or other Unix-like platforms), though I can understand reluctance to make a new release for a single change such as this one. In Debian terms it'd be good to get an updated stimfit package fairly soon, whether it is via a new upstream release, maintainer uploaded 0.13.18-2, or NMU. That way there should be plenty of time to shake out any issues prior to the jessie release freeze (Nov 5th). Cheers, Olly -- Christoph Schmidt-Hieber Wolfson Institute for Biomedical Research University College London Gower Street London WC1E 6BT UK Phone +44 (0)7551994016 pgpPVByv0luAa.pgp Description: PGP signature
Bug#757289: stimfit: Please update to use wxwidgets3.0
On Thu, Aug 07, 2014 at 11:08:54AM -0400, Yaroslav Halchenko wrote: On Thu, 07 Aug 2014, Christoph Schmidt-Hieber wrote: Applied upstream in https://github.com/neurodroid/stimfit/commit/db161956 https://github.com/neurodroid/stimfit/commit/3d9305ff why not just to use alternatives in the above commit? with two copies of control file it would be impossible to build neurodebian backports, and in general -- duplication is not good ;) You can still build backports, you just need to do this as part of the backporting process: cp debian/control-wx2.8 debian/control I already outlined the issues with using alternatives - quoting: You can have alternates in Build-Depends, though the buildds will only try to install the first alternative. So you could have something like this which would work for uploads to unstable: Build-Depends: libwxgtk3.0-dev | libwxgtk2.8-dev, python-wxgtk3.0 | python-wxgtk2.8, python-wxgtk3.0-dev | python-wxgtk2.8 This would also allow you to manually install the 2.8 packages and build, but it wouldn't work for uploading to build against 2.8 in wheezy backports, and nothing ensures you get a matching set (e.g. libwxgtk3.0-dev + python-wxgtk2.8 satisfies this). For wheezy you'll just be able to backport as-is soon: For wheezy-backports, wxwidgets3.0 is already backported, and I'm intending to also provide a backport of wxpython3.0 shortly. I can't do this until wxpython3.0 migrates to testing though, which should happen in a day or two unless there's a serious problem discovered before then. I'm unsure whether we should release 0.13.19 including these changes or use your NMU instead given that we've just uploaded 0.13.18 - Yaro, what do you think? I would not mind NMU at all - but you would need to not forget to ACK it in your next upload (so might end up more of work for you, depending on how easy/complex is to cut a new release). A new upstream release would also benefit anyone else trying to use stimfit with wxWidgets 3.0 on Linux (or other Unix-like platforms), though I can understand reluctance to make a new release for a single change such as this one. In Debian terms it'd be good to get an updated stimfit package fairly soon, whether it is via a new upstream release, maintainer uploaded 0.13.18-2, or NMU. That way there should be plenty of time to shake out any issues prior to the jessie release freeze (Nov 5th). Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
Thanks for the patch. Note that we've just released 0.13.18-1:
https://packages.debian.org/sid/stimfit
It would be good to apply your patch upstream, but I was wondering how
your build-depends line would affect packaging for older releases
(wheezy and precise)? Is there a way to make this compatible across
releases?
On Thu, Aug 07, 2014 at 10:51:22AM +1200, Olly Betts wrote:
Package: stimfit
Version: 0.13.15-1
Severity: important
Tags: patch
Tags: sid jessie
User: freewx-ma...@lists.alioth.debian.org
Usertags: wx3.0 wxpy3.0
Control: block 748169 by -1
Control: block 755757 by -1
We're aiming to migrate the archive to using wxwidgets3.0/wxpython3.0
instead of wxwidgets2.8, and hope to drop wxwidgets2.8 before jessie
is released.
Upstream, stimfit supports wx3.0, but it looks like there's a problem
with this support under wxGTK - when __WXGTK__ is defined,
src/stimfit/gui/app.cpp calls:
wxMenuBar* menu_bar = CreateUnifiedMenuBar();
This defaults the doc parameter to NULL, and if wxCHECK_VERSION(2, 9, 0)
is true (which it is for wx = 2.9.0) we then try to call a method on
doc, which segfaults:
((wxStfDoc*)doc)-SetFileMenu( file_menu );
I've added a simple fix for this, though it may not be the best way to
address this. But with the patch, I can run stimfit, and it starts up
OK and I can open a few dialogs. I don't have suitable data to actually
test much functionality though.
I'm happy to NMU this change if you wish me to - just let me know.
Cheers,
Olly
diff -Nru stimfit-0.13.15/debian/changelog stimfit-0.13.15/debian/changelog
--- stimfit-0.13.15/debian/changelog 2014-02-17 02:23:17.0 +1300
+++ stimfit-0.13.15/debian/changelog 2014-08-07 09:42:21.0 +1200
@@ -1,3 +1,10 @@
+stimfit (0.13.15-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update to use wxWidgets 3.0 - new patch: wx3.0-compat.patch
+
+ -- Olly Betts o...@survex.com Thu, 07 Aug 2014 09:42:05 +1200
+
stimfit (0.13.15-1) unstable; urgency=low
* Fix half duration limits bug
diff -Nru stimfit-0.13.15/debian/control stimfit-0.13.15/debian/control
--- stimfit-0.13.15/debian/control2014-02-17 02:23:17.0 +1300
+++ stimfit-0.13.15/debian/control2014-08-07 09:14:27.0 +1200
@@ -3,13 +3,13 @@
Priority: optional
Maintainer: Christoph Schmidt-Hieber chris...@gmx.de
Uploaders: Yaroslav Halchenko deb...@onerussian.com
-Build-Depends: debhelper (= 7), libboost-dev (= 1.40.0), python-all-dev
(= 2.6.6-3), python-numpy, libhdf5-dev, swig, python-wxgtk2.8 (= 2.8.9),
libwxgtk2.8-dev (= 2.8.9), libfftw3-dev, liblapack-dev, chrpath, help2man,
libbiosig-dev, libsuitesparse-dev, dh-autoreconf
+Build-Depends: debhelper (= 7), libboost-dev (= 1.40.0), python-all-dev
(= 2.6.6-3), python-numpy, libhdf5-dev, swig, python-wxgtk3.0,
python-wxgtk3.0-dev, libwxgtk3.0-dev, libfftw3-dev, liblapack-dev, chrpath,
help2man, libbiosig-dev, libsuitesparse-dev, dh-autoreconf
Standards-Version: 3.9.4
Homepage: http://www.stimfit.org
Package: stimfit
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
libbiosig-dev, libsuitesparse-dev, python-wxgtk2.8 (= 2.8.9), python-numpy,
python-matplotlib
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
libbiosig-dev, libsuitesparse-dev, python-wxgtk3.0, python-numpy,
python-matplotlib
Recommends: python-scipy
Description: Program for viewing and analyzing electrophysiological data
Stimfit is a free, fast and simple program for viewing and analyzing
diff -Nru stimfit-0.13.15/debian/patches/series
stimfit-0.13.15/debian/patches/series
--- stimfit-0.13.15/debian/patches/series 1970-01-01 12:00:00.0
+1200
+++ stimfit-0.13.15/debian/patches/series 2014-08-07 09:39:02.0
+1200
@@ -0,0 +1 @@
+wx3.0-compat.patch
diff -Nru stimfit-0.13.15/debian/patches/wx3.0-compat.patch
stimfit-0.13.15/debian/patches/wx3.0-compat.patch
--- stimfit-0.13.15/debian/patches/wx3.0-compat.patch 1970-01-01
12:00:00.0 +1200
+++ stimfit-0.13.15/debian/patches/wx3.0-compat.patch 2014-08-07
09:42:00.0 +1200
@@ -0,0 +1,22 @@
+Description: Fix build with wx3.0 under __WXGTK__
+ While stimfit has been ported to wx3.0, it seems this hasn't been tested
+ under __WXGTK__ as there doc is always NULL in
wxStfApp::CreateUnifiedMenuBar
+ but we try to call methods on it for wx = 2.9.0.
+ .
+ I don't understand the reason for all the conditionalisation on __WXGTK__,
+ __WXMSW__ etc, so this may not be the best fix, but it seems to work.
+Author: Olly Betts o...@survex.com
+Forwarded: no
+Last-Update: 2014-08-06
+
+--- stimfit-0.13.15.orig/src/stimfit/gui/app.cpp
stimfit-0.13.15/src/stimfit/gui/app.cpp
+@@ -605,7 +605,7 @@ wxMenuBar *wxStfApp::CreateUnifiedMenuBa
+ file_menu-AppendSeparator();
+ file_menu-Append(wxID_EXIT);
+
+-#if (wxCHECK_VERSION(2, 9, 0))
++#if
Bug#757289: stimfit: Please update to use wxwidgets3.0
On Thu, Aug 07, 2014 at 10:58:16AM +0100, Christoph Schmidt-Hieber wrote: Thanks for the patch. Note that we've just released 0.13.18-1: https://packages.debian.org/sid/stimfit Oops, sorry I missed that - it must have been uploaded shortly after I pulled down the source. It would be good to apply your patch upstream, but I was wondering how your build-depends line would affect packaging for older releases (wheezy and precise)? Is there a way to make this compatible across releases? For wheezy-backports, wxwidgets3.0 is already backported, and I'm intending to also provide a backport of wxpython3.0 shortly. You can have alternates in Build-Depends, though the buildds will only try to install the first alternative. So you could have something like this which would work for uploads to unstable: Build-Depends: libwxgtk3.0-dev | libwxgtk2.8-dev, python-wxgtk3.0 | python-wxgtk2.8, python-wxgtk3.0-dev | python-wxgtk2.8 This would also allow you to manually install the 2.8 packages and build, but it wouldn't work for uploading to build against 2.8 in wheezy backports, and nothing ensures you get a matching set (e.g. libwxgtk3.0-dev + python-wxgtk2.8 satisfies this). The approach I'd probably take would be keep a version of debian/control with the old BDs as something like debian/control-wx2.8, and then when you want to backport, just copy that over debian/control. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757289: stimfit: Please update to use wxwidgets3.0
On Thu, Aug 07, 2014 at 11:55:36AM +0100, Olly Betts wrote: On Thu, Aug 07, 2014 at 10:58:16AM +0100, Christoph Schmidt-Hieber wrote: Thanks for the patch. Note that we've just released 0.13.18-1: https://packages.debian.org/sid/stimfit Oops, sorry I missed that - it must have been uploaded shortly after I pulled down the source. It would be good to apply your patch upstream, but I was wondering how your build-depends line would affect packaging for older releases (wheezy and precise)? Is there a way to make this compatible across releases? For wheezy-backports, wxwidgets3.0 is already backported, and I'm intending to also provide a backport of wxpython3.0 shortly. You can have alternates in Build-Depends, though the buildds will only try to install the first alternative. So you could have something like this which would work for uploads to unstable: Build-Depends: libwxgtk3.0-dev | libwxgtk2.8-dev, python-wxgtk3.0 | python-wxgtk2.8, python-wxgtk3.0-dev | python-wxgtk2.8 This would also allow you to manually install the 2.8 packages and build, but it wouldn't work for uploading to build against 2.8 in wheezy backports, and nothing ensures you get a matching set (e.g. libwxgtk3.0-dev + python-wxgtk2.8 satisfies this). The approach I'd probably take would be keep a version of debian/control with the old BDs as something like debian/control-wx2.8, and then when you want to backport, just copy that over debian/control. Applied upstream in https://github.com/neurodroid/stimfit/commit/db161956 https://github.com/neurodroid/stimfit/commit/3d9305ff I'm unsure whether we should release 0.13.19 including these changes or use your NMU instead given that we've just uploaded 0.13.18 - Yaro, what do you think? pgpuEU3xWAqKX.pgp Description: PGP signature
Bug#757289: stimfit: Please update to use wxwidgets3.0
Package: stimfit
Version: 0.13.15-1
Severity: important
Tags: patch
Tags: sid jessie
User: freewx-ma...@lists.alioth.debian.org
Usertags: wx3.0 wxpy3.0
Control: block 748169 by -1
Control: block 755757 by -1
We're aiming to migrate the archive to using wxwidgets3.0/wxpython3.0
instead of wxwidgets2.8, and hope to drop wxwidgets2.8 before jessie
is released.
Upstream, stimfit supports wx3.0, but it looks like there's a problem
with this support under wxGTK - when __WXGTK__ is defined,
src/stimfit/gui/app.cpp calls:
wxMenuBar* menu_bar = CreateUnifiedMenuBar();
This defaults the doc parameter to NULL, and if wxCHECK_VERSION(2, 9, 0)
is true (which it is for wx = 2.9.0) we then try to call a method on
doc, which segfaults:
((wxStfDoc*)doc)-SetFileMenu( file_menu );
I've added a simple fix for this, though it may not be the best way to
address this. But with the patch, I can run stimfit, and it starts up
OK and I can open a few dialogs. I don't have suitable data to actually
test much functionality though.
I'm happy to NMU this change if you wish me to - just let me know.
Cheers,
Olly
diff -Nru stimfit-0.13.15/debian/changelog stimfit-0.13.15/debian/changelog
--- stimfit-0.13.15/debian/changelog 2014-02-17 02:23:17.0 +1300
+++ stimfit-0.13.15/debian/changelog 2014-08-07 09:42:21.0 +1200
@@ -1,3 +1,10 @@
+stimfit (0.13.15-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update to use wxWidgets 3.0 - new patch: wx3.0-compat.patch
+
+ -- Olly Betts o...@survex.com Thu, 07 Aug 2014 09:42:05 +1200
+
stimfit (0.13.15-1) unstable; urgency=low
* Fix half duration limits bug
diff -Nru stimfit-0.13.15/debian/control stimfit-0.13.15/debian/control
--- stimfit-0.13.15/debian/control 2014-02-17 02:23:17.0 +1300
+++ stimfit-0.13.15/debian/control 2014-08-07 09:14:27.0 +1200
@@ -3,13 +3,13 @@
Priority: optional
Maintainer: Christoph Schmidt-Hieber chris...@gmx.de
Uploaders: Yaroslav Halchenko deb...@onerussian.com
-Build-Depends: debhelper (= 7), libboost-dev (= 1.40.0), python-all-dev (= 2.6.6-3), python-numpy, libhdf5-dev, swig, python-wxgtk2.8 (= 2.8.9), libwxgtk2.8-dev (= 2.8.9), libfftw3-dev, liblapack-dev, chrpath, help2man, libbiosig-dev, libsuitesparse-dev, dh-autoreconf
+Build-Depends: debhelper (= 7), libboost-dev (= 1.40.0), python-all-dev (= 2.6.6-3), python-numpy, libhdf5-dev, swig, python-wxgtk3.0, python-wxgtk3.0-dev, libwxgtk3.0-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libbiosig-dev, libsuitesparse-dev, dh-autoreconf
Standards-Version: 3.9.4
Homepage: http://www.stimfit.org
Package: stimfit
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, libbiosig-dev, libsuitesparse-dev, python-wxgtk2.8 (= 2.8.9), python-numpy, python-matplotlib
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, libbiosig-dev, libsuitesparse-dev, python-wxgtk3.0, python-numpy, python-matplotlib
Recommends: python-scipy
Description: Program for viewing and analyzing electrophysiological data
Stimfit is a free, fast and simple program for viewing and analyzing
diff -Nru stimfit-0.13.15/debian/patches/series stimfit-0.13.15/debian/patches/series
--- stimfit-0.13.15/debian/patches/series 1970-01-01 12:00:00.0 +1200
+++ stimfit-0.13.15/debian/patches/series 2014-08-07 09:39:02.0 +1200
@@ -0,0 +1 @@
+wx3.0-compat.patch
diff -Nru stimfit-0.13.15/debian/patches/wx3.0-compat.patch stimfit-0.13.15/debian/patches/wx3.0-compat.patch
--- stimfit-0.13.15/debian/patches/wx3.0-compat.patch 1970-01-01 12:00:00.0 +1200
+++ stimfit-0.13.15/debian/patches/wx3.0-compat.patch 2014-08-07 09:42:00.0 +1200
@@ -0,0 +1,22 @@
+Description: Fix build with wx3.0 under __WXGTK__
+ While stimfit has been ported to wx3.0, it seems this hasn't been tested
+ under __WXGTK__ as there doc is always NULL in wxStfApp::CreateUnifiedMenuBar
+ but we try to call methods on it for wx = 2.9.0.
+ .
+ I don't understand the reason for all the conditionalisation on __WXGTK__,
+ __WXMSW__ etc, so this may not be the best fix, but it seems to work.
+Author: Olly Betts o...@survex.com
+Forwarded: no
+Last-Update: 2014-08-06
+
+--- stimfit-0.13.15.orig/src/stimfit/gui/app.cpp
stimfit-0.13.15/src/stimfit/gui/app.cpp
+@@ -605,7 +605,7 @@ wxMenuBar *wxStfApp::CreateUnifiedMenuBa
+ file_menu-AppendSeparator();
+ file_menu-Append(wxID_EXIT);
+
+-#if (wxCHECK_VERSION(2, 9, 0))
++#if !defined __WXGTK__ (wxCHECK_VERSION(2, 9, 0))
+ ((wxStfDoc*)doc)-SetFileMenu( file_menu );
+ #else
+ GetDocManager()-FileHistoryLoad( *config );
