Bug#462189: wxwindows2.4 is scheduled to be removed
On Sun, 26 Apr 2009, Kevin Rosenberg wrote: Yes, that's a reasonable plan. I eliminated all my initialization code, but the segv still occurs on startup. The next step would be to start removing other, non-initializing code and declarations. Could you push this to a publicly avialable repository to? However, at this time I don't have time to work on further efforts to port to a new version of wx. For my own needs, I can use CTSim on wx2.4, even if the package does not stay in Debian. I can perfectly this works-for-me-no-time-for-more-effort attitude but there are chances at some point in time you are forced to change even in yourprivate environment. I learned that such changes sometimes might even come with more time preasure than expected. So it is a good investment into the future to keep track with up to date libs. Considering the fact that new users are approaching from the distributors side and look at the large image before they dive into specific packages it would serve our users better if we would care better for things like this and so from a users perspective an updated package (even if it is rather cosmetics than technical progress) might make sense. Okay, it'd be no trouble to upload a package for wx2.4 that updates those minor, Debian specific metadata. That's nice. If the benefits of group maintenance outweighs the cost of segmenting my open-source packages from my own code server to an outside server, then I'm in favor of it. As for what would make the switch worthwhile, from my perspective, if a volunteer to work on the wx2.8 port I can not promise anything but as I said the strip down to bare minimum strategy and than ask for help might be reasonable. IMHO a branch like svn://svn.debian.org/svn/debian-med/trunk/packages/ctsim/branch might be used (and dropped once the problem might be solved). This gives Debian Med people easy access. Regarding pristine-tar I'd like to come back to my arguing above: If you consider my suggestion interesting please make sure that the debian directory will not be include into pristine tarball. As I mentioned, my build scripts clean the git repository (which has debian/ integrated in the directory structure), so the upstream tarballs are without any Debian-specific files. That's fine. That'd be fine if I got some real help dealing with the underlying problem: the reliance on wx2.4. There is no guarantee - but chances are better if you push the problem to more helpers. As for the package, I'll fix and upload the minor issues, then tag the repository as wx2.4. Then copy over the wx2.8 port code in the repository in case someone wants to try cracking the problem. Just keep us informed if there is something to test. Again, thanks for your time and thoughts, Andreas. You are welcome Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462189: wxwindows2.4 is scheduled to be removed
On Apr 23, 2009, at 12:53 AM, Andreas Tille wrote: I wonder whether it might be a good idea to spend all effort on wx2.8 exclusively given the fact that wx2.6 is outdated as well. That might be reasonable. They're are many changes between wx2.6 and wx2.8 in terms of eliminating compiler errors. However, as far as dealing with runtime differences, it'll likely be easier to get it working on wx2.6 first. While I havn't any experience with wx and my GTK experience is only from very outdated GTK 1.2 I think it is a good strategy to track down problems like this to make a copy of your program and remove part by part so long as the error occures. Try to get the smallest piece of code which showas the problem - which should not be that much considering the fact that you said it is at font initialisation which should be quite at the beginning. When doing so in most cases I have seen the problem myself and in the remaining cases this small testcase is an easy target for helpers hanging around on relevant mailing lists Yes, that's a reasonable plan. I eliminated all my initialization code, but the segv still occurs on startup. The next step would be to start removing other, non-initializing code and declarations. However, at this time I don't have time to work on further efforts to port to a new version of wx. For my own needs, I can use CTSim on wx2.4, even if the package does not stay in Debian. Any logs / extract of this discussion to not waste time on reproducing just the same? I'd suggest to CC Debian Med mailing list for such discussions - the list is not that much crowded that it can not bear some extra technical discussion. I'm fairly sure that I no longer have a record of those messages with Barry, but I will check. Which tool did you use? valgrind? Yes. 2) I had the minor changes for Homepage, Vcs, Standards-Version -- but haven't uploaded them since the main issue is that I've not been able to successfully port to wx2.6 or 2.8. Considering the fact that new users are approaching from the distributors side and look at the large image before they dive into specific packages it would serve our users better if we would care better for things like this and so from a users perspective an updated package (even if it is rather cosmetics than technical progress) might make sense. Okay, it'd be no trouble to upload a package for wx2.4 that updates those minor, Debian specific metadata. As I said above if I where you I would try to force 2.8 to become main branch to make sure not to lag behind up to date libraries. The burden to maintain 3 branches in parallel using outdated libraries for two of them does not sound like a good strategy from an outsiders point of view. My guess is that you have to keep a working installation running for your local uses and so you are bound to the old wx2.4 based version - but if I were you I would put all effort into the wx2.8 based version. That would certainly simplify the git repository branch issues, though it'd leave code that doesn't work as the head of the master branch. But, I can tag the wx2.4 working code so that someone could go back to that tag for working code. Well, there are different steps inbetween if you are not completely happy with the way we agreed upon working together in the Debian Med team. Given the fact that it is generally a good idea to let the world know about the current status of your work - in our case related to Debian packaging - we invented the Debian Med svn[2]. There is actually no need to group maintain the package to use the SVN - single maintainers are welcome as well even it has turned out to be easier to apply such kind of changes like Homepage and Policy. We might be perfectly able to take this "burden" from you - I admit it is not much of a burden but Free Software more or less works that way that those people do the job who are at most interested to get it done. So group maintenance would have ensured that CTSim would look better on the tasks pages even now without draining any time of yours. It is your choice whether you think this is important for you or not. I'm not familiar with the policies of the Debian Med Team (I know, I know, as an M.D. I should be). I'll read the link that you provided for the Debian-Med Group Policy. I admit your situation being upstream and Debian maintainer in one person is a bit specific and makes your view on group maintenance a bit different. It's finally your choice. If the benefits of group maintenance outweighs the cost of segmenting my open-source packages from my own code server to an outside server, then I'm in favor of it. As for what would make the switch worthwhile, from my perspective, if a volunteer to work on the wx2.8 port What do you think about the following to enhance your workflow (as upstream *and* Debian developer): Considering you are maintain CTSim in a Git repository anyway
Bug#462189: wxwindows2.4 is scheduled to be removed
On Wed, 22 Apr 2009, Kevin Rosenberg wrote: 1) It's stored in a local git repository. I've made local git branches for porting to wx2.6 and wx2.8 I wonder whether it might be a good idea to spend all effort on wx2.8 exclusively given the fact that wx2.6 is outdated as well. with the main changes being conversions of all strings to Unicode. The source compiles without warnings, but segfaults during GTK font initialization. While I havn't any experience with wx and my GTK experience is only from very outdated GTK 1.2 I think it is a good strategy to track down problems like this to make a copy of your program and remove part by part so long as the error occures. Try to get the smallest piece of code which showas the problem - which should not be that much considering the fact that you said it is at font initialisation which should be quite at the beginning. When doing so in most cases I have seen the problem myself and in the remaining cases this small testcase is an easy target for helpers hanging around on relevant mailing lists I've worked a bit with the wx maintainer so took a look at the error, but no solution has been found. Any logs / extract of this discussion to not waste time on reproducing just the same? I'd suggest to CC Debian Med mailing list for such discussions - the list is not that much crowded that it can not bear some extra technical discussion. I went as fair as to comment out all the application-specific code from the wx startup function, but it still segfaults. I looked for string overflows, but didn't find any. Which tool did you use? valgrind? 2) I had the minor changes for Homepage, Vcs, Standards-Version -- but haven't uploaded them since the main issue is that I've not been able to successfully port to wx2.6 or 2.8. That's fine. Also there is no real need to upload such kind of cosmetics if you know that there are more pressing problems in the code. The problem regarding a missing Homepage tag is that there are different points of view: From a single package point of view it is a minor problem whether the homepage information is given in long description or in a separate field. From a distributors point of view (or from the blends perspective) information is harvested and used for a larger set of packages and it makes a more important point to provide a complete set of information fields. New techniques evolved since the last upload of CTSim for instance the Debian Med tasks pages and if you look at the CTSim entry[1] it looks foolisch to say that there is no homepage avialable and mention this page later in the long description. Considering the fact that new users are approaching from the distributors side and look at the large image before they dive into specific packages it would serve our users better if we would care better for things like this and so from a users perspective an updated package (even if it is rather cosmetics than technical progress) might make sense. Plus, I made those changes to the 2.6 or 2.8 branch and haven't quite figured out how to apply that patch to the wx2.4 (main) branch. As I said above if I where you I would try to force 2.8 to become main branch to make sure not to lag behind up to date libraries. The burden to maintain 3 branches in parallel using outdated libraries for two of them does not sound like a good strategy from an outsiders point of view. My guess is that you have to keep a working installation running for your local uses and so you are bound to the old wx2.4 based version - but if I were you I would put all effort into the wx2.8 based version. 3) I'd welcome help with the wx port and fixing current bugs. If group maintenance is the best way to achieve that, then I'm agreeable to that. Well, there are different steps inbetween if you are not completely happy with the way we agreed upon working together in the Debian Med team. Given the fact that it is generally a good idea to let the world know about the current status of your work - in our case related to Debian packaging - we invented the Debian Med svn[2]. There is actually no need to group maintain the package to use the SVN - single maintainers are welcome as well even it has turned out to be easier to apply such kind of changes like Homepage and Policy. We might be perfectly able to take this "burden" from you - I admit it is not much of a burden but Free Software more or less works that way that those people do the job who are at most interested to get it done. So group maintenance would have ensured that CTSim would look better on the tasks pages even now without draining any time of yours. It is your choice whether you think this is important for you or not. Alternately, I can handle all of the sophisticated mathematics in the program, so perhaps one time help on the wx port would be all would be necessary. Well, the Debian maintenance is not so much about your upstream code. We most probably will leave it untouched (as lon
Bug#462189: wxwindows2.4 is scheduled to be removed
The current status of CTSim is: 1) It's stored in a local git repository. I've made local git branches for porting to wx2.6 and wx2.8 with the main changes being conversions of all strings to Unicode. The source compiles without warnings, but segfaults during GTK font initialization. I've worked a bit with the wx maintainer so took a look at the error, but no solution has been found. I went as fair as to comment out all the application-specific code from the wx startup function, but it still segfaults. I looked for string overflows, but didn't find any. 2) I had the minor changes for Homepage, Vcs, Standards-Version -- but haven't uploaded them since the main issue is that I've not been able to successfully port to wx2.6 or 2.8. Plus, I made those changes to the 2.6 or 2.8 branch and haven't quite figured out how to apply that patch to the wx2.4 (main) branch. 3) I'd welcome help with the wx port and fixing current bugs. If group maintenance is the best way to achieve that, then I'm agreeable to that. Alternately, I can handle all of the sophisticated mathematics in the program, so perhaps one time help on the wx port would be all would be necessary. I prefer the latter, but, as above, I'm agreeable to the former. If it seems helpful, I can tarball my current git development repository and post it on my web server. (Since I'm not that familiar with dealing with branches between a development repository and my master git repository, I've not pushed the wx2.6 and wx2.8 local branches to ctsim's master public repository which is git://git.b9.com/ctsim.git.) If someone could help with pushing my local porting branches to a master git repository, that might be best so that everyone submit patches relative to the master repository. Thanks for your interest, Andreas, Kevin On Apr 20, 2009, at 4:42 PM, Andreas Tille wrote: On Sun, 15 Mar 2009, Moritz Muehlenhoff wrote: What's the status of the port of ctsim to a more recent wxwindows? GTK 1.2 is scheduled for removal (and wx2.4 along with it) Kevin, IMHO it would be a good idea if you would keep the Debian Med list informed about the current state of ctsim. The package is in danger to be removed, has some easy to fix wishlist bugs with patches, contains outdated (Standards-Version) and incomplete information in debian/control (Homepage, Vcs is missing). You did not answered my question [1] whether you agree to group maintenance. If you would I might try to upgrade the package to current policy and fix the bugs with patches. While doing so I might give recent wx stuff a try. Just give us an update please. Kind regards Andreas. [1] http://lists.debian.org/debian-med/2008/03/msg00085.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462189: wxwindows2.4 is scheduled to be removed
On Sun, 15 Mar 2009, Moritz Muehlenhoff wrote: What's the status of the port of ctsim to a more recent wxwindows? GTK 1.2 is scheduled for removal (and wx2.4 along with it) Kevin, IMHO it would be a good idea if you would keep the Debian Med list informed about the current state of ctsim. The package is in danger to be removed, has some easy to fix wishlist bugs with patches, contains outdated (Standards-Version) and incomplete information in debian/control (Homepage, Vcs is missing). You did not answered my question [1] whether you agree to group maintenance. If you would I might try to upgrade the package to current policy and fix the bugs with patches. While doing so I might give recent wx stuff a try. Just give us an update please. Kind regards Andreas. [1] http://lists.debian.org/debian-med/2008/03/msg00085.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462189: wxwindows2.4 is scheduled to be removed
Hi, Has there been any progress on this, now that wxwidgets2.8 is in unstable? Cheers, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462189: wxwindows2.4 is scheduled to be removed
Package: ctsim Version: 4.5.5-1 Severity: serious Hi, This is a heads up bug that we are attempting to get wxwindows2.4 removed from the archive (Hence the serious severity). I know we have spoken in the past you aren't particularly interested in transitioning to wx2.6 but hopefully we will get 2.8 or 3.0 in. Please let me know if I can help in any way. Thank you, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
