Re: What does dpkg-source mean with this?

[Paul Cupis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 13 November 2002 06:58, Karolina Lindqvist wrote:
> tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> > It looks like all the files are pre-existing.  Try running dpkg-source
> > -b from another directory or renaming the noteedit-2.0.16 directory?
>
> That might be the problem, so please bear me with some questions so that I
> get this very clear to me:
>
> When you take a tar file from somewhere and make a debian package of it,
> should it be unchanged from upstream or can it be modified?

It can be modified. It should be unchanged. Being unchanged has beneifts 
including but not limited to allowing users to verify the original tgz with 
upstream and clearly showing (in the diff.gz) what changes were made during 
packaging. If these changes can be sent upstream for inclusion in a later 
release of the software, geat.

> For example, should (in this case) noteedit_2.0.16.orig.tar.gz extract to
> noteedit, noteedit-2.0.16 or noteedit-2.0.16.orig? Does it matter?

It doesn't matter. dpkg-source will extract the tgz to a correctly named 
directory.

> Can the source tar file be called noteedit-2.0.16.tar or should it be
> renamed to noteedit_2.0.16.orig.tar

It should be called noteedit_2.0.16.orig.tar.gz, per the packaging manual.

> If there is an old debian directory in the upstreams tar file, for some old
> debian version. Should that be removed?

I would be inclined to leave it in the orig.tar.gz, but either patch it or 
remove in the build process (in the clean target?). I'm don't have the 
details of how to best do this handy, but iirc, this is the recommended 
solution.

> If there are bin-files or *.o files or similar in the upstreams tar file.
> Should they be removed?

Not by you? Bug upstream about it, i think. Again, this is related to having a 
pristine upstream orig.tar.gz if possible (but this is not essential).

> In KDE applications, normally a "make -f Makefile.cvs" (or similar) is done
> before the upstreams tar file is packed. But often that is done with
> another version of automake than debian is using. Often an old automake1.4
> or something. If some changes are needed to the *.am files, that will
> create problems due to automake incompatibilites. If no changes to the *.am
> files is needed, it might work even with incompatible versions, since
> automake is never called, but it might create trouble if something is
> changed.
>
> One solution is to make a "make -f Makefile.cvs" before building it on
> debian, but then the diffs with all the Makefile.in files etc. will become
> huge. Can that be done before packing the *.orig.tar file, to avoid
> rebuilding problems and making the diffs small?

I'll leave the rest for someone else, unless I get more time later. :)

Paul Cupis
- -- 
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE90jUOIzuKV+SHX/kRArphAJ9nnYHG1Dy6/gEvrOs0womIcTrmvwCeLct/
W4YmXm7BrhEXBj7ZSQLdAYw=
=qZwO
-END PGP SIGNATURE-


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

Re: What does dpkg-source mean with this?

[Sven Luther]

On Wed, Nov 13, 2002 at 11:18:20AM +, Paul Cupis wrote:
> > If there is an old debian directory in the upstreams tar file, for some old
> > debian version. Should that be removed?
> 
> I would be inclined to leave it in the orig.tar.gz, but either patch it or 
> remove in the build process (in the clean target?). I'm don't have the 
> details of how to best do this handy, but iirc, this is the recommended 
> solution.

Just leave it.

You erase it, modify it or do whatever you need to bring it to par with
the your current need, and let dpkg-buildpackage generate the .diff that
will patch the upstream provided directory to the current one.

If you want, you can even send the diff upstream so they have an
uptodate debian directory.

> > If there are bin-files or *.o files or similar in the upstreams tar file.
> > Should they be removed?
> 
> Not by you? Bug upstream about it, i think. Again, this is related to having a 
> pristine upstream orig.tar.gz if possible (but this is not essential).

It would depend on what the .o are. If they are cruft left there by a an
incomplete clean target, patch the makefile so they get removed and send
a bug report with it upstream. If they have legitimate reason for being
there, then it is another question, which will depend on the reason for
it being there.

You will face problems with the clean target and multiple running of
dpkg-buildpackage if they are present, get changed or are removed by
clean though.

I have such a case in one of my packages, and i move them around during
the build and restore them when cleaning.

Friendly,

Sven Luther


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

Request for Sponsor: kdirstat - Graphical disk usage display

[Mike Schacht]

Package location: 
www.midstatesd.net/~mschacht/debian/kdirstat_2.0.1*

Be sure to get this version, 2.0.1. The 2.2.0 version depends on some
kde3 libs that have still not made it into unstable.

>From the .deb description:

 KDirStat (KDE Directory Statistics) is a small utility program that
 sums up disk usage for direcory trees, very much like the Unix 'du'
 command.  It displays the disk space used up by a directory tree, both
 numerically and graphically. It is network transparent (i.e., you can
 use it to sum up FTP servers), and comes with predefined and user
 configurable cleanup actions. You can directly open a directory branch
 in Konqueror or the shell of your choice, compress it to a .tar.bz2
 archive, or define your own cleanup actions.

Upstream
Author: Stefan Hundhammer <[EMAIL PROTECTED]>
Site:   kdirstat.sourceforge.net
 
This should be a fairly easy package to check. It compiled right out of
the box and its operation is straight-forward. The upstream code required
only one small modification in a makefile to fix some little policy
offense.


Thanks,

Mike Schacht
[EMAIL PROTECTED]


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

Re: Replacing a single file with Replaces:

[Matt Zimmerman]

On Tue, Nov 12, 2002 at 08:32:53PM -0500, Duncan Findlay wrote:

> Try using Conflicts: instead of (or in addition to) Replaces:

That means something entirely different.

-- 
 - mdz


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

RE: What to do with wrong files from upstreams

[wturkal]

>= Original Message From Karolina Lindqvist <[EMAIL PROTECTED]> 
=
>tisdagen den 12 november 2002 22.25 skrev Warren Turkal:
>
>> File a bug with the KDE people. Maybe look at the automake stuff and figure
>> out why it doesn't delete them.
>> What kde package is this in?
>
>It is not in main KDE, but in an application knetfilter, that I picked up and
>thought could be handy to have. Yes, I can contact the author and point it
>out. I was wondering in general what to do in such a situation, how to
>produce a debian package without waiting for upstreams to fix it (which can
>take a long time for the next release).
The easiest thing I can think of is to make the clean of debian/rules delete 
all moc files from the build tree. This keeps the changes out of the source. I 
think that the right solution is to look and see if you can provide a patch to 
the upstream source, though.

Warren

-- 
Treasurer, GOLUM, Inc.
Group of Linux Users in Memphis
http://www.golum.org


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

Looking for sponsor for: libapache-mod-sqlinclude, hd-dma

[Marcin Orlowski]

Hi,

I've packaged mod_sqlinclude 
and small script hd-dma. Both can be found packaged at
http://wfmh.org.pl/~carlos/debian/

These are my first packages so I am open for all the 
improvement sugestions. And I'm looking for sponsor
and uploader of course ;)

Regards,
-- 
 And he said: "God CTRL-S the Queen"...

 Marcin  http://wfmh.org.pl/~carlos/
 mailto:[EMAIL PROTECTED]



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

ogmtools

[Marc Leeman]

A second call for a sponsor for the package ogmtools.

The package enables e.g. encoding media files (xvid, ...) with an ogg
audio stream instead of mp3 encoded audio.

The tools are used in transcode (excellent video transcoding tool
(maintained by Christian Marillat).


Upstream: http://www.bunkus.org/videotools/
Debian pre: http://www.esat.kuleuven.ac.be/~mleeman/simple/debian.html

-- 
greetz, marc
 
My pony-tail hit the on/off switch on the power strip.
 Key fingerprint = 890C E47F 1589 F240 9CC8  C60C 510A 63D3 D356 2DE1
Linux mykene 2.4.19-xfs #1 Mon Aug 26 14:55:46 CEST 2002 i686 unknown unknown GNU/Linux



msg07845/pgp0.pgp
Description: PGP signature

Looking for sponsor: ada-reference-manual

[Florian Weimer]

I'm looking for a sponsor for the ada-reference-manual package.

* Package name: ada-reference-manual
  Version : 1.0
  Upstream Author : ISO/IEC JTC1/SC22/WG9, Ada Rapporteur Group
* URL : http://www.ada-auth.org/arm.html
* License : custom, but DFSG-conforming
  Description : The standard describing the Ada 95 language.

This package contains various versions of the Ada Reference Manual, the
standard describing the programming language Ada.  HTML, text and
Texinfo formats are provided.

A preliminary package can be found here (careful, slow link):

  


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

Re: Request for Sponsor: kdirstat - Graphical disk usage display

[Brian Nelson]

Mike Schacht <[EMAIL PROTECTED]> writes:

> Package location: 
>   www.midstatesd.net/~mschacht/debian/kdirstat_2.0.1*
>
> Be sure to get this version, 2.0.1. The 2.2.0 version depends on some
> kde3 libs that have still not made it into unstable.
>
> From the .deb description:
>
>  KDirStat (KDE Directory Statistics) is a small utility program that
>  sums up disk usage for direcory trees, very much like the Unix 'du'
>  command.  It displays the disk space used up by a directory tree, both
>  numerically and graphically. It is network transparent (i.e., you can
>  use it to sum up FTP servers), and comes with predefined and user
>  configurable cleanup actions. You can directly open a directory branch
>  in Konqueror or the shell of your choice, compress it to a .tar.bz2
>  archive, or define your own cleanup actions.
>
> Upstream
> Author: Stefan Hundhammer <[EMAIL PROTECTED]>
> Site: kdirstat.sourceforge.net
>  
> This should be a fairly easy package to check. It compiled right out of
> the box and its operation is straight-forward. The upstream code required
> only one small modification in a makefile to fix some little policy
> offense.

Only problem I see is that you should close the ITP "bug" in the
changelog:

  * Initial Release (Closes: #162015)

Unfortunately, I'm not a dev yet, and I can't upload this for you.

-- 
People said I was dumb, but I proved them!



msg07847/pgp0.pgp
Description: PGP signature

Re: What to do with wrong files from upstreams

[Roger Leigh]

Karolina Lindqvist <[EMAIL PROTECTED]> writes:

> tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> 
> > It looks like all the files are pre-existing.  Try running dpkg-source
> > -b from another directory or renaming the noteedit-2.0.16 directory?
> 
> ... And then yet another question. When I get the following error message:
> 
> In file included from knat_toolbar.cpp:18:
> knat.moc:17: #error "This file was generated using the moc from 3.0.5. It"
> knat.moc:18: #error "cannot be used with the include files from this version 
> of Qt."
> knat.moc:19: #error "(The moc has changed too much.)"
> 
> Oobviously I need to rebuild the *.moc files that comes from upstreams that 
> are not deleted by "make distclean". Sometimes that goes automatically by the 
> Makefile if the moc file is removed.  How should I handle this gracefully? 
> Delete the *.moc files from the *.orig.tar file, delete them in the 
> debian/rules files, delete them in the "clean" rule or something else?

The `clean' rule is run before the build (by dpkg-buildpackage), so I
would do

find . -name '*.moc' | xargs rm -f

to remove the .moc files.  If they can easily be regenerated, I would
ask upstream to remove them from the tarball (but I'm not a Qt/KDE
expert).  Make sure you Build-Depend on libqt-dev (which provides
moc)!


-- 
Roger Leigh
"Liberty and Livelihood" - Support the Countryside Alliance
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers


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

Re: Request for Sponsor: kdirstat - Graphical disk usage display

[Rene Engelhard]

Hi Mike,

Mike Schacht wrote:
> Package location: 
>   www.midstatesd.net/~mschacht/debian/kdirstat_2.0.1*
> 
[...]
> 
>  KDirStat (KDE Directory Statistics) is a small utility program that
>  sums up disk usage for direcory trees, very much like the Unix 'du'
>  command.  It displays the disk space used up by a directory tree, both
>  numerically and graphically. It is network transparent (i.e., you can
>  use it to sum up FTP servers), and comes with predefined and user
>  configurable cleanup actions. You can directly open a directory branch
>  in Konqueror or the shell of your choice, compress it to a .tar.bz2
>  archive, or define your own cleanup actions.

Found a sponsor already?

If no, I can sponsor you.

Mail me back if you need one.

Regards,

Rene

-- 
  .''`. Rene Engelhard -- Debian GNU/Linux Developer 
 : :' : http://www.debian.org | http://people.debian.org/~rene/ 
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73



msg07849/pgp0.pgp
Description: PGP signature

Re: ogmtools

[Luigi Gangitano]

Il mer, 2002-11-13 alle 22:07, Marc Leeman ha scritto:
> The package enables e.g. encoding media files (xvid, ...) with an ogg
> audio stream instead of mp3 encoded audio.

If nobody has already offered, I can sponsor you.

> Upstream: http://www.bunkus.org/videotools/
> Debian pre: http://www.esat.kuleuven.ac.be/~mleeman/simple/debian.html

I took your 1:0.960-2 version. You should upgrade to Standard-Version
3.5.7 as this is what is up-to-date now and close your ITP bug in
changelog.

In addition lintian reports that the man page for ogmcat is strange and
indeed it is empty. Please write one if upstream is unwilling.

L

-- 
 Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]>
 GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26



signature.asc
Description: PGP signature

Re: Looking for sponsor for: libapache-mod-sqlinclude, hd-dma

[Matthew Palmer]

On Wed, 13 Nov 2002, Marcin Orlowski wrote:

> I've packaged mod_sqlinclude 
> and small script hd-dma. Both can be found packaged at
> http://wfmh.org.pl/~carlos/debian/

I'm not seeing an .orig.tar.gz and a patch.  Trust me on this - you want to
keep them separate, even if you are the only person working on it at this
stage.  CVS has nice features for doing this - it's been discussed before,
but if you want my way of doing it, just ask.

> These are my first packages so I am open for all the 
> improvement sugestions. And I'm looking for sponsor
> and uploader of course ;)

I'll sponsor at least mod_sqlinclude (I'm maintainer for mod_auth_mysql, as
well as upstream for it at present, so I know a bit about packaging apache
modules) but I'd prefer to do it the Proper Way (orig+diff).

My current list of suggestions for improvement are:

* orig+diff.  I can't help it, it's my way, but I really don't like
non-native packages without orig+diff.  Think of it as a sub-release if it
helps.

* Your LICENSE.txt file mentions mod_sqlinclude.c version 2.x, but your up
to 1.4.  Residue from whatever you took your example from?

* No need to put gratuitous .txt extensions after things; this is Unix, we
are the Blessed People of the ASCII Format.  

* Use autoconf for your Makefile.  It's not really a Debian thing, but
hand-editing Makefiles gets real old, real fast.  Check out the latest
(4.1.0) release of mod_auth_mysql for an example of how to do it (not the
best example, but functional(ish)).

* No need to leave an empty dirs file in debian/.

* I don't think your manual page actually documents the bar command.  Also,
I don't see any info documentation.  I commend your dedication in writing a
man page, though, but it needs a fair chunk of work.

* Your postinst needs to be taken out the back and put out of it's misery. 
We have Debconf.  It's cool.  Please use it.  Ditto for your prerm.

* Rip the commented-out debhelper calls out of rules.  It's a niggly thing,
but there's no point leaving them in there.

And I think I've ripped your packagin skills to bits enough for one day. 



-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org


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

Re: What to do with wrong files from upstreams

[Karolina Lindqvist]

Wednesday 13 November 2002 22.30 skrev Roger Leigh:

> The `clean' rule is run before the build (by dpkg-buildpackage), so I
> would do
>
> find . -name '*.moc' | xargs rm -f
>
> to remove the .moc files.  If they can easily be regenerated, I would
> ask upstream to remove them from the tarball (but I'm not a Qt/KDE
> expert).  Make sure you Build-Depend on libqt-dev (which provides
> moc)!

So I guess this is the best thing to do in this case, and as you say, ask 
upstream to remove the files that are regenerated in the makefile.

-- Karolina


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

Re: What does dpkg-source mean with this?

[Karolina Lindqvist]

Wednesday 13 November 2002 12.18 skrev Paul Cupis:

> It can be modified. It should be unchanged. Being unchanged has beneifts
> including but not limited to allowing users to verify the original tgz with
> upstream and clearly showing (in the diff.gz) what changes were made during
> packaging. If these changes can be sent upstream for inclusion in a later
> release of the software, geat.

Ok, I understand. Unmodified if possible, even if dpkg-source complains.

> It doesn't matter. dpkg-source will extract the tgz to a correctly named
> directory.

It appears that it does not do that in the noteedit case, since it tries to 
extract over the build-directory. So something else is wrong.

> It should be called noteedit_2.0.16.orig.tar.gz, per the packaging manual.

Meaning the only modification is to change the name?

> I would be inclined to leave it in the orig.tar.gz, but either patch it or
> remove in the build process (in the clean target?). I'm don't have the
> details of how to best do this handy, but iirc, this is the recommended
> solution.

The problem is that the diff file becomes hard to understand, and you can't 
use the same diff file on a later version of the program, but have to unpack 
the version matching the diff file first, save the debian dir, and then 
unpack the version you want to build, remove the patches to the debian dir 
from the diff file, and apply the patches (if any). Therefore I actually 
prefer a clean debian dir in the tar file when the patch file is made. Of if 
somehow the debian files in the diff file can just completely replace the old 
ones with some diff option. If it is possible to make debian-source to 
understand that.

> Not by you? Bug upstream about it, i think. Again, this is related to
> having a pristine upstream orig.tar.gz if possible (but this is not
> essential).

So if there are any, I should just leave them and remove them in the clean 
target.


-- Karolina


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

Re: What does dpkg-source mean with this?

[Karolina Lindqvist]

tisdagen den 12 november 2002 21.28 skrev Roger Leigh:

> It looks like all the files are pre-existing.  Try running dpkg-source
> -b from another directory or renaming the noteedit-2.0.16 directory?

That might be the problem, so please bear me with some questions so that I get 
this very clear to me:

When you take a tar file from somewhere and make a debian package of it, 
should it be unchanged from upstream or can it be modified?

For example, should (in this case) noteedit_2.0.16.orig.tar.gz extract to 
noteedit, noteedit-2.0.16 or noteedit-2.0.16.orig? Does it matter?

Can the source tar file be called noteedit-2.0.16.tar or should it be renamed 
to noteedit_2.0.16.orig.tar

If there is an old debian directory in the upstreams tar file, for some old 
debian version. Should that be removed?

If there are bin-files or *.o files or similar in the upstreams tar file. 
Should they be removed?

In KDE applications, normally a "make -f Makefile.cvs" (or similar) is done 
before the upstreams tar file is packed. But often that is done with another 
version of automake than debian is using. Often an old automake1.4 or 
something. If some changes are needed to the *.am files, that will create 
problems due to automake incompatibilites. If no changes to the *.am files is 
needed, it might work even with incompatible versions, since automake is 
never called, but it might create trouble if something is changed.

One solution is to make a "make -f Makefile.cvs" before building it on debian, 
but then the diffs with all the Makefile.in files etc. will become huge. Can 
that be done before packing the *.orig.tar file, to avoid rebuilding problems 
and making the diffs small?

Many questions, but it is things that I have been wondering about.

-- Karolina

What to do with wrong files from upstreams

[Karolina Lindqvist]

tisdagen den 12 november 2002 21.28 skrev Roger Leigh:

> It looks like all the files are pre-existing.  Try running dpkg-source
> -b from another directory or renaming the noteedit-2.0.16 directory?

... And then yet another question. When I get the following error message:

In file included from knat_toolbar.cpp:18:
knat.moc:17: #error "This file was generated using the moc from 3.0.5. It"
knat.moc:18: #error "cannot be used with the include files from this version 
of Qt."
knat.moc:19: #error "(The moc has changed too much.)"

Oobviously I need to rebuild the *.moc files that comes from upstreams that 
are not deleted by "make distclean". Sometimes that goes automatically by the 
Makefile if the moc file is removed.  How should I handle this gracefully? 
Delete the *.moc files from the *.orig.tar file, delete them in the 
debian/rules files, delete them in the "clean" rule or something else?

-- Karolina

Re: What does dpkg-source mean with this?

[Paul Cupis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 13 November 2002 06:58, Karolina Lindqvist wrote:
> tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> > It looks like all the files are pre-existing.  Try running dpkg-source
> > -b from another directory or renaming the noteedit-2.0.16 directory?
>
> That might be the problem, so please bear me with some questions so that I
> get this very clear to me:
>
> When you take a tar file from somewhere and make a debian package of it,
> should it be unchanged from upstream or can it be modified?

It can be modified. It should be unchanged. Being unchanged has beneifts 
including but not limited to allowing users to verify the original tgz with 
upstream and clearly showing (in the diff.gz) what changes were made during 
packaging. If these changes can be sent upstream for inclusion in a later 
release of the software, geat.

> For example, should (in this case) noteedit_2.0.16.orig.tar.gz extract to
> noteedit, noteedit-2.0.16 or noteedit-2.0.16.orig? Does it matter?

It doesn't matter. dpkg-source will extract the tgz to a correctly named 
directory.

> Can the source tar file be called noteedit-2.0.16.tar or should it be
> renamed to noteedit_2.0.16.orig.tar

It should be called noteedit_2.0.16.orig.tar.gz, per the packaging manual.

> If there is an old debian directory in the upstreams tar file, for some old
> debian version. Should that be removed?

I would be inclined to leave it in the orig.tar.gz, but either patch it or 
remove in the build process (in the clean target?). I'm don't have the 
details of how to best do this handy, but iirc, this is the recommended 
solution.

> If there are bin-files or *.o files or similar in the upstreams tar file.
> Should they be removed?

Not by you? Bug upstream about it, i think. Again, this is related to having a 
pristine upstream orig.tar.gz if possible (but this is not essential).

> In KDE applications, normally a "make -f Makefile.cvs" (or similar) is done
> before the upstreams tar file is packed. But often that is done with
> another version of automake than debian is using. Often an old automake1.4
> or something. If some changes are needed to the *.am files, that will
> create problems due to automake incompatibilites. If no changes to the *.am
> files is needed, it might work even with incompatible versions, since
> automake is never called, but it might create trouble if something is
> changed.
>
> One solution is to make a "make -f Makefile.cvs" before building it on
> debian, but then the diffs with all the Makefile.in files etc. will become
> huge. Can that be done before packing the *.orig.tar file, to avoid
> rebuilding problems and making the diffs small?

I'll leave the rest for someone else, unless I get more time later. :)

Paul Cupis
- -- 
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE90jUOIzuKV+SHX/kRArphAJ9nnYHG1Dy6/gEvrOs0womIcTrmvwCeLct/
W4YmXm7BrhEXBj7ZSQLdAYw=
=qZwO
-END PGP SIGNATURE-

Re: What does dpkg-source mean with this?

[Sven Luther]

On Wed, Nov 13, 2002 at 11:18:20AM +, Paul Cupis wrote:
> > If there is an old debian directory in the upstreams tar file, for some old
> > debian version. Should that be removed?
> 
> I would be inclined to leave it in the orig.tar.gz, but either patch it or 
> remove in the build process (in the clean target?). I'm don't have the 
> details of how to best do this handy, but iirc, this is the recommended 
> solution.

Just leave it.

You erase it, modify it or do whatever you need to bring it to par with
the your current need, and let dpkg-buildpackage generate the .diff that
will patch the upstream provided directory to the current one.

If you want, you can even send the diff upstream so they have an
uptodate debian directory.

> > If there are bin-files or *.o files or similar in the upstreams tar file.
> > Should they be removed?
> 
> Not by you? Bug upstream about it, i think. Again, this is related to having 
> a 
> pristine upstream orig.tar.gz if possible (but this is not essential).

It would depend on what the .o are. If they are cruft left there by a an
incomplete clean target, patch the makefile so they get removed and send
a bug report with it upstream. If they have legitimate reason for being
there, then it is another question, which will depend on the reason for
it being there.

You will face problems with the clean target and multiple running of
dpkg-buildpackage if they are present, get changed or are removed by
clean though.

I have such a case in one of my packages, and i move them around during
the build and restore them when cleaning.

Friendly,

Sven Luther

Request for Sponsor: kdirstat - Graphical disk usage display

[Mike Schacht]

Package location: 
www.midstatesd.net/~mschacht/debian/kdirstat_2.0.1*

Be sure to get this version, 2.0.1. The 2.2.0 version depends on some
kde3 libs that have still not made it into unstable.

>From the .deb description:

 KDirStat (KDE Directory Statistics) is a small utility program that
 sums up disk usage for direcory trees, very much like the Unix 'du'
 command.  It displays the disk space used up by a directory tree, both
 numerically and graphically. It is network transparent (i.e., you can
 use it to sum up FTP servers), and comes with predefined and user
 configurable cleanup actions. You can directly open a directory branch
 in Konqueror or the shell of your choice, compress it to a .tar.bz2
 archive, or define your own cleanup actions.

Upstream
Author: Stefan Hundhammer <[EMAIL PROTECTED]>
Site:   kdirstat.sourceforge.net
 
This should be a fairly easy package to check. It compiled right out of
the box and its operation is straight-forward. The upstream code required
only one small modification in a makefile to fix some little policy
offense.


Thanks,

Mike Schacht
[EMAIL PROTECTED]

Re: Replacing a single file with Replaces:

[Matt Zimmerman]

On Tue, Nov 12, 2002 at 08:32:53PM -0500, Duncan Findlay wrote:

> Try using Conflicts: instead of (or in addition to) Replaces:

That means something entirely different.

-- 
 - mdz

RE: What to do with wrong files from upstreams

[wturkal]

>= Original Message From Karolina Lindqvist <[EMAIL PROTECTED]> 
=
>tisdagen den 12 november 2002 22.25 skrev Warren Turkal:
>
>> File a bug with the KDE people. Maybe look at the automake stuff and figure
>> out why it doesn't delete them.
>> What kde package is this in?
>
>It is not in main KDE, but in an application knetfilter, that I picked up and
>thought could be handy to have. Yes, I can contact the author and point it
>out. I was wondering in general what to do in such a situation, how to
>produce a debian package without waiting for upstreams to fix it (which can
>take a long time for the next release).
The easiest thing I can think of is to make the clean of debian/rules delete 
all moc files from the build tree. This keeps the changes out of the source. I 
think that the right solution is to look and see if you can provide a patch to 
the upstream source, though.

Warren

-- 
Treasurer, GOLUM, Inc.
Group of Linux Users in Memphis
http://www.golum.org

Looking for sponsor for: libapache-mod-sqlinclude, hd-dma

[Marcin Orlowski]

Hi,

I've packaged mod_sqlinclude 
and small script hd-dma. Both can be found packaged at
http://wfmh.org.pl/~carlos/debian/

These are my first packages so I am open for all the 
improvement sugestions. And I'm looking for sponsor
and uploader of course ;)

Regards,
-- 
 And he said: "God CTRL-S the Queen"...

 Marcin  http://wfmh.org.pl/~carlos/
 mailto:[EMAIL PROTECTED]

ogmtools

[Marc Leeman]

A second call for a sponsor for the package ogmtools.

The package enables e.g. encoding media files (xvid, ...) with an ogg
audio stream instead of mp3 encoded audio.

The tools are used in transcode (excellent video transcoding tool
(maintained by Christian Marillat).


Upstream: http://www.bunkus.org/videotools/
Debian pre: http://www.esat.kuleuven.ac.be/~mleeman/simple/debian.html

-- 
greetz, marc
 
My pony-tail hit the on/off switch on the power strip.
 Key fingerprint = 890C E47F 1589 F240 9CC8  C60C 510A 63D3 D356 2DE1
Linux mykene 2.4.19-xfs #1 Mon Aug 26 14:55:46 CEST 2002 i686 unknown unknown 
GNU/Linux


pgpJvDwDhmz2G.pgp
Description: PGP signature

Looking for sponsor: ada-reference-manual

[Florian Weimer]

I'm looking for a sponsor for the ada-reference-manual package.

* Package name: ada-reference-manual
  Version : 1.0
  Upstream Author : ISO/IEC JTC1/SC22/WG9, Ada Rapporteur Group
* URL : http://www.ada-auth.org/arm.html
* License : custom, but DFSG-conforming
  Description : The standard describing the Ada 95 language.

This package contains various versions of the Ada Reference Manual, the
standard describing the programming language Ada.  HTML, text and
Texinfo formats are provided.

A preliminary package can be found here (careful, slow link):

  

Re: Request for Sponsor: kdirstat - Graphical disk usage display

[Brian Nelson]

Mike Schacht <[EMAIL PROTECTED]> writes:

> Package location: 
>   www.midstatesd.net/~mschacht/debian/kdirstat_2.0.1*
>
> Be sure to get this version, 2.0.1. The 2.2.0 version depends on some
> kde3 libs that have still not made it into unstable.
>
> From the .deb description:
>
>  KDirStat (KDE Directory Statistics) is a small utility program that
>  sums up disk usage for direcory trees, very much like the Unix 'du'
>  command.  It displays the disk space used up by a directory tree, both
>  numerically and graphically. It is network transparent (i.e., you can
>  use it to sum up FTP servers), and comes with predefined and user
>  configurable cleanup actions. You can directly open a directory branch
>  in Konqueror or the shell of your choice, compress it to a .tar.bz2
>  archive, or define your own cleanup actions.
>
> Upstream
> Author: Stefan Hundhammer <[EMAIL PROTECTED]>
> Site: kdirstat.sourceforge.net
>  
> This should be a fairly easy package to check. It compiled right out of
> the box and its operation is straight-forward. The upstream code required
> only one small modification in a makefile to fix some little policy
> offense.

Only problem I see is that you should close the ITP "bug" in the
changelog:

  * Initial Release (Closes: #162015)

Unfortunately, I'm not a dev yet, and I can't upload this for you.

-- 
People said I was dumb, but I proved them!


pgpoF6dP0nmOD.pgp
Description: PGP signature

Re: What to do with wrong files from upstreams

[Roger Leigh]

Karolina Lindqvist <[EMAIL PROTECTED]> writes:

> tisdagen den 12 november 2002 21.28 skrev Roger Leigh:
> 
> > It looks like all the files are pre-existing.  Try running dpkg-source
> > -b from another directory or renaming the noteedit-2.0.16 directory?
> 
> ... And then yet another question. When I get the following error message:
> 
> In file included from knat_toolbar.cpp:18:
> knat.moc:17: #error "This file was generated using the moc from 3.0.5. It"
> knat.moc:18: #error "cannot be used with the include files from this version 
> of Qt."
> knat.moc:19: #error "(The moc has changed too much.)"
> 
> Oobviously I need to rebuild the *.moc files that comes from upstreams that 
> are not deleted by "make distclean". Sometimes that goes automatically by the 
> Makefile if the moc file is removed.  How should I handle this gracefully? 
> Delete the *.moc files from the *.orig.tar file, delete them in the 
> debian/rules files, delete them in the "clean" rule or something else?

The `clean' rule is run before the build (by dpkg-buildpackage), so I
would do

find . -name '*.moc' | xargs rm -f

to remove the .moc files.  If they can easily be regenerated, I would
ask upstream to remove them from the tarball (but I'm not a Qt/KDE
expert).  Make sure you Build-Depend on libqt-dev (which provides
moc)!


-- 
Roger Leigh
"Liberty and Livelihood" - Support the Countryside Alliance
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers

Re: Request for Sponsor: kdirstat - Graphical disk usage display

[Rene Engelhard]

Hi Mike,

Mike Schacht wrote:
> Package location: 
>   www.midstatesd.net/~mschacht/debian/kdirstat_2.0.1*
> 
[...]
> 
>  KDirStat (KDE Directory Statistics) is a small utility program that
>  sums up disk usage for direcory trees, very much like the Unix 'du'
>  command.  It displays the disk space used up by a directory tree, both
>  numerically and graphically. It is network transparent (i.e., you can
>  use it to sum up FTP servers), and comes with predefined and user
>  configurable cleanup actions. You can directly open a directory branch
>  in Konqueror or the shell of your choice, compress it to a .tar.bz2
>  archive, or define your own cleanup actions.

Found a sponsor already?

If no, I can sponsor you.

Mail me back if you need one.

Regards,

Rene

-- 
  .''`. Rene Engelhard -- Debian GNU/Linux Developer 
 : :' : http://www.debian.org | http://people.debian.org/~rene/ 
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


pgpEY193pokBk.pgp
Description: PGP signature

Re: ogmtools

[Luigi Gangitano]

Il mer, 2002-11-13 alle 22:07, Marc Leeman ha scritto:
> The package enables e.g. encoding media files (xvid, ...) with an ogg
> audio stream instead of mp3 encoded audio.

If nobody has already offered, I can sponsor you.

> Upstream: http://www.bunkus.org/videotools/
> Debian pre: http://www.esat.kuleuven.ac.be/~mleeman/simple/debian.html

I took your 1:0.960-2 version. You should upgrade to Standard-Version
3.5.7 as this is what is up-to-date now and close your ITP bug in
changelog.

In addition lintian reports that the man page for ogmcat is strange and
indeed it is empty. Please write one if upstream is unwilling.

L

-- 
 Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]>
 GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26


signature.asc
Description: PGP signature

Re: Looking for sponsor for: libapache-mod-sqlinclude, hd-dma

[Matthew Palmer]

On Wed, 13 Nov 2002, Marcin Orlowski wrote:

> I've packaged mod_sqlinclude 
> and small script hd-dma. Both can be found packaged at
> http://wfmh.org.pl/~carlos/debian/

I'm not seeing an .orig.tar.gz and a patch.  Trust me on this - you want to
keep them separate, even if you are the only person working on it at this
stage.  CVS has nice features for doing this - it's been discussed before,
but if you want my way of doing it, just ask.

> These are my first packages so I am open for all the 
> improvement sugestions. And I'm looking for sponsor
> and uploader of course ;)

I'll sponsor at least mod_sqlinclude (I'm maintainer for mod_auth_mysql, as
well as upstream for it at present, so I know a bit about packaging apache
modules) but I'd prefer to do it the Proper Way (orig+diff).

My current list of suggestions for improvement are:

* orig+diff.  I can't help it, it's my way, but I really don't like
non-native packages without orig+diff.  Think of it as a sub-release if it
helps.

* Your LICENSE.txt file mentions mod_sqlinclude.c version 2.x, but your up
to 1.4.  Residue from whatever you took your example from?

* No need to put gratuitous .txt extensions after things; this is Unix, we
are the Blessed People of the ASCII Format.  

* Use autoconf for your Makefile.  It's not really a Debian thing, but
hand-editing Makefiles gets real old, real fast.  Check out the latest
(4.1.0) release of mod_auth_mysql for an example of how to do it (not the
best example, but functional(ish)).

* No need to leave an empty dirs file in debian/.

* I don't think your manual page actually documents the bar command.  Also,
I don't see any info documentation.  I commend your dedication in writing a
man page, though, but it needs a fair chunk of work.

* Your postinst needs to be taken out the back and put out of it's misery. 
We have Debconf.  It's cool.  Please use it.  Ditto for your prerm.

* Rip the commented-out debhelper calls out of rules.  It's a niggly thing,
but there's no point leaving them in there.

And I think I've ripped your packagin skills to bits enough for one day. 



-- 
Matthew Palmer, Debian Developer
[EMAIL PROTECTED] http://www.debian.org