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]

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: 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: 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 r...@ringlet.net  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 r...@ringlet.net 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: 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

snip

 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]

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 ref 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: 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: 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: 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]

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: 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 dpoliv...@gmx.de
 * 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/ 
 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 http://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

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]

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.|  http://www.debian.org
   (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: 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: 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

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: 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: 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: 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: 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] changes file

(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

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)

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.
http://www.samba.org  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: 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]

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

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#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#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