looking for sponsor for gpmudmon-applet

[Colin Walters]

Hello,

I'm looking for a sponsor for my package of gpmudmon;

[EMAIL PROTECTED]:~$ dpkg -s gpmudmon-applet
Package: gpmudmon-applet
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 152
Maintainer: Colin Walters <[EMAIL PROTECTED]>
Version: 0.1.1-3
Depends: pmud, gdk-imlib1 (>= 1.9.10-3), libart2 (>= 1.2.13-5), libaudiofile0, 
libc6 (>= 2.2.3-1), libcapplet0 (>= 1.4.0.2-3), libdb3 (>= 3.2.9-1), libesd0 
(>= 0.2.22-4) | libesd-alsa0 (>= 0.2.22-4), libglib1.2 (>= 1.2.0), libgnome32 
(>= 1.2.13-5), libgnomesupport0 (>= 1.2.13-5), libgnomeui32 (>= 1.2.13-5), 
libgnorba27 (>= 1.2.13-5), libgtk1.2 (>= 1.2.10-1), liborbit0 (>= 0.5.8), xlibs 
(>> 4.0.3)
Description: GNOME battery applet for PMUD
 gpmudmon is a GNOME applet which displays battery status obtained
 from the PMU daemon (powerpc only).

It is apt-able from:

deb http://www.cis.ohio-state.edu/~walters/debian/sid ./

Thanks!

Re: making a debian package of a php development project

[Colin Walters]

Peter Kruppa <[EMAIL PROTECTED]> writes:

> I'd like to make a debian package of our php-based application, so
> it can be easily installed on a debian system.  But I have a
> problem, it seems that you have to have at least 1 main binary in
> the package (is that true?)

I don't think so.  There are a lot of packages which only install
documentation, for example.

[...]

> Has somebody got a fine link how to make a debian package out of
> some code which doesn't need any compiling and which doesn't produce
> any binary...?  I read the maint-guide, but didn't get mush wiser...

Check out Manoj Srivastava's page:

http://people.debian.org/~srivasta/rules/

> I hope this is the right mailinglist to post this message, if not,
> please inform me about which is the right one.

I believe this is the right list.

Re: packaging HTML, CGIs, etc.

[Colin Walters]

Jimmy Kaplowitz <[EMAIL PROTECTED]> writes:

> There is probably a standard and not-too-difficult way to
> selectively add the Mail-Followup-To: header to such a configurable
> system as any incarnation of Emacs. I wish I could provide a way,
> but I can't.

I mailed this privately to Tollef, but since it might be generally
useful for other Gnusers:

If you've set up your `to-address' group parameter in Gnus for each
mailing list (so 'F' does the right thing), then adding the following
code to one's `gnus-posting-styles' will make it automatically insert
that address as the Mail-Followup-To.

((and (message-mail-p) (stringp gnus-newsgroup-name))
 ("Mail-Followup-To" (gnus-group-get-parameter gnus-newsgroup-name 
'to-address)))

Just as an example, here's my full `gnus-posting-styles':

(setq gnus-posting-styles
  '((".*"
 ("User-Agent" (if (= 0 (random 10))
   (format "Microsoft Gnus Express, Build %s (%s)"
   (gnus-continuum-version (gnus-version))
   gnus-version-number)
 (concat (gnus-extended-version) " (" 
system-configuration ")")))
 (organization "The Ohio State University Dept. of Computer and Info. 
Science"))
((and (message-mail-p) (stringp gnus-newsgroup-name))
 ("Mail-Followup-To" (gnus-group-get-parameter gnus-newsgroup-name 
'to-address)))
((message-news-p)
 (address "[EMAIL PROTECTED]")
 ("Mail-Copies-To" "never"))
("^gnu\\|emacs"
 (organization "Church of Emacs, Missionary Dept."))
("gnu\\.emacs\\.bug"
 ("Mail-Copies-To" nil

Posting styles rock :)

looking for sponsor for gpmudmon-applet

[Colin Walters]

Hello,

I'm looking for a sponsor for my package of gpmudmon;

walters@space-ghost:~$ dpkg -s gpmudmon-applet
Package: gpmudmon-applet
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 152
Maintainer: Colin Walters <[EMAIL PROTECTED]>
Version: 0.1.1-3
Depends: pmud, gdk-imlib1 (>= 1.9.10-3), libart2 (>= 1.2.13-5), libaudiofile0, libc6 
(>= 2.2.3-1), libcapplet0 (>= 1.4.0.2-3), libdb3 (>= 3.2.9-1), libesd0 (>= 0.2.22-4) | 
libesd-alsa0 (>= 0.2.22-4), libglib1.2 (>= 1.2.0), libgnome32 (>= 1.2.13-5), 
libgnomesupport0 (>= 1.2.13-5), libgnomeui32 (>= 1.2.13-5), libgnorba27 (>= 1.2.13-5), 
libgtk1.2 (>= 1.2.10-1), liborbit0 (>= 0.5.8), xlibs (>> 4.0.3)
Description: GNOME battery applet for PMUD
 gpmudmon is a GNOME applet which displays battery status obtained
 from the PMU daemon (powerpc only).

It is apt-able from:

deb http://www.cis.ohio-state.edu/~walters/debian/sid ./

Thanks!


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

Re: making a debian package of a php development project

[Colin Walters]

Peter Kruppa <[EMAIL PROTECTED]> writes:

> I'd like to make a debian package of our php-based application, so
> it can be easily installed on a debian system.  But I have a
> problem, it seems that you have to have at least 1 main binary in
> the package (is that true?)

I don't think so.  There are a lot of packages which only install
documentation, for example.

[...]

> Has somebody got a fine link how to make a debian package out of
> some code which doesn't need any compiling and which doesn't produce
> any binary...?  I read the maint-guide, but didn't get mush wiser...

Check out Manoj Srivastava's page:

http://people.debian.org/~srivasta/rules/

> I hope this is the right mailinglist to post this message, if not,
> please inform me about which is the right one.

I believe this is the right list.


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

Re: packaging HTML, CGIs, etc.

[Colin Walters]

Jimmy Kaplowitz <[EMAIL PROTECTED]> writes:

> There is probably a standard and not-too-difficult way to
> selectively add the Mail-Followup-To: header to such a configurable
> system as any incarnation of Emacs. I wish I could provide a way,
> but I can't.

I mailed this privately to Tollef, but since it might be generally
useful for other Gnusers:

If you've set up your `to-address' group parameter in Gnus for each
mailing list (so 'F' does the right thing), then adding the following
code to one's `gnus-posting-styles' will make it automatically insert
that address as the Mail-Followup-To.

((and (message-mail-p) (stringp gnus-newsgroup-name))
 ("Mail-Followup-To" (gnus-group-get-parameter gnus-newsgroup-name 
'to-address)))

Just as an example, here's my full `gnus-posting-styles':

(setq gnus-posting-styles
  '((".*"
 ("User-Agent" (if (= 0 (random 10))
   (format "Microsoft Gnus Express, Build %s (%s)"
   (gnus-continuum-version (gnus-version))
   gnus-version-number)
 (concat (gnus-extended-version) " (" system-configuration 
")")))
 (organization "The Ohio State University Dept. of Computer and Info. 
Science"))
((and (message-mail-p) (stringp gnus-newsgroup-name))
 ("Mail-Followup-To" (gnus-group-get-parameter gnus-newsgroup-name 
'to-address)))
((message-news-p)
 (address "[EMAIL PROTECTED]")
 ("Mail-Copies-To" "never"))
("^gnu\\|emacs"
 (organization "Church of Emacs, Missionary Dept."))
("gnu\\.emacs\\.bug"
 ("Mail-Copies-To" nil

Posting styles rock :)


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

Re: Help building packages.

[Colin Walters]

William <[EMAIL PROTECTED]> writes:

> The first thing that I did was to use dpkg-deb.  My first question
> is, what are control/changelog files and how would I create one?
> Everytime I try to package something, it tries to locate
> 'debian/control' or 'debian/changelog'.  The only thing that seems
> to alleviate this is 'dpkg-deb -b --nocheck .'

You definitely need a control file and a changelog file.  If you don't
understand their purpose, read through the Policy manual.  You can
"apt-get install debian-policy", or browse it online at:

http://www.debian.org/doc/debian-policy/>

There are a lot of tools for creating, building, and maintaining
Debian packages, and it is very confusing at first (at least it was
for me).  Just spend some time on it, study the policy carefully, look
at other packages (like hello), search the mailing list archives, and
then asking specific questions here would be a good idea.


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

trouble with HTML changelogs and SGML catalogs

[Colin Walters]

I'm currently in the process of making a package for the XML Resume
Library:

http://xmlresume.sourceforge.net>

My current package is at:

http://monk.verbum.org/~walters/debian/experimental>

I have two problems with it.  First, lintian complains:

E: xml-resume-library: changelog-file-not-compressed changelog 13585

The upstream documentation comes as HTML, including the changelog.  Policy
section 13.8 states that the changelog file must be compressed.
However, the changelog is hyperlinked from other parts of the
documentation; renaming it to changelog.html.gz would break those
links.  What should I do?

Secondly (this question is more for SGML gurus), there is no catalog
file in the upstream XML Resume Library; what should I do about this?
I'm not too familiar with SGML (I'm still learning XML too).  Do I
need a catalog file?  As far as I can tell they're just a mapping from
the public identifiers to the location on the actual filesystem.  Is
creating one the upstream author's job?  Or should I create one and
include it in the package?


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

Re: trouble with HTML changelogs and SGML catalogs

[Colin Walters]

Joey Hess <[EMAIL PROTECTED]> writes:

> Convert it to text. Include the html changelog if it makes sense,
> but make changelog.gz be the text version.

Right, I am currently converting it to text and including that.  But
my problem is that policy says specifically that the HTML changelog
should be named 'changelog.html.gz' (and presumably be in the
top-level of the doc directory).  But naming it that would break the
hyperlinks.

Here's how upstream lays out the documentation:

walters@space-ghost> ls -R doc
doc:
authors  changelog  copying  index.html  install  news  todo

doc/authors:
index.html

doc/changelog:
index.html

doc/copying:
index.html

doc/install:
index.html

doc/news:
index.html

doc/todo:
index.html
walters@space-ghost>

And, for example, the toplevel index.html references
changelog/index.html.

Right now I'm just copying all those subdirectories to
/usr/share/doc/xml-resume-library.  So should I do:

cp changelog/index.html changelog.html && gzip -9qf changelog.html

...in addition to having the changelog available as
changelog/index.html?

I guess this is a relatively minor thing, but I don't like seeing
lintian errors every time I debuild :)

Maybe Julian's suggestion of a lintian override is the best in this
situation, since it's just a 'should'.



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

Re: trouble with HTML changelogs and SGML catalogs

[Colin Walters]

Robert Bihlmeyer <[EMAIL PROTECTED]> writes:

> You could try piping the files through
>   sed 's|changelog/index\.html|changelog.html.gz|g'
> while installing...

Eek.  I feared someone was going to suggest that.  It seems like too
much of a hack to me.

> No, that would completely defeat the point of compressing. If you
> don't want to sed, I think symlinking changelog/index.html to
> changelog.html and overriding lintian is ok.

OK, that makes sense.  I'll override lintian; this doesn't seem like a
big deal anyways.  Thanks for the advice!


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

Re: dinstall error message on ftp-master

[Colin Walters]

Salvador Abreu <[EMAIL PROTECTED]> writes:

> 10:41:58$ dinstall -n gprolog_1.2.7-1_i386.changes 
> Traceback (innermost last):
>   File "/org/ftp.debian.org/katie/katie", line 1425, in ?
> main()
>   File "/org/ftp.debian.org/katie/katie", line 1361, in main
> projectB = pg.connect(Cnf["DB::Name"], Cnf["DB::Host"], int(Cnf["DB::Port"]));
> _pg.error: FATAL 1:  user "spa" does not exist

I asked about this same error on IRC (I was trying to run madison).
Brendan O'Dea guessed that the PostgreSQL user database is generated
from the Debian LDAP database, but didn't know how often that
happened.  I've only just got through NM too...



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

Re: Problem with compiling my package

[Colin Walters]

Jean-Michel Kelbert <[EMAIL PROTECTED]> writes:

> Since I make my last dist-upgrade (friday) my package komba2 doesn't
> compile

[...]

> cd . && automake --foreign --include-deps ./Makefile
> ./Makefile.am:5: EXTRA_DIST multiply defined in condition TRUE

This is probably because your package is incompatible with automake
1.5, and you have the automake 1.5 which was in sid for a bit.  It's
recently been downgraded to 1.4.  Just updating to the very latest sid
should fix the problem.


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

Re: How granular should a package{,set} be?

[Colin Walters]

Erich Schubert <[EMAIL PROTECTED]> writes:

> Well, i think the basic principle is "split everything that people
> might want to install independantly or that can be upgraded
> independantly"

Mmmm...I'd rather go for a basic principle of "Use as few packages as
possible, but no fewer".  There's no need to create multiple packages
(which lead to more overhead, more space in the Packages file, another
directory in /usr/share/doc, another place in the BTS to check, etc)
when the majority of people will install them all (or not) anyways.


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

Re: "AOL-level help request": Packaging drivers that require kernel/pcmcia-cs source

[Colin Walters]

Bryan-TheBS-Smith <[EMAIL PROTECTED]> writes:

> As such, this is going to be almost an "AOL-level" help request.
> I'm very sorry for this.  All I'm looking for is a little direction,
> and I'll RTFM the rest.  I've gone through much of the FAQ,
> Developer's Reference and New Maintainer's Guide, and I'm a bit
> "overwhelmed" to say the least.  I've downloaded the "hello" source
> package as well as "alsa-driver," trying to see how things are done
> -- but am confused on the .diff.gz, .desc, orig.tar.gz I get from
> apt-get source blah, versus what the docs say about "control files",
> etc...

It is very confusing at first; there are a *lot* of tools that
interact at different levels.  What I would do is try to figure out
everything you can on your own, and then come back here with more
specific questions.

I'll attempt to briefly explain the .diff.gz, .dsc, and .orig.tar.gz,
because their purpose and time of generation confused the hell out of
me at first.

There are two kinds of packages, "Debian native", and not.  If in
doubt, your package should not be Debian native.  A non-Debian native
package has a .diff.gz which has the changes made to the upstream
package (which is in the .orig.tar.gz).

So, you have you upstream source directory unpacked, in a directory
named "foo-1.0/".  What you'll do is add a debian/ directory which has
"control files" that describe the stuff about the package.  After this
is done, you have a "debianized" source tree.  When you use
dpkg-buildpackage or debuild to build the package, a .diff.gz of your
Debianized source tree versus the upstream source tree will be
generated.  In order to do this, you must have a tarball with the
original source (i.e. not "debianized") in the same directory as your
debianized source, and it must be named
foo_upstreamversion.orig.tar.gz.  Otherwise, dpkg-source will assume
your package is Debian native, which is not what you want.

An important consequence of this is that the Debian diff is
regenerated each time you rerun dpkg-buildpackage or debuild.

As for the .dsc, you can probably just ignore it for now.  It
contains a little metadata about the package, and is also regenerated
by dpkg-buildpackage or debuild. 

Speaking of debuild, I highly recommend it, as it automatically runs
lintian for you.  Lintian is your friend.

Good luck!


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

Re: [installer@ftp-master.debian.org: configwin_0.9-2_i386.changesREJECTED]

[Colin Walters]

On Mon, 2002-01-28 at 08:18, Stefano Zacchiroli wrote:

> So I reupload the package _including .orig.tar.gz_ and I received some
> mails like the following, what I have to do?

This won't directly solve your problem, but I strongly suggest running
dinstall -n on your changes file after you upload.  This will tell you
right away what is (almost certainly) going to happen to your upload,
and you won't have to wait a day only to find it will be rejected. (Note
dput will run dinstall -n for you automatically).


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

Re: how many users is too few

[Colin Walters]

On Mon, 2002-03-11 at 20:50, Corrin Lakeland wrote:

> I had a look on popularity contest and that said it had 7 recent users.  

You have to keep in mind that the popularity-contest is almost certainly
not a representative sample of our users.  So it is likely that more
than 7 people use it.

> I've stopped using it myself, but it is extremely easy to maintain so I don't 
> really mind maintaining it.

It might be worth maintaining; I played it once or twice, but the
computer opponents aren't very good.  What I'd really love to see is a
GTK+/GNOME port of cgoban.


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

Re: New package

[Colin Walters]

On Sun, 2002-03-17 at 11:41, Chris AtLee wrote:
> Hi there,
> 
> I've written a small program that I'd like to package and have included
> in the debian archive.  It's a gnome applet that allows you to set
> alarms and then be notified when those alarms go off.

Have you looked at "sanduhr"?


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

Re: Looking for a sponsor for Ppower4

[Colin Walters]

On Thu, 2002-05-16 at 15:47, Robert Bihlmeyer wrote:

> I didn't know that swing (or basically any GUI) stuff worked with a
> JVM in main.

You can definitely program GUIs using Java and JVMs in main.  See for
example:

http://java-gnome.sourceforge.net/

and

http://gnome-gcj.sourceforge.net/






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

Re: where to place a .xsl file ?

[Colin Walters]

On Fri, 2002-05-24 at 18:55, Eric Gentilini wrote:
> Hi all,
> 
> I m starting to package a few things and wondered where .xsl files should go ?
> These files, in the context I use them, are used to produce different outputs
> used externally to the program. There are also ways to produce this output
> without using the program, since the dtd & xml files are not program specific.

I put the xml-resume-library's .xsl files in
/usr/share/sgml/xml-resume-library/xsl.

Maybe a better place is /usr/share/xml-resume-library/xsl, though.  Any
other opinions?


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

Re: where to place a .xsl file ?

[Colin Walters]

On Fri, 2002-05-24 at 15:41, Stefano Zacchiroli wrote:
> On Fri, May 24, 2002 at 02:06:13PM -0400, Colin Walters wrote:
> > I put the xml-resume-library's .xsl files in
> > /usr/share/sgml/xml-resume-library/xsl.
> > 
> > Maybe a better place is /usr/share/xml-resume-library/xsl, though.  Any
> > other opinions?
> 
> Probably you meant /usr/share/xml/xml-resume-library/xsl. We have no
> policy actually covering this paths (FHS doesn't mention it yet), but if
> you want to be consistent with the /usr/share/sgml path ...

Actually, I didn't realize that /usr/share/xml existed.  I think I'll
use that for the next version of xml-resume-library.  Thanks!



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

Re: w3c-libwww_5.4.0-2 build problems

[Colin Walters]

On Fri, 2002-07-12 at 08:31, Richard Atterer wrote:
> On Sat, Jul 06, 2002 at 11:58:39PM +0200, Richard Atterer wrote:
> > I just uploaded a new version of libwww 5.4.0 to fix #151894 and the
> > build failed on sparc and ia64 with really bizarre symptoms.
> 
> I now found out that the build fails on ReiserFS, but succeeds on
> ext2! What could be causing this?

I remember hearing somewhere that the ext filesystem internally orders
directory entries alphabetically by filename, and readdir() of course
returns them that way, while ReiserFS stores them in some sort of
special order internally, and the readdir() doesn't return sorted
entries.

Perhaps libtool (or some other program) is parsing the output of 'ls' or
something and is implicitly depending on the alphabetical ordering,
instead of piping the output to 'sort'?



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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Mon, 2002-07-15 at 19:40, Ari Pollak wrote:

> The packages can be found at . 
> Suggestions welcome.

Hmm..the .orig.tar.gz seems to be missing.



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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Mon, 2002-07-15 at 21:53, Ari Pollak wrote:
> Ack, woops. It should be up there now.

Ok, I got a chance to look at your package; it looks good to me.  I will
be happy to sponsor you.

I see your GPG key is already signed by a Debian Developer; that's a
good sign.

You should file an ITP bug now, and be sure to close it in the
changelog.  Let me know if you have any questions!


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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Tue, 2002-07-16 at 10:36, Ari Pollak wrote:
> Yeah, I am registered as a New Maintainer, but the process takes a while 
> and I've been on "Waiting for DAM to approve blah blah" for more than a 
> month now. I'm registered under [EMAIL PROTECTED] I've uploaded 
> updated packages which close the ITP bug - I didn't increment the 
> revision, since that would seem pointless.

That's fine.  Actually, the first time I looked at your package, I only
casually glanced through the Debian diff, and it looked ok.  However,
there are a few little things (and one big thing) that I noticed on a
second pass.

The major one is that your Build-Depends: are incorrect; at least
libgtk2.0-dev is missing.  To test this, I highly recommend using
"pbuilder" to build your packages in a clean chroot.  I often forget
about this too, so don't sweat it :)

The other little things are basically the same issues that Bastien
Nocera raised in the thread "metacity-setup .debs" on debian-gtk-gnome;
you have usr/sbin in the .dirs file, but don't actually put any files
there.  Also, I'd remove the commented out dh_foo lines from
debian/rules.

Finally, you are patching config.sub in your Debian diff; that's fine,
but please push upstream to update it, so you don't have to.

Thanks for making this package, it looks pretty neat.  If you can fix
these things I'll get it uploaded right away.


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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Tue, 2002-07-16 at 17:24, Ari Pollak wrote:
> Looking at 
> configure.ac, it really only requires GTK+2 and pspell, so I just added 
> libgtk2.0-dev to the build-depends. 

Hm, but it still appears to need libpspell-dev, which isn't in the
Build-Depends.  If it's left out, my pbuilder build dies with:

/bin/sh ../libtool --mode=compile gcc -DPACKAGE_NAME=\"gtkspell\" 
-DPACKAGE_TARNAME=\"gtkspell\" -DPACKAGE_VERSION=\"2.0.0\" 
-DPACKAGE_STRING=\"gtkspell\ 2.0.0\" -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]\" 
-DPACKAGE=\"gtkspell\" -DVERSION=\"2.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_DLFCN_H=1  -I. -I.-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include 
-I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -g -O2 -c -o 
libgtkspell_la-gtkspell_pspell.lo `test -f gtkspell_pspell.c || echo 
'./'`gtkspell_pspell.c
rm -f .libs/libgtkspell_la-gtkspell_pspell.lo
gcc -DPACKAGE_NAME=\"gtkspell\" -DPACKAGE_TARNAME=\"gtkspell\" 
-DPACKAGE_VERSION=\"2.0.0\" "-DPACKAGE_STRING=\"gtkspell 2.0.0\"" 
-DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]\" -DPACKAGE=\"gtkspell\" 
-DVERSION=\"2.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. 
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -g -O2 -c gtkspell_pspell.c 
-Wp,-MD,.deps/libgtkspell_la-gtkspell_pspell.TPlo  -fPIC -DPIC -o 
.libs/libgtkspell_la-gtkspell_pspell.lo
gtkspell_pspell.c:8: pspell/pspell.h: No such file or directory
make[2]: *** [libgtkspell_la-gtkspell_pspell.lo] Error 1
make[2]: Leaving directory `/tmp/buildd/gtkspell-2.0.0/gtkspell'
make[1]: *** [all-recursive] Error 1

Again, definitely check your packages with pbuilder; otherwise, you'll
just get a serious bug report filed on your package as soon as it's
uploaded, and all the autobuilders barf.

Using pbuilder is really easy: just "aptitude install pbuilder; sudo
pbuilder create; cd /path/to/gtkspell-2.0.0 && pdebuild".  You'll need
to set sudo up, of course.  Oh, and do install aptitude if you haven't
already :)


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

Re: auto-builders, how do they work?

[Colin Walters]

On Wed, 2002-07-17 at 09:58, Rick Younie wrote:

> conserver is non-free so the autobuild system doesn't know
> about it.  I'm not sure all autobuild admins bother with
> non-free, for philosophical reasons, so you should look into
> building it yourself on each arch yourself if you can.
> http://db.debian.org/machines.cgi for accessible machines.

>From what I understand, the autobuilder machines don't bother with
non-free for quite practical reasons; mostly the lack of autobuilder
maintainer manpower to check each license.  It may be outright illegal
to recompile some of them at all.  Or some of them might require that a
message be sent to the author whenever a binary is made.  Or any of
millions of other possible onerous restrictions.

Basically, non-free software just sucks.

I'm sure one of the autobuilder maintainers could explain more.


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

Re: need sponsor for vegastrike upload

[Colin Walters]

On Tue, 2002-07-23 at 13:11, Michael Furr wrote:
> err, guess a link to the packages would help:
> 
> deb http://userpages.umbc.edu/~fu1/debian unstable main
> deb-src http://userpages.umbc.edu/~fu1/debian unstable main

I took a quick look at your packages; the first thing I noticed is that
your diff is a bit big:

walters@space-ghost> diffstat ../vegastrike_0.2.9.2-4.diff.gz   
/tmp/vegastrike/vegastrike-0.2.9
[...]
 mission/.deps/button.Po |  117 ++
 mission/.deps/easydom.Po|  159 
 mission/.deps/file.Po   |  204 +++
 mission/.deps/general.Po|  131 +++
 mission/.deps/glut_support.Po   |  115 ++
 mission/.deps/graphics.Po   |  208 +++
 mission/.deps/hashtable.Po  |  123 ++
 mission/.deps/select.Po |  208 +++
 mission/.deps/selector.Po   |  208 +++
 mission/.deps/text_area.Po  |  208 +++
 mission/.deps/xml_support.Po|  141 +++

Is it really necessary to create these files?  I bet they're just cruft
that 'make clean' didn't remove.

 mission/Makefile|  358 +++

Since the Makefile is generated from Makefile.in by configure, you
shouldn't patch it in your diff.

[...]
 objconv/Makefile|  226 
 saveinterface/Makefile  |   26 +
[...]
 vssetup/src/Makefile|   29 +

Not sure about these.

Other than that, your package looks good.  I'd prefer it if you had your
key signed by a Debian developer before I sponsor you.  Could you try to
do that first?  At least the key:

pub  1024D/B056CC96 2002-04-12 Michael E. Furr <[EMAIL PROTECTED]>

that I got from pgp.mit.edu was not signed.


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

Re: developer vs user wants

[Colin Walters]

On Sun, 2002-07-28 at 09:37, Andrew Suffield wrote:

> If the developers of limewire want to force people to view the ads,
> they must write this into the license (and we punt it to non-free),
> otherwise it is completely futile to try and make people do so.

Less confrontationally, you might point out to upstream that there are
other ways of making money from free software (like paypal donations).


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

Re: apt configuration

[Colin Walters]

On Wed, 2002-08-21 at 00:18, Ian Zimmerman wrote:
> 
> I am trying to make apt always run debsums_gen on the just-installed
> packages.  

You may want to try my dpkg patch in bug #155676; it will at least be
faster.  I hope it will be in dpkg proper soon.


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

Re: inclusion of a debian dir in upstream src

[Colin Walters]

On Tue, 2002-09-24 at 19:34, Sam Powers wrote:
> Is it a good idea to keep a debian directory upstream? I have CVS access,
> so I think it'd make it easier for me, and also for others who want to
> build custom debs, if the debian files were in CVS.

I think the best solution is to keep it in CVS, but exclude it from
released tarballs.  That way you keep the upstream/Debian distinction,
but all the source code is in one place.


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

Re: stripping binaries...must we?

[Colin Walters]

On Sat, 2002-10-12 at 23:19, Drew Parsons wrote:

> Why does policy ask us to strip binaries anyway?  Is it merely to reduce
> storage and bandwidth costs?

Right.  I think there will be a point in the future (probably 2-3 years
away at least though) though where we can just default to shipping
unstripped binaries, and have the user strip them on installation if
they want.

But to answer your specific question, I don't see it as a big deal if
you ship unstripped binaries in a package in unstable for a while.  I
think the important part is providing stripped binaries for sarge; so
just be sure to upload a stripped package before sarge releases.


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

Re: Help building packages.

[Colin Walters]

William <[EMAIL PROTECTED]> writes:

> The first thing that I did was to use dpkg-deb.  My first question
> is, what are control/changelog files and how would I create one?
> Everytime I try to package something, it tries to locate
> 'debian/control' or 'debian/changelog'.  The only thing that seems
> to alleviate this is 'dpkg-deb -b --nocheck .'

You definitely need a control file and a changelog file.  If you don't
understand their purpose, read through the Policy manual.  You can
"apt-get install debian-policy", or browse it online at:

http://www.debian.org/doc/debian-policy/>

There are a lot of tools for creating, building, and maintaining
Debian packages, and it is very confusing at first (at least it was
for me).  Just spend some time on it, study the policy carefully, look
at other packages (like hello), search the mailing list archives, and
then asking specific questions here would be a good idea.

trouble with HTML changelogs and SGML catalogs

[Colin Walters]

I'm currently in the process of making a package for the XML Resume
Library:

http://xmlresume.sourceforge.net>

My current package is at:

http://monk.verbum.org/~walters/debian/experimental>

I have two problems with it.  First, lintian complains:

E: xml-resume-library: changelog-file-not-compressed changelog 13585

The upstream documentation comes as HTML, including the changelog.  Policy
section 13.8 states that the changelog file must be compressed.
However, the changelog is hyperlinked from other parts of the
documentation; renaming it to changelog.html.gz would break those
links.  What should I do?

Secondly (this question is more for SGML gurus), there is no catalog
file in the upstream XML Resume Library; what should I do about this?
I'm not too familiar with SGML (I'm still learning XML too).  Do I
need a catalog file?  As far as I can tell they're just a mapping from
the public identifiers to the location on the actual filesystem.  Is
creating one the upstream author's job?  Or should I create one and
include it in the package?

Re: trouble with HTML changelogs and SGML catalogs

[Colin Walters]

Joey Hess <[EMAIL PROTECTED]> writes:

> Convert it to text. Include the html changelog if it makes sense,
> but make changelog.gz be the text version.

Right, I am currently converting it to text and including that.  But
my problem is that policy says specifically that the HTML changelog
should be named 'changelog.html.gz' (and presumably be in the
top-level of the doc directory).  But naming it that would break the
hyperlinks.

Here's how upstream lays out the documentation:

[EMAIL PROTECTED]> ls -R doc
doc:
authors  changelog  copying  index.html  install  news  todo

doc/authors:
index.html

doc/changelog:
index.html

doc/copying:
index.html

doc/install:
index.html

doc/news:
index.html

doc/todo:
index.html
[EMAIL PROTECTED]>

And, for example, the toplevel index.html references
changelog/index.html.

Right now I'm just copying all those subdirectories to
/usr/share/doc/xml-resume-library.  So should I do:

cp changelog/index.html changelog.html && gzip -9qf changelog.html

...in addition to having the changelog available as
changelog/index.html?

I guess this is a relatively minor thing, but I don't like seeing
lintian errors every time I debuild :)

Maybe Julian's suggestion of a lintian override is the best in this
situation, since it's just a 'should'.

Re: trouble with HTML changelogs and SGML catalogs

[Colin Walters]

Robert Bihlmeyer <[EMAIL PROTECTED]> writes:

> You could try piping the files through
>   sed 's|changelog/index\.html|changelog.html.gz|g'
> while installing...

Eek.  I feared someone was going to suggest that.  It seems like too
much of a hack to me.

> No, that would completely defeat the point of compressing. If you
> don't want to sed, I think symlinking changelog/index.html to
> changelog.html and overriding lintian is ok.

OK, that makes sense.  I'll override lintian; this doesn't seem like a
big deal anyways.  Thanks for the advice!

Re: dinstall error message on ftp-master

[Colin Walters]

Salvador Abreu <[EMAIL PROTECTED]> writes:

> 10:41:58$ dinstall -n gprolog_1.2.7-1_i386.changes 
> Traceback (innermost last):
>   File "/org/ftp.debian.org/katie/katie", line 1425, in ?
> main()
>   File "/org/ftp.debian.org/katie/katie", line 1361, in main
> projectB = pg.connect(Cnf["DB::Name"], Cnf["DB::Host"], 
> int(Cnf["DB::Port"]));
> _pg.error: FATAL 1:  user "spa" does not exist

I asked about this same error on IRC (I was trying to run madison).
Brendan O'Dea guessed that the PostgreSQL user database is generated
from the Debian LDAP database, but didn't know how often that
happened.  I've only just got through NM too...

Re: How granular should a package{,set} be?

[Colin Walters]

Erich Schubert <[EMAIL PROTECTED]> writes:

> Well, i think the basic principle is "split everything that people
> might want to install independantly or that can be upgraded
> independantly"

Mmmm...I'd rather go for a basic principle of "Use as few packages as
possible, but no fewer".  There's no need to create multiple packages
(which lead to more overhead, more space in the Packages file, another
directory in /usr/share/doc, another place in the BTS to check, etc)
when the majority of people will install them all (or not) anyways.

Re: Problem with compiling my package

[Colin Walters]

Jean-Michel Kelbert <[EMAIL PROTECTED]> writes:

> Since I make my last dist-upgrade (friday) my package komba2 doesn't
> compile

[...]

> cd . && automake --foreign --include-deps ./Makefile
> ./Makefile.am:5: EXTRA_DIST multiply defined in condition TRUE

This is probably because your package is incompatible with automake
1.5, and you have the automake 1.5 which was in sid for a bit.  It's
recently been downgraded to 1.4.  Just updating to the very latest sid
should fix the problem.

Re: apt-howto's package

[Colin Walters]

Gustavo Noronha Silva <[EMAIL PROTECTED]> writes:

> I am the author and packager of apt-howto, as soon as it was
> translated into english from portuguese, I packaged it and added it
> to the DDP, I was adviced, on the -devel list to just create one
> package: apt-howto with all the translations of the manual, but I am
> now receiving more translations and I think it will be a waste of
> space for the one who installs it...

Rather than creating many packages, I think what we really need to do
is implement support in dpkg for translations.  For example, I'd like
to say "Don't install any translations except English" on my personal
systems.  Then when I "apt-get install apt-howto", those extra files
won't be installed.

Even more generally, I'd like to be able to say "Don't install any
documentation at all", or "Don't install man pages"...  This was
discussed a while ago, but I can't seem to find it in the archives.

> I want to create apt-howto-$lang packages and probably one apt-howto
> meta-package that'll depend on all of them, as I don't like to be
> english-centric, and will not be satisfied installing apt-howto-en
> when asked for apt-howto, my target is the world, and not the
> enlighs-readers, what do you think?

If you're still at two or three translations, I think it would be
overkill to split the package.

If you really want to save bandwidth for people, implementing the
automatic translation idea in doc-base would be much better :)

Re: "AOL-level help request": Packaging drivers that require kernel/pcmcia-cs source

[Colin Walters]

Bryan-TheBS-Smith <[EMAIL PROTECTED]> writes:

> As such, this is going to be almost an "AOL-level" help request.
> I'm very sorry for this.  All I'm looking for is a little direction,
> and I'll RTFM the rest.  I've gone through much of the FAQ,
> Developer's Reference and New Maintainer's Guide, and I'm a bit
> "overwhelmed" to say the least.  I've downloaded the "hello" source
> package as well as "alsa-driver," trying to see how things are done
> -- but am confused on the .diff.gz, .desc, orig.tar.gz I get from
> apt-get source blah, versus what the docs say about "control files",
> etc...

It is very confusing at first; there are a *lot* of tools that
interact at different levels.  What I would do is try to figure out
everything you can on your own, and then come back here with more
specific questions.

I'll attempt to briefly explain the .diff.gz, .dsc, and .orig.tar.gz,
because their purpose and time of generation confused the hell out of
me at first.

There are two kinds of packages, "Debian native", and not.  If in
doubt, your package should not be Debian native.  A non-Debian native
package has a .diff.gz which has the changes made to the upstream
package (which is in the .orig.tar.gz).

So, you have you upstream source directory unpacked, in a directory
named "foo-1.0/".  What you'll do is add a debian/ directory which has
"control files" that describe the stuff about the package.  After this
is done, you have a "debianized" source tree.  When you use
dpkg-buildpackage or debuild to build the package, a .diff.gz of your
Debianized source tree versus the upstream source tree will be
generated.  In order to do this, you must have a tarball with the
original source (i.e. not "debianized") in the same directory as your
debianized source, and it must be named
foo_upstreamversion.orig.tar.gz.  Otherwise, dpkg-source will assume
your package is Debian native, which is not what you want.

An important consequence of this is that the Debian diff is
regenerated each time you rerun dpkg-buildpackage or debuild.

As for the .dsc, you can probably just ignore it for now.  It
contains a little metadata about the package, and is also regenerated
by dpkg-buildpackage or debuild. 

Speaking of debuild, I highly recommend it, as it automatically runs
lintian for you.  Lintian is your friend.

Good luck!

Re: [installer@ftp-master.debian.org: configwin_0.9-2_i386.changes REJECTED]

[Colin Walters]

On Mon, 2002-01-28 at 08:18, Stefano Zacchiroli wrote:

> So I reupload the package _including .orig.tar.gz_ and I received some
> mails like the following, what I have to do?

This won't directly solve your problem, but I strongly suggest running
dinstall -n on your changes file after you upload.  This will tell you
right away what is (almost certainly) going to happen to your upload,
and you won't have to wait a day only to find it will be rejected. (Note
dput will run dinstall -n for you automatically).

Re: how many users is too few

[Colin Walters]

On Mon, 2002-03-11 at 20:50, Corrin Lakeland wrote:

> I had a look on popularity contest and that said it had 7 recent users.  

You have to keep in mind that the popularity-contest is almost certainly
not a representative sample of our users.  So it is likely that more
than 7 people use it.

> I've stopped using it myself, but it is extremely easy to maintain so I don't 
> really mind maintaining it.

It might be worth maintaining; I played it once or twice, but the
computer opponents aren't very good.  What I'd really love to see is a
GTK+/GNOME port of cgoban.

Re: New package

[Colin Walters]

On Sun, 2002-03-17 at 11:41, Chris AtLee wrote:
> Hi there,
> 
> I've written a small program that I'd like to package and have included
> in the debian archive.  It's a gnome applet that allows you to set
> alarms and then be notified when those alarms go off.

Have you looked at "sanduhr"?

Re: w3c-libwww_5.4.0-2 build problems

[Colin Walters]

On Fri, 2002-07-12 at 08:31, Richard Atterer wrote:
> On Sat, Jul 06, 2002 at 11:58:39PM +0200, Richard Atterer wrote:
> > I just uploaded a new version of libwww 5.4.0 to fix #151894 and the
> > build failed on sparc and ia64 with really bizarre symptoms.
> 
> I now found out that the build fails on ReiserFS, but succeeds on
> ext2! What could be causing this?

I remember hearing somewhere that the ext filesystem internally orders
directory entries alphabetically by filename, and readdir() of course
returns them that way, while ReiserFS stores them in some sort of
special order internally, and the readdir() doesn't return sorted
entries.

Perhaps libtool (or some other program) is parsing the output of 'ls' or
something and is implicitly depending on the alphabetical ordering,
instead of piping the output to 'sort'?



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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Mon, 2002-07-15 at 19:40, Ari Pollak wrote:

> The packages can be found at . 
> Suggestions welcome.

Hmm..the .orig.tar.gz seems to be missing.



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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Mon, 2002-07-15 at 21:53, Ari Pollak wrote:
> Ack, woops. It should be up there now.

Ok, I got a chance to look at your package; it looks good to me.  I will
be happy to sponsor you.

I see your GPG key is already signed by a Debian Developer; that's a
good sign.

You should file an ITP bug now, and be sure to close it in the
changelog.  Let me know if you have any questions!


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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Tue, 2002-07-16 at 10:36, Ari Pollak wrote:
> Yeah, I am registered as a New Maintainer, but the process takes a while 
> and I've been on "Waiting for DAM to approve blah blah" for more than a 
> month now. I'm registered under [EMAIL PROTECTED] I've uploaded 
> updated packages which close the ITP bug - I didn't increment the 
> revision, since that would seem pointless.

That's fine.  Actually, the first time I looked at your package, I only
casually glanced through the Debian diff, and it looked ok.  However,
there are a few little things (and one big thing) that I noticed on a
second pass.

The major one is that your Build-Depends: are incorrect; at least
libgtk2.0-dev is missing.  To test this, I highly recommend using
"pbuilder" to build your packages in a clean chroot.  I often forget
about this too, so don't sweat it :)

The other little things are basically the same issues that Bastien
Nocera raised in the thread "metacity-setup .debs" on debian-gtk-gnome;
you have usr/sbin in the .dirs file, but don't actually put any files
there.  Also, I'd remove the commented out dh_foo lines from
debian/rules.

Finally, you are patching config.sub in your Debian diff; that's fine,
but please push upstream to update it, so you don't have to.

Thanks for making this package, it looks pretty neat.  If you can fix
these things I'll get it uploaded right away.


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

Re: request for sponsor: GtkSpell

[Colin Walters]

On Tue, 2002-07-16 at 17:24, Ari Pollak wrote:
> Looking at 
> configure.ac, it really only requires GTK+2 and pspell, so I just added 
> libgtk2.0-dev to the build-depends. 

Hm, but it still appears to need libpspell-dev, which isn't in the
Build-Depends.  If it's left out, my pbuilder build dies with:

/bin/sh ../libtool --mode=compile gcc -DPACKAGE_NAME=\"gtkspell\" 
-DPACKAGE_TARNAME=\"gtkspell\" -DPACKAGE_VERSION=\"2.0.0\" 
-DPACKAGE_STRING=\"gtkspell\ 2.0.0\" -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" 
-DPACKAGE=\"gtkspell\" -DVERSION=\"2.0.0\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1  -I. -I.-I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 
-I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   
-g -O2 -c -o libgtkspell_la-gtkspell_pspell.lo `test -f gtkspell_pspell.c || 
echo './'`gtkspell_pspell.c
rm -f .libs/libgtkspell_la-gtkspell_pspell.lo
gcc -DPACKAGE_NAME=\"gtkspell\" -DPACKAGE_TARNAME=\"gtkspell\" 
-DPACKAGE_VERSION=\"2.0.0\" "-DPACKAGE_STRING=\"gtkspell 2.0.0\"" 
-DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DPACKAGE=\"gtkspell\" 
-DVERSION=\"2.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. 
-I. -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -g -O2 -c gtkspell_pspell.c 
-Wp,-MD,.deps/libgtkspell_la-gtkspell_pspell.TPlo  -fPIC -DPIC -o 
.libs/libgtkspell_la-gtkspell_pspell.lo
gtkspell_pspell.c:8: pspell/pspell.h: No such file or directory
make[2]: *** [libgtkspell_la-gtkspell_pspell.lo] Error 1
make[2]: Leaving directory `/tmp/buildd/gtkspell-2.0.0/gtkspell'
make[1]: *** [all-recursive] Error 1

Again, definitely check your packages with pbuilder; otherwise, you'll
just get a serious bug report filed on your package as soon as it's
uploaded, and all the autobuilders barf.

Using pbuilder is really easy: just "aptitude install pbuilder; sudo
pbuilder create; cd /path/to/gtkspell-2.0.0 && pdebuild".  You'll need
to set sudo up, of course.  Oh, and do install aptitude if you haven't
already :)


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

Re: auto-builders, how do they work?

[Colin Walters]

On Wed, 2002-07-17 at 09:58, Rick Younie wrote:

> conserver is non-free so the autobuild system doesn't know
> about it.  I'm not sure all autobuild admins bother with
> non-free, for philosophical reasons, so you should look into
> building it yourself on each arch yourself if you can.
> http://db.debian.org/machines.cgi for accessible machines.

>From what I understand, the autobuilder machines don't bother with
non-free for quite practical reasons; mostly the lack of autobuilder
maintainer manpower to check each license.  It may be outright illegal
to recompile some of them at all.  Or some of them might require that a
message be sent to the author whenever a binary is made.  Or any of
millions of other possible onerous restrictions.

Basically, non-free software just sucks.

I'm sure one of the autobuilder maintainers could explain more.


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

Re: need sponsor for vegastrike upload

[Colin Walters]

On Tue, 2002-07-23 at 13:11, Michael Furr wrote:
> err, guess a link to the packages would help:
> 
> deb http://userpages.umbc.edu/~fu1/debian unstable main
> deb-src http://userpages.umbc.edu/~fu1/debian unstable main

I took a quick look at your packages; the first thing I noticed is that
your diff is a bit big:

[EMAIL PROTECTED]> diffstat ../vegastrike_0.2.9.2-4.diff.gz   
/tmp/vegastrike/vegastrike-0.2.9
[...]
 mission/.deps/button.Po |  117 ++
 mission/.deps/easydom.Po|  159 
 mission/.deps/file.Po   |  204 +++
 mission/.deps/general.Po|  131 +++
 mission/.deps/glut_support.Po   |  115 ++
 mission/.deps/graphics.Po   |  208 +++
 mission/.deps/hashtable.Po  |  123 ++
 mission/.deps/select.Po |  208 +++
 mission/.deps/selector.Po   |  208 +++
 mission/.deps/text_area.Po  |  208 +++
 mission/.deps/xml_support.Po|  141 +++

Is it really necessary to create these files?  I bet they're just cruft
that 'make clean' didn't remove.

 mission/Makefile|  358 +++

Since the Makefile is generated from Makefile.in by configure, you
shouldn't patch it in your diff.

[...]
 objconv/Makefile|  226 
 saveinterface/Makefile  |   26 +
[...]
 vssetup/src/Makefile|   29 +

Not sure about these.

Other than that, your package looks good.  I'd prefer it if you had your
key signed by a Debian developer before I sponsor you.  Could you try to
do that first?  At least the key:

pub  1024D/B056CC96 2002-04-12 Michael E. Furr <[EMAIL PROTECTED]>

that I got from pgp.mit.edu was not signed.


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

Re: developer vs user wants

[Colin Walters]

On Sun, 2002-07-28 at 09:37, Andrew Suffield wrote:

> If the developers of limewire want to force people to view the ads,
> they must write this into the license (and we punt it to non-free),
> otherwise it is completely futile to try and make people do so.

Less confrontationally, you might point out to upstream that there are
other ways of making money from free software (like paypal donations).


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

Re: libxmlsec

[Colin Walters]

On Wed, 2002-08-07 at 12:07, John Belmonte wrote:

> I've packaged libxmlsec (bug #152605), a library for performing
> signature and encryption operations on XML [...]

Cool.

> and am looking for a sponsor.

I am looking over your packages now.

> The required version of libxslt1 wasn't available (bug #154730), so I've
> also prepared a libxslt NMU.

Hm, the last maintainer upload was almost a year ago.  Could you try
contacting the maintainer directly and ask if he would mind if you did a
NMU?

> I haven't had luck in getting my key signed by a developer yet (I'm in
> Tokyo).

I much prefer to sponsor people who have at least had their key signed
by a developer.  Have you seen the keysigning coordination page?

http://nm.debian.org/gpg_offer.php

I just looked there, and saw this listing under Japan:

* Fumitoshi UKAI <[EMAIL PROTECTED]>
o Tokyo, Japan: always

Re: libxmlsec

[Colin Walters]

On Wed, 2002-08-07 at 21:33, Indra Kusuma wrote:
> On 7 Aug 2002, Colin Walters wrote:
> 
> # I much prefer to sponsor people who have at least had their key signed
> # by a developer.  Have you seen the keysigning coordination page?
> #
> # http://nm.debian.org/gpg_offer.php
> 
> what about my country .ID ?
> is it okey if im just send driving license and sign it with my gpg key ?

If you're asking about what qualifies for application to the NM process,
I don't know the answer to that.  You'll have to ask the NM team.

Re: libxmlsec

[Colin Walters]

On Wed, 2002-08-07 at 21:01, John Belmonte wrote:

> Thanks, I appreciate it.

I didn't find any problems in your packages; they look good.

> OK, I've sent an email off to the maintainer.

I think a week or so should be fair.

> That's understandable.  About three weeks ago I tried to contact the
> person on the keysigning offers page, but got no reply.  It's odd to
> have your name on the offers list, yet be too busy to reply to an email.
> ~ I have my name on the "looking for" page.

Hm.  Well, maybe you could try again...according to our developer
tracker he was last seen on -devel-changes on Aug 5, so maybe he just
missed your mail for some reason.

How do you plan to get your key signed for applying to the project?

Incidentally (and this is more a question for upstream, but maybe you
know), how hard would it be to make this library work with GNUTLS?  See,
I might want to use it with a GPL'd application, and of course since
libxmlsec links with OpenSSL this won't work.

Re: apt configuration

[Colin Walters]

On Wed, 2002-08-21 at 00:18, Ian Zimmerman wrote:
> 
> I am trying to make apt always run debsums_gen on the just-installed
> packages.  

You may want to try my dpkg patch in bug #155676; it will at least be
faster.  I hope it will be in dpkg proper soon.

Re: inclusion of a debian dir in upstream src

[Colin Walters]

On Tue, 2002-09-24 at 19:34, Sam Powers wrote:
> Is it a good idea to keep a debian directory upstream? I have CVS access,
> so I think it'd make it easier for me, and also for others who want to
> build custom debs, if the debian files were in CVS.

I think the best solution is to keep it in CVS, but exclude it from
released tarballs.  That way you keep the upstream/Debian distinction,
but all the source code is in one place.

Re: stripping binaries...must we?

[Colin Walters]

On Sat, 2002-10-12 at 23:19, Drew Parsons wrote:

> Why does policy ask us to strip binaries anyway?  Is it merely to reduce
> storage and bandwidth costs?

Right.  I think there will be a point in the future (probably 2-3 years
away at least though) though where we can just default to shipping
unstripped binaries, and have the user strip them on installation if
they want.

But to answer your specific question, I don't see it as a big deal if
you ship unstripped binaries in a package in unstable for a while.  I
think the important part is providing stripped binaries for sarge; so
just be sure to upload a stripped package before sarge releases.

Re: Converting dpkg-conffile in postinst

[Colin Walters]

On Sun, 2002-10-20 at 02:09, Marc Haber wrote:

> Can anybody name me a package that does a conffile conversion in the
> maintainer scripts, and does a decent job? I desparately need to steal
> some code ;)

I believe netbase does.