Re: RFS: gnomecatalog

[Matthew Palmer]

On Tue, Jan 08, 2008 at 08:02:02PM +0100, José Sánchez Moreno wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "gnomecatalog".
> 
> * Package name: gnomecatalog
>   Version : 0.3.1-1.0

That '.0' at the end isn't necessary.

>   Upstream Author : [fill in name and email of upstream]
> * URL : [fill in URL of upstreams web site]
> * License : [fill in]

*cough*

> It builds these binary packages:
> gnomecatalog - Cataloging software for CD, DVD, and hard disk files

Do you have a long description?

- Matt


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

Re: Config files which are writable by www-data

[Matthew Palmer]

On Sat, Feb 09, 2008 at 10:09:13AM +0100, Roland Gruber wrote:
> The problem is that my application provides a set of default templates
> for user creation. These files must be editable via the application
> itself and therefore reside in /var/ldap-account-manager.

I most sincerely hope they do not.

> But the files are overwritten on every package installation because they
> are not treated as config files in Debian's sense.

Well, don't do that, then.  Ship the template files somewhere else, and then
copy them into /var if they're not already there.

> Now I think about moving the files to /etc. But Debian policy sais that
> files in /etc should be owned by root and writable only by the user.
> 
> So what can I do? Would it be ok to assign these files to group www-data
> and allow the group write access? Or would it be better to own them by
> www-data and not root?

There are already some files in /etc that are writable by www-data, so
that's a possibility too.  It comes down to direct admin editability -- is
it expected that sysadmins may want to futz around with these template files
using a text editor, or is the only sensible way of dealing with these files
through the application?  If the former, /etc.  If the latter, /var.

- Matt


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

Re: Config files which are writable by www-data

[Matthew Palmer]

On Sun, Feb 10, 2008 at 12:02:02PM +0100, Roland Gruber wrote:
> Matthew Palmer schrieb:
> > Well, don't do that, then.  Ship the template files somewhere else, and then
> > copy them into /var if they're not already there.
> 
> that is probably the best solution. I think I will put them in
> /usr/share/doc/ldap-account-manager/examples and copy them from there to
> /var.

Except that the contents of /usr/share/doc must not be relied upon for the
proper functioning of your package.  Somewhere under /usr/share/l-a-m is the
correct place for these sorts of things.

- Matt


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

Re: RFS: obm

[Matthew Palmer]

On Tue, May 06, 2008 at 11:56:44AM +0200, Sylvain Garcia wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "obm".
> 
> * Package name: obm
>   Version : 2.1.9-1
>   Upstream Author : [fill in name and email of upstream]
   ^^

That's good advice.

- Matt


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

Re: Modifying existing packages

[Matthew Palmer]

On Mon, Jun 16, 2008 at 11:20:40PM -0400, Jerry Stuckle wrote:
> I'm new to this end - and don't know if what I want is possible or not.
> But here goes.

What you want is quite possible, and something a lot of people do a lot.

> I need to modify some of the stock Debian packages for different
> options.  For instance, I need to modify
> Exim to include MySQL support.  I have several other packages with
> similar needs.
>
> What I need is a pointer to instructions on how I can get the the
> information for how these packages
> were built so I can modify them to meet my needs.  I'd like to change
> them as little as necessary to
> maintain compatibility with other packages.
>
> I've looked through a lot of documentation and haven't figured out how
> to get the original build
> information.  But with all the available info out there, I probably
> missed it, also.  So if someone can
> at least provide a pointer to doc on where I should start, I'd
> appreciate it.

I'm not aware of any canonical documentation that specifically addresses
your needs, since it's been so long since I learnt this stuff.  In general,
what you want is the source package that corresponds to the binary package
you want to build, and that can usually be obtained by running 'apt-get
source '.  From there, you patch the package to suit your needs and
then rebuild/compile the binary package (for which there are any number of
methods, and documentation available).

A quick Google search has found a couple of things that might be of use to
you:

http://www.murrayc.com/blog/permalink/2006/04/21/building-modified-debian-packages/
http://www.debian-administration.org/articles/20

- Matt


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

Re: Setup Clean Etch Build Environment

[Matthew Palmer]

On Tue, Jul 22, 2008 at 02:08:34PM +0200, Marko Randjelovic wrote:
> How to set clean Etch build environment, so I can backport a package from
> testing to etch?

pbuilder, just like you would setup a lenny or sid build environment.

- Matt


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

Re: GPL v1 files

[Matthew Palmer]

On Mon, Aug 25, 2008 at 04:08:08AM +0200, Noel David Torres Taño wrote:
> Hello mentors:
> 
> I have some files in the package I'm maintaining which are (most probably) 
> under GPLv1. And it is NOT in /usr/share/common-licenses
> 
> What must I do? To install the GPL-1 file there or to express the whole 
> license text in debian/copyright and reference it?

Put the whole licence text in debian/copyright.  Try clarifying the licence
position with upstream, though, if you can.

- Matt


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

Re: 'cdarch' has a dash version

[Matthew Palmer]

On Sat, Oct 04, 2008 at 10:43:00PM +0200, Jann Horn wrote:
> Er... I haven't got a file named "*.orig.tar.gz". I think it's because I
> myself made the program I want to put in a package.
> So my question is: How can I remove this dash?

You don't want to remove the dash, you want to fix your package so that it's
a proper non-native package.  For that, the upstream tarball should match
_.orig.tar.gz.

- Matt


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

Re: Packaging with CMake

[Matthew Palmer]

On Mon, Oct 06, 2008 at 01:45:10AM +0200, Laurent Léonard wrote:
> I try to build the package kio-ftps, but the 0.2 version (for KDE 4) uses 
> CMake. What is the procedure to build a Debian package with CMake ?

It's no different to any other package.  You put cmake in the build-deps,
run it to build and install the software, then use dh_install to shuffle the
files where they need to go.

- Matt


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

Re: howto create debian package with conf files

[Matthew Palmer]

On Sat, Oct 25, 2008 at 11:21:19PM +0200, lucas kenter wrote:
> I would like to create a debian package for a simple project that I've
> created. The project contains only scripts, so there is no makefile or
> anything like that. For the script to work I would like to prompt for some
> simple questions like "what url should be used", "what organisation does
> this computer belong to".
> 
> I've created a postinst script that asks these questions and writes them in
> a configuration file. (and this configuration file is listed in conffiles)
> 
> Now the problem that I have is that when I reinstall this package, or
> upgrade it, all the questions are asked again.
> 
> After some research I'm still not able to find a simple example or howto to
> do this right.
> 
> - Is it necessary to use debconf to accomplish this?

I'm not sure if Policy mandates using Debconf, but since this sounds like
it's a local-only package, you don't need to follow policy anyway.  I'd
certainly *recommend* using debconf, though, as it provides both a
standardised interface for the asking and answering of questions, a way to
avoid re-asking questions, and also an easy means of automating the
answering of the questions with preseeding, should you wish to do so in
the future.

> - I thought that the postinst script was called with an argument
> install/upgrade/configure and so I could ask my question only when it was
> and install or configure, but this doesnt work. apperantly upgrading a
> package also uses argument configure...

The postinst is called with the configure argument to say "please configure
the package that has just been installed", whether or not that installation
is a new one or an upgrade.  What might be of use to you is the fact that
the second argument to the postinst call is the previous version that was
fully configured.  So you could do something like this in your postinst:

if [ "$1" = "configure" -a "$2" = "" ]; then
# Ask your questions
fi

Because the only time that the second argument will be empty is on the
initial install -- after that, $2 will always contain the previously
configured version.

> I've tried to look at packages like postfix, to see how they do it, but
> those are to difficult for my simple scripting skills :-(

I don't know if the 'hello' package has any debconf in it, but it's usually
considered the canonical "how to get started" package.  Otherwise, I can't
think of any specific packages that are good examples of the debconf art,
but I know that MTAs in general are far too complex to make good examples
for new packagers.

- Matt


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

Re: howto create debian package with conf files

[Matthew Palmer]

On Sun, Oct 26, 2008 at 12:10:26AM +0200, lucas kenter wrote:
> Wow,
> 
> Thanks for the quick and helpfull response Matthew and ehm... I suppose this
> is what they mean by "Debians helpfull community"! I'm possitively amazed!
> :-D
> 
> one more question though,
> 
> >  So you could do something like this in your postinst:
> >
> > if [ "$1" = "configure" -a "$2" = "" ]; then
> ># Ask your questions
> > fi
> >
> > Because the only time that the second argument will be empty is on the
> > initial install -- after that, $2 will always contain the previously
> > configured version.
>
> Would this still allow users to issue a dpkg-reconfigure?

Now *that* is an interesting question I've never explored.  I'll leave that
one up to you to test.  If you put:

echo $*

at the top of your postinst, though, and then install, upgrade, and
dpkg-reconfigure your package and see what happens...

- Matt


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

Re: RFS: dhcp-probe, another try to request with a lot of update

[Matthew Palmer]

On Thu, Nov 27, 2008 at 10:14:56PM +0100, Laurent Guignard wrote:
> Michal ??iha?? a écrit :
> > Hi
> > 
> > [...]
> > 
> > Quick look at the package:
> > 
> > - any reason why it is Architecture: i386?
> 
> 
> In reason of the libraries dependency.
> libnet1 package is for i386 architecture and dhcp_probe use it with
> previous update of this library in order to provide specific functions
> needed by dhcp_probe.
> 
> #apt-cache show libnet1
>   Package: libnet1
[...]
>   *Architecture: i386*

That shows the binary package information on your system.  If you'd run that
on an arm system, dhcp-probe would now be an arm-only package.

Examine the source package info, or just look at
http://packages.debian.org/sid/libnet1 for the list of architectures that a
package is built for.

But at any rate, your argument is bollocks -- packages should have the
architectures listed that *it* supports, regardless of it's dependencies. 
What if libnet1 *was* an i386-only package at the moment, but then in a
month's time someone makes it truly arch-neutral and it builds for all
arches?  Much easier for everyone if your package doesn't need any changes
to support more arches.

> May be i am wrong, but i think it is impossible to build a package on
> architectures that are not supported by needed libraries ?

It's impossible to build, yes, but that situation will be adequately dealt
with by the autobuilders.

> > - why you manually create some directories and files? dh_install and
> > dh_installdirs should do the job better and nicer. Anyway most of these
> > dirs do not have to be created (examples) or look simply wrong to me
> > (/etc/default/dhcp-probe)

[...]

> The /etc/default/dhcp-probe directory is used to store all configuration
> files needed (one for each interface on which dhcp-probe is used). I
> thought that it was the best solution instead of spreading all
> configuration files directly in /etc.

dh_installinit will automatically put a default file in place if
asked nicely.  See the appropriate man page for more details.

- Matt


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

Re: RFS: dhcp-probe, another try to request with a lot of update

[Matthew Palmer]

On Sat, Nov 29, 2008 at 01:37:48PM +0100, Laurent Guignard wrote:
> I have another question about architecture :
> How is it possible to check if a package could be built on architecture
> without the appropriate hardware ?
> I can say that dhcp-probe could be build on i386 and any compatible
> architectures and with the upstream notes, i can say that dhcp-probe
> could be built on sparc but how to test on other architectures ?

You don't test it yourself.  When it's uploaded with Arch: any, it gets
built on all architectures.  If the build fails, you'll be notified of it
(via a bug).  Those bugs then get fixed.  If it builds, but fails to run
properly on an arch, then someone will find that out and lodge a bug too.

> >> The /etc/default/dhcp-probe directory is used to store all configuration
> >> files needed (one for each interface on which dhcp-probe is used). I
> >> thought that it was the best solution instead of spreading all
> >> configuration files directly in /etc.
> > 
> > dh_installinit will automatically put a default file in place if
> > asked nicely.  See the appropriate man page for more details.
> 
> Yes, dh_installinit will automatically put *a* default file in place.
> As you noticed, it place *A* default file.
> That i would like to do, is to place at least one file and i doesn't
> know how many because it depends of the number of network interfaces the
> host on which the package is installed has !

Uhm... no.  That's not how it's done.  /etc/default/ is a shell
fragment that configures the operation of /etc/init.d/.  /etc/default
is not a place for random config junk because you don't want to mkdir
/etc/.

I repeat: DO NOT put your package's general config data in /etc/default. Put
all that configuration data in /etc/dhcp-probe.  If the init scripts for the
package are currently structured such that there is one init script per
configured interface, someone needs to learn to use for loops.

- Matt


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

Re: RFS: hexec

[Matthew Palmer]

On Mon, Dec 01, 2008 at 03:04:33PM +0100, Alexander Block wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "hexec".
>
> Package name: hexec
> Version : 0.2.0-1
> Upstream Author : Alexander Block <[EMAIL PROTECTED]>
> URL : http://sourceforge.net/projects/hexec/
> License : GPL
> Section : devel
>
> It builds these binary packages:
> hexec   - The hexec tool itself

That's a really crap short description.

- Matt


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

Re: Question about bug hunting

[Matthew Palmer]

On Tue, Dec 02, 2008 at 09:11:36PM +0100, Laurent Guignard wrote:
> Is there any means to know if someone work on a bug from RC bug ?
> rc-alert or popbugs show all RC bugs of our packages but if someone is
> already on, it isn't necessary to work to solve the bug.
> Are all works in progress referenced somewhere ?

There's no real "This is being worked on" flag in the BTS; the problem with
a flag like that is that if someone gives up or has to stop working on the
bug there's no guarantee that they'll be able to or care enough to remove
the flag again.  It's courtesy to perhaps send an e-mail to the bug saying
"I'm working on this, I should have a fix within $TIMEFRAME", but it's
certainly not something you can rely on happening.

In practice, it's very, very rare for there to be collisions in bugfixes,
except in specific instances like bug-squashing parties (when there are
protocols in place to minimise problems).  There's plenty of bugs to be
fixed, and not that many people actively working on them, so I'd be inclined
to not worry so much about possible duplication of work and just dig in and
fix something that you think needs fixing.

- Matt


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

Re: RFS: dhcp-probe, another try to request with a lot of update

[Matthew Palmer]

On Wed, Dec 03, 2008 at 04:14:06PM -0800, Michael Tautschnig wrote:
> [...]
> > 
> > A new version of the package is available which integrates all updates
> > you noticed.
> > I controlled all files twice but an error or anything else could be
> > hidden in.
> > 
> > You will find all links need to reach the package on mentors.debian.net
> > 
> > The package can be found on mentors.debian.net:
> > - URL: http://mentors.debian.net/debian/pool/main/d/dhcp-probe
> > - Source repository: deb-src http://mentors.debian.net/debian unstable
> > main contrib non-free
> > - dget
> > http://mentors.debian.net/debian/pool/main/d/dhcp-probe/dhcp-probe_1.2.2-2.dsc
> >
> [...]
> 
> Sorry, there are problems in your source package:
> 
> - dget ... && dpkg-source -x dhcp-probe_1.2.2-2.dsc fails because .orig.tar.gz
>   does not match the size noted in the .dsc file, apparently it was modified
>   afterwards.

Are the modifications to the tarball documented in the source package
somewhere?

> - The unpacked directory should better be named $package-$version, not
>   $package_$version.

Only if the tarball has been repacked for other reasons.  Renaming the root
directory of a tarball is *not* sufficient reason to repack it.

- Matt


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

Re: Listing dependencies with specific versions

[Matthew Palmer]

On Tue, Dec 09, 2008 at 04:06:46PM +, Neil Williams wrote:
> On Tue, 9 Dec 2008 22:18:01 +0900
> "Paul Wise" <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins <[EMAIL PROTECTED]>
> > wrote:
> > 
> > > New symbols. It specifically has support for embedding images into
> > > the FLAC file. This was introduced in 1.2.
> > 
> > Looks like you just found an RC bug in libflac++6 - includes new
> > symbols in version 1.2.1-1 according to mole but the shlibs does not
> > depend on that version:
> 
> That is not a bug - the package building against it merely has to
> require that version.

Sure, if the package that is building needs those symbols.  But what about
other packages that *don't* necessarily need those symbols, but get built
against the newer version of the library anyway?  Those symbols can end up
in the built binary, but unless dpkg-shlibdeps happens to know that symbols
have been added, it won't know to version the library dependency and all
hell breaks loose.

The solution: shlibs files, which list the last package version in which a
new symbol was added to the library, so that the packaging system can make
sure that that newer version is available to packages that need the extra
symbols.

> The bug only arises if symbols are removed or function prototypes are
> changed in existing symbols.

Not quite.  If you remove symbols or change the type of a symbol, you need
to bump the SONAME because that's the only piece of information that the
dynamic linker has to be able to determine if a *newer* library will or
won't work with a particular binary.

If you add symbols, you don't need to bump the SONAME because the library is
still backwards-compatible -- the SONAME effectively defines a "base ABI"
that will continue to work into the future, and when that no longer applies,
*then* the SONAME is bumped.

> If it was, we'd be on libglib.so.7787.0.0 by now.

*cough*

/usr/lib/libglib-2.0.so.0.1600.6

Not quite, but close...

> > Hopefully more libraries will adopt the new dpkg symbols stuff so that
> > this can be detected and fixed more often.
> 
> The fix is only necessary if the symbol has CHANGED - added symbols can
> be managed perfectly well without a SONAME bump.

Yes, you are perfectly correct about this.  But we're not referring to a
SONAME bump, we're talking about putting correct information in the shlibs
file regarding new symbols.

- Matt


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

Re: debian OID / dicom3tools packaging

[Matthew Palmer]

On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote:
> http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration
> 
> ...
> To use SNMP one needs an Enterpise UID assigned by IANA, which is free
> and may also be used for any other purpose that requires a UID root.
> 
> * http://www.iana.org/cgi-bin/enterprise.pl to register
> * http://www.iana.org/assignments/enterprise-numbers to see the registry
> 
> 
> You use the assigned enterpise number as  in "1.3.6.1.4.1."
> ...

I'm not online at the moment, so I can't read the FAQ reference given, but
this most categorically *not* what an OID is supposed to be used for,
*especially* in the SNMP context.

An OID is supposed to provide a globally-unique but *stable* tree path to
retrieve an SNMP value.  You can't write a MIB if your OIDs are always
changing out from underneath you.

Instead, the SNMP MIB for this device should provide a table mapping the
UUID of the device to entries in a table, or (if there's only one device per
SNMP agent) then you can shortcut the table part of the whole thing.

>   Which would mean for debian that I could simply be using
> 1.3.6.1.4.1.9586 (https://dsawiki.debian.org/dsawiki/iana). Would that
> be ok ? Should I be using some kind of subspace of this UID ? Since
> this would be done for debian-med I would suggest:
> 
> $ echo "med" | od -b
> 000 155 145 144 012
> 
>  1.3.6.1.4.1.9586.155.145.144
> 
> This would be the toplevel (root) of all UID generated from the
> dicom3tools package.

Despite the similarity in acronym, an OID is not like a (U)UID.  If you need
a globally-unique value to identify a device or otherwise, we have whole
RFCs dedicated to the task of describing how to generate one.  Trying to
brutalise an OID tree into doing the job is just plain *weird*, not to
mention a bunch of other less-complimentary phrases.

- Matt


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

Re: debian OID / dicom3tools packaging

[Matthew Palmer]

On Tue, Jan 27, 2009 at 01:32:34PM +0100, Mathieu Malaterre wrote:
> So IMHO only large institution would need to change that to their own
> OID, unfortunately this is a compile time variable...

Fix that.  Making something that has to be unique to each installation a
compile-time flag is stupendously stupid.  Read it out of a config file. 
Then have the postinst generate a UUID properly, and you're pretty much
guaranteed global uniqueness.

See my other message about (not) using an OID for this purpose.

- Matt


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

Re: debian OID / dicom3tools packaging

[Matthew Palmer]

On Wed, Jan 28, 2009 at 07:44:27PM -0600, Steve M. Robbins wrote:
> Hi,
> 
> To begin, I think there's some confusion about UID and OID.  They
> are actually the same thing, according to Clunie:
> 
>   What DICOM calls "UIDs" are referred to in the 
>   ISO OSI world as Object Identifiers (OIDs). 

May I be the first to say, WT*F*?

- Matt


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

Re: RFS: fspy - filesystem activity monitoring tool

[Matthew Palmer]

On Fri, Jan 30, 2009 at 05:45:44PM +0100, Giuseppe Iuculano wrote:
> I am looking for a sponsor for my package "fspy".
> 
> * Package name: fspy
>   Version : 0.1.0-1
>   Upstream Author : Richard Sammet 
> * URL : http://mytty.org/fspy/
> * License : GPL
>   Programming Lang: C
>   Section : misc
> 
> It builds these binary packages:
> fspy   - filesystem activity monitoring tool

Looks good, except that the manpage mentions info pages which don't appear
to exist in the package or upstream tarball.

Fix that up, reupload to m.d.n, let me know, and I'll upload it.

- Matt


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

Re: RFS: fspy - filesystem activity monitoring tool

[Matthew Palmer]

On Sat, Jan 31, 2009 at 09:54:30AM +0100, Giuseppe Iuculano wrote:
> Matthew Palmer ha scritto:
> 
> > Looks good, except that the manpage mentions info pages which don't appear
> > to exist in the package or upstream tarball.
> 
> Fixed.

Looks good.  Uploaded.  Ping me directly for future uploads if you like.

- Matt


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

debian-mentors FAQ updated

[Matthew Palmer]

I've made several updates to the debian-mentors FAQ in the last few days,
including making mention of sponsors.debian.net, pointing to some revision
control howtos, a comprehensive description of native vs non-native
packages, and a pointer to the REJECT-FAQ (with a list of things to check
for in packages before upload).

This round of changes includes material or suggestions from Paul Wise, Joost
van Baal, Nico Golde, Matthijs Mohlmann, Jamie Jones, and Jay Berkenbilt.  I
thank all of them for their contributions.

I'd encourage every new and prospective maintainer to check out the FAQ, and
if anyone has any suggestions on how to improve the FAQ further, I will
endeavour to incorporate your suggestions quicker than I have in the recent
past.

The FAQ is at: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

- Matt


signature.asc
Description: Digital signature

Re: debian-mentors FAQ updated

[Matthew Palmer]

On Fri, Sep 09, 2005 at 01:33:55PM +0100, Ben Hutchings wrote:
> George Danchev wrote:
> > On Friday 09 September 2005 15:01, Matthew Palmer wrote:
> > --cut--
> > > The FAQ is at: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html
> > 
> > a minor typo at: 
> > "How do I effectively keep track of my packaging changes?
> > At the basic level, it's a good idea to keep an archive of the completed 
> > source packages that get uploaded. Although there are services which keep a 
> > record of everything in the archive (such as archive.debian.net)"
> > 
> > Since archive.debian.net does not exist, and archive.debian.org doesn't fit 
> > the context either I assume you mean http://changelogs.debian.net/ here ?
> 
> I rather think this should be <http://snapshot.debian.net>.

Bonus point for Ben.

Yes, I did mean snapshot.debian.net, but was hacking on the FAQ away from
'net access, and didn't verify that my memory was correct before I uploaded. 
Thanks to George, also, for pointing out my mistake.

- Matt


signature.asc
Description: Digital signature

Re: pre-sponsored-package checklist (was: Re: RFS: FileZilla3 - GUI ftp client of wxwidgets2.6)

[Matthew Palmer]

On Thu, Sep 29, 2005 at 01:13:19PM -0400, Justin Pryzby wrote:
> On Thu, Sep 29, 2005 at 06:30:29PM +0800, Paul Wise wrote:
> > On Thu, 2005-09-29 at 12:16 +0200, Joost van Baal wrote:
> > 
> > > On http://www.debian.org/ there is a link called "Help Debian", to
> > > http://www.debian.org/devel/join/ ("How You Can Help".
> > > 
> > > Perhaps that page should incorporate your (very nice!) checklist.
> > > And/or maybe it should link to
> > > http://people.debian.org/~mpalmer/debian-mentors_FAQ.html .
> > 
> > I'll send a patch to debian-www, thanks for the pointer.
> That's mathew's personal page, bug him :)
> (Hi Mathew!)

Hey Justin!

Yes, I've added Paul's checklist to the FAQ.  I announced this earlier, but
only to Joost...   (note to self: it's 'L', not 'r')

- Matt


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

Re: Sponsors and the Uploaders field (was: RFS: dict-freedict ...)

[Matthew Palmer]

On Fri, Sep 30, 2005 at 06:03:10PM +0200, Christoph Berg wrote:
> Re: Thaddeus H. Black in <[EMAIL PROTECTED]>
> > Pierre Machard wrote:
> > > Do not worry if I set my name as uploader, so that it's easy for me to
> > > track packages I am sponsoring.
> 
> The PTS does perfectly suit this, and you can even subscribe to a
> package before it is in the archive. There is no need to add yourself
> to Uploaders unless you really want to co-maintain the package.

The primary reason I've seen expressed for desire to be added to the
Uploaders field is so that the sponsor can get a quick summary of a
sponsored package's state from the excellent developer.php script on
qa.debian.org.  I've noticed that being able to do a "subscription" in
developer.php is a requested feature, but I can't see a way to do that yet.

- Matt

Re: Sponsors and the Uploaders field (was: RFS: dict-freedict ...)

[Matthew Palmer]

On Wed, Oct 05, 2005 at 01:40:03AM +0200, Christoph Berg wrote:
> Re: Matthew Palmer in <[EMAIL PROTECTED]>
> > The primary reason I've seen expressed for desire to be added to the
> > Uploaders field is so that the sponsor can get a quick summary of a
> > sponsored package's state from the excellent developer.php script on
> > qa.debian.org.  I've noticed that being able to do a "subscription" in
> > developer.php is a requested feature, but I can't see a way to do that yet.
> 
> I'm working on it. Jeroen committed a first patch on Sunday, which
> makes the internal backend data more handy. There is no nice interface
> yet, but you can already put
> 
>   &packages=bla+foo+bar

Whoa... mondo cool.

I'd be inclined to perhaps have a separate page (or at least a well separate
mode) that allowed someone to add packages to their "list" (like a "add new
package:" box at the top) and then they can bookmark that particular page. 
Alternately, if there's persistent storage behind the page, a similar thing
but without the need to bookmark would be handy.

Very, very cool feature already though. I like having the collection of
packages in a separate table too... keeps things clean.

- Matt


signature.asc
Description: Digital signature

Re: upgrades skipping stable releases

[Matthew Palmer]

On Sun, Oct 16, 2005 at 05:00:01PM +0200, Stefano Zacchiroli wrote:
> On Sat, Oct 15, 2005 at 09:48:26PM +0200, Christoph Berg wrote:
> > You can remove the transition package now; upgrades skipping a stable
> > release are not supported.
> 
> Interesting, is this policy or just common practice in past releases?

Policy.

- Matt


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

Re: upstream changed the source tarball name...

[Matthew Palmer]

On Sat, Nov 26, 2005 at 04:53:50PM -0700, Al Stone wrote:
> What's puzzling me is this:
> 
>-- the original source tarball used to be acovea-4.0.0.tar.gz,
>   and I used the name acovea_4.0.0.orig.tar.gz, as is proper.

Check.

>-- upstream has changed the name of the source tarball so that
>   it's now called 'libacovea-5.1.1.tar.gz', implying I should
>   use 'libacovea_5.1.1.orig.tar.gz'.

Not necessarily.  Upstreams do all sorts of bong-ass stuff.  Considering:

>-- at the same time, the new source (5.1.1) provides the same
>   binaries as the old source (4.0.0),

It seems like it's reasonable for the release-as-a-whole to still be called
acovea, but to add the shared library packages as extra binary packages, as
you rightly suggest:

>   PLUS what makes sense
>   to package as 'libacovea-5.1-5*deb' (a shared library) and
>   'libacovea-dev*deb' (the development files).  Hence, it seems
>   to make sense to have the 'debian/control' file create three
>   binary packages -- acovea, libacovea, and libacovea-dev.
> 
> So, here's the questions:
> 
>-- if I follow the rules, the 'control' file should also now say
>   'Source: libacovea', correct?  It seems to make sense that it
>   should.

If it were my package, I'd make the judgement call to still call the source
package acovea, name the source tarball acovea_5.1.1.orig.tar.gz, and build
the extra binary packages.

>-- And the 'acovea' binary package now being created should Conflict/
>   Replace with older versions, correct?  This also seems to make
>   sense.

I can't think of any reason why you'd need to C/R acovea against itself --
you can't have two versions of the same package installed in any case. 
You'd probably need to C/R libacovea 5.1.1 against acovea 4.0.0, if the old
acovea binary package included the shared library (or other files which
libacovea now provides).

>-- But, how do I properly inform the ftp masters that the old
>   'acovea' source has been replaced by the new 'libacovea' source,
>   even though both produce a binary package called 'acovea' (and
>   should do so)?  ITP the new stuff and file the bug to remove the
>   old?

Upload.  They're clever people, they'll sort it out.  If in doubt, make the
changelog nice and verbose.

- Matt


signature.asc
Description: Digital signature

Re: Building packages with epoch

[Matthew Palmer]

On Sun, Dec 11, 2005 at 11:26:43AM +0100, Norbert Preining wrote:
> Dear all!
> 
> I have a question concerning packages with epoch: We are preparing a NMU
> (maintainer approved) for tipa which currently is of version
>   2:1.2-2
> When I get the source package via apt-get source tipa and rebuild the
> package with
>   dpkg-buildpackage -us -uc -rfakeroot
> I get a binary package called
>   tipa_1.2-2_all.deb
> and not
>   tipa_2%3a1.2-2_all.deb
> 
> But the internal version number (in the control file) of the package 
> is correct, as one can see when calling scanpackages I get a correct
> entry:
>   Package: tipa
>   Version: 2:1.2-2
> 
> Any suggestions? What is the correct way to build packages with epoch?

That is the correct way.  Epochs don't show up in a number of places (when
they're deemed to be unimportant).  Also note that what a file happens to be
called has no bearing whatsoever on it's end utility.  You could rename a
package winword.exe and then run "dpkg -i winword.exe" and it'll install
exactly as per normal.  

- Matt


signature.asc
Description: Digital signature

Re: Remove an ITP

[Matthew Palmer]

On Thu, Dec 22, 2005 at 09:10:14PM -0500, Joe Smith wrote:
> 
> "Justin Pryzby" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> >Indeed, many packages aren't copyrighted by individual person[s];
> >check out the 'coreutils' package, the copyright of which is held by
> >some funky group called the 'free the software foundation'.
> 
> I'm hoping you are joking, as anybody who messes up the name of the FSF 
> that badly should probably
> not be talking on these lists.

"Join us now and free the software,  You'll be free, hackers,
yoo'll be free..."

Did more damage to the cause of free software than *anything* else, I swear.

- Matt


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

Re: Proposal for collaborative maintenance of packages

[Matthew Palmer]

On Thu, Dec 29, 2005 at 12:13:31PM +1100, skaller wrote:
> This is how Wikipedia works and why it is successful. With minimal
> fuss I have contributed some comments and a couple of changes.

How easy is it for a Wikipedia comment to contain a rootkit, though?

- Matt


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

Re: Proposal for collaborative maintenance of packages

[Matthew Palmer]

On Thu, Dec 29, 2005 at 02:14:14PM +1100, skaller wrote:
> On Wed, 2005-12-28 at 20:44 -0500, Justin Pryzby wrote:
> 
> > > EG: My comp is on the net sometimes and sitting here idle.
> > > I'd be happy if Debian used it occasionally to build binaries.
> > > Where is the web page telling me how to advise Debian autobuilder
> > > how to access my comp??
> > That won't happen.  Debian developers, by whatever definition, is
> > accountable ethically if not legally for packages we distribute.
> > AFAIK that is one reason why we distribute free software :)
> 
> > We're also responsible for not distributing malware in our packages,
> > and, whereas I would love to have an absolute trust in the goodwill of
> > mankind, I recognize that it isn't feasible to allow autobuilding on
> > arbitrary hosts.
> 
> You assumed that ONE machine would be blindly trusted to build a 
> binary package. Did I say that?? :)
> 
> You'd want at least 3 to produce identical results, and
> you'd only use this mechanism for Unstable type stuff.

This typically isn't possible to do.  Different machines will, oddly enough,
often produce slightly different results from a package build, due to the
embedding of various bits of data in the output (such as timestamps inside
files).

> The final distro would of course still be built under
> more controlled conditions.

So we then need to throw *massive* amounts of processing power at compiling
over 10,000 packages (some of which can take up to a day, even on modern
hardware) for a short period of time.  People already complain that Debian
is outdated when it's released -- this isn't going to help matters.  Not to
mention the old "Trusting Trust" attack (and if you don't know what I'm
talking about, it's time to stop talking and break out the research cap). 

- Matt


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

Re: Extra debian repository

[Matthew Palmer]

On Fri, Jan 13, 2006 at 08:04:01PM +0200, Mugurel Tudor wrote:
> - the repository created is a trivial one (something like "deb
> http://server/dir1/dir2 dir3/"), and dir3 containes the packages
> involved and the Packages.gz (created with dpkg-scanpackages)

Hint: use apt-ftparchive.  It's a lot tidier.

> - apt-get fails ("my_meta_package requires 1.1 for abc, but 1.0 is about
> to be installed")
> 
> If I do an "apt-cache show abc", than both packages are displayed,
> version 1.0 and 1.1cvs01012006.

Try manually installing abc, if necessary explicitly setting the version to
yours (so "apt-get install abc=1.1cvs01012006").  I'm willing to make a
small wager that it won't install, probably due to dependency problems or
conflicts (say, something else on your machine depends on abc (<< 1.1), or
your abc package depends on a newer library version, because it was built in
the wrong chroot).  Fix that and the problem magically goes away.

- Matt


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

Re: How to help with neglected packages

[Matthew Palmer]

On Wed, Jan 18, 2006 at 05:17:48PM +0100, Marcus Better wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I use a few packages, such as kernel-patch-exec-shield, which are
> neglected by the maintainer. What can I do to help if the maintainer is
> not responding to bug reports or e-mail?
> 
> I have prepared patches fixing some bugs (even RC) and sent them to the
> BTS several weeks ago, and later also e-mailed the maintainer, but
> received to reply. The maintainer obviously hasn't touched the package
> for years.

You've done everything right so far.

> I am not a DD. Should I ask someone to do an NMU on these packages?

Your next step from here is probably to e-mail debian-qa@lists.debian.org
and ask them for an NMU, as they're the people who normally give otherwise
neglected packages (although I've recently seen a wider willingness amongst
DDs to jump into random packages, which is good).  As mentioned, if you
suspect that the package maintainer is really MIA (as opposed to, say, just
very overworked) you can e-mail [EMAIL PROTECTED] to give the folks who do
that work to look into the manner.

- Matt


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

Re: debian package installation - setting environment

[Matthew Palmer]

On Wed, Jan 18, 2006 at 04:40:12PM +0200, Ivars Strazdins wrote:
> Sam Morris wrote:
> > it should really live in /usr/lib/. If the use of /opt
> > is hard coded into the package then, well, that sucks. :)
> 
> It is hard coded into management decision to which I really have no 
> access whatsoever.
> 
> > see  for
> > details.
> 
> Thanks, I also thought I should go this way.
> But what to do with $PATH ?:(

Wrappers in /usr/bin.  If there is a Management Decree that No Package File
Will Be Outside /opt, then you're screwed unless you can mandate the use of
/bin/bash, and ship a modified /etc/profile.

Time to re-read "How To Win Friends And Influence People", and go to work on
the management twonks making your life difficult.

- Matt


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

Re: ITP: wengophone -- A free SIP softphone

[Matthew Palmer]

On Wed, Feb 08, 2006 at 09:01:18PM +0100, Marco Nenciarini wrote:
> On Wed, Feb 08, 2006 at 02:25:29PM -0500, Justin Pryzby wrote:
> > On Wed, Feb 08, 2006 at 08:21:42PM +0100, Marco Nenciarini wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Marco Nenciarini <[EMAIL PROTECTED]>
> > > 
> > > * Package name: wengophone
> > >   Version : 0.99+svn4179
> > >   Upstream Author : Wengo SAS 
> > > * URL : http://dev.openwengo.com/
> > > * License : GPL with exception for ssl linking
> > >   Description : A free SIP softphone
> > > 
> > >  WengoPhone Classic is a Voice and Video Over IP application based on
> > >  standard protocols like SIP and RTP.
> > > 
> > > Sorry for the little long description, i asked upstream for a better.
> > You're allowed, indeed, encouraged, to supply your own description of
> > the package.
> 
> Yes, but my english is not so fluent to make a good description.

If there's one thing people are good at here in d-mentors, it's editing long
descriptions to improve them.

- Matt


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

Re: ITP: wengophone -- A free SIP softphone

[Matthew Palmer]

On Thu, Feb 09, 2006 at 10:12:46AM +0100, Marco Nenciarini wrote:
> On Thu, Feb 09, 2006 at 09:21:08AM +1100, Matthew Palmer wrote:
> > 
> > If there's one thing people are good at here in d-mentors, it's editing long
> > descriptions to improve them.
> > 
> 
> Ok, i need comments about this description:
> 
> Description: A free SIP-based VoIP softphone with Video and Chat features.
>  WengoPhone is a Voice over IP application based on standard protocols
>  like SIP and RTP. It enables voice, video and text chat between two
>  clients.  Features include a contact list with presence and status,
>  call history and NAT traversal capability. Combined with commercial
>  service, WengoPhone can be used to call regular PSTN lines and/or
>  send SMS messages to cell phones.

Looks good to me.  Sounds like a quality app, to boot.  

- Matt


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

Re: Take over an ITP in absence of an answer from the bug owner

[Matthew Palmer]

On Mon, Mar 13, 2006 at 08:19:23PM +0100, Julien Valroff wrote:
> I am very interested in taking over fast-user-switch-applet package
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304763)
> 
> I don't own the ITP which is almost one year old, and the owner hasn't
> (yet) answered my e-mail.
> 
> Now I am wondering what to do if after a few other weeks/messages I get
> no answer.

Package and upload.  ITPs are to reduce duplication of effort, they're not
an exclusive lock on a prospective package.

- Matt


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

Re: Help with debian/control Depends: for php4 and php5

[Matthew Palmer]

On Fri, Apr 14, 2006 at 02:31:54PM -0400, Kevin Coyner wrote:
> Now I'd like to make it depend on either php4 or php5, so I've
> attempted the following:
> 
> Depends: ${misc:Depends}, php4 (>=4.3) | php5 (>=5.1) |
> libapache2-mod-php4 | libapache2-mod-php5, php4-mysql (>=4 .3) |

I think you're over-complicating things here (and introducing a couple of
bugs, to boot).  The php4 and php5 packages are both meta-packages these
days, depending on all of the available flavours of PHP interpreter out
there (for that particular major version of PHP).  Hence, it isn't necessary
for you to specify either of the libapache2-mod-php? packages in the depends
line, because the php4 | php5 dependency will pick up a PHP interpreter for
you.

Now, as to the bugs.  Firstly, you've specified minimum required versions of
php4 and php5 (presumably because your package really needs those minimum
versions) but you haven't carried that version requirement through to the
apache2 modules.  This means that I could install
libapache-mod-php5_5.0.5-2, which would satisfy the dependency as a whole,
but not have the minimum required version of PHP 5 (if the version on the
php5 package is correct).

Secondly, the version you've specified for the php4 and php4-mysql packages
is incorrect.  The php4 packages have an epoch on them, which means that
the correct version spec for them is ">= 4:4.3".

Also, I don't think I'd bother putting a versioned dep on php4-mysql -- it's
unlikely that you need features that are only available in the 4.3+ versions
of that package, so all you want is a version of php4-mysql which is
compatible with the version of the PHP 4 interpreter that you're installing. 
That requirement will, of course, be settled by the dependencies in the
php4-mysql and PHP interpreter package, so there's no need to specify the
versioned dependency unless you have a real need for features in the
php4-mysql package only present in the given version.

- Matt


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

Re: W: A binary links against a library it does not use symbols from

[Matthew Palmer]

On Tue, Apr 18, 2006 at 03:18:23PM +0200, Daniel Leidert wrote:
> W: winefish; A binary links against a library it does not use symbols from
>  This package contains a binary that links against a library that is
>  not in the Depends line. This may also be a bug in the library which
>  does not have a shlibs file.
> 
> My problem: How can I determine the library the warning is about? I
> build the package in my environment and in a pbuilder environment. Both
> show the same 'Depends:' line. And there is no FTBFS. So how could I
> determine the library? There are IIRC graphical tools to build a diagram
> with dependencies for a package, right? This could be one way. Do you
> know a better way?

ldd will tell you what libraries a binary links against; it's just a matter
of matching that list against your Depends: line and seeing what's missing. 
You could fix the problem by adding an entry for the package by hand to your
Depends line, but you're better off looking at the package that provides
the library and working out why it's missing a shlibs file (if it is), or
why it's otherwise not being picked up by dh_shlibdeps.

- Matt


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

Re: php[4|5]+apache DSO - should I care about php4?

[Matthew Palmer]

On Fri, Apr 21, 2006 at 01:58:08PM -0700, Tyler MacDonald wrote:
>   Of course, both php4 and php5 are still out there and probably both
> are widely used at this point. There's two ways I can think of to go about
> rolling .deb's for each:
> 
>   - change "--with-php-config" in my configure script to
> "--with-php4-config" and "--with-php5-config", which would do the exact same
> thing, only twice. :-)
> 
>   - build that part of the source tree twice with two
> different sets of configure options to create the two DSOs.

These two options seem more or less the same.  It's quite common to do this,
BTW -- see Python modules that build for multiple Python versions, or Apache
modules that build for both 1.3 and 2 (libapache-mod-auth-mysql is an
example of this).

>   But should I be overly concerned with building a php4- package? Or
> is PHP4 expected to be retired soonish?

Based on the Debian experience with PHP3, I'd doubt it.  It's not even dead
upstream yet, and PHP4 still has massive mindshare.  Since converting
existing code to PHP5 is non-trivial, I seriously doubt that PHP4 will be
going away any time soon.

That being said, there's no reason why you have to support PHP4.  There's
plenty of software out there that's PHP5 only; you just have to decide if
the increased developer exposure is worth the extra maintenance burden.

- Matt


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

Re: A list of common gotchas in Debian packaging

[Matthew Palmer]

On Thu, May 04, 2006 at 02:52:43PM +0300, Panu Kalliokoski wrote:
> Some issues seem to come up time and again when somebody inspects RFS'd
> packages.  Some of these are not breaches of policy but simply bad
> practices, like leaving quoted dh_* commands in debian/rules.  Some are
> breaches of policy but common enough to focus separate attention to.
> 
> I wonder, whether there is a list of these "common gotchas" in packaging
> somewhere, or a checklist for package quality?  In a similar vein, I

Such as http://people.debian.org/~mpalmer/sponsorship_checklist.html ?  It's
not authoritative, but it's not a bad start.  Additions gratefully received.

- Matt


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

Re: optional building of a package

[Matthew Palmer]

On Sat, Jun 03, 2006 at 01:46:35PM +0900, Charles Plessy wrote:
> I am working on packaging probcons, which consists of two main programs
> carrying the core functionalities, and a few other programs with
> ambiguous names (convert, makegunplut, project) which will not be useful
> to the vast majority of users. The upstream author advised me to drop
> them from the package, which I will do.
> 
> However, I was wondering wether it would make sense to provide to the
> Debian user a mean to install the extra programs from the Debian sources.
> Is there a way to make the source package able to produce a
> probcons-extra package, but only optionaly?

You *can* create a package optionally (have some sort of build-time option
to enable passing the package name to all the relevant debhelper rules), but
I'd build the binaries normally, and probably rename them so they're
non-conflicting.  You *could* put them in /usr/lib/, perhaps, but that
just seems... weird.

Of course, if upstream says "don't include them", they're obviously not
particularly useful, in which case you probably don't need to put them in
the package at all.

- Matt


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

Re: executable name collision

[Matthew Palmer]

On Thu, Jun 08, 2006 at 06:14:39PM -0500, Carlo Segre wrote:
> We are working on package of a data acquisition & control system (called 
> "mx") which has an executable called "motor" which has a completely 
> different function (it is a java editor).  This executable conflicts with 
> an executable of the same name in the package "motor" [0].  Since this 
> executable is in use in a number of places, I really can't change its name 
> in the Debian package.  The only way I can see to handle this is to make 
> our package (called mx1.2) conflict with the "motor" package or just 
> ignore the entire thing and let the last package installed with a 
> --force-overwrite win.
> 
> Any other ideas?

Is motor generally useful, or is it just used as an internal component of
mx? (not a good name itself, BTW)  If the latter, consider putting motor
into /usr/lib/mx.

- Matt


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

Re: executable name collision

[Matthew Palmer]

On Thu, Jun 08, 2006 at 08:42:39PM -0500, Carlo Segre wrote:
> >Is motor generally useful, or is it just used as an internal component of
> >mx? (not a good name itself, BTW)  If the latter, consider putting motor
> >into /usr/lib/mx.
> 
> It is a generally used program for data acquisition and control.  The name 
> motor is historical but is basically because it controls physical motors 

I thought motor was the java editor?  Obviously misread something.  Ignore
me, then.

- Matt


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

Re: Dependancies within multi-binary packages

[Matthew Palmer]

On Mon, Jul 03, 2006 at 12:02:24PM +1000, Nikolai Lusan wrote:
> Once I install the libpq4-hw package dpkg will still complain:
> 
> [EMAIL PROTECTED] # dpkg -i postgresql-client-8.0-hw_8.0.7-1_i386.deb 
> Selecting previously deselected package postgresql-client-8.0-hw.
> (Reading database ... 22134 files and directories currently installed.)
> Unpacking postgresql-client-8.0-hw (from
> postgresql-client-8.0-hw_8.0.7-1_i386.deb) ...
> dpkg: dependency problems prevent configuration of
> postgresql-client-8.0-hw:
>  postgresql-client-8.0-hw depends on libpq4 (>= 8.0.4); however:
>   Package libpq4 is not installed.

Versioned dependencies cannot be satisfied by Provided packages, AFAIK.

> Does anyone know how I can fix this one?

I strongly suspect that You're Stuffed.  For this sort of thing, I typically
just create my own packages with the same name and cross my fingers that
they don't get into the wild -- worst case, I make my packages depend on
some sort of local dummy package that shouldn't end up in the wider world,
to prevent major problems.

- Matt


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

Re: Dependancies within multi-binary packages

[Matthew Palmer]

On Mon, Jul 03, 2006 at 12:32:53PM +1000, Nikolai Lusan wrote:
> On Mon, 2006-07-03 at 12:15 +1000, Matthew Palmer wrote:
> > I strongly suspect that You're Stuffed.  For this sort of thing, I typically
> > just create my own packages with the same name and cross my fingers that
> > they don't get into the wild -- worst case, I make my packages depend on
> > some sort of local dummy package that shouldn't end up in the wider world,
> > to prevent major problems.
> looks like I remove the "${shlibs:Depends}" from the control file and
> put them in by hand, praying I don't leave something out. :)

Since all you'll be doing is putting in manually what shlibs:Depends would
have added, I don't think you're going to benefit much.  If you're thinking
of gutting the versions, please reconsider -- they're there for very good
reason (ensuring that you don't go linking against a library version that
might not have all the symbols you need), and it'll almost certainly break
something, at some time, and be a right pest to debug.

- Matt


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

Re: Automatic installation of packages

[Matthew Palmer]

On Wed, Jul 19, 2006 at 09:03:18PM -0700, Steven Hill wrote:
> I have been reading the literature on debian packages, and I am trying
> to figure out how to tell the package installer to automatically use
> "apt-get install" to satisfy a dependency at installation time - is
> there any way to do that?

What do you mean by "package installer"?  Do you mean dpkg?  If so, it's not
designed to automatically satisfy dependencies, but rather to just do
exactly what you tell it to.  You should use apt-get to install packages
including satisfying dependencies where necessary.

If you've got a local package that isn't in an apt repo that you want to
install, then you can use dpkg to install the package and then run "apt-get
-f install" to subsequently satisfy the dependencies and configure the first
package.

- Matt


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

Re: plea to sponsees about announcing location of packages

[Matthew Palmer]

On Tue, Jul 25, 2006 at 10:46:47AM +0100, martin f krafft wrote:
> Matthew, could we please add this to the FAQ?

It shall be done.  I'll also note about dget (which is a little-known tool,
I think).

- Matt


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

Re: Please tell if you found a sponsor

[Matthew Palmer]

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

Only works for new packages, not existing packages looking for a new upload.

- Matt


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

Re: shlib-with-non-pic-code

[Matthew Palmer]

On Mon, Aug 28, 2006 at 07:57:27PM +0200, Michael Biebl wrote:
> Now lintian complains about the files in /usr/lib/kde3:
> 
> E: kdesvn-kio-plugins: shlib-with-non-pic-code usr/lib/kde3/kded_kdesvnd.so
> E: kdesvn-kio-plugins: shlib-with-non-pic-code usr/lib/kde3/kio_ksvn.so
> E: kdesvn: shlib-with-non-pic-code usr/lib/kde3/libkdesvnpart.so
> 
> Looking at the corresponding check, lintian greps for TEXTREL in objdump
> -x and indead, this section is there. Can someone explain what this
> section is for, google was not very helpful there.
> 
> The command line when linking the modules is
> /usr/bin/c++  -fPIC -g -Wall -O2 -Wnon-virtual-dtor -Wno-long-long -ansi
> -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W
> -Wpointer-arith -Wwrite-strings -O2 -Wformat-security -fno-exceptions
> -fno-check-new -fno-common -fexceptions -fstack-protector  -shared
> -Wl,-soname,kded_kdesvnd.so -o ../../lib/kded_kdesvnd.so

More important than the linker command line is the compilation command line. 
You need to make sure that all of the source files that make up those .so
files were built with -fPIC in their command lines.

- Matt


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

Re: shlib-with-non-pic-code

[Matthew Palmer]

On Mon, Aug 28, 2006 at 10:37:06PM +0200, Michael Biebl wrote:
> If forgot to add, that the software runs just fine on my i386 box. Is
> this a error message that can safely be ignored or does it only affect
> certain !i386 platforms.

It's only a problem on some !i386 platforms.

- Matt


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

Re: shlib-with-non-pic-code

[Matthew Palmer]

On Tue, Aug 29, 2006 at 01:16:40AM +0200, Michael Biebl wrote:
> Matthew Palmer wrote:
> > On Mon, Aug 28, 2006 at 07:57:27PM +0200, Michael Biebl wrote:
> >> Now lintian complains about the files in /usr/lib/kde3:
> >>
> >> E: kdesvn-kio-plugins: shlib-with-non-pic-code usr/lib/kde3/kded_kdesvnd.so
> >> E: kdesvn-kio-plugins: shlib-with-non-pic-code usr/lib/kde3/kio_ksvn.so
> >> E: kdesvn: shlib-with-non-pic-code usr/lib/kde3/libkdesvnpart.so
> >>
> >> Looking at the corresponding check, lintian greps for TEXTREL in objdump
> >> -x and indead, this section is there. Can someone explain what this
> >> section is for, google was not very helpful there.
> >>
> >> The command line when linking the modules is
> >> /usr/bin/c++  -fPIC -g -Wall -O2 -Wnon-virtual-dtor -Wno-long-long -ansi
> >> -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W
> >> -Wpointer-arith -Wwrite-strings -O2 -Wformat-security -fno-exceptions
> >> -fno-check-new -fno-common -fexceptions -fstack-protector  -shared
> >> -Wl,-soname,kded_kdesvnd.so -o ../../lib/kded_kdesvnd.so
> > 
> > More important than the linker command line is the compilation command 
> > line. 
> > You need to make sure that all of the source files that make up those .so
> > files were built with -fPIC in their command lines.
> 
> Hi Matt,
> thanks for your advice but it seems that they all are built with -fPIC.
> The command line for a source file looks like this:
> 
>  /usr/bin/c++   -Dkded_kdesvnd_EXPORTS -g -Wall -O2 -Wnon-virtual-dtor
> -Wno-long-long -ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts
> -Wall -W -Wpointer-arith -Wwrite-strings -O2 -Wformat-security
> -fno-exceptions -fno-check-new -fno-common -fexceptions
> -fstack-protector -fPIC -I/usr/include/kde -I/usr/share/qt3/include

Bugger.  That's the only thing that I've ever had to check.  Mike Hommey
appears to have deeper knowledge of why things can end up being
non-position-independent than me, so I'll leave the tricky debugging work to
him.

- Matt


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

Re: RFS: audacious

[Matthew Palmer]

References: <[EMAIL PROTECTED]>
+<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
+<[EMAIL PROTECTED]>
+<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Please don't hijack threads.  If you wish to start a new thread, click 'new
message' rather than replying to an existing message and changing the
subject.

- Matt


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

Re: RFS: personalbackup

[Matthew Palmer]

On Thu, Sep 07, 2006 at 05:26:53PM -0500, Luis Rodrigo Gallardo Cruz wrote:
> On Thu, Sep 07, 2006 at 08:27:43PM +0200, kku wrote:
> > >You are programaticaly managing a configuration file in /etc. You
> > >should look into using ucf, that already handles this.
> > 
> > I've had a look at ucf, but I do not think it fits my need (unless I have 
> > overlooked something).
> > 
> > I have a template file 
> > "/usr/share/doc/personalbackup/personalbackup.apache" and the parameter 
> > "webalias"
> > is being replaced in that template during postinst. Depending on the user's 
> > choose for apache/apache2 this file will be placed in 
> > '/etc/apache/conf.d/personalbackup' or 
> > '/etc/apache2/sites-enabled/personalbackup'
> > 
> > Now to detect that the user did (not) change the conf file, I check the 
> > md5sum of the content of the appropriate conf file 'except' for the Alias 
> > line.
> > And as far as I can see this is something ucf cannot handle...or am I wrong 
> > here?
> 
> Uhh. From apt-cache show ucf

Luis, I think you missed a critical bit of what's being done with the config
file -- the md5sum of only part of the config file is being checked, which
(unless it's has had some *very* interesting features added lately) ucf
can't do.

This doesn't, however, change the fact that this "only compare parts of the
config file" approach isn't policy compliant.  If I change *any* part of a
config file, I expect those changes to be preserved.  Debconf Is Not A
Registry is a sacred and hallowed principle, and it's still applicable here.

I don't care if I answered a certain question a certain way when the package
was first installed -- the Unix philosophy is that I go and edit config
files directly when I want things changed.  If the package goes and puts
things back how they were because of a debconf setting (overriding my
carefully hand-crafted changes) then that's a bug.

- Matt


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

Re: RFS: personalbackup

[Matthew Palmer]

On Thu, Sep 07, 2006 at 10:18:29PM -0500, Luis Rodrigo Gallardo Cruz wrote:
> On Fri, Sep 08, 2006 at 10:01:47AM +1000, Matthew Palmer wrote:
> > On Thu, Sep 07, 2006 at 05:26:53PM -0500, Luis Rodrigo Gallardo Cruz wrote:
> > > On Thu, Sep 07, 2006 at 08:27:43PM +0200, kku wrote:
> > > > Now to detect that the user did (not) change the conf file, I check the 
> > > > md5sum of the content of the appropriate conf file 'except' for the 
> > > > Alias 
> > > > line.
> > > > And as far as I can see this is something ucf cannot handle...or am I 
> > > > wrong 
> > > > here?
> > > 
> > > Uhh. From apt-cache show ucf
> > 
> > Luis, I think you missed a critical bit of what's being done with the config
> > file -- the md5sum of only part of the config file is being checked, which
> > (unless it's has had some *very* interesting features added lately) ucf
> > can't do.
> 
> Indeed. Must read more carefuly next time.
> 
> Now, from a mentoring point of view, what should kku do? Create the
> file on first install acording to the user's answer, then consider the
> *resulting* file a conffile and treat it accordingly?

That would certainly be my best recommendation.  Since the package can't
ship a stock conffile, the only options are to use ucf to manage the update
of the file or to rewrite ucf's functionality (been there, done that,
trained professionals, don't try this at home, etc).

- Matt


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

Re: dvipng: Version 1.8 package (NMU / New Maintainer)

[Matthew Palmer]

On Sat, Sep 16, 2006 at 05:16:06PM +0100, James Westby wrote:
> On (16/09/06 21:34), Kapil Hari Paranjape wrote:
> > On Sat, 16 Sep 2006, James Westby wrote:
> > >   * The debian/copyright file is lacking. There is no copyright
> > > information, what is referred to as Copyright is in fact a License,
> > > and not a copy of a license header from the package.
> > 
> > I didn't follow. The debian/copyright file contains the copyright
> > information which for this program is given the statement of the
> > author that the program is available under the GPL. I must be missing
> > something here ...
> > 
> 
> The debian/copyright file states
> 
> Copyright:
> 
>dvipng is free software; you can redistribute it and/or modify it under
>the terms of the GNU General Public License as published by the Free
>Software Foundation; either version 2, or (at your option) any later
>version.
> 
>dvipng is distributed in the hope that it will be useful, but WITHOUT
>ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>more details.
> 
> Whereas this is in fact the License of dvipng, though not one of the
> license headers from the source code.

It certainly *looks* like (part of) what you would find in the header of a
source file.

Kapil: there are a couple of bits missing from this, though -- the copyright
attribution, and identification of where the text quoted was taken from. 
You should end up with something like this:

Copyright:

Taken from main.c:

  Copyright (C) 2005 Joe Bloggs <[EMAIL PROTECTED]>
  Copyright (C) 2003-2006 Fred Nurks <[EMAIL PROTECTED]>
  
  dvipng is free software; etc

-8<-

You should do a bit of a whip-around the source files to see if there's any
source files that might be under a different licence, or even documentation
or support materials that are licenced differently.  If you do find anything
that's different, you add extra stanzas to document the differences and
label which parts of the software the different statements apply to.

> See http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
> and the links from there.

I heartily endorse this product and/or event.

- Matt


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

Re: my projects for debian ? - Answer to Tony

[Matthew Palmer]

On Sun, Sep 17, 2006 at 11:33:43PM +0200, [EMAIL PROTECTED] wrote:
> > How does pag compare to pwgen (http://sourceforge.net/projects/pwgen/)?
> > 
> > Cheers,
> > tony
> 
> Hi Tony,
> 
> yes, i tested pwgen in thought the same. Pwgen has no option to create a
> password list and you cant set the length of the password(s). My program

Uhm...

$ pwgen -h 2>&1 |head -1
Usage: pwgen [ OPTIONS ] [ pw_length ] [ num_pw ]

$ pwgen -1 10 10
dieN0iyuab
eetaDu9oeW
eeThoush6f
raec1Iel4u
bu3ug7eeLo
shaiL3uD0I
eiP3Theeb9
phoeN8waRe
Ied6oVuito
aiShih4aek

> I cant even move the output from pwgen to a file with a pipe,

$ pwgen -1 10 10 >/tmp/foo
$ cat /tmp/foo
izaiteidet
queibohghu
ahpoxiewoo
hedimaibap
goonaeveek
lunoufaiso
ootuusogha
heacheilee
ufiepeoloh
ponuisaiqu

> Like said, my project has more options, you can set everything and it can
> also generate a password file with x passwords , so how many passwords you
> want.

I've just had a look at your code, and I can safely say that pwgen has a lot
more options, and is significantly more flexible.  You have to recompile
your program to change the output file or increase the maximum size of the
password beyond 15 characters, you have to answer a bunch of questions
interactively to get a password, and there's no pronounceability or security
options.  To top it all off, you're using scanf throughout your code to
retrieve input from the user, and you've got global variables named x, y, z,
m, n, and max.

Suffice it to say, I don't think your program adds much to the feature set
already provided by pwgen.

- Matt


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

Re: 'what' on Linux?

[Matthew Palmer]

On Sun, Sep 17, 2006 at 11:01:57PM +0200, Toni Mueller wrote:
> I'm looking for a program like 'what' on BSD, but on Linux (obviously).

This is more a question for debian-user.  But I'll say that a bit of shell
plumbing would probably get you what you want:

strings $file | grep '^\$.*\$$'

Of course there's a lot of reasons why that isn't going to work on a lot of
binaries.

- Matt


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

Re: pwgen / pagen - only numbers

[Matthew Palmer]

On Mon, Sep 18, 2006 at 03:19:27AM +0200, [EMAIL PROTECTED] wrote:
> You cant generate passwords with only numbers in it with pwgen.

Sounds like a chance for a feature enhancement you could make.

> But maybe pwgen is better i dont know. My program cant generate
> PWs with only letters at time.
> And by the way, i found a bug in pwgen with the following syntax:
> $ pwgen -s -B -1 10 3
> it looks like this:
> 32
> dsl450fls2
> lf03j4n59d

You're right -- sometimes (but only sometimes) the first password is
truncated.  I even got it to truncate the first two passwords to the same
length.  The length of the truncated password varied between runs, too.

Definite bug report time.

- Matt


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

Re: Version 1 accidentally released as version 2...

[Matthew Palmer]

On Tue, Sep 26, 2006 at 02:44:14PM +0900, Charles Plessy wrote:
> For one of the packages I created, the upstream sources I used were a
> version 1.x accidentally released as version 2.0 on sourceforge.

"Accidentally"?  Did you package and upload this new upstream release?  Has
upstream gone back to numbering their releases as 1.x?  I don't really
understand the problem.  It sounds like there's a new major version of the
software, which is incompatible with the old version, but that's not very
"accidental".

> The
> differences between the two versions are quite high, as the file formats
> accepted in input have changed (some added, some removed).
> 
> I am wondering what I am supposed to do in this case :
> 
> a) Release a different package which conflicts on the previous, or

Perhaps, if the changes are major enough that silently upgrading is likely
to deeply annoy some people (or if the program has effectively forked and
1.x is going to continue being developed alongside 2.x).  The conflict is
only required if both packages are going to provide files of the same names.

> b) use an epoch and upgrade the current package as version 2.0, or

I don't understand what problem you're trying to solve, exactly, but this
would only be necessary where you "accidentally" packaged a 2.x release when
upstream is really still only making 1.x releases.

> c) ask upstream to increase the version number (for instance they could
> include add the manpages I wrote for the program) and upgrade then.

That's another possiblity, but it depends greatly on what exactly upstream
have done, whether they consider it to be a problem as well, what their
plans are in general, and what sort of relationship you've got with them.

> The options b) or c) could be accompagned by a NEWS or something
> equivalent if this is not an abuse, to tell that there has been a major
> version change and that scripts could break.

An item in NEWS is a good idea if people could suffer problems on the
upgrade.

> I would favor option a), but if upstream becomes suddently mega-active
> and releases a major version every half year, this could be a mess.

I don't see the problem with just making a new version of the existing
package, automatically upgrading as much as you can, and warning users that
Things Have Changed.  But I really don't understand the exact problem that
you're having.

- Matt


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

Re: Version 1 accidentally released as version 2...

[Matthew Palmer]

On Tue, Sep 26, 2006 at 05:09:51PM +0900, Charles Plessy wrote:
> Le Tue, Sep 26, 2006 at 04:28:14PM +1000, Matthew Palmer a écrit :
> > On Tue, Sep 26, 2006 at 02:44:14PM +0900, Charles Plessy wrote:
> > > For one of the packages I created, the upstream sources I used were a
> > > version 1.x accidentally released as version 2.0 on sourceforge.
> > 
> > "Accidentally"?
> 
> Well, SourceForge was offering "poa_release_2_0.tar.gz" for a few
> months, and it recently changed to "poaV2.tar.gz". I contacted the
> upstram author, and he explained me that poa_release_2_0.tar.gz was
> supposed to contain sources tagged "release_2_0" in their CVS
> repository, but in fact contained an older version.
> 
> My first version of the package is poa_2.0-1, and is based on
> poa_release_2_0.tar.gz, which is not version 2.0.

What's upstream doing about it now?  Are they releasing a 2.0.1 or 2.1 or 3
or something to replace that one, or are they just sticking with the V2
package?  Again, what are upstream's plans?  That will have a massive
bearing on what you do.

- Matt

Re: Version 1 accidentally released as version 2...

[Matthew Palmer]

On Thu, Sep 28, 2006 at 09:33:46AM +0900, Charles Plessy wrote:
> Le Wed, Sep 27, 2006 at 08:20:15PM -0300, Leo Antunes a écrit :
> > If that's done then you're job's simple, repackage with the new version
> > and that's it. Make it as fast as possible though, since your users are
> > probably a bit confused by now... and if upstream takes a while to
> > release officially (for any reason), you could just get the CVS version
> > tagged as 2.0, name it 2.0+1-1 or something like that and upload fast.
> > If, however, upstream decides to not release a new tarball you repackage
> > it yourself and use the same naming convention as above.
> 
> OK, thanks all for your answers. I will mention the problem in the
> README. How can I give a message only to the users who upgrade from the
> previous version? I do not want to annoy the ones who will install from
> Etch next year...

If you put in NEWS.Debian (it has the same format as debian/changelog, you
can even use dch to edit it) then people who are using apt-listchanges and
are upgrading from a version older than the version in which the news was
logged against will see the message.

- Matt

Re: Version 1 accidentally released as version 2...

[Matthew Palmer]

On Thu, Sep 28, 2006 at 07:36:36PM +0900, Charles Plessy wrote:
> Le Thu, Sep 28, 2006 at 12:19:04PM +0200, Bas Wijnen a écrit :
> > But that's not what he wants, because then all the people who upgrade to 
> > etch
> > with also see it then, even though it's irrelevant for them.  What he's 
> > asking
> > is if there's a way to show it only if the upgrade is from a high enough
> > version.
> 
> Luckily, the situation is simpler: the package has been created
> recently, and six popcon-persons installed it. Only one version of the
> debian package has been released for the moment (i.e. the changelog has
> only one entry). I would like the persons upgrading to see the message
> and the people installing for the first time not seeing it. Will
> NEWS.Debian fit this purpose?

Yes.

- Matt

Re: What to do if upstream downlaod location disappears?

[Matthew Palmer]

On Fri, Sep 29, 2006 at 07:19:04AM +1000, Andree Leidenfrost wrote:
> The '(if any)' makes me think I can amend the copyright file like this:
> 
> It was originally downloaded from
> http://home1.stofanet.dk/peter-seidler/ which does not exist anymore.
> There is currently no known download location. However, the 
> pristine last upstream source is in the petris_1.0.1.orig.tar.gz tarball
> in the Debian archives.
> 
> Would this be acceptable?

I would consider that to be a perfectly acceptable statement of the facts.

- Matt


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

Re: No response to RFS -- what to do now?

[Matthew Palmer]

On Sun, Nov 05, 2006 at 11:56:59PM +0100, Székelyi Szabolcs wrote:
> I've posted an [0]RFS about 2 weeks ago, but the package has received no
> attention from official developers.
> 
> What is the usual procedure in this case? Wait longer, re-post the RFS
> or try to accept that the package will never be a part of Debian?

d) Read the FAQ: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

- Matt

Re: Help with updating nco package?

[Matthew Palmer]

On Fri, Nov 10, 2006 at 11:44:55PM -0800, Charlie Zender wrote:
> 2. dh_builddeb warnings with gpg signing

Try passing '-uc -us' to dpkg-buildpackage -- that should tell it to not try
and sign the resulting package upload.

- Matt


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

Re: Help About: to propose package

[Matthew Palmer]

On Sat, Nov 25, 2006 at 02:15:35PM +0100, Salokine wrote:
> I learn to create my first new package (tremulous-mappack). I've finished to 
> create it and download to ftp//mentors.debian.net.
> 
> What must I do now to continue integration process ?
> Why my package isn't to "My Packages" view ?
> Why don't I received email confirmation ?
> Where can I say "Need Sponsor = Yes" ?
> Is my package too big ?
> 
> Sorry for my basic questions ...

The FAQ list might answer some of your questions:
http://people.debian.org/~mpalmer/debian-mentors_FAQ.html

- Matt


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

Re: Bad practice to make a package depend on a specific kernel image

[Matthew Palmer]

On Mon, Jan 01, 2007 at 10:32:21PM -0500, Roberto C. Sanchez wrote:
> On Tue, Jan 02, 2007 at 02:24:13PM +1100, Robert Collins wrote:
> > 
> > Because the vast bulk of users do *not* roll their own kernels [yes, an
> > assumption, but I'm pretty confident here :)].
> > 
> I disagree.  I think that while it is not the majority, a sizeable
> portion of the user base installs a home-rolled kernel.

Could you stop that hand of yours from waving around quite so much?  Unless
you can provide some reasonably respectable numbers to support your
position, you're arguing about dancing angels.

> Now, I find out about your package and install it.  Every indication
> from aptitude is that everything installs OK.  Now, I try and use your
> package and it *doesn't* work because I am not running the kernel it
> depends on.
> 
> What would I do at that point?  Personally, without any further
> documentation or information available, I'd file a bug.

This would be why the init script would, when it determined that you were
running an incompatible kernel, would spit out a helpful error message. 

- Matt


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

Re: RFS: Legends: The Game

[Matthew Palmer]

On Fri, Jan 12, 2007 at 09:15:28AM +1100, Tim Hessint wrote:
> So, there is no .dsc or orig.tar.gz.

There needs to be a source package in a Debian upload.  A source package
consists of a .dsc plus the files it references.  Until you have a source
package, there's no way your package can be uploaded, into non-free or any
other part of Debian.

- Matt


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

Re: RFS: gexec

[Matthew Palmer]

On Wed, Jan 17, 2007 at 07:21:51AM +0100, Johann Rudloff wrote:
> I hope it's correct now, but I've one little question:
> 
> >   * your build-depends are wrong. you depend on libgtk2.0-0 instead of
> > libgtk2.0-dev and libglib2.0-dev
> I added both, but is the dependency on libglib2.0-dev really neccessary?
> Since libgtk2.0-dev depends on it, I think that dependency is already
> implied, or am I wrong with that?

Speaking purely at the general level, as I haven't examined your package
specifically, it's usually a good idea to specify all of the packages that
you rely on to build, regardless of whether they're depended on by another
package you depend on, just in case that other package changes it's
dependencies in the future, leaving your package broken.

Sure, I doubt that GTK is going to stop needing glib any time soon, but it's
a good habit to get into.  I don't know if your package needs any of glib's
symbols itself, though.

- Matt


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

Re: RFS: crotch

[Matthew Palmer]

On Tue, Jan 23, 2007 at 06:42:13PM +0100, Chris Amthor wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "crotch".
> 
> * Package name: crotch
>   Version : 1.0.1-1
>   Upstream Author : Chris Amthor <[EMAIL PROTECTED]>
> * URL : http://www.chroam.de/
> * License : GPL
>   Section : games
> 
> It builds these binary packages:
> crotch - Very simple ROT13 [de|en]crypting tool

What benefits does this package have over the 'rot13' program (in the
package bsdgames), or even an appropriate invocation of 'tr'?

- Matt


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

Re: bzr branch and C-c interrupt - should it do cleanup

[Matthew Palmer]

On Sat, Jan 27, 2007 at 07:26:00PM +0200, Jari Aalto wrote:
> 
> Suppose this:
> 
>   bzr branch devel.branch  my.branch
>   
>   C-c

This is a question for the bzr lists, not debian-mentors.

- Matt


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

Re: RFS: liferea 1.0.27-2

[Matthew Palmer]

On Wed, Feb 07, 2007 at 10:22:41PM -0600, Luis Rodrigo Gallardo Cruz wrote:
> I do have an issue I need help testing before upload. If I install
> etch/sid liferea + liferea-gtkhtml in a chroot, then add a sources
> line for my private repository with this new version, apt-get update,
> apt-get dist-upgrade the package does not upgrade cleanly.
> 
> What I need to happen is that liferea-gtkhtml is removed and
> liferea-xulrunner_1.0.27-2, liferea_1.0.27-2 are installed.
> 
> What happens is that liferea is held-back. I've tried adding or taking
> out a 
>  Provides: liferea-gtkhtml 
> to the liferea package, with no results.

I suspect you need the third horseman of the package apocalypse, Replaces:,
but I'm not confident enough of that to guarantee it.  I'm also reviewing
your package for sponsorship now; if it's OK, I'll await your word about the
Replaces.  I'm 'womble' on Freenode and OFTC if you want to go all realtime
on me.  

> Zenophobia: the irrational fear of convergent sequences.

That's just... hinky.

- Matt


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

Re: RFS: liferea 1.0.27-2 [Upgrading problems]

[Matthew Palmer]

On Thu, Feb 08, 2007 at 01:33:54PM -0600, Luis Rodrigo Gallardo Cruz wrote:
> On Thu, Feb 08, 2007 at 06:37:28PM +1100, Matthew Palmer wrote:
> > On Wed, Feb 07, 2007 at 10:22:41PM -0600, Luis Rodrigo Gallardo Cruz wrote:
> > > What happens is that liferea is held-back. I've tried adding or taking
> > > out a 
> > >  Provides: liferea-gtkhtml 
> > > to the liferea package, with no results.
> > 
> > I suspect you need the third horseman of the package apocalypse, Replaces:,
> 
> Nope, no good. Still doesn't work.
> 
> Actually, what happens at the dist-upgrade is that the *new*
> liferea-xulrunner get pulled, but liferea itself is held back at the
> old version and liferea-gtkhtml is not removed.

That's very odd.

> Is there something wrong with calling your private's repository
> distribution 'unstable'? Does having two repositories called the same
> but with different contents confuse apt somehow?

No, I'm pretty sure that apt works based on URLs rather than names.  The
release names are used by the '-t' option to apt-get, and also in pinning,
but I presume that there's no pinning rules that are relevant in your apt
config?

- Matt


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

Re: RFS: liferea 1.0.27-2 [Upgrading problems]

[Matthew Palmer]

On Fri, Feb 09, 2007 at 10:39:28PM -0600, Luis Rodrigo Gallardo Cruz wrote:
> [Note: I updated the package to backport a patch from 1.2.5, which
> both a reporter and upstream agree should close #379900. Please, if you
> deem the package uploadable, do grab the new version first, from the
> same URL: 
>  http://www.nul-unu.com/quien/rodrigo/debian/liferea/liferea_1.0.27-2.dsc
> ]

Done.

> [EMAIL PROTECTED]:/# apt-get dist-upgrade
[...]
> The following packages have been kept back:
>   liferea
> 
> But
> 
> [EMAIL PROTECTED]:/# aptitude dist-upgrade
[...]
> The following packages will be automatically REMOVED:
>   liferea-gtkhtml
[...]
> The following packages will be REMOVED:
>   liferea-gtkhtml
> The following packages will be upgraded:
>   libdb4.3 liferea
> 
> (libdb4.3 gets upgraded because it's a two days old sid chroot :-)

It's interesting that aptitude does the right thing, but apt-get bombs out. 
This reminds me of a long-past conversation about the differences between
the two programs, but I can't remember what the outcome was.  

I've got a question on your transition decision, which I can't work out: you
got rid of the liferea-gtkhtml package completely, but the liferea-mozilla
package is a stub.  Why not either get rid of liferea-mozilla or leave
liferea-gtkhtml as a stub as well?  After all, if liferea-gtkhtml is a stub
package, then the upgrade works fine as liferea-xulrunner gets pulled in as
expected.  Certainly, no amount of jiggering around with
Conflicts/Replaces/Provides and reading Policy and the DevRef is solving the
problem for me -- I think the Conflicts/Replaces thing is really only
appropriate for renaming packages, rather than subsuming their capabilities
into an existing package.

- Matt


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

Re: RFS: liferea 1.0.27-2 [Upgrading problems]

[Matthew Palmer]

On Sun, Feb 11, 2007 at 09:44:45PM -0600, Luis Rodrigo Gallardo Cruz wrote:
> On Sun, Feb 11, 2007 at 01:43:52PM +1100, Matthew Palmer wrote:
> > On Fri, Feb 09, 2007 at 10:39:28PM -0600, Luis Rodrigo Gallardo Cruz wrote:
>  
> > > [EMAIL PROTECTED]:/# apt-get dist-upgrade
> > [...]
> > > The following packages have been kept back:
> > >   liferea
> > 
> > I've got a question on your transition decision, which I can't work out: you
> > got rid of the liferea-gtkhtml package completely, but the liferea-mozilla
> > package is a stub.  Why not either get rid of liferea-mozilla or leave
> > liferea-gtkhtml as a stub as well?  After all, if liferea-gtkhtml is a stub
> > package, then the upgrade works fine as liferea-xulrunner gets pulled in as
> > expected.
> 
> Yes, this was the way. I decided to leave liferea-gtkhtml as a stub,
> I'll work on finally removing it for lenny.
> 
> New, working, package at the same URL. I ended up removing the patch
> from the last update, as the poster wrote later saying it didn't solve
> the problems after all.

Took us a while, but it's now sorted and I've just uploaded it.

- Matt


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

Re: debian: user-request-daemon (it could solve some problems)

[Matthew Palmer]

On Thu, Feb 15, 2007 at 11:29:36PM +0100, Curt Manucredo wrote:
> i am not quiet sure about sudo, since it asks from time to time a
> password.

Then you haven't put NOPASSWD: in the relevant sudoers entry.  It works like
a charm.

Oh, and I think that you've totally over-complicated the wheel in your
urequestd thing.

- Matt


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

Re: i need help with

[Matthew Palmer]

On Mon, Feb 19, 2007 at 08:22:30PM -0800, FROM FILA wrote:
> {libglade) i been tying to install for the last month and it's killing me, i
> get a message that says not installable so i go to problems and that say
> Aplication package is incompatible with current software but i have the
> lastest?? can you help me or tell me what am i doing wrong i am new to the
> whole tablet thing so you might understand my trouble, i can be reach  at

This is a question better suited for the debian-user list.  debian-mentors
is for helping people create and maintain packages in Debian.

- Matt


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

Re: debian: user-request-daemon (it could solve some problems)

[Matthew Palmer]

On Tue, Feb 27, 2007 at 04:17:10AM +0100, Curt Manucredo wrote:
> i could never imagine that it is possible to call a command and then
> have root rights for it, without authentificating on the system with a
> password. so i thought a daemon running as root might solve that problem
> (which i thought it does exist) ;-). but since today i can not imagine
> how sudo is doing that - it might be very difficult to explain since i
> couldn't find an explantion on the net.
> so, how is sudo doing this auth-job, even with no
> password-verification. how does sudo treat the system?

/etc/sudoers tells sudo who is allowed to do what, who needs to give a
password or not, and so on.  The 'sudo' command itself is a setuid binary,
which means that even when run as an ordinary user, the program has the
rights of it's owner -- in this case root -- and can therefore do anything
that root can do.

Yes, exploitable setuid programs are a big security risk.  But they're
invaluable in cases like sudo.

- Matt


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

Re: Build package first, or change to ITA first?

[Matthew Palmer]

On Tue, May 22, 2007 at 10:51:45PM +0100, Richard Fearn wrote:
> I was wondering whether I should change the package from "RFA" to "ITA" 
> now, even though I've got some way to go before I'm competent enough to 
> create packages. I feel that adopting the package, when I won't be able 
> to package it properly for a while yet, might not be the best thing to do.

You do currently intend to adopt the package, so an ITA seems entirely
appropriate.  Putting a comment in the bug log to the effect that it might
be a while before any new packages see the light of day because you're
getting up to speed is a good idea too, though.

- Matt


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

Re: RFS: enblend

[Matthew Palmer]

On Thu, May 31, 2007 at 01:04:57PM +0200, [EMAIL PROTECTED] wrote:
> On Wed, May 30, 2007 at 12:15:03AM +0200, Sebastian Harl wrote:
> >   - The files under src/win32helpers are released under the 4-clause BSD
> > license which is incompatible with the GPL. Thus distributing them as 
> > part
> > of a GPL'ed program is illegal - the .orig.tar.gz should be repackaged 
> > to
> > not include those files (they are only needed under Windows anyway) and
> > '+dfsg' should be added to the version number.
> 
> Okay, i removed those files. Adding +dfsg to the version number means
> that the package is modified to comply, right? But why is it done then -
> i thought every package in main has to comply with dfsg, so its clear
> that the packages in main either comply or are modified to comply by the
> packager. (don't get me wrong - i dont put adding +dfsg in question, i
> just want to understand why its done ;P).

It's to make it clear, from the very outset, that what you're getting in the
Debian .orig.tar.gz isn't quite the same as what you're getting by
downloading the upstream tarball.  People tend to expect (to the point of
using the Debian mirrors as a kind of upstream source mirror!) that the
.orig.tar.gz is identical to upstream's release.  The +dfsg just makes it
clear, by modifying the upstream version number a bit, that that isn't the
case.

- Matt


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

Re: Advice on packaging SAGE

[Matthew Palmer]

On Thu, May 31, 2007 at 06:01:53PM -0700, Russ Allbery wrote:
> Charles Plessy <[EMAIL PROTECTED]> writes:
> 
> > It is exactly because it is anyway wrong to not cite authors that it is
> > better to leave the requirement out of the licence. When we publish
> > scientific articles, we do not put a disclaimer on the top saying "if
> > you read this article, you must properly cite it if you re-use some
> > results or concepts in your research."
> 
> > Having that kind or requirement in licences has multipls consequences:
> 
> > - It makes the software non-compliant to the DFSG.
> 
> Why?  I don't see anything in the DFSG that says that licenses may not
> require citing authors, and in fact many DFSG-free licenses require that
> one preserve copyright statements or authorship information.

I don't think we want to turn d-mentors into an alternate debian-legal. 

- Matt


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

Re: CC by-SA 3.0 is DFSG-free?

[Matthew Palmer]

On Sun, Jun 10, 2007 at 02:01:15AM +0900, Hideki Yamane wrote:
>  I've made Konatu font package (ttf-konatu) 
>  http://www.masuseki.com/index.php?u=be/konatu.htm
>  and I have a question about its license is dfsg-free or not.
> 
>  It is licensed under Creative Commons Attribution-ShareAlike 3.0.
>  http://creativecommons.org/licenses/by-sa/3.0/
> 
>  I saw some discussions about CC3.0 and DFSG, but I don't know about 
>  its conclusion - dfsg-free or not. Could someone tell me about it?
>  If it meets dfsg-free, I would do ITP for that package.

The best place to ask this question is on the debian-legal mailing list.  It
might be a little intense at times, but it's far more likely to provide an
answer than this list is.

- Matt


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

Re: debian files in sourceforge cvs

[Matthew Palmer]

On Wed, Jun 27, 2007 at 11:07:17AM -0300, Tiago Saboga wrote:
> I am working closely with upstream devs, and I am willing to manage
> the debian files in the same sourceforge cvs. I understand that the
> upstream tarball should not contain the debian files; OTOH,
> sourceforge asks that all files in cvs should be released (and I
> understand them too, it's free software).

Ignore SourceForge, for they know not what they say.  There's shedloads of
files in your CVS thee you don't want ending up in your released tarballs --
your test suite, for one.  Just drop the debian/ dir from your release
tarballs and let everyone be happy.

> in debian wiki and in this list's archives and I have not found a tip
> as to what is the best way to address both sides preferences. 

Ignore SourceForge.  If they get snippy, tell 'em to talk to me.  

> I thought about making a separate release just for the debian files,
> making clear that the files in debian archive should be used instead,
> but it's a little ugly, isn't it?

It's a whole world of ugly.  The only people who want the debian/ directory
in their tarballs are the few people at this time who can't get it from
Debian and who desperately want a package they can install.  Other distros
don't want it, Debian itself doesn't want it, people who install from
tarballs don't want it.  If you *really* want to include those people, make
a Debian source package (.dsc, .diff.gz) and ship that until the package
gets into Debian proper.

- Matt


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

Re: debian files in sourceforge cvs

[Matthew Palmer]

On Wed, Jun 27, 2007 at 10:59:12AM -0500, Raphael Geissert wrote:
> On 27/06/07, Tiago Saboga <[EMAIL PROTECTED]> wrote:
> >I am working closely with upstream devs, and I am willing to manage
> >the debian files in the same sourceforge cvs. I understand that the
> >upstream tarball should not contain the debian files;
> 
> I'm not quite sure, but I think that would be a 'Debian native' package.

No, it should not be a Debian-native package.  Please do not advocate this
without understanding the actual intent of a Debian-native package -- that
the package makes no sense outside of Debian.

- Matt


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

Re: debian files in sourceforge cvs

[Matthew Palmer]

On Wed, Jun 27, 2007 at 08:49:47PM -0400, Roberto C. Sánchez wrote:
> On Thu, Jun 28, 2007 at 07:50:58AM +1000, Matthew Palmer wrote:
> > On Wed, Jun 27, 2007 at 10:59:12AM -0500, Raphael Geissert wrote:
> > > On 27/06/07, Tiago Saboga <[EMAIL PROTECTED]> wrote:
> > > >I am working closely with upstream devs, and I am willing to manage
> > > >the debian files in the same sourceforge cvs. I understand that the
> > > >upstream tarball should not contain the debian files;
> > > 
> > > I'm not quite sure, but I think that would be a 'Debian native' package.
> > 
> > No, it should not be a Debian-native package.  Please do not advocate this
> > without understanding the actual intent of a Debian-native package -- that
> > the package makes no sense outside of Debian.
> 
> There is something else to consider.  Even some packages which make no
> sense outside of Debian should not be Debian native packages.  The
> reason is that the Debian native pacakage has no .orig.tar.gz and
> .diff.gz.  Only a single .tar.gz.  That means that *every* single
> package update requires incrementing the "upstream" version number
> and uploading the entire source all over again, even for trivial
> packaging-related changes.

Which for packages that *should* be Debian-native isn't a problem, because
their only possible destination is Debian anyway.

- Matt

debian-mentors FAQ updated

[Matthew Palmer]

Finally, after much delay, I've got a new version of the FAQ uploaded to
it's usual place at
http://people.debian.org/~mpalmer/debian-mentors_FAQ.html .

Updates in this "release":

  * Add a comment about telling everyone you got sponsored to reduce
duplication of effort.  (Christoph Haas)

  * Add a link to the d-w mentoring program

  * Enhance the 'how do I add a new package to the archive' question.  (Paul
Wise)

  * Add a link to the d-w BTS howto

  * Switch from using top-level ULs for questions to actually using headings.

  * Add a link to the d-w packaging tutorial

  * Switch the #debian-mentors channel to OFTC, where it lives now.  (Eric
Rzewnicki)

  * Remove the madduck.net Arch wiki page (Martin F. Krafft / Andreas Fester)

  * Remove the 'this is a draft' thing from my sponsorship info page.

  * Add a paragraph on building packages to the 'How do I make my first
package' question, including a link to the HowToPackageForDebian wiki
page

  * Improve the wording of 'what happens if I can't find a sponsor?' and
update the number of sections.  (Sandro Tossi)

Please check over this new version and suggest any improvements you think
of.  I'll hopefully get your changes integrated quicker next time around.

Thanks,
- Matt


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

Another revision of the d-m FAQ

[Matthew Palmer]

In my last update of the FAQ, I forgot to include a substantial rework of
the difference between native and non-native packages from Thijs Kinkhorst. 
The rework also split the discussion on why debian dirs in upstream tarballs
is bad, which should help in the future when people ask about it -- now
you've got something to point them at.

Thanks Thijs, and thanks also to everyone else who has contributed material
to the FAQ in the past.

- Matt


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

Re: dpkg-buildpackage and fakeroot

[Matthew Palmer]

On Sat, Jul 14, 2007 at 12:50:32AM -0500, Manoj Srivastava wrote:
> On Tue, 10 Jul 2007 11:46:13 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 
> 
> > 'fakeroot dpkg-buildpackage' runs the build target under fakeroot,
> > which is undesirable primarily because Debian 'build' targets are
> > required to not depend on root privileges, and running them under
> > fakeroot can hide bugs of this nature.
> 
> I also vaguely recall some actions which work as an ordinary
>  user but fail under fakeroot; due to a difference in behaviour.  I no
>  longer can recall the details, though, so I could be mistaken.

The bzr test suite, for one.

- Matt


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

Re: RFS: ftpsync -- fast ftp directory synchronization

[Matthew Palmer]

On Sun, Jul 15, 2007 at 05:13:58PM +0200, Julian Andres Klode wrote:
> I am looking for a sponsor for my package "ftpsync".

Any major feature improvements over sitecopy?

- Matt


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

Re: Broken uploads to mentors.debian.net

[Matthew Palmer]

On Sun, Jul 15, 2007 at 10:41:57PM +0200, Christoph Haas wrote:
> I have no good explanation for the situation Neil mentioned though. The
> package maintainer must have uploaded a package with an orig tarball.
> But then the orig tarball was changed and an upload without an orig
> tarball was done that mentioned the orig tarball though.
> 
> How come the .dsc file mentions an orig file that is not uploaded? All
> files mentioned in the .dsc file must be uploaded. I'm confused.

No they don't.  All the files mentioned in a .changes get uploaded, because
the .changes represents the changes made to the archive (hence the name). 
In contrast, a .dsc describes a particular Debian source package.  If
someone builds a Debian source package with a different .orig.tar.gz to
another source package (of the same source package name and upstream
version), then you'll get a different .orig.tar.gz mentioned in the .dsc.
What happens from there is a matter for whatever is processing the .dsc
after that.

>From a personal perspective, I think m.d.n should work as close to
ftp-master as possible.  If you want to keep the ability to have people take
multiple stabs at a single package revision, then at the very least, .dsc
files should be verified after upload and if the sums don't *all* match or
one of the files in the .dsc is missing, the upload is rejected.  That would
solve Neil's problem, at the very least.

- Matt


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

Re: RFS: fuse (updated package)

[Matthew Palmer]

On Tue, Jul 24, 2007 at 11:21:09AM +0200, "Adam Cécile (Le_Vert)" wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 2.7.0-1
> of my package "fuse".

I'm taking a look at this now.

- Matt


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

Re: Sponsored: fuse 2.7.0-1

[Matthew Palmer]

On Tue, Jul 24, 2007 at 11:21:09AM +0200, "Adam Cécile (Le_Vert)" wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 2.7.0-1
> of my package "fuse".

Looks solid.  Uploaded.

- Matt


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

Re: Getting involved with Debian development...

[Matthew Palmer]

On Thu, Jul 26, 2007 at 04:13:06PM -0400, Tim Hull wrote:
> Anyway, I am curious what exactly it entails to become a Debian developer,
> and what would be best to do if one wanted to involve
> oneself in Debian with this ultimate goal.

The FQ... the FAQ... 

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

- Matt


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

Re: Creating Source Packages

[Matthew Palmer]

On Sun, Jul 29, 2007 at 11:13:06AM +1000, Brendon Costa wrote:
> I have been looking on the web, but have found little in the way of
> tutorials on how to create a debian source package. I have created a
> binary package for my project (EDoc++: http://edoc.sourceforge.net/),
> but want to create a source package and then build the binary one from this.
> 
> Does anyone here know of a link where there is information on doing this
> sort of thing? I couldn't believe google didn't come up with anything as
> I am sure this is a VERY common way of creating debian packages.

It's *really* common -- pretty much every upload into Debian has to provide
the source package.  You just run 'dpkg-buildpackage -S' in the unpacked
tree and it'll do all the usual "dpkg-buildpackage" kind of things and
produce a source package including a .changes file.  If you want to get a
bit lower level, 'dpkg-source -b ' will just build the diff/dsc.

Manpages, as usual, will give you all the dirty details.

- Matt


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

Re: Creating Source Packages

[Matthew Palmer]

On Sun, Jul 29, 2007 at 02:59:53PM +1000, Brendon Costa wrote:
> > Actually, there is no one-file source package form of a deb like there
> > is for rpms. When you create your binary package, a signed .dsc file is
> > created with which you can create the deb in conjunction with the
> > original upstream tarball and the diff of the debian packaging.
> 
> Ahh that would have been my mistake. I thought there would have been a
> single .deb file that contained the source package similar to that of
> source rpm's.
> 
> I have those files listed below (Excepting the package_1.0-1.diff.gz) as
> there are no differences that need to be applied for debian. So a
> "source distribution" would just include the .dsc and .tar.gz file.

Take a look at
http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native
and the question after that ("What's wrong with upstream shipping a debian/
directory?").

- Matt


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

Re: php4 in lenny and Depends

[Matthew Palmer]

On Sun, Aug 12, 2007 at 03:33:20PM -0400, Kevin Coyner wrote:
> I have a package that I maintain that has a dependency on php4-cgi
> or php5-cgi.
> 
> If I remember correctly php4 will not be in lenny. Correct me if I
> was dreaming and misunderstood this.

Nope, I think you're right.  Last I heard, PHP4 was getting removed before
Lenny's release.

> If I am correct, then in any future repackagings of my packages for
> lenny, do I no longer need to Depend on php4-cgi and now just on
> php5-cgi?

You should definitely order your dependency so that php5-cgi comes first (eg
"php5-cgi | php4-cgi") but I'm not convinced that removing the option of
php4-cgi is necessarily a fantastic idea at this stage.  If your package
doesn't otherwise need packages (or versions of packages) that only exist in
unstable, then leaving the php4-cgi option there allows people to install
the newer package in their older environments (that perhaps use PHP4). 
While backporting is an alternative to this, I like to allow people maximum
flexibility.

(This isn't any sort of official pronouncement, just my personal opinion. 
If you get differing opinions from (eg) release team people or ftpmasters or
pretty much anyone, ignore me)

- Matt


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

Re: homebank (license issue)

[Matthew Palmer]

On Thu, Aug 16, 2007 at 02:42:19PM +0200, Francesco Namuri wrote:
> Hi mentors,
> I've received from the author of homebank a pre-release version 3.4 of
> homebank with new SVG icons released under GPL, I have a doubt regarding
> one of these icons, it is released with this license metadata:
> 
> rdf:about="http://web.resource.org/cc/PublicDomain";>
[...]
> It's ok for debian?

While the "concept" of Public Domain is fine for Debian, I'm a little
concerned about the execution.  This doesn't seem like a "proper" licence
grant, like the GPL boilerplate, and hence might not be considered to be
sufficiently clear for Debian to take the risk on.  I'd check with d-legal,
and perhaps try and get a clearer licence statement out of upstream.

- Matt


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