Re: new pkg: libcrypt-simple-per

[tony mancill]

Just to make sure we're all talking about the same thing, Sandro, are
you referring to this:

http://www.tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/

If so, I think you should have read the introduction more carefully,
where the author states:

"The intended use of such a newly created archive is to install it only
on your own box, not to get them into the official Debian distribution.
To follow the 'official' process, please study the Debian New
Maintainers' Guide."

I bring this up on the list not to embarass you, but because
occassionally there is some confusion on this issue.  I have been
involved with several sponsorees who proposed binary-only packages.  In
general, this concept no longer exists within Debian proper.  (I suppose
there are exception cases, but I can't think of one at the moment.)

In this case, the .pm is the source for Crypt::Simple, so you will most
likely be creating an "Arch: all" package.  But as Brendan states, what
needs to be uploaded into the archive are the .dsc, .diff.gz, and
.orig.tar.gz files, not just the .deb.

[BTW, I pulled debian-perl out of the cc: list since it seemed woefully
OT, and cc'd Brendan directly.]

Sandro Tosi wrote:
>>By source package, Russ was referring to the following files:
>>
>>libcrypt-simple-perl_0.06-1.dsc
>>libcrypt-simple-perl_0.06-1.diff.gz
>>libcrypt-simple-perl_0.06.orig.tar.gz
> 
> 
> I think it's a binary package: I take the .pm file from CPAN, and
> taking other lib as model, I've created a pianry package. I follow
> Debian Binary Package Building HOWTO as guide, but no source code.
> 
> I hope to be clear when I talk: this is my first package, and a binary one...
> 
> Thanks for you attention
> 
> --
> Sandro Tosi (aka Morpheus, matrixhasu)
> My (little) site: http://matrixhasu.altervista.org/
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: festvox-suopuhe-{mv,lj}: Finnish speakers for Festival

[tony mancill]

Sponsored.  Thanks Niko.
tony

Niko Tyni wrote:
> Hi,
> 
> I'm reposting this since I didn't get any comments last time (a month
> ago).  These are quite simple packages. Please consider sponsoring
> them.
> 
> Name: festvox-suopuhe-lj
> License: LGPL
> ITP: #341964
> Description: Finnish female speaker for Festival
>  This is a Finnish female speaker for the Festival speech synthesis
>  system. It was developed as part of the Suopuhe project at
>  the universities of Helsinki and Joensuu.
>   
> Name: festvox-suopuhe-mv
> License: LGPL
> ITP: #301066
> Description: Finnish male speaker for festival
>  This is a Finnish male speaker for the Festival speech synthesis
>  system. It was developed as part of the Suopuhe project at
>  the universities of Helsinki and Joensuu.
> 
> Packages can be found at 
> 
> http://mentors.debian.net/debian/pool/main/f/festvox-suopuhe-lj/
> http://mentors.debian.net/debian/pool/main/f/festvox-suopuhe-mv/
> 
> Any comments are welcome.
> 
> Cheers,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: libcrypt-simple-perl

[tony mancill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sponsored and uploaded to the archive.

Thanks,
tony

Sandro Tosi wrote:
> Hi all,
> I'm here again in search for a sponsor for libcrypt-simple-perl .
> Since the first request I've corrected some warning at build-time,
> changed dependences in debian/control and added watch file.
> 
> Files are available at this links:
> 
> http://matrixhasu.altervista.org/debian/libcrypt-simple-perl_0.06-1_all.deb
> http://matrixhasu.altervista.org/debian/libcrypt-simple-perl_0.06-1.diff.gz
> http://matrixhasu.altervista.org/debian/libcrypt-simple-perl_0.06-1.dsc
> http://matrixhasu.altervista.org/debian/libcrypt-simple-perl_0.06-1_i386.build
> http://matrixhasu.altervista.org/debian/libcrypt-simple-perl_0.06-1_i386.changes
> http://matrixhasu.altervista.org/debian/libcrypt-simple-perl_0.06.orig.tar.gz
> 
> or in repository:
> 
> deb http://matrixhasu.altervista.org/debian/ ./
> deb-src http://matrixhasu.altervista.org/debian/ ./
> 
> Here is a description:
> 
> Description: Perl library to encrypt stuff simply
>  Maybe you have  a web application and you need  to store some session
>  data at the  client side (in a cookie or hidden  form fields) but you
>  don't want the user to be able  to mess with the data. Maybe you want
>  to save  secret information  to a text  file.  Maybe you  have better
>  ideas of what to do with encrypted stuff!
>  .
>  This little module  will convert all your data  into nice base64 text
>  that you can save in a text file, send in an email, store in a cookie
>  or web page, or bounce around the Net. The data you encrypt can be as
>  simple or as complicated as you like.
>  .
>  This library is Crypt::Simple .
>  .
>   Homepage: http://search.cpan.org/~kasei/Crypt-Simple-0.06/
> 
> Could someone check if it's packaged correctly, and perhaps, upload it
> into debian?
> 
> Many Thanks in Advance
> 
> --
> Sandro Tosi (aka Morpheus, matrixhasu)
> My (little) site: http://matrixhasu.altervista.org/
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDypvqpdwBkPlyvgMRAhc/AJ9wt6bLr3Pk0KDOYUUR3rZCIXgpewCfV0Fj
x+DFYFVtcHgAtwgsrXq6I5g=
=dLNG
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: distributed-net

[tony mancill]

I'll sponsor this.

Cheers,
tony

On Wed, Jun 21, 2006 at 01:54:01PM -0400, James Stark wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "distributed-net".
> 
> * Package name: distributed-net
>   Version : 2.9012.497-1
>   Upstream Author : distributed.net
> * URL : http://www.distributed.net/
> * License : Proprietary (non-free)
>   Section : non-free/misc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: changelog of debian policy?

[tony mancill]

Thijs Kinkhorst wrote:
> Hello Harri,
> 
>> Is there a changelog of the Debian policy online?
>> Actually I would have expected a pointer on
>> http://www.debian.org/doc/debian-policy/, but maybe
>> I am too blind to see.
> 
> That depends on what information you need. If you're refering to the
> packaging of the policy, that URL's have passed by now. But what I guess
> you mean is the changes between policy versions, i.e. what you need to
> change to upgrade a package's standards-version. That information is
> in /usr/share/doc/debian-policy/upgrading-checklist.txt.gz. I don't
> think that's available online though.

Which is somewhat ironic, given that upgrading-checklist starts out as
upgrading-checklist.html in the debian-policy source package, and is then
stripped of tags to be distributed as a .txt file.

It might be nice to distribute it as html and/or fix-up the reference in
section 1.2 to point this file.  Perhaps the checklist could be referenced
as an appendix or the like so that the  tag could be used, and then
dwww could easily find it as well.  However, I'm not sure whether this is
wishlist bug-worthy or not.

tony


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: ace-of-penguins -- Solitaire-games with penguin-look

[tony mancill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Uploaded.
tony

Jari Aalto+mail.linux wrote:
> * Sat 2006-07-01 jari.aalto AT cante.net (Jari Aalto+mail.linux)
>> I'm looking for sponsor for followin package. Details below.
>>
>>   ITA: ace-of-penguins -- Solitaire-games with penguin-look
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFEqB9ypdwBkPlyvgMRAlfrAJ4wLKE4098wflo5zp+2bHTWe2EnvgCY/HfY
C6WiY+BRgr9S5tDu9mM/fQ==
=UGOJ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: python-htmlgen -- library for the generation of HTML

[tony mancill]

Kevin Coyner wrote:
> I am looking for a sponsor for the package 'python-htmlgen'.  This is a great
> little Python module that generates html pages on the fly.

Sponsored.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: libnet-ping-external-perl (updated package)

[tony mancill]

Hello Eugene,

I'm looking at your package now and agree to sponsor it.  It appears that
you've erased the changelog entry for the NMU of 0.11-0.1 which closed a
couple of those bugs.  Instead of removing that entry, I suggest that you
leave it intact, and then request that the sponsor build with the
"-v0.11-0.1" option so that the prior changelog entry is parsed.

Also, just curious here, was there a specific reason for dropping the
dependency on ping in debian/control?

Cheers,
tony

Eugene Krivdyuk wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 0.11-1
> of package "libnet-ping-external-perl".
> 
> It builds these binary packages:
> libnet-ping-external-perl - Provide an interface to the system ping command
> 
> The package is lintian clean.
> 
> The upload would fix these bugs: 209890, 329636, 358802, 359465
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/l/libnet-ping-external-perl
> - Source repository: deb-src http://mentors.debian.net/debian unstable main 
> contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/l/libnet-ping-external-perl/libnet-ping-external-perl_0.11-1.dsc
> 
> I would be glad if someone uploaded this package for me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: xsysinfo

[tony mancill]

Sandro Tosi wrote:
> I am looking for a sponsor for the new version 1.7-4
> of my package "xsysinfo".

uploaded


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: mysql-navigator

[tony mancill]

Sandro Tosi wrote:
> I am looking for a sponsor for the new version 1.4.2-8
> of my package "mysql-navigator".

Uploaded.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: tstat

[tony mancill]

Sandro Tosi wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "tstat".
> 
> * Package name: tstat
>  Version : 1.01-1
>  Upstream Author : Dario Rossi <[EMAIL PROTECTED]>, Marco Mellia
> <[EMAIL PROTECTED]>
> * URL : http://tstat.tlc.polito.it/
> * License : GPL2
>  Section : net
> 
> It builds these binary packages:
> tstat  - TCP STatistic and Analysis Tool
> 
> The package is lintian clean.
> 
> The upload would fix these bugs: 323913
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/t/tstat
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget http://mentors.debian.net/debian/pool/main/t/tstat/tstat_1.01-1.dsc
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards
> Sandro Tosi
> 


Hi Sandro,

IANAL (I am not a lawyer), but I wonder if we shouldn't ask debian-legal
about these license clauses for erf.c:

  3. All advertising materials mentioning features or use of this software
 must display the following acknowledgement:
   This product includes software developed by Endace Technology Ltd.,
   Hamilton, New Zealand, and its contributors.
  4. Neither the name of Endace Technology nor the names of its contributors
 may be used to endorse or promote products derived from this software
 without specific prior written permission.

It seems to be that you can't talk about the features of the software
without using the name of Endace Technology, but that you can't use the name
of Endace without prior written consent.  I guess it all stems from how you
define "All advertising materials," which taken broadly could contain the
description field in the debian/control file, along with how you interpret
"endorse or promote."

Comments from others who have more experience with this?
Thanks,
tony



signature.asc
Description: OpenPGP digital signature

Re: RFS: jzip -- Text mode interpreter for Z-Code adventures

[tony mancill]

Niko Tyni wrote:
> http://mentors.debian.net/debian/pool/main/j/jzip
> 
> I would be glad if someone uploaded this package for me.

Sponsored.
tony



signature.asc
Description: OpenPGP digital signature

Re: Please tell if you found a sponsor

[tony mancill]

Bart Martens wrote:
> On Sat, 2006-08-26 at 18:59 +0200, Christoph Haas wrote:
>> Dear package maintainers...
>>
>> a sponsor of Debian packages today sent an email to the mentors.debian.net 
>> support email address and I would like to forward the suggestion here. 
>> Please tell us if you found a sponsor. I often found myself downloading 
>> and testing packages from mentors.debian.net and found out too late that 
>> someone else already sponsored the upload.
> 
> I suggest that:
> 
> - the maintainer logs on the ITA/ITP that he/she's has prepared a
> package for review and upload, and is looking for a sponsor,
> - the sponsor logs on the ITA/ITP that he/she's reviewing the package.

I like this proposal.  In addition, perhaps it would be possible to use tags
for these states, so that it would be fairly simple to query the BTS for
packages needing a sponsor, etc.

tony




signature.asc
Description: OpenPGP digital signature

Re: RFS: wmmisc (updated package)

[tony mancill]

Sandro Tosi wrote:
> I am looking for a sponsor for the new version 1.1-2
> of my package "wmmisc".

Uploaded.
Thanks,
tony



signature.asc
Description: OpenPGP digital signature

Re: RFS: wmfishtime (updated package)

[tony mancill]

Sandro Tosi wrote:
> I am looking for a sponsor for the new version 1:1.24-5
> of my package "wmfishtime".

Sponsored.



signature.asc
Description: OpenPGP digital signature

Re: RFS: wmtz (updated package)

[tony mancill]

Sandro Tosi wrote:
> I am looking for a sponsor for the new version 0.7-7
> of my package "wmtz".

sponsored



signature.asc
Description: OpenPGP digital signature

Re: RFS: wmdonkeymon (updated package)

[tony mancill]

Sandro Tosi wrote:

> I am looking for a sponsor for the new version 0.91-3
> of my package "wmdonkeymon".

sponsored



signature.asc
Description: OpenPGP digital signature

Re: RFS: wmspaceweather (updated package)

[tony mancill]

Sandro Tosi wrote:
> I am looking for a sponsor for the new version 1.04-18
> of my package "wmspaceweather".

sponsored



signature.asc
Description: OpenPGP digital signature

Re: Subject: RFS: c++-annotations

[tony mancill]

Hello George,

I'm looking at this package.  Here are a couple of comments so far:

debian/control:

* The package Architecture should be "all" instead of "any" - this will
prevent the (identical) package from being built for every Debian architecture.

* You can remove ${shlibs:Depends} from Depends:

* What is the reason for declaring a dependency on lynx | www-browser?
There are other document formats in the package (therefore, it is useful
without having a browser installed).

* You may want to add  Homepage: to the send of the Description:

* You Build-Depend on gs | gs-gpl, but gs depends on gs-gpl, so I think you
can safely choose one or the other.

Cheers,
tony

George Danchev wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "c++-annotations".
> 
> * Package name: c++-annotations
>   Version : 6.4.0f-1
>   Upstream Author : Frank B. Brokken
> * URL : ftp://ftp.rug.nl/contrib/frank/documents/annotations/
> * License : GPL
>   Section : devel
> 
> It builds these binary packages:
> c++-annotations - Extensive tutorial and documentation about C++
> 
> The package is lintian clean.
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/c/c++-annotations
> - Source repository: deb-src http://mentors.debian.net/debian unstable main 
> contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/c/c++-annotations/c++-annotations_6.4.0f-1.dsc
> 
> I would be glad if someone uploaded this package for me.
> 
> Maintainer note: please build with -v option of dpkg-buildpackage since the 
> previous changelog entry closes the ITP bug #386060. Thanks.
> 
> Kind regards
>  George Danchev




signature.asc
Description: OpenPGP digital signature

Re: my projects for debian ?

[tony mancill]

[EMAIL PROTECTED] wrote:

> - pag -
> The second program is pag - a password generator written in c. It can 
> generate numbers,
> signs or both together, so 3 options. You can set the length of the password. 
> You can
> generate just on password to stdout or a complete password list in a *.txt 
> file. You can
> set the number of passwords which the program have to write in the *.txt when 
> you
> use this option. It is very simple and fast and because of this it compiles 
> without problems.
> Here is the mirror to this project:
> 
> www.sourceforge.net/projects/pagen

Hello Acid0,

How does pag compare to pwgen (http://sourceforge.net/projects/pwgen/)?

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Re: question about reporting bugs on my own package

[tony mancill]

Satoru Takeuchi wrote:
> Hi mentors,
> 
> I have a problem with bug reporting. I maintain a package and found some
> bugs with it. Is it correct way to report bugs on my own package, or should
> I just fix these bugs and describe about it on changelog? I briefly read
> Debian Developer's Reference, but I couldn't find the description about
> my question.
> 
> Thanks,
> Satoru

This is up to you; I've done it both ways in the past.  If the bug is
affects the usability of the package, and it could take a while to fix it,
go ahead and report the bug to the BTS.  That will let other users know that
the maintainer is aware of the issue.  You may even be able to describe a
workaround in the bug report.  If the bug is trivial or purely aesthetic
then the bug report would be less useful.  However, it doesn't hurt to file
a bug report, even if the issue is very minor, so if you're in doubt, I
would suggest filing one.

Hope that helps,
tony



signature.asc
Description: OpenPGP digital signature

Re: RFS: rpl -- intelligent recursive search/replace utility

[tony mancill]

Sponsored (but not yet uploaded).

Kevin Coyner wrote:
> I am looking for a sponsor for the new version 1.5.4
> of my package "rpl".  The package was recently orphaned.



signature.asc
Description: OpenPGP digital signature

Re: RFS: logwatch (temporary sponsor)

[tony mancill]

Sponsored.
Cheers,
tony

Willi Mann wrote:
> Hi!
> 
> I'm searching for a temporary sponsor for logwatch 7.3.1-2. It's
> available from
> 
> http://pkg-logwatch.alioth.debian.org/apt/pool/main/l/logwatch/



signature.asc
Description: OpenPGP digital signature

Re: RFS: bbtime (updated package) [uploaded]

[tony mancill]

Kevin Coyner wrote:
> I am looking for a sponsor for the updated version 0.1.5-10
> of my package "bbtime".  It is lintian clean and builds fine in a
> pbuilder sid chroot.

uploaded to the archive

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Re: RFS: zim (updated package) [sponsored]

[tony mancill]

Emfox Zhou wrote:
> I am looking for a sponsor for the new version 0.16-1
> of my package "zim".

zim_0.16 has been uploaded.
Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Re: Subject: RFS: shc (updated package) [sponsored]

[tony mancill]

George Danchev wrote:
> I am looking for a sponsor for the new version 3.8.6-2
> of my package "shc".

Uploaded to the archive.
Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Re: RFS: moc - ncurses based console audio player [sponsored]

[tony mancill]

Sponsored.  By the way, I made one change to the package in
debian/changelog; I modified bug number "#36452" to be "#364524".

Regards,
tony

Elimar Riesebieter wrote:
> Hi all,
> 
> could one please upload the new vwrsion of moc?
> 
> moc (2.4.1-1) unstable; urgency=low
> 
>   * New upstream version.
>   * Fixed handling mixer errors. (closes: #36452)
>   * Updated watchfile to version 3
>   * Disabled 12_endianess1.patch, applied upstream.
>   * Reworked package structure to make it easier to play with automake, which
> changes the configure script. (closes: #393824)
> 
>  -- Elimar Riesebieter <[EMAIL PROTECTED]>  Sat, 21 Oct 2006 20:34:02 +0200
> 
> deb http://www.lxtec.de/debarchiv unstable main
> deb-src http://www.lxtec.de/debarchiv unstable main
> 
> The package is already in the pool, but I can't reach the sponsor Bartosz
> Fenski since over a week.
> 
> The binaries are build in an chroot pbuilder environment and are lintian 
> clean.




signature.asc
Description: OpenPGP digital signature

Re: RFS: wormux (updated package) [sponsored]

[tony mancill]

This package is being uploaded to experimental now.  (It takes a while for
me to push 65MB.)

Jean Parpaillon wrote:
> Dear mentors,
> 
> I've built new packages of Wormux. This is an alpha version of Wormux
> upstream code so it should go to experimental distro. Is it possible ?
> 
> It builds these binary packages:
> wormux - A funny fight game on 2D maps
> wormux-data - Data files for the game wormux
> 
> The upload would fix these bugs: 383990
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/w/wormux
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/w/wormux/wormux_0.8alpha1-1.dsc
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards
> Jean Parpaillon
> 




signature.asc
Description: OpenPGP digital signature

Re: RFS: radvd (updated package) [sponsored]

[tony mancill]

Uploaded to the archive.  Thanks for updating the package (and for
removing all of the {arch} stuff that was in the .diff.gz of the 0.8 version).

Cheers,
tony

Andreas Rottmann wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 1:1.0-1
> of my package "radvd".
> 
> It builds these binary packages:
> radvd  - Router Advertisement Daemon
> 
> The package is lintian clean.
> 
> The upload would fix these bugs: 396441
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/r/radvd
> - Source repository: deb-src http://mentors.debian.net/debian unstable main 
> contrib non-free
> - dget http://mentors.debian.net/debian/pool/main/r/radvd/radvd_1:1.0-1.dsc
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards
>  Andreas Rottmann




signature.asc
Description: OpenPGP digital signature

Re: RFS: zim (updated package) [sponsored]

[tony mancill]

This has been uploaded to the archive.

Cheers,
tony

Emfox Zhou wrote:

> I am looking for a sponsor for the new version 0.17-1
> of my package "zim".



signature.asc
Description: OpenPGP digital signature

Re: RFH: Need sponsor for debmirror [UPLOADED]

[tony mancill]

This has been uploaded to the archive.

Cheers,
tony

Goswin von Brederlow wrote:
> Hi,
> 
> I'm looking for a sponsor for debmirror 20070123. Preferably someone
> using it but anyone will do.
> 
> MfG
> Goswin
> 
> http://mrvn.homeip.net/debmirror/
> 
> Format: 1.7
> Date: Tue, 23 Jan 2007 14:53:14 +0100
> Source: debmirror
> Binary: debmirror
> Architecture: source all
> Version: 20070123
> Distribution: unstable
> Urgency: low
> Maintainer: Goswin von Brederlow <[EMAIL PROTECTED]>
> Changed-By: Goswin von Brederlow <[EMAIL PROTECTED]>
> Description: 
>  debmirror  - Debian partial mirror script, with ftp and package pool support
> Closes: 386697 386707 397936 399058 399834 400054 400526 401245
> Changes: 
>  debmirror (20070123) unstable; urgency=low
>  .
>* Add dependency for libdigest-sha1-perl (ACK NMU) (Closes: #386707)
>* Change manpage entry for --pdiff (Closes: #386697)
>* Fix Release.gpg check to use gpgv (Closes: #400526)
>* Fix use of uninitialized value in addition
>* Count errors in pdiff files as small errors (Closes: #400054)
>* Cleanup tempfiles (Closes: 399834)
>* Fix manpage permissions with patch by (Closes: #399058)
>  "Dmitry E. Oboukhov" <[EMAIL PROTECTED]>
>* Skip pdiff files if patch binary is missing (Closes: #401245)
>* Skip pdiff files if ed binary is missing and recommend it (Closes: 
> #397936)
> Files: 
>  fc77201ee20d30a72e2be043a3cd12e5 494 net extra debmirror_20070123.dsc
>  96efc420aaa8bba9fce6c9d99797ef6e 23174 net extra debmirror_20070123.tar.gz
>  5bf6ba7d4f56356e4c82895c3a7ef95c 30748 net extra debmirror_20070123_all.deb
> 



signature.asc
Description: OpenPGP digital signature

Re: Better to run multiple configure/make cycles or use separate sources?

[tony mancill]

Another thing to realize is that the number of binary .debs generated from a
source package is dictated by the contents of debian/control.  Each
"Package:" stanza indicates another binary .deb to be generated by the package.

(Sorry if that's already been mentioned.  I didn't see it, and couldn't tell
if that was part of what was puzzling Roman.)

Cheers,
tony

James Westby wrote:
> On (19/02/07 19:54), Roman Müllenschläder wrote:
>> Let's ask different:
>> I'm able to do differnet compiles and install (using 'make install') the 
>> whole 
>> program (including pos, themes, docs, binaries, etc.) into subdirs beneath 
>> debian ..
>> debian/compiled-version1
>> debian/compiled-version2
>> debian/compiled-version3
>>
>> What I want now is to put only the binaries in the different flavour-deb's 
>> and 
>> all the common rest in a common.deb.
>> How would I do that? Just not use upstream's 'make install' and use 
>> dh_install 
>> together with flavour.install files in debian?
>> Thus would mean, I have to re-do all what is done in upstream's Makefile by 
>> hand in 'rules' !?
>>
>> So ... I do have 3 subdirs under debian containing 3 complete installs with 
>> different flavours.
>> How do I part them up into 3 flavour.debs and 1 common.deb?
>>
> 
> You don't need to recreate everything in the rules, you can use the
> upstream Makefile.
> 
> The easiest approach would seem to be to have an install target for
> each version that looks like
> 
>   install-flavour1-stamp: build-flavour1-stamp
>  $(MAKE) install DESTDIR="$(CURDIR)/debian/tmp/flavour1"
> 
> where the build target depends on the configure target that passes the
> correct options. The configure target should also depend on a semi-clean
> target that removes the built files but not debian/tmp. You can add a
> proper clean rule as normal.
> 
> Then you can have package.flavour1.install files that have
> 
>   debian/tmp/flavour1/file
> 
> which should grab the correct files for each flavour.
> 
> Then make the binary target depend on all the install targets, you may
> have some trouble getting binary-arch/indep separation though.
> 
> You can add as much Makefile madness to this as you like to generate the
> targets that you need, but the basic idea should work.
> 
> Note that I have never packaged a package like this, so you might hit a
> snag with this method, if so I suggest you look at other examples.
> 
> Thanks,
> 
> James
> 




signature.asc
Description: OpenPGP digital signature

Re: RFS: ripit

[tony mancill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Elimar Riesebieter wrote:
> On Sun, 17 Jun 2007 the mental interface of
> Elimar Riesebieter told:
> 
>> Hi mentors,
> [...]
>> ripit (3.6.0-0) unstable; urgency=low
> 
> Fixed to 3.6.0-1.
> 
> Please notice, that I am looking for an uploader. This isn't a new
> package but a new _version_ ;)
> 
> Elimar

Hi Elimar,

I can take care of this upload for you.

Cheers,
tony

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGdtOwpdwBkPlyvgMRAhpbAJ9RAZcJ4fcjWMqEShLopA4B0kccKgCfcyos
wy7ZJPQbIc+1L2qCucjvNBM=
=3U6I
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: libj2ssh-java

[tony mancill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Koch wrote:
> On Thu, Aug 30, 2007 at 01:47:43PM +0530, Kumar Appaiah wrote:
>> (CC'ed to Debian Mentors).
>>
>> Dear Mentors,
>>
>> Myself and a friend have managed to package libj2ssh-java.
>>
>> http://mentors.debian.net/debian/pool/main/l/libj2ssh-java/libj2ssh-java_0.2.9-1.dsc



> Your package is very good. Thanks for your work. Just one nit. Please
> put the javadocs and examples into an extra -doc package. I think the
> size of them warrents an extra package. And please make the normal
> package suggest the -doc package.

Michael,

Can you provide any generic guidelines on how large the docs should be to
warrant a separate -doc package?  This comes up from time to time
sponsoring, and for new packages I've seen packages rejected because the
- -doc package was too small.

Thank you,
tony
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG4As4pdwBkPlyvgMRAsm/AJ9H+DoEdFWxFGPgc3wAS/JsA7DVmACeJZCT
hFxg1jC4WgkAHvkFAnreBcY=
=850o
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#690010: RFS: sweethome3d-furniture-editor/1.8-1 [ITP]

[tony mancill]

On 10/08/2012 04:25 PM, Gabriele Giacone wrote:
> Package: sponsorship-requests
> Severity: wishlist
> Control: block 689980 by -1
> 
> Dear mentors,
> 
>   I am looking for a sponsor for my package "sweethome3d-furniture-editor"

Hi Gabriele,

I am reviewing this package and will sponsor an upload once I have finished.

Thank you,
tony





signature.asc
Description: OpenPGP digital signature

Re: RFS: nedit (updated package)

[Tony Mancill]

Hi Paul,

I must have missed your previous email.  I'm a long-time nedit user, and
so am happy to see it continue to be supported.  Give me a little time
to get a few other things taken care of on my side and I'll review it
and prepare an upload.

Thank you,
Tony

On Wed, 2009-03-11 at 16:45 +0100, Paul Gevers wrote:
> Hi
> 
> It has been a month since my last mail. Although the files at mentors
> seem to attract reasonable traffic, I have not heard back from anybody.
> Would somebody be interested in commenting on my work (target
> experimental) on packaging a release candidate of nedit (lesstif2 based
> text editor) which I intend to adopt.
> 
> The package can still be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/n/nedit
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/n/nedit/nedit_5.6~cvs20081118-3.dsc
> 
> If somebody is willing to sponsor it, but wants the version number plain
> xxx-1 please let me know.
> 
> Paul
> 
> Paul Gevers wrote:
> >>> Laurent Guignard found a bug in my packaging (failed to build twice in a
> >>> row).
> >> Looks to me like the bug is still there; in binary-arch you:
> >>
> >> mv source/nc source/nedit-nc
> >>
> >> But in debian/rules clean you don't delete source/nedit-nc, which is
> >> problematic because make clean doesn't remove the renamed binary.
> > 
> > Fixed
> > 
> >> Incidentally, it would be trivially to fix the pedantic warning in lintian:
> >>
> >> P: nedit: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
> > 
> > Fixed, including two other pedantic warnings about not using "set -e" in
> > postinst and prerm.
> > 
> > The package can again be found on mentors.debian.net:
> > - URL: http://mentors.debian.net/debian/pool/main/n/nedit
> > - Source repository: deb-src http://mentors.debian.net/debian unstable
> > main contrib non-free
> > - dget
> > http://mentors.debian.net/debian/pool/main/n/nedit/nedit_5.6~cvs20081118-3.dsc
> > 
> > If somebody is willing to sponsor it, but wants the version number plain
> > xxx-1 please let me know.
> > 
> > Paul
> > 
> 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Building localy

[tony mancill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jaromír Mikeš wrote:
> Hello mentors,
> 
> Can somebody help me with this error please?
> 
> $ sudo dpkg-buildpackage -S
> is runnig fine...
> 
> $ sudo dpkg-buildpackage -nc
> giving me this error

Any reason you're using sudo instead of -ffakeroot?  Also, note that -S is a
source-only build, and so is not the same thing as -nc, which is going to
build the binary package.

Tony

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknIBMEACgkQpdwBkPlyvgNOCwCfdhX+rz9Wx6JQElisctCDbGb2
WfAAoICujxM49V8g/zPsGCa8BEX4tcqN
=4blK
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: prips (adopted and updated)

[Tony Mancill]

Uploaded.  Feel free to contact me directly for subsequent uploads of
this package.

Thank you,
Tony

On Fri, 2009-03-27 at 19:46 +0200, Peter Pentchev wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 0.9.5-1
> of my package "prips".  I've adopted the Debian package,
> and since upstream seems to be, well, moribund, I've also
> taken the liberty of adopting the upstream piece of software
> and releasing a new version.
> 
> It builds these binary packages:
> prips  - Print IP address on a given range
> 
> The package is lintian- and pbuilder-clean.
> 
> The upload would fix these bugs: 497429, 519379
> 
> The package can be found on mentors.debian.net:
> dget -x http://mentors.debian.net/debian/pool/main/p/prips/prips_0.9.5-1.dsc
> 
> Just for reference, here is the changelog of my 0.9.5-1 entry:
> 
> prips (0.9.5-1) unstable; urgency=low
> 
>   * New maintainer.  Closes: #519379
>   * Fix the date format of the 0.9.4-3 changelog entry.  Closes: #497429
>   * Move the debhelper compatibility version to debian/compat.
>   * Add a watch file.
>   * Add the Homepage, Vcs-Svn, and Vcs-Browser control fields.
>   * Convert the copyright file to the machine-parseable format and
> add some copyright notices for the Debian packaging.
>   * Bump the debhelper compatibility level to 7:
> - add ${misc:Depends} to the binary package
>   * Bump Standards-Version to 3.8.1:
> - the new version honors our CFLAGS, thus honoring DEB_BUILD_OPTIONS
>   * Use dh_install to install the prips binary.
>   * Minimize the rules file using debhelper 7's dh(1) utility.
>   * New upstream version - actually, I adopted the package:
> - remove all the Debian patches - some of them were integrated upstream,
>   and the cidr_lp64 one was overtaken by the uint32_t change
> - remove the manpage - integrated upstream, rewritten as mdoc(7)
>   and fleshed out a bit
> - remove README.Debian - the upstream has a manpage now :)
>   * Use build hardening by default, disabled by the "nohardening" option.
>   * Use the -Werror compiler flag if the "werror" option is present.
> 
>  -- Peter Pentchev   Fri, 27 Mar 2009 19:36:58 +0200
> 
> I would be glad if someone uploaded this package for me.
> 
> G'luck,
> Peter
> 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: hexer (adopted & updated package)

[Tony Mancill]

Uploaded.  You can contact me directly for future uploads of this
package. 

On Fri, 2009-04-03 at 15:24 +0300, Peter Pentchev wrote:
> On Fri, Apr 03, 2009 at 11:17:05AM +0800, Paul Wise wrote:
> > On Fri, Apr 3, 2009 at 10:50 AM, Peter Pentchev  wrote:
> > 
> > > - dget 
> > > http://mentors.debian.net/debian/pool/main/h/hexer/hexer_0.1.4c-3.dsc
> > 
> > I'm unable to sponsor at the moment, but I took a look at the diff.gz.
> > 
> > Please remove the lintian overrides, you should only override lintian
> > complaints when the lintian test is wrong and it isn't possible to fix
> > the test for your case, not when you just want to ignore it or the
> > test has a bug. In this case there isn't an upstream homepage or
> > changelog yet, which are both valid complaints that you intend to fix
> > by taking over upstream.
> 
> Good point.  Thanks!
> 
> > The rest of the diff.gz looks fine, I suggest someone else do a deeper
> > review and upload this package.
> 
> I've built and uploaded a new version of hexer-0.1.4c-3 to mentors.d.n
> at the same URL:
> http://mentors.debian.net/debian/pool/main/h/hexer/hexer_0.1.4c-3.dsc
> 
> The changes are:
> - removed the lintian overrides
> - reworded the last line in the changelog entry; 5:30am does not for
>   good grammar make!
> 
> Thanks to you and Michal both for taking a look!
> 
> G'luck,
> Peter
> 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: freeplane - A Java program to create and edit mind maps

[tony mancill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Eric,

I have sponsored the upload.  Please feel free to contact me directly for future
uploads of freeplane.

Regards,
tony

On 07/19/2010 01:15 AM, Eric Lavarde wrote:
> Hello,
> 
> I am looking for a sponsor for my package "freeplane".
> 
> * Package name: freeplane
>   Version : 1.1.1-1
>   Upstream Author : Dimitri Polivaev 
> * URL : http://freeplane.org/
> * License : GPLv2+
>   Section : editors
> 
> It builds these binary packages:
> freeplane  - A Java program to create and edit mind maps.
> libjortho-freeplane-java - A Java spell-checking library.
> 
> The package appears to be lintian & pbuilder clean.
> 
> The upload would fix these bugs: 566375
> 
> My motivation for maintaining this package is: Freeplane is the
> follow-up version of FreeMind and more actively developed, with already
> more features than FreeMind (and that's what I'm now using to write
> MindMaps).
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/f/freeplane
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/f/freeplane/freeplane_1.1.1-1.dsc
> 
> - and also present in Svn-Java
> svn+ssh://ewl-gu...@svn.debian.org/svn/pkg-java/trunk/freeplane
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards
>  Eric Lavarde
> 
> PS: due to holiday season, my answers might take more time than usual.
> Sorry for this, but I wanted to keep a chance to get Freeplane in squeeze.
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxFKz8ACgkQpdwBkPlyvgPo0wCdHiTcq70Y9lLTvBOKu3QA2kU+
0TwAn09ijnD1ccaN8A0MDtzcSO7B5voU
=Vf0F
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c452b3f.2030...@debian.org

Re: RFS: cpptasks (fwd to d-java@l.d.o)

[Tony Mancill]

Sponsored.

Cheers,
tony

On 07/23/2010 05:35 PM, Niels Thykier wrote:
> On 2010-07-24 00:29, Chris Baines wrote:
>> Dear mentors,
> 
>> I am looking for a sponsor for my package "cpptasks".
> 
>> * Package name: cpptasks
>>   Version : 1.0~b5-1
>>   Upstream Author : Unknown
>> * URL :
>> http://ant-contrib.sourceforge.net/cpptasks/index.html
>> * License : Apache (v2.0)
>>   Section : java
> 
>> It builds these binary packages:
>> ant-contrib-cpptasks - C/C++ compilation tasks for Ant.
> 
>> The package appears to be lintian clean.
> 
>> The upload would fix these bugs: 590045
> 
>> My motivation for maintaining this package is: that I needed this to
>> continue packaging the lejos-nxj package (ITP: 590049) and that its a
>> simple introduction in to packaging and maintaining.
> 
>> The package can be found on mentors.debian.net:
>> - URL: http://mentors.debian.net/debian/pool/main/c/cpptasks
>> - Source repository: deb-src http://mentors.debian.net/debian unstable
>> main contrib non-free
>> - dget
>> http://mentors.debian.net/debian/pool/main/c/cpptasks/cpptasks_1.0~b5-1.dsc
> 
>> I would be glad if someone uploaded this package for me.
> 
>> Kind regards
>>  Christopher Baines
> 
> 
> 
> 
> Hi
> 
> Just cross posting this to debian-j...@l.d.o as you are more likely to
> find a sponsor for a Java package on that list.
> 
> ~Niels
> 


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c4b0925.90...@mancill.com

Re: RFS: service-wrapper-java

[tony mancill]

On 08/06/2010 07:58 AM, Rémi Debay wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "service-wrapper-java".
> 
> * Package name : service-wrapper-java
> Version : 3.5.3-1
> Upstream Author : Tanuki Software Ltd
> * URL : http://wrapper.tanukisoftware.com/doc/
> * License : GPLv2
> Section : java
> 
> It builds these binary packages:
> service-wrapper-java - Jar daemon wrapper
> 
> The package appears to be lintian clean.
> The upload would fix these bugs: 591758

Hello Rémi,

I've taken a look at this package and have a few questions:

1)  The package isn't lintian clean from what I can see.  The
/usr/sbin/wrapper command doesn't include a manpage, which should be a
warning for any recent version of lintian.  There is also a warning
about the standards version; the current standards version is 3.9.1.
These are both minor and easily addressed.

2)  You are installing the JNI libraries in /usr/lib/service-wrapper/.
According to Java policy, you should be installing the C compiled bits
under /usr/lib/jni/.  Specifically see
http://www.debian.org/doc/packaging-manuals/java-policy/c43.html.  I
think ideally your packaging would produce (2) binary packages, one
arch: all package that contains the wrapper script and the JAR, and then
another arch: any package that contains the JNI libraries per platform.

3)  I was curious about setting -Dbits=32 in Debian rules.  Will this
work on all architectures, or does it imply a 32-bit JVM?

4)  You may also want to review the information about javahelper here:
http://wiki.debian.org/Java/Packaging

Regards,
tony



signature.asc
Description: OpenPGP digital signature

Re: RFS: service-wrapper-java [2nd try]

[tony mancill]

Hi Remi,

I'm still willing to sponsor the package and have looked at your 
changes - I've just been a little slow.  I'll upload this weekend.

Thank you,
tony

On Thu, Aug 19, 2010 at 01:46:19PM +0200, Rémi Debay wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "service-wrapper-java".
> * Package name : service-wrapper-java
> 
> Version : 3.5.3-2
> Upstream Author : Tanuki Software Ltd
> * URL : http://wrapper.tanukisoftware.com/doc/
> * License : GPLv2
> 
> Section : java
> 
> 
> It builds these binary packages:
> libservice-wrapper-java - Jar daemon wrapper java libraries
> libservice-wrapper-jni - Jar daemon wrapper JNI libraries
> 
> service-wrapper - Jar daemon wrapper
> 
> The package appears to be lintian clean.
> 
> My motivation for maintaining this package is:
> The package is a needed dependency for another RFP package I2P (bug :
> 
> #448638). As I am packaging the I2P router, I need this
> dependency to get onto the repositories. I got contact with the upstream
> Author and I will maintain the software with their help.
> 
> Please get a special attention to the name of the package, how I am
> 
> building it, and to the jni libraries binaries built by the package.
> 
> The package can be found on mentors.debian.net:
> 
> - URL: http://mentors.debian.net/debian/pool/main/s/service-wrapper-java
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> 
> - dget 
> http://mentors.debian.net/debian/pool/main/s/service-wrapper-java/service-wrapper-java_3.5.3-2.dsc
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards
> 
> 
> Rémi Debay,


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100819135250.ga13...@dorf.mancill.com

Re: RFS: service-wrapper-java [2nd try]

[tony mancill]

Hello Remi,

I have uploaded the package to experimental archive instead of unstable,
just for the duration of the freeze.  Please feel free to contact me
directly for future uploads of this package, and thank you for your
contribution to Debian.

Cheers,
tony

On 08/19/2010 04:46 AM, Rémi Debay wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "service-wrapper-java".
> * Package name : service-wrapper-java
> 
> 
> Version : 3.5.3-2
> Upstream Author : Tanuki Software Ltd
> * URL : http://wrapper.tanukisoftware.com/doc/ 
> 
> * License : GPLv2
> 
> 
> Section : java
> 
> 
> It builds these binary packages:
> libservice-wrapper-java - Jar daemon wrapper java libraries
> libservice-wrapper-jni - Jar daemon wrapper JNI libraries
> 
> 
> service-wrapper - Jar daemon wrapper
> 
> The package appears to be lintian clean.
> 
> My motivation for maintaining this package is:
> The package is a needed dependency for another RFP package I2P (bug :
> 
> 
> #448638). As I am packaging the I2P router, I need this
> dependency to get onto the repositories. I got contact with the upstream
> Author and I will maintain the software with their help.
> 
> Please get a special attention to the name of the package, how I am
> 
> 
> building it, and to the jni libraries binaries built by the package.
> 
> The package can be found on mentors.debian.net :
> 
> 
> - URL: http://mentors.debian.net/debian/pool/main/s/service-wrapper-java
> - Source repository: deb-src http://mentors.debian.net/debian unstable main 
> contrib non-free
> 
> 
> - dget 
> http://mentors.debian.net/debian/pool/main/s/service-wrapper-java/service-wrapper-java_3.5.3-2.dsc
> 
> 
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards
> 
> 
> Rémi Debay,
> 




signature.asc
Description: OpenPGP digital signature

Re: RFS: freeplane (updated package)

[tony mancill]

On 06/08/2011 07:58 AM, Eric Lavarde wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 1.1.3-1
> of my package "freeplane".
> 
> It builds these binary packages:
> freeplane  - Java program to create and edit mind maps.
> libjortho-freeplane-java - Java spell-checking library.
> 
> The package appears to be lintian clean.
> 
> The upload would fix these bugs: 626187
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/f/freeplane
> - Source repository: deb-src http://mentors.debian.net/debian unstable main
> contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/f/freeplane/freeplane_1.1.3-1.dsc
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards
>  Eric Lavarde
> 
> PS: Lintian currently complains about the class-path manifest, but we agreed 
> on
> the Debian Java list that this is a special case (due to OSGi specifics) that
> Lintian might be able to catch in the future.

Sponsored.

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Bug#695588: RFS: jitsi/1.1.4365-1 [ITP]

[tony mancill]

On 03/15/2013 03:42 AM, Damian Minkov wrote:
> Hi,
> 
> we've just updated the package on mentors.debian.net following the
> comments we recieved:
> The dsc file can be found at:
> http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_2.0.4506.10553-1.dsc
> 
> Regards
> Damian

Hello Damian,

If you haven't heard from other potential sponsors, I will take a look
at the latest packaging.

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Bug#740035: RFS: sunflow and sweethome3d [DM but 1st upload to backports]

[tony mancill]

owner 740035 !
tags 740035 +pending
thanks

Hi Gabriele,

I'm working on these.

Thanks,
tony



signature.asc
Description: OpenPGP digital signature

Re: Excessive wait for DAM - something needs to be done

[tony mancill]

On Wed, 16 Jul 2003, David B Harris wrote:

> Hardly. Every Debian Developer has the ability to run arbitrary code as
> root on everybody's system. Do you want to try and make the argument
> that regardless of whether the person has proved spiteful, unstable,
> mean, and just generally a jackass ... right, are you wanting to make
> the case that even if they've proven themselves to be totally unreliable
> and untrustworthy, they should be allowed to run code as root on
> people's systems because they're technically capable of writing said
> code?

I personally don't find this argument compelling.  Like it or not, the
open source community is one built on trust, together with the fact that
having access to source and many willing and capable testers, problems are
detected and flushed out very quickly.  But read on, I believe that the
trust issue can be overcome.

> Indeed, pretty much every stage except for the DAM stage checks for
> technical details. Do they understand the DFSG? Do they know how to make
> a package? Can they prove they are who they say they are?
>
> At this point, as far as I know, only the DAM stage of the NM process is
> where the individual is looked at as a whole.

And the only argument here is that it's a huge task, and the DAM doesn't
seem to be able to keep up with applicants.

> Getting rid of that examination would be very detrimental to Debian as a
> whole, and will likely result in some very, very unpleasant things
> happening to the Debian community and to our users at some point.

Once again, I don't anticipate an apocalypse, but it is conceivable that
some unpleasantries could arise.  I can think of a couple of things that
would make the system a bit more fool-proof:

1)  Not everyone should be able to upload every package.  Unless you are
the established package maintainer, or until you file an ITP, and that ITP
is accepted and approved by some yet-to-be-delegated body in Debian, the
installer will simply throw away your package.  This eliminates the danger
of an NMU/hijack of binutils that rootkits everyone running unstable.  It
can also help prevent more subtle mistakes and attacks that could land
Debian in much worse trouble than a trojan horse.  The wrong piece of
non-DFSG code uploaded into the archive and then distributed via our
archive and mirrors system could wreck the project entirely.  Having a
checkpoint before stuff gets into our distribution mechanism seems prudent
anyway.

QA and security folks should be able to NMU/hijack at will.  They are
delegates, and are therefore entrusted with the extra authority.  There
may be other delegates who should have this authority as well, but it
should be controlled.

2)  Since the DAM can't look at *everyone* in explicit detail, I propose
that we extend the concept of advocacy beyond the NM phase and on into
maintainership.  If I were to advocate a script kiddie who actually tried
something malicious, then it should my ass, my key deleted from the
keyring, as well as the kiddie's.  I think there are other advantages to
this as well, such as encouraging a certain sense of community, maybe even
teamwork.

Also, the "strong advocate" method doesn't have to be the case for every
applicant - the DAM could continue with the process as today for folks who
couldn't find, or didn't want to tied to an advocate.

3)  A mechanism to revoke maintainership probably is necessary.  After
all, if you decide that you can't contribute to the project for a while,
why should Debian run the risk of keeping your account open.  You should
at least orphan all of your packages (hence "unregistering" your ability
to upload them) and have your machine accounts disabled.  When you're
ready to come back, given that you were worth a damn the last go around,
it should be no problem to get a DD to advocate you, and then you're back
in, contributing to the cause.  Beyond that, a delegate group of the DPL
that could exterminate the accounts of unsavories seems like a necessary
evil.  I'm not sure that we don't already have that today anyway.

4)  I'm not sure why everyone needs machine accounts.  Or for that matter,
even a d.o email address.  Sponsored maintainers seem to be able to get
along pretty well without either of these.  (At the same time, I don't see
why the email address should matter either way.)

Anyway, this thread should probably be on newmaint, so I'm cross-posting
it there.  Please follow-up on newmaint.

Cheers,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)

updates to upstream packages

[tony mancill]

-BEGIN PGP SIGNED MESSAGE-


I have been working with the authors of wanpipe and have some assorted
goodies that I'd like to include into my Debian package.  dpkg-buildsource
does like it when I just add the files to my source tree, I guess since
there is nothing to diff them against.

Should I upload a new .orig.tar.gz file?  And if I do so, shouldn't I
update the upstream version number?  (Which is bordering on raw fiction,
since no such upstream version exists.)

TIA,
tony

- --
In cartoons:
Here's a nickel, go buy yourself a real operating system...  (Scott Adams) 
In real life:
http://www.debian.org

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBNYX2GW7abKuvMMmhAQHHhwP+O1PfOrNC6eXYSJxA78u3bxwjOxy/fy3M
R9stH/T+J/mtBnIB0eh5Zc/ClQGrZ+WgDb1pKgZ/VjQSuEY5gRNhw/43HgPI9WGP
aFFd1MFdmur2/8w9ew9OeBJlVXKqwvCX24uk6FOHx850l0d1qTf0Wf02HRA97bJ5
gnGzgSzZxOY=
=BCYr
-END PGP SIGNATURE-


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

changing location of .conf files

[tony mancill]

I've been studying the "Debian Packaging Manual" section 6.3, and I want
to make sure that I am interpreting it correctly. 

My package contains a few conffiles which will be changing locations.
They are currently:

/etc/router.rc
/etc/router.conf
/usr/lib/router/interfaces/* -> ../../../var/wanpipe/*

(I never understood the need/reason symlink either; I inherited it from
Christoph Lameter.  Perhaps he was foreshadowing, in an Obi-Wan sort of
way, that I needed to do what I'm about to do.) 

I want to move them to:

/etc/wanpipe/router.rc
/etc/wanpipe/router.conf
/etc/wanpipe/interfaces/*

My question is:

According to the manual (section 6.3), "6.  Any files which were in the
old version of the package but not in the new are removed."  Fortunately,
I have a chance to take care of this in my preinst script (step 3).

But, I'm afraid of freaking out dpkg when it gets around to handling the
conffiles explicitly (as explained in chapter 9).  

The format of the configuration files is not changing.  Does the
following sound sane?

preinst checks to see if it was called with just "install" (new install -
in which case, don't worry about the conffiles, dpkg will handle them
later)

preinst checks to see if it was called with either "install "
or "upgrade ", which case it will copy whatever the user had
for these conffiles into the new locations (and then remove the old
conffiles?  Or let dpkg handle this?)

TIA for pointers and well-intended flames.
tony
<[EMAIL PROTECTED]>

--
"Here's a nickel, go buy yourself  |  Debian/GNU Linux
a _real_ operating system."|  
   (Dilbert)   | (real life)

using packages in slink

[tony mancill]

Hopefully this question isn't too dense, but I'm interested in seeing how
others handle this problem.  I pointed my hamm system at an ftp server
carrying slink and updated my package list.  Now dselect wants me to
update about 80MB of software on my system.  This is ok, I guess, but I
happened to notice that one of the packages was libstdc++ 2.9.  If I load
this and then build my package (wanpipe, which has one executable which
links against this), isn't that basically forcing everyone who wants to
use wanpipe to start using slink instead of stable?

On a related note, I'm still completely in the dark about how packages
migrate through the different sub-distributions within a release.  i.e.
should everything I upload to master be classified as "unstable"?  And
when/how/by which criteria will it move to "slink" and then maybe to
"stable"?

Sorry once again if these aren't rocket science.  I've been using Debian
since 1.1 in production and have never used anything except "stable".  Now
that I'm maintaining a package, I want to be using the latest revision,
but don't see a way of doing that outside of placing that package in my
dists/stable/local directory on my company's internal mirror.  I'd also
like to understand better what makes up a (point) release and how we can
help those who are working on it.  (i.e. upload revs early and often, or
try to keep uploads to a minimum while the package slowly ripens in my own
test environment...)

Thanks,
tony

--
"Here's a nickel, go buy yourself  |  Debian/GNU Linux
a _real_ operating system."|  
   (Dilbert)   | (real life)

packages with kernel version dependencies

[tony mancill]

Greetings mentors,

I maintain the wanpipe package, which is a set of utilities for use with
Sangoma WAN router cards.  The binaries have to be compiled with a certain
version of the kernel.  Moreover, the kernel patches required for the
drivers are not part of 2.0.36 or 2.0.37 (the package distributes these,
and the admin must apply them against the kernel source).  Alan Cox is
working on integrating the patches into the 2.2.x kernel, but the effort
is not yet complete.  They are there, but the pristine source still
require patching.  What's worse, there are different patches for several
2.2.x versions.

Has anyone has experience working with a package that has this sort of
issues?  Most router admins are aware of the kernel issues, but I still 
have the need to have versions of the package compiled for both 2.0 and 
2.2.  Do I have to create a package with a new name?  Does wanpipe have
to conflict with certain kernel packages?  Should I try to get the
patches (and modules) integrated into the Debian kernel packages?

The current package works fine with 2.0.3[67], but I want to upload
something before the potato freeze if necessary.

Also, can anyone tell me when potato will freeze and what the target
kernel version is?  (Sorry, there's no way I could read debian-devel and
have enough time to do anything else for the project.)

Assistance is appreciated,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.mancill.com | a pound of obscure...
   |(Peart)

Re: how best to maintain a patch

[tony mancill]

On Fri, 30 Jul 1999, David Coe wrote:

> So I think I'll create a source patch file
> and add a rule to debian/rules to apply it 
> for each build.  The alternative, of course, 
> would be to just apply the patch once to 
> the working source tree, and let the .deb 
> system handle it.
> 
> I think I like the separate patch file better,
> though, because it'll be easier to keep this
> patch separate from other patches made for
> other purposes, when migrating to newer releases
> of upstream source.

Having made the mistake of applying the patches to the source tree and
then having to jump through major hoops everytime a new upstream version
came out, I think that you are on the right track.  I have a directory in
the root of my package directory named non_upstream which I use for things
that the upstream people will not incorporate into their source and are
required to comply with the FHS, etc.  But I normally just copy the new
versions into place during the build.  If you apply them as patches,
you'll need to remember to revert them during your "make clean" phase.

It might be sort of nice to do it the way you propose, but I'd like to
hear some other thoughts on the matter.

tony

things broke when I went to dpkg-dev 1.4.1.6

[tony mancill]

Can anyone give me a clue on where to look for this one?  My rules file
has not changed (much), and now my package build gets almost to the end
and dies with:

dpkg-genchanges: failure: cannot read files list file: No such file or
directory

Any help would be appreciated.
TIA,
tony

  [EMAIL PROTECTED] |  I am a concientious man. 
http://www.debian.org  |  When I throw rocks at seabirds,
   |  I leave no tern unstoned.  (Ogden Nash)

Re: things broke when I went to dpkg-dev 1.4.1.6

[tony mancill]

I was able to circumnavigate the problem (perhaps I should have played
with it a little longer before posting), but it still baffles me.  I was
doing my package build with:

dpkg-buildpackage -rfakeroot

and it was failing.  I invoked dh_gencontrol by itself with "fakeroot
dh_gencontrol" and it produced a debian/files file for me...  Weird.  Now
I cannot reproduce the problem.

Thanks for the reply,
tony

P.S.  Thanks go to Mattias Klose for suggesting using the .dpatch
mechanism from the egcs package.  It works great.  If anyone else would
like to keep their mods to the upstream source in patches which are
applied/reversed during the build/clean, check out the debian/rules and
debian/patches/* part of the egcs package, or look at mine
(wanpipe_2.0.5-1), or drop me a line.

  [EMAIL PROTECTED] |  Life is fraught with opportunities
http://www.debian.org  |to keep your mouth shut. 
   |   (fortune)

On Mon, 16 Aug 1999, Raphael Hertzog wrote:

> Le Mon, Aug 16, 1999 at 01:53:13AM -0700, tony mancill écrivait:
> > dpkg-genchanges: failure: cannot read files list file: No such file or
> > directory
> 
> The file debian/files is removed by dh_clean. Check that you don't call
> dh_clean somewhere unexpected. For a multi-binary package you may have to
> use dh_clean -k.
> 
> If you're not using debhelper, you should show us the rules file. I'm
> using dpkg-dev 1.4.1.6 without problems ...
> 
> Cheers,
> -- 
> Hertzog Raphaël >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/
> 

Re: debian version numbers for future-maintainers

[tony mancill]

On Thu, 19 Aug 1999, David Coe wrote:

> I'm ready to create packages, as a future-maintainer,
> to be handed to my sponsor to be uploaded.
> 
> Should I set the debian version number to -1 (currently
> it's -0.6, never had an official maintainer), or should
> I continue using NMU numbering (i.e. -0.7 in this case)?

It is my opinion that you should set the debian version number to -1.
You will be the maintainer of the package for some time to come.

  [EMAIL PROTECTED] |  Forget honesty - forget creativity
http://www.debian.org  |  The dumbest buys the mostest
   |  Is the name of the game...  (Biafra)

Re: binary package version numbers?

[tony mancill]

On Sat, 11 Sep 1999, Josip Rodin wrote:

> On Sat, Sep 11, 1999 at 02:20:07PM -0400, Peter S Galbraith wrote:
> > We don't have a scheme which doesn't force other arches to
> > rebuild beacuse of another arch build's mistake, right?
> 
> I think that we use -2.0.1 , meaning "a recompile of -2". I've seen
> that quite often, don't know how official it is.

I think that this is pretty much equivalent to the following section from
the Debian Developer's Reference:

   8.2 Guidelines for Porter Uploads 

   If the package builds out of the box for the architecture to be ported
   to, you are in luck and your job is easy. This section applies to that
   case; it describes how to build and upload your binary NMU so that it
   is properly installed into the archive. If you do have to patch the
   package in order to get it to compile for the other architecture, you
   are actually doing a source NMU, so consult How to do a source NMU,
   Section 7.4 instead.

   In a binary NMU, no real changes are being made to the source. You do
   not need to touch any of the files in the source package. This
   includes debian/changelog. 

   Sometimes you need to recompile a packages against other packages
   which have been updated, such as libraries. You do have to bump the
   version number in this case, so that the upgrade system can function
   properly. Even so, these are considered binary-only NMUs -- there is
   no need in this case for all architectures to recompile.  You should
   set the version number as in the case of NMU versioning, but add a
   ``.0.'' before the the NMU version. For instance, a recompile-only NMU
   of the source package ``foo_1.3-1'' would be numbered
   ``foo_1.3-1.0.1''. 

   The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B
   -mporter-email. Of course, set porter-email to your email address.
   This will do a binary-only build of only the architecture-dependant
   portions of the package, using the `binary-arch' target in
   debian/rules.


  [EMAIL PROTECTED] |  A word to the wise is... 
http://www.debian.org  |  often enough to start an argument.  (fortune)

Re: Bug#49648: plib1: Where is -dev package?

[tony mancill]

On 9 Nov 1999, Falk Hueffner wrote:

> [snip]
> > > Hence, a program compiled with the Version 1 header will crash
> > > if linked against the version 2 library.
> [snip]
> > > This makes distributing
> > > binary programs very hard if the library is a '.so' because it's
> > > very likely that the program will become linked to a library
> > > that doesn't match the header it was compiled with.
> 
> This cannot happen when using Debian packages, since they (should)
> include appropriate Conflicts.

I'm sorry that I didn't reply to this sooner, since I cannot quote all of
the original message.  I think that things are a little bit backwards; you
*need* to distribute the .so libraries in the regular plib package, and
the .a libraries in the -dev package.  .a libraries are useless unless
you're compiling (static) binaries.

Falk Hueffner is correct in the assessment of .so libraries - for
any Debian package compiled with plib, there will be a dependency on
the correct version of the the plib package (containing the necessary 
.so files of the correct version).

So, in summary:

The plib-dev package should contain headers and .a libraries.
The plib package should contain the shared libraries.

Disclaimer:  I'm not a maintainer of library packages, so those who know
better, please feel free to jump in and set things straight.  AFAIK,
however, this is how it should work.

  [EMAIL PROTECTED] | If we all work together, 
http://www.debian.org  |we can totally disrupt the system.  (fortune)

Re: Devices and patches

[tony mancill]

Hi David,

On Thu, 6 Apr 2000, David Fernandez Vaamonde wrote:

> The program needs a patch to be applied to the kernel... How can you mark
> this need in the package ? Should it be automatized? 

I went though this same thing with "wanipe" package.  If the patch is
stable, but unlikely to be part of the upstream kernel anytime soon, you
can ask the maintainer of the Debian kernel packages (Herbert Xu) to
include the patch.  If it's not too intrusive and can be compiled as a
module, it can be part of the "stock" Debian kernel.  Otherwise, it could
be part of the kernel source package, and you would include notes in your
package about how to build the source.

Hope that helps,
tony

P.S.  Your English seems to be very good indeed.

  [EMAIL PROTECTED] |  Race is not a competition
http://www.debian.org  |  Sex is not a job description
(Peart ->) |  We hold these truths to be self-evident...

Re: ITP and sponsor needed: texdoctk

[tony mancill]

On Sun, 30 Apr 2000, Adrian Bunk wrote:

> I would like to package texdoctk for Debian and I'm looking for a sponsor.

Hello Adrian,

I'll be happy to sponsor this for you.

Regards,
tony

  [EMAIL PROTECTED] | Danger + Survival = Fun
http://www.debian.org  |(Neil Peart)

Re: How do I *really* get my GPGP key?

[tony mancill]

Bruce,

I must be missing something here.  How do you intend to be a Debian
maintainer if you don't run a Debian box?  Perhaps you are requesting that
a Debian maintainer pick up your package to add to the distribution.
Please send me some details or a link, and I'll be happy to look at the
package.

Regards,
tony mancill

  [EMAIL PROTECTED] |  Race is not a competition
http://www.debian.org  |  Sex is not a job description
(Peart ->) |  We hold these truths to be self-evident...


On Thu, 4 May 2000, Bruce Korb wrote:

> 
> Hi,
> 
> The instructions on:
> 
>   http://www.debian.org/doc/packaging-manuals/developers-reference\
> /ch-new-maintainer.html
> 
> was too confusing.  Especially since I am behind firewalls and
> running OSR5, not Linux let alone Debian.  I forwarded on my
> request for maintainership for my AutoGen package, sans a PGP key.

Re: what creates a Packages{,.gz} etc. file ?

[tony mancill]

I did this same thing to setup a Debian mirror at work.  If you look
carefully, all you have to do is delete the existings Packages.gz files
(since they are for a single CD) and mv Packages-cd.gz Packages.gz (do the
same for the uncompressed packages).  It's a lot easier if you do this
with a find . -name Packages-cd -exec mv ..., because there are about 6 of
them.

BTW, this worked for everything *except* non-US, which I need to look
further into.  It could just be that I have the source URL in apt
definined incorrectly.

HTH,
tony

On Fri, 5 May 2000, Jordi Mallach wrote:

> On Wed, May 03, 2000 at 05:30:00PM +1000, Andrew J Cosgriff wrote:
> > dpkg-scanpackages was it.  I missed it when I did a "man -k Packages".
> 
> Related to this, I have a question also.
> One friend has a new hard drive and wants to copy his 3 unofficial potato
> CDs into it, and make them aptable. So I copied the CDs on a
> debian/dist/{m,c,n-f,n-u} tree and I guess I only need to run
> dpkg-scanpackages on each directory to generate the Packages files. The
> problem is I don't know which is the overrides file in the CDs. Is it
> necessary?
> 
> An example would be the best help.
> 
> -- 
> Jordi Mallach Pérez || [EMAIL PROTECTED]   || Rediscovering Freedom,
> ka Oskuro in RL-MUD || [EMAIL PROTECTED]|| Using Debian GNU/Linux
> 
> http://sindominio.net  GnuPG public information:  pub  1024D/917A225E 
> telnet pusa.uv.es 23   73ED 4244 FD43 5886 20AC  2644 2584 94BA 917A 225E
> 

  [EMAIL PROTECTED] |  After all is said and done, 
http://www.debian.org  |  a heck of a lot more is said than done.
   | (fortune)

Re: Linux Beginner

[tony mancill]

On Fri, 12 May 2000, Jay Kelly wrote:

> I am currently running Windows 2000 as my file server with three clients
> running Windows 98. Can I replace the Windows 2000 server with Linux and
> still have the Windows 98 clients log into the Linux server just as before?
> Any help would be appreciated

Jay,

you should spend some time researching "Samba" as a network server.
  There are also some good books on Samba out there.
BTW, the debian-mentors list is for new Debian maintainers who have
questions about developing for Debian.  You should send further questions
to [EMAIL PROTECTED]

Hope that helps,
tony

  [EMAIL PROTECTED] |   There is unrest in the forest
http://www.debian.org  |   There is trouble with the trees
   |   For the Maples want more sunlight
 (Peart ->)|   And the Oaks ignore their pleas

Re: is this RC?

[tony mancill]

On Sun, 21 May 2000, Christian Hammers wrote:

> /home/gchavdarov/mysql32/mysql-3.22.32# dpkg-buildpackage
> dpkg-buildpackage: source package is mysql
> dpkg-buildpackage: source version is 3.22.32-1
> dpkg-buildpackage: source maintainer is Christian Hammers <[EMAIL PROTECTED]>
> debian/rules clean DEB_BUILD_ARCH=i386 DEB_BUILD_GNU_CPU=i386
>  +DEB_BUILD_GNU_SYSTEM=linux DEB_BUILD_GNU_TYPE=i386-linux DEB_HOST_ARCH=i386
>  +DEB_HOST_GNU_CPU=i386 DEB_HOST_GNU_SYSTEM=linux DEB_HOST_GNU_TYPE=i386-linux
> /usr/bin/dpkg-buildpackage: debian/rules: Permission denied
> 
> I think it's because "dpkg-source -x" tells me that one piece of the patches
> in the diff file was rejected. Don't ask me why the automatically generated
> patch was rejected, as the problem is "{ome" instead of "some" I think that
> my filesystem got corrupted somewhen.

The "Permission denied" bit is most likely because debian/rules is not
executable.  You can change this with a simple:  "chmod +x debian/rules"
The rejection of the diff file sounds a bit more serious.  I'd make sure
that everything is sane, bump your version number because of the
permissions change, and then upload the new version along with the
complete source.

Cheers,
tony

  [EMAIL PROTECTED] |  DYSLEXICS OF THE WORLD, UNTIE!
http://www.debian.org  |  

Re: upload with name of sponsored person?

[tony mancill]

On Wed, 23 Aug 2000, Joop Stakenborg wrote:

> I am sponsoring drew parsons and would like to upload his packages
> with only his entry in the changelog. Is that possible?
> 
> My guess is that the package will be rejected because he is not
> a debian maintainer yet

Ah, finally something I know the answer to.  I've done quite a bit of
sponsoring of late, and have found that the following procedure works
best:

1)  Have the sponsee build the package, but don't have them sign
it.  (You'll just end up having to hand-edit .dsc and .changes to remove
their signature header and signature.)

2)  Have the sponsee send you a tarball of the build directory (or just
the files in the build directory).  They can use something like:

find . -maxdepth 1 -type f | tar cIvf /tmp/pkgtarball.tar.bz2 -T -

If you trust their key, have them sign the tarball itself.

3)  Extract the tarball into a directory on your box and perform your
normal checks.  (* What you should check is an entirely different topic.)  
If you want to test a build, save a copy of the tarball for later.

4)  Use "debsign -m [EMAIL PROTECTED] *changes" to sign the package with
your key.  Then "dupload *changes".

The advantages to this method (over, say building the package yourself
from sources) are:

- bug reports, etc. go to the sponsee, because the control file has their
email address in it.  This helps them get the "real" maintainer
experience.  (One of my sponsees always add a line to the change record to
indicate who sponsored the upload.  This seems prudent in case there were
to be some problem later on.)

- libraries and dependencies get calculated on the sponsee's machine, so
the sponor doesn't necessarily have to have the same Debian release as the
package.

- it's less work for the sponsor than any other way I've tried.

I'm writing this sort of off-the-cuff while at work, so feel free to hit
me up with questions and comments.  If there is interest, I'll try to get
this typed up as a HOWTO of sorts.

Cheers!
tony

  [EMAIL PROTECTED] |  Time after time we lose sight of the way.
http://www.debian.org  |  Our causes can't see their effects.
   |  (Neil Peart)

OT: Re: Sponsor's responsibilities

[tony mancill]

On Sat, 16 Sep 2000, Antti-Juhani Kaijanaho wrote:

> On 2915T060004-0700, Rick Younie wrote:
> > Sponsee?  Tony made that one up didn't he?  I can see the
> > confusion in a couple years when the number of Debian maintainers
> > hits a few million.  "What's that language you're speaking?
> > Debian you say?" :-)
> 
> Tony who?
> 
> You ever heard of deriving words?  The thing that allows you to make
> up a word using established derivation mechanisms when no existing word
> is suitable?

I appear to be the Tony in question.  I'm very likely also responsible for
coining the word "sponsee" (although I can't really take credit - my
company uses "mentee" as the counterpart to "mentor" - since no one seems
to be able to spell "protege" correctly on a consistent basis.)

I have to confess that I need to go back and try to follow this thread
from the start (/me runs off to find a threaded mail reader), but if the
issue is the use of Debianspeak, then what do folks think of the word
protege?

$ dict protege
2 definitions found

From Webster's Revised Unabridged Dictionary (1913) [web1913]:

  Prot'eg'e \Pro`t['e]`g['e]"\, n. m. Prot'eg'ee
  \Pro`t['e]`g['e]e"\, n. f.[F., p. p. of prot['e]ger. See
 {Protect}.]
 One under the care and protection of another.

From WordNet (r) 1.6 [wn]:

  protege
   n : a person who receives support and protection from an
   influential patron who furthers the protege's career

I guess that we're talking about a career in Debian, although I'm not sure
how much "support and protection" I provide to my
victims^H^H^H^H^H^H^Hsponsees.  (On the other hand, maybe we really *need*
a new word for "the person whom a sponsor sponsors" since I'm not sure
that such a relationship existed up until now.)

Cheers,
tony

  [EMAIL PROTECTED] |  Time after time we lose sight of the way.
http://www.debian.org  |  Our causes can't see their effects.
   |  (Neil Peart)

the "right" way to handle caps in package/program names

[tony mancill]

I'm working on a package for ripperX, which comes in a ripperX_2.0 tarball
and extracts itself into ripperX-2.0 directory, and produces a "ripperX"
binary.

When I left things as they were upstream, dh_make doesn't complain, but I
get all kinds of problems actually trying to build the package.  (dpkg
doesn't like the control file with caps in the package name, and when I
fix that, then the orig.tar doesn't match, etc.)

Is there a prescribed method for handling upstream source like this?  
Should I fold the directory name in the tarball into lowercase?  Since the
package name is going to be lowercase, it seems confusing that the binary
is mixed-case.  Should I provide a symlink?  Fold the binary name itself
into lowercase?  (The same applies for the manpage too, I guess.)

Thanks in advance for pointers, tony

  [EMAIL PROTECTED] |  I am a concientious man. 
http://www.debian.org  |  When I throw rocks at seabirds,
   |  I leave no tern unstoned.  (Ogden Nash)

Re: different sizes for same upstream tarball

[tony mancill]

On 7 Jan 2001, Goswin Brederlow wrote:

> The orig.tar.gz file should be pristine (does someone have the pointer
> to the policiy about this?). Basically NEVER rebuild it.
> 
> It should be the original file downloaded from the upstream author
> without any changes so that the md5sum compares to any md5sum the
> author made public.

This is neither pragmatic, nor could I find anything in policy or the
packaging manual that states this.  The reason this is not a useful
guideline is that *many* upstream tarballs are not a
./$package-$version/code format.  Some aren't gzipped, and some
aren't even tarballs.  Yet others are broken in other special ways.  For
example, I just sponsored  an upload a fortunes package where the
upstream tarball contained a full copy of the source for wget (?!?) -
naturally, we cut that out and saved about 450kB of cruft from occupying
every Debian mirror in the world.

As for Debian policy, the packaging manual (section 3.3) has this to say:

Original source archive - package_upstream-version.orig.tar.gz

  This is a compressed (with gzip -9) tar file containing the source code
  from the upstream authors of the program. The tarfile unpacks into a
  directory package-upstream-version.orig, and does not contain files 
  anywhere other than in there or in its subdirectories. 

Of course, you should make every effort to maintain the integrity of the
upstream source, but that doesn't mean that you can't repack it if need
be.  After all, that's why we insist on licenses that allow 
redistribution.

tony

  [EMAIL PROTECTED]  |  Der Graf sehnt sich so sehr nach dem Blut einer 
http://www.debian.org   |  Jungfrau.  Doch der Graf hat Angst... 
|  Angst vor HIV. (die Aerzte)

Re: Custom package versioning

[tony mancill]

On Tue, 17 Apr 2001, Amaya wrote:

> At work, we are making custom Debian packages and we need a special
> versioning system so that apt does not try to replace our package with
> a newer upstream one.
> 
> I would like to know if there's a standard way to proceed, apart from
> setting the debian version to customX, which is good, but doesn not
> deal with the fact that dpkg will try to replace the package with a
> newer upstream one.

At my work, we pulled a copy of stable and placed it on a mirror.  Then we
created our own "dist" with two sections - bofa (Bank of America) and
backports.  The first is for truly local packabes, and the second is for
"Debian upstream" packages that we recompile for various reasons (either
stuff from unstable, or slight mods, etc.)  We've got a script to regen
our packages files every time we drop something new into the mirror.  We
name our packages "version-XlocalY"

Pros:
complete control over what gets installed on your systems
fast internal mirror is faster and saves bandwidth for everybody

Cons:
relatively labor intensive to keep current on point releases and
security.d.o (but we've got really strong change control, and we know
what's out there!)

HTH,
tony

Re: upload with name of sponsored person?

[tony mancill]

On Wed, 23 Aug 2000, Joop Stakenborg wrote:

> I am sponsoring drew parsons and would like to upload his packages
> with only his entry in the changelog. Is that possible?
> 
> My guess is that the package will be rejected because he is not
> a debian maintainer yet

Ah, finally something I know the answer to.  I've done quite a bit of
sponsoring of late, and have found that the following procedure works
best:

1)  Have the sponsee build the package, but don't have them sign
it.  (You'll just end up having to hand-edit .dsc and .changes to remove
their signature header and signature.)

2)  Have the sponsee send you a tarball of the build directory (or just
the files in the build directory).  They can use something like:

find . -maxdepth 1 -type f | tar cIvf /tmp/pkgtarball.tar.bz2 -T -

If you trust their key, have them sign the tarball itself.

3)  Extract the tarball into a directory on your box and perform your
normal checks.  (* What you should check is an entirely different topic.)  
If you want to test a build, save a copy of the tarball for later.

4)  Use "debsign -m [EMAIL PROTECTED] *changes" to sign the package with
your key.  Then "dupload *changes".

The advantages to this method (over, say building the package yourself
from sources) are:

- bug reports, etc. go to the sponsee, because the control file has their
email address in it.  This helps them get the "real" maintainer
experience.  (One of my sponsees always add a line to the change record to
indicate who sponsored the upload.  This seems prudent in case there were
to be some problem later on.)

- libraries and dependencies get calculated on the sponsee's machine, so
the sponor doesn't necessarily have to have the same Debian release as the
package.

- it's less work for the sponsor than any other way I've tried.

I'm writing this sort of off-the-cuff while at work, so feel free to hit
me up with questions and comments.  If there is interest, I'll try to get
this typed up as a HOWTO of sorts.

Cheers!
tony

  [EMAIL PROTECTED] |  Time after time we lose sight of the way.
http://www.debian.org  |  Our causes can't see their effects.
   |  (Neil Peart)



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

OT: Re: Sponsor's responsibilities

[tony mancill]

On Sat, 16 Sep 2000, Antti-Juhani Kaijanaho wrote:

> On 2915T060004-0700, Rick Younie wrote:
> > Sponsee?  Tony made that one up didn't he?  I can see the
> > confusion in a couple years when the number of Debian maintainers
> > hits a few million.  "What's that language you're speaking?
> > Debian you say?" :-)
> 
> Tony who?
> 
> You ever heard of deriving words?  The thing that allows you to make
> up a word using established derivation mechanisms when no existing word
> is suitable?

I appear to be the Tony in question.  I'm very likely also responsible for
coining the word "sponsee" (although I can't really take credit - my
company uses "mentee" as the counterpart to "mentor" - since no one seems
to be able to spell "protege" correctly on a consistent basis.)

I have to confess that I need to go back and try to follow this thread
from the start (/me runs off to find a threaded mail reader), but if the
issue is the use of Debianspeak, then what do folks think of the word
protege?

$ dict protege
2 definitions found

From Webster's Revised Unabridged Dictionary (1913) [web1913]:

  Prot'eg'e \Pro`t['e]`g['e]"\, n. m. Prot'eg'ee
  \Pro`t['e]`g['e]e"\, n. f.[F., p. p. of prot['e]ger. See
 {Protect}.]
 One under the care and protection of another.

From WordNet (r) 1.6 [wn]:

  protege
   n : a person who receives support and protection from an
   influential patron who furthers the protege's career

I guess that we're talking about a career in Debian, although I'm not sure
how much "support and protection" I provide to my
victims^H^H^H^H^H^H^Hsponsees.  (On the other hand, maybe we really *need*
a new word for "the person whom a sponsor sponsors" since I'm not sure
that such a relationship existed up until now.)

Cheers,
tony

  [EMAIL PROTECTED] |  Time after time we lose sight of the way.
http://www.debian.org  |  Our causes can't see their effects.
   |  (Neil Peart)


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

the "right" way to handle caps in package/program names

[tony mancill]

I'm working on a package for ripperX, which comes in a ripperX_2.0 tarball
and extracts itself into ripperX-2.0 directory, and produces a "ripperX"
binary.

When I left things as they were upstream, dh_make doesn't complain, but I
get all kinds of problems actually trying to build the package.  (dpkg
doesn't like the control file with caps in the package name, and when I
fix that, then the orig.tar doesn't match, etc.)

Is there a prescribed method for handling upstream source like this?  
Should I fold the directory name in the tarball into lowercase?  Since the
package name is going to be lowercase, it seems confusing that the binary
is mixed-case.  Should I provide a symlink?  Fold the binary name itself
into lowercase?  (The same applies for the manpage too, I guess.)

Thanks in advance for pointers, tony

  [EMAIL PROTECTED] |  I am a concientious man. 
http://www.debian.org  |  When I throw rocks at seabirds,
   |  I leave no tern unstoned.  (Ogden Nash)


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: different sizes for same upstream tarball

[tony mancill]

On 7 Jan 2001, Goswin Brederlow wrote:

> The orig.tar.gz file should be pristine (does someone have the pointer
> to the policiy about this?). Basically NEVER rebuild it.
> 
> It should be the original file downloaded from the upstream author
> without any changes so that the md5sum compares to any md5sum the
> author made public.

This is neither pragmatic, nor could I find anything in policy or the
packaging manual that states this.  The reason this is not a useful
guideline is that *many* upstream tarballs are not a
./$package-$version/code format.  Some aren't gzipped, and some
aren't even tarballs.  Yet others are broken in other special ways.  For
example, I just sponsored  an upload a fortunes package where the
upstream tarball contained a full copy of the source for wget (?!?) -
naturally, we cut that out and saved about 450kB of cruft from occupying
every Debian mirror in the world.

As for Debian policy, the packaging manual (section 3.3) has this to say:

Original source archive - package_upstream-version.orig.tar.gz

  This is a compressed (with gzip -9) tar file containing the source code
  from the upstream authors of the program. The tarfile unpacks into a
  directory package-upstream-version.orig, and does not contain files 
  anywhere other than in there or in its subdirectories. 

Of course, you should make every effort to maintain the integrity of the
upstream source, but that doesn't mean that you can't repack it if need
be.  After all, that's why we insist on licenses that allow 
redistribution.

tony

  [EMAIL PROTECTED]  |  Der Graf sehnt sich so sehr nach dem Blut einer 
http://www.debian.org   |  Jungfrau.  Doch der Graf hat Angst... 
|  Angst vor HIV. (die Aerzte)


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Custom package versioning

[tony mancill]

On Tue, 17 Apr 2001, Amaya wrote:

> At work, we are making custom Debian packages and we need a special
> versioning system so that apt does not try to replace our package with
> a newer upstream one.
> 
> I would like to know if there's a standard way to proceed, apart from
> setting the debian version to customX, which is good, but doesn not
> deal with the fact that dpkg will try to replace the package with a
> newer upstream one.

At my work, we pulled a copy of stable and placed it on a mirror.  Then we
created our own "dist" with two sections - bofa (Bank of America) and
backports.  The first is for truly local packabes, and the second is for
"Debian upstream" packages that we recompile for various reasons (either
stuff from unstable, or slight mods, etc.)  We've got a script to regen
our packages files every time we drop something new into the mirror.  We
name our packages "version-XlocalY"

Pros:
complete control over what gets installed on your systems
fast internal mirror is faster and saves bandwidth for everybody

Cons:
relatively labor intensive to keep current on point releases and
security.d.o (but we've got really strong change control, and we know
what's out there!)

HTH,
tony


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Perl Packages

[tony mancill]

On Fri, 24 Aug 2001, Martin Butterweck wrote:

> I ITP some perl modules, is there something special I have to know about
> packaging them ? Or are perl packages just like all other packages ?

Please see the Perl Policy:  http://people.debian.org/~bod/perl-policy/

Cheers,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: no arch debs

[tony mancill]

On Wed, 17 Apr 2002, David H. Askew wrote:

> I am building some unofficial(for now) debs for jedit... and have
> completed building them for the x86 arch .. and I got to thinking of
> something... is it possible to build debs without a dependent arch?

Hi David,

if I understand correctly, all you need to do is set "Architecture: all"
in your debian/control file and then declare a dependency on an
appropriate interpreter.  This is what many Perl-based packages do.  In
this case, I suppose you'll have a dependency on a JVM package.

> ..since jedit is written in java ... its technically platform
> independent ... is it possible to produce debs that will install on any
> platform? and if so .. what should I read?
>
> .. if not ... Is it the infrastructure, by the way its setup via
> porters, that make this impossible .. ?

When you upload, the package won't be built on the other architectures and
will only be stored once in the archive.  The .deb will be something like:

libmath-currency-perl_0.09-1_all.deb

Don't be alarmed by the fact that the changes files references an
architecture in it's name; this is simply an indication of the platform on
which the package was built.  E.g.:

libmath-currency-perl_0.09-1_i386.changes

Hope that helps,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: File a bug against my own package?

[tony mancill]

On Tue, 19 Nov 2002, Kenneth Pronovici wrote:

> While testing a patch from upstream to fix a bug in my libxmltv-perl
> package, I discovered another bug related to the package version
> for libhtml-tableextract-perl (one XMLTV script requires 1.08, the
> Debian version of the package is 1.06-2).  I've filed a bug against
> libhtml-tableextract-perl requesting that the new upstream version be
> packaged.
>
> Should I file a bug against my own package to report the related
> problem, that libxmltv-perl should depend on libhtml-tableextract-perl
> (>=1.08-1), or should I just track this on my own?  I'm thinking it
> would be nice to have a changelog entry:
>
>* Changed to depend on libhtml-tableextract-perl >=1.08 (closes: #nnn)
>
> but I'm not sure this is appropriate.

Ken,

I believe that filing a bug against your own package is appropriate,
especially when the bugreport might be useful to others.

Cheers,
tony

  [EMAIL PROTECTED] | Better the pride that resides in a citizen of
http://www.debian.org  | the world, than the pride that divides,
   | when a colorful rag is unfurled.(Peart)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Warning about Debian New Maintainer Application

[tony mancill]

On Tue, 4 Feb 2003, Craig Small wrote:

> On Mon, Feb 03, 2003 at 11:10:48AM +0300, Shiju p. Nair wrote:
> > Am currently mainatains two packages ( libnet-easytcp-perl & libmng )
> > both sponsored by Tony Mancil and am interested in adopting more
> > orphaned packages. But Tony no longer responds to my email for unknown
> > reason. Its now
>
> That's a concern, Tony has been one of the more active advocates.
> Hope everything is ok.

I'm here, I've just been very slow to respond recently.  (Too many high
priority Real Life(tm) processes for the 'ole scheduler to handle without
thrashing...)  I've contacted madhu privately about sponsoring some
orphaned packages.

Cheers,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dpkg-signpackage

[tony mancill]

On Fri, 4 Apr 2003, Colin Watson wrote:

> On Fri, Apr 04, 2003 at 05:05:09PM +0200, A Mennucc1 wrote:
> > I would like to sponsor a package of a friend
> >
> > the first time, I (of course) check the package
> > (lintian, install it, etc etc)
> >
> >
> > but what about the next times? what is the best practice?
> >
> >
> > 1) simply resign it, and upload.
> >
> > 2) rebuild it from source each time
>
> Never sign something you haven't built.
>
> > I would prefer the 1st , for saving my time, but I have problems.
> > Is there any easy way to strip away the signature of the sponsoree
> > and sign it with mine? there used to be a 'dpkg-signpackage'
> > command, but I can't find it anymore
>
> debsign, maybe?

Just to chime in, I never sponsor anything I haven't built myself either.
I recommend getting the sponsoree to send you only the orig.tar.gz, the
diff.gz, and the .dsc file.  That way you'll know that the package builds
from source.  Then build with:

dpkg-buildpackage -rfakeroot -us -uc

Once I'm satisfied with the build, lintian/linda checks, and that the
package installs/deinstalls ok, etc., then I sign with debsign.  I just
dropped a script into ~/bin/ that should be called with the .changes
file(s) as the argument.

[EMAIL PROTECTED]:~$ cat bin/dsign
#!/bin/sh
debsign [EMAIL PROTECTED] $*

HTH,
tony



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Excessive wait for DAM - something needs to be done

[tony mancill]

On Wed, 16 Jul 2003, David B Harris wrote:

> Hardly. Every Debian Developer has the ability to run arbitrary code as
> root on everybody's system. Do you want to try and make the argument
> that regardless of whether the person has proved spiteful, unstable,
> mean, and just generally a jackass ... right, are you wanting to make
> the case that even if they've proven themselves to be totally unreliable
> and untrustworthy, they should be allowed to run code as root on
> people's systems because they're technically capable of writing said
> code?

I personally don't find this argument compelling.  Like it or not, the
open source community is one built on trust, together with the fact that
having access to source and many willing and capable testers, problems are
detected and flushed out very quickly.  But read on, I believe that the
trust issue can be overcome.

> Indeed, pretty much every stage except for the DAM stage checks for
> technical details. Do they understand the DFSG? Do they know how to make
> a package? Can they prove they are who they say they are?
>
> At this point, as far as I know, only the DAM stage of the NM process is
> where the individual is looked at as a whole.

And the only argument here is that it's a huge task, and the DAM doesn't
seem to be able to keep up with applicants.

> Getting rid of that examination would be very detrimental to Debian as a
> whole, and will likely result in some very, very unpleasant things
> happening to the Debian community and to our users at some point.

Once again, I don't anticipate an apocalypse, but it is conceivable that
some unpleasantries could arise.  I can think of a couple of things that
would make the system a bit more fool-proof:

1)  Not everyone should be able to upload every package.  Unless you are
the established package maintainer, or until you file an ITP, and that ITP
is accepted and approved by some yet-to-be-delegated body in Debian, the
installer will simply throw away your package.  This eliminates the danger
of an NMU/hijack of binutils that rootkits everyone running unstable.  It
can also help prevent more subtle mistakes and attacks that could land
Debian in much worse trouble than a trojan horse.  The wrong piece of
non-DFSG code uploaded into the archive and then distributed via our
archive and mirrors system could wreck the project entirely.  Having a
checkpoint before stuff gets into our distribution mechanism seems prudent
anyway.

QA and security folks should be able to NMU/hijack at will.  They are
delegates, and are therefore entrusted with the extra authority.  There
may be other delegates who should have this authority as well, but it
should be controlled.

2)  Since the DAM can't look at *everyone* in explicit detail, I propose
that we extend the concept of advocacy beyond the NM phase and on into
maintainership.  If I were to advocate a script kiddie who actually tried
something malicious, then it should my ass, my key deleted from the
keyring, as well as the kiddie's.  I think there are other advantages to
this as well, such as encouraging a certain sense of community, maybe even
teamwork.

Also, the "strong advocate" method doesn't have to be the case for every
applicant - the DAM could continue with the process as today for folks who
couldn't find, or didn't want to tied to an advocate.

3)  A mechanism to revoke maintainership probably is necessary.  After
all, if you decide that you can't contribute to the project for a while,
why should Debian run the risk of keeping your account open.  You should
at least orphan all of your packages (hence "unregistering" your ability
to upload them) and have your machine accounts disabled.  When you're
ready to come back, given that you were worth a damn the last go around,
it should be no problem to get a DD to advocate you, and then you're back
in, contributing to the cause.  Beyond that, a delegate group of the DPL
that could exterminate the accounts of unsavories seems like a necessary
evil.  I'm not sure that we don't already have that today anyway.

4)  I'm not sure why everyone needs machine accounts.  Or for that matter,
even a d.o email address.  Sponsored maintainers seem to be able to get
along pretty well without either of these.  (At the same time, I don't see
why the email address should matter either way.)

Anyway, this thread should probably be on newmaint, so I'm cross-posting
it there.  Please follow-up on newmaint.

Cheers,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Perl Packages

[tony mancill]

On Fri, 24 Aug 2001, Martin Butterweck wrote:

> I ITP some perl modules, is there something special I have to know about
> packaging them ? Or are perl packages just like all other packages ?

Please see the Perl Policy:  http://people.debian.org/~bod/perl-policy/

Cheers,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)

Re: upload packages

[tony mancill]

On Wed, 17 Apr 2002, pp wrote:

> I make "Midgard CMS" packages from daily cvs.
> We already have sid and woody packages.
> Official existing packages   do not work
> properly , and there is no info from its maintainers
> , so how may I uplod my packages?

I would start by contacting the current Debian maintainer for these
packages.

tony

  [EMAIL PROTECTED] | Linux: because a PC is a terrible thing to waste
http://www.debian.org  |-- [EMAIL PROTECTED] put this on Tshirts in '93


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: no arch debs

[tony mancill]

On Wed, 17 Apr 2002, David H. Askew wrote:

> I am building some unofficial(for now) debs for jedit... and have
> completed building them for the x86 arch .. and I got to thinking of
> something... is it possible to build debs without a dependent arch?

Hi David,

if I understand correctly, all you need to do is set "Architecture: all"
in your debian/control file and then declare a dependency on an
appropriate interpreter.  This is what many Perl-based packages do.  In
this case, I suppose you'll have a dependency on a JVM package.

> ..since jedit is written in java ... its technically platform
> independent ... is it possible to produce debs that will install on any
> platform? and if so .. what should I read?
>
> .. if not ... Is it the infrastructure, by the way its setup via
> porters, that make this impossible .. ?

When you upload, the package won't be built on the other architectures and
will only be stored once in the archive.  The .deb will be something like:

libmath-currency-perl_0.09-1_all.deb

Don't be alarmed by the fact that the changes files references an
architecture in it's name; this is simply an indication of the platform on
which the package was built.  E.g.:

libmath-currency-perl_0.09-1_i386.changes

Hope that helps,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: Appeal to follow up on sponsor/advocate requests

[tony mancill]

FWIW, I typically respond via private email too.  Perhaps we should
resurrect http://www.internatif.org/bortzmeyer/debian/sponsor/ (which
still functions, but seems to be outdated), or try using the RFS
suggestion someone recently posted?

On Tue, 25 Jun 2002, Sean 'Shaleh' Perry wrote:

> On 25-Jun-2002 Ben Armstrong wrote:
> > Hi,
> >
> > Looking over the past month or so of debian-mentors, I'm seeing that quite a
> > number of people's appeals for sponsorship or advocacy are apparently
> > falling on deaf ears (unless these are being answered only in private
> > email).  If regulars here would periodically scan the past week or more of
> > debian-mentors archives to see if any have fallen through the cracks, we
> > could keep on top of these.  I have tried to get the ball rolling by
> > answering a couple of sponsorship requests today, but there are several
> > others with subjects containing "sponsor", "RFS", or in one case "spronsor".
> >
>
> I have answered one via private mail, the kopete maintainer.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: File a bug against my own package?

[tony mancill]

On Tue, 19 Nov 2002, Kenneth Pronovici wrote:

> While testing a patch from upstream to fix a bug in my libxmltv-perl
> package, I discovered another bug related to the package version
> for libhtml-tableextract-perl (one XMLTV script requires 1.08, the
> Debian version of the package is 1.06-2).  I've filed a bug against
> libhtml-tableextract-perl requesting that the new upstream version be
> packaged.
>
> Should I file a bug against my own package to report the related
> problem, that libxmltv-perl should depend on libhtml-tableextract-perl
> (>=1.08-1), or should I just track this on my own?  I'm thinking it
> would be nice to have a changelog entry:
>
>* Changed to depend on libhtml-tableextract-perl >=1.08 (closes: #nnn)
>
> but I'm not sure this is appropriate.

Ken,

I believe that filing a bug against your own package is appropriate,
especially when the bugreport might be useful to others.

Cheers,
tony

  [EMAIL PROTECTED] | Better the pride that resides in a citizen of
http://www.debian.org  | the world, than the pride that divides,
   | when a colorful rag is unfurled.(Peart)

Re: Warning about Debian New Maintainer Application

[tony mancill]

On Tue, 4 Feb 2003, Craig Small wrote:

> On Mon, Feb 03, 2003 at 11:10:48AM +0300, Shiju p. Nair wrote:
> > Am currently mainatains two packages ( libnet-easytcp-perl & libmng )
> > both sponsored by Tony Mancil and am interested in adopting more
> > orphaned packages. But Tony no longer responds to my email for unknown
> > reason. Its now
>
> That's a concern, Tony has been one of the more active advocates.
> Hope everything is ok.

I'm here, I've just been very slow to respond recently.  (Too many high
priority Real Life(tm) processes for the 'ole scheduler to handle without
thrashing...)  I've contacted madhu privately about sponsoring some
orphaned packages.

Cheers,
tony

  [EMAIL PROTECTED] |  An ounce of perception,
http://www.debian.org  | a pound of obscure...
   |(Peart)

Re: dpkg-signpackage

[tony mancill]

On Fri, 4 Apr 2003, Colin Watson wrote:

> On Fri, Apr 04, 2003 at 05:05:09PM +0200, A Mennucc1 wrote:
> > I would like to sponsor a package of a friend
> >
> > the first time, I (of course) check the package
> > (lintian, install it, etc etc)
> >
> >
> > but what about the next times? what is the best practice?
> >
> >
> > 1) simply resign it, and upload.
> >
> > 2) rebuild it from source each time
>
> Never sign something you haven't built.
>
> > I would prefer the 1st , for saving my time, but I have problems.
> > Is there any easy way to strip away the signature of the sponsoree
> > and sign it with mine? there used to be a 'dpkg-signpackage'
> > command, but I can't find it anymore
>
> debsign, maybe?

Just to chime in, I never sponsor anything I haven't built myself either.
I recommend getting the sponsoree to send you only the orig.tar.gz, the
diff.gz, and the .dsc file.  That way you'll know that the package builds
from source.  Then build with:

dpkg-buildpackage -rfakeroot -us -uc

Once I'm satisfied with the build, lintian/linda checks, and that the
package installs/deinstalls ok, etc., then I sign with debsign.  I just
dropped a script into ~/bin/ that should be called with the .changes
file(s) as the argument.

[EMAIL PROTECTED]:~$ cat bin/dsign
#!/bin/sh
debsign [EMAIL PROTECTED] $*

HTH,
tony

Re: The Debian Mentors Project

[tony mancill]

On Tue, 13 May 2003, Daniel K. Gebhart wrote:

> Matthew Palmer <[EMAIL PROTECTED]> wrote Tue, May 13, 2003 at 08:36:12AM 
> +1000:
> > *very* serious problem for anyone who starts relying on the binary packages
> > uploaded to m.d.n.  What sort of protections do you have in place or plan to
> > put in place to protect against this sort of thing?
>
> The mentors project is not something like apt-get.org! Hosting stable
> and safe packages is not our goal. We are responsible for the contact
> between maintainers and sponsors. Not between maintainers and users.

Appropos of this and Colin's statement, my suggestion is to make only a
deb-src URL available on the site, and to only host source packages.  For
packages destined for the Debian archive, it's critical that they be
reviewed as source, and that they build from source.  I do a fair amount
of sponsoring, and never have need for a binary of the package being
sponsored.

Cheers,
tony
<[EMAIL PROTECTED]

Re: How do you upload/build sponsored packages?

[tony mancill]

Hi Jerome,

I build like this:

dpkg-buildpackge -rfakeroot -us -uc

(actually, I use a little script called "dbuild" that tacks a $* on the
end of the line in case I need to "dbuild -sa")

Once the packages builds correctly and I've reviewed it, I use

debsign [EMAIL PROTECTED] 

(actually, another list script, dsign, that contains)

debsign [EMAIL PROTECTED] $*

Hope that helps,
tony

On Thu, 22 May 2003, Jérôme Marant wrote:

>
> Hi,
>
> When I sponsor a packages, I usually build it with :
>   debuild -m'My Name <[EMAIL PROTECTED]>'
>
> But the .changes file looks like :
>   Maintainer: My Name <[EMAIL PROTECTED]>
>   Changed-By: Sponsoree <[EMAIL PROTECTED]>
>
> I can see several sponsored packages whose .changes file
> look like:
>   Maintainer: Sponsoree <[EMAIL PROTECTED]>
>   Changed-By: Sponsoree <[EMAIL PROTECTED]>
>
> How is this possible?
>
> Thanks.
>
> --
> Jérôme Marant <[EMAIL PROTECTED]>
>   <[EMAIL PROTECTED]>
>
> http://marant.org

Bug#838749: RFS: csvjdbc/1.0.31-1 [UPLOADED]

[tony mancill]

On 09/24/2016 02:27 AM, Christopher Hoskin wrote:
> Package: sponsorship-requests
> Severity: normal
> 
>   Dear Mentors,
> 
>   I am looking for a sponsor for my package "csvjdbc"

Hi Christopher,

Thank you for the update. Uploaded.

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Re: Scala 2.10

[tony mancill]

On Thu, Nov 10, 2016 at 11:39 PM, Gianfranco Costamagna
 wrote:
>>I'm not in the Java packaging community, but from a little searching
>>.m2 appears to be created by the Maven build system, and I know for
>>sure there is software packaged in Debian that uses Maven, so maybe
>
>>you'd want to take a look at those packages how they do their build.
>
> I'm far from being a java expert, but IIRC maven tries to download from
> internet or create such directories when a dependency is not available.
>
> Solution: package it, and add it to control file, and try again.

For Marko's purposes, which IIRC, are to create a non-free package to
avoid the circular dependency scala has upon itself, packaging all of
the build dependencies isn't strictly necessary.  However, the source
package must contain all of the bits required to build the desired
binary package(s), either as dependencies on other Debian packages or
(and only for a non-free package) as JAR files included with the
source package.

As Christian points out, Maven will happily attempt to download
dependencies.  For a non-free Java package, those Maven Central
dependencies need to be available on the local file system and all
references to them updated to use  scope and the path where
they can be found.  (There might be an easier way to accomplish this,
but this is the one I'm familiar with.)

Cheers,
tony

Bug#784831: RFS: gnash/0.8.11~git20150419-1~bpo8+1 [1st upload to bpo]

[tony mancill]

On 05/09/2015 03:46 AM, Gabriele Giacone wrote:
> Package: sponsorship-requests
> Severity: normal

Hi Gabriele,

I have built against jessie-backports and uploaded the package.
Thank you for the update.

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Bug#934939: RFS: xlog/2.0.17-1

[tony mancill]

On Sat, Aug 17, 2019 at 12:12:02AM +0200, Ervin Hegedüs wrote:
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "xlog"
> 
>  * Package name: xlog
>Version : 2.0.17-1
>Upstream Author : Andy Stewart KB1OIQ 
>  * URL : http://savannah.nongnu.org/projects/xlog
>  * License : GPL
>Section : hamradio
> 
> (snip)
>
> Changes since the last upload:
>   * Team upload.
>   * New upstream release (Closes: #925864).
>   * Bump Standards-Version to 4.4.0.

Hello Ervin,

I didn't come across this sponsorship request until after I uploaded an
update to the xlog package.  My update didn't include the newer upstream
version, so I will work on getting your update uploaded to the archive.

One comment about the changes in your package... Standards-Version 4.4.0
[1] includes a recommendation to use the dh sequencer in debian/rules,
which has not been done yet.  I'm happy to work with you on this if
you're interested; otherwise I plan to do it before the next upload.  If
you have a Salsa account or would like to create one, we now have a
packaging repo [2], which will make easier to collaborate via merge
requests, etc.

Cheers,
tony

[1] 
https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-4-0
[2] https://salsa.debian.org/debian-hamradio-team/xlog


signature.asc
Description: PGP signature

Bug#934053: RFS: fwlogwatch/1.4-2

[tony mancill]

On Tue, Aug 06, 2019 at 10:12:08AM -0300, William Grzybowski wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> fwlogwatch (1.4-2) unstable; urgency=medium

Hi William,

Thank you for helping with fwlogwatch.  I've taken a look at your
updated package and things look really good.  I noticed a couple minor
issues in the manpage I wanted to suggest you address before we upload.

- The configuration file is found in /etc/fwlogwatch/fwlogwatch.config,
  not in /etc/fwlogwatch.config.

- The pid file is now in /run/fwlogwatch.pid, not /var/run/fwlogwatch.pid

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1025274: Bug#819332: License question about sf2 soundfont in Tuxguitar

[tony mancill]

On Sun, Jan 15, 2023 at 10:02:55PM +0100, Helmar Gerloni wrote:
> > https://lists.debian.org/debian-legal/2023/01/msg5.html
> > https://lists.debian.org/debian-mentors/2023/01/msg00097.html
> Roberto, Tobias, thanks for your answers.
> 
> I have removed MagicSFver2.sf2 from the package and added a note to 
> README.Debian.
> The new package now depends on fluid-soundfont-gm, see
> https://mentors.debian.net/package/tuxguitar/
> 
> The package builds and runs on amd64 and in Qemu for arm64. It looks pretty 
> good to me now.
> Maybe someone can take a look and upload it?
> If there is anything more I can do, just let me know.

Hello Helmar,

I am reviewing the updated package now and will either sponsor an upload
if everything looks good or provide feedback.

Thank you!
tony


signature.asc
Description: PGP signature

Bug#1025274: Bug#819332: License question about sf2 soundfont in Tuxguitar

[tony mancill]

On Mon, Jan 16, 2023 at 08:33:07AM -0800, tony mancill wrote:
> On Sun, Jan 15, 2023 at 10:02:55PM +0100, Helmar Gerloni wrote:
> > > https://lists.debian.org/debian-legal/2023/01/msg5.html
> > > https://lists.debian.org/debian-mentors/2023/01/msg00097.html
> > Roberto, Tobias, thanks for your answers.
> > 
> > I have removed MagicSFver2.sf2 from the package and added a note to 
> > README.Debian.
> > The new package now depends on fluid-soundfont-gm, see
> > https://mentors.debian.net/package/tuxguitar/
> > 
> > The package builds and runs on amd64 and in Qemu for arm64. It looks pretty 
> > good to me now.
> > Maybe someone can take a look and upload it?
> > If there is anything more I can do, just let me know.
> 
> Hello Helmar,
> 
> I am reviewing the updated package now and will either sponsor an upload
> if everything looks good or provide feedback.

The update looks great!  I have updated debian/copyright to document
the files that are licensed under a license other than the LGPL, but
otherwise everything looks good.  I will upload today.

For the time-being, I will push the updated sources and tag to the
current java-team repo [1], but we may want adjust that before the
bullseye release since the package is no longer team-maintained.

Thank you for your work on this!
tony

[1] https://salsa.debian.org/java-team/tuxguitar

Bug#1029186: reply: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules

[tony mancill]

On Fri, Feb 03, 2023 at 07:55:08AM +, min sun wrote:
> 
> Hi mentors!
> 
> I packaged  new version of  libcommons-validator [1] and uploaded again to 
> debian mentors[2], please refer to Upload #2 .

Hi!

I will review and sponsor the upload soon.  Thank you for your
contribution to Debian!

Cheers,
tony

Bug#1031123: RFS: libcommons-collections4-java/4.4-1 [Team] -- Apache Commons Collections - Extended Collections API for Java

[tony mancill]

On Sun, Feb 12, 2023 at 03:43:05PM +0100, Hilmar Preuße wrote:
> Am 12.02.2023 um 07:54 teilte min sun mit:
> 
> Hi,
> 
> > To access further information about this package, please visit the 
> > following URL:
> > 
> >https://mentors.debian.net/package/libcommons-collections4-java/
> > 
> If you look at that link you'll see a few things, which should the
> resolved. At least the distribution name has to be changed from
> UNRELEASED to the desired value.

As a sponsor, I find it helpful when the distribution name is left as
UNRELEASED in a sponsor request.  It makes it easier to manipulate the
changelog with `dch` while preparing the package for a sponsored upload. 

But as Hilmar notes, the other checks on that page should be addressed.
Specifically:

- fix debian/watch so the local version 4.4 matches upstream 4.4
- update the standards version
- update the debhelper dependency

Cheers,
tony


signature.asc
Description: PGP signature

Re: New upstream version 1.6.6 of tuxguitar available on salsa

[tony mancill]

Hello Helmar,

On Fri, Jan 03, 2025 at 11:47:15PM +0100, Helmar Gerloni wrote:
> I just uploaded version 1.6.6 to salsa:
> 
> https://salsa.debian.org/helger/tuxguitar
> 
> Maybe you can push this new version into Sid?

I review and sponsor the upload of 1.6.6.

> Just let me know if you want me to create a merge request on salsa, upload 
> the new version to mentors or if I can help in any other way.

Can you push the updated source package to mentors?  (I cloned your repo
from Salsa, but didn't see updates on the pristine-tar or upstream
branches.  I think new upstream versions are somewhat easier via mentors
anyway.)

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1094600: RFS: tsctp/0.8.1-1

[tony mancill]

On Thu, Jan 30, 2025 at 05:53:11PM +, Phil Wyett wrote:
> I believe 'tsctp' is ready for review/possible sponsorship. Could a Debian
> Developer (DD) with available free time, please review this package and upload
> if you feel it is ready.

I have sponsored the upload.

Phil, thank you for the review.  
Thomas, thank you for the contribution to Debian.

Cheers,
tony


signature.asc
Description: PGP signature