Re: RFC/RFS: rhinote -- virtual sticky-notes for your desktop

[Andrea Bolognani]

Hi mentors!

Here I am sending this RFC/RFS again.
Having corrected all the bugs/wishlist items which came up here on the list,
I feel Rhinote is finally ready to be uploaded.
Obviously, if someone finds any other problem, I'll be happy to fix it and
learn a little more :)

Below is the info about the package.

* Package: rhinote
  Version: 0.7.0
* License: GPL
  URL: http://greyspace.letzebuerg.org/projects.php
  Upstream author: Marv Boyes <[EMAIL PROTECTED]>
* Description: virtual sticky-notes for your desktop
 Rhinotes is a small program that provides virtual sticky-notes. It's handy
 for jotting down quick notes or holding copied text that you plan to paste
 elsewhere later.
 .
 Notes can be saved as plain text for later viewing/editing
 with Rhinote or any other text editor.
 .
 Rhinote is designed to be "keyboard friendly", that is, every single action
 is bound to a specific keystroke.

The package is both lintian and linda clean, builds (?) cleanly in an
up-to-date pbuilder environment and is available from the following URLs:

* http://www.kiyuko.org/debian/rhinote_0.7.0.orig.tar.gz
* http://www.kiyuko.org/debian/rhinote_0.7.0-1.diff.gz
* http://www.kiyuko.org/debian/rhinote_0.7.0-1.dsc

My little repository is also apt-gettable: just add the following lines to
your sources.list

deb http://www.kiyuko.org/debian ./
deb-src http://www.kiyuko.org/debian ./

Thank you for your patience.

Cheers.

-- 
KiyuKo 
"Like Russian Rulette with six bullets loaded"


pgpgxWZimODOE.pgp
Description: PGP signature

Re: proper way to package mozilla extensions

[Don Armstrong]

On Mon, 24 Apr 2006, Yaroslav Halchenko wrote:
> I am upgrading to the recent upstream one of the extensions I am
> maintaining. Finally I made a proper debian/watch file but now I need to
> decide which way to go on how to keep .orig.tar.gz. I've investigated a
> few packaged extensions and didn't find an answer to my question: how to
> perform automatic upgrade (via uscan). The reason is that
> 
> 1. There are two possible packaging schemes
>   a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it
>  at build time.
> 
>   b. Keep unzipped .xpi in .orig.tar.gz.

c. Distribute the actual source code in the orig.tar.gz.

No; please distribute the actual upstream source, and build the .xpi.
[Hint: this isn't the unpacked xpi either... it's probably whatever
upstream has in their VCS.]

Otherwise it's a PITA to actually patch the .xpi, as you have to
unpack it, unpack the jar, patch the jar, pack the jar, pack the xpi.

Most packages don't have rules files that do this, so it means that
any security patch is going to have to go mucking about in your
debian/rules to implement this packing/unpacking and then actually add
the patch itself. Save everyone's sanity, and actually distribute the
real upstream source in the orig.tar.gz, not the "binary" package that
upstream distributes.[1]

See Michael Spang's work on greasemonkey for an example on how to do
this.


Don Armstrong

1: Note that I personally won't sponsor mozilla modules that don't
distribute the actual source in the orig.tar.gz...
-- 
If it jams, force it. If it breaks, it needed replacing anyway.
 -- Lowery's Law

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: RFS: weather-util - command-line tool to obtain weather conditions and forecasts

[The Fungi]

On Mon, Apr 24, 2006 at 09:19:45PM -0700, Russ Allbery wrote:
[...]
> Looks good to me at this point.  I've gone ahead and uploaded it.  You
> should shortly get the notification that it's waiting in NEW.
[...]

Got it--thanks! I'll keep an eye on the new queue and see if/when it
gets into sid.

> Does using the command line switch work when there isn't an entry in the
> database?  I wasn't having any luck with just weather --id=KPAO, but I may
> have been missing something.  And indeed, it seems to be working now.
> Must have just been pilot error.

Yeah, the aliases defined in your weatherrc are just conveniences to
keep from typing a bunch of command-line switches and to group
values together into a more memorable name. Nothing magic about
them. I opted to provide a global set that pre-defines a lot of
airport abbreviations as an additional nicety, and hope to expand
that as time goes on. If it gets unwieldy, I may shift the presets
to /usr/share/weather/aliases.gz or something and let /etc/weatherrc
be more for the admins to centrally override what they want without
having to edit a huge list of defaults.

> Thank you for writing it!  This is something I'll probably use regularly.
> It's nice and simple and useful and doesn't require subjecting myself to
> piles of advertising on the web.

Necessity is the mother of invention. I was honestly shocked that I
couldn't find a tool capable of exactly this already in Debian, so
now hopefully nobody else has to be similarly shocked. My only
regret is that the (completely unrelated) "weather" package will be
in oldstable/non-free until etch+1, or I would have simply called my
package that.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: spcaview : package review needed

[Ben Finney]

On 25-Apr-2006, Ted Percival wrote:
> Paul Wise wrote:
> >   * debian/changelog: the version should be 0.0.20051212 or
> > 0.0.0.20051212 or something so that if upstream changes their
> > version scheme, you won't have to use [an] epoch.
> 
> Isn't that exactly what the epoch is for?

In a way. It's still much better to plan the version numbering scheme
to avoid epoch changes.

-- 
 \  "Everything is futile."  -- Marvin of Borg |
  `\   |
_o__)  |
Ben Finney <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: RFS: weather-util - command-line tool to obtain weather conditions and forecasts

[Russ Allbery]

Jeremy Stanley <[EMAIL PROTECTED]> writes:
> On Sun, Apr 23, 2006 at 07:35:29PM -0700, Russ Allbery wrote:

>> The reference to /usr/share/common-licenses/BSD is not really correct
>> since your software is not Copyright The Regents of the University of
>> California.  I'd remove that and just put the full text of the license
>> into debian/copyright.  Besides, your license doesn't actually match
>> anyway; you only have a two-clause license.

> Great point, and corrected (uploaded to the same repo). I didn't bump
> the package revision since I've seen some debates in here on whether
> it's a good idea to enter the new queue with something other than a -1
> rev, but I can easily do so and update the debian/changelog if such is
> your preference.

Nah, I prefer it the way that you did it.

Looks good to me at this point.  I've gone ahead and uploaded it.  You
should shortly get the notification that it's waiting in NEW.

> As per the FAQ, the default list is far from complete and submissions
> are welcomed.

Whoops, sorry, I should have RTFMed.  That explains the whole situation
nicely.  Thank you!

> The couple hundred I threw in there were ones where I was easily able to
> match the METAR up to a forecast path with an identical state and
> city/MSA name (via some quick and dirty awk magic). It's trivial to add
> your own aliases or even just use the command-line switches instead.

Does using the command line switch work when there isn't an entry in the
database?  I wasn't having any luck with just weather --id=KPAO, but I may
have been missing something.  And indeed, it seems to be working now.
Must have just been pilot error.

> Thanks for the interest and let me know if any other issues jump out
> at you!

Thank you for writing it!  This is something I'll probably use regularly.
It's nice and simple and useful and doesn't require subjecting myself to
piles of advertising on the web.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Help needed with architectures getting ignored

[Justin Pryzby]

On Tue, Apr 25, 2006 at 01:37:30PM +1000, Andree Leidenfrost wrote:
> Dear mentors,
> 
> My packages with explicit architecture lists don't get built by the
> autobuilders. I have checked the Debian Policy, Developer's Reference
> and New Mainatiner's Guide and believe that the following in the control
> file should be valid and work:
> 
> Architecture: amd64 i386 ia64
> 
> I upload the i386 and would expect amd64 and ia64 to be built by the
> autobuilders. Alas, this is not the case. 
> 
> As an example, while p.q.d.o clearly acknowledges that the architectures
> are amd64 i386 ia64 for my mindi package:
> 
> http://packages.qa.debian.org/m/mindi.html
> 
> p.d.o has only i386:
> 
> http://packages.debian.org/unstable/utils/mindi
> 
> The interesting thing is that amd64.debian.net has an amd64 version
> (just not the latest, probably because of the recent transition?):
> 
> http://amd64.debian.net/debian-amd64/pool/main/m/mindi/
> 
> I am aware that anything but 'any' for the architecture is frowned upon,
> but I am not aware that I need to take any particular steps to get them
> auto-built just on the specified architectures. (Just for the record,
> the software in question is quite heavily tied to the IA32 architecture
> and has recently been extended to IA64 but won't work on any other
> architecture right at the moment.)
> 
> It would be great if you could let me know what I am overlooking here
> and what I need to do to get the other architectures built by the
> autobuilders.
Your package is listed in packages-arch-specific:
  http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak&rev=HEAD

Which means that builds are never attempted.  See the comments for who
to ask for updates.

Justin


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

Help needed with architectures getting ignored

[Andree Leidenfrost]

Dear mentors,

My packages with explicit architecture lists don't get built by the
autobuilders. I have checked the Debian Policy, Developer's Reference
and New Mainatiner's Guide and believe that the following in the control
file should be valid and work:

Architecture: amd64 i386 ia64

I upload the i386 and would expect amd64 and ia64 to be built by the
autobuilders. Alas, this is not the case. 

As an example, while p.q.d.o clearly acknowledges that the architectures
are amd64 i386 ia64 for my mindi package:

http://packages.qa.debian.org/m/mindi.html

p.d.o has only i386:

http://packages.debian.org/unstable/utils/mindi

The interesting thing is that amd64.debian.net has an amd64 version
(just not the latest, probably because of the recent transition?):

http://amd64.debian.net/debian-amd64/pool/main/m/mindi/

I am aware that anything but 'any' for the architecture is frowned upon,
but I am not aware that I need to take any particular steps to get them
auto-built just on the specified architectures. (Just for the record,
the software in question is quite heavily tied to the IA32 architecture
and has recently been extended to IA64 but won't work on any other
architecture right at the moment.)

It would be great if you could let me know what I am overlooking here
and what I need to do to get the other architectures built by the
autobuilders.

Thank you very much & best regards,
Andree
-- 
Andree Leidenfrost
Sydney - Australia



signature.asc
Description: This is a digitally signed message part

Re: spcaview : package review needed

[Ted Percival]

Paul Wise wrote:
>   * debian/changelog: the version should be 0.0.20051212 or
> 0.0.0.20051212 or something so that if upstream changes their
> version scheme, you won't have to use [an] epoch.

Isn't that exactly what the epoch is for?

-T



signature.asc
Description: OpenPGP digital signature

Re: spcaview : package review needed

[Paul Wise]

On Mon, 2006-04-24 at 23:48 +0200, Le_Vert wrote:

> spcaview : package review needed

The convention is RFC: package -- package description

> http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212-1.dsc

Best to just specify the dsc/diff so we can go dget -x  for a
more thorough review, or open it in a browser for a quick one.

> Could you check this package before my sponsor upload it ? :

Some comments:

  * hopefully your sponsor will check it too ;)
  * debian/changelog: the version should be 0.0.20051212 or
0.0.0.20051212 or something so that if upstream changes their
version scheme, you won't have to use and epoch.
  * debian/control: might want to add the Homepage. see the devref
6.2.4 for how.
  * debian/compat: might want to consider dropping to 4 if you don't
use any debhelper 5 features (makes things slightly easier for
sarge backporters)
  * debian/control: package description could use some work, esp
grammar. consult either this list or the debian-l10n-english
list if english is not your first language. Also, check policy,
the devref and [1] for some helpful tips for descriptions.
  * debian/copyright: you miss the authors and some of the
copyrights, please read [2] and check them with mc and grep -rih
copyright . | sort -u
  * debian/rules: better to use quilt/dpatch than a homebrew patch
system
  * debian/rules: you can use debian/manpages instead of passing
arguments to dh_installman
  * debian/watch: please add one (read uscan(1) for more info)
  * debian/patches and debian/manpages: don't forget to send these
to upstream (except changing the BIN variable, upstream should
use /usr/local)
  * http-java-applet/install should probably get installed as a doc.
http-java-applet/index-sample.html and
http-java-applet/control.jpg should probably be installed using
dh_installexamples
  * orig.tar.gz: http-java-applet/JWebcamPlayer.jar contains
compiled bytecode, it *must not* be shipped (and probably should
be removed from the orig.tar.gz). You should recompile it using
free java if possible. If not, ask on the debian-java list, or
possibly the classpath developers for help porting it.
  * orig.tar.gz: what is the copyright/licence for SwingWorker.java?
looks like a copy of [3]. If so, that would be copyright by sun
and not distributable.
  * orig.tar.gz: please remove the build/install instructions from
the README (since debian users don't need them), and ask
upstream to split those out into INSTALL.
  * lintian/linda: give these errors:

E: spcaview source: debian-rules-missing-required-target binary-indep
N:
N:   The debian/rules file for this package does not provide one of the
N:   required targets. All of build, binary, binary-arch, binary-indep, and
N:   clean must be provided, even if they don't do anything for this
N:   package.
N:
N:   Refer to Policy Manual, section 4.8 for details.
N:
W: spcaview; 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.

 1. http://people.debian.org/~walters/descriptions.html
 2. http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
 3. 
http://java.sun.com/products/jfc/tsc/articles/threads/src/SwingWorker.java

-- 
bye,
pabs

http://pabs.zip.to


signature.asc
Description: This is a digitally signed message part

Re: Getting close to releasing my first .deb's... What's next?

[Russ Allbery]

Tyler MacDonald <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> wrote:

>> The general rule of thumb is that if there is any intention whatsoever
>> that the package be used on a platform other than Debian, the Debian
>> packaging and the upstream source should be separate.

>   Okay, so what do you guys do about upstream sources that already
> have a debian/ directory? Just gripe and deal with it?

Yup.  :)

>> The Debian packaging and the upstream source are often going to change
>> independently; there will be fixes for Debian (such as changes to the
>> dependencies) that won't result in any changes to the upstream source
>> and for which there's no reason to do a new upstream release.

>   I would probably do a new upstream release anyways, with a
> changelog entry like "Depend on new and improved package  under
> debian", and maybe find an excuse to throw in a few other patches as
> well. If anything, it means the word "debian" will appear on the
> freshmeat front page for a few seconds. ;-)

*grin*.  Fair enough.

>   So I guess I will roll mod_bt 0.0.15 *without* the debian/
> directory, even though debianizability was the primary focus of that
> release. (Don't worry, there's still a few other things going into it as
> well.) But, on the record, it really irks me that it has to be that
> way. :-)

It's one of the ways in which Debian is different than a lot of other
distributions.  People tend to just toss their Red Hat spec files into the
same package distribution.  But I think a lot of that is because people
get RPMs from all over the place and have a whole hodgepodge of different
things on their system, whereas with Debian the emphasis is on having one
central trusted location for (nearly) all Debian packages of interest.

Separating the Debian packaging and the upstream source makes it a bit
clearer that the Debian packaging is allowed to have an independent
existence from upstream and that Debian as a project is taking on some
willingness to keep the package up to date or at least retire it in an
orderly fashion if it can't be maintained any more.  If, for instance, you
should for some reason lose interest in the project but someone else still
wanted to maintain the Debian packages, they would move forward and
continue to make modifications in the debian/ directory.

It's a bit hard to explain, as it really is a sort of "feel" thing, but I
started with exactly the same feelings as you have and came around to
doing the split for my own packages.  One of the things I like about
Debian is the emphasis on consistency across Debian and integration into
the Debian packaging tools, emphasized over and above consistency with any
single upstream.  When I'm upstream myself, it feels weird, but since I
like how the principal works in all other cases, it feels right to play
ball with my own software as well.  As the maintainer of, say, kstart, I'm
really wearing two hats: I'm the upstream maintainer and I'm the Debian
packager.  The separate debian/ directory is sort of a psychological
separation of hats that keeps it clearer that I may not always and forever
wear both hats.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Getting close to releasing my first .deb's... What's next?

[Tyler MacDonald]

Russ Allbery <[EMAIL PROTECTED]> wrote:
> The general rule of thumb is that if there is any intention whatsoever
> that the package be used on a platform other than Debian, the Debian
> packaging and the upstream source should be separate.

Okay, so what do you guys do about upstream sources that already
have a debian/ directory? Just gripe and deal with it?

> The Debian packaging and the upstream source are often going to change
> independently; there will be fixes for Debian (such as changes to the
> dependencies) that won't result in any changes to the upstream source and
> for which there's no reason to do a new upstream release. 

I would probably do a new upstream release anyways, with a changelog
entry like "Depend on new and improved package  under debian", and maybe
find an excuse to throw in a few other patches as well. If anything, it
means the word "debian" will appear on the freshmeat front page for a few
seconds. ;-)

> Also, including the debian directory in the upstream release makes it
> somewhat harder to package, since the packager has to worry about files
> that may not be accurate for packaging changes and that have to be removed
> so that debhelper doesn't do the wrong thing, which is hard to do with a
> diff.

Fair enough...

> I'm in the same boat as you and am unlikely to ever use something other
> than Debian, but I made this separation for all of my packages.  I
> actually keep everything together in Subversion, including the debian
> directory, but exclude the debian directory from the distribution and
> build Debian packages by exporting the Debian directory from Subversion
> over a virgin source untar.
> 
> 
> 
> has some additional details for how I do this personally.

There is a *wealth* of good information there. Thanks!!

So I guess I will roll mod_bt 0.0.15 *without* the debian/
directory, even though debianizability was the primary focus of that
release. (Don't worry, there's still a few other things going into it as
well.) But, on the record, it really irks me that it has to be that way. :-)

Cheers,
Tyler


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

Re: Getting close to releasing my first .deb's... What's next?

[Russ Allbery]

Tyler MacDonald <[EMAIL PROTECTED]> writes:

>   Okay... to make my intentions clear:

>   I've been using debian now since 1999 and don't see myself
> changing distributions at any point in the future. I love debian. The
> first thing I do when I get a blank harddrive is install debian on it
> and I encourage all of my friends to do the same. (Yes, I looked at
> ubuntu briefly, but decided they weren't offering me anything that made
> it worth distancing myself from the core). I've been working on mod_bt
> for two years now, and the entire time the eventual end goal has been a
> debian package. One of my daydreams has been a special netboot image
> that quickly deploys a mod_bt-centric webserver running debian, just scp
> or ftp in your content and .torrents and it starts seeding. I don't want
> to exclude non-debian types from using mod_bt (in fact, I'm going to be
> looking into how to get it to work properly under win32 soon), but the
> primary target environment has always been debian. Whenever I am not the
> debian maintainer for mod_bt, I would accept patches from the maintainer
> to keep my debian/ tree in sync with what's actually needed, and/or give
> the maintainer commit access to the CVS tree where it's stored.

>   So with that understood,

>   1. Do I still need to make it an ".orig" package, even if it will
> have a zero-byte diff?

>   2. Is having a "debian/" directory in the tarball such a bad thing?
> In a way, it advertises debian to anybody that downloads the source.

The general rule of thumb is that if there is any intention whatsoever
that the package be used on a platform other than Debian, the Debian
packaging and the upstream source should be separate.  The Debian
packaging and the upstream source are often going to change independently;
there will be fixes for Debian (such as changes to the dependencies) that
won't result in any changes to the upstream source and for which there's
no reason to do a new upstream release.  Also, including the debian
directory in the upstream release makes it somewhat harder to package,
since the packager has to worry about files that may not be accurate for
packaging changes and that have to be removed so that debhelper doesn't do
the wrong thing, which is hard to do with a diff.

I'm in the same boat as you and am unlikely to ever use something other
than Debian, but I made this separation for all of my packages.  I
actually keep everything together in Subversion, including the debian
directory, but exclude the debian directory from the distribution and
build Debian packages by exporting the Debian directory from Subversion
over a virgin source untar.



has some additional details for how I do this personally.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Getting close to releasing my first .deb's... What's next?

[Piotr Ozarowski]

sorry, correct version: (I should probably go to sleep...)

$ cd package-version
$ mv debian ../
$ tar zcf ../package_version.orig.tar.gz ./
$ mv ../debian ./
$ debuild

-- 
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-


pgpUvD01r4ygH.pgp
Description: PGP signature

Re: Getting close to releasing my first .deb's... What's next?

[Piotr Ozarowski]

Tyler MacDonald ([EMAIL PROTECTED]):
>   1. Do I still need to make it an ".orig" package, even if it will
> have a zero-byte diff?

Follow these steps:

$ cd package.version
$ mv debian ../
$ tar zcf package_version.orig.tar.gz ./
$ mv ../debian ./
$ debuild

-- 
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-


pgpo2OEz1ZOOz.pgp
Description: PGP signature

Re: Getting close to releasing my first .deb's... What's next?

[Tyler MacDonald]

Justin Pryzby <[EMAIL PROTECTED]> wrote:
> > 4. W: libbtt: non-dev-pkg-with-shlib-symlink usr/lib/libbtt.so.0.0.0 
> > usr/lib/libbtt.so
> > Should I care?
> Is it a public shared library?  (Do other packages link to it?)  If
> not, you can/should try to move it out of /usr/lib.  

It's potentially a public shared library. I doubt anybody else is
using it right now, but I intend to document the interface and at least
*I'll* probably build other package that use it in the future.

Cheers,
Tyler


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

Re: Getting close to releasing my first .deb's... What's next?

[Justin Pryzby]

On Mon, Apr 24, 2006 at 03:01:23PM -0700, Tyler MacDonald wrote:
> 
> I'm working on creating .deb packages for one of my projects, with the
> eventual goal of having it included in the debian distribution.
> 
> I've browsed through the policy manual, new maintainers guide, etc, and I've
> successfully created a "debian/" directory in my project that allows debuild
> to produce the files here:
> 
>   http://www.crackerjack.net/mod_bt/experimental_debs/
> 
> These files aren't signed (yet). I know that's the next step. :-) But then,
> what about after that Before I seek a sponsor I'd like to have all the
> spit-n-polish done and have these packages as close to "perfect", but
> there's a few issues I'm not sure how to deal with:
> 
>   1. lintian complains that I don't have manpages for my executables.
> This is because the project is still young and they haven't actually been
> written yet. However, the executables aren't the meat of the project,
> they're just nice-to-haves and some may disappear/get re-arranged. Is the
> lack of manpages for these tools a blocker? I've noticed several packages
> that get installed with a generic "no manpage was written for this" manpage,
> can I just do that for now?
You can write a single manpage that documents all the executables, and
modify it as they come and go.  dh_undocumented creates the "not yet
documented" link, but this is depreciated.

>   4. W: libbtt: non-dev-pkg-with-shlib-symlink usr/lib/libbtt.so.0.0.0 
> usr/lib/libbtt.so
>   Should I care?
Is it a public shared library?  (Do other packages link to it?)  If
not, you can/should try to move it out of /usr/lib.  

Justin


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

Re: Getting close to releasing my first .deb's... What's next?

[Tyler MacDonald]

Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> Just include no manpage at all. Don't silence Lintian for it, because man
> pages need to be made eventually. However, will the binaries really change
> that much that it creating man pages would be wasted effort? Just some
> general documentation is already a lot more helpful than nothing at all.
> My advice would be to include as much of a manpage as is reasonable
> looking at what you expect of the future of that binary.

Fair enough. :-) 4/5ths of them are perl scripts, so it'll be easy
to add a bit of POD and look at prior art for turning that into a deb
manpage. However, I expect bt_db2xml.c in particular to change quite a bit
in the future.

> Your package is a "Debian native" package, i.e. without an orig.tar.gz.
> That's not considered a good idea unless it's really Debian-specific.
> Normally you'd have an .orig.tar.gz from upstream and a .diff.gz with the
> Debian-specific changes.

> Please don't include the 'debian/' directory in the upstream tarball. This
> is just a little convenient when maintainer == upstream, but as soon as
> either one changes, this can lead to confusion when the debian-diff is a
> diff over an existing debian dir. There's been quite some discussion about
> this previously.

Okay... to make my intentions clear:

I've been using debian now since 1999 and don't see myself changing
distributions at any point in the future. I love debian. The first thing I
do when I get a blank harddrive is install debian on it and I encourage all
of my friends to do the same. (Yes, I looked at ubuntu briefly, but decided
they weren't offering me anything that made it worth distancing myself from
the core). I've been working on mod_bt for two years now, and the entire
time the eventual end goal has been a debian package. One of my daydreams
has been a special netboot image that quickly deploys a mod_bt-centric
webserver running debian, just scp or ftp in your content and .torrents and
it starts seeding. I don't want to exclude non-debian types from using
mod_bt (in fact, I'm going to be looking into how to get it to work properly
under win32 soon), but the primary target environment has always been
debian. Whenever I am not the debian maintainer for mod_bt, I would accept
patches from the maintainer to keep my debian/ tree in sync with what's
actually needed, and/or give the maintainer commit access to the CVS tree
where it's stored.

So with that understood,

1. Do I still need to make it an ".orig" package, even if it will
have a zero-byte diff?

2. Is having a "debian/" directory in the tarball such a bad thing?
In a way, it advertises debian to anybody that downloads the source.

> You can use the debian BTS as your upstream bts though, as long as you're
> keeping it in shape of course :)

Awesome!!

Thanks,
Tyler


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

Re: Getting close to releasing my first .deb's... What's next?

[Thijs Kinkhorst]

Hello Tyler,

On Tue, April 25, 2006 00:01, Tyler MacDonald wrote:
> I'm working on creating .deb packages for one of my projects, with the
> eventual goal of having it included in the debian distribution.

Then you've come to the right place for help :)

I'm out of town, so just some general comments here:

Your package is a "Debian native" package, i.e. without an orig.tar.gz.
That's not considered a good idea unless it's really Debian-specific.
Normally you'd have an .orig.tar.gz from upstream and a .diff.gz with the
Debian-specific changes.

> 1. lintian complains that I don't have manpages for my executables.
> This is because the project is still young and they haven't actually been
> written yet. However, the executables aren't the meat of the project,
> they're just nice-to-haves and some may disappear/get re-arranged. Is the
>  lack of manpages for these tools a blocker? I've noticed several
> packages that get installed with a generic "no manpage was written for
> this" manpage, can I just do that for now?

Just include no manpage at all. Don't silence Lintian for it, because man
pages need to be made eventually. However, will the binaries really change
that much that it creating man pages would be wasted effort? Just some
general documentation is already a lot more helpful than nothing at all.
My advice would be to include as much of a manpage as is reasonable
looking at what you expect of the future of that binary.

> 2. "php5-apache2-mod-bt". This package actually needs php5, apache2,
> and mod-bt to be installed and links them all together, providing a php5
> interface to inspect the data of a running mod_bt tracker on an apache2
> server. Should the ordering of the name be rearranged? Like
> "libapache2-php5-mod-bt" or something?

I'm not entirely sure since I'm not well aware of the specifics of your
module. If other people on this list can't help with that, you could
consider contacting e.g. the debian-apache list for a second review of
your package.

> 3. Currently, one set of documentation is generated for all of
> mod_bt's components. All of the components are part of the same
> distribution and released under the same license (Apache 2.x). I'm
> guessing I should place this documentation in the deepest common
> dependancy (libbtt) and symlink the other package's share/doc/ directories
> over there. I saw that libzvt does that with it's -dev package.. Is that a
> generally accepted practice? Even if we're talking about 8 different
> .deb's?

Sure. Just make sure that users have the documentation they need when they
install just one of the packages, and that they have all information
required by policy (Debian changelog).

> Also, one other thing; once mod_bt gets injected into debian, I was
> toying with the idea of having the debian BTS be the mod_bt's official bug
>  tracking database. This would save having to maintain two bug lists,
> forward things upstream, etc., especially because as of 0.0.15 I'll be
> distributing the source debian-ready. To get used to it I've set up a
> debbugs server to play with (http://bts.yi.org/). Is it acceptable to use
> the debian bug database as the official bug database for a package that's
> available in debian, but also available elsewhere? (eg; if I made RPM's,
> etc)

Please don't include the 'debian/' directory in the upstream tarball. This
is just a little convenient when maintainer == upstream, but as soon as
either one changes, this can lead to confusion when the debian-diff is a
diff over an existing debian dir. There's been quite some discussion about
this previously.

You can use the debian BTS as your upstream bts though, as long as you're
keeping it in shape of course :)


Good luck with your package!

Thijs


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

Getting close to releasing my first .deb's... What's next?

[Tyler MacDonald]

I'm working on creating .deb packages for one of my projects, with the
eventual goal of having it included in the debian distribution.

I've browsed through the policy manual, new maintainers guide, etc, and I've
successfully created a "debian/" directory in my project that allows debuild
to produce the files here:

http://www.crackerjack.net/mod_bt/experimental_debs/

These files aren't signed (yet). I know that's the next step. :-) But then,
what about after that Before I seek a sponsor I'd like to have all the
spit-n-polish done and have these packages as close to "perfect", but
there's a few issues I'm not sure how to deal with:

1. lintian complains that I don't have manpages for my executables.
This is because the project is still young and they haven't actually been
written yet. However, the executables aren't the meat of the project,
they're just nice-to-haves and some may disappear/get re-arranged. Is the
lack of manpages for these tools a blocker? I've noticed several packages
that get installed with a generic "no manpage was written for this" manpage,
can I just do that for now?

2. "php5-apache2-mod-bt". This package actually needs php5, apache2,
and mod-bt to be installed and links them all together, providing a php5
interface to inspect the data of a running mod_bt tracker on an apache2
server. Should the ordering of the name be rearranged? Like
"libapache2-php5-mod-bt" or something?

3. Currently, one set of documentation is generated for all of
mod_bt's components. All of the components are part of the same distribution
and released under the same license (Apache 2.x). I'm guessing I should
place this documentation in the deepest common dependancy (libbtt) and
symlink the other package's share/doc/ directories over there. I saw that
libzvt does that with it's -dev package.. Is that a generally accepted
practice? Even if we're talking about 8 different .deb's?

4. W: libbtt: non-dev-pkg-with-shlib-symlink usr/lib/libbtt.so.0.0.0 
usr/lib/libbtt.so
Should I care?

5. W: libbtt: package-name-doesnt-match-sonames libbtt0
I suppose I should care about that, but how does it pan out for the
packages that depend on it? Should libbtt-utils be named libbtt0-utils? Or
should it stay named the same and always depend on the libbttX package it
was built against?

There's a few other misc. lintian warnings i'm seeing that I know
how to fix, I'm going to work through those... but I'd love any advice on
how to proceed with those above, as well as any other suggestions people may
have... I've put off debianizing mod_bt for a lng time now because the
debian/ folder made me nervous, but I think I'm finally getting a handle on
it. :)

Also, one other thing; once mod_bt gets injected into debian, I was
toying with the idea of having the debian BTS be the mod_bt's official bug
tracking database. This would save having to maintain two bug lists, forward
things upstream, etc., especially because as of 0.0.15 I'll be distributing
the source debian-ready. To get used to it I've set up a debbugs server to
play with (http://bts.yi.org/). Is it acceptable to use the debian bug
database as the official bug database for a package that's available in
debian, but also available elsewhere? (eg; if I made RPM's, etc)

Thanks,
Tyler






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

spcaview : package review needed

[Le_Vert]

Hello,

Could you check this package before my sponsor upload it ? :

http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212-1.dsc
http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212-1.diff.gz
http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212.orig.tar.gz


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: proper way to package mozilla extensions

[Yaroslav Halchenko]

> >1. There are two possible packaging schemes
> > a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it
> >at build time.
> > b. Keep unzipped .xpi in .orig.tar.gz.
> > I was going the b. way but now I think that keeping original .xpi
> > would be better
> I'm no DD, but I would say (a) is nicer because then a checksum can be 
> verified more easily.
:-) Actually this is the only way the checksum can be verified ;-) as
soon as you extract it, there is no way (besides downloading xpi,
extracting and md5suming all the files) to verify the authenticity of
upstream release.

This is what I think and that is why I would like to move over keeping
original .xpi. And the question is did anyone done it proper way to
automate it with uscan + svn-upgrade... :-)

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




pgpbWoC9fMAzi.pgp
Description: PGP signature

Re: RFS: thailatex (orphaned package for babel-based Thai latex support)

[Frank Küster]

"Theppitak Karoonboonyanan" <[EMAIL PROTECTED]> wrote:

> Dear mentors,
>
> I have adopted the orphaned thailatex package in the bug:
>   http://bugs.debian.org/357871
>
> And now the brand new package has been dressed up,
> waiting for sponsoring.

I'm willing to look into it and finally sponsor it (especially since my
recent NMU might have caused this or that bug).  There are still some
minor things to do:

- debian/changelog:

  * You shouldn't close bugs with "new upstream release" as an
explanation, unless it's a request to package the new version.
Instead, write something like 

  * New upstream release
- now has a orig.tar.gz again (closes: #344554)
- ... babel.sty ... (closes:  #351501)
- updated fonts
- new Loma font

  * the "bumped standards version to..." section usually also gets an
explanation (like "no changes needed" or "lots of packaging changes,
details below", or whatever).

- debian/copyright:

  Should mention where babel.sty comes from.  I assume it's a newer
  upstream version than teTeX's.  Anyway, be sure to follow the
  instructions in 3.4 of the Debian TeX Policy Draft, especially the
  second paragraph under number 2. (hint: the maintainer address for the
  Basic TeX packages is [EMAIL PROTECTED], you can also reach
  texlive's maintainer there).

- debian/README.Debian:

  Please check that the information is still correct and needed (and if
  yes, fix the bad wording, it misses a "problems" or similar).

- debian/rules:

  You could switch to using dh_installtex for the fonts, this would also
  make the maintainer scripts simpler, and you'd even no longer need
  10thailatex.cfg in your debian directory.  But this is optional (and
  I'm not the dh_installtex guy among the Debian TeX Task Force, so
  don't ask me for details).

- installation:

  * thai.map should not be in TEXMFSYSCONFIG, see
  
file:///usr/share/doc/tex-common/Debian-TeX-Policy.html/ch4.html#s-configurationfiles
 

  * it would be nice if the documentation, at least the upstream
README. would be available to texdoc.  A symlink
/usr/share/doc/texmf/thailatex/thailatex.txt ->
../../thailatex/README would do.



Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: proper way to package mozilla extensions

[Asheesh Laroia]

On Mon, 24 Apr 2006, Yaroslav Halchenko wrote:


1. There are two possible packaging schemes
 a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it
at build time.

 b. Keep unzipped .xpi in .orig.tar.gz.

 I was going the b. way but now I think that keeping original .xpi
 would be better


I'm no DD, but I would say (a) is nicer because then a checksum can be 
verified more easily.


-- Asheesh.

--
Never drink coke in a moving elevator.  The elevator's motion coupled with
the chemicals in coke produce hallucinations.  People tend to change into
lizards and attack without warning, and large bats usually fly in the
window.  Additionally, you begin to believe that elevators have windows.


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

proper way to package mozilla extensions

[Yaroslav Halchenko]

Hi All,

I am upgrading to the recent upstream one of the extensions I am
maintaining. Finally I made a proper debian/watch file but now I need to
decide which way to go on how to keep .orig.tar.gz. I've investigated a
few packaged extensions and didn't find an answer to my question: how to
perform automatic upgrade (via uscan). The reason is that

1. There are two possible packaging schemes
  a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it
 at build time.

  b. Keep unzipped .xpi in .orig.tar.gz.

  I was going the b. way but now I think that keeping original .xpi
  would be better

2. All packages I've checked were missing debian/watch, so I could not
   see how people perform upgrades. Now I need to either write my own
   wrapper around svn-merge, which would be called by uscan, and it will
   tar.gz the freshiest .xpi into .tar.gz and call svn-upgrade

   But before I do that I thought to ask people on what they think about
   a. vs b.  and debian/watch config to (semi)automatically upgrade to
   the most recent upstream

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




pgpbdrY0iDH34.pgp
Description: PGP signature

RFS: texi2html

[Francesco Cecconi]

Hi all DD,

I'm looking a sponsor for adopt texi2html [1]!

I have another tree packages in Debian!

libemail-find-perl
libconfig-general-perl
libhtml-fromtext-perl

Package Name: texi2html
Short Description: texi2html is a Perl script that converts Texinfo files to 
HTML

Release: 1.76-4

linda & lintian clean!

Sources:

http://mentors.debian.net/debian/pool/main/t/texi2html/


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360947

Many Thanks!

Cheers,
Francesco



signature.asc
Description: This is a digitally signed message part