Re: help in chages necessary for rules file( creating .deb packages)

[Matthew Palmer]

On Wed, Jan 12, 2005 at 07:31:33AM -0600, elijah wright wrote:
> 
> >From: TIFR students <[EMAIL PROTECTED]>
> 
> >We are trying to make .deb packages using
> 
> generally you will probably get more help if you subscribe with your 
> PERSONAL email accounts and *sign your name* rather than sending mail from 
> what appears to be a pseudo-anonymous group account.
> 
> I suspect there are other people who are also ignoring you because you are 
> essentially *not a person* as far as collaboration or cooperation are 
> concerned.  Who are you?  No one else on here has a clue!

I don't care that they use a pseudonym, but their hit-n-run tactics are
getting up my nose.  I've asked a good number of questions to help give them
a better answer, and have never received a response.  So I've given up
trying to help them.

- Matt


signature.asc
Description: Digital signature

Re: rfc:ratpoison

[Sven Mueller]

Mike O'Connor wrote on 12/01/2005 18:45:
ratpoison (1.3.0-1) unstable; urgency=low
  * changed Build-depends from automaken to automake1.4 (Closes: #289743)
  * repackaged as a non-debian native package
  * added emacsen scripts to install the ratpoison.el from upstream
  * changed dh_installmanpages to dh_installman (Closes: #257098)
257098 is "new upstream version available"
  * Closes: #267475
This is the manpage not installed bug, so it should probably be:
 * changed dh_installmanpages to dh_installman (Closes: #267475)
 * Updated to new upstream version (Closes: #257098)
You should never use any "Closes: #" without explanation.
Didn't take any look at the package itself though.
cu,
sven
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFS: autoreply

[Chris Sacca]

Name of package:  autoreply
License: BSD style
autoreply - A safe, rate-limited auto-responder
Autoreply is a simple auto-responder useful for replying to
email upon receipt,  designed to be used safely without
supervision.
Avalible at: http://csacca.thecsl.org/deb/
-
Autoreply is a simple auto-responder useful for replying to email upon 
receipt,  designed to be used safely without supervision.

   * It remembers who it has replied to recently, and won't reply to 
them again within a specified interval (default, 30 minutes)

   * It has a list of addresses that it will not respond to 
(MAILER-DAEMON, majordomo, listserv, etc)

   * It examines headers checking for mailing lists, and does not reply 
if it determines the mail is from a mailing list

   * In case these features are insufficient autoreply also has a rate 
limit, and will not send more than a specified amount of mail in a given 
time. The rate and interval are configurable.

Thank you for your time,
-- Christopher Sacca
--
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/S d-(+) s+: a--- C++() UL++($) P++>+++ L++>+++ E W++ N
o? K- w--- O? M+ V- PS++ PE- Y+ PGP- t+ 5? X+(-) R+>++ tv- b+ DI+ D---
G e>+++ h!>- r*>++ y+
--END GEEK CODE BLOCK--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: dosage -- powerful webcomic downloader / archiver

[Tristan Seligmann]

I haven't had any offers for sponsorship yet, so I thought I'd provide
a more detailed description of the software.

Dosage is a webcomic downloader, written in Python. The main intent is
to provide you with an easy way of keeping up-to-date local copies of
your favourite comics, so you don't have to manually check for new
strips, or wait for them to load (which can take a little while on a
slower connection).

Unlike dailystrips, it can "catch up" to the last strip you downloaded,
even if there have been several new strips in the meanwhile. You can also
download every strip in one shot through the same mechanism (eg. if you
discover a new comic that you're interested in). Dosage and dailystrips
currently have support for an overlapping set of comics, but Dosage is
updated fairly frequently, and will soon catch up.

stripclub has similar downloading functionality (Dosage does not include
any kind of viewing software), but has not been updated in Debian for
nearly 6 months, and has support for a relatively tiny set of comics. You
can add your own definition files, of course, but Dosage is similarly
extensible with a little knowledge of regexes and Python.

As mentioned before, Dosage is licenced under the GPL.

The upstream website is at:
http://slipgate.za.net/dosage

My packages are located at:
http://slipgate.za.net/~mithrandi/debian/dosage

-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: Question about packaging documentation

[Magnus Therning]

Frank Küster wrote:
<[EMAIL PROTECTED]> schrieb:
So is there any documenation about building non binary packages from scratch?
Just as any architecture-independent package. Why not have a look at one
existing example (apt-cache --names-only search ^doc-).
One problem with many of the -doc packages is that they are part of 
multi-packages (e.g. libtool and libtool-doc are built from the same 
source package). devhelp-books is an example of a doc-only package.

/M
--
Magnus Therning(OpenPGP: 0xAB4DFBA4)
[EMAIL PROTECTED]
http://magnus.therning.org/
Software is not manufactured, it is something you write and publish.
Keep Europe free from software patents, we do not want censorship
by patent law on written works.
Nearly all men can stand adversity, but if you want to test a man's
character, give him power.
 -- Abraham Lincoln


signature.asc
Description: OpenPGP digital signature

Re: RFS[2]: cpufrequtils (comments on packaging also welcome)

[Mattia Dongili]

On Wed, Jan 12, 2005 at 12:59:38AM +0100, Achim Bohnet wrote:
> On Friday 07 January 2005 22:03, Mattia Dongili wrote:
[...]
> > Hopefully many of the existing cpufreq related daemons will soon use
> > the provided library (cpufreqd is migrating at least).
> 
> Any comment from the cpudyn upstream yet?

No, I've seen a patch to migrate cpuspeed but that tool is not in Debian
(yet?)

[...]
> > Last but not least comments on packaging are welcome. :)
> 
> o why not libcpufreq0-dev as suggested at 
>   http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
>   At least with libcpufreq1 you will need something like libcpufreq1-dev
>   otherwise one can't build pkg depending on libcpufreq0 interface anymore

Actually reading one ot the latest topics on d-devel[1] I'm pretty
convinced that having only one -dev package is better. Also, I'm
upstream for cpufreqd so I can keep it up-to-date and I like coding:
patches for outdated pkgs will flw :)

[1]: http://lists.debian.org/debian-devel/2005/01/msg00623.html
  or better
 http://lists.debian.org/debian-devel/2005/01/msg00695.html

> o AUTHOR, NEWS file isn't included.  Btw. AUTHOR file and upstream in
>   debian/copyright do not match.  You are too humble ;)

uh :) right (/me turning red)

> o -dev pkg should depend on the libcpufreq0 (= ${Source-Version})
> 
> o just wondering: tarball comes precompiled .mo files.  Are they
>   cpu architecture independent?

Hummm, I documented myself a (very) little and I'd say they are... but I
may be plainly wrong, so I'll continue my self documentation on the
subject

> o cpufreq.h is GPL 'V2 or later' no only GPL V2.  Is just
>   'Licensed under the terms of the GNU GPL License version 2' in .c
>   files enough?

I'll ping upstream on this issue.

Thanks for your comments, I'll keep your suggestion for the next pkg
revision

> -- 
>   To me vi is Zen.  To use vi is to practice zen. Every command is
>   a koan. Profound to the user, unintelligible to the uninitiated.
>   You discover truth everytime you use it.
:)
-- 
mattia
:wq!


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

Re: rfc:ratpoison

[Mike O'Connor]

> (cc'd #289743 as this info is important for anyone looking at this bug)
> 
> On Wed, Jan 12, 2005 at 12:45:52PM -0500, Mike O'Connor wrote:
> >   * changed Build-depends from automaken to automake1.4 (Closes: #289743)
> 
> If it doesn't work with other automake, you _need_ to make sure this
> won't happen, i.e. invoke automake1.4 explicitely, including
> (disclaimer: following from inperfect memory, I can very well be wrong!)
> probably aclocal-1.4, as otherwise automake-1.4 would invoke whatever
> aclocal version that's preferred, in stead of the 1.4 version.
> 
> Just merely depending on automake1.4 will not prevent automake1.7 (for
> example) from being present, and automaking the package.

Yes.  I think i'm ok in this regard.

I have several automake versions installed on my machine and i have the 
automake alternative pointing to automake1.9 currently and this package builds 
fine that way.

The Makefile that is created by configure contains this definition:

AUTOMAKE = automake-1.4

Thanks,
mike


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

Re: help in chages necessary for rules file( creating .deb packages)

[Osamu Aoki]

On Wed, Jan 12, 2005 at 02:23:25AM -0800, TIFR students wrote:
> 
>  We are trying to make .deb packages using
> dh_make...it works fine..it creates a template for
> rules filesuppose a source file is a simple c
> program(hello world) what changes should we make in
> the rules file so that the dpkg-buildpackage works
> properly
> 
> Please Help!!1

You can do:

# apt-get source hello

and learn from it.  Also Josip has nice intro:

 http://www.debian.org/doc/manuals/maint-guide/index.en.html

 (I recently made few chwanges, if you find error, let me know.)

Osamu


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

Re: rfc:ratpoison

[Jeroen van Wolffelaar]

(cc'd #289743 as this info is important for anyone looking at this bug)

On Wed, Jan 12, 2005 at 12:45:52PM -0500, Mike O'Connor wrote:
>   * changed Build-depends from automaken to automake1.4 (Closes: #289743)

If it doesn't work with other automake, you _need_ to make sure this
won't happen, i.e. invoke automake1.4 explicitely, including
(disclaimer: following from inperfect memory, I can very well be wrong!)
probably aclocal-1.4, as otherwise automake-1.4 would invoke whatever
aclocal version that's preferred, in stead of the 1.4 version.

Just merely depending on automake1.4 will not prevent automake1.7 (for
example) from being present, and automaking the package.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

rfc:ratpoison

[Mike O'Connor]

The ratpoison package seems to be neglectecd.  I made an attempt to repackage 
it, and I was going to send it to the maintainer to see if i can get a new 
version uploaded, but since I haven't done much of this I was hoping to get 
someone to look over my packaging before I send it to the maintainer.

The new packages I created are here:

deb http://vireo.org/debian/ratpoison binary/
deb-src http://vireo.org/debian/ratpoison source/

and my entry to the changelog:

ratpoison (1.3.0-1) unstable; urgency=low

  * changed Build-depends from automaken to automake1.4 (Closes: #289743)
  * repackaged as a non-debian native package
  * added emacsen scripts to install the ratpoison.el from upstream
  * changed dh_installmanpages to dh_installman (Closes: #257098)
  * Closes: #267475

 -- Mike O'Connor <[EMAIL PROTECTED]>  Tue, 11 Jan 2005 13:35:14 -0500

I don't know if urgency=low is correct because this fixes an RC bug.

Any comments would be appriciated.

Thanks,
stew


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

Re: About creating .deb packages

[Bernhard R. Link]

* martin f krafft <[EMAIL PROTECTED]> [050112 12:45]:
> also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2005.01.03.1055 +0100]:
> > Are you trying to say "You even get an alarm if the malfunction has 
> > only hit metadata and no important data yet".
> 
> metadata? We are talking about MD5 sums, and yes, it does not really
> matter whether the bit flip is in the data or the hash... or can you
> tell which one actually changed?

I know _something_ has changed. Redownloading the .deb I can see which
of the both is changed. I can look what is happening. And reinstall this
package after I deaktivated dma or did whatever else to make the system
work again properly.

> > I do not know why you know what it is supposed to do. I also do not
> > care what it is supposed to do. I'm concerned what it is useful for.
> > And it is definitly useful.
> 
> An integrity checker does the job in a better way -- if used
> properly. And I would be very happy to hear of a good reason for
> debsums other than helping you figure out which files in /usr or
> /lib you modified, as the admin -- which you should not do anyway.

Again, I do not know what you consider as "job" or as "better". But
still debsums is a real, existing and easy solution to a real problem.
If I get to some machine running Debian and having problems, I can
install debsums and let it run. And in both cases of broken hardware
or some admin or program stupidly changing system files it will tell
me. Change the Debian base system to include anything you call a
"integrity checker" in an default install and I may change my opinion,
but until that debsums is integral and important part of Debian
infrastructure, and packages not shipping a .md5sums file a --
thankworthily seldom -- nuisance.

> > > If the md5sum of the DEB file validates against the Packages index,
> > > the package is valid.
> > 
> > Hurray, downloading all installed .deb's, verifying their md5sum,
> > comparing the files against installed versions is still very slow
> > on a modern computer connected with 100MBit to the local mirror
> > (containing even all obsolete and old versions of installed packages).
> > Not to mention the lack of tool to do this automatically...
> 
> I am failing to see your point.

My point is that there is no other solution to the problem. Your
suggestion seems to have been to not have .md5ums file but have alle
.deb files around, which is normally not doable.

Hochachtungsvoll,
  Bernhard R. Link


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

Re: help in chages necessary for rules file( creating .deb packages)

[Eric Lavarde]

Hi,

have you read the "Debian New Maintainers' Guide"? That's what I started
with recently, and it's pretty easy to follow.
Install it with "apt-get install maint-guide" or have a look at
http://www.debian.org/doc/maint-guide/.

Cheers, Eric

>
>  We are trying to make .deb packages using
> dh_make...it works fine..it creates a template for
> rules filesuppose a source file is a simple c
> program(hello world) what changes should we make in
> the rules file so that the dpkg-buildpackage works
> properly
>
> Please Help!!1


-- 
Eric de France, d'Allemagne et de Navarre


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

Re: help in chages necessary for rules file( creating .deb packages)

[elijah wright]

From: TIFR students <[EMAIL PROTECTED]>

We are trying to make .deb packages using
generally you will probably get more help if you subscribe with your 
PERSONAL email accounts and *sign your name* rather than sending mail from 
what appears to be a pseudo-anonymous group account.

I suspect there are other people who are also ignoring you because you are 
essentially *not a person* as far as collaboration or cooperation are 
concerned.  Who are you?  No one else on here has a clue!

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

Re: upload and package

[Justin Pryzby]

On Wed, Jan 12, 2005 at 01:04:18PM +0100, Pierre Ancelot wrote:
> 
> Theoricaly, this shouldn't ever happen but anyways and since it's written, i 
> think i be better to tell about it even if i'm certainly wrong on what really 
> happened.
> 
> After running dpkg-buildpackage -rfakeroot as written on the debian 
> maintainer's guide i get this message. it tells me to enter a pass phrase 
> which i do. Anyhow my curiosity is piqued by the last line : 
> dpkg-buildpackage: binary and diff upload (original source NOT included)
Right; the .orig file is uploaded precisely once; after that,
Developers just upload new .diff's to that source.  (And a new source
is uploaded when upstream releases another one).

Justin


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

Re: RFC and RFS: latex-svninfo

[Achim D. Brucker]

Hi,
Frank Küster <[EMAIL PROTECTED]> schrieb:
> - As it is, the package must go into contrib (Section: contrib/tex),
>   because it build-depends on latex2html from non-free. Maybe you can
>   get rid of this, by not building the html documentation.=20
as a quick "fix", just replace the "\usepackage{html}" by "\usepackage{hevea}". 
Anyway, as I'm not using latex2html (and hevea is IMHO much better) I will 
remove the dependency to html2latex upstream. 

Achim


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

Re: RFS: mocp -- music on console player

[Frank S. Thomas]

Hi,

On Wednesday 12 January 2005 00:03, Michal Jeczalik Jr wrote:

> > THe short descriptopn in the control file shouldnt start
> > with a capital letter.
>
>  Most of short descriptions in debian packages starts with capital
>  letter, so what is the rule?

See the Developer's Reference section 6.2.2 "The package synopsis, or short 
description".

> Debian policy, 5.1:
> ,, Field names are not case-sensitive, but it is usual to capitalize
>the field names using mixed case as shown below.''

The short description is not the field name, it is the field value. The field 
name is "Description".

-Frank
-- 
Nunc vino pellite curas! -- Horaz


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

Re: RFS: mocp -- music on console player

[Nico Golde]

hi,
* Michal Jeczalik Jr <[EMAIL PROTECTED]> [2005-01-12 13:00]:
>  * Nico Golde <[EMAIL PROTECTED]> wrote:
> 
> >> I have uploaded it, http://www.orora.org/michalj/debian/mocp/
> > the package has no revision number. it should be -1. change
> > the changelog file.
> 
>  Fixed.
> 
> > THe short descriptopn in the control file shouldnt start
> > with a capital letter.
> 
>  Most of short descriptions in debian packages starts with capital
>  letter, so what is the rule?

If you detect this, you can write a bug report if you want.
with low priority.
See section 6.2.2 of the dev reference.

> Debian policy, 5.1:
> ,, Field names are not case-sensitive, but it is usual to capitalize
>the field names using mixed case as shown below.''
> 
> > check the files with linda and lintian.
> 
>  No errors, no warnings.
> 
> aarcia% for i in *.(deb|dsc|changes); do echo $i; linda $i; lintian $i; done
> mocp_2.1.4-1.dsc
> mocp_2.1.4-1_i386.changes
> mocp_2.1.4-1_i386.deb

sounds good.
for the future: you only have to check the changes file with
lintian. it checks all files which are listed in it.
regard nico
-- 
Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF ,'"`.
[EMAIL PROTECTED] | http://www.ngolde.de   (  grml.org
VIM has two modes - the one in which it beeps`._,'   
and the one in which it doesn't -- encrypted mail preferred


signature.asc
Description: Digital signature

Re: upload and package

[Eric Lavarde]

Hi,

no problem, nothing was upload_ed_, everything is ready for the described
upload.

Eric

>
> Theoricaly, this shouldn't ever happen but anyways and since it's written,
> i
> think i be better to tell about it even if i'm certainly wrong on what
> really
> happened.
>
> [...]
>
> dpkg-buildpackage: binary and diff upload (original source NOT included)
> [EMAIL PROTECTED]:~/debian/hwtools-0.8$
>


-- 
Eric de France, d'Allemagne et de Navarre


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

Re: upload and package

[Anibal Monsalve Salazar]

On Wed, Jan 12, 2005 at 01:04:18PM +0100, Pierre Ancelot wrote:
>
>Theoricaly, this shouldn't ever happen but anyways and since it's written, i 
>think i be better to tell about it even if i'm certainly wrong on what really 
>happened.
>
>After running dpkg-buildpackage -rfakeroot as written on the debian 
>maintainer's guide i get this message. it tells me to enter a pass phrase 
>which i do. Anyhow my curiosity is piqued by the last line : 
>dpkg-buildpackage: binary and diff upload (original source NOT included)
>
>written "upload". If it did, well, i'm not allowed to, and noone had a review 
>on the package to please someone tell me i didn't _really_ upload it... (even 
>though i didn't modify anything yet in the source.

Don't worry about that. Nothing has been uploaded yet. The message
is about the content of the .changes file.

>You need a passphrase to unlock the secret key for
>user: "Pierre Ancelot <[EMAIL PROTECTED]>"
>1024-bit DSA key, ID 9C2D8B72, created 2005-01-09
>
>
> dpkg-genchanges
>dpkg-genchanges: not including original source code in upload
> signfile hwtools_0.8-2_i386.changes
>
>You need a passphrase to unlock the secret key for
>user: "Pierre Ancelot <[EMAIL PROTECTED]>"
>1024-bit DSA key, ID 9C2D8B72, created 2005-01-09
>
>
>dpkg-buildpackage: binary and diff upload (original source NOT included)
>[EMAIL PROTECTED]:~/debian/hwtools-0.8$

Anibal Monsalve Salazar
--
 .''`. Debian GNU/Linux
: :' : Free Operating System
`. `'  http://debian.org/
  `-   http://v7w.com/anibal


signature.asc
Description: Digital signature

upload and package

[Pierre Ancelot]

Theoricaly, this shouldn't ever happen but anyways and since it's written, i 
think i be better to tell about it even if i'm certainly wrong on what really 
happened.

After running dpkg-buildpackage -rfakeroot as written on the debian 
maintainer's guide i get this message. it tells me to enter a pass phrase 
which i do. Anyhow my curiosity is piqued by the last line : 
dpkg-buildpackage: binary and diff upload (original source NOT included)

written "upload". If it did, well, i'm not allowed to, and noone had a review 
on the package to please someone tell me i didn't _really_ upload it... (even 
though i didn't modify anything yet in the source.




You need a passphrase to unlock the secret key for
user: "Pierre Ancelot <[EMAIL PROTECTED]>"
1024-bit DSA key, ID 9C2D8B72, created 2005-01-09


 dpkg-genchanges
dpkg-genchanges: not including original source code in upload
 signfile hwtools_0.8-2_i386.changes

You need a passphrase to unlock the secret key for
user: "Pierre Ancelot <[EMAIL PROTECTED]>"
1024-bit DSA key, ID 9C2D8B72, created 2005-01-09


dpkg-buildpackage: binary and diff upload (original source NOT included)
[EMAIL PROTECTED]:~/debian/hwtools-0.8$


pgpTaPgojZGkn.pgp
Description: PGP signature

Re: About creating .deb packages

[martin f krafft]

also sprach Matthew Palmer <[EMAIL PROTECTED]> [2005.01.03.0215 +0100]:
> No idea.  That still feels like an incredibly weird requirement to me, BTW. 
> What's wrong with GNU ar, considering that we use everything else GNU...

Sure; I am not the one with whom to argue.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: About creating .deb packages

[martin f krafft]

also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2005.01.03.1055 +0100]:
> Are you trying to say "You even get an alarm if the malfunction has 
> only hit metadata and no important data yet".

metadata? We are talking about MD5 sums, and yes, it does not really
matter whether the bit flip is in the data or the hash... or can you
tell which one actually changed?

> > md5sums is not supposed to guard against broken
> > hardware, the only cause I see for such bitflips.
> 
> I do not know why you know what it is supposed to do. I also do not
> care what it is supposed to do. I'm concerned what it is useful for.
> And it is definitly useful.

An integrity checker does the job in a better way -- if used
properly. And I would be very happy to hear of a good reason for
debsums other than helping you figure out which files in /usr or
/lib you modified, as the admin -- which you should not do anyway.

> > If the md5sum of the DEB file validates against the Packages index,
> > the package is valid.
> 
> Hurray, downloading all installed .deb's, verifying their md5sum,
> comparing the files against installed versions is still very slow
> on a modern computer connected with 100MBit to the local mirror
> (containing even all obsolete and old versions of installed packages).
> Not to mention the lack of tool to do this automatically...

I am failing to see your point.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: Question about packaging documentation

[Frank Küster]

<[EMAIL PROTECTED]> schrieb:

> So is there any documenation about building non binary packages from scratch?

Just as any architecture-independent package. Why not have a look at one
existing example (apt-cache --names-only search ^doc-).

> I tried with my own Makefile for installing the files and tried out dh_make - 
> but
> then the packages are bulid als _i386.deb ;-) So at first a hint to some doc 
> to 
> read would be nice...

file:///usr/share/doc/debian-policy/policy.html/ch-controlfields.html#s-f-Architecture

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: RFC and RFS: latex-svninfo

[martin f krafft]

also sprach Adrian von Bidder <[EMAIL PROTECTED]> [2005.01.11.1626 +0100]:
> Madduck: you're my sponsor so far - willing to take that, too? (If NM 
> continues in its present pace, I expect my account by the time sarge 
> releases :-)  I'd obviously add you as uploader if you do.

Unless someone takes it on before I return on the 24th, ping me
again...

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


signature.asc
Description: Digital signature

Re: RFC and RFS: latex-svninfo

[Frank Küster]

Adrian von Bidder <[EMAIL PROTECTED]> schrieb:

> On Tuesday 11 January 2005 16.26, you wrote:
>> [not subscribed to tetex-maint, so please cc: me if replying there.]
>
>> I created a quick package of Achim Brucker's svninfo latex Package.
>> 
>
> ... and of course, I have it online. Arrgh!
>
> 

Some comments:

- As it is, the package must go into contrib (Section: contrib/tex),
  because it build-depends on latex2html from non-free. Maybe you can
  get rid of this, by not building the html documentation. 

- you should also call texhash in postrm

- From debian/rules:

build: build-stamp
make

build-stamp:
touch build-stamp

  Shouldn't the make call be in the build-stamp target? This way you'll
  end up with a build-stamp even if make fails.

- you don't install any files in /usr/share/doc...

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: help in chages necessary for rules file( creating .deb packages)

[Chirag Kantharia]

On Wed, Jan 12, 2005 at 02:23:25AM -0800, TIFR students wrote:
|  We are trying to make .deb packages using
| dh_make...it works fine..it creates a template for
| rules filesuppose a source file is a simple c
| program(hello world) what changes should we make in
| the rules file so that the dpkg-buildpackage works
| properly

You could probably lookup some example rules files from a debian
package. Do a:
$ apt-get source 

Do that, for some package, which you're familiar with. Something, you
may have compiled and install from source. You, would find easy to
corelate.

Regards,

-- 
Chirag Kantharia, puggy.symonds.net/~chyrag/



signature.asc
Description: Digital signature

help in chages necessary for rules file( creating .deb packages)

[TIFR students]

 We are trying to make .deb packages using
dh_make...it works fine..it creates a template for
rules filesuppose a source file is a simple c
program(hello world) what changes should we make in
the rules file so that the dpkg-buildpackage works
properly

Please Help!!1




__ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250


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

Question about packaging documentation

[jan.kesten]

Hi all ;-)

At first I'm entirely new on this list (but not to Debian at all) and my name 
is Jan :-)

I looked around quite a lot in google and list archives to find some information
about how to build doc-only packges (all information I found are for building
binary packages). 

What I plan to do: I have some archives of mailing lists and would like to have
debian packages of them (so it can be easier for me to keep them up-to-date
on my computers and I find this could be useful for others).

So is there any documenation about building non binary packages from scratch?
I tried with my own Makefile for installing the files and tried out dh_make - 
but
then the packages are bulid als _i386.deb ;-) So at first a hint to some doc to 
read would be nice...

Cheers,
Jan


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

Re: New upstream packages?

[Steve Langasek]

On Wed, Jan 12, 2005 at 09:29:40AM +0100, Osamu Aoki wrote:
> On Sat, Dec 18, 2004 at 05:32:48PM -0800, Steve Langasek wrote:
> > On Sun, Dec 19, 2004 at 02:48:02AM +0200, Antti-Juhani Kaijanaho wrote:
> > > Like with many other things in Debian, how you do it doesn't matter as
> > > long as you don't break things.  Things that should be considered
> > > include:
> > 
> > >  - Use a -1 Debian revision number for the new upstream release.
> > 
> > >  - Preserve old changelog entries (sounds obvious, but there have been
> > >incidents...)
> > 
> > >  - Add an entry "New upstream release" to the changelog.

> > ... and please note that "New upstream release" is not a change that closes
> > bugs other than wishlist requests *for* the new upstream release; if there
> > are changes *in* the new upstream release that fix reported bugs, please
> > enumerate those changes before closing the bugs in the changelog.

> Noted in CVS version of maint-guide.

> # Describe concisely the changes in the new upstream release that fix
>   reported bugs and close those bugs in the changelog.

> # Describe concisely the changes to the new upstream release by the
>   maintainer that fix reported bugs and close those bugs in the changelog.

Sounds good to me, thanks.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: New upstream packages?

[Osamu Aoki]

On Wed, Dec 22, 2004 at 07:31:22PM -0800, Matt Zimmerman wrote:
> On Mon, Dec 20, 2004 at 09:45:32PM -0500, Erinn Clark wrote:
> 
> > * Brian Nelson <[EMAIL PROTECTED]> [2004:12:18 18:15 -0800]: 
> > 
> > > Did I miss anything?
> > 
> > Yeah, the part where you turn this into a poster to be hung on my wall.
> 
> ...and the unified diff for developers-reference. :-)


This may be another good idea but I already added to CVS version of
maint-guide.

Together with the use of pbuilder and avoiding native package, these are
typical NM issues I think.  OK?

Osamu


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

Re: New upstream packages?

[Osamu Aoki]

On Sat, Dec 18, 2004 at 05:32:48PM -0800, Steve Langasek wrote:
> On Sun, Dec 19, 2004 at 02:48:02AM +0200, Antti-Juhani Kaijanaho wrote:
> > Like with many other things in Debian, how you do it doesn't matter as
> > long as you don't break things.  Things that should be considered
> > include:
> 
> >  - Use a -1 Debian revision number for the new upstream release.
> 
> >  - Preserve old changelog entries (sounds obvious, but there have been
> >incidents...)
> 
> >  - Add an entry "New upstream release" to the changelog.
> 
> ... and please note that "New upstream release" is not a change that closes
> bugs other than wishlist requests *for* the new upstream release; if there
> are changes *in* the new upstream release that fix reported bugs, please
> enumerate those changes before closing the bugs in the changelog.

Noted in CVS version of maint-guide.

# Describe concisely the changes in the new upstream release that fix
  reported bugs and close those bugs in the changelog.

# Describe concisely the changes to the new upstream release by the
  maintainer that fix reported bugs and close those bugs in the changelog.

OK?

Osamu


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

Re: New upstream packages?

[Osamu Aoki]

Hi,
On Sun, Dec 19, 2004 at 02:48:02AM +0200, Antti-Juhani Kaijanaho wrote:
> Like with many other things in Debian, how you do it doesn't matter as
> long as you don't break things.  Things that should be considered
> include:
> 
>  - Use a -1 Debian revision number for the new upstream release.
> 
>  - Preserve old changelog entries (sounds obvious, but there have been
>incidents...)
> 
>  - Add an entry "New upstream release" to the changelog.
> 
>  - Upgrades to the new version should preferably be silent and
>nonintrusive (existing users should not notice the upgrade except by
>discovering that old bugs have been fixed and there perhaps are new
>features)
> 
>  - When an upgrade is necessarily intrusive (eg. it will break existing
>usage), the upgrade must be noisy (a note in README.Debian or other
>documentation is generally not enough; NEWS.Debian note may become
>okay once apt-listchanges with NEWS.Debian support becomes standard
>operating practice)
> 
>  - Existing Debian changes need to be reevaluated; throw away stuff that
>upstream has incorporated (in one form or another) and remember to
>keep stuff that hasn't been incorporated by upstream, unless there is
>compelling reason not to.
> 
> I'm probably forgetting something here.
> 
> It isn't really possible to give comprehensive generally useful
> procedures - the situation dictates what you need to do.  For many
> packages, for small upstream upgrades, uupdate (from devscripts) can
> make all necessary changes.  Even then, you should be cautious and read
> upstream release documentation, lurk in upstream user forums and bug
> tracking systems looking for problem reports, test, test, test and test
> again.

True but these post are good baseline.  I added this to maint-guide CVS.

  
http://www.debian.org/doc/manuals/maint-guide/ch-update.en.html#s-newupstream-real


I think NM needs to know these more than current released maint-guide.

Osamu


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

Re: New upstream packages?

[Osamu Aoki]

On Sat, Dec 18, 2004 at 06:15:10PM -0800, Brian Nelson wrote:
...
> First of all, I'll assume you've skimmed over the source as part of your
> initial packaging.  I usually go through the following steps:
... 
> Did I miss anything?

Pretty good.  I added this and other post to maint-guide.  OK to be
GPLed?

Osamu


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