Re: RFS: icecat
Hello, On Sat, 20 Aug 2011 10:11:10 +0200 Javier Sancho wrote: > Andrew O. Shadoura wrote: > > i) What's the point of it, how is it different from Iceweasel? > The goal of the IceCat project is to provide a completely free version > of the popular Mozilla source code. Iceweasel is already free, isn't it? > It is (so far the only) part of Gnuzilla, the umbrella project > analogous to Mozilla. The base Mozilla code is free but it supports > and suggests using non-free plugins and other modules. GNU IceCat is > completely free, and suggests only free plugins to users. It's not about freedom, it's about limiting it for the users. Users must be free to install non-free extensions and plug-ins if they want to. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: icecat
Hello, On Fri, 19 Aug 2011 09:04:44 +0200 Javier Sancho wrote: > I am looking for a sponsor for my package "icecat". i) What's the point of it, how is it different from Iceweasel? ii) Why doesn't your package use pre-existing XULRunner in Debian? -- WBR, Andrew signature.asc Description: PGP signature
Re: Solving lintian warnings for multi-package roxterm
Hello, On Wed, 17 Aug 2011 21:19:44 +0100 Tony Houghton wrote: > roxterm-legacy: binaries compiled and linked with GTK2 > roxterm: binaries compiled and linked with GTK3 > roxterm-common: All the other files An off-topic question: why've you chosen this naming scheme? Why 'legacy'? In particular, I'm not going to switch to GTK+3 any time soon, and guess I'm not alone, so it can't be legacy, I think. -- WBR, Andrew signature.asc Description: PGP signature
RFS: bmake -- NetBSD make
Hello, I am looking for a sponsor for my package 'bmake'. * Package name: bmake Version : 20110622-1 Upstream Author : Simon J. Gerraty * URL : http://www.crufty.net/help/sjg/bmake.htm * License : BSD Section : devel It builds this binary package: bmake - NetBSD make The upload would fix these bugs: #476267, #627983. The original packaging was done by NetBSD developer Aleksey Cheusov. Together with Jeroen Schot we're working on this package maintainance. This package is important as pmake that's currently in Debian is too old and obsolete, and bmake's absense is preventing some software from entering Debian. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/package/bmake - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bmake/bmake_20110622-1.dsc Also, it's kept under version control here: http://anonscm.debian.org/hg/collab-maint/bmake I would be glad if someone uploaded this package for me. -- WBR, Andrew signature.asc Description: PGP signature
Re: tkpath review
Hello, On Thu, 11 Aug 2011 15:46:48 +0300 "Andrew O. Shadoura" wrote: > ix) Vcs-* fields. Put your packaging under version control and upload > it to Alioth using whatever VCS you like (it may be Git or Mercurial > or anything else). There are some tools which simplify (or not > really) the workflow when using VCS, you may be interested in using > them. Then uncomment Vcs-* fields and put the actual URLs there. > Don't forget to commit changes! Well, using VCS is entirely optional while it's definitely good and recommended. In the case you have your reasons for not using it at all, it's better to remove those commented fields. -- WBR, Andrew signature.asc Description: PGP signature
tkpath review
Hello Vitaly,
I'm glad to see you're going to maintain tkpath, as it's really useful
piece of software (and I thought of making a package myself once).
However, your packaging ([1]) has some problems which would be good to
fix.
Also, I'm not a DD so I can't upload, sorry :)
Well, let's start. Sure, that's not everything, but just things I could
spot easily.
i) debian/changelog: your entry must close an ITP bug (don't put xx
there, open a real bug report; you can use reportbug program to
simplify this).
ii) Most probably you don't want to create a native package (read
maintainer's documentation on this [2]), therefore the package's
version should be 0.3.1-1. Please change debian/source/format too.
iii) Your package build-depends on debhelper (>= 7.0.50~) but doesn't
seem to actually use any features of it. I'd recommend you to actually
use dh7's short form, which makes it possible to radically reduce
the number of lines your debian/rules file. That also highlights your
changes to the boilerplate rules file and makes them easy to spot.
Also, if the build process changes in the future, the changes will be
minimal.
iv) Your debian/control says the package depends on '${shlibs:Depends},
${misc:Depends}, tk8.5 , tcl8.5'. First, I'd remove the extra after
tk8.5, but are you sure it's really 8.5? You'd better use
${tcl:Depends} and ${tk:Depends} and tcltk-depends helper from tk-dev
package, on which you should build-depend if you use it.
v) Also, in the same file you build-depend on tcl8.5-dev and tk8.5-dev.
That means, I can't build the package if I have no 8.5 packages
installed but I do have {tcl,tk}8.4-dev and {tcl,tk}8.6-dev. You should
depend on tk-dev and tcl-dev. I'm pretty sure the package will build on
8.4 too, but please test and add versioned dependencies if it doesn't.
vi) mv $(CURDIR)/debian/tmp/usr/lib/* $(PDIR)/usr/lib/tcltk. This step
is not needed AFAIK, the dirs file listing /usr/lib/tcltk is not as
well. Looking at tclxml package, it works perfectly
from /usr/lib/Tclxml3.x, so should tkpath.
vii) You have debian/docs empty, but list doc/* in debian/rules as
`dh_installdocs doc/*`. Please use debian/docs instead.
viii) debian/control again. You have the following short description:
'It is an extension package to Tcl/Tk for the canvas widget'. Drop 'It
is'. Just something like 'Tcl/Tk improved canvas widget' would be
enough, I think. Also, remove ANNOUNCE stuff from the long description
and clean it up a bit.
ix) Vcs-* fields. Put your packaging under version control and upload
it to Alioth using whatever VCS you like (it may be Git or Mercurial or
anything else). There are some tools which simplify (or not really) the
workflow when using VCS, you may be interested in using them. Then
uncomment Vcs-* fields and put the actual URLs there. Don't forget to
commit changes!
x) After you fix the problems above, don't forget to run your packaging
through lintian and fix at least the most important problems it
indicates. Then, please read the Policy changelog, find out what's
changed between 3.8.4 and 3.9.2 and determine if it concerns you.
If you have any questions, don't hesitate to ask. Please keep the
mailing list CC'ed (also, you may want to subscribe to it).
When you have any progress, upload what you did to mentors/debexpo
and post a message here.
Links:
[1] http://mentors.debian.net/debian/pool/main/t/tkpath/tkpath_0.3.1.dsc
[2]
http://www.debian.org/doc/manuals/maint-guide/first.en.html#non-native-dh-make
--
WBR, Andrew
signature.asc
Description: PGP signature
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
Hello, On Thu, 30 Jun 2011 17:21:05 +0200 Kilian Krause wrote: > > > 5. Lintian issues (lintian -iI --pedantic): > > >W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1 > > >W: tnat64: non-dev-pkg-with-shlib-symlink > > > usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so I: tnat64: > > > no-symbols-control-file usr/lib/libtnat64.so.0.1 > > Isn't really relevant, as this is a LD_PRELOAD-able library. > What's the one to do with the other here? If it's a real shared > library it can and even should be split out to a lib package. The > possibility to preload it doesn't really make more sense to me than > linking it in statically I guess. But maybe I just missed your point. This package doesn't make any sense without LD_PRELOAD, it's all about the library which gets preloaded to hook into some Berkeley sockets functions. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
Hello, On Thu, 30 Jun 2011 17:18:50 +0200 Kilian Krause wrote: > > > >> >Isn't really relevant, as this is a LD_PRELOAD-able library. > this discussion about moving a shared lib into private namespace is > somewhat puzzling me. If the code it provides is only used internally > - why not link it in statically and don't ship it? Because it has to be dynamic --- it gets LD_PRELOADed into the process. If it was static, that'd not be possible. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
Hello, On Thu, 30 Jun 2011 13:07:12 +0200 "SZERB, Tamas" wrote: > >> * Andrew O. Shadoura , 2011-06-30, 00:30: > >> >> 5. Lintian issues (lintian -iI --pedantic): > >> >> W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1 > >> >> W: tnat64: non-dev-pkg-with-shlib-symlink > >> >> usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so > >> >> I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1 > >> >Isn't really relevant, as this is a LD_PRELOAD-able library. > >> Then there's no reason to install the library into /usr/lib. > >> Install it to a private directory instead. And you don't need any > >> symlinks either. > > Agree. In that case this is also relevant to tsocks package (Cc'ed). > Could you provide the bug #number to see the whole? There isn't a bug filed, but as my tnat64 is actually a fork of tsocks (he-he), this bug must present in tsocks too (as it has /usr/lib/tsocks.so). -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
Hello, On Wed, 29 Jun 2011 23:39:31 +0200 Jakub Wilk wrote: > * Andrew O. Shadoura , 2011-06-30, 00:30: > >> 5. Lintian issues (lintian -iI --pedantic): > >>W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1 > >>W: tnat64: non-dev-pkg-with-shlib-symlink > >> usr/lib/libtnat64.so.0.1 usr/lib/libtnat64.so > >>I: tnat64: no-symbols-control-file usr/lib/libtnat64.so.0.1 > >Isn't really relevant, as this is a LD_PRELOAD-able library. > Then there's no reason to install the library into /usr/lib. Install > it to a private directory instead. And you don't need any symlinks > either. Agree. In that case this is also relevant to tsocks package (Cc'ed). -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: tnat64 -- IPv4 to NAT64 redirector
Hello, On Wed, 29 Jun 2011 16:11:56 -0500 Elías Alejandro wrote: > I am not a DD, so I can't sponsor your contribution. I'm sorry. But > here my fast review about your package: > 1. Bump Standards-Version to 3.9.2 Yes, I know. > 2. Maybe you can use debhelper version 8 under: debian/compat, > debian/control Possibly. > 3. debian/copyright: please use DEP-5 format[0] I don't think it's a good idea. > 4. Newest version on remote site is 0.03 I know, I'm the upstream. > 5. Lintian issues (lintian -iI --pedantic): >W: tnat64: package-name-doesnt-match-sonames libtnat64-0.1 >W: tnat64: non-dev-pkg-with-shlib-symlink usr/lib/libtnat64.so.0.1 > usr/lib/libtnat64.so I: tnat64: no-symbols-control-file > usr/lib/libtnat64.so.0.1 Isn't really relevant, as this is a LD_PRELOAD-able library. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: xxxterm
Hello, On Sat, 25 Jun 2011 22:38:16 +0100 Luis Henriques wrote: > > Upgrading zlib1g-dev from 1:1.2.3.3.dfsg-14 to > > 1:1.2.3.4.dfsg-3 helped, however. > First of all, thanks for testing the package (it actually the first > time I try to build a debian package). > Anyway, I'm not sure where to go from here. Is there something wrong > with my packaging? A missing dependency, maybe? Because I didn't had > problems compiling and installing it (I tried it on Debian testing > only). Well, I must say that the package builds successfully with pbuilder in the current unstable chroot, so maybe it's okay. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: xxxterm
Hello, On Sat, 25 Jun 2011 23:33:45 +0300 "Andrew O. Shadoura" wrote: > > I am looking for a sponsor for my package "xxxterm". > FTBFS here: Upgrading zlib1g-dev from 1:1.2.3.3.dfsg-14 to 1:1.2.3.4.dfsg-3 helped, however. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: xxxterm
Hello, On Sat, 25 Jun 2011 21:03:14 +0100 Luis Henriques wrote: > I am looking for a sponsor for my package "xxxterm". FTBFS here: $ dpkg-buildpackage -b dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2 dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): dpkg-buildpackage: source package xxxterm dpkg-buildpackage: source version 1.399-1 dpkg-buildpackage: source changed by Luis Henriques dpkg-buildpackage: host architecture i386 dpkg-source -i.hg --before-build xxxterm-1.399 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp /usr/bin/make -C linux/ clean make[1]: Entering directory `/tmp/xxxterm-1.399/linux' rm -f xxxterm *.o ../*.o Package zlib was not found in the pkg-config search path. Perhaps you should add the directory containing `zlib.pc' to the PKG_CONFIG_PATH environment variable Package 'zlib', required by 'GnuTLS', not found rm -f javascript.h make[1]: Leaving directory `/tmp/xxxterm-1.399/linux' dh_clean debian/rules build dh_testdir /usr/bin/make -C linux/ PREFIX=/usr make[1]: Entering directory `/tmp/xxxterm-1.399/linux' perl ../js-merge-helper.pl ../hinting.js ../input-focus.js > \ javascript.h Package zlib was not found in the pkg-config search path. Perhaps you should add the directory containing `zlib.pc' to the PKG_CONFIG_PATH environment variable Package 'zlib', required by 'GnuTLS', not found Package zlib was not found in the pkg-config search path. Perhaps you should add the directory containing `zlib.pc' to the PKG_CONFIG_PATH environment variable Package 'zlib', required by 'GnuTLS', not found cc -g -O2 -Wall -ggdb -D_GNU_SOURCE -I.-c -o ../marco.o ../marco.c Package zlib was not found in the pkg-config search path. Perhaps you should add the directory containing `zlib.pc' to the PKG_CONFIG_PATH environment variable Package 'zlib', required by 'GnuTLS', not found ../marco.c: In function ‘marco_message’: ../marco.c:31:2: warning: implicit declaration of function ‘arc4random_uniform’ [-Wimplicit-function-declaration] Package zlib was not found in the pkg-config search path. Perhaps you should add the directory containing `zlib.pc' to the PKG_CONFIG_PATH environment variable Package 'zlib', required by 'GnuTLS', not found cc -g -O2 -Wall -ggdb -D_GNU_SOURCE -I.-c -o ../xxxterm.o ../xxxterm.c Package zlib was not found in the pkg-config search path. Perhaps you should add the directory containing `zlib.pc' to the PKG_CONFIG_PATH environment variable Package 'zlib', required by 'GnuTLS', not found ../xxxterm.c:62:21: fatal error: gtk/gtk.h: No such file or directory compilation terminated. make[1]: *** [../xxxterm.o] Error 1 make[1]: Leaving directory `/tmp/xxxterm-1.399/linux' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- WBR, Andrew signature.asc Description: PGP signature
Re: ITA-RFS: cronolog - logfile rotator
Hello, On Mon, 13 Jun 2011 22:56:00 +0200 Maxime Chatelle wrote: > > Ah I see where that comes from. Those packages with tarball-in- > > tarball > > are rather rare these days. Changing the tarball without renaming it > > won't technically work however. You can still rename the tarball to > > something like cronolog_1.6.2+ds.orig.tar.gz and adapt the version > > in debian/changelog accordingly so you can move to the more standard > > layout. > Ho, yes, I understand. I will do this quickly. > Thank you very much Maxime, I think you may want to jump to the short form of the dh7, that will radically simplify your debian/rules file, and also it's the easiest way to switch to the modern layout and get rid of dbs. -- WBR, Andrew signature.asc Description: PGP signature
Re: DEP-5 format definition hell
Hello, On Mon, 30 May 2011 17:39:40 +0800 Thomas Goirand wrote: > > It's much harder to read it for humans than old good traditional > > debian/copyright. > Which format are you talking about? The "old good traditional > format" is in fact no format at all, with no rules, and we had > all sorts of formatting, which is why DEP5 was invented. Why not just make it a format, e.g. require that some things must presents here, some another must be there, but leave it relatively free-form? Personally I like using something like traditional d/c plus some DEP5 fields if necessary. For me, strict DEP5 is extremely hard to read unlike what was before it was invented. -- WBR, Andrew signature.asc Description: PGP signature
Re: DEP-5 format definition hell
Hello, On Mon, 30 May 2011 01:05:02 +0800 Thomas Goirand wrote: > P.S: What's blocking DEP5 from reaching the policy? > I think it's great the way it is right now already... Isn't it way too machine-oriented to be in the policy? It's much harder to read it for humans than old good traditional debian/copyright. -- WBR, Andrew signature.asc Description: PGP signature
Re: What to do about the situation with id3v2
Hello, On Wed, 27 Apr 2011 18:10:35 +0200 Stefan Ott wrote: > - Port id3v2 to libid3tag [5]. This is a different id3 tagging library > which supports v2.4 tags. I did some work in this direction but I > realized that this would require major modifications to id3v2 since > it's closely modeled around libid3. Also, some modifications to > libid3tag would be required to support all the current features of the > id3v2 program. My current estimate is that the work required for a > complete port of id3v2 would be close to rewriting it from scratch and > would result in a program that hardly shares any code with the current > id3v2 tool. You can also drop libid3 as it is now and write a wrapper around some better ID3 tagging library that has the same (or compatible) interface as libid3. Also, I'd merge id3 and id3v2 into one package, or even one binary, which would behave differently depending on its argv[0]. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: retext
Hello, On Sun, 15 May 2011 17:19:22 +0200 Jakub Wilk wrote: > >>rm -rf debian/icons > >You can use the debian/clean file. No need to add any overrides ;) > However, you can't remove directories via debian/clean, and I assume > that debian/icons is a directory. You can remove debian/icons/* and not remove the directory itself, as it can't be represented in the diff. Mmm, why does anyone want remove anything under debian/? -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: retext
Hello, On Sat, 14 May 2011 14:05:01 +0400 Dmitry Shachnev wrote: > override_dh_auto_clean: > dh_auto_clean > rm -rf debian/icons > rm -f retext > rm -f wpgen/wpgen > > Dmitry Shachnev You can use the debian/clean file. No need to add any overrides ;) -- WBR, Andrew signature.asc Description: PGP signature
RFS: mcs (updated package)
Hello, I am looking for a sponsor for my package "mcs". * Package name: mcs Version : 0.7.2-1 Upstream Author : William Pitcock * URL : http://www.atheme.org/projects/mcs * License : BSD Section : libs It builds these binary packages: libmcs-backend-gconf - GNOME GConf backend for libmcs libmcs-dev - development library and headers for libmcs1 libmcs-doc - documentation files for libmcs1 libmcs-utils - tools for the maintenance of the mcs system libmcs1- abstraction library to store configuration settings The upload would fix these bugs: 521010. I'd like to maintain this package as the current maintainer isn't doing any maintainance since 2008. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mcs - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mcs/mcs_0.7.2-1.dsc Also, it's kept under version control here: http://hg.debian.org/hg/collab-maint/mcs I would be glad if someone uploaded this package for me. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: gtk2-engines-equinox
Hello, On Tue, 3 May 2011 23:24:18 +0300 "Andrew O. Shadoura" wrote: > Why don't you just becoma a maintainer of it in Debian too? Become, even. Anyway, it'd be easier to keep the two packages in sync. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: gtk2-engines-equinox
Hello, On Tue, 3 May 2011 23:37:13 +0700 Maia Kozheva wrote: > Any progress on this? There is also a gtk2-engines-equinox package in > Ubuntu already (I packaged it independently before that); perhaps it > would be worth basing your package on that instead of reinventing the > wheel? Why don't you just becoma a maintainer of it in Debian too? -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: socketcan-utils
Hello, On Mon, 2 May 2011 17:07:01 +0200 Markus Becker wrote: [ I'm not a DD, but I'd like to share some my ideas about your RFS, however. ] > * Package name: socketcan > Version : 0.0.1+svn1240-1 > Upstream Author : Volkswagen Group Electronic Research > Wolfgang Grandegger > Vladislav Gribov, IXXAT Automation GmbH, > Is it an author, or multiple authors? Does it really matter where do they work? Also, don't really seem to belong here. > * URL : I'd prefer to specify http:// URL here, that is, the home page of the project. > * License : GPL-2 Is it just GPL-2, or GPL-2 and later? If latter, it must be GPL-2+ here. > Section : net You'd better put some short package description here (which probably goes into Description field of debian/control file). > It builds these binary packages: > socketcan-driver - Source for the socketcan kernel modules This maybe should include -source as the part of the package name (I'm not sure, however, but I'd do it that way). > socketcan-utils - Socket-CAN user space programs [...] > Please CC me, as I am not subscribed to the list. I do. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: mactelnet
Hello, On Mon, 2 May 2011 13:50:08 +0200 Håkon Nessjøen wrote: > mactelnet-client - Console tools for telneting and pinging via MAC > addresses > mactelnet-server - Telnet daemon for accepting connections > via MAC addresses My opinion is that the description is a bit messy. You don't 'accept connections via MAC addresses', basically. And you can't literally have 'UDP packets with a MAC-address as destination', as far as my knowledge of TCP/IP stack suggests. I would call these packages this way: mactelnet-client - Client for Microtic proprietary MAC Telnet protocol Ping, discovery and telnet tools for connecting to Mikrotik RouterOS devices, or other MAC Telnetd powered machines/devices. . This tool can communicate with servers using Microtik proprietary MAC Telnet protocol. You can connect to Linux machines that have installed mactelnet-server, or a Mikrotik RouterOS device. . Included are also MNDP discovery application, and macping to ping via the mactelnet protocol. . These tools have nothing to do with Telnet protocol specified by RFC 854 and 855. mactelnet-server - Server for Microtik proprietary MAC Telnet protocol The remote access server that uses Mikrotik proprietary MAC Telnet protocol. This enables to users to access the host using MAC Telnet protocol. . This package has nothing to do with Telnet protocol specified by RFC 854 and 855. -- WBR, Andrew signature.asc Description: PGP signature
RFS: tnat64 -- IPv4 to NAT64 redirector
Hello, I am looking for a sponsor for my package 'tnat64'. * Package name: tnat64 Version : 0.02-1 Upstream Author : Andrew O. Shadoura * URL : https://bitbucket.org/andrew_shadoura/tnat64/ * License : GPL-2+ Programming Lang: C Description : IPv4 to NAT64 redirector It builds these binary packages: tnat64 - IPv4 to NAT64 redirector The upload would fix these bugs: 624490 I would like to have this program in Debian because too many programs support IPv6 poorly or do not support at all, and not always it's easy to add the support or fix one which is broken, so this software can help users in situations when the system is IPv6-only, and some application requires IPv4 to work properly. TNAT64 is derived from tsocks, another TCP traffic interceptor written by Shaun Clowes in 2000. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tnat64 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tnat64/tnat64_0.02-1.dsc Also, the package can be found on Alioth, where its DVCS repository resides: http://hg.debian.org/hg/collab-maint/tnat64/ I would be glad if someone uploaded this package for me. Thanks in advance. -- WBR, Andrew signature.asc Description: PGP signature
Re: RFS: tayga -- userspace stateless NAT64
Hello, On Tue, 28 Dec 2010 08:58:32 +0200 "Andrew O. Shadoura" wrote: > I am looking for a sponsor for my package "twms". Sorry, of course I mean "tayga". But if you want to sponsor "twms" as well... you know :) -- WBR, Andrew signature.asc Description: PGP signature
RFS: tayga -- userspace stateless NAT64
Hello dear mentors, I am looking for a sponsor for my package "twms". * Package name: tayga Version : 0.9-1 Upstream Author : Nathan Lutchansky * URL : http://www.litech.org/tayga/ * License : GPL-2+ Section : net It builds these binary packages: tayga - userspace stateless NAT64 The package appears to be lintian clean. The upload would fix these bugs: 608136 I want this package in Debian, and I want to maintain it because I think a good out-of-kernel NAT64 implementation would be important during IPv6 transition period. The package can be found on alioth.debian.org: - Mercurial repository: http://hg.debian.org/hg/collab-maint/tayga/ mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tayga - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tayga/tayga_0.9-1.dsc I would be glad if someone uploaded this package for me. Thank you so much. -- WBR, Andrew signature.asc Description: PGP signature
RFS: twms -- tiny web map service
Hello. Dear mentors, I am looking for a sponsor for my package "twms". * Package name: twms Version : 0.01q-1 Upstream Author : Darafei Praliaskouski * URL : http://code.google.com/p/twms * License : GPL-3+ Section : science It builds these binary packages: twms - tiny web map service The package appears to be lintian clean. The upload would fix these bugs: 587522 I want this package in Debian, and I want to maintain it because many people (including me) use this quite often, as tWMS is useful enough. tWMS is most used as a caching proxy for WMS and TMS services. Most typical its usage is as follows: - Yahoo! aerial imagery is provided as a JavaScripted web service, not as WMS - JOSM, the Java OpenStreetMap editor, uses WMS - local tWMS instance can fetch imagery from Yahoo! and provide it as WMS The package is quite popular in the OpenStreetMap community. Also, I know author personally, so it's easy for me to contact upstream. The package can be found on alioth.debian.org: - Mercurial repository: http://hg.debian.org/hg/collab-maint/twms/ mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/twms - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/twms/twms_0.01q-1.dsc I would be glad if someone uploaded this package for me. Thank you very much. -- WBR, Andrew signature.asc Description: This is a digitally signed message part.
RFS: twms -- tiny web map service
Hello. Dear mentors, I am looking for a sponsor for my package "twms". * Package name: twms Version : 0.01q-1 Upstream Author : Darafei Praliaskouski * URL : http://code.google.com/p/twms * License : GPL-3+ Section : science It builds these binary packages: twms - tiny WMS service The package appears to be lintian clean. The upload would fix these bugs: 587522 I want this package in Debian, and I want to maintain it because many people (including me) use this quite often, as tWMS is useful enough. Also, I know author personally, so it's easy for me to contact upstream. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/twms - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/twms/twms_0.01q-1.dsc I would be glad if someone uploaded this package for me. Thank you very much. -- WBR, Andrew signature.asc Description: This is a digitally signed message part.
Re: RFS: tclxml
Hello.
On Tuesday 10 November 2009 18:36:16 Sven Hoexter wrote:
> Ok a few short remarks after a first look:
> * There are a lot of commented out lines in debian/rules - need them or
> delete them. ;)
Ok, removed most of them.
> * Is there a reason to build-dep on tcl 8.4? Otherwise build-dep on the
> tcl-dev package.
Fixed.
> * One should try if you can utilize the 'tcltk-depends' helper script to
> get your depends from this tool and the ${tclsh:Depends} variable.
Fixed, but it worked, hmm, a little bit strange: it added a dependency on tcl,
but haven't added a dependency on tcllib. The first is not necessary when the
second present. But I left {$tcl:Depends} in place and just added tcllib
manually. Not sure it's the best way, though.
> * Note in debian/copyright that you're now maintaining the package.
Added a line "Current maintainer: ..."
> There is a pkg-tcltk-devel mailinglist on lists.alioth.org,
> it's worth posting RFS there too so that people interested in Tcl related
> packages see them.
Ok, I'm sending RFS there too.
--
WBR, Andrew
signature.asc
Description: This is a digitally signed message part.
RFS: tclxml
Hello. The previous maintainer on tclxml package orphaned it, while package has a bug rendering it completely unusable, and there's a new upstream version available with that bug fixed. I'd like to take over maintainance, and I need a sponsor for that. Package name: tclxml Version: 3.2-1 Homepage: http://tclxml.sourceforge.net/ Author: Steve Ball License: BSD-style Description: Tcl library for XML parsing TclXML provides event-based parsing of XML documents. The application may register callback scripts for certain document features, and when the parser encounters those features while parsing the document the callback is evaluated. The package is lintian-clean, even with --pedantic. The upload would fix these bugs: 519315, 540507 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tclxml - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tclxml/tclxml_3.2-1.dsc Thank you. -- WBR, Andrew signature.asc Description: This is a digitally signed message part.
RFS: libnatspec (re-post)
Dear mentors, I am looking for a sponsor for my package "libnatspec". * Package name: libnatspec Version : 0.2.5-1 Upstream Authors: Vitaly Lipatov , Pavel Vainerman * URL : http://natspec.sourceforge.net/ * License : LGPL2.1 Section : libs It builds these binary packages: libnatspec-dev - a library for national and language-specific issues (development) libnatspec-examples - a library for national and language-specific issues (examples) libnatspec0 - a library for national and language-specific issues The package appears to be lintian clean, even with --pedantic. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libnatspec - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libnatspec/libnatspec_0.2.5-1.dsc I would be glad if someone uploaded this package for me. Thank you. -- WBR, Andrew signature.asc Description: This is a digitally signed message part.
RFS: libnatspec
Dear mentors, I am looking for a sponsor for my package "libnatspec". * Package name: libnatspec Version : 0.2.5-1 Upstream Authors: Vitaly Lipatov , Pavel Vainerman * URL : http://natspec.sourceforge.net/ * License : LGPL2.1 Section : libs It builds these binary packages: libnatspec-dev - a library for national and language-specific issues (development) libnatspec-examples - a library for national and language-specific issues (examples) libnatspec0 - a library for national and language-specific issues The package appears to be lintian clean, even with --pedantic. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libnatspec - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libnatspec/libnatspec_0.2.5-1.dsc I would be glad if someone uploaded this package for me. Thank you. -- WBR, Andrew signature.asc Description: This is a digitally signed message part.
RFS: gdigi --- utility to control DigiTech effect pedals
Dear mentors, I am looking for a sponsor for my package "gdigi". * Package name: gdigi Version : 0.1.8.hg-1 Upstream Author : Tomasz Moń * URL : http://desowin.org/gdigi * License : GPLv3 Section : sound It builds these binary packages: gdigi - utility to control DigiTech effect pedals The package appears to be lintian clean, even with --pedantic. This version is updated package, with some bugs fixed and sources updated. The upload would fix these bugs: 524202 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gdigi - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gdigi/gdigi_0.1.8.hg-1.dsc I would be glad if someone uploaded this package for me. -- WBR, Andrew signature.asc Description: This is a digitally signed message part.
RFS: gdigi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package "gdigi". * Package name: gdigi Version : 0.1.8~hg-1 Upstream Author : Tomasz Moń * URL : http://desowin.org/gdigi * License : GPLv3 Section : sound It builds these binary packages: gdigi - utility to control DigiTech effect pedals The package appears to be lintian clean. The upload would fix these bugs: 524202 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/g/gdigi - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/g/gdigi/gdigi_0.1.8~hg-1.dsc I would be glad if someone uploaded this package for me. Kind regards Andrew O. Shadoura -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp95NoACgkQ/mQMD2bMZ2v6WgCgmwcym+c0Y0teUchpMZ62/SVM KpEAoJHqWbJ0hTE32LsfJQpiv5vSTPR7 =3VPP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
