From: Brandon L. G. <br...@de...> - 2001-05-19 18:31:30
|
I plan on creating a debian package of Gramps. Actually I am half way done with it and thought I'd let you and everyone else on this list know that it is coming, as well as do the honorable thing and ask your blessing in creating it. My wife uses this program alot and seems to like it very much. You've probably gotten many emails from her about it (ShawnAnn Griffith). Anyhow here is what I plan on doing. I have noticed there is no manual page for gramps, since the debian policy does not *require* one but it heavily suggests one I will write a simple one for the purposes of the package. If you have already started on one please let me know and I'll cease, or if you wish for it to be a bit more expanded on information email me back with the important details you would like included and I'll do my best. Since I personally do not use this program I doubt my manual page will contain much information, that's why I'm asking you. The version I am packaging is your latest (v0.1.4) I should have this package finished by tonight and was wondering if you would rather me wait for a new release that might? be coming in the next few days. I do notice that this one if failry recent though, but I'm not sure if you are going to release a bug fix version tomorrow which would make this package obsolete before it was upladed to the apt mirrors. Once I am finished I will send you the official package *.deb if you'd like to have it displayed on your project page at sourceforge. Well, that's about it from me, don't want to bore you with all the details. Please email me back and let me know if there is anyhting you'd like to see included. Brandon L. Griffith Give me liberty or give me something <br...@de...> of equal or lesser value from your <bgr...@le...> glossy 30 page catalog. |
From: Ross G. <ro...@th...> - 2013-11-27 21:58:09
|
Hi All, James Treacy has "orphaned" the Gramps package in Debian due to a lack of time. So I have taken over the maintenance and 3.4.6 has been uploaded. Of course as a new maintainer, I will need a sponsorship for each upload for a while. My next task will be to try and get Gramps 4.0.2 into Debian experimental and using Python 3. Once everything seems stable, all the dependencies are in place etc. it will be simple to switch to the 4.0.x series. Anyway, I just wanted you all to know that I am lurking on the list if you need to get hold of me. Cheers, Ross |
From: Vassilii K. <vas...@ta...> - 2013-11-28 09:45:48
|
Hi Ross, Welcome to your official new capacity, thanks for packaging us. Hopefully you'll also send more patches our way, too! V. |
From: Paul F. <pf....@gm...> - 2013-11-29 16:20:31
|
I second the welcome! Very much, as I will be happy to see the bug reports from gramps "3.4.0" users disappearing!! As I am not a Debian/Ubuntu user I do not claim to be an expert, but if I understand correctly then 3.4.6 is scheduled to appear in Ubuntu 14.4 -- so I wonder if it is possible for users of earlier releases to get it? Thanks again, and "welcome" also! |
From: Ross G. <ro...@th...> - 2013-11-29 16:56:14
|
On 11/29/2013 05:20 PM, Paul Franklin wrote: > As I am not a Debian/Ubuntu user I do not claim to be an expert, > but if I understand correctly then 3.4.6 is scheduled to appear in > Ubuntu 14.4 -- so I wonder if it is possible for users of earlier > releases to get it? > Hi Paul - and thanks for your encouragement all the way along! I believe 3.4.6 has already synced across to the Ubuntu development release (Trusty Tahr - 14.04). There is the possibility to "pin" a package to a different release from your default repository in both Debian and Ubuntu. Here is the Ubuntu wiki: https://help.ubuntu.com/community/PinningHowto You shouldn't do it if it is likely to pull in lots of new dependencies, but that shouldn't be a problem from 3.4.0 - 3.4.6. Cheers, Ross |
From: Jerome <rom...@ya...> - 2013-11-29 18:00:12
|
Thank you Ross! Note, should we try to merge changes[1] to gramps' git (at least /debian[2] for 3.4.x)? [1] http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary [2] http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian Le mer. 27 nov. 2013 at 22:45,Ross Gammon <ro...@th...> a écrit : > Hi All, > > James Treacy has "orphaned" the Gramps package in Debian due to a lack > of time. So I have taken over the maintenance and 3.4.6 has been > uploaded. Of course as a new maintainer, I will need a sponsorship for > each upload for a while. > > My next task will be to try and get Gramps 4.0.2 into Debian > experimental and using Python 3. Once everything seems stable, all the > dependencies are in place etc. it will be simple to switch to the > 4.0.x series. > > Anyway, I just wanted you all to know that I am lurking on the list if > you need to get hold of me. > > Cheers, > > Ross > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most > IT > organizations don't have a clear picture of how application > performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Ross G. <ro...@th...> - 2013-11-29 18:43:52
|
On 11/29/2013 06:59 PM, Jerome wrote: > > Thank you Ross! > > Note, should we try to merge changes[1] to gramps' git (at least > /debian[2] for 3.4.x)? > > [1] http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary > [2] > http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian > > The standard Debian approach to packaging is to take the tarball from the upstream project and "debianise" it. The tarballs should not contain a /debian directory and are supposed to be deleted if they do. But you are welcome to take bits of the debian directory for use in the debs on the Gramps sourceforge site. Most of the tweaks I did (with the help of my sponsor) were to bring the package up to date with the latest best practise in Debian, and therefore to avoid the errors and warnings when you run "lintian" on the package. You don't need the watch file (which is just watching the Gramps Sourceforge site checking for new releases), or the source/local-options file (which is just a config file for the collab-maint git repository). And it is probably best if the changelog and control files look a bit different in both debs. Then if we get any strange problems in the future we can work out which deb file a user installed from. |
From: Benny M. <ben...@gm...> - 2013-12-02 12:38:23
|
Ross, First Tracy had commit access. I think he made the debian dir. If changes needed (delete eg), let us know. It's a pity now all of the original 'old' Gramps team are gone. Second, an option is to have gramps3 and current gramps run side by side by users to ease transition would be nice. I run them side by side from source, gramps3 will normally still be supported for a year. As gramps3 is installed as a program, and new gramps as a python module, not difficult to achieve. Only the /usr/bin script needs to be called gramps3 instead, and some mime type head-aches on which has preference. As to gramps 4.x and python 3, please still use it with python 2. Python 3 is supported but not the default yet, no need to life on the edge. As it is a python module, a python3 and python2 version is possible, but users installing both will have problems with databases (no corruption though, just database not opening with python2 if ever opened with python3, requiring export/import to move back to python 2). So, you are looking at: 1. making sure installing gramps34 of stable and also gramps40 should not cause headaches. You could enforce removal of gramps34 once 40 is installed 2. gramps40 as python2 and as python3 package. Again, /usr/bin script to select what to use. Perhaps gramps --> python 2 40 version, gramps3 -> python 3 40 version, and if gramps34 allowed in parellel: gramps2_34 ?? Does Debian follow the Ubuntu way of python packages being called python-gramps? If so, that is another change. Benny 2013/11/29 Ross Gammon <ro...@th...> > On 11/29/2013 06:59 PM, Jerome wrote: > > > > Thank you Ross! > > > > Note, should we try to merge changes[1] to gramps' git (at least > > /debian[2] for 3.4.x)? > > > > [1] > http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary > > [2] > > > http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian > > > > > The standard Debian approach to packaging is to take the tarball from > the upstream project and "debianise" it. The tarballs should not contain > a /debian directory and are supposed to be deleted if they do. > > But you are welcome to take bits of the debian directory for use in the > debs on the Gramps sourceforge site. Most of the tweaks I did (with the > help of my sponsor) were to bring the package up to date with the latest > best practise in Debian, and therefore to avoid the errors and warnings > when you run "lintian" on the package. > > You don't need the watch file (which is just watching the Gramps > Sourceforge site checking for new releases), or the source/local-options > file (which is just a config file for the collab-maint git repository). > And it is probably best if the changelog and control files look a bit > different in both debs. Then if we get any strange problems in the > future we can work out which deb file a user installed from. > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jerome <rom...@ya...> - 2013-12-04 13:46:31
|
Ok, thanks! I added two experimental .deb - one with webapp environment, the second without- on unstable section: http://sourceforge.net/projects/gramps/files/Unstable/ Both provides python-gramps 4.0.2 (desktop app) for python 2.7, either with webapp files or without. See '--server' argument from 'setup.py'. Control can complain about missing gramps' dependencies with the webapp, because the focus was rather on checking 'python-sqlite' and 'python-django'! They have been generated after merging some of your improvements to gramps git repository (gramps40). I still need to modify a little bit 'setup.py' for generating the ressource path, and I do not know if there is a safe WSGI support for the webapp? Jérôme Le ven. 29 nov. 2013 at 19:43,Ross Gammon <ro...@th...> a écrit : > On 11/29/2013 06:59 PM, Jerome wrote: >> >> Thank you Ross! >> >> Note, should we try to merge changes[1] to gramps' git (at least >> /debian[2] for 3.4.x)? >> >> [1] >> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary >> [2] >> >> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian >> >> >> > The standard Debian approach to packaging is to take the tarball from > the upstream project and "debianise" it. The tarballs should not > contain > a /debian directory and are supposed to be deleted if they do. > > But you are welcome to take bits of the debian directory for use in > the > debs on the Gramps sourceforge site. Most of the tweaks I did (with > the > help of my sponsor) were to bring the package up to date with the > latest > best practise in Debian, and therefore to avoid the errors and > warnings > when you run "lintian" on the package. > > You don't need the watch file (which is just watching the Gramps > Sourceforge site checking for new releases), or the > source/local-options > file (which is just a config file for the collab-maint git > repository). > And it is probably best if the changelog and control files look a bit > different in both debs. Then if we get any strange problems in the > future we can work out which deb file a user installed from. > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most > IT > organizations don't have a clear picture of how application > performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2013-12-04 13:52:40
|
On Wed, Dec 4, 2013 at 8:46 AM, Jerome <rom...@ya...> wrote: > > Ok, thanks! > > I added two experimental .deb - one with webapp environment, the second > without- on unstable section: > http://sourceforge.net/projects/gramps/files/Unstable/ > > Both provides python-gramps 4.0.2 (desktop app) for python 2.7, > either with webapp files or without. See '--server' argument from > 'setup.py'. > Control can complain about missing gramps' dependencies with the > webapp, because the focus was rather on checking 'python-sqlite' and > 'python-django'! > > They have been generated after merging some of your improvements to > gramps git repository (gramps40). > > I still need to modify a little bit 'setup.py' for generating the > ressource path, and I do not know if there is a safe WSGI support for > the webapp? What do you mean "safe WSGI support"? I can provide a template for running the webapp under WSGI. There are lots of options for running the webapp (database backend, static file server, web server, etc). Should we just make a package that assumes apache, sqlite, and wsgi as an illustration, and provide hints on how to adapt? -Doug > > Jérôme > > > Le ven. 29 nov. 2013 at 19:43,Ross Gammon <ro...@th...> a > écrit : >> On 11/29/2013 06:59 PM, Jerome wrote: >>> >>> Thank you Ross! >>> >>> Note, should we try to merge changes[1] to gramps' git (at least >>> /debian[2] for 3.4.x)? >>> >>> [1] >>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary >>> [2] >>> >>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian >>> >>> >>> >> The standard Debian approach to packaging is to take the tarball from >> the upstream project and "debianise" it. The tarballs should not >> contain >> a /debian directory and are supposed to be deleted if they do. >> >> But you are welcome to take bits of the debian directory for use in >> the >> debs on the Gramps sourceforge site. Most of the tweaks I did (with >> the >> help of my sponsor) were to bring the package up to date with the >> latest >> best practise in Debian, and therefore to avoid the errors and >> warnings >> when you run "lintian" on the package. >> >> You don't need the watch file (which is just watching the Gramps >> Sourceforge site checking for new releases), or the >> source/local-options >> file (which is just a config file for the collab-maint git >> repository). >> And it is probably best if the changelog and control files look a bit >> different in both debs. Then if we get any strange problems in the >> future we can work out which deb file a user installed from. >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most >> IT >> organizations don't have a clear picture of how application >> performance >> affects their revenue. With AppDynamics, you get 100% visibility into >> your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Jerome <rom...@ya...> - 2013-12-04 15:01:43
|
In fact, the experimental .deb with webapp files does not ran additional commands. It just provides the environment. Maybe like fedora's rpm[1? Yes, by safe "safe WSGI support", I just thought on "ready for a web server" (not the local static one)! I suppose it is like any webapp (eg, GeneWeb[3][4]), but a configuration dialog or like your proposal a template might be more user friendly? I do not like much manual edition of files after an installation via a deb file (with root rights, md5 hashes, etc ...). Is it not possible to use a path like '.local/share/gramps/webapp.ini' for launching something with user rights, then to ask for logging (admin tasks), etc .. Yes, if possible, to provide hints on how to adapt. I do not know if it is easy to get something like that or if there is a need. What do you think? [1] http://kojipkgs.fedoraproject.org//packages/gramps/4.0.2/1.fc20/data/logs/noarch/build.log [2] http://gramps-project.org/wiki/index.php?title=Gramps-Connect#Running_on_a_real_system [3] http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gwtp/README [4] http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gui/gui.ml Le mer. 4 déc. 2013 at 14:52,Doug Blank <dou...@gm...> a écrit : > On Wed, Dec 4, 2013 at 8:46 AM, Jerome <rom...@ya...> wrote: >> >> Ok, thanks! >> >> I added two experimental .deb - one with webapp environment, the >> second >> without- on unstable section: >> http://sourceforge.net/projects/gramps/files/Unstable/ >> >> Both provides python-gramps 4.0.2 (desktop app) for python 2.7, >> either with webapp files or without. See '--server' argument from >> 'setup.py'. >> Control can complain about missing gramps' dependencies with the >> webapp, because the focus was rather on checking 'python-sqlite' and >> 'python-django'! >> >> They have been generated after merging some of your improvements to >> gramps git repository (gramps40). >> >> I still need to modify a little bit 'setup.py' for generating the >> ressource path, and I do not know if there is a safe WSGI support >> for >> the webapp? >> > What do you mean "safe WSGI support"? I can provide a template for > running the webapp under WSGI. > > There are lots of options for running the webapp (database backend, > static file server, web server, etc). Should we just make a package > that assumes apache, sqlite, and wsgi as an illustration, and provide > hints on how to adapt? > > -Doug > >> >> Jérôme >> >> >> Le ven. 29 nov. 2013 at 19:43,Ross Gammon <ro...@th...> a >> écrit : >>> On 11/29/2013 06:59 PM, Jerome wrote: >>>> >>>> Thank you Ross! >>>> >>>> Note, should we try to merge changes[1] to gramps' git (at least >>>> /debian[2] for 3.4.x)? >>>> >>>> [1] >>>> >>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary >>>> [2] >>>> >>>> >>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian >>>> >>>> >>>> >>>> >>> The standard Debian approach to packaging is to take the tarball >>> from >>> the upstream project and "debianise" it. The tarballs should not >>> contain >>> a /debian directory and are supposed to be deleted if they do. >>> >>> But you are welcome to take bits of the debian directory for use in >>> the >>> debs on the Gramps sourceforge site. Most of the tweaks I did (with >>> the >>> help of my sponsor) were to bring the package up to date with the >>> latest >>> best practise in Debian, and therefore to avoid the errors and >>> warnings >>> when you run "lintian" on the package. >>> >>> You don't need the watch file (which is just watching the Gramps >>> Sourceforge site checking for new releases), or the >>> source/local-options >>> file (which is just a config file for the collab-maint git >>> repository). >>> And it is probably best if the changelog and control files look a >>> bit >>> different in both debs. Then if we get any strange problems in the >>> future we can work out which deb file a user installed from. >>> >>> >>> ------------------------------------------------------------------------------ >>> Rapidly troubleshoot problems before they affect your business. >>> Most >>> IT >>> organizations don't have a clear picture of how application >>> performance >>> affects their revenue. With AppDynamics, you get 100% visibility >>> into >>> your >>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >>> AppDynamics Pro! >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Sponsored by Intel(R) XDK >> Develop, test and display web and hybrid apps with a single code >> base. >> Download it for free now! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> |
From: Ross G. <ro...@th...> - 2013-12-04 19:06:05
|
Okay - looks like there is a clear way forward. Python 2 for now & go modular. I hadn't thought about the webapp at all. It had been on my todo list for a while (to try it out). There is no need to take Debian a completely different way to RPM land either. Currently searching for a similar gui/web modular split in debian for inspiration! On 12/04/2013 04:01 PM, Jerome wrote: > > In fact, the experimental .deb with webapp files does not ran > additional commands. It just provides the environment. Maybe like > fedora's rpm[1? > > Yes, by safe "safe WSGI support", I just thought on "ready for a > web server" (not the local static one)! I suppose it is like any > webapp (eg, GeneWeb[3][4]), but a configuration dialog or like your > proposal a template might be more user friendly? > > I do not like much manual edition of files after an installation > via a deb file (with root rights, md5 hashes, etc ...). Is it not > possible to use a path like '.local/share/gramps/webapp.ini' for > launching something with user rights, then to ask for logging > (admin tasks), etc .. > > Yes, if possible, to provide hints on how to adapt. I do not know > if it is easy to get something like that or if there is a need. > What do you think? > > > [1] > http://kojipkgs.fedoraproject.org//packages/gramps/4.0.2/1.fc20/data/logs/noarch/build.log > > [2] > http://gramps-project.org/wiki/index.php?title=Gramps-Connect#Running_on_a_real_system > > [3] > http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gwtp/README > > [4] > http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gui/gui.ml > > > > > Le mer. 4 déc. 2013 at 14:52,Doug Blank <dou...@gm...> a > écrit : >> On Wed, Dec 4, 2013 at 8:46 AM, Jerome <rom...@ya...> >> wrote: >>> >>> Ok, thanks! >>> >>> I added two experimental .deb - one with webapp environment, >>> the second without- on unstable section: >>> http://sourceforge.net/projects/gramps/files/Unstable/ >>> >>> Both provides python-gramps 4.0.2 (desktop app) for python >>> 2.7, either with webapp files or without. See '--server' >>> argument from 'setup.py'. Control can complain about missing >>> gramps' dependencies with the webapp, because the focus was >>> rather on checking 'python-sqlite' and 'python-django'! >>> >>> They have been generated after merging some of your >>> improvements to gramps git repository (gramps40). >>> >>> I still need to modify a little bit 'setup.py' for generating >>> the ressource path, and I do not know if there is a safe WSGI >>> support for the webapp? >>> >> What do you mean "safe WSGI support"? I can provide a template >> for running the webapp under WSGI. >> >> There are lots of options for running the webapp (database >> backend, static file server, web server, etc). Should we just >> make a package that assumes apache, sqlite, and wsgi as an >> illustration, and provide hints on how to adapt? >> >> -Doug >> >>> >>> Jérôme >>> >>> >>> Le ven. 29 nov. 2013 at 19:43,Ross Gammon >>> <ro...@th...> a écrit : >>>> On 11/29/2013 06:59 PM, Jerome wrote: >>>>> >>>>> Thank you Ross! >>>>> >>>>> Note, should we try to merge changes[1] to gramps' git (at >>>>> least /debian[2] for 3.4.x)? >>>>> >>>>> [1] >>>>> >>>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary >>>>> >>>>> [2] >>>>> >>>>> >>>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian |
From: Jerome <rom...@ya...> - 2013-12-05 08:23:18
|
My first idea was to try to split into multiple packages: * core/cli + data * gui (gtk) (need core/cli) * web (webapp) (need core/cli) * translations (eg, we could generate a new version for fixing a typo) As work on webapp is still in progess, the current way (set on setup.py) was the easiest and maybe the more safe for the moment? About WSGI, I cannot explain with the right terms, but to have something close to a very light 'PythonAnywhere' (proprietary application framework). Maybe something like the feature named "in-browser interactive consoles"[1]? [1] https://en.wikipedia.org/wiki/PythonAnywhere#Features Le mer. 4 déc. 2013 at 20:05,Ross Gammon <ro...@th...> a écrit : > Okay - looks like there is a clear way forward. Python 2 for now & go > modular. I hadn't thought about the webapp at all. It had been on my > todo list for a while (to try it out). There is no need to take Debian > a completely different way to RPM land either. > > Currently searching for a similar gui/web modular split in debian for > inspiration! > > On 12/04/2013 04:01 PM, Jerome wrote: >> >> In fact, the experimental .deb with webapp files does not run >> additional commands. It just provides the environment. Maybe like >> fedora's rpm[1? >> >> Yes, by safe "safe WSGI support", I just thought on "ready for a >> web server" (not the local static one)! I suppose it is like any >> webapp (eg, GeneWeb[3][4]), but a configuration dialog or like your >> proposal a template might be more user friendly? >> >> I do not like much manual edition of files after an installation >> via a deb file (with root rights, md5 hashes, etc ...). Is it not >> possible to use a path like '.local/share/gramps/webapp.ini' for >> launching something with user rights, then to ask for logging >> (admin tasks), etc .. >> >> Yes, if possible, to provide hints on how to adapt. I do not know >> if it is easy to get something like that or if there is a need. >> What do you think? >> >> >> [1] >> >> http://kojipkgs.fedoraproject.org//packages/gramps/4.0.2/1.fc20/data/logs/noarch/build.log >> >> [2] >> >> http://gramps-project.org/wiki/index.php?title=Gramps-Connect#Running_on_a_real_system >> >> [3] >> >> http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gwtp/README >> >> [4] >> >> http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gui/gui.ml >> >> >> >> >> Le mer. 4 déc. 2013 at 14:52,Doug Blank <dou...@gm...> a >> écrit : >>> On Wed, Dec 4, 2013 at 8:46 AM, Jerome <rom...@ya...> >>> wrote: >>>> >>>> Ok, thanks! >>>> >>>> I added two experimental .deb - one with webapp environment, >>>> the second without- on unstable section: >>>> http://sourceforge.net/projects/gramps/files/Unstable/ >>>> >>>> Both provides python-gramps 4.0.2 (desktop app) for python >>>> 2.7, either with webapp files or without. See '--server' >>>> argument from 'setup.py'. Control can complain about missing >>>> gramps' dependencies with the webapp, because the focus was >>>> rather on checking 'python-sqlite' and 'python-django'! >>>> >>>> They have been generated after merging some of your >>>> improvements to gramps git repository (gramps40). >>>> >>>> I still need to modify a little bit 'setup.py' for generating >>>> the ressource path, and I do not know if there is a safe WSGI >>>> support for the webapp? >>>> >>>> >>> What do you mean "safe WSGI support"? I can provide a template >>> for running the webapp under WSGI. >>> >>> There are lots of options for running the webapp (database >>> backend, static file server, web server, etc). Should we just >>> make a package that assumes apache, sqlite, and wsgi as an >>> illustration, and provide hints on how to adapt? >>> >>> -Doug >>> >>>> >>>> Jérôme >>>> >>>> >>>> Le ven. 29 nov. 2013 at 19:43,Ross Gammon >>>> <ro...@th...> a écrit : >>>>> On 11/29/2013 06:59 PM, Jerome wrote: >>>>>> >>>>>> Thank you Ross! >>>>>> >>>>>> Note, should we try to merge changes[1] to gramps' git (at >>>>>> least /debian[2] for 3.4.x)? >>>>>> >>>>>> [1] >>>>>> >>>>>> >>>>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary >>>>>> >>>>>> >>>>>> > [2] >>>>>> >>>>>> >>>>>> >>>>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian >>>>>> > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Ross G. <ro...@th...> - 2013-12-07 23:02:17
|
Tried splitting gramps into gui, common & webapp. It was fairly easy to write a debian/*.install file for the common & webapp modules (that would install the right directories if you did apt-get install python-gramps-webapp). But doing one for "the rest" (gui) gave me a few problems. I will go back to try and solve that later. I need to do a bit more research on packaging Django in Debian anyway. The Debian wiki has more questions than answers :-) : https://wiki.debian.org/DjangoPackagingDraft So today I worked on trying to package dual python 2 & 3. I have got it building both python-gramps and python3-gramps modules in one go. But as Benny pointed out, there needs to be a gramps3 /usr/bin script and there are the mime types to sort out. You can see what I have so far (debian/control & debian/rules): http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=shortlog;h=refs/heads/experimental I know Jerome has already done it, but for the record: $ git clone git://git.debian.org/git/collab-maint/gramps.git Then checkout the experimental branch. I normally build using dpkg-buildpackage -us -us. Then you will get the two debs (only one of which works of course). I may have a bit of time on this tomorrow - but not much. Cheers, Ross On 12/05/2013 09:22 AM, Jerome wrote: > > My first idea was to try to split into multiple packages: > > * core/cli + data > * gui (gtk) (need core/cli) > * web (webapp) (need core/cli) > * translations (eg, we could generate a new version for fixing a typo) > > As work on webapp is still in progess, the current way (set on setup.py) > was the easiest and maybe the more safe for the moment? > > About WSGI, I cannot explain with the right terms, but to have something > close to a very light 'PythonAnywhere' (proprietary application > framework). Maybe something like the feature named "in-browser > interactive consoles"[1]? > > [1] https://en.wikipedia.org/wiki/PythonAnywhere#Features > > > Le mer. 4 déc. 2013 at 20:05,Ross Gammon <ro...@th...> a écrit : >> Okay - looks like there is a clear way forward. Python 2 for now & go >> modular. I hadn't thought about the webapp at all. It had been on my >> todo list for a while (to try it out). There is no need to take Debian >> a completely different way to RPM land either. >> >> Currently searching for a similar gui/web modular split in debian for >> inspiration! >> >> On 12/04/2013 04:01 PM, Jerome wrote: >>> >>> In fact, the experimental .deb with webapp files does not run >>> additional commands. It just provides the environment. Maybe like >>> fedora's rpm[1? >>> >>> Yes, by safe "safe WSGI support", I just thought on "ready for a >>> web server" (not the local static one)! I suppose it is like any >>> webapp (eg, GeneWeb[3][4]), but a configuration dialog or like your >>> proposal a template might be more user friendly? >>> >>> I do not like much manual edition of files after an installation >>> via a deb file (with root rights, md5 hashes, etc ...). Is it not >>> possible to use a path like '.local/share/gramps/webapp.ini' for >>> launching something with user rights, then to ask for logging >>> (admin tasks), etc .. >>> >>> Yes, if possible, to provide hints on how to adapt. I do not know >>> if it is easy to get something like that or if there is a need. >>> What do you think? >>> >>> >>> [1] >>> http://kojipkgs.fedoraproject.org//packages/gramps/4.0.2/1.fc20/data/logs/noarch/build.log >>> >>> >>> [2] >>> http://gramps-project.org/wiki/index.php?title=Gramps-Connect#Running_on_a_real_system >>> >>> >>> [3] >>> http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gwtp/README >>> >>> >>> [4] >>> http://opensource.geneanet.org/projects/geneweb/repository/revisions/master/entry/gui/gui.ml >>> >>> >>> >>> >>> >>> Le mer. 4 déc. 2013 at 14:52,Doug Blank <dou...@gm...> a >>> écrit : >>>> On Wed, Dec 4, 2013 at 8:46 AM, Jerome <rom...@ya...> >>>> wrote: >>>>> >>>>> Ok, thanks! >>>>> >>>>> I added two experimental .deb - one with webapp environment, >>>>> the second without- on unstable section: >>>>> http://sourceforge.net/projects/gramps/files/Unstable/ >>>>> >>>>> Both provides python-gramps 4.0.2 (desktop app) for python >>>>> 2.7, either with webapp files or without. See '--server' >>>>> argument from 'setup.py'. Control can complain about missing >>>>> gramps' dependencies with the webapp, because the focus was >>>>> rather on checking 'python-sqlite' and 'python-django'! >>>>> >>>>> They have been generated after merging some of your >>>>> improvements to gramps git repository (gramps40). >>>>> >>>>> I still need to modify a little bit 'setup.py' for generating >>>>> the ressource path, and I do not know if there is a safe WSGI >>>>> support for the webapp? >>>>> >>>>> >>>> What do you mean "safe WSGI support"? I can provide a template >>>> for running the webapp under WSGI. >>>> >>>> There are lots of options for running the webapp (database >>>> backend, static file server, web server, etc). Should we just >>>> make a package that assumes apache, sqlite, and wsgi as an >>>> illustration, and provide hints on how to adapt? >>>> >>>> -Doug >>>> >>>>> >>>>> Jérôme >>>>> >>>>> >>>>> Le ven. 29 nov. 2013 at 19:43,Ross Gammon >>>>> <ro...@th...> a écrit : >>>>>> On 11/29/2013 06:59 PM, Jerome wrote: >>>>>>> >>>>>>> Thank you Ross! >>>>>>> >>>>>>> Note, should we try to merge changes[1] to gramps' git (at >>>>>>> least /debian[2] for 3.4.x)? >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> >>>>>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=summary >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> [2] >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git;a=tree;f=debian |
From: Ross G. <ro...@th...> - 2013-12-02 18:59:55
|
Thanks Benny, On 12/02/2013 01:38 PM, Benny Malengier wrote: > Ross, > > First Tracy had commit access. I think he made the debian dir. If > changes needed (delete eg), let us know. It's a pity now all of > the original 'old' Gramps team are gone. No need to do anything in particular as far as I know. It is a shame that James no longer had the time to spare, but the great thing about free software is that it can keep going! > > Second, an option is to have gramps3 and current gramps run side by > side by users to ease transition would be nice. I run them side by > side from source, gramps3 will normally still be supported for a > year. > > As gramps3 is installed as a program, and new gramps as a python > module, not difficult to achieve. Only the /usr/bin script needs to > be called gramps3 instead, and some mime type head-aches on which > has preference. > > As to gramps 4.x and python 3, please still use it with python 2. > Python 3 is supported but not the default yet, no need to life on > the edge. Now that the latest Gramps 3.4 is in Debian, I have been working over the last week to see how I could package Gramps 4.0. First I switched the packaging to use the latest Debian Python Team policy for packaging with distutils applications instead of autotools (leaving it in python 2). Then I switched to python 3. The intention was to do what other python applications are doing in Debian for packages that are python 3 aware, and defaulting to python 3 during installation if it is available on the system, but using python 2 if not. However, over the weekend I was testing all the dependencies for Gramps in python 3 mode, and there were 5 of them where there is still no up-to-date package available in Debian unstable (2 of them strongly recommended in the README). Until your email, I was thinking of putting Gramps 4 into Debian experimental, so that the Debian/Ubuntu users out there keen to be on the edge could report bugs and improve the python 3 version of Gramps. In the meantime I could chase around all the maintainers of the missing dependencies to try and get them updated. Then I could release it to unstable once everything looked fine. > As it is a python module, a python3 and python2 version is > possible, but users installing both will have problems with > databases (no corruption though, just database not opening with > python2 if ever opened with python3, requiring export/import to > move back to python 2). > > So, you are looking at: 1. making sure installing gramps34 of > stable and also gramps40 should not cause headaches. You could > enforce removal of gramps34 once 40 is installed 2. gramps40 as > python2 and as python3 package. Again, /usr/bin script to select > what to use. Perhaps gramps --> python 2 40 version, gramps3 -> > python 3 40 version, and if gramps34 allowed in parellel: > gramps2_34 ?? > Thanks for the extra options :-) With this we can also probably deal with the different dependencies for python2/3 in a tidier way. Anyway, as I am not yet a Debian Maintainer with full upload rights, I have to get each upload sponsored. I will seek the opinion of my mentors and see what they advise. > Does Debian follow the Ubuntu way of python packages being called > python-gramps? If so, that is another change. Yes - python applications can just have their name. Python modules must now start with python- (e.g. python-foo). There are plenty of examples of other naming conventions in Debian before that one was decided though! > > Benny > If my sponsors prefer not to go the dual approach, what would be the preference from a Gramps perspective: 1. Get Gramps 4.0 out in Debian/Ubuntu land in python 2 form with little loss of functionality, but no feedback on python 3 specific problems? 2. Get Gramps 4.0 into Debian experimental in python 3 mode and start getting feedback on stability whilst we get all the dependencies in line? Regards, Ross |
From: Benny M. <ben...@gm...> - 2013-12-03 08:25:51
|
2013/12/2 Ross Gammon <ro...@th...> > Thanks Benny, > > On 12/02/2013 01:38 PM, Benny Malengier wrote: > > Ross, > > > > First Tracy had commit access. I think he made the debian dir. If > > changes needed (delete eg), let us know. It's a pity now all of > > the original 'old' Gramps team are gone. > > No need to do anything in particular as far as I know. It is a shame > that James no longer had the time to spare, but the great thing about > free software is that it can keep going! > > > > Second, an option is to have gramps3 and current gramps run side by > > side by users to ease transition would be nice. I run them side by > > side from source, gramps3 will normally still be supported for a > > year. > > > > As gramps3 is installed as a program, and new gramps as a python > > module, not difficult to achieve. Only the /usr/bin script needs to > > be called gramps3 instead, and some mime type head-aches on which > > has preference. > > > > As to gramps 4.x and python 3, please still use it with python 2. > > Python 3 is supported but not the default yet, no need to life on > > the edge. > > Now that the latest Gramps 3.4 is in Debian, I have been working over > the last week to see how I could package Gramps 4.0. First I switched > the packaging to use the latest Debian Python Team policy for > packaging with distutils applications instead of autotools (leaving it > in python 2). Then I switched to python 3. The intention was to do > what other python applications are doing in Debian for packages that > are python 3 aware, and defaulting to python 3 during installation if > it is available on the system, but using python 2 if not. However, > over the weekend I was testing all the dependencies for Gramps in > python 3 mode, and there were 5 of them where there is still no > up-to-date package available in Debian unstable (2 of them strongly > recommended in the README). > Until your email, I was thinking of putting Gramps 4 into Debian > experimental, so that the Debian/Ubuntu users out there keen to be on > the edge could report bugs and improve the python 3 version of Gramps. > In the meantime I could chase around all the maintainers of the > missing dependencies to try and get them updated. Then I could release > it to unstable once everything looked fine. > > > As it is a python module, a python3 and python2 version is > > possible, but users installing both will have problems with > > databases (no corruption though, just database not opening with > > python2 if ever opened with python3, requiring export/import to > > move back to python 2). > > > > So, you are looking at: 1. making sure installing gramps34 of > > stable and also gramps40 should not cause headaches. You could > > enforce removal of gramps34 once 40 is installed 2. gramps40 as > > python2 and as python3 package. Again, /usr/bin script to select > > what to use. Perhaps gramps --> python 2 40 version, gramps3 -> > > python 3 40 version, and if gramps34 allowed in parellel: > > gramps2_34 ?? > > > Thanks for the extra options :-) With this we can also probably deal > with the different dependencies for python2/3 in a tidier way. Anyway, > as I am not yet a Debian Maintainer with full upload rights, I have to > get each upload sponsored. I will seek the opinion of my mentors and > see what they advise. > > > Does Debian follow the Ubuntu way of python packages being called > > python-gramps? If so, that is another change. > > Yes - python applications can just have their name. Python modules > must now start with python- (e.g. python-foo). There are plenty of > examples of other naming conventions in Debian before that one was > decided though! > > > > Benny > > > If my sponsors prefer not to go the dual approach, what would be the > preference from a Gramps perspective: > 1. Get Gramps 4.0 out in Debian/Ubuntu land in python 2 form with > little loss of functionality, but no feedback on python 3 specific > problems? > 2. Get Gramps 4.0 into Debian experimental in python 3 mode and start > getting feedback on stability whilst we get all the dependencies in line? > Gramps34 will very quickly be deprecated once windows installer works. So the faster you move to gramps40 the better for us. Windows gramps4 is on python2. The Mac version also. So best that the linux default is also still python2. We are compatible with python3, but Gramps40 is the first which has that, and there will still be bugs, as almost all developers still work in python2. We aim to allow python3 as default for Gramps41. Then Mac python3 and windows python3 might also be possible. About Gramps as python module. We rewrote gramps so that with Gramps4.0 other applications can do: from gramps.gen import Person Aim here is to allow the core library (database access, object model) to be reusable, and to be able to run all the reporting independent in another program. So you should consider it as a python module. The aim is to go to two interfaces: the GTK gui and the Django web application. For the Django app, all non GUI parts will not be needed, it can run headless. We did not decide yet if we want to move to split packages in the future, at the moment you install all or nothing. For the typical Gramps users this is the best. Allowing for an option in the setup.py could be quickly done though. Benny > > Regards, > > Ross > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Paul F. <pf....@gm...> - 2013-12-03 17:26:24
|
On 12/3/13, Benny Malengier <ben...@gm...> wrote: > So you should consider it as a python module. The aim is to go to two > interfaces: the GTK gui and the Django web application. For the Django app, > all non GUI parts will not be needed, it can run headless. We did not > decide yet if we want to move to split packages in the future, at the > moment you install all or nothing. Fedora 20 will have: gramps-4.0.2-1.fc20.noarch.rpm gramps-common-4.0.2-1.fc20.noarch.rpm gramps-webapp-4.0.2-1.fc20.noarch.rpm |
From: Doug B. <dou...@gm...> - 2013-12-03 17:38:32
|
On Tue, Dec 3, 2013 at 12:26 PM, Paul Franklin <pf....@gm...> wrote: > On 12/3/13, Benny Malengier <ben...@gm...> wrote: >> So you should consider it as a python module. The aim is to go to two >> interfaces: the GTK gui and the Django web application. For the Django app, >> all non GUI parts will not be needed, it can run headless. We did not >> decide yet if we want to move to split packages in the future, at the >> moment you install all or nothing. > > Fedora 20 will have: > > gramps-4.0.2-1.fc20.noarch.rpm > gramps-common-4.0.2-1.fc20.noarch.rpm > gramps-webapp-4.0.2-1.fc20.noarch.rpm Excellent! Where are the sources for these? Will the webapp package setup the backend database and WSGI so that it is ready to use on the server? That would be great. -Doug > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Jerome <rom...@ya...> - 2013-12-03 17:42:44
|
http://www.rpmfind.net/linux/rpm2html/search.php?query=gramps-webapp Le mar. 3 déc. 2013 at 18:38,Doug Blank <dou...@gm...> a écrit : > On Tue, Dec 3, 2013 at 12:26 PM, Paul Franklin <pf....@gm...> > wrote: >> On 12/3/13, Benny Malengier <ben...@gm...> wrote: >>> So you should consider it as a python module. The aim is to go to >>> two >>> interfaces: the GTK gui and the Django web application. For the >>> Django app, >>> all non GUI parts will not be needed, it can run headless. We did >>> not >>> decide yet if we want to move to split packages in the future, at >>> the >>> moment you install all or nothing. >>> >> Fedora 20 will have: >> >> gramps-4.0.2-1.fc20.noarch.rpm >> gramps-common-4.0.2-1.fc20.noarch.rpm >> gramps-webapp-4.0.2-1.fc20.noarch.rpm >> > Excellent! Where are the sources for these? Will the webapp package > setup the backend database and WSGI so that it is ready to use on the > server? That would be great. > > -Doug > >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. >> Most IT >> organizations don't have a clear picture of how application >> performance >> affects their revenue. With AppDynamics, you get 100% visibility >> into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most > IT > organizations don't have a clear picture of how application > performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jerome <rom...@ya...> - 2013-12-03 17:53:11
|
It seems that they still need to fix some minor issues. https://admin.fedoraproject.org/pkgdb/acls/bugs/gramps https://bugzilla.redhat.com/show_bug.cgi?id=983418 Le mar. 3 déc. 2013 at 18:38,Doug Blank <dou...@gm...> a écrit : > On Tue, Dec 3, 2013 at 12:26 PM, Paul Franklin <pf....@gm...> > wrote: >> On 12/3/13, Benny Malengier <ben...@gm...> wrote: >>> So you should consider it as a python module. The aim is to go to >>> two >>> interfaces: the GTK gui and the Django web application. For the >>> Django app, >>> all non GUI parts will not be needed, it can run headless. We did >>> not >>> decide yet if we want to move to split packages in the future, at >>> the >>> moment you install all or nothing. >>> >> Fedora 20 will have: >> >> gramps-4.0.2-1.fc20.noarch.rpm >> gramps-common-4.0.2-1.fc20.noarch.rpm >> gramps-webapp-4.0.2-1.fc20.noarch.rpm >> > Excellent! Where are the sources for these? Will the webapp package > setup the backend database and WSGI so that it is ready to use on the > server? That would be great. > > -Doug > >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. >> Most IT >> organizations don't have a clear picture of how application >> performance >> affects their revenue. With AppDynamics, you get 100% visibility >> into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most > IT > organizations don't have a clear picture of how application > performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Don A. <don...@ho...> - 2001-05-19 19:25:33
|
A Debian package would be wonderful. If you've already started on a man page, that is great as well. I haven't written a man page in quite a few years. I could probably add to it in the future. There is one outstanding bug that I have since fixed (dealing with merging and date ranges). If there is a concensus among the people on the list, I would make a quick 0.1.5 release, and this could serve a starting point for the .deb. Otherwise, we could just release a 0.1.4 .deb. I would definitely like to put the .deb file on the website. (Is that how it is done in Debian, or does everyone just apt-get it from a mirror?) - Don P.S. - The merge/date problem is fixed in CVS, if anyone needs it before the next release. ________________________________________________________________________ Don Allingham don...@ho... |