Re: f.el dependency loop (was: Re: Cask & dependencies)

[David Bremner]

Sean Whitton  writes:

>
> 3) Disable running f-el's test suite at package build time, but supply a
>autopkgtest so the tests will still get run in ci.debian.org.
>
> 4) Disable running undercover.el's test suite at package build time, but 
> supply a
>autopkgtest so the tests will still get run in ci.debian.org.
>
> What would be best?  Options (3) and (4) avoid introducing a new
> bootstrapping loop into the Debian archive.  But on the other hand maybe
> such a bootstrapping loop is okay because all these packages are
> architecture independent.

My initial opinion is to avoid a bootstrapping loop. That might be
partially because I've never really used build profiles before, but also
it seems to more or less double the number of sponsored uploads you'd
need.

d

Re: Cask & dependencies

[David Bremner]

Sean Whitton  writes:
>
> After:
> ,
> | EMACSFLAGS = -L /usr/share/emacs/site-lisp/dash-el \
> | -L /usr/share/emacs/site-lisp/elpa-src/noflet-*
> | test :
> | $(EMACS) --no-site-file --no-site-lisp --batch \
> | $(EMACSFLAGS) \
> | -l test/run-tests
> `
>
> Is this the best way to work around upstream's usage of Cask?
>

It seems like a reasonable idea to me. Although I'm not really familiar
with cask, if I understand correctly, it's mainly about providing a
controlled test environment? This we can do via chroots.

d

Minutes from Getting your packages into Debian

[David Bremner]

Hi all;

Here are the minutes from the (apparently) annual mentors-bof, thanks
to Didier Raboud for taking them. It turned into a bit more of a
tutorial session than last year, which I don't think is necessarily a
bad thing. I also attach the LaTeX source for the slides; a pdf is
available (somewhere) on penta.debconf.org.

===

QUOTE: Bremner: Gobby is not emacs, it's so sad.

Some statistics:

* 18790 packages are in Sid, amongst which 3036 are non-NMU sponsored
 packages. If you use Debian, you are probably needing one of those;
 you probably rely on any of them.  946 active DDs, 178 DMs, 906
 sponsored people.

OPINION: Bremner: There's a high barrier to be able to upload packages
without a key in the /magic keyring/.

OPINION: Bremner: Know packaging, love packaging, do packaging. This
amount of work is the tiny part of getting packages sponsored.

Bremner: sponsoring as a source for new contributors, not only about new
packages; most of actual DDs have come to Debian trough getting packages
sponsored, this shouldn't be underestimated as a source of future DDs.

Bremner: There are DDs that sponsor, others that don't, various reasons
undermine this.

== The big picture ==

There is sort-of a command-line shock: debian-mentors{.*} is not
anywhere close to Launchpad™.

The Mighty Steps to Getting My Package Uploaded:

* Prepare (Close your browser, open a terminal, Gh !? )
* ITP (for new packages, reportbug wnpp)
* go package (get help from #debian-mentors, feedback on your
   ITP[probably not positive].
* upload (well, sort-of) to mentors.debian.net : Upload, QA check, …
* File a Request For Sponsoring (RFS) against sponsorship-requests. 
\o/ BTS fun
* Wait, Revise, Wait, Revise, More Wait. This time the feedback is most 
probably positive.
* Your Package Gets Uploaded™ (or not…)

== What packages belong in Debian ? ==

It recently came as a surprise to some that someone wants a new package
to Debian but it might very well be that `Debian doesn't want it`…

ITP serves three roles:
* Sanity check incoming packages
* First contact of new contributions with the Debian community
* Mutex to avoid multiple people working on the same
  thing. (less important in sponsoring context)

The perception of ITP depends on the side: the filer says here's the
work I did, I propose it to Debian, while debian-devel (if that
exists) understands it as here's a new package `Debian` will have to
maintain.

Closing RFS's is another (fairly rarely used) feedback mechanism: make
sure feedback is given out soon enough.

== Tracking sponsorship requests in the BTS ==

After this experiment started, there has been been a lot more noise on
the mailing list, but is planned to be improved.

* 28 RC bugs fixed, 172 updates, 69? new packages; quite a successful
  experiment.

== Discussion ==

Q: Bottleneck in those steps ^ ? A: Not enough sponsors.

I: Teams are not an administrative barrier, they are probably a resource.

Q: Maybe we are not communicating / enforcing the needed commitment for
new packages: in fact, the lifetime of a package is in measured in
multiple years (unstable-testing-stable-security- …).

I: Removal of packages doesn't only carry a /technical/ cost, it does
carry a human cost too (users, …).

Q: Do the packages need to be in english? A: Not necessarily, but
description and copyright probably need both for sponsors and
FTP-Masters team.

\documentclass[presentation]{beamer}
\usetheme{default}
\usepackage[utf8]{inputenc}
%\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\AtBeginSection[]
{
  \begin{frame}beamer
\tableofcontents[currentsection]
  \end{frame}
}

\tolerance=1000
\providecommand{\alert}[1]{\textbf{#1}}
\newcommand{\notes}[1]{\par\vfill\small\textbf{Notes:} #1}
\newcommand{\recipebutton}[1]{\hyperlink{#1}{\beamergotobutton{#1}}\hypertarget{back:#1}{}}
\newcommand{\recipe}[1]{\hypertarget{#1}{}\hyperlink{back:#1}{\beamerreturnbutton{back}}}
\title{Getting your packages into Debian}
\author{David Bremner}
\titlegraphic{based on notes by Asheesh Laroia, Arno Töll, 
  and Nicolas Dandrimont, shameless cribbing from mailing lists, and stuff I just made up}
\date{9 July 2012}
\usecolortheme{rose}
\begin{document}

\begin{frame}
  \maketitle
\end{frame}

\begin{frame}
  \frametitle{This is not a lecture}

  \begin{block}+-{What's it about?}
Getting packages \emph{sponsored}, i.e uploaded Debian for people
without keys in the uploading keyring.
  \end{block}

  \begin{block}+-{What's the plan?}  I have some slides to fill the
awkward silences. It would be great if I \emph{fail} to make it to
the end of my slides, because we find more interesting things

Bug#661309: RFS: task-spooler/0.7.3-1 [ITP]

[David Bremner]

Alexander Inyukhin shur...@sectorb.msk.ru writes:


 Changes from previous package version:
  * priority changed to optional;
  * fixed memory leak (cppcheck warning).

Sounds good, I'll have a (hopefully final) look at this today.

d



-- 
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/87sjdez8ft.fsf@zancas.localnet

Bug#661309: RFS: task-spooler/0.7.3-1 [ITP] (fix policy violation)

[David Bremner]

Alexander Inyukhin shur...@sectorb.msk.ru writes:

 On Sun, May 27, 2012 at 11:12:04AM -0300, David Bremner wrote:
 David Bremner brem...@debian.org writes:
 
  I'll have a look at this.
 
 I sent a separate mail about some warnings from cppcheck and
 compilation. These might not be blockers, but the following is, your
 package currently violates policy 10.1
 
 The conflict is resolved by renaming ts to tsp.


The packaging looks OK now (at least I didn't find any problems). You
should probably choose priority optional rather than extra. Did you have
a chance to discuss those cppcheck warnings with upstream?

David



-- 
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/87d352afi0.fsf@zancas.localnet

Bug#676218: RFS: ustr/1.0.4-3 [RC] -- enable hardening flags and multiarch

[David Bremner]

Václav Ovsík vaclav.ov...@i.cz writes:

 Package: sponsorship-requests
 Severity: important

Does the RC in your subject refer to release critical? If so, what RC
bug does this close?

d



--
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/87vcj5u8ba.fsf@zancas.localnet

Re: RFS: new powertop version

[David Bremner]

Julian Wollrath jwollr...@web.de writes:

 I prepared a new version, which keeps the changes in the rules minimal but 
 since upstream changed the building process a little bit, minimal changes 
 were 
 needed to get it build. The massive changes of the copyright file were also 
 needed so that it would be machine readable according to the specifications 
 in 
 http://dep.debian.net/deps/dep5/.

This kind of change (changing the copyright file format) is not usually
acceptable in an NMU, unless cleared with the maintainer.  Although many
maintainers consider the use of the machine readable format to be a best
practice, it does not have the force of policy, and the absence of
machine readable formatting of debian/copyright is at most wishlist bug,
i.e. something that the submitter might like, but the maintainer might
or might not agree is an improvement.

Note that while it is not especially likely, it is possible to introduce
release critical bugs (violations of policy musts) by editing of
debian/copyright.  For more information, see section 12.5 of Debian
policy.

Pretty much the same thing holds for changing packaging formats from 1.0
to 3.0 (quilt), which you did not do here, but is a common beginner
mistake in NMUs.

Thanks for your efforts, and don't get too discouraged, more experienced
contributors make similar mistakes.

David


pgp4rKNx6oXKM.pgp
Description: PGP signature

Bug#661309: RFS: task-spooler/0.7.3-1 [ITP] (new upstream)

[David Bremner]

Alexander Inyukhin shur...@sectorb.msk.ru writes:

 Dear mentors,

 I am looking for a sponsor for my package task-spooler
 It builds those binary packages:

   task-spooler - personal job scheduler

I'll have a look at this.

Alexander, please fix the expiry date on your gpg key; either make a new
key or bump the expiry date on the one you have. The latter will
preserve the signature, although since I couldn't retrieve key 
53487F0A, that might not matter.

d



-- 
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/87zk8t3ibj.fsf@zancas.localnet

Re: Bug#661309: RFS: task-spooler/0.7.3-1 [ITP] (new upstream)

[David Bremner]

David Bremner brem...@debian.org writes:

 I'll have a look at this.

I sent a separate mail about some warnings from cppcheck and
compilation. These might not be blockers, but the following is, your
package currently violates policy 10.1

  Two different packages must not install programs with different
  functionality but with the same filenames.

( http://www.debian.org/doc/debian-policy/ch-files.html#s-binaries )

In particular your package ships /usr/bin/ts, which is also present in
moreutils.

Note that conflicts are not appropriate to resolve this problem; it is
perfectly plausible for people to want both moreutils and task-spooler
installed.

Since your package is the new one, the obvious thing is for you to
rename your version. I leave that to you and Joey Hess (the moreutils
maintainer) to sort out.

d


-- 
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/87vcjh3e8b.fsf@zancas.localnet

Re: RFS: new powertop version

[David Bremner]

Julian Wollrath jwollr...@web.de writes:

 Dear mentors,

 I am looking for a sponsor for a new version of the package powertop, which 
 closes several bugs (e.g. bug #672555). I do this since there was no reaction 
 from the maintainer regarding my patches which fix bug #672555 and would like 
 to see the new version of powertop in Debian.


Did you know about 


http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

It outlines the best practices for dealing with an unresponsive
maintainer.

See also 

  
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines

which discusses when and how to do non-maintainer uploads (which is what
you are proposing).

Since you probably don't have access to the mia database, I can tell you
that Patrick's last activity was in November of 2011.

You should also note that there is a release critical bug on powertop;
you should make sure your proposed upload fixes this.

d


-- 
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/87d35quarb.fsf@zancas.localnet

Re: Getting rid of control messages revisited

[David Bremner]

Gergely Nagy alger...@balabit.hu writes:

 That sounds like a good idea, though closing mails would be useful on
 -mentors@ too, not sure whether that counts as bug traffic or
 control. But that's just a nice to have thing, in my opinion, one can
 always manually subscribe to interesting RFS bugs anyway.


People also have the option of CC'ing mentors with control messages
thought to be of general interest (closing without sponsoring springs to
mind).

I'm in favour of this plan also, assuming the PTS works like we hope.

d


-- 
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/87wr41d37u@convex-new.cs.unb.ca

Bug#670589: RFS: newlisp/10.4.0-4 ITP

[David Bremner]

Nathan Owens ndow...@gmx.us writes:

 Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]
   * Package name: newlisp
 Version : 10.4.0-4
 Upstream Author : [fill in name and email of upstream]
   * URL : [fill in URL of upstreams web site]
   * License : [fill in]
 Section : lisp

I hope you put more care into the packaging than you did into filling
out this template.




-- 
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/87pqatv0ct.fsf@zancas.localnet

Bug#670589: RFS: newlisp/10.4.0-4 ITP

[David Bremner]

David Bremner brem...@debian.org writes:

 Nathan Owens ndow...@gmx.us writes:

 Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]
   * Package name: newlisp
 Version : 10.4.0-4
 Upstream Author : [fill in name and email of upstream]
   * URL : [fill in URL of upstreams web site]
   * License : [fill in]
 Section : lisp

 I hope you put more care into the packaging than you did into filling
 out this template.

OK, I admit that sounds a little harsh. But the questions are there for
a reason, and without them filled in, the message is pretty much content
free. So please think about the time of your many readers as well.

Cheers,

David.



-- 
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/87mx5xuzoz.fsf@zancas.localnet

Re: RFS: open-axiom/1.4.1+svn~2626-1

[David Bremner]

Игорь Пашев pashev.i...@gmail.com writes:

 Package: sponsorship-requests
 Severity: normal

 Dear mentors,

   I am looking for a sponsor for my package open-axiom


I will have a look at this.

d


--
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/874ns9xqmg.fsf@zancas.localnet

DMUA, again.

[David Bremner]

On Tue, 27 Dec 2011 21:58:39 +0700, Mahyuddin Susanto udi...@ubuntu.com wrote:
 Dear mentors,
 
 I am looking for a sponsor for my package gkamus.
 
  * Package name: gkamus
Version : 1.0-1
Upstream Author : Ardhan Madras aj...@knac.com, Firmansyah
 leonard_gims...@yahoo.com

Hi, nothing personal about this package or maintainer, but I have to
state again that in my opinion it is almost never correct to upload a
package for the first time with DMUA set, and certainly never correct to
do so for a maintainer that the uploader does not know well. My
interpretation of the DM structure is that the DD doing the upload needs
to assess the DM's ability to maintain *that particular package*. I can
(maybe) imagine that being possible for a maintainer that the DD knows,
and package similar to other packages already maintained by that
maintainer, but I am puzzled by generic requests for sponsorship with
DMUA: yes.

David


pgp0aAnEH10aP.pgp
Description: PGP signature

Re: NMU done but unresponsive maintainer

[David Bremner]

On Fri, 09 Dec 2011 10:58:20 +0100, Alexander Reichle-Schmehl 
toli...@debian.org wrote:

 I'm sorry, but personally I don't like to sponsor your NMU.
 
 Some of the reasons are:
 
 * Only fixing a wishlist bug, nothing else
 * The wishlisht bug is a new version not detailing why the new version
 is needed
 * No apparent consent of the maintainer for the NMU

I agree with the first two points. But I think the third is OK, according
to Emilien's previous message, the maintainer did bless the NMU.

d


-- 
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/871useuefk.fsf@zancas.localnet

Re: RFS: open-axiom - new release

[David Bremner]

On Thu, 17 Nov 2011 00:36:55 +0400, Игорь Пашев pashev.i...@gmail.com wrote:
 Dear mentors,
 
 I am looking for a sponsor for my package open-axiom.
 
  * Package name: open-axiom
Version : 1.4.1+svn~2470-1

I'll have a look at this. Igor: do you want to roll another svn
snapshot?

d


--
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/87iplwugna.fsf@zancas.localnet

Re: RFS: parcellite 1.0.2~rc5-1 (updated package)

[David Bremner]

On Wed, 14 Sep 2011 19:53:20 -0400, Andrew Starr-Bochicchio 
a.star...@gmail.com wrote:
 Hi all,
 
 I'm looking for a sponsor for my package parcellite. I would also
 appreciate it if the sponsor would set the DM-Upload-Allowed field.

I might be stricter than some, but for me this is a no-go.  According to
my interpretation of the DM process, this flag should only be set by a
sponsor that is familiar with your work and has confidence that you can
maintain the package without supervision. I don't think one upload is
enough to know this.

d


-- 
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/87fwjyo8u8.fsf@zancas.localnet

Re: RFS: lcmaps

[David Bremner]

On Mon, 12 Sep 2011 00:36:53 +0200, Dennis van Dok denni...@nikhef.nl wrote:
 lcmaps-basic-interface - LCMAPS header files for plug-in development
  lcmaps-globus-interface - LCMAPS header files for plug-in development
  lcmaps-openssl-interface - LCMAPS header files for plug-in development
  liblcmaps-dev - LCMAPS development libraries
  liblcmaps0 - Grid (X.509) and VOMS credentials to local account mapping

Hi Dennis, 

Thanks for the contribution, but what is it?

Seriously, you are more likely to attract sponsor interest if you give
at least the package long description in your RFS.  Perhaps the short
descriptions could be improved as well.

d



pgpd0RPHRIrrO.pgp
Description: PGP signature

Report from the debconf11 sponsoring/mentors BoF.

[David Bremner]

This report started as a summary from the sponsorship BoF held during
Debconf 11 in Banja Luka.  The full video stream is available on [0].
These were the major points, as interpreted by Arno Töll and David
Bremner.  As it was being written up, a few relevant things happened
with debexpo (mentors.debian.net) and/or were discussed on the list,
so we added some pointers to those as well.

Q: Why does Debian sponsor uploads?
- ---

Many present agreed that the main reason to sponsor uploads is
training.  New contributors need experience and training to get
packages in shape. Therefore the mentoring process can be seen as
incubator to develop new (uploading) Debian developers. One impression
to support this is that as new contributors tend to package software
for a fairly narrow target group.

On the other hand, several people outlined the technical benefit of
sponsoring packages, which is to get new software (typically that the
sponsors themselves consider useful or interesting) into Debian.
Similarly sponsors upload packages which have been orphaned by the former
maintainer.

Debian has several teams, at least some of which are highly effective
at mentoring, and all of which have more specialized expertise than
the debian-mentors mailing list.  In principle the mentoring process
should generally endorse people to join existing teams. This is
mutually beneficial, as new contributors learn best practices and
workflows while helping with the workload of teams.  Unfortunately
apparently [1] only 20% of all RFS requests appear to be related to
the work of existing teams.

Q: How are we doing, what could we improve?
- ---

Several problems were identified with mentoring process (or with the
experience of mentees). Broadly speaking these are in the (overlapping)
areas of making connections with sponsors, getting feedback, and
variability/fairness.

There was some discussion about how people have succeeded in finding
sponsors, and how sponsors like to be found. One or two people
mentioned only succeeding because of a pre-existing social
relationship. Most, but not all, sponsors preferred email over IRC as
a contact point.

Lack of feedback in the mentors process is a problem for several
reasons.  The current mentors process has a fairly large degree of
uncertainty.  Often it is unknown to sponsorees how they are doing as
there is no (visible) progress or feedback at all. This is
discouraging for new contributors.  In fact the mentors FAQ already
gives some ideas about what to do in this case (ask on IRC, ask again,
and so on). It isn't clear how much people read this FAQ, maybe some
automatic messages could be generated from mentors.debian.net with
hints about future steps.

Another, quite different problem with the mentors process is that it
seems based on the false assumption that every package belongs to
Debian.  Many packages are either too immature or don't add anything
really new to Debian.  We should be willing to tell people this,
rather than politely ignoring packages and hoping they go away.

Debian is supposed to be Do-ocracy, in particular as many decisions
as possible are left to the individual developer. From the sponsoree
perspective the result is a bit chaotic: they hear different stories
about what is mandatory and what is suggested. There is also the
element of developer taste, which varies widely in terms of what
software they find interesting and worthwhile.  This can result in a
high quality package providing software for special interests gets
lost, while a less good package but targeting a more popular area of
interest is sponsored. There was no concensus about whether it was
possible (or desirable) to change these subjective aspects, but see
below for a technical proposal about matching packages and sponsors.

Recently, Michael Gilbert asked to switch the reviewing part of the
mentoring process to the Debian Bug Tracking Systems (BTS) [2]. If you
are sponsoring packages or being a sponsored maintainer, please tell
us your opinion here, as there are possible improvements over the
current procedure observable, as well as concerns. Help us to find
the best solution.

Q: Should there be a mentors team, or some other structure?
- ---

The discussion, whether there should be a mentors team can be seen
From two perspectives. First, one could see it as team which looks for
lost and lonely packages, and sees as last resort, whether it could
be uploaded to Debian. Generally this idea did not seem to attract many
persons in the audience.

Alternatively, this could be seen as collaborative maintenance team,
similar to the QA team (including its drawbacks), where sponsors and
maintainers get together to collectively improve packages. Some people
casted doubts on this idea as well, mentioning the QA team as refer-
ence, where everyone but effectively nobody feels responsible

Re: How to get a package into experimental

[David Bremner]

On Thu, 8 Sep 2011 15:28:03 +0200, Christo Buschek cr...@30loops.net wrote:

 production and it adds lots of features I wouldn't wanna miss, especially the
 implementation of the TPROXY protocol. I was wondering if its possible and if
 it makes sense to upload my packages for this dev version to experimental, to
 make the packages already available for users.

There is no problem in principle with sponsored uploads for
experimental. Of course, it isn't any easier than getting sponsors for
unstable. I would start by talking to whomever uploaded your package to
unstable.

d


-- 
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/87zkif15yb@convex-new.cs.unb.ca

Re: RFS: open-axiom

[David Bremner]

On Sun, 04 Sep 2011 12:54:43 +0400, Igor Pashev pashev.i...@gmail.com wrote:
 03.09.2011 19:22, David Bremner пишет:
 1. Is it ok to use different lisps on different archs?
Or is it better to wait for sbcl (in lenny there were many archs) ?

Yes, that is OK. 

 
 2. I set build-dep to sbcl = 1.0.30, but I see sbcl has an epoch.
Should I change it? sbcl =2:1.0.30 (wheezy and sid have 2) ?

no, you don't need the epoch.

I pushed some things to

  http://pivot.cs.unb.ca/git/?p=open-axiom.git;a=summary

you might find interesting.

upstream   has the upstream tarball imported 
pristine-tar   is auxilary data for the pristine tar utility
master has one patch to fix a lintian warning
build  has merged debian packaging and upstream source.

It's up to you how you want to organize things, but I personally find it
most convenient to work with a branch like build and commit directly
there, after merging in the new upstream release. Most of my packaging
repos have such a branch as master. Most of the tools like gitpkg and
git-buildpackage expect such a branch.

Of course it costs a bit of diskspace to store the upstream source as
well, but github won't complain about 86M. And if they do you can always
use alioth.debian.net

Oh, and for next upload please add Vcs-Browser and Vcs-Git headers

d






--
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/87hb4swf33.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Sun, 04 Sep 2011 11:35:12 -0300, David Bremner brem...@debian.org wrote:
  2. I set build-dep to sbcl = 1.0.30, but I see sbcl has an epoch.
 Should I change it? sbcl =2:1.0.30 (wheezy and sid have 2) ?
 
 no, you don't need the epoch.

I have been corrected on IRC that indeed the epoch is necessary.

d


-- 
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/87bov0wac4.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Mon, 05 Sep 2011 00:02:27 +0400, Igor Pashev pashev.i...@gmail.com wrote:

  Oh, and for next upload please add Vcs-Browser and Vcs-Git headers
 Is it ok to use github or whatsoever for this?

I think this is not well codified within Debian at the moment, but I
would say the corporate nature and non-free software aspect of github
make some of us a bit uncomfortable.

Probably the least controversial procedure is to get an account on
alioth.debian.org, and join the collab-maint project. I suppose it
should be possible to mirror a github repository into alioth if you
wanted to work that way.

d


pgpXy8tvVgeo2.pgp
Description: PGP signature

Re: RFS: open-axiom

[David Bremner]

On Sat, 03 Sep 2011 16:07:39 +0400, Igor Pashev pashev.i...@gmail.com wrote:
 I have upload new version without
  ./contrib and ./src/include/xpm.h.
 
 The latter is going to be removed in upstream,
 that file is from very old Axiom version.
 
 ./contrib is not used now and has unclear license mess:
 ./contrib/texmacs/COPYING says about GPL-3,
 but sources are BSDL or GPL (1?).

I guess that makes sense to me about contrib. It might be possible to
fix by asking upstream for clarification what that COPYING file is meant
to apply to.

Removing xpm.h alone would not be a good reason to repack (although
here, there is no real pristine upstream tarball), but since you are
repacking anyway, OK.

I'm rebuilding as we speak. By the way, parallel build support would be
nice ;).

d


-- 
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/87ehzxyf71.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Sat, 03 Sep 2011 18:34:23 +0400, Igor Pashev pashev.i...@gmail.com wrote:
 
 What about other architectures (i386, alpha, powerpc, etc)?
 Do I need another sponsor? :-)
 How much time does it take for package to appear in repo?
 

Other architectures will be built on the autobuilder network, all going
well.  For the second question, it depends how long the package takes to
pass through NEW. It is usually pretty quick these days, but it could be
a week (or longer if the ftp-masters get busy).

d




-- 
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/871uvxy7ki.fsf@zancas.localnet

Re: RFS: task-spooler

[David Bremner]

On Fri, 2 Sep 2011 00:39:07 +0400, Alexander Inyukhin shur...@sectorb.msk.ru 
wrote:
 * Package name: task-spooler
   Version : 0.7.0-1~rc1
   Upstream Author : Lluís Batlle i Rossel vi...@vicerveza.homeunix.net
 * URL : http://vicerveza.homeunix.net/~viric/soft/ts/
 * License : GPLv2+
   Section : misc

Hi Alexander;

Thanks for working on task-spooler. I have used it before and found it
pretty useful.

Some comments

 - you miss Gentoo Foundation as copyright holder for the ebuild files

 - your version number is odd. If your package is ready for upload
  (in your opinion) it should have a version like 0.7.0-1

 - I have a vague memory of this being discussed before, but I can't
   find the discussion now.  As far as I can tell, there are several
   ways in which the socket setup could be improved.

   - I don't really understand why the permissions on
 /tmp/socket-ts.$uid are group and world readable.

   - having the socket in world writable location makes ts
 vulnerable to a denial of service attack.

   wouldn't it be better to put the socket in a mode 0700 directory
   e.g. in the users home directory?

David   


--
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/87ippazc22.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Tue, 30 Aug 2011 16:17:30 +0400, Igor Pashev pashev.i...@gmail.com wrote:

 I saw this message after making symlink
 /usr/lib/open-axiom/share/hypertex - /usr/share/open-axiom/hypertex
 And can't reproduce it after purging old version
 and clean install of new version.

OK, for first upload this is fine.

As you probably read in your email by now, I have uploaded the current
version. You will have to wait for the ftp-masters to approve (or not)
the new package(s) for the archive.  Feel free to contact me directly
for future versions.

One thing I noticed while testing is that the default fonts in hyperdoc
are quite bad (super-pixelly) on my system. I think this is because they
are probably set to nonexistant (at least on my system). Things got a
bit better when I over-rode to use e.g. 

OpenAxiom.hyperdoc.RmFont: lucidasans-14

in my .Xresources

Maybe for the next upload you could investigate a bit, and possibly
include some hints or a template .Xresources.


d


-- 
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/87y5yaxsat.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Mon, 29 Aug 2011 20:26:22 -0400, Joseph R. Justice jayare...@gmail.com 
wrote:

 Or, is this incorrect, and if so what needs to be done and/or who
 needs to be aware of this connection between OpenAxiom and SBCL such
 that if if there *is* a fix to SBCL that needs to be incorporated into
 OpenAxiom also, it will be duly incorporated into OpenAxiom either
 automatically and/or through manual actions being taken by whomever
 needs to take them?

This is not the first Common Lisp application in Debian, nor is Lisp the
only language that includes a run time system in the resulting
executables (as far as I know, most (all?) of the Haskell libs in Debian
are static because until recently that is all ghc could deal with). It
isn't ideal, but we can deal with problems as they arise. There is a
mechanism to rebuild packages when needed (binNMU). If a problem is
discoved in one of the compilers (I'm not aware of an instance of this,
but I did not research it) then a script like build-rdeps (in package
devscripts) can find the packages which need to be rebuilt.

d


-- 
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/87vctexr5d.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Sat, 27 Aug 2011 23:01:12 +0400, Игорь Пашев pashev.i...@gmail.com wrote:

 I have fixed all lintian issues, except two:
 1.  image-file-in-usr-lib (e. g.
 usr/lib/open-axiom/share/hypertex/bitmaps/anna_logo.xbm)

Hmm. This should be fixed eventually, but if it will be fixed upstream
anyway, it is probably more sensible to wait for that fix. In the
meantime, I think we can live with it. I know that racket had a few
hundred of these before I did the symlink trick.  Maybe others feel
differently about the severity of this problem.

You should probably investigate whether the fasl files are architecture
independant (i.e. can work on arm, mips, sparc and friends). In that
case, it will be worthwhile splitting out an open-axiom-common
architecture independent package.  This only needs to be build (and
stored) once. On the other hand, the fasl files may depend tightly on
the machine architecture.

 2.  unusual-interpreter + script-not-executable (e. g.
 usr/lib/open-axiom/algebra/D02EJFA.fasl)

[...]

 The second is a feature of SBCL: *.fasl files are compiled lisp code,
 and they must have a special header. Changing shebang makes SBCL core
 contains an illegal byte in the FASL header at position 0: Expected 35, got
 10.

The literal error message complains because the file does not start with
#. Maybe you have a blank line before # FASL? I'm no common lisp expert though.

As far as I understand, the #! is added by sbcl to permit fasl files to
be run as scripts. But this is not much use if the path inserted is in
the build tree, namely something like:

#!/build/open-axiom-NMAtjL/open-axiom-1.4.1+svn~2299/build-tree/src/interp/interpsys
 --script

I'm not sure if open-axiom uses this feature (and I notice sbcl itself
also has broken #! lines in it's fasl files. In your case, I suspect the
upstream build process is putting the wrong path into the #!
lines. interpsys isn't installed by debian sbcl and it isn't included in
the open-axiom source package.

David


--
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/87k49xy415.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Sun, 28 Aug 2011 23:11:25 +0400, Игорь Пашев pashev.i...@gmail.com wrote:
Non-text part: multipart/alternative
 Lintian clear.
 
 1. Hypetex data is moved to /usr/share with symlink.
 2. Removed shebangs and compiled from ... lines from *.fasl files
 
 Now OA packages are lintian clear.

Just upload another source package to mentors.debian.net, and I'll
review and hopefully upload it. Or find something else to complain 
about :).

David


--
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/8762lhti70.fsf@zancas.localnet

Re: RFS: open-axiom

[David Bremner]

On Mon, 29 Aug 2011 02:34:03 +0400, Игорь Пашев pashev.i...@gmail.com wrote:
Non-text part: multipart/alternative
 Uploaded.
 
 http://mentors.debian.net/package/open-axiom
 
 Sorry for flooding ;-)
 

Some of these things I should have found earlier, but I thought lintian
would keep you busy longer ;).

- The second paragraph of the long description is not helpful to the
  debian user trying to decide whether to install the package; we try
  not to waste space in the description because it is stored in many
  places (e.g. /var/lib/dpkg/available).  You are welcome to add a
  README.Debian file if you want to say more about the project.

- rather than putting TODO in debian/control, it is better have a
  seperate TODO file that will be installed by dh_installdocs

- In your debian/copyright file, you should mention the license for your
  packaging. It would be a good idea to have a seperate header line for
  license and to explicitly say by each copyright holder (NAG, Axiom
  Team) what license applies (do they all use the BSD-like mentioning
  NAG, or are there variants?).

- I'm confused why debian/open-axiom.png is listed in
  debian/source/include-binaries, but not include in the source
  package. Previous experiment?

- Don't think removing the compiled from lines is needed, but it is
  your call. The shebang lines I agree should go.

- at some point you should consider adding some metadata to your
  patches. I typically just use git-format-patch, but if using straight
  quilt you may want to look at http://dep.debian.net/deps/dep3/.

Anyway I have to run, Hurricane Irene is making my power flicker on and
off.

d




pgpph1CrR4Fye.pgp
Description: PGP signature

Re: RFS: open-axiom

[David Bremner]

On Mon, 22 Aug 2011 19:54:42 +0400, Игорь Пашев pashev.i...@gmail.com wrote:

 I am looking for a sponsor for my package open-axiom.
 
  * Package name: open-axiom
Version : 1.4.1+svn~2299-1

Hi Igor;

Thanks for working on this, and for making a source package. You package
builds OK, but it has many lintian errors (attached). You will need to
fix most of these before the package is likely to be uploaded. Be sure
to run a recent version of lintian, as it is changing fairly quickly
these days.  Also, I think it would be helpful if you could explain the
relationship between axiom (maintainer in CC), which is already shipped
in Debian and open-axiom.  Does Debian need both? It's fine if they both
have something to offer, but if one supercedes the other, then that
could mean less work all around.

All the best, 

David




lintian.txt.gz
Description: Binary data

Re: Package for OpenAxiom

[David Bremner]

On Sat, 20 Aug 2011 18:45:44 +0400, Игорь Пашев pashev.i...@gmail.com wrote:

 I have prepared packages for OpenAxiom:
 https://github.com/ip1981/open-axiom-debian

It would help lazy/busy reviewers if you would provide either a source
package uploaded to mentors.debian.net or a git repo that makes it
easier to build a source package (i.e. has a branch where
dpkg-buildpackage -S works). 

I have redirected followups to debian-mentors, where you are more likely
to find help.

All the best,

d


--
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/87zkj4jf4d.fsf@zancas.localnet

Re: RE : : RFS: autoconf-archive (updated package)

[David Bremner]

On Fri, 15 Jul 2011 10:47:25 +0200, Kilian Krause kil...@debian.org wrote:
Non-text part: multipart/signed

 I've not fixed the unneeded-build-dep-on-quilt warning of lintian, but
 maybe that could be part of the gitpkg fix that would only ship
 debian/patches (including debian/patches/series) if it's really
 required

This is already fixed in gitpkg 0.20; the lintian false-positive is about
something different; see #633891 for details.

 and also ship the quilt-b-dep if it's really required. It may very well
 be that it's not even required due to the dpkg-source v3.

The quilt build-dep has nothing to do with gitpkg, as far as I know. I
suspect you (and lintian) are correct that it is not needed.

d


-- 
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/87aacfkfrf.fsf@zancas.localnet

Re: RE : : RFS: autoconf-archive (updated package)

[David Bremner]

On Thu, 14 Jul 2011 12:34:30 +0200, roucaries bastien 
roucaries.bastien+deb...@gmail.com wrote:
 
 They are no patches. It is a bug in gitpkg even after david Bremner
 patch lintian complain.
 

I'm a bit surprised by that. In any case, try version 0.20 of gitpkg
which contains a different fix. If there is still a bug, please report
it.

d


-- 
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/87wrfljdzt.fsf@zancas.localnet

Re: RE : : RFS: autoconf-archive (updated package)

[David Bremner]

On Thu, 14 Jul 2011 16:41:05 +0200, roucaries bastien 
roucaries.bastien+deb...@gmail.com wrote:
 On Thu, Jul 14, 2011 at 1:30 PM, David Bremner brem...@debian.org wrote:
 
 I use 0.20, it does not export patches but lintian complain. See the
 file in mentors. I believe it is a lintian bug.
 What do you think ?
 

Certainly 

   E: autoconf-archive source: unknown-file-in-debian-source git-patches

is a bug in lintian. For what it is worth, you refer to the wrong bug on
mentors.debian.net. This was 607502, also fixed in 2.5.1 (and in
2.5.0~rc1).

d






-- 
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/874o2og32z@convex-new.cs.unb.ca

Re: RE : : RFS: autoconf-archive (updated package)

[David Bremner]

On Thu, 14 Jul 2011 20:06:06 +0200, roucaries bastien 
roucaries.bastien+deb...@gmail.com wrote:
 Not fixed in my case:
 lintian *.changes || lintian --version
 E: autoconf-archive source: git-patches-not-exported
 Lintian v2.5.1

Ah, yes. I agree this is a bug, different than the bug we just fixed in
gitpkg. I'm not sure at the moment where this should be fixed.  It is
not possible for lintian to detect that your git-patches file is
trivial, i.e. that it will not result in the export of any patches.  On
the other hand, it seems like something we should try to support, even
if we didn't think about it before.  Please file a bug on gitpkg, and we
can reassign to lintian if that turns out to be the place to fix it.

d


-- 
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/871uxsg0op@convex-new.cs.unb.ca

Re: RE : : RFS: autoconf-archive (updated package)

[David Bremner]

On Wed, 13 Jul 2011 11:17:46 +0200, Kilian Krause kil...@debian.org wrote:
 
 3. Lintian still warns about:
 E: autoconf-archive source: git-patches-not-exported
 P: autoconf-archive source: unneeded-build-dep-on-quilt
 

Hi Bastien, Hi Kilian;

As 

   lintian-info -t git-patches-not-exported 

indicates, that warning is because the source package contains a
non-empty debian/source/git-patches, but no actual patches.

I couldn't actually find a tag or branch named upstream/2011.04.12 in
your git repo on collab-maint, but if I use the current head of
upstream, then it is identical to debian-patches/2011.04.12. This seems
to have triggered a bug in the gitpkg hook which fails to detect that
you have not exported any patches.  For the moment, you can just
comment out the line in debian/source/git-patches (or delete that file),
and I'll see about fixing the gitpkg hook. I append a patch, but I'm not
sure yet that this is the best fix.

David



pgppRfioD7q7Q.pgp
Description: PGP signature
From e0002bf481955279fbd9e930f08afb25403ac00d Mon Sep 17 00:00:00 2001
From: David Bremner brem...@debian.org
Date: Wed, 13 Jul 2011 08:23:24 -0300
Subject: [PATCH] quilt-patches-deb-export-hook: Count only non-blank lines in
 debian/patches/series

---
 hooks/quilt-patches-deb-export-hook |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hooks/quilt-patches-deb-export-hook b/hooks/quilt-patches-deb-export-hook
index 37afb60..1c74544 100644
--- a/hooks/quilt-patches-deb-export-hook
+++ b/hooks/quilt-patches-deb-export-hook
@@ -91,7 +91,7 @@ echo # $patch_list exported from git by quilt-patches-deb-export-hook  $patc
  $patch_list ; echo ) | do_patches || exit 1
 
 
-count=$(wc -l $patch_dir/series | cut -f1 -d' ')
+count=$(grep -c -v '^\s*$' $patch_dir/series | cut -f1 -d' ')
 
 if [ $count -eq 1 ]; then
 echo No patches generated from $patch_list
-- 
1.7.5.4

Re: Nitpicking: you are doing it wrong

[David Bremner]

On Fri, 8 Jul 2011 08:47:31 -0400, Scott Howard showard...@gmail.com wrote:
 
  - debian/copyright not in DEP-5 format;
 
 This is accepted and will be policy soon [3]. What should be done
 eventually must be done immediately.
 

I think you might misunderstand the DEP process, which is easy to
do. The following is my understanding. Accepted DEPs must still go
through a policy revision process. The point is to converge on a
process/implementation, and once that process/implementation becomes
widely used and successful, then it can become policy. In particular, I
would find it pretty surprising if DEP-5 became a policy must, and
suspect that it will most likely be a policy may [1]. That would mean
that not having a DEP-5 copyright file might, at some point in the
future be grounds for a wishlist bug.

David


[1]: see http://www.debian.org/doc/debian-policy/ch-scope.html#s1.1 for
 definitions.


pgpdyhadsIq1r.pgp
Description: PGP signature

Re: /usr/lib64 or /usr/lib

[David Bremner]

On Thu, 09 Jun 2011 13:40:54 -0700, Russ Allbery r...@debian.org wrote:
 
 On Debian, you should always install into lib and never use lib64.
 (Eventually, you may want to use the multiarch directory, but it will
 still not be lib64.)
 

That was my first thought, but I couldn't find a straightforward
justification in

  http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs

I wonder if a slight clarification is needed, or it's just me.

David


-- 
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/87vcwehbqj.fsf@zancas.localnet

Re: /usr/lib64 or /usr/lib

[David Bremner]

On Thu, 09 Jun 2011 15:41:34 -0700, Russ Allbery r...@debian.org wrote:
 
 9.1.1 point 2:
 
 The requirement for amd64 to use /lib64 for 64 bit binaries is
 removed.

Yeah, that is the point that confused me. For me, removing the
requirement is not the same as forbidding.

 
 Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems.
 

So that makes it a bit academic, at the moment.

cheers,

d


-- 
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/87sjrihb88.fsf@zancas.localnet

Re: RFS: dylandotnet

[David Bremner]

On Sat, 14 May 2011 11:32:19 +0200, Dylan Borg borgdy...@hotmail.com wrote:
 
 It builds these binary packages:
 dylandotnet - This is the dylan.NET compiler
 

Hi Dylan;

It seems like your package ships several .dll files that are not rebuilt
during the package build process.  By policy 2.2.1, your package must be
buildable from source using tools in main; the easiest way to
demonstrate this is to do it.  

I'm not a .NET expert, but I was also not sure that the the .DLL files
are really architecture independant. 

Your package has some lintian warnings and errors:

W: dylandotnet: extended-description-line-too-long
E: dylandotnet: depends-on-metapackage depends: mono-complete
W: dylandotnet: debian-changelog-line-too-long line 1
W: dylandotnet: binary-without-manpage usr/bin/dylandotnet
E: dylandotnet: helper-templates-in-copyright
E: dylandotnet: helper-templates-in-copyright
E: dylandotnet: copyright-contains-dh_make-todo-boilerplate

Note that debian/copyright is crucial for a package to be accepted into
the archive.



Aside from lintians complaints, your description also didn't really help
me understand what the package is.  Please see

   
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis

   
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc

For some hints about writing a short and long description. Remember your
audience is likely not expert in .NET

I found the phrase This compiler when ready a bit discouraging; is the
compiler useful for something now? 

It would be good to clarify if your package has anything to do with

 http://en.wikipedia.org/wiki/Dylan_(programming_language)

I'm guessing not, but this is the default when I hear dylan and
programming language.

You may also want to look for feedback/sponsorship from the debian mono
team.
   
   pkg-mono-de...@lists.alioth.debian.org


-- 
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/87hb8xfqsk.fsf@zancas.localnet

RE: RFS: dylandotnet

[David Bremner]

I took the liberty of redirecting this reply back to the list.
You may want to bounce  your original message to the list as well.
In general, please direct the discussion to the list.

I'm not sure why lintian does not catch this, but your changelog needs
work.

 - target should be debian unstable, not ubuntu.

 - Your closes line is wrong, it should not be part of the line with
 urgency=low. 

 - Your changelog should also close a Debian ITP bug, since that is the
 right place to have a discussion about whether a proposed package is
 suitable for Debian.

On Sat, 14 May 2011 14:25:52 +0200, Dylan Borg borgdy...@hotmail.com wrote:

 My target audience is a .NET aware audience, this package contains a
 compiler after all.

You still need to provide a description that is useful for debian users
in general. 

 The .dlls are binary and platform independent(it is in the ECMA 335
 spec).

OK.

 Right now the current dylan.NET compiler is only runnable on windows.

[...]

 Because the build cannot happen on Linux currently I ship the dlls
 ready made.

Then I think you will have to target contrib rather than Debian main
until you can build in Debian. See policy 2.2.2 for an explanation.

  http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

MS-Windows certainly counts as a non-free package ;).

 The method inners are being worked on but I wish the packaging and the
 already completed parts to be tried on and bugs filed to me.

Do you think there is enough audience to justify uploading to Debian at
this time?  What would this audience be?

 It does not have to do with the Dylan programming language.

Right, so please add that to your long description.

All the best,

David





pgpINqaECUemM.pgp
Description: PGP signature

RE: RFS: dylandotnet

[David Bremner]

On Sat, 14 May 2011 16:34:14 +0200, Dylan Borg borgdy...@hotmail.com wrote:
 
 I have updated the package(the debian dir only). The packagge is opens
 ource. Open source software can run on Windows!...remove the
 misconception that Windows software always must cost money.

Hi Dylan;

non-free is used in Debian in a technical sense to refer to software
that does not mee the Debian Free Software Guidelines. In order to be
included in Debian main, not only must your software be DFSG free, but
it must be buildable using only DFSG free tools. Since your software
only builds on Windows so far, it can't be built only with DFSG free
tools. This is why I referred you to specific sections of Debian policy.

In my opinion, you should also address the question of what-kind/how
large of an audience your package would have. You have to remember that
you are in the position of selling your package to a potential sponsor,
and there are many packages and people clamouring for attention.

David






pgpMeW3PcBM1V.pgp
Description: PGP signature

Re: RFS: jansson - C library for encoding, decoding and manipulating JSON data

[David Bremner]

On Wed, 6 Apr 2011 23:28:58 +0200, Alessandro Ghedini al3x...@gmail.com wrote:

 It builds these binary packages:
 libjansson4 - C library for encoding, decoding and manipulating JSON data
 libjansson4-dev - C library for encoding, decoding and manipulating JSON data 
 (dev)
 libjansson4-doc - C library for encoding, decoding and manipulating JSON data 
 (doc)

Some comments:

1) Don't put the soname in the name of the -dev package, unless you are
   really sure it is needed. It complicates SONAME transitions.

   Unfortunately library packaging docs are in flux right now, but see
   for example the message

http://lists.debian.org/debian-mentors/2011/03/msg00357.html

2) Same for the doc file; I see less downsides here to the versioning, but
   convention is to to have unversioned doc files.

3) I see you install docs into /usr/share/doc/jansson instead of
   /usr/share/libjansson4-doc. I'm not sure that this is a bug, but it
   is bit unusual. Can you explain/justify this?

4) It could be nice to install

   test/bin/json_process.c

   as an example (see e.g. man dh_installexamples); no makefile or anything
   is needed.

5) licenscheck --copyright src   suggests one more copyright holder that
   could be added to debian/copyright.

6) I'm not sure about saying C library rather than just library in the
   short description. Perhaps it betrays my age, but for me that is the
   default. But I'm willing to convinced if there is some advantage to
   the user.

That is all I see now.  Feel free to just push changes to git.debian.org;
I prefer to work from the git repo in any case.

David




pgpRGx8UQdThC.pgp
Description: PGP signature

Re: RFS: jansson - C library for encoding, decoding and manipulating JSON data

[David Bremner]

On Sat, 9 Apr 2011 15:26:20 +0200, Alessandro Ghedini al3x...@gmail.com wrote:
 
 Thanks for your review.
 

Uploaded. Feel free to contact me directly for future jansson uploads.

I took the liberty of pushing a tag debian/2.0.1-1 to collab-maint
(corresponding to version I uploaded). Feel free to delete if the naming
convention doesn't suit you, or whatever.

d


pgpJPl4qHkGpb.pgp
Description: PGP signature

ITR: jansson - C library for encoding, decoding and manipulating JSON data

[David Bremner]

On Wed, 6 Apr 2011 23:28:58 +0200, Alessandro Ghedini al3x...@gmail.com wrote:
 
 My motivation for maintaining this package is: Thanks to its intuitive and
 simple API I think this is a very valid alternative to the IMHO more complex
 json-c which is already in the archive. Many new interesting open source 
 projects are using this library so it will probably be needed at some point 
 in the future.

If no-one more keen gets to it first, I'll have a look at this package
on the weekend.

d


-- 
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/87ipupr4ab.fsf@zancas.localnet

Re: Git Package Versioning

[David Bremner]

On Sun, 20 Mar 2011 22:25:38 +0100, Joachim Wiedorn ad_deb...@joonet.de wrote:

 
 Please be aware, that + is not the optimal connector.
 Try dpkg --compare-versions and see:

[snip] 

 The version b) is the better way. So please use ~ 
 as connector.

That rather depends on your goal. If the version number is before the
current snapshot, then + is appropriate.

I like to use the output of git-describe, along with sed, something like
the following:

,
| SOURCEPKG=$(shell dpkg-parsechangelog | sed  -n 's/^Source: \(.*\)/\1/p')
| UPSTREAM=$(shell dpkg-parsechangelog |  sed -n 's/^Version: 
\(.*\)-[^-]*/\1/p')
| SHA1=$(lastword $(subst ~g, ,$(UPSTREAM)))
| ORIG=${SOURCEPKG}_${UPSTREAM}.orig.tar.gz
| 
| describe-current-version:
|   git describe --tags upstream | sed 's,^release-,,;s,-,+,;s,-,~,;'
| 
| get-orig-source:
|   git archive --format=tar $(SHA1) | gzip -9  ../$(ORIG)
`

The output from ./debian/rules describe-current-version is pasted into
debian/changelog, and it makes things like

  0.7.1+706~g1157b91-1

So here + really makes sense because it is 706 commits after tag
release-0.7.1

The second ~ could be a + as well, doesn't matter.

Your mileage, may, as they say, vary.

d


-- 
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/878vw9mopa.fsf@zancas.localnet

Re: RFS: dwarf-ng

[David Bremner]

On Fri, 28 Jan 2011 20:41:32 + (UTC), Fernando xna...@cryptolab.net wrote:
 
 The package is not present in debian, it is my first commit.
 
 The package can be found on Savannah:
 http://download.savannah.gnu.org/releases/dwarf-ng/dwarf_0.3.0-1_i386.deb
 
 I would be glad if someone uploaded this package for me.
 

You need to provide a source package. It would also help if you provided
a description of the package, filed an ITP bug, told us what programming
language it is implemented in, and why you think it ought to be in
debian.   You might find the templates on mentors.debian.net helpful. 
To file an ITP bug, type reportbug wnpp on your debian system and
follow the prompts.

Hope this helps,

David


-- 
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/87d3ngeok5@convex-new.cs.unb.ca

Re: RFS: hugs98 (NMU, RC bugfix)

[David Bremner]

On Sun, 16 Jan 2011 18:08:13 +0100, Felix Geyer debfx-...@fobos.de wrote:
 I am looking for a sponsor for my NMU of the package hugs98.
 
 The upload would fix this RC bug: http://bugs.debian.org/608220

 http://mentors.debian.net/debian/pool/main/h/hugs98/hugs98_98.200609.21-5.2.dsc
 

Hi Felix;

Please discuss with the release team (in CC) whether your upload is OK
for squeeze. If they approve it I (or someone else) can sponsor the NMU.

Release team: diffstat is big because autoconf rewrites all of 
configure. Other than that, the interesting change is 

--- hugs98-98.200609.21/debian/rules
+++ hugs98-98.200609.21/debian/rules
@@ -18,6 +18,9 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
+# Ensure that LDFLAGS is empty as the build system can't handle commas.
+LDFLAGS :=
+
 CONFIG_DIRS := . packages/network/ packages/Cabal/tests/HSQL/ \
packages/ALUT/ packages/GLUT/ packages/OpenAL/ \
packages/OpenGL/ src/unix/ 


d


pgpzOy11LvLSO.pgp
Description: PGP signature

Re: ITR: robocut (driver for consumer GRAPHTEC cutting plotters like Silhouette SD and craftROBO)

[David Bremner]

On Sun, 19 Dec 2010 17:54:03 -0400, David Bremner brem...@debian.org wrote:
 
 I intend to review, and all going well sponsor this.
 

Uploaded. Some comments for the next upload:

- Can you talk to Tim about re-generating the moc/qrc files at package
  build time (either don't distribute them, or delete them in the clean
  step)? Unless there are good reasons not to do this, it will make it
  clear that the package really supplies all the needed source (as you
  tested by deleting them and running make).

- It wasn't clear to me how the Debian source package is produced from
  the git repository. Perhaps you could document this in
  debian/README.source

Thanks for your contribution to Debian

d


pgpqOPlF8zJt2.pgp
Description: PGP signature

Re: ITR: robocut (driver for consumer GRAPHTEC cutting plotters like Silhouette SD and craftROBO)

[David Bremner]

On Mon, 20 Dec 2010 20:17:40 -0500, Markus Schulz sch...@alpharesearch.de 
wrote:

 I'm generating the tar.gz file via qmake; make; make dist - please tell
 me if I need to create this readme file in this case or not?
 (From debian-policy 4.14 I don't think so, but I'm still learning)

No, you don't need to document how you make .orig.tar.gz. What I was
curious about was after you have .tar.gz, how do you make a debian
source package from a branch containing only the ./debian directory.
Policy wise, you don't _need_ to document this either. However, many of
us are becoming more and more VCS centric in our debian work, and the
first thing we will try to look at a package is 

% debcheckout robocut  

we can then get the .orig.tar.gz by running 

% uscan

So now the question is, how can I apply an emergency security fix while
you are on holidays somewhere warm?

  - Can you talk to Tim about re-generating the moc/qrc files at package
build time (either don't distribute them, or delete them in the clean
step)? 

 I did look into git archive and dpgk- source options that were suggested
 on irc, however I guess if users compile from scratch on non Debian
 systems this source packaging with make dist could make it easier...

That could well be the case.  There is still the option of moving the 
files out of the way in debian/rules and moving them back
afterwords. This is probably uneeded here, but is a good trick to know
about in general.

Hope this helps,

David


-- 
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/87r5dbewb0@zancas.localnet

ITR: robocut (driver for consumer GRAPHTEC cutting plotters like Silhouette SD and craftROBO)

[David Bremner]

On Sun, 05 Dec 2010 20:15:49 -0500, Markus Schulz sch...@alpharesearch.de 
wrote:
 I uploaded a new version 1.0.6-1 that fixes a display bug and some other
 small changes.
 
 This driver imports an SVG file from Inkscape and lets the use cut the path.
 

I intend to review, and all going well sponsor this.

d


pgp90jpRILEgy.pgp
Description: PGP signature

Re: RFS: aspell-id; third try

[David Bremner]

On Sat, 11 Dec 2010 01:41:33 +0700, Mahyuddin Susanto udi...@debian-id.org 
wrote:

 * Package name: aspell-id
   Version : 1.2-0-4
   Upstream Author : Benitius Brevoort benitius.brevo...@kapusin.org
 * URL : http://translationproject.org/team/id.html
 * License : GPLv2+
   Section : text


1) Usually packagers using this debian/copyright style add something like 

   Files: debian/*
   Copyright: Your name here
   License: same as upstream

2) I can confirm it builds in a chroot.

3) You don't need changelog entries for all the versions that were not
uploaded to debian. I understand you want to show people that you are
fixing the things they suggest, but I think most of your comments belong
in git logs, not not in the changelog.  I would suggest one stanza, and
remove some of the minor packaging issues. Feel free to leave in the
various contributions from other people.


-- 
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/87wrnfrbd1@zancas.localnet

Re: RFS: daisy-player

[David Bremner]

On Wed, 08 Dec 2010 20:31:37 +0100, Paul Gevers p...@climbing.nl wrote:

 daisy-player - player for DAISY Digital Talking Books
 daisy-player-dbg - daisy-player debugging symbols

Dear Paul;

Is there some media available that people could test this with? I had a
quick look at the daisy web site, but nothing jumped out at me.

All the best

David


-- 
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/87y6803sbw@convex-new.cs.unb.ca

Re: RFS: robocut

[David Bremner]

On Sun, 28 Nov 2010 20:46:23 -0500, Markus Schulz sch...@alpharesearch.de 
wrote:

 I am looking for a sponsor for my package robocut.
 
 * Package name: robocut
   Version : 1.0.4-1
   Upstream Author : Tim Hutt tdh...@gmail.com
 * URL : https://launchpad.net/robocut
 * License : GPL V3
   Section : graphics
 
 It builds these binary packages:
 robocut- Control program for Graphtec cutting plotters

Hi Markus;

I'm not quite ready to upload a package I can't test. Also, I think this
package probably needs somebody comfortable with QT. Nonethless here are
some comments that may help move things forward.

Some things I checked, and looked good:

- It builds clean in a chroot
- uscan works ok now :)
- It is indeed lintian clean
- I ran piuparts, and got only familiar false positives.
- I looked at the copyright and license headers.
- It starts up and I managed to import an SVG file of unknown
  provenance.
- I verified that you closed the right bug in your changelog.
- there is no mysterious diffs in .debian.tar.gz
- md5 sums match for the .orig.tar.gz

Some things to think about:

- debian/copyright looked OK, although I'm not sure you need the header
  at the end. Isn't that covered by the packaging copyright statement?

- You ship quite a few generated source files. Please double check that
  these can be generated with the tools in Debian; a surefire way to do
  that is do to it at build time.

- images are a constant source of copyright issues; you might want to
  make some statement in debian/copyright that the files in images/ 
  are the source; i.e. they are not generated from some other files.

- If you have the packaging in version control somewhere, you should add 
  Vcs-$system (e.g. Vcs-Git) and Vcs-Browse fields. If not, why not?

- I'm not a big fan of binaries that start with capital letters. That is
  just my personal opinion.

- I thought the homepage url was broken, but maybe it is supposed to say
  Launchpad does not know where Robocut hosts its code..
  In which case, since you are upstream, maybe you could fix that?

Thanks for your efforts for Debian.
 
David




pgpYey4yfmALb.pgp
Description: PGP signature

Re: RFS: twatch

[David Bremner]

On Mon, 11 Oct 2010 16:57:25 +0400, Roman V. Nikolaev rsha...@rambler.ru 
wrote:
 Dear mentors,
 
 I am looking for a sponsor for my package twatch.
 
 * Package name: twatch
   Version : 0.0.4-1
   Upstream Author : Roman V. Nikolaev rsha...@rambler.ru
 * URL : twatch.rshadow.ru
 * License : GPL3
   Section : net
 
 It builds these binary packages:
 libtwatch-perl - watch torrent trackers and automatically download new
 torrents
 twatch - watch torrent trackers and automatically download new torrents

Hi Roman;

A few quick notes on your package.

- You might ask the debian perl team (debain-p...@lists.debian.org,
   #debian-perl on irc.oftc.net) if they would like to help with your
   package.  Mostly they package modules, but there are some packages
   like yours where there is a script as well.  See libapp-nopaste-perl
   for an example.

- Does it really need to make two seperate packages? Generally we try to
  avoid tiny packages when possible.

- The latest lintian complains your libtwatch-perl should be in section
  perl.  

That's all I have time for now,

David


-- 
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/87sjzzuvnb@convex-new.cs.unb.ca

Re: RFS: disco

[David Bremner]

On Tue, 12 Oct 2010 03:31:06 +0200, Janos Guljas ja...@janos.in.rs wrote:
 Hi David,
 
 As I see, there is only one copy of jquery library
 master/www/js/jquery-1.2.1.js which is removed and linked in
 debian/rules. Another copy which in disco-doc package as a result of
 python-sphinx work is also removed and linked. If there is another
 copy that I missed, could you point it out?
 

Ah, that sounds fine. This is the problem with extremely fast review, it
sometimes generates false positives.

All the best,

David


-- 
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/874ocreefm@convex-new.cs.unb.ca

Re: RFS: disco

[David Bremner]

On Mon, 11 Oct 2010 22:13:43 +0200, Niels Thykier ni...@thykier.net wrote:
 -BEGIN PGP SIGNED MESSAGE-

 While I am not a python/erlang/etc. packager, I did a small review of
 your package. It is quite possible that I missed some issues that a
 second reviewer will find (particularly if said review knows anything
 about packaging python or erlang).

Please double check your package for embedded libraries. I saw what
looked like libjs-jquery. You should (almost always) ensure your binary
packages are not using the embedded version.  See

http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

for more information.

d


-- 
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/87k4logvjw@rocinante.cs.unb.ca

Re: RFS: btag -- interactive command-line based multimedia tag editor

[David Bremner]

On Fri, 1 Oct 2010 00:50:15 -0300, Fernando Lemos fernando...@gmail.com wrote:

 * Package name: btag
   Version : 1.0.0-1
   Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com
 * URL : http://github.com/fernandotcl/btag
 * License : BSD
   Section : sound

Hi Fernando;

I'm not a DD, but hopefully this review can make it easier to sponsor
your package.

Your package

- compiles clean in a sid chroot
- lintian clean with version 2.4.3
- the man page looks good
- I did a successful test run on some mp3's, and seemed to work.

Some comments

- It should be documented what extensions/formats are supported.  I
  tried some m4a's and it didn't work. Probably this should be in the
  long description.

- The file LICENSE has one COPYRIGHT HOLDER in it that looks like it
  should be replaced. This is probably a minor thing to be reported to
  upstream.

Thanks for your Debian packaging efforts.

d



--
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/877hhwh8fk@convex-new.cs.unb.ca

Re: packaging qt apps for debian

[David Bremner]

On Sat, 2 Oct 2010 13:46:40 +0530, Rustom Mody rustompm...@gmail.com wrote:
 
 http://build-common.alioth.debian.org/cdbs-doc.html#id2561450
 
 So you think it maybe better to go the cdbs-qmake-class way?
 

Without wishing to speak ill of CDBS, you will find that more people can
help you with debhelper questions, at least on #debian-mentors (IRC). I
don't follow this list quite as closely, but I think also here CDBS
using mentors are quite a small minority.

David



-- 
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/871v88vpmk@rocinante.cs.unb.ca

Re: RFS: packagekit

[David Bremner]

On Sun, 29 Aug 2010 14:48:17 +0200, Matthias Klumpp matth...@nlinux.org wrote:
 somone (pabs?) wrote:
  Why do you move the upstream helper scripts to /usr/lib?
 They're scripts and should not be in /usr/share/PackageKit. In this
 directory we only have documentation of PK.

As best I understand the Linux File Hierarchy Standard, and thus Debian
Policy, architecture independent files should go in /usr/share, even if
they are scripts.  Perhaps you could make a subdirectory for the docs,
and one for the helper scripts

All the best,

David


-- 
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/87aao4xn0t@rocinante.cs.unb.ca

help with dpkg-shlibdeps/library dependencies

[David Bremner]

I'm packaging the latest syncevolution (beta2) which needs a snapshot of
libsynthesis (3.4.0.5+ds1).  It builds fine, and seems to work, but the
calculated depencies are wrong.

src:libsynthesis makes two library binary packages, libsynthesis0 and
libsmltk0

dpkg-shlibdeps computes dependency 

 libsynthesis0 (= 3.2.0.35+ds2-1)

This seems plausible, since the symbols file didn't change since
then. On the other hand, it doesn't generate any dependency on
libsmltk0, which is consistent with what is reported by.

  objdump -x /usr/bin/syncevolution | grep NEEDED 

Unfortunately, libsmltk0 has got at least one new symbol, and
syncevolution gets fatal runtime errors (although, it is a bit
mysterious that it doesn't get link time errors) if I install
3.2.0.35+ds2-2 of libsynthesis0 and libsmltk0

libsynthesis and syncevolution are in collab-maint, and you can get
them with 

 debcheckout libsynthesis
 debcheckout syncevolution

Any ideas would be welcome. I tried linking with --as-needed and passing 
-lsmltk explicitly, but it doesn't seem to change anything.

here is the link line from the build log (wrapped)

,
| libtool: link: g++ -I/usr/include/gnome-keyring-1
| -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2
| -uSyncEvolution_Module_Version -Wl,--export-dynamic -Wl,--as-needed -o
| syncevolution syncevolution-syncevolution.o
| syncevolution-CmdlineSyncClient.o
| syncevolution-AddressBookSourceRegister.o
| syncevolution-EvolutionCalendarSourceRegister.o
| syncevolution-EvolutionContactSourceRegister.o
| syncevolution-FileSyncSourceRegister.o
| syncevolution-MaemoCalendarSourceRegister.o
| syncevolution-SQLiteContactSourceRegister.o
| syncevolution-XMLRPCSyncSourceRegister.o -pthread
| backends/addressbook/.libs/syncaddressbook.a
| backends/evolution/.libs/syncebook.a -lebook-1.2
| backends/evolution/.libs/syncecal.a -ldl -lecal-1.2 -lical -licalss
| -licalvcal
| 
/build/bremner-syncevolution_1.0+ds1~b2a-1-i386-Xlwprz/syncevolution-1.0+ds1~b2a/src/syncevo/.libs/libsyncevolution.a
| backends/file/.libs/syncfile.a backends/maemo/.libs/syncmaemocal.a
| backends/sqlite/.libs/syncsqlite.a backends/xmlrpc/.libs/syncxmlrpc.a
| syncevo/.libs/libsyncevolution.a -lsmltk -ledataserver-1.2
| /usr/lib/libxml2.so /usr/lib/libgconf-2.so /usr/lib/libbonobo-2.so
| /usr/lib/libbonobo-activation.so /usr/lib/libORBit-2.so -lsynthesissdk
| -lsynthesis -lsoup-2.4 /usr/lib/libgio-2.0.so /usr/lib/libgmodule-2.0.so
| -lopenobex /usr/lib/libbluetooth.so /usr/lib/libgthread-2.0.so -lrt
| /usr/lib/libgobject-2.0.so -lgnome-keyring /usr/lib/libglib-2.0.so
| -pthread
`


-- 
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/87mxymd4mf@rocinante.cs.unb.ca

RFS: nauty graph isomorphism package (fixes RC bug).

[David Bremner]

Dear mentors,

I am looking for a sponsor for my package nauty.

* Package name: nauty
  Version : 2.4-1
  Upstream Author : Brendan McKay b...@cs.anu.edu.au
* URL : http://cs.anu.edu.au/~bdm/nauty/
* License : non-free: non-commercial/pacifist
  Section : non-free/math

It builds these binary packages:
libnauty-dev - library for computing graph automorphisms (development files)
libnauty1d - library to compute graph automorphisms and canonical labellings
nauty  - command line tools to compute graph automorphisms

The package appears to be lintian clean.

The upload would fix these bugs: 569269 (FTBFS due to appearence of
getline in default namespace).

My motivation for maintaining this package is: I use it in my work, and
it is a build depend for polymake, another package I am (slowly) 
working on.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/n/nauty
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 David Bremner


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

Re: RFS: nauty graph isomorphism package (fixes RC bug).

[David Bremner]

On Sat, 13 Feb 2010 18:11:43 -0400, David Bremner brem...@unb.ca wrote:
 
 The upload would fix these bugs: 569269 (FTBFS due to appearence of
 getline in default namespace).

Sigh. That should be bug #569626, fixed in a new upload to mentors.

d


-- 
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/87iqa0iw0w@rocinante.cs.unb.ca

RFS: lrslib, package to enumerate solutions to linear inequalities

[David Bremner]

rom: David Bremner brem...@unb.ca
To: debian-mentors@lists.debian.org
Subject: RFS: lrslib

Dear All;

I am looking for a sponsor for my package lrslib.

* Package name: lrslib
  Version : 0.42c-1
  Upstream Author : David Avis a...@cs.mcgill.ca
* URL : http://cgm.cs.mcgill.ca
* License : GPL2+
  Language:   : C
  Section : math

It builds these binary packages:
liblrs-dev - package to enumerate vertices and extreme rays (static libraries)
liblrs0d   - package to enumerate vertices and extreme rays (shared libraries)
lrslib - package to enumerate vertices and extreme rays of a convex 
polyhedron

The package appears to be lintian (-I) clean. I even fixed the
spelling-mistake-in-binary warning after some grumbling :).

The upload would fix these bugs: 454469

My motivation for maintaining this package is that is a Build
dependency for polymake (ITP #461976), and also useful as a tool for
mathematicians and other scientists and engineers.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/lrslib
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/l/lrslib/lrslib_0.42c-1.dsc

You can check the package out from git

git clone git://git.debian.org/debian-science/packages/lrslib

There is a gpg signed tag debian/0.42c-1rc2.  the original source
tarball is stored using pristine tar in the same repo.

I would be glad if someone uploaded this package for me.

Kind regards
 David Bremner


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

Re: RFS: libplist (Adopted, updated package)

[David Bremner]

Sorry for the bizzare spam-like From on that last message. Experimental mail 
setup gone wild...

d




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

Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues

[David Bremner]

Ben Finney wrote:

* Declare dependencies on the version of the library in Debian, even
  though that version may be later than the convenience copy currently
  in the original source?

Section 4.1.3 of Debian policy says 

   If the included code is already in the Debian archive in the form
   of a library, the Debian packaging should ensure that binary
   packages reference the libraries already in Debian and the
   convenience copy is not used. If the included code is not already
   in Debian, it should be packaged separately as a prerequisite if
   possible.

That seems to be a yes, or a yes + update the library, at least as a
best practice.

* Remove the convenience copy from the original source archive, or
  merely from the binary package?

IMHO, it depends. If the code is dfsg free and not too big, don't
bother to repack.

* Document the convenience copy in the dependent package's ‘copyright’,
  even if it doesn't appear in the binary package?

I thought everything in the source package should be documented in
debian/copyright?  At least, this seems to be what the ftp-masters
expect, based on some recent email exchanges I have read. Sorry no
references, but maybe check the pkg-perl or debian-science archives.

d



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

Re: RFS: aegis (updated package, NMU)

[David Bremner]

Walter Franzini wrote:


The problem may be related to the procedure used to produce the upstream
tarball, it is created with file ownership different from root.root and
git-buildpackage /probably/ is unable to reproduce it exactly.

If you are regenerating the tarball from git you should investigate
pristine-tar, which can produce checksum identical tarballs.

d


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

Re: RFS: libv8

[David Bremner]

At Sun, 6 Sep 2009 16:03:10 +,
Antonio Radici wrote:

 I am looking for a sponsor for my package libv8.
 
 * Package name: libv8
   Version : 1.3.9-1
   Upstream Author : Google v8 team
 * URL : http://code.google.com/p/v8/

Some comments, from only looking at .dsc file.

 - according to the home page, v8 only works on ia32 or ARM architectures, 
 so Architecture: any is surprising

 - I doubt that many sponsors will be happy DM-Upload-Allowed: yes
   on a NEW package.

d


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

Re: RFS: graph isomorphism package nauty

[David Bremner]

I found a silly packaging bug that causes the package to FTBFS almost
everywhere.

I uploaded a new version to 

  http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc

or from 

  git://git.debian.org/git/debian-science/packages/nauty.git

  signed tag: debian/2.4b7rc2

I know many people (including me) are not too enthusiastic about
spending time and effort on non-free software, however

  - nauty is the de-facto standard for graph isomorphism computation
  - I'm packaging it as a build depends for polymake, a GPLed package
   that I'm currently packaging for contrib, but hopefully will
   migrate to main by squeeze+1 (needs about a page of upstream code
   rewritten to replace the build-depends on nauty).  Several people 
   have inquired about polymake packages, so I don't think it is a pure 
   vanity package.

I hope that somebody at least downloads and test-builds this version,
since I'm pretty sure nobody did the last one :)

All the best,

David


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

Re: RFS: graph isomorphism package nauty

[David Bremner]

At Sat, 5 Sep 2009 13:32:26 -0500,
Steve M. Robbins wrote:

 I'm willing to sponsor nauty.

Thanks!

 I had a very quick look.  It builds and seems to produce correct packages.
 However, there is some weird output during the process:

   dh --with quilt /usr/share/topgit/tg2quilt.mk   

   dh: Unknown sequence /usr/share/topgit/tg2quilt.mk (choose from: binary 
 binary-arch binary-indep build clean install patch)

Ahh, yeah. So the problem (which I think is just aesthetic) is an
interaction between gmake and dh.  I have worked around it by replacing

,
| -include  /usr/share/topgit/tg2quilt.mk 
`

with

,
| include $(wildcard /usr/share/topgit/tg2quilt.mk)
`

Hopefully you don't find the solution uglier than the problem :)

The new package can be found in the same places.

 http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc

the new git tag is debian/2.4b7rc3

d


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

Re: RFS/RFC syncevolution and libsynthesis

[David Bremner]

At Sat, 22 Aug 2009 12:17:04 +0200,
Yves-Alexis Perez wrote:

 Hmhm, and syncevolution is supposed to include sync-ui, a GTK interface,
 which doesn't seem to be included in your package. Is it on purpose?

Not exactly on purpose; it just was not enabled by the default
configure, so I forgot about it. I'll see about enabling it.  It is
probably a matter of having the right packages installed at build
time.  It did build OK in a previous version.

About testing, I have been using the (free-as-in-beer) Funambol
service http://my.funambol.com.  Someone could also eventually package
the (AGPL3) java server software for Debian; ftp-masters have agreed
that this license is suitable for Debian main.

David


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

Re: RFS/RFC syncevolution and libsynthesis

[David Bremner]

OK, I made a new version of the source package the builds the
GUI. There is now, per suggestion, a separate sync-ui binary
package. This lets people who only want the command line client to
have significantly less dependencies.

http://mentors.debian.net/debian/pool/main/s/syncevolution/syncevolution_0.9+ds1-1.dsc

d




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

RFS/RFC syncevolution and libsynthesis

[David Bremner]

Dear mentors,

I am looking for a sponsor for my packages syncevolution and
libsynthesis.  Syncevolution is the command line application that
supports synching Evolution (and e.g. plain text files) with a SyncML
server.  Libsynthesis is a SyncML client library used by
Syncevolution.  Both packages are written in C++ and use
autoconf/automake as a build system. Packaging is straightforward dh7,
no patch system so far.

Details for syncevolution:
,
| * Package name: syncevolution
|   Version : 0.9+ds1-1
|   Upstream Author : Patrick Ohley
| * URL : http://www.syncevolution.org
|   Vcs-Git : 
git+ssh://git.debian.org/git/collab-maint/syncevolution.git
| * License : LGPL
|   Section : utils
| 
| It builds these binary packages:
| syncevolution - Evolution data synchronization program using SyncML
| 
| The package appears to be lintian clean.
| 
| The upload would fix these bugs: 404942
| 
| The package can be found on mentors.debian.net:
| - URL: http://mentors.debian.net/debian/pool/main/s/syncevolution
| - Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
| - dget 
http://mentors.debian.net/debian/pool/main/s/syncevolution/syncevolution_0.9+ds1-1.dsc
`

Details for libsynthesis
,
|  Package name: libsynthesis
|   Version : 3.0.3.28+ds1-1
|   Upstream Author : Synthesis AG
| * URL : http://www.synthesis.ch/indefero/index.php/p/libsynthesis/
|   Vcs-Git : 
git+ssh://git.debian.org/git/collab-maint/syncevolution.git
| * License : LGPL
|   Section : libs
| 
| It builds these binary packages:
| libsmltk0  - library for SyncML-DS (SyncML Data Sync) clients (shared 
libraries)
| libsynthesis-dev - library for SyncML-DS (SyncML Data Sync) clients 
(development files)
| libsynthesis0 - library for SyncML-DS (SyncML Data Sync) clients (shared 
libraries)
| 
| The package appears to be lintian clean.
| 
| The upload would fix these bugs: 540506
| 
| The package can be found on mentors.debian.net:
| - URL: http://mentors.debian.net/debian/pool/main/l/libsynthesis
| - Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
| - dget 
http://mentors.debian.net/debian/pool/main/l/libsynthesis/libsynthesis_3.0.3.28+
`

I would be happy to receive any feedback on these packages, or uploading if 
they seem 
OK. Note that both packages are in collab-maint.

Kind regards
 David Bremner


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

Re: vera++ on debian git: collab maint

[David Bremner]

Mathieu Malaterre wrote:

I am checking again today for the http view of the vera++ rep and I
still cannot see it.


Clearly the files are older than 6hours ago, right ?

Hi Mathieu.

Something (gitweb?) does not like the name vera++.git.  I cannot get it to show 
up even with the url

  http://git.debian.org/?p=collab-maint/vera++.git;a=summary

I made a clone verapp.git and it seems to show up fine at 

  http://git.debian.org/?p=collab-maint/verapp.git;a=summary

feel free to remove my collab-maint/verapp.git if you decide to use that name.

All the best, 

David




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

RFS: graph isomorphism

[David Bremner]

* Package name: nauty
  Version : 2.4~b7-1
  Upstream Author : Brendan McKay b...@cs.anu.edu.au
* URL : http://cs.anu.edu.au/~bdm/nauty/
* License : non-free/pacifist. See below.
  Programming Lang: C
  Section : non-free/math

  Description : graph isomorphism testing library, with command line tools

 nauty (no automorphisms, yes?) is a set of procedures for determining
 the automorphism group of a vertex-coloured graph. It provides this
 information in the form of a set of generators, the size of the
 group, and the orbits of the group. It is also able to produce a
 canonically-labelled isomorph of the graph, to assist in isomorphism
 testing.

nauty is a build dependency of polymake (ITP 461976)

Unfortunately upstream is not interested in relicensing the package.
Non-free bits of the license are follows:

  Copyright (1984-2009) Brendan McKay. All rights reserved. Permission
  is hereby given for use and/or distribution with the exception of sale
  for profit or application with nontrivial military significance.
  
It builds these binary packages:
libnauty-dev - library for computing graph automorphisms (development files)
libnauty0d - library to compute graph automorphisms and canonical labellings
nauty  - command line tools to compute graph automorphisms

The package appears to be lintian clean.

The upload would fix these bugs: 529094 (ITP)

I would be grateful if someone uploaded this package for me.

Warm regards
 David Bremner


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

Re: RFS: graph isomorphism package nauty

[David Bremner]

Sorry, doze-n-send, strikes again.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/n/nauty
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/non-free/n/nauty/nauty_2.4~b7-1.dsc


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

Re: git-buildpackage issues

[David Bremner]

At Mon, 3 Aug 2009 14:48:12 +0200,
Mathieu Malaterre wrote:

 $ \rm -fr rsvndump
 $ mkdir rsvndump
 $ cd rsvndump
 $ git init
 Initialized empty Git repository in
 /home/mathieu/Perso/gdcm/Sandbox/debian-med/build-area/rsvndump/.git/
 $ git-import-dsc --pristine-tar ../rsvndump_0.5.2.dsc

try git-import-dsc without the other steps. It works fine for me, and
creates the git repo for in a subdirectory of the current directory

 I found multiple links:
 * http://wiki.debian.org/Alioth/Git
 * http://wiki.debian.org/PackagingWithGit

The canonical place to look for documentation in Debian is
but /usr/share/doc/packagename.  In this case

  /usr/share/doc/git-buildpackage/manual-html/index.html

answers your questions about branch layout, I believe.





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

Re: RFS: task-spooler

[David Bremner]

Thanks for your work packaging this.  I'm not a DD, so I can't upload
it.

1) I expect whoever does sponsor it will ask you to compress
debian/changelog a bit. Typically there should be 1 changelog entry
per debian upload. Sorry I didn't mention this in my mail to BTS.

2) Is there any security risk in the control socket(s) for ts being
world readable? Or is that just controlled by users umask?

For any DDs pondering sponsoring this, 
- It's written in C
- a simple package using CDBS 
- for me, pbuilder and lintian clean.
- IMHO useful; I've been using it for running experiments for the 
last few days. 

David



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

Re: New package for pmgraph

[David Bremner]

At Thu, 11 Jun 2009 11:21:58 +0100,
Noe Gonzalez wrote:

I have just started to work with debian packages building, I create a
 package for the project pmgraph. The package is main to install the war
 file of the pmgraph project create a mysql database, and install and
 configure some extra software. 

Welcome to debian-mentors;

Probably you will get a better response if you fill in (and expand)
one of the templates on mentors.debian.net. See the list archives, or
sign up on mentors. Maybe someone knows a direct link to the templates.

In particular, most people will want to know the programming language
(Java I guess), more about what the package actually does, and the
license before they investigate further, and the output from lintian
(i.e., there shouldn't be any warnings or errors).

David
Writing on behalf of no-one but himself.


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

Re: RFS: scmbug

[David Bremner]

At Tue, 12 May 2009 10:26:50 -0700,
Kristis Makris wrote:

  Because it breaks some tools which check archive and makes NMUs
  needlessly complicated.
 
 It sounds like some tools need to be corrected.
 
 For example, man dpkg-buildpackage reports a -c parameter for
 specifying the control file from a directory OTHER than debian/. But
 this flag is not available for dpkg-buildpackage.
 
 One should be able to provide those files in a directory with any name
 they want.

Hi Kristis;

I think it is probably not too realistic to expect debian to adapt
their tools to your expectations.  When/if you get more familiar with
the tools and the debian packaging process, feel free to file bug
reports for suggested enhancements.  In the meantime, please consider
that despite what might come across as a bit arbitrary and rough toned
from time to time, people here are trying to lead you to a state of if
not best practices, at least good enough practices for your
package to enter the debian archive.

all the best, 

David


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

Re: RFS: scmbug

[David Bremner]

Kristis Makris wrote:
On Mon, 2009-01-26 at 19:16 +0100, Michal Čihař wrote:
What do I need to do to change the package into being non-native ?
How/where do I specify the non-native version number ?

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

(short answer: in debian/changelog)

 2. Please create proper debian directory and not by symlink to some
 directory with templates and other crap in it.

Debian is not the only distribution this system is packaged for. I don't
like to have a top-level directory called debian in the source code
repository. Instead, I have a directory called packaging/debian.

Usually the debian directory is added seperately, and not in the
upstream source.


 4. Build fails as there are some hardcoded paths: make: Entering an
 unknown directory make: ***
 /home/mkgnu/devel/scmbug.0.26.13/SCMBUG_RELEASE_0-26-13/src/tests:
 No such file or directory.  Stop. make: Leaving an unknown

There are no hardcoded paths in the build process. I'm not sure why this
error occurs. This link is no longer valid.

Perhaps you can try building your package using pbuilder (see debian
package of the same name) or cowbuilder. This is a good way to catch
these kind of errors.

 6. Please use litian:
 
 $ lintian -IE --pedantic scmbug_0.26.13.dsc
 W: scmbug source: ancient-standards-version 3.5.2 (current is 3.8.0)
 W: scmbug source: configure-generated-file-in-source config.log
 W: scmbug source: configure-generated-file-in-source config.status

Is it necessary that I correct warnings ?

Look at it this way. You ask someone to sign off on your package for
you; they are likely to find so many errors discouraging.  At least
the first one seems quite bad for a new package.  How did you get such
a version anyway?

David

Not a debian developer.



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

Re: How to get COMMIT right for an already exiting project ( MSEide-MSEgui in the Sid branch ) ?

[David Bremner]

At Thu, 09 Apr 2009 16:47:16 +0400,
Bobyr Raisa Efimovna wrote:
 
 Me'm the maintainer of this project but don't have access right to put 
 updates.
 Torsten Werner mail.twer...@googlemail.com and Mazen Neifer 
 ma...@freepascal.org helped me to join then with the COMMIT stuff but 
 currently don't respond to e-mail. Me'm  affraid that the project may be 
 considered abandoned dut to no updates in 3 months. 
 What to do ?

I guess you mean upload when you say commit. See the mentors FAQ at 

  http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

d


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

Re: quilt

[David Bremner]

Jaromír Mikeš wrote:

http://wiki.debian.org/HolgerLevsen#addingpatcheswithquilttoapackage

I used this how-to and my patch is done like this:
$ diff -Naur makefile-orig makefile-edited  makefile.patch

If you use quilt to generate the patches, then quilt will definitely
understand them, and put the name correctly in debian/patches/series,
etc...

See the section adding more patches later in Holger's page, or the
pkg-perl quilt howto referenced below.

d


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

RFC: new version of bibutils

[David Bremner]

Dear mentors, Dear debian-science people;

I am hoping that Yaroslav Halchen will continue sponsoring this (Hi
Yaroslav!), but I made quite a few changes in this new version
including:
 
 - soname bump
 - added a symbol file
 - converted packaging to topgit
 - two standards version bumps

Since this is my first experience with soname bumps and symbol files,
I would appreciate any feedback/sanity-checking on the packaging that
people have.

* Package name: bibutils
  Version : 4.1-1
  Vcs-Git : git://git.debian.org/git/debian-science/packages/bibutils/
  Vcs-Browser : 
http://git.debian.org/?p=debian-science/packages/bibutils.git
  Upstream Author : Christopher Putnam cdput...@ucsd.edu
  URL : http://www.scripps.edu/~cdputnam/software/bibutils/
  License : GPL-2+
  Language: C
  Section : text

It builds these binary packages:
bibutils   - interconvert various bibliographic data formats
libbibutils-dev - bibliography file converter, development kit
libbibutils1 - bibliography file converter, shared library

The package appears to be lintian clean.

The upload would fix these bugs: 485243, 506960

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/b/bibutils
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/b/bibutils/bibutils_4.1-1.dsc



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

Re: RFS: lxmusic

[David Bremner]

DreamerC wrote:

* Package name: lxmusic
  Version : 0.2.3-1+svn090103
  Upstream Author : [fill in name and email of upstream]
* URL : [fill in URL of upstreams web site]
* License : [fill in]
  Section : sound


Hi DreamerC;

Please fill in all those places that say fill in something. Thanks!

David


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

Re: packaging without make

[David Bremner]

At Sat, 21 Feb 2009 17:19:28 +0100,
Michael Rasmussen wrote:
 
 I intend to package a web based application which does not contain a
 build system - no Makefile etc.
 
 What is the best way to approach this situation in my package? Create a
 Makefile or whatever?

You can probably do everything you need from debian/rules, since that
is a Makefile. Otherwise you probably end up introducing a patch
system, making a patch the makes the Makefile, and generally making
life more complicated than needs be.  If you already are using quilt
or dpatch, then I guess it does not matter, and you might send a
Makefile upstream.

d



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

Re: RFS: libdata-compare-perl (updated package)

[David Bremner]

At Thu, 29 Jan 2009 20:41:04 -0430,
Miguelangel Jose Freitas Loreto wrote:
 I would be glad if someone uploaded this package for me.
 

You might consider joining the debian perl team, 

http://pkg-perl.alioth.debian.org

It is never a problem finding someone to upload packages from the 
team svn repository.

David




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

Re: RFS: premake

[David Bremner]

At Sun, 16 Nov 2008 19:16:51 -0600,
Boyd Stephen Smith Jr. wrote:
 
 [1  text/plain; utf-8 (quoted-printable)]
 On Sunday 2008 November 16 11:20, Kaido Kert wrote:

  Quite a few developers prefer premake for its use of Lua as scripting
  language, rather than using custom syntax.
 
 Sounds like it should wait until a package in Debian needs it.  The
 are quite a few packages in Debian -- are there any projects using
 premake whose software is in Debian.

For what it is worth (not very much, I suspect), I disagree that being
a build dependency for a Debian package is the only valid reason to
include a tool in Debian. I, like many others use Debian as a software
development platform. Having a good set of development tools is a big
selling feature for me.

I suspect there are other reasons why no-one has volunteered to review
Kaido's package, mainly the (non)-release of Lenny, and lua not being
as well known as other scripting languages.

Cheers,

David



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

Re: RFS: maxima (NMU)

[David Bremner]

At Sun, 27 Jul 2008 09:31:26 +0200,
Vincent Bernat wrote:
 
 [1  text/plain; iso-8859-15 (quoted-printable)]
 OoO  Pendant le  repas  du samedi  26  juillet 2008,  vers 19:36,  David
 Bremner [EMAIL PROTECTED] disait :
 
  I have prepared an NMU changing the underlying lisp to SBCL. This is
  semantically quite intrusive, but according to upstream SBCL is one of
  the dialects of common lisp they test with.
 
 Maybe  you can fix  gcl instead?  I don't  know if  it is  considered as
 something  to do,  but  you could  depend  on gcc-4.2  and compile  with
 gcc-4.2. There are some packages  that are doing this (for example qemu,
 which compiles with gcc-3.4).

Hi Vincent;

It is true that fixing GCL would probably fix more packages than just
maxima.  On the other hand, GCL looks like it needs help upstream as
well as in debian, and has at least on RC bug not fixed by gcc-4.2.  I
think a package with an RC bug for 152 days needs a new
(co-)maintainer rather than an NMU.

Maybe Peter de Wachter would like to adopt GCL?  Unlike me, he seems
to have some grip on the internals of GCL :-).

All the best,

David


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

Re: RFS: maxima (NMU) [UPLOADED]

[David Bremner]

Riku Voipio uploaded this NMU. Thanks all.

David



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

RFS: maxima (NMU)

[David Bremner]

Dear mentors,

Apparently due to problems with GCL, maxima currently either fails to
build (474909) or builds but fails its test suite (489871).

I have prepared an NMU changing the underlying lisp to SBCL. This is
semantically quite intrusive, but according to upstream SBCL is one of
the dialects of common lisp they test with.

If you want to get a handle on how intrusive the patch is in terms of lines 
changed,
you can have a look at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474909#27

The resulting package is not perfect of course, but I think it is
better than what we have now (which, AFAIKT, is no maxima in lenny).
Two issues in particular:

1)  The documentation index is read into lisp and the system redumped.  
This makes the image
about 1M bigger than required (OTOH, it is already 43M).
2) there is now versioned dependency on SBCL, since the core format turns 
out to be
unstable from release to release.

If you prefer, you can grab a copy of my packaging vcs:

   git clone alioth.debian.org:/git/debian-science/packages/maxima

The latter can be built with

git-buildpackage --git-ignore-new

It builds these binary packages: maxima - A computer algebra system --
base system maxima-doc - A computer algebra system -- documentation
maxima-emacs - A computer algebra system -- emacs interface
maxima-share - A computer algebra system -- extra code maxima-src - A
computer algebra system -- source code maxima-test - A computer
algebra system -- test suite xmaxima - A computer algebra system -- x
interface

The upload would fix these bugs: 474909, 489871

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/maxima
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/m/maxima/maxima_5.13.0-3.2.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 David Bremner



pgpurijOTvIuo.pgp
Description: OpenPGP Digital Signature

Re: 2nd RFS/RFC vrr: dynamic vector graphics with TeX text

[David Bremner]

 pabs == Paul Wise [EMAIL PROTECTED] writes:

pabs On Mon, Mar 24, 2008 at 3:40 AM, David Bremner
pabs [EMAIL PROTECTED] wrote:

 I am looking for a sponsor for my package vrr.  This is my
 second post, essentially unchanged.  Since last time I added
 icons and a .desktop file.
pabs ...
 Vcs-Svn: svn://svn.debian.org/pkg-science/vrr/ Vcs-Browser:
 http://svn.debian.org/wsvn/pkg-science/vrr

pabs Any particular reason you didn't CC the debian-science list?

Err, no _good_ reason.  I guess I just have not figured out the best
procedure. My idea so far had been to try on debian-mentors and then
if that did not work out, on debian-science.  

For those of you just joining us, the request for sponsors salespitch
can be found at
 
  http://lists.debian.org/debian-mentors/2008/03/msg00292.html




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

2nd RFS/RFC vrr: dynamic vector graphics with TeX text

[David Bremner]

Dear mentors,

I am looking for a sponsor for my package vrr.  This is my second
post, essentially unchanged.  Since last time I added icons and a
.desktop file.

* Package name: vrr
  Version : 0.9.4-1
  Upstream Author : VRR team [EMAIL PROTECTED]
  URL : http://atrey.karlin.mff.cuni.cz/projekty/vrr/
  License : GPL-2+
  Section : graphics
  Language/Libs   : C, Scheme, GTK+
  Vcs-Svn: svn://svn.debian.org/pkg-science/vrr/
  Vcs-Browser: http://svn.debian.org/wsvn/pkg-science/vrr

It builds these binary packages:
vrr- vector image editor with TeX support
vrr-doc- vector image editor with TeX support, documentation

 VRR is a vector image editor designed especially (but not only) for
 making illustrations of mathematical articles. Its main features are
 many types of geometric objects and keeping of their dependencies,
 cooperation with TeX, scripting in Scheme, real-size dimensions,
 support for a wide range of file formats (including PS, EPS, PDF, and
 SVG).

Why should this package be in Debian:

 VRR is somewhat similar to IPE, another drawing package already in
 Debian. Probably they both have advantages and disadvantages; one
 compelling feature of vrr that IPE does not have (as far as I know)
 is certain simple dynamic geometry features. You can compute the
 intersection of two b-splines (or line segments), move the control
 points of b-splines, and the intersection point moves.  Compared to
 something like kig, I think it has less powerful construction
 abilities, but has the important advantage that you can enter labels
 in TeX (in particular math). For mathematical diagrams destined for
 publication, this is really crucial.

The package is lintian -i -I clean, and builds in an sid (today) pbuilder.

The upload would fix these bugs: 448633

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/v/vrr
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/v/vrr/vrr_0.9.4-2.dsc

I would be glad if someone uploaded this package for me, or for any
comments on the packaging. You can see in debian/TODO, there are some
packaging issues I am aware of. The main ones are

  * currently ld flag --as-needed is used to work around the excessive
  libraries given by pkg-config. 
  * there is a fair sized doc package. I want to eventually make this
  a recommends, but since it contains the online help, this requires 
  a little gtk+ hacking to pop up a dialog when the doc
  package is not present.

Kind regards
 David Bremner



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

RFS/RFC vrr: dynamic vector graphics with TeX text

[David Bremner]

Dear mentors,

I am looking for a sponsor for my package vrr.

* Package name: vrr
  Version : 0.9.4-1
  Upstream Author : VRR team [EMAIL PROTECTED]
  URL : http://atrey.karlin.mff.cuni.cz/projekty/vrr/
  License : GPL-2+
  Section : graphics
  Language/Libs   : C, Scheme, GTK+
  Vcs-Svn: svn://svn.debian.org/pkg-science/vrr/
  Vcs-Browser: http://svn.debian.org/wsvn/pkg-science/vrr

It builds these binary packages:
vrr- vector image editor with TeX support
vrr-doc- vector image editor with TeX support, documentation

 VRR is a vector image editor designed especially (but not only) for
 making illustrations of mathematical articles. Its main features are
 many types of geometric objects and keeping of their dependencies,
 cooperation with TeX, scripting in Scheme, real-size dimensions,
 support for a wide range of file formats (including PS, EPS, PDF, and
 SVG).

Why should this package be in Debian:

 VRR is somewhat similar to IPE, another drawing package already in
 Debian. Probably they both have advantages and disadvantages; one
 compelling feature of vrr that IPE does not have (as far as I know)
 is certain simple dynamic geometry features. You can compute the
 intersection of two b-splines (or line segments), move the control
 points of b-splines, and the intersection point moves.  Compared to
 something like kig, I think it has less powerful construction
 abilities, but has the important advantage that you can enter labels
 in TeX (in particular math). For mathematical diagrams destined for
 publication, this is really crucial.

The package is lintian -i -I clean, and builds in an sid (today) pbuilder.

The upload would fix these bugs: 448633

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/v/vrr
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/v/vrr/vrr_0.9.4-1.dsc

I would be glad if someone uploaded this package for me, or for any
comments on the packaging. You can see in debian/TODO, there are some
packaging issues I am aware of. The main ones are

  * currently ld flag --as-needed is used to work around the excessive
  libraries given by pkg-config. Or maybe bad use of pkg-config
  upstream.
  * there is a fair sized doc package. I want to eventually make this
  a recommends, but since it contains the online help, this requires 
  a little gtk+ hacking to pop up a dialog when the doc
  package is not present.

Kind regards
 David Bremner


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

Re: RFS: Perl packages update.

[David Bremner]

 Francesco == Francesco Cecconi [EMAIL PROTECTED] writes:

Francesco Hi DD, I'm looking a sponsor for update my perl
Francesco packages:

Dear Francesco:

It would be great if you would join the pkg-perl team. The DDs there
are are very helpful about uploading packages. 

See http://alioth.debian.org/projects/pkg-perl/

With your 4 packages, the team would maintain 664, the neighbour of the
beast :-)


David


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

Re: Program not supporting UTF8==bug ?

[David Bremner]

 Thibaut == Thibaut Paumard [EMAIL PROTECTED] writes:


Thibaut following a [1]bug report on one of my packages
Thibaut ([2]yorick), I realize this interpreter has trouble
Thibaut dealing with UTF-8 strings. Is it considered a bug in
Thibaut itself?

This wiki page [A] suggests that there might be some consensus around
lack of UTF-8 being a bug, but not a release critical bug. I don't
know of any formal policy. Perhaps someone more expert than I
(i.e. almost anyone :-) ) can comment.


IaNaDD, 

d

[A] http://wiki.debian.org/UTF8BrokenApps


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

Re: RFS/RFC: bibutils; convert bibliographic data between formats

[David Bremner]

 Charles == Charles Plessy [EMAIL PROTECTED] writes:

Charles Le Sun, Jan 27, 2008 at 04:42:39AM +0100, David Bremner a
Charles écrit :

Charles I have added your package on the following wiki page:
Charles http://wiki.debian.org/DebianScienceBibliography If you
Charles want, can you update it when bibutils gets accepted in
Charles Debian?

Sure, and I will send a message debian-science when I upload the next
version to mentors.

Charles Although I am not a DD, I have a few comments on your
Charles package:

Thank you for your review.

Charles * debian/copyright: bibutils is released under the GPLv2
Charles or any later version. Also, you have to include the thee
Charles paragraphs from the How to Apply These Terms to Your New
Charles Programs section of the GPL to the copyright
Charles file. Lastly, the copyright of C. Putnam starts from
Charles 1995.

Ahh, OK, I'll sort this out.

Charles * debian/docs: has a duplicated line.

Hmm, good catch. Actually this file is only about building so I
deleted it.

Charles Personnaly, I do not build the manpages
Charles at buildd time anymore, I just regenerate them only if
Charles they really changed, and include the .1 files in the
Charles source package. 

Hmm, OK, I see how this could reduce the build dependencies.  I have
some vague memory of dh_link for man pages being frowned upon, but
maybe it is just slightly more work.  It seems slightly nicer to use
to use the refname/refname than a seperate list of links (e.g. for
using the file outside Debian), but it is not a big deal.

Charles * debian/control: are you sure you need the autotools.dev
Charles package? Will the config.(sub|guess) files be used by the
Charles configure script?

Ah, again I missed this. Actually the package does not even use
autotools, so I removed this.

Charles * debian/rules: are you sure that you need to run the
Charles configure script?  If not, you can drop the
Charles build-dependancy on csh.

Hmm. The script is simple, and I could write a replacement, but
something has to generate a Makefile. The script could be replaced
with a few sed invocations. This makes the package slightly more
fragile with respect to upgrades; do you think this is worth it to
drop the dependency? 

Charles PS: actually, debhelper is very smart and replaces the
Charles .so manpages by symlinks !

Right, so do you think there is any reason not to rely on this?  

Thanks again for your help,

David