Trac team almost dead?
On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
[Jan Dittberner, 2009-08-28] On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, [...] I would really like to have trac in DPMT or maybe PAPT (is trac module used outside trac itsefl? If not, it should be moved to private directory, IMHO) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
On Fri, Aug 28, 2009 at 10:48:48AM +0200, W. Martin Borgert wrote: On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? I would really like to have trac in DPMT (or more activity in the current trac team). Maybe we could also coordinate to include commithooks [1] which integrate darcs, mercurial and git with trac and debbugs but should use trac's included post-commit scripts and consists of some Python and bash scripts. [1] http://git.complete.org/commithooks I'm using trac and commithooks and would like to help with better Debian support for both. Regards Jan -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/ signature.asc Description: Digital signature
Re: Trac team almost dead?
[W. Martin Borgert, 2009-08-28] On 2009-08-28 11:29, Piotr Ożarowski wrote: or maybe PAPT (is trac module used outside trac itsefl? If not, it should be moved to private directory, IMHO) I think, it's in the similar category as Django etc. i.e. it is a base technology on that you install plugins. It is, however, more specialised (focus on project management) and you can use it without writing your own application opposed to Django etc. question is: are these plugins installed in trac's directory or do they import trac? -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-trac-devel] Trac team almost dead?
On 2009-08-28 12:08, Piotr Ożarowski wrote: question is: are these plugins installed in trac's directory or do they import trac? AFAIK, this depends on the package. Typical plugins are installed into Trac directories, but they have also to import trac to use the APIs. I'm currently not near my trac server, but I remember that email2trac is installed under /usr/bin and uses the Trac API by from trac import Installation outside of Trac directories is, however, an exception. CMIIW. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Fri, 28 Aug 2009 11:01:37 +0200 Jan Dittberner ja...@debian.org wrote: On Fri, Aug 28, 2009 at 10:48:48AM +0200, W. Martin Borgert wrote: On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? I would really like to have trac in DPMT (or more activity in the current trac team). Maybe we could also coordinate to include commithooks [1] which integrate darcs, mercurial and git with trac and debbugs but should use trac's included post-commit scripts and consists of some Python and bash scripts. [1] http://git.complete.org/commithooks I'm using trac and commithooks and would like to help with better Debian support for both. I've looked at this scripts and found them not very accurate. So as for me, I've decided to use trac-post-commit-hook from trac distribution and simple shell scipt to run it in right time. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-trac-devel] Trac team almost dead?
Twas brillig at 12:21:21 28.08.2009 UTC+02 when deba...@debian.org did gyre and gimble: WMB Typical plugins are installed into Trac directories, ? There are two modes of installation: putting the .egg to the concrete Trac instance and installing it site-wide in the PYTHONPATH. You're probably referring to former. Distribution-friendly way is latter. -- http://fossarchy.blogspot.com/ pgp7bdlHbgBYz.pgp Description: PGP signature
Re: Trac team almost dead?
On 2009-08-28 17:25, Mikhail Gusarov wrote: There are two modes of installation: putting the .egg to the concrete Trac instance and installing it site-wide in the PYTHONPATH. You're probably referring to former. Distribution-friendly way is latter. Than I was wrong. I thought that plugins can go into a site-wide Trac directory, but you are right. So anybody vetoing against moving Trac to DPMT? You have three seconds... :~) Given that (1) pkg-trac was inactive the last months and that (2) interested Trac team members can easily join DPMT, and (3) a new upstream version is needed desperately by some users, I will probably start migration tomorrow. Depends on the weather. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
W. Martin Borgert schrieb: On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? Hi! I have some of the trac-plugins ITA/ITPed and would probably consider following trac itself into one of the python Teams. However I wonder how the $VCS will be handled, throwing away trac's git history doesn't sound like a good idea to me. As my packages have (following trac itself) a git history and the one I've ITA-ed has some HG history I'm interested in what the team thinks so I can decide if / what to move in. Regards Christoph -- /\ ASCII Ribbon : GPG-Key ID: 0x0372275D \ /Campaign : GPG 4096R : 0xD49AE731 X against HTML : Debian NM / \ in eMails : http://www.debian.org/ http://www.christoph-egger.org/ signature.asc Description: OpenPGP digital signature
Re: Trac team almost dead?
Christoph Egger wrote: I have some of the trac-plugins ITA/ITPed and would probably consider following trac itself into one of the python Teams. However I wonder how the $VCS will be handled, throwing away trac's git history doesn't sound like a good idea to me. As my packages have (following trac itself) a git history and the one I've ITA-ed has some HG history I'm interested in what the team thinks so I can decide if / what to move in. We're thinking about migrating the modules/apps teams repositories to git for a long time, actually there is even a plan (at least in my head) to make it possible to have modules in git or svn while still being able to checkout all of them in a useful way, but that means writing new code, and I didn't have the time to do so yet. Dropping the history doesn't make sense indeed, so I'm not sure what the best way to handle this is *now* - on the long run I;m sure we'll find a way to include it properly. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Quoting Christoph Egger deb...@christoph-egger.org: I have some of the trac-plugins ITA/ITPed and would probably consider following trac itself into one of the python Teams. However I wonder how the $VCS will be handled, throwing away trac's git history doesn't sound like a good idea to me. The git history would still exist. And we could also import the git history into the SVN repository of DPMT. I never used git and I currently don't have the time to learn new tools, so maybe somebody could post the right command line to do this, please? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Bernd Zeimetz be...@bzed.de (28/08/2009): long time, actually there is even a plan (at least in my head) to make it possible to have modules in git or svn while still being able to checkout all of them in a useful way, but that means writing new code, and I didn't have the time to do so yet. You meant putting a few lines into a .mrconfig file? Mraw, KiBi. signature.asc Description: Digital signature
Re: Trac team almost dead?
Cyril Brulebois wrote: Bernd Zeimetz be...@bzed.de (28/08/2009): long time, actually there is even a plan (at least in my head) to make it possible to have modules in git or svn while still being able to checkout all of them in a useful way, but that means writing new code, and I didn't have the time to do so yet. You meant putting a few lines into a .mrconfig file? no. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-trac-devel] Trac team almost dead?
On 2009-08-28 12:21, Piotr Ożarowski wrote: DPMT is fine then (most important ;-) problem solved) Maybe not yet: To me it would make sense to maintain Trac and some Trac plugins in the same team and in the same VCS. DPMT would be OK for Trac, but probably not for all the plugins, that are never used by anything but Trac. So maybe PAPT is the right choice then? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
On Fri, Aug 28, 2009 at 11:48 AM, W. Martin Borgertdeba...@debian.org wrote: I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb Please, note that MySQL support in Trac is still experimental. Why Trac should belong to application is that Python Application is something that should be run inside virtualenv. Trac is not a module, but rather important piece of server software that should better be updated alone with it's dependent libraries and probably independent of main Python installation. --anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: burn 0.4.3-2.2 (Lenny security bug fixes)
Felipe Sateler fsate...@gmail.com writes: Ben Finney wrote: Felipe Sateler fsate...@gmail.com writes: I believe packages with updates to stable debian releases are versioned version-revision+lenny1 or something like that. BTW, I know this is not a hard requirement, but it is to easily detect stable updates. Okay. Given that the release team has approved a specific set of changes that includes the package release version string, would I need to seek approval again when changing that string? I'm not sure, but I would think not. After all, the change is irrelevant to the software functionality. Well, I don't know exactly what needs to be done here. The examination of this updated release for stable was discussed on ‘debian-release’ and this issue didn't arise at all; I can only assume the chosen version string was not worth commenting on in that discussion. I don't want to change the version string based on a guess. I can't find any mention of the convention you're describing in the Developer's Reference or the Policy; what should I read to know what you're referring to? -- \ “Holy rising hemlines, Batman!” —Robin | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: burn 0.4.3-2.2 (Lenny security bug fixes)
On Sat, 29 Aug 2009 11:33:22 am Ben Finney wrote: Felipe Sateler fsate...@gmail.com writes: Ben Finney wrote: Felipe Sateler fsate...@gmail.com writes: I believe packages with updates to stable debian releases are versioned version-revision+lenny1 or something like that. BTW, I know this is not a hard requirement, but it is to easily detect stable updates. Okay. Given that the release team has approved a specific set of changes that includes the package release version string, would I need to seek approval again when changing that string? I'm not sure, but I would think not. After all, the change is irrelevant to the software functionality. Well, I don't know exactly what needs to be done here. The examination of this updated release for stable was discussed on ‘debian-release’ and this issue didn't arise at all; I can only assume the chosen version string was not worth commenting on in that discussion. I don't want to change the version string based on a guess. I can't find any mention of the convention you're describing in the Developer's Reference or the Policy; what should I read to know what you're referring to? It really doesn't matter. The only thing is you shouldn't have a version number that is higher than the one in the next release. Most of the people in the sec team prefer a version number that has the codename in the version, mainly to make it plain that this is a special update for this release. This was also adopted by the release team in the past, but as said it is not a requirement. Cheers Steffen signature.asc Description: This is a digitally signed message part.
RFS: burn 0.4.3-2.1+lenny1 (Lenny security bug fixes)
Howdy mentors, I am looking for a sponsor for the new release 0.4.3-2.1+lenny1 of my package ‘burn’ in Lenny. Since it's implemented in Python, I'm asking on both ‘debian-mentors’ and ‘debian-python’. It builds these binary packages: burn - Command line Data-CD, Audio-CD, ISO-CD, Copy-CD writing tool The upload would fix these bugs: 542329, 542750 Both these bugs are tagged ‘security’, so the ‘urgency’ setting in the changelog entry is ‘high’. The debdiff against the version currently in Lenny (0.4.3-2.1) is online at URL:http://pastebin.ca/1546649. If you want to sponsor this upload, please apply that diff to the current Lenny package and upload the result. The acknowledgement from the ‘debian-release’ forum for this change to go into Lenny (note that the diff being discussed had a version string that was not correct; that has been fixed now) is at URL:http://lists.debian.org/debian-release/2009/08/msg00396.html. Please let me know whether anything further needs to be done before this package can be sponsored into Lenny. -- \“I'd take the awe of understanding over the awe of ignorance | `\ any day.” —Douglas Adams | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
