Bug#927070: ITP: ledger2beancount -- Convert Ledger-based textual ledgers to Beancount ones
Thanks Jelmer ! :-) On April 14, 2019 6:49:26 PM GMT+02:00, Jelmer Vernooij wrote: >Package: wnpp >Severity: wishlist >Owner: Jelmer Vernooij > >* Package name: ledger2beancount > Version : 1.6 > Upstream Author : Stefano Zacchiroli >Martin Michlmayr >* URL : https://github.com/zacchiro/ledger2beancount >* License : GPLv3 > Programming Lang: Perl >Description : Convert Ledger-based textual ledgers to Beancount >ones > >A script to automatically convert Ledger-based textual ledgers to >Beancount >ones. > >Conversion is based on (concrete) syntax, so that information that is >not >meaningful for accounting reasons but still valuable (e.g., comments, >formatting, etc.) can be preserved. -- Sent from my mobile phone. Please excuse my brevity and top-posting.
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
tag 917532 + pending thanks Fava is now in NEW. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
On Sun, Dec 30, 2018 at 01:24:23AM +0100, Pierre-Elliott Bécue wrote: > I think a webserver config + WSGI handling is quite overkill. Do you agree? Yeah, I agree. Upstream is reluctant to even document easy setup recipes on the basis that Fava is essentially a personal service. I've myself setup a "public" Fava, behind HTTPS auth of course, but I see value in not making it "too easy" in this case, for fear of unsavvy users leaking personal information out of the box. If anything, we should work with upstream on the deployment documentation side, and make sure said documentation is shipped with the package. Cheers PS I commented on IRC about that, but FWIW: I think the reference on the package description to "beancount" as package name is correct, because there is such a binary package and it is the end-user oriented entry point to Beancount in Debian -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
On Sat, Dec 29, 2018 at 09:11:23PM +0100, Pierre-Elliott Bécue wrote: > It's in new now. :) Thanks! :-) -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
Looks like a fava dependency is missing in Debian: [python3-]markdown2, https://pypi.org/project/markdown2/ (There's python3-markdown in the archive, but that's a different one: https://pypi.org/project/Markdown/) Volunteers to package markdown2 are welcome; I'm not going to package it myself. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
A package skeleton is now available on salsa: https://salsa.debian.org/python-team/applications/fava Help and co-maintainers are welcome. (It's not clear to me if I should do anything else, other than creating the project on salsa, to make sure other members of PAPT can directly commit to the repo. If so, I'd appreciate someone letting me know.) Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
Package: wnpp Severity: wishlist * Package name: fava Version : 1.9 Upstream Author : Dominik Aumayr * URL : https://beancount.github.io/fava/ * License : MIT Programming Lang: Python Description : web interface for the Beancount accounting tool Fava is a web interface for the double-entry bookkeeping software Beancount with a focus on features and usability. Beancount is packaged in Debian as "beancount".
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
The package is now sitting in NEW, waiting to land in experimental. I've also pushed a couple of minor improvements on salsa, waiting for the next upload. As soon as it passes NEW, I plan to upload again to unstable, hoping to make the freeze cut (you never know... :-)) Please let me know if you have objections and please test the package and let this bug report know if you encounter any showstopper. For my part I've migrated my local use of beancount to the current version of the package and it is working just fine for my needs. Cheers. -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
On Mon, Dec 24, 2018 at 07:30:31PM +0200, Martin Michlmayr wrote: > So this issue was reported and fixed already upstream: > > Here's the original bug report: > > https://bitbucket.org/blais/beancount/issues/341/test_utilsfind_repository_root-doesnt-work Thanks Martin for finding this, and thanks James for raising it upstream after last time I tried it out. I've updated the package to a hg snapshot of today (which includes the commits with the fix, and more). The source package as it is on salsa now builds fine on a fresh unstable chroot. Testing welcome. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
On Sun, Dec 09, 2018 at 05:23:35PM +0200, Martin Michlmayr wrote: > Is the delay because of the test failures mentioned by Zack? The main current issue is that several tests, at least when run under sbuild/cowbuilder, enters infinite loops stat()-ing forever "/PKG-INFO". I have been unable to find the cause, but it's somewhat specific to the Debian build environment in conjunction with pytest. In addition to that there are some test failures too, but they look easy to fix (and the patches should probably be sent upstream for integration). I don't see myself having more time than I already devoted to this in time for the next freeze. But if you're up to tackling this, I can provide more info, e.g., I've a list of the affected tests, in case it might help finding a pattern. The *general* pattern is that tests that exec() stuff are impacted, but it's not specific enough (at least for me) to pinpoint the issue. Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
Hi Adrian,
On Mon, Mar 20, 2017 at 02:18:27AM -0300, Adrian Alves wrote:
> Pass is a simple password store. This fork changes a few
> things while trying to maintain most of it intact,
> specially the core idea. I will keep pulling pass commits,
> and also pushing my modifications to them.
as a pass user, I'm interesting in having a look at this. However, the
description is not particularly telling about what are the differences
("a few things" :-)) and why this fork exists. Can you update the
description of the final package to address this?
TIA,
Cheers.
--
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: PGP signature
Bug#821248: ITP: fgallery -- modern, minimalist javascript photo gallery
On Sun, Apr 17, 2016 at 01:23:14AM +0200, Andreas Tille wrote: > * Package name: fgallery fgallery seems to already be in the archive: https://tracker.debian.org/pkg/fgallery Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#807054: ITP: flask-testing -- unit testing utilities for the Flask micro web framework
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli
* Package name: flask-testing
Version : 0.4.2
Upstream Author : Dan Jacob
* URL : http://pythonhosted.org/Flask-Testing/
* License : BSD-3-clause
Programming Lang: Python
Description : unit testing utilities for the Flask micro web framework
(Long description forthcoming.)
The binary packages will be named python{,3}-flask.ext.testing.
The package Git repository will be put under the DPMT umbrella.
Bug#807053: ITP: flask-api -- browsable web APIs for the Flask micro web framework
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli
* Package name: flask-api
Version : 0.6.4
Upstream Author : Tom Christie
* URL : http://www.flaskapi.org/
* License : BSD-2-clause
Programming Lang: Python
Description : browsable web APIs for the Flask micro web framework
Flask API is an implementation of the same web browsable APIs that the
Django REST framework provides. It gives you properly content negotiated
responses and smart request parsing.
The binary packages will be named python{,3}-flask-api.
The package Git repository will be put under the DPMT umbrella.
Bug#797359: ITP: universal-ctags -- Generates an index (or tag) file of names found in source files
Thanks for your answer, Víctor! On Mon, Aug 31, 2015 at 10:14:10AM +0200, Víctor Cuadrado Juan wrote: > You can read a somewhat comprehensive list of changes from upstream > here[1], and more info here[2]. Very helpful! Last question: are you aware of any performance comparison between exuberant-ctags and universal-ctags? -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Bug#797359: ITP: universal-ctags -- Generates an index (or tag) file of names found in source files
On Sun, Aug 30, 2015 at 12:44:44AM +0200, Víctor Cuadrado Juan wrote: > * Package name: universal-ctags > * URL : https://ctags.io/ > A continuation of the exuberant-ctags implementation of the ctags Hey, can you elaborate a bit on how universal-ctags compare to exuberant-ctags? This is by no means an objection to packaging this, but as a heavy user of exuberant-ctags for Debsources, I'm curious about how the two compares, specifically in terms of performances and language support. Thanks! -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#764940: RFP: debsources -- index and publish Debian source code on the Web
Package: wnpp Severity: wishlist * Package name: debsources Version : 1.0 Upstream Author : Stefano Zacchiroli Matthieu Caneill * URL : http://sources.debian.net/ * License : AGPL3+ Programming Lang: Python Description : index and publish Debian source code on the Web Debsources is a Python-based infrastructure used to index and publish on the Web the source code of the Debian operating system. Via the Debsources web app, users can browse through the list of available source packages, or search for a particular one based on package-level metadata. Multiple versions of each source package are supported. Users can also search the actual source code content using, code-level metadata or regular expressions. Once chosen a specific version of a package, users can browse through the source package structure, inspect individual source files, and obtain links to individual lines. When using a Javascript-enabled web browser, source code will be syntax-highlighted; otherwise the raw file will be returned. Using specific URL schemes users can highlight specific lines of code as well as associate pop-up messages to them. Developers can use Debsources programmatically via its API, or simply as a stable base to refer to source code lines. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012125957.28517.35900.reportbug@timira.takhisis.invalid
Bug#651606: Bug#700630: ITP: gitorious -- Git based tool for collaborating on distributed open source projects
On Fri, Feb 15, 2013 at 03:40:12PM +0100, Mike Gabriel wrote: > Package: wnpp > Severity: wishlist > Owner: Mike Gabriel > > * Package name: gitorious > Version : 2.4.9 That's great, thanks for giving this a try. We definitely need more good packages of self-hosted replacements for popular centralized (and often proprietary) services out there. gitorious surely qualifies and is very seldomly seen installed in the wild, other than the "main" instance at gitorious.org. On a related matter, do you happen to have any news about gitlab packaging? I understand it's a "concurrent" of gitorious :-), but AFAICT from the RFP, it was expected to land under the hood of pkg-ruby-extras as well. Thanks for your work, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#665318: ITP: faac -- AAC audio encoder
On Thu, Oct 18, 2012 at 09:13:06AM +0200, Fabian Greffrath wrote: > Am 17.10.2012 18:37, schrieb Bob Bib: > >This package has been rejected by ftpmaster as violating Debian patents > >policy, > >but has the issue been reviewed by the Debain patent expert person, as > >described in the policy statements? > > Good question, but honestly I don't know the answer. The fact that "it may infringe existing patents" is not, per se, against the patent policy. In fact, that statement is true for every package in the archive: *alleged* sowftware patent violations can be found in almost any piece of software out there. Luca, can you please reconsider? -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#616548: please ship upstream documentation for offline reading
On Sat, Sep 29, 2012 at 10:29:12PM -0400, Micah Anderson wrote: > I'm pushing the git repository now, and going to have a beer and squash some > RC > bugs instead! Thanks: - for trying - for the forthcoming RC bugs fixes - and for making my day with this tale :-) feel free to do whatever you please with this bug report, maybe it'd be useful for other to mark as wontfix, if anyone else in the future try to turn you into Hulk-mode again. Cheers. PS no, the building bill is *not* fine :-P -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#687624: ITP: libdvdcss-pkg -- automated installer for libdvdcss
On Fri, Sep 14, 2012 at 02:14:57PM +0200, Reinhard Tartler wrote: > > This is a proof-of-concept implementation of automated installer for > > libdvdcss. > > This has been discussed before within the pkg-multimedia team. There > is even preliminary work available at > http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libdvdcss-installer.git;a=summary. Indeed. I've in the past sought legal advice on the appropriateness of having an automated installer for libdvdcss in the Debian archive and shared the results with interested members of pkg-multimedia team. The bottom line of that work was that it could be done, but we need to pay attention at the package description. Please check back with me before finalizing that part. ... and of course, as a more general advice, please avoid duplicating efforts and converge on a single implementation, whatever, but please only one :-) Thanks for your interest in this, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#658927: O: turbogears2-doc
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193648.gg9...@upsilon.cc
Bug#658926: O: turbogears2
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193632.gf9...@upsilon.cc
Bug#658925: O: tg.devtools
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193620.ge9...@upsilon.cc
Bug#658924: O: sprox
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193607.gd9...@upsilon.cc
Bug#658923: O: python-webflash
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193601.gc9...@upsilon.cc
Bug#658921: O: python-tgext.admin
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193535.ga9...@upsilon.cc
Bug#658922: O: python-toscawidgets
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193551.gb9...@upsilon.cc
Bug#658918: O: catwalk
Package: wnpp Severity: normal As discussed in http://lists.debian.org/debian-python/2012/02/msg1.html I'm hereby orphaning the packages of the turbogears2 stack of which I'm the sole maintainer. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120206193431.9359.10319.reportbug@usha.takhisis.invalid
Bug#649784: On dh_apparmor, and possibly other dh_* stuff in the future
On Wed, Dec 28, 2011 at 12:01:04AM +0100, Gergely Nagy wrote:
> Yup, this is the reason I dared raising the option in the first
> place. (Though, even if this weren't the case, I'd be up for helping
> maintain such a package, but thankfully, doing so would be an easy job.)
>
> So, if I understand it well, there is no opposition?
Thanks for pushing the discussion until here!
> Then we "only" need a package name, possibly finding other scripts apart
> from dh_apparmor (perhaps even poking the maintainers of various dh_*
> scripts if they'd consider merging into a single thing), and a
> maintainer (I'm willing to help with that, but the more the merrier,
> especially if there's someone more versed in dh-land than I am).
A first approximation is given by:
apt-file search -x '/usr/bin/dh_.*' | grep -v ^debhelper:
of course there is a catch in centralizing dh_* scripts in a single
package, in terms of ease of maintenance by the respective teams --- as
an author of one of those tools myself (dh_ocaml), I believe it would
benefit more from staying separate than from being merged in something
like "debhelper-extras".
But still it'd be useful to have such a package for dh_* scripts that
have no obvious location.
If Joey has no objections, I believe you should just go ahead creating
"debhelper-extras" (or whatever name pleases you), including dh_apparmor
in it, and then ask on -devel who is looking for a home for orphan dh_*
scripts.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#644757: O: ocaml-book -- English book: "Developing applications with Objective Caml"
Package: wnpp
Severity: normal
I've just orphaned ocaml-book (shipping binary packages ocaml-book-{en,fr}).
In the last upload I've cleaned up the package and brought it up to recent
packaging practices, as well as acknowledged a recent NMU (thanks Jakub Wilk!).
Maintenance cost of the package is essentially zero.
It should probably be adopted by the Debian OCaml team (Cc:-ed). The only
reason why it wasn't maintained by them yet is that the package actually
predated widespread team maintenance of OCaml-related packages.
The main pending task is to convert it to a non-native Debian package, creating
a fake/joint upstream tarball for the two books.
Cheers.
The package descriptions are:
HTML version of the French book: "Developpement d'applications
avec Objective Caml" published by O'Reilly.
.
This package contains the HTML version of the book.
This is the English translation of the O'Reilly's OCaml French
book "Developpement d'applications avec Objective Caml" that can
be found in the ocaml-book-fr package.
.
This package contains both the HTML and PDF version of the book.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20111008190455.22039.85852.reportbug@usha.takhisis.invalid
Bug#636016: ITP: goodbye -- next part after 'hello', and a packaging example
On Sat, Jul 30, 2011 at 12:17:49PM +0200, Adam Borowski wrote:
> Using slow, bloated tools like debhelper and dpkg-dev will cost you precious
> SECONDS when building your package. Multiplied by tens of thousands of
> packages Debian has, this can be a burden on archive rebuilds. Thus, this
> is a proposal and example how to get rid of that inefficiency.
>
> Written in a Real Man(tm)'s scripting language with a JIT compiler, it's
> over two orders of magnitude faster than mainstream packaging techniques.
OK, I bite (although I regret it already…).
In case you really want to upload this to the archive, can you make it
clear in the package description that the packaging practices embodied
by goodbye are just a show off of what can be done, but at the same time
that they are discouraged practices?
No matter how little the risk is, I don't think we want to risk that
people will imitate them in new packages.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#608922: ITP: matlab -- integrate local Matlab installations into the Debian system
On Tue, Jan 04, 2011 at 11:49:55AM -0500, Michael Hanke wrote:
> > It really shouldn't be called “matlab” then.
> The likelihood of Debian having a package that actually provides matlab
> seems to be rather low. If it ever happens this package would be
> obsolete and could be removed.
Still, it looks a bit convoluted to name a package as something that it
does not ship, relying then on the fact that the user will rule out that
possibility, knowing the licensing details of the specific software in
question.
> I assume you want to point to the problem of some people having matlab
> packages that actually contain the binaries, right? How does Debian
> deal with this issue? Could we have a 'skype' package?
>
> What name do you suggest? Maybe 'matlab-package'?
'matlab-integration' would be nice, but in the specific context of
matlab might be misleading (cfr. 'octave-integration'). As a second
choice, how about 'matlab-support'?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#579786: Bug#604968: w3-recs: Package is out-of-date
tags 604968 + help
thanks
On Thu, Nov 25, 2010 at 09:17:03PM +0100, Manuel Strehl wrote:
> Since the last update of the w3-recs package a lot of activity has
> been going on at the W3C. Most notably the advance of HTML5 and
> several CSS3 modules come to mind.
Well, I don't know about the CSS3 modules you have in mind, but HTML5 is
not a good example, given that the HTML5 is still a working draft and
not a Recommendation. As the package name implies, w3-recs is meant to
contain only Recommendations and not W3C documents in other status.
> This is not reflected in the specifications included in w3-recs. An
> update of this otherwise useful package is in need.
Nevertheless, this is true. I meant to update w3-recs once before the
Squeeze freeze and then formally orphan the package (see #579786), but I
badly failed at it.
Some people declared interest in adopting w3-recs (Cc:ing them with this
mail), but in spite of some early work on the package, it seems that
unfortunately no upload has been made yet. Folks, if you are *really*
interested in maintaining w3-recs, please go ahead with an upload and
feel free to remove me from the maintainer/uploader fields. I doubt
there is any room for an updated version for Squeeze (which is
unfortunate), but it would be nice to have the package up to date in
unstable, as its dependencies make it trivial to install it from any
Debian suite.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Wed, Sep 08, 2010 at 04:58:21PM -0400, Joey Hess wrote:
> Incoming code of possible security significance should be reviewed for
> at least common classes of security holes. Instead, we get a thread where
> the ITPer is required to prove that nothing in Debian can do what his
> package does.
You got me. I'm convinced by these arguments.
Still, they account for a possibly inflated perception of the trade-off
between security *risks* and the benefits of having a new package in the
archive. That trade-off is not the same as the trade-off between
security *work* and the benefits of introducing a new package. That is
to say that arguably the security team will have to fix anyhow a
security fix in woof, even if its impact is much lower than the impact
of a security hole exploitable in the default Apache configuration.
But once more you're right: it is not up to us here to say which
packages are acceptable from the POV of the security team. I can just
comment that my, probably inflated, perception of the extra burden is
not based only on my personal beliefs. My perception is also based on
past comments (and talks) on the subject by the security team, where the
"yet another web server" example was frequently cited, at least in my
recalling.
I also agree that the default mood (or culture as you call it) "against"
ITPs is probably excessive, but we should not give up on requiring
adherences to best ITP practices. In particular, a review of
alternatives available in the archive is something I do expect from
ITP-ers of *any* software, whether it's security-sensitive or not.
Similarly, documenting in the long description reasons for choosing the
package over its alternatives is something to be expected as well. For
woof, it might be written as simply as you just did, but it's still
something this ITP is waiting for.
Bottom line: this thread could have probably been spared entirely, by
providing a long description matching the above criteria since the
beginning.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Wed, Sep 08, 2010 at 08:03:14PM +0200, Salvo Tomaselli wrote:
> > This would already reduce the load on the FTP, release and security
> > teams, and allow their members to do more useful things.
> And would lead many people to choose other distributions that offer more than
> merely core packages.
Salvo, I do appreciate how much you care about this package, but I don't
think the past, say, 15 messages of "lateral" discussion in this thread
have helped at all the cause of woof. I'm of course biased, but I've the
impression that the main points to be addressed are still the one raised
in my earlier post in this thread.
That is: considering that introducing a new web server in the archive
will potentially increase the work of the security team, it must be
worth. To verify it is worth or not there is only one way: perform a
thorough review of alternatives already present in the archive and point
out the unique features (of all kind, including user interface
difference) of woof with respect to them. Bonus points: mention those
unique feature in the long description as help for sysadms having to
choose woof among others.
I haven't yet seen either you, or the ITP-er, or anyone else doing that
and I've the impression you'll be getting nowhere until that is done.
/me and his last post on this thread
Cheers.
PS As a not very thorough personal suggestion of mine, and after a bit
of Googling, I'd start from the "webfs" package to document what more
woof has to offer.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
[ adding back the ITP to Cc: ]
On Tue, Sep 07, 2010 at 10:56:15AM +0200, Salvo Tomaselli wrote:
> The default installation of lighttpd would put itself in the autostart, maybe
> i just wanted to share a file and it would take time for me to change the
> configuration for avoiding autostart and create a new config file. And of
> course i should also know how to do that.
Fair enough. Note that nobody here is saying "thou shall not package
this". We are just very cautious because adding a new web server to the
archive might easily become a security PITA (ask the security team for
some horror stories on the subject of "yet another web server"). So what
we are saying is just that "it should be worth it" wrt other software
offerings already in the archive.
On a related topic, please remember that long descriptions are meant to
help sysadms to decide whether they want to install a package or not. In
this specific case, and giving the availability of competitor tools,
your long description should explain why one might want to prefer woof
over other packages.
If I were the packager, I would skim through the output of "debtags
search web::server" and try to convince myself that the new one I'm
adding really has distinguishing features (things like "ease of
configuration" might of course qualify as a features). Once done, I
would mention my reasons in the long description. ... and that's also
why it's wise to have long descriptions ready at ITP-submission time:
thread like this one might have been avoided completely, thanks to a
convincing long description :-)
Thanks for your packaging work!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#579786: RFA: w3-recs -- Recommendations of the World Wide Web Consortium (W3C)
Package: wnpp Severity: normal I'm looking for a new maintainer for the w3-recs package. The package is quite low maintenance as package generation is automated from the machine-parseable index of W3C rcommendations [1]. Still, it needs following the W3C feed to spot new recommendations and update the package from time to time, at least once per release. In fact, the update for Squeeze is still pending and I would be glad to find an adopter in Squeeze time willing to do that *g*, otherwise I'll try to do that anyhow before actual orphaning it. Note that the package is non-free, as current W3C license for technical documents is not DFSG-free. Cheers. [1] http://upsilon.cc/~zack/blog/posts/2007/09/w3-recs/ The package description is: This package includes the Recommendations produced by the World Wide Web Consortium (W3C) standardization body in HTML format. . The included Recommendations are: -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100430184703.21795.73150.report...@usha.takhisis.invalid
Bug#579735: O: gtkmathview
Package: wnpp Severity: normal I'm hereby orphaning the gtkmathview package. It consists of a C++ library used to render MathML documents to various backends, including GTK. Most notably, it is used to support rendering of mathematical formulae in third party applications, such as abiword. The library has become quite stable in recent years, and upstream is friendly, competent, and reponsive. The package is in collab-maint already, builds upon autotools and has hence one-liner CDBS or dh7 debian/rules. The maintenance burden is very low. I'm copying the abiword maintainers: given that the sky-rocketing popcon of gtkmathview is mainly due to them, they might want to maintain the package by themselves to avoid breakages in abiword. I'm filing the "O" bug now, I'll upload the actually orphaned package if noone step up to take it over in a week or so (feel free to ping me if I forget). Cheers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100430100221.14465.68896.report...@usha.takhisis.invalid
Bug#579735: O: gtkmathview
On Fri, Apr 30, 2010 at 12:07:08PM +0200, Sylvestre Ledru wrote:
> As a the jeuclid maintainer (a library/viewer of MathML in Java), I
> could also take this one in the context of Debian Science.
> However, I would prefer a user of this package to step-in (or a
> maintainer of one of its reverse dependencies).
Fine, I'd say it would be fair to keep you as "fallback" then.
Do you mind following how it goes and then, unless someone fulfilling
the proposed requirement steps up, upload a version with you as the
maintainer in a 7-10 days?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#520324: ITP: chromium-browser -- A web browser developed by Google based on the WebKit engine
On Mon, Apr 26, 2010 at 03:14:43PM +0200, Giuseppe Iuculano wrote:
> Preliminary i386/amd64 Debian packages can be found here:
> http://people.debian.org/~iuculano/chromium/
Wonderful!, thanks.
I'll given them a try and report any problem.
(You might want to sign the .dsc though, so that people can have a trust
path to the .deb-s.)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100426135823.ga10...@usha.takhisis.invalid
Bug#520324: ITP: chromium-browser -- A web browser developed by Google based on the WebKit engine
On Fri, Apr 23, 2010 at 01:42:35PM +0200, Alexander Sack wrote:
> > > BTW, yesterday I uploaded gyp.
> >
> > Thanks and already accepted (interesting to see some packages can go fast ;)
> > I guess nothing prevent to upload a package to experimental now.
>
> OK, I will make this happen over weekend. Will add Guiseppe as an Uploader ...
> please contribute directly to our branches in launchpad from here on.
That's great news guys, I'm really looking forward for chromium browser
in unstable ... and if you need a beta tester, ping me :-)
Thanks a lot and keep up the good work.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100423205527.ga17...@usha.takhisis.invalid
Bug#520324: ITP: chromium-browser -- A web browser developed by Google based on the WebKit engine
On Thu, Apr 22, 2010 at 01:10:12PM +0300, Fathi Boudra wrote:
> > *possibility* of getting the package in squeeze. That means having it in
> > unstable first, then we'll use the usual rules for transition to testing
> > of all other packages.
> or experimental.
Yup, exactly, with the added benefit that in the mean time we'll get NEW
review.
> > Regarding security issues, I duly notice that Giuseppe is a full member
> > of the Debian security team, so I believe we should trust his judgement
> > on that.
> webkit related security issues are real and I'm well placed to know about it.
> I would like to hear Giuseppe about his concerns wrt this point.
Sure, I just meant to highlight that he's probably more qualified than
other people (surely more than me for instance) to judge on this. I do
hope he has already thought about it :), but it would indeed be nice if
he can share his opinions here.
> IMHO, common sense is preferred here.
> I don't see the problem for Giuseppe to team up with Alexander (and
> Fabien Tassin) and finally push a package in experimental.
Sure, and thanks for the hook to highlight what I forgot to mention: the
offer Giuseppe has already advanced of collaborating on the packaging on
alioth is surely the best possible outcome of all this.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100422102527.ga23...@usha.takhisis.invalid
Bug#520324: ITP: chromium-browser -- A web browser developed by Google based on the WebKit engine
On Thu, Apr 22, 2010 at 03:12:56AM +0200, Alexander Sack wrote:
> > > Is there a specific reason why you (Chromium team) uploaded
> > > chromium-browser in Ubuntu two months ago and not yet in Debian?
> > I don't received any answer, so I'm going to take over this ITP in order
> > to get chromium-browser in time for squeeze.
Hi Giuseppe, many thanks for your offer, personally I'd like you to go
ahead with your packaging work on chromium-browser to at least have the
*possibility* of getting the package in squeeze. That means having it in
unstable first, then we'll use the usual rules for transition to testing
of all other packages.
> > I requested an alioth group, feel free to join it when it will be
> > accepted.
> The problem is that chromium browser cannot be maintained in a debian
> stable relase as it is. If you think different talk to me on IRC.
It's a bit of a pity that this argument of yours was not in the bug log
of the ITPs of chromium, or else I've missed it blatantly (in that case
I apologize in advance). The only counter argument I've found thus far
to upload was a licensing problem, which seems to be solved now.
Regarding security issues, I duly notice that Giuseppe is a full member
of the Debian security team, so I believe we should trust his judgement
on that.
All in all, it would be an incredible pity not to have chromium-browser
in Debian and probably a good argument for a lot of desktop users to use
another Debian-based distribution (say, Ubuntu). I don't think we should
block the packaging of chromium lightly; if there are clear reasons to
do so they should be clearly stated, and well communicated.
No matter what, we've clear processes for this kind of issues and I
think we should use them rather then simply not uploading the package
and stopping other developers motivated in doing that, by fiddling with
the owner of this ITP.
If you ask me, I'd like Giuseppe to take back ownership of this bug
report and go ahead with the packaging work.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#575938: ITP: dh-autoreconf -- debhelper add-on to call autoreconf and clean up after the build
On Wed, Mar 31, 2010 at 02:07:31PM +0800, Paul Wise wrote:
> >> Package: dh-autoreconf
> I'd suggest just putting this into debhelper rather than making it a
> separate package.
Seconded. The addons looks quite general, I don't see the point of
having it in a separate package.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#556098: ITA: hamlib / new version for upload
On Tue, Feb 16, 2010 at 07:53:53PM -0800, Kamal Mostafa wrote:
> I wasn't sure what to do with the debian/control "Uploaders:" field. As
> a placeholder, I set it to the debian-h...@lists.debian.org list address
> -- I expect that it will be changed by the actual uploader:
>
> Uploaders: Debian Hamradio Maintainers
>
> This is my first experience with maintenance of a package at Debian, so
> I am not at all sure that I'm following the proper procedures here. Any
> guidance will be much appreciated.
So, I've just checked your package and it looks generally OK to me. I'll
proceed to upload it to DELAYED/1, just to give other people a bit of
time to react in case there are reservations.
The few comments I've are as follows, please consider them in future
uploads:
- I've switched your Maintainer/Uploaders line, to match the best
practices on that. Maintainer is the official contact address (the
mailing list) and Uploaders is the list of people usually *working*
(not just doing the final upload, despite the name) on the package,
hence you in this case. Please port the change to your working copy of
the packaging.
- You install a couple more .so files than in the past, however these
new .so are not versioned, I believe it is an upstream choice, but you
should discuss with them whether this is really intended or not.
- As hamlib has a homepage (the sourceforce page), you should declare it
in debian/control using the "Homepage" field, check the developer's
reference for details. If you use some version control system to
maintain the packaging, you should declare that too using the Vcs-*
fields (again, devref has details about that).
- There are quite a lot of lintian warnings, you should fix them. Most
of them are missing ${misc:Depends} substvar that are recommended if
you use debhelper (as you do) in the packaging; please add them.
Thanks for your work!
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100217102837.gb22...@usha.takhisis.invalid
Bug#556098: ITA: hamlib / new version for upload
On Tue, Feb 16, 2010 at 07:53:53PM -0800, Kamal Mostafa wrote:
> http://www.whence.com/debian/proposed/hamlib_1.2.10-1.dsc
Thanks a lot, I'll review this shortly and get back to you.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100217083217.ga12...@usha.takhisis.invalid
Bug#569521: Bug#569519: ITP: groundcontrol -- Launchpad integration for Nautilus
On Thu, Feb 11, 2010 at 11:01:10PM -0500, Luke Faraone wrote:
> * Package name: groundcontrol
On Thu, Feb 11, 2010 at 11:05:08PM -0500, Luke Faraone wrote:
> * Package name: groundcontrol
Eya, thanks for your intention of packaging groundcontrol for Debian!
However, the ITP has been submitted twice and hence has got two
different bug numbers: #569519, and #569521. Please close one of them.
All the best.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#520324: thanks a lot for chromium packaging work!
On Sun, Jan 17, 2010 at 02:14:13PM +0100, Alexander Sack wrote:
> we are making progress on this. the latest bzr branch has a
> licensecheck.pl that generates dep-5 file copyright.
Hi Alexander, just a big "THANK YOU" for the ongoing work on the
chromium-browser packaging, of course that extends from you to all other
people who contributed. I'm eager to play with the browser and I thought
a supportive message would be better than nothing :-)
Do you have any ETA for when the package will be available in unstable?
Do you plan to ship it with squeeze?
Thanks again,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#566668: O: myspell-el-gr -- Greek (el_GR) dictionary for myspell
Package: wnpp Severity: normal Popcon is still respectable, even if the package has seen only 2 uploads (one of which is an NMU) since 2004. Cheers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566364: RFH: doc-central
On Sat, Jan 23, 2010 at 04:12:22PM +0900, Charles Plessy wrote:
> doc-central has one release-critical bug, making it unfit for the release. Are
> there volunteers to adopt it? Robert? The QA team? Otherwise, despite it is
> useful, it is maybe time to give up and remove it from our archive...
I find this request of yours unsubstantiated.
The RC bug has a patch pending and is pretty easy to fix. I might
eventually NMU it to fix that, even though I'm not willing to maintain
the package right now. Beside that bug, the package works quite well,
has a respectable number of popcon user (as you observe); I, for
instance, am a daily user of it.
So, exactly *why* you want this package to be removed, considering that
there are way more "bad" packages in the archive (and almost completely
unused) that would deserve removal first?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#558090: ITP: camljava -- interface between OCaml and Java via Caml/C interface and JNI
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: camljava Version : 0.3 Upstream Author : Xavier Leroy * URL : http://pauillac.inria.fr/~xleroy/software.html#camljava * License : LGPL Programming Lang: OCaml, C, Java Description : interface between OCaml and Java via Caml/C interface and JNI CamlJava is an interface between OCaml and Java allowing programs written in one of the two languages to call code written in the other. . Interaction among the two languages happen via the respective C interfaces: Caml/C interface for OCaml and JNI (Java Native Interface) for Java. . Currently, CamlJava provides a low-level, weakly-typed OCaml interface very similar to the JNI. Java object references are mapped to an abstract type, and various JNI-like operations are provided to allow Java method invocation, field access, and more. . A basic callback facility (allowing Java code to invoke methods on OCaml objects) is also provided, although some stub Java code must be written by hand. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522138: ITP: gears -- Gears (formally Google Gears)
Hi Fabian, ping on this ITP.
I've recently noticed that the Gears package is available in Ubuntu, at
least in Karmic [1], an announcement/heads up about it has been recently
posted to Planet Ubuntu [2]. As an annoyed amd64 user which still has
no Gears, I'd really like to see the package arriving in Debian too.
Are you still working on the packaging?
Do you need help?
Any reason not to join efforts with Ubuntu people?
If you are no longer interested in packaging it please let us know, so
that someone else can step in and finally package it.
TIA,
Cheers.
[1] http://packages.ubuntu.com/karmic/gears
[2]
http://blog.thesilentnumber.me/2009/10/how-to-64-bit-google-gears-for-ubuntu.html
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555197: ITP: fieldslib -- OCaml syntax extension that enables folding over record fields
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: fieldslib Version : 0.1.0 Upstream Author : Jane Street Holding, LLC * URL : http://ocaml.janestreet.com/?q=node/13 * License : LGPL (+ usual OCaml linking exception) Programming Lang: OCaml Description : OCaml syntax extension that enables folding over record fields I'm packaging this as a new dependency for the janest-core library, starting from core 0.6.0. The package is a CamlP4 syntax extension, binary package will be called libfields-camlp4-dev. Cheers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550817: ITP: gitolite -- standalone, souped-up version of gitosis
On Tue, Oct 13, 2009 at 10:15:24AM +0200, Gerfried Fuchs wrote:
> Description : standalone, souped-up version of gitosis
>
> Gitolite is a rewrite of gitosis, with a completely different config
> file that allows (at last!) access control down to the branch level,
> including specifying who can and cannot rewind a given branch.
/me playing devil's attorney role
What if one has no idea of what "gitosis" is? For such a person, the
above description will be close to meaningless. I suggest expanding in a
couple of words what gitosis is, turning the reference to it as
something like "similar to gitosis".
Thanks for your packaging work!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#538261: O: pynetsnmp
Package: wnpp Severity: normal Me and Bernd Zeimetz have just orphaned pynetsnmp. If anybody in the python modules team is willing to take it up, please do so. Package description follows. Description: Python ctypes bindings for NET-SNMP with Twisted integration pynetsnmp is a set of Python ctypes binding for NET-SNMP, an implementation of the Simple Network Management Protocol (SNMP). . pynetsnmp is a replacement for the various Python bindings provided by PySNMP* implementations (available as the Debian packages python-pysnmp*). . It also implements a glue with the Python Twisted Matrix networking framework which replaces the TwistedSNMP implementation (available as the python-twisted-snmp Debian package). -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538255: O: pysnmp-se
Package: wnpp Severity: normal I've just removed my name from the Uploaders of pysnmp-se, because I've lost interest in it and cannot reliably maintain it any more. As I was the only one in Uploaders, that raises the issue about whether the package is orphaned or not. To avoid forgetting about that, I've uploaded a really orphaned version (i.e. Maintainer: QA) to DELAYED/7, and I'm opening this bug report. If someone else on the Python Module team wants to take over pysnmp-se, please dcut the DELAYED upload and close this bug report. Cheers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519377: Integrate yaclc in devscripts?
On Mon, Jul 20, 2009 at 03:28:34PM +0200, Patrick Schoenfeld wrote:
> Its an already existing tool. But indeed an interesting question.
It is an existing tool, ... which was going to disappear. So I think
it is reasonable to ask whether it should really be saved or not.
> > If the check is all it does, it looks like a simple "--check" option
> > can be added to tagpending to achieve the same effect.
>
> I don't know if this matches the use-case. AFAICS yacls is meant to
> be used as a dput hook or so, to tell you "OH! WAIT! You are gonna
> close the wrong bugs if you really upload now"
Yep, that's clear. The reasoning for associating the two is that
blatantly they deal with the same entities: last changelog entry, BTS
inquiry about open bugs and owning packages. Before joining the burden
of maintaining both, now in the same package, I cannot help thinking
whether there is an alternative :-)
Regarding your dput hook use case, which is a really interesting one,
I don't see a problem in that hook being encoded as "tagpending
--check", you write once, you stop thinking about it forever.
That said, I do agree that the name of the tool (tagpending) could
become non-intuitive. So my proposal is to actually add the option to
tagpending *and* to have an additional symlink under /usr/bin,
pointing to tagpending, which would just mimic the (future) behavior
of the tagpending check. How does that sound?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519377: Integrate yaclc in devscripts?
On Mon, Jul 20, 2009 at 02:27:31PM +0200, Patrick Schoenfeld wrote:
> Sandro Tosi orphaned the package yaclc, because the maintainer of
> it (Thomas Smith ) isn't active anymore.
>
> Ralf Treinen suggested to integrate it into devscripts.
> I think that this is a good idea. What do the other devscripts
> maintainers think?
Do we really need (yet another) separate tool for that?
If the check is all it does, it looks like a simple "--check" option
can be added to tagpending to achieve the same effect.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#535975: ITP: turbogears2-doc -- documentation for the TurboGears2 web framework
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: turbogears2-doc Version : svn snapshot r6598 Upstream Author : Kevin Dangoor and contributors * URL : http://www.turbogears.org/2.0/docs/ * License : MIT Programming Lang: documentation (HTML generated from RST) Description : documentation for the TurboGears2 web framework TurboGears2 is a framework to develop web applications in Python, following a model-view-controller architecture. . The main TurboGears2 package is python-turbogears2. This package contains the framework documentation (architecture description, tutorials, references, howtos and recipes, ...) . The documentation shipped by this package corresponds to what is usually available on the TG2 documentation website. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534686: ITP: python-tgext.admin -- user management controller add-on for TurboGears
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-tgext.admin Version : 0.2.4 Upstream Author : Christopher Perkins * URL : http://pypi.python.org/pypi/tgext.admin * License : MIT Programming Lang: Python Description : user management controller add-on for TurboGears TurboGears2 is a framework to develop web applications in Python, according to the model-view-controller (MVC) architecture; tgext.admin is a controller add-on for TurboGears2 that provides a user interface to manage users, groups, and their permissions. . tgext.admin is compatible with the basic TurboGears2 identity model. The package will be maintained under the umbrella of the Python Modules Team. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534311: ITP: sprox -- Python library to generate web widgets from database schemas
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: sprox Version : 0.6.2 Upstream Author : Christopher Perkins * URL : http://www.sprox.org/ * License : MIT Programming Lang: Python Description : Python library to generate web widgets from database schemas Sprox is a Python library to generate web widgets from database schemas. . Sprox provides an easy way to create forms for web content which are: automatically generated, easy to customize, and validated. The way in which Sprox displays content is customizable by the means of different "viewers". Finally, Sprox provides a way to fill your widgets, whether they are forms or other content with customizable data. The package will be maintained under the umbrella of the Python Modules Team. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534307: ITP: python-catwalk -- model management interface for the Turbogears web application framework
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-catwalk Version : 2.0.2 Upstream Author : Christopher Perkins * URL : http://pypi.python.org/pypi/Catwalk * License : MIT Programming Lang: Python Description : model management interface for the Turbogears web application framework TurboGears2 is a framework to develop web applications in Python, according to the model-view-controller (MVC) architecture. . Catwalk is a component to manage TurboGears2 models via a simple, web-based interface. . Using Catwalk application developers can populate their database with sample data for rapid prototyping purposes. Similarly, Catwalk can be used to manage models of deployed applications skipping other application-specific interfaces. The package will be maintained under the umbreall of the Debian Python Modules Team. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532625: ITP: python-peak.util -- utilities from the Python Enterprise Application Kit
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-peak.util Version : 20090610 Upstream Author : Philip J. Eby * URL : http://peak.telecommunity.com/ * License : dual-license: Python license (PSF) or Zope public license Programming Lang: Python Description : utilities from the Python Enterprise Application Kit The Python Enterprise Application Kit (PEAK) is a set of Python libraries to help develop large-scale Python applications. . PEAK includes libraries and frameworks to support: component integration, component configuration , document-driven testing, event-driven programming, storage management and persistence, domain modelling, and much more. . This package provides a subset of utilities related to PEAK, and commonly found as dependencies for PEAK-based components. In particular, this package provides: . * AddOns - dynamic mixins with private attribute and methods * BytecodeAssembler - code object generation assembling bytecode * Extremes - absolute max and min values (PEP 326 implementation) * SymbolType - symbol type, i.e., enumerations The above are four different upstream packages, but all small enough to not warrant a separate source package (IMO). Collectively, they form a significant subset of the peak.util namespace. Also, they are collectively needed as dependencies for PEAK.rules (ITP #531871), which in turn is a dependency needed to un-FUBAR TurboJson (#507909). The package will be maintained under the umbreall of Python Modules Team: help is appreciated. Cheers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531871: will be fixed by (fulfilling) ITP 531871
Package: python-turbojson
Version: 1.2.1-1
Followup-For: Bug #507909
As already observed, this bugs boils down to a missing dependency,
which isn't yet packaged in Debian, namely PEAK.Rules. I've ITP-ed it,
the corresponding bug log is 531871.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531871: ITP: python-peak.rules -- generic functions and business rules support systems for Python
On Thu, Jun 04, 2009 at 07:15:04PM -0300, Gustavo Noronha wrote:
> This is the thing that replaces python-dispatch (ruledispatch source
> package), by the way. You may want to get rid of that one soonish
> (as in, ASAP).
Thanks for the heads up. I noticed that there was some overlapping,
but I wasn't sure that PEAK rules completely replaces dispatch. Once
I've the package ready, do you know where/what I should test to ensure
the replacement is completely functional?
More generally, if you are aware of any incompatibilities, I'd
appreciate hints :-)
Thanks!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531871: ITP: python-peak.rules -- generic functions and business rules support systems for Python
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-peak.rules Version : 0.5a1 Upstream Author : Phillip J. Eby * URL : http://pypi.python.org/pypi/PEAK-Rules * License : ZPL Programming Lang: Python Description : generic functions and business rules support systems for Python long description following soon ... I'm packaging this is because PEAK Rules is one of the missing dependencies for turbojson, no matter its being currently uploaded to unstable. Without PEAK Rules, turbojson is currently useless and makes in turn unusable both turbogears2 *and* turbogears 1 (which was working in Lenny). More details can be found in #507909, which I'm Cc-ing with this ITP bug report. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531848: ITP: python-tg.devtools -- developer tools for the TurboGears web framework
On Thu, Jun 04, 2009 at 03:01:03PM +0200, Stefano Zacchiroli wrote:
> Another important note is that this package depends on
> zope.sqlalchemy which is not currently packaging. I'm trying to
> contact the Zope maintainers to decide whether I'm to package it or
> they are.
Just receive a comment about that from the Zope people (via Fabio
Tranchitella): they are packaging zope.sqlalchemy, hence tg.devtools
will just depend on their work. Thanks!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#531848: ITP: python-tg.devtools -- developer tools for the TurboGears web framework
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-tg.devtools Version : 2.0 Upstream Author : Kevin Dangoor and contributors * URL : http://www.turbogears.org/ * License : MIT/X Programming Lang: Python Description : developer tools for the TurboGears web framework TurboGears2 is a framework to develop web applications in Python, following a model-view-controller architecture. . The main TurboGears2 package is python-turbogears2. This package contains developer tools that ease developing TurboGears applications. In particular, this package provide integration with the Python Paste tools implementing scaffolding command to start developing TurboGears2 applications. I'm packaging this as a dependency of TurboGears2, which is currently in unstable but is lacking the packaging of its dependencies to work (gap that I'm trying to fill). The code of this particular package is currently shipped by python-turbogears2, but---as discussed with other folks of #debian-python---it is better to package it separately. Until the turbogears2 package itself is fixed to account for this code move, this package will stay in experimental. Another important note is that this package depends on zope.sqlalchemy which is not currently packaging. I'm trying to contact the Zope maintainers to decide whether I'm to package it or they are. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531208: ITP: python-repoze.what-plugins -- authorization framework for Python WSGI applications - plugins collection
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-repoze.what-plugins Version : 20090540 Upstream Author : Various authors * URL : http://pypi.python.org/pypi?%3Aaction=search&term=repoze.what&submit=search * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : authorization framework for Python WSGI applications - plugins collection repoze.what is an authorization framework for WSGI applications, based on repoze.who (which deals with authentication and identification). . This package contains a collection of plugins for repoze.what, in particular: . * repoze.what.plugins.sql - adapter plugin for SQLAlchemy * repoze.what-pylons - integration with Pylons / TurboGears * repoze.what-quickstart - simple authentication and authorization * repoze.what.plugins.sql - XML adapter plugin This package will contain _a collection of_ plugins for Python repoze.what. A sampling of them can be seen at http://pypi.python.org/pypi?%3Aaction=search&term=repoze.what&submit=search . A core part of them is needed as a dependency for TurboGears2. Same disclaimer about "multiple source package" vs "archive bloat" as I wrote in #531146 . The current choice is to prefer "multiple source package", as it was done in python-repoze.who-plugins. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531146: ITP: python-repoze.who-plugins -- authentication framework for Python WSGI applications - plugins collection
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-repoze.who-plugins Version : 20090530 Upstream Author : Various athors * URL : http://pypi.python.org/pypi?%3Aaction=search&term=repoze.who&submit=search * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : authentication framework for Python WSGI applications - plugins collection repoze.who is an identification and authentication framework for arbitrary Python WSGI applications; it acts as WSGI middleware and is inspired by Zope 2's Pluggable Authentication Service (PAS). . This package contains a collection of plugins for repoze.who, in particular: . * repoze.who-friendlyform - developer-friendly forms * repoze.who-plugins.sa - SQLAlchemy integration * repoze.who-testutil - test utilities for repoze.who applications * repoze.who.plugins.ldap - LDAP authentication * repoze.who.plugins.openid - login via OpenID * repoze.who.plugins.recaptcha - server-side recaptcha implementation This package will contain _a collection of_ plugins for Python repoze.who. A sampling of them can be seen at http://pypi.python.org/pypi?%3Aaction=search&term=repoze.who&submit=search . A core part of them is needed as a dependency for TurboGears2. The reason why I'm proposing a collection package (i.e., a source package with more than one upstream) is that, taken individually, the plugins are about 20/30 Kb and I fear polluting the archive with too many small packages. In this case, I consider the choice of the collection package worth, but it will carry the usual drawbacks of multiple upstream packages. If people, especially from the Debian Python Modules team, have arguments to prefer several source packages (I will need at least 4 for TG2), please let me know. Cheers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531083: ITP: python-repoze.who -- Identification and authentication framework for Python WSGI applications
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-repoze.who Version : 1.0.13 Upstream Author : Agendaless Consulting * URL : http://www.repoze.org/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Identification and authentication framework for Python WSGI applications repoze.who is an identification and authentication framework for arbitrary Python WSGI applications; it acts as WSGI middleware. . repoze.who is inspired by Zope 2's Pluggable Authentication Service (PAS), but is not dependent on Zope in any way; it is useful for any WSGI application. . It provides no facility for authorization (ensuring whether a user can or cannot perform the operation implied by the request). This is considered to be the domain of the WSGI application. [ mini-boilerplate follows, for the sake of context in the bug log ] I'm packaging this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *looking for help* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531042: package uploaded to experimental
tags 531042 + pending
thanks
The package has been resurrected from its previous location:
Vcs-Svn:
svn://svn.debian.org/python-modules/packages/python-toscawidgets/trunk/
Vcs-Browser:
http://svn.debian.org/viewsvn/python-modules/packages/python-toscawidgets/trunk/
The package has been uploaded to experimental, but will need to pass
through NEW.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#531038: package now available
tags 531038 + pending
thanks
repoze.tm2 is now available. Its packaging is in SVN:
Vcs-Svn: svn://svn.debian.org/python-modules/packages/python-repoze.tm2/trunk/
Vcs-Browser:
http://svn.debian.org/viewsvn/python-modules/packages/python-repoze.tm2/trunk/
and the package has been uploaded to experimental (but must need to go
through NEW).
*However* the package depends on python-transaction, which is being
packaged by the Zope team. Before that package is available, you'll
need to easy_install python-transaction to be able to install
repoze.tm2.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#531038: ITP: python-repoze-tm2 -- Zope-like transaction manager via WSGI middleware
retitle 531038 ITP: python-repoze.tm2 -- Zope-like transaction manager via WSGI
middleware
thanks
[ adding back the ITP bug log to Cc:, full quote to its benefit ]
On Fri, May 29, 2009 at 06:48:08PM +0200, Fabio Tranchitella wrote:
> Hello Zack,
>
> * 2009-05-29 14:20, Stefano Zacchiroli wrote:
> > * Package name: python-repoze-tm2
>
> repoze.tm2 depends on transaction, which is a python module which will be
> packaged very soon by the Debian/Ubuntu Zope team as the result of the
> splitting of the old monolithic zope3 package.
Indeed, I was just going to ITP it :-), but I'll refrain then. Please
do so, so that we can keep track of the work. In the meantime, I'll
package tm2, assuming transaction will be called
"python-transaction". Please let me know when you have draft packages,
so that I can better test all the stack up to TG2.
> More details about this splitting and how it will affect reverse
> dependencies will be send out in an announcement to debian-python,
> but the general rule is that we are trying to keep the naming of the
> python module as linked as possible with their setuptools name.
>
> For example, zope.interface will have a source file called
> zope.interface and a binary package called python-zope.interface. I
> would suggest to apply the same rules to these packages, calling the
> binary python-repoze.tm2.
OK, I'll do the renaming both in the source and in the binary package.
Thanks for the heads up.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#531046: ITP: python-repoze-what-pylons -- Authorization framework for Python WSGI applications - Pylons/TG2 plugin
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-repoze-what-pylons Version : 1.0 Upstream Author : Gustavo Narea * URL : http://pypi.python.org/pypi/repoze.what-pylons/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Authorization framework for Python WSGI applications - Pylons/TG2 plugin Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531045: ITP: python-repoze-what -- Authorization framework for Python WSGI applications
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-repoze-what Version : 1.0.8 Upstream Author : Gustavo Narea * URL : http://www.repoze.org/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Authorization framework for Python WSGI applications Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531044: ITP: python-webflash -- Portable flash messages for Python WSGI apps
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-webflash Version : 0.1a9 Upstream Author : Alberto Valverde Gonzalez * URL : http://python-rum.org/wiki/WebFlash * License : MIT/X Programming Lang: Python Description : Portable flash messages for Python WSGI apps Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531042: ITP: python-toscawidgets -- Web widget creation toolkit based on TurboGears widgets
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-toscawidgets Version : 0.9.4 Upstream Author : Alberto Valverde Gonzalez * URL : http://toscawidgets.org/ * License : MIT/X Programming Lang: Python Description : Web widget creation toolkit based on TurboGears widgets Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] Packaging will continue from the current SVN of python-toscawidgets, which was worked on in 2007, but never uploaded. The previous packagers agree (and hopefully will collaborate :-)) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#531038: ITP: python-repoze-tm2 -- Zope-like transaction manager via WSGI middleware
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: python-repoze-tm2 Version : 1.0a4 Upstream Author : Agendaless Consulting * URL : http://pypi.python.org/pypi/repoze.tm2/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Zope-like transaction manager via WSGI middleware Long description coming soon ... I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. Cheers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527906: ITP: ocaml-text -- library for dealing with sequences of Unicode characters
On Sun, May 10, 2009 at 02:38:40AM +0200, Stephane Glondu wrote:
> > Please improve the long descriptions, some hints: [...]
> What about:
Good!, finally I understand (without having to look at the library
itself) what ocaml-text does :-)
> >> OCaml-Text is designed to be easy to use and interacts well with
> >> other projects.
> > Is this line useful? "interacts well with other projects" sounds like
> > marketing and nothing else ...
> What's wrong with marketing? :-)
That its S/N is 0 :-) I've nothing against marketing, which is
arguably also part of a software description, but it should provide
info. Saying "other projects" is pretty useless to me: either you
mention which projects are compatible with ocaml-text or you explain
what of ocaml-text makes it "easy to interoperate" (or you drop the
sentence :-))
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527906: ITP: ocaml-text -- library for dealing with sequences of Unicode characters
On Sat, May 09, 2009 at 11:44:52AM +0200, Stephane Glondu wrote:
> Description : library for dealing with sequences of Unicode characters
Please improve the long descriptions, some hints:
> OCaml-Text is an OCaml library for dealing with "text", i.e. sequences
> of Unicode characters, in a convenient way. It supports:
> * easy encoding/decoding of text;
> * a lot of functions for manipulation of UTF-8 encoded strings;
This line is useless, at least to me. What does it mean "a lot of
functions"? A lot of functions to do what kind of operations? I still
don't get from the descriptions whether they are some low-level
encoding handling functions or some high-level functions like text
layout (like boxes et al.).
> OCaml-Text is designed to be easy to use and interacts well with
> other projects.
Is this line useful? "interacts well with other projects" sounds like
marketing and nothing else ...
Thanks!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#525192: ITP: vtg -- Vala Toys for gEdit
On Thu, Apr 23, 2009 at 12:44:24AM +0300, Marc-André Lureau wrote:
> 2009/4/23 Josselin Mouette :
> > The package name doesn’t sound really helpful. How about something like
> > gedit-plugins-vala?
>
> I fully agree. However, upstream name is vtg. I am not familiar with
> policy about upstream package name, and whether we can rename them (I
> guess it's not a so good idea).
Well, "vtg" does not look like particularly conflict prone to me, so
it can probably stay at the *source* package name. On the contrary,
"gedit-plugins-vala" looks like a way better *binary* package name,
which is what users see.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#524834: ITP: syncmaildir -- Sync Mail Dir is a set of tools to synchronize Maildirs
On Tue, Apr 21, 2009 at 02:17:58PM +0200, Enrico Tassi wrote:
> AFAIK OfflineIMAP gives you (or will give you soon) something more
> called always-connected-with-ther-server-to-fetch-mail-ASAP option
JFTR, that would be support for IMAP "IDLE" command:
http://git.complete.org/offlineimap?a=commit;h=9e085565293b3aeb1592ccda7cc461a5e448a83d
Regarding the ITP, I suggest to stress in the long description a bit
more the features of syncmaildir; in particular I would be happy to
read there that there are the two pull/push tools because it is what
will give me the feeling of the tool workflow.
Just my 0.02€,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518869: ITP: shorewall6 -- Shoreline Firewall (IPv6 version), netfilter configurator
On Sun, Mar 08, 2009 at 08:34:23PM -0400, Roberto C. Sanchez wrote:
> Description : Shoreline Firewall (IPv6 version), netfilter configurator
Uh? Can you please explain?
Even though I'm not following the upstream evolution I'm a user of the
shorewall package, which has IPv6 support even though disabled by
default. Why we now need a separate package now?
Thanks in advance,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
On Tue, Feb 17, 2009 at 07:14:45PM -0800, Marc Singer wrote:
> Also, it doesn't look like you're a DD. Why are you so keen to
> maintain it?
Please consider refraining to post comments like this in the
future. Your intention might have been good, but written as you wrote
it, it can discourage non-DDs to maintain packages.
We have sponsorship in place exactly because we (unless proven
otherwise) want also non-DDs to maintain packages, of course with
mentoring and review in place before uploading.
Also, the Debian Project endorsed the notion of Debian Maintainer [1]
which, again, show our support to non-DDs maintaining packages
(sometime for the interim before becoming DDs, sometime not).
Cheers.
[1] http://www.debian.org/vote/2007/vote_003
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#515330: RFA: gpscorrelate
Package: wnpp Severity: normal I'm looking for a new maintainer for the source package gpscorrelate, a tool to correlate digital photos with GPS data filling the relevant EXIF fields. The tool comes with a command line interface as well as a GUI, it is implemented in C++, has a responsive maintainer subscribed to PTS notifications, and is relatively low maintenance. Packaging itself is in good shape, but still in the debhelper 5 era with CDBS. Maintenance has always happened in the collab-maint repository, using SVN (planned but never happened migration to Git). I'm giving the package away simply because I no longer use the software, having now at least a camera with built-in GPS. Please follow-up if you are interested in maintaining the package: FCFS policy. If I don't receive replies in a reasonable timeframe (say, 1-2 weeks), I'll formally orphan it. Cheers. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514639: ITP: frei0r -- a minimalistic plugin API for video effects
On Tue, Feb 10, 2009 at 06:35:16PM +0100, Luca Bigliardi wrote:
> Many thanks! I've updated the description with a few more details for
> binary plugins package and: "frei0r plugins are used by several projects
> (e.g.: LiVES, Veejay, Open Movie Editor, FreeJ, Pure Data Visual Junk
> Tools, MLT framework).".
Cool, thanks.
> You can follow the changes here:
> http://git.dyne.org/index.cgi?url=frei0r/log/&h=debian
Any reason for the project for not being hosted on the git repo of
collab-maint?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#514639: ITP: frei0r -- a minimalistic plugin API for video effects
On Tue, Feb 10, 2009 at 10:30:06AM +0100, Luca Bigliardi wrote:
> On Mon, Feb 09, 2009 at 03:33 PM, Ron Johnson wrote:
>
> > What apps support this?
>
> MLT framework (thus things like kdenlive), FreeJ, LiVES among all.
> There's a list on the project homepage.
>
> Do you think I should mention that in the description field?
Yes, definitely.
Remember that the description should be enough for a random sysadm to
understand whether she needs the package or not, and just "plugin"
does not really help in that sense.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#512834: ITP: ocaml-autoconf -- autoconf macros for OCaml
On Mon, Jan 26, 2009 at 08:42:52AM +0100, Ralf Treinen wrote:
> we also have Jean-Christophe Filliatre's configure.in and
> Makefile.in templates that are currenly in the ocaml-tools package,
> for lack of any better place for it. Maybe they can be packaged
> together with ocaml-autoconf, or ocaml-autoconf can be part of the
> ocaml-tools package?
Interesting, I didn't know that. Those two files should definitely be
companions of ocaml-autoconf, and I presume they initially were meant
as such.
Jean-Christophe has already agreed in relicensing ocaml-autoconf
macros, I presume there will be no problem in doing the same with
those snippets and distributing them together with ocaml-autoconf.
Regarding the packaging, I've no objections in adding all this to
ocaml-tools, but I had the impression you were in the past
"discouraging" multiple-source Debian packages. In fact that's one of
the reasons for me to propose a separate package. But if you are fine
with adding another bit to ocaml-tools I've no objections whatsoever.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512834: ITP: ocaml-autoconf -- autoconf macros for OCaml
On Sat, Jan 24, 2009 at 01:34:19PM +0100, Stéphane Glondu wrote:
> Stefano Zacchiroli a écrit :
> > Nevertheless, I don't want to package this together with the compiler
> > itself, because it would become painful to update.
>
> What about putting it in dh-ocaml?
I thought about it, and discarded this option. Rationale: dh-ocaml is
targeted at debian package builders, ocaml-autoconf at application
builders (i.e. programmers).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512834: ITP: ocaml-autoconf -- autoconf macros for OCaml
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli * Package name: ocaml-autoconf Upstream Author : Richard Jones, Stefano Zacchiroli, et al. * URL : http://ocaml-autoconf.forge.ocamlcore.org/ * License : BSD (3-clauses) Programming Lang: m4 Description : autoconf macros for OCaml RFC: this package will consists of just one file: /usr/share/ocaml-autoconf/ocaml.m4 , and this puzzles me a bit as overkilling. Nevertheless, I've no clue about how autoconf extensions should be packaged, and my naive attempts to find similar packages in the archive failed. Nevertheless, I don't want to package this together with the compiler itself, because it would become painful to update. Any suggestions? -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512658: ITP: coccinelle -- semantic patching tool for C
On Thu, Jan 22, 2009 at 05:24:49PM +0100, Євгеній Мещеряков wrote:
> * Package name: coccinelle
> Version : >= 0.1.4
> Upstream Authors: Julia Lawall
> Yoann Padioleau
> Rene Rydhof Hansen
> Henrik Stuart
> * URL : http://www.emn.fr/x-info/coccinelle/
> * License : GPLv2
> Programming Lang: OCaml, Python
> Description : semantic patching tool for C
Please get in touch with Debian OCaml maintainers (Cc-ed) to maintain
this package, possibly using a git repo under the hood of the
collaborative package maintenance. Also, please read the OCaml policy,
et al. :)
Thanks for your interest in packaging that!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Bug#472802: what is missing for a limesurvey upload?
On Mon, Jan 12, 2009 at 07:22:24AM +, Julian Gilbey wrote:
> I don't know about collab-maint - please could you give us some
> details of how we access it etc.?
The full story is here: http://wiki.debian.org/Alioth/PackagingProject
The short is that limesurvey is currently available at the following
SVN URL on alioth:
svn+ssh://svn.debian.org/svn/collab-maint/ext-maint
to which any DD can commit + anyone having an Alioth account and being
a member of the "collab-maint" project [1].
Cheers.
[1] http://alioth.debian.org/projects/collab-maint/
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#472802: what is missing for a limesurvey upload?
On Sun, Jan 11, 2009 at 04:36:26PM +0100, Nick Barcet wrote:
> Well, since I received the previous message, I thought that Mathieu was
> taking over. However, a version of my package is waiting for a review
> and possibly some fixes at: http://www.nijaba.info/debian/
Thanks for the pointer.
> Feel free to do whatever you want to it
Please expand: I'm willing to review / sponsor your package, but I'm
not willing to maintain it in Debian for the moment. Hence, if you (or
someone else) want to take care of maintaining it I'll be happy to
sponsor---even routinely---if there is the need.
If this is not the case it would be quite pointless to sponsor the
upload of a package which will be de facto orphaned just after its
first upload.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#472802: what is missing for a limesurvey upload?
On Wed, Oct 08, 2008 at 08:42:04PM +0200, Mathieu Parent wrote:
> I have also packaged limesurvey (unfortunately I've seen this ITP too
> late). We can join our forces.
>
> Mine is in collab-maint, I can make the merge.
>
> What do you think?
Hi all, thanks for your work on the limesurvey package.
I'm gonna need this software and I'm saddened to not seeing it in the
Debian archive yet.
Can I ask what is mussing for uploading the package? Is it just a
matter of sponsoring or what? If you need sponsoring please let me
know, as I'd be happy to help out (as I'm going to use your package
anyhow :-)).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506865: RFP: pylzma -- Platform independent python bindings for the LZMA compression library
On Thu, Nov 27, 2008 at 07:59:44PM +0100, Daniel Rus Morales wrote: > The upstream package contains most of the LZMA v4.42 sources, some > of them were modified by the pylzma author. I tried to substitute > some of the dependant sources compiling against lzma and lzma-dev > official packages, but that does not work due to the current version > provided by lzma and lzma-dev, that is the v4.43 (current upstream > stable release for LZMA is already 4.57). > > To prevent any confusion between the version of LZMA provided by the > package "lzma" and the one that comes with "python-pylzma" I added > the release number to the later, so the package name is > "python-pylzma-4.42". Sorry, that's not acceptable, we can not ship two different versions of LZMA in Debian, one quite well hidden into a binding. The reason is security: if a security issue gets discovered about LZMA, we will need to fix it into several places. More philosophically, free software is about sharing, and with sharing (usually) comes factorization, we should factorized the code. Bottom line: PyLZMA should be make working with Debian's LZMA, possibly getting in touch with LZMA's maintainers to apply patches if needed. When doing that, please Cc this RFP. > Could you sponsor the package? > I'll wait for your remarks if any. List of remarks follows (notwithstanding the showstopper above): - debian/control should be 7, it is a new package, it is pointless to use an old debhelper, same goes for the debhelper deps in control - you should reopen 401034, as you have been working on the package, to avoid duplicate work by someone else - you should change the target distribution in changelog to experimental: we are near a Debian release, and unstable should not be targeted by packages which wont be part of Lenny anhow - debian/copyright is quite a mess, why you have several licenses into it? it is pointless unless you explain which part of the (source) package are subject to each license. I suggest you to have a look at http://wiki.debian.org/Proposals/CopyrightFormat and implement that proposal in your debian/copyright - debian/watch is missing, it shouldn't be - distributing version.txt as a documentation is pointless - regression tests are not (necessarily (all)) good examples Finally, I'm no Python-stuff packaging guru (that's why I didn't package PyLZMA by myself in the first place), and I particularly I've never used python-central (only python-support), so for a review of that I'd prefer you to ask for comments on some debian/python mailing list. Again, please Cc the RFP in doing so. When all this gets solved, I'll be more than happy to sponsor an upload. Thanks in advance, Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#506865: RFP: pylzma -- Platform independent python bindings for the LZMA compression library
Package: wnpp Severity: wishlist * Package name: pylzma Upstream Author : Joachim Bauch * URL : http://www.joachim-bauch.de/projects/python/pylzma/ * License : LGPL-2.1+ Programming Lang: Python Description : Platform independent python bindings for the LZMA compression library There was an old ITP about this software (#401034) which has been closed automatically due to no progress, I've no idea how far the packaging work has gone. Beside other things, pylzma support is needed to support .deb containing LZMA-compressed parts in python-debian (see ##503983). TIA, Cheers. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#504991: ITP: camlbz2 -- OCaml bindings for the bzip2 compression library
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> * Package name: camlbz2 Version : 0.6.0 Upstream Author : Stefano Zacchiroli <[EMAIL PROTECTED]> * URL : http://camlbz2.forge.ocamlcore.org/ * License : LGPL with OCaml linking exception Programming Lang: OCaml Description : OCaml bindings for the bzip2 compression library CamlBZ2 provides OCaml bindings for libbz2 (AKA bzip2), a popular compression library which typically compresses better (i.e., smaller resulting files) than gzip. Using CamlBZ2 you can read and write compressed "files", where files can be anything offering an in_channel/out_channel abstraction (files, sockets, ...). Also, with CamlBZ2 you can compress and decompress strings in memory using the bzip2 compression algorithm. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
On Thu, Oct 23, 2008 at 11:14:53PM +0900, Tatsuya Kinoshita wrote: > > I think that a package for one single file is too much. I agree with Luca here. FWIW I also formally object to this ITP. > Even so, the Debian package is helpful for users to install, > upgrade and use it. This is not an argument per se. Everything which should be installed on user machines can benefit to be managed as a package. Still, we have trade-offs to do about the maintainability of our package base. > `alpaca' is an old and simple way. > > The old version of alpaca (named gpg.el) was released in 2003 and > has been useful ever since. EasyPG, "yet another GnuPG interface > for Emacs", version 0.0.1 was released in 2006, and then merged the > development version of Emacs (will be 23.1 release) in 2008. Indeed, the fact that EasyPG is now integrated in development version of Emacs is my main reason for objecting this ITP. I'm using emacs-snapshot from [1] and without any configuration at all *.gpg files are handled properly. The level of integration is the same I used to have with gnupg.vim as shipped by vim-scripts. Hence the question goes as: considering that the next release of Debian is most likely going to be released with Emacs (>= 23.1), which is integrated properly with EasyPG, do we need alpaca in Debian? I believe the answer is «no». [1] http://emacs.orebokech.com/ > `alpaca' just provides a hook function for *.gpg file handling. > Meanwhile EasyPG is a powerful tool which also provides keyring > browser, dired integration, mail functions and so on. So, the > source code of alpaca is more small and simple. Yes, but EasyPG is integrated with a package we already have, and the complexity you are mentioning is not exposed to the random user of *.gpg files. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
