To early for keysigning (Delaware)?
Yesterday I put my name on the applicant list for the New Maintainer program, and I was wondering: Is it too early to put my name on the Debian Key Signing Coordination Page to start looking for someone to sign my key for the identification phase? And if it's not, and someone reading this is located near Delaware, could you get in contact with me? -- Harry Henry Gebel, ICQ# 76308382 West Dover Hundred, Delaware -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unattandend maintainer(s) - what do I do?
On Mon, Dec 11, 2000 at 01:59:31PM +0100, Michael Moerz wrote: > Just in case that I have detected an unattandend maintainer > who hasn't fixed bugs at least for half a year and never > answeres to direct mails ( have been waiting for an answere > now more than a month ), what should I do? Speak to [EMAIL PROTECTED] -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: NM help: toolchain
On Mon, 11 Dec 2000, Toni Mueller wrote:
> Hello,
Hi Tony,
> I'm in the process of qualifying for a Debian Maintainer and need
> to deliver some working packages. I've done some, but have problems
> understanding how the toolchain works (so my Build-Depends and Depends
> are out of line). Where do these ${shlibs...} et al get set, and how?
> Is there a way to find out short of digging all dh_* scripts up?
> Eg. 'grep -i shlibs: dh_*' doesn't turn up anything, too.
I assume you have read the chapter about shlibs in the Debian Packaging
Manual. Which are the parts you don't understand?
If you want to understand what the debhelper commands do try a
man debhelper
This gives you much information and references to the other debhelper
manual pages.
> Best Regards,
> --Toni++
cu,
Adrian
--
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi
NM help: toolchain
Hello,
I'm in the process of qualifying for a Debian Maintainer and need
to deliver some working packages. I've done some, but have problems
understanding how the toolchain works (so my Build-Depends and Depends
are out of line). Where do these ${shlibs...} et al get set, and how?
Is there a way to find out short of digging all dh_* scripts up?
Eg. 'grep -i shlibs: dh_*' doesn't turn up anything, too.
Best Regards,
--Toni++
Re: MD5 Sums and tarballs
Hello, On Mon, Dec 11, 2000 at 01:53:35PM +0100, Bas Zoetekouw wrote: > > Does the md5 sum of the .orig.tar.gz have to be the same as the one of > > the upstream tarball ? > Aren't the orig.tar.gz's packed with gzip -9? If that is the case, the > md5sum would almost always change, since most upstream developers just > use the default compression. someone gave me a hint that there is varying data in an archive, being a time stamp. A bit of experimenting with gzip, od and sc yields the strong suspicion that the bytes 4-7 (ie, the second long) is the mtime of the original file (ok, this should be restoreable somehow on decompression, so it must be included in the file, no?). Therefore I normally choose to manually apply the patch and then proceed to build the package. Best Regards, --Toni++
Re: MD5 Sums and tarballs
Hi Jérôme! You wrote: > Does the md5 sum of the .orig.tar.gz have to be the same as the one of > the upstream tarball ? Aren't the orig.tar.gz's packed with gzip -9? If that is the case, the md5sum would almost always change, since most upstream developers just use the default compression. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+
unattandend maintainer(s) - what do I do?
Hi! Just in case that I have detected an unattandend maintainer who hasn't fixed bugs at least for half a year and never answeres to direct mails ( have been waiting for an answere now more than a month ), what should I do? I am really interested in fixing that outstanding bugs and I would like to continue that package, but I don't want to steal the package. (I am in the NM queue awaiting DAM approval and account creation) -- kind regards, Michael Moerz
Re: unattandend maintainer(s) - what do I do?
On Mon, Dec 11, 2000 at 01:59:31PM +0100, Michael Moerz wrote: > Just in case that I have detected an unattandend maintainer > who hasn't fixed bugs at least for half a year and never > answeres to direct mails ( have been waiting for an answere > now more than a month ), what should I do? Speak to [EMAIL PROTECTED] -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NM help: toolchain
On Mon, 11 Dec 2000, Toni Mueller wrote:
> Hello,
Hi Tony,
> I'm in the process of qualifying for a Debian Maintainer and need
> to deliver some working packages. I've done some, but have problems
> understanding how the toolchain works (so my Build-Depends and Depends
> are out of line). Where do these ${shlibs...} et al get set, and how?
> Is there a way to find out short of digging all dh_* scripts up?
> Eg. 'grep -i shlibs: dh_*' doesn't turn up anything, too.
I assume you have read the chapter about shlibs in the Debian Packaging
Manual. Which are the parts you don't understand?
If you want to understand what the debhelper commands do try a
man debhelper
This gives you much information and references to the other debhelper
manual pages.
> Best Regards,
> --Toni++
cu,
Adrian
--
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NM help: toolchain
Hello,
I'm in the process of qualifying for a Debian Maintainer and need
to deliver some working packages. I've done some, but have problems
understanding how the toolchain works (so my Build-Depends and Depends
are out of line). Where do these ${shlibs...} et al get set, and how?
Is there a way to find out short of digging all dh_* scripts up?
Eg. 'grep -i shlibs: dh_*' doesn't turn up anything, too.
Best Regards,
--Toni++
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MD5 Sums and tarballs
Hi Jérôme! You wrote: > Does the md5 sum of the .orig.tar.gz have to be the same as the one of > the upstream tarball ? Aren't the orig.tar.gz's packed with gzip -9? If that is the case, the md5sum would almost always change, since most upstream developers just use the default compression. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MD5 Sums and tarballs
Hello, On Mon, Dec 11, 2000 at 01:53:35PM +0100, Bas Zoetekouw wrote: > > Does the md5 sum of the .orig.tar.gz have to be the same as the one of > > the upstream tarball ? > Aren't the orig.tar.gz's packed with gzip -9? If that is the case, the > md5sum would almost always change, since most upstream developers just > use the default compression. someone gave me a hint that there is varying data in an archive, being a time stamp. A bit of experimenting with gzip, od and sc yields the strong suspicion that the bytes 4-7 (ie, the second long) is the mtime of the original file (ok, this should be restoreable somehow on decompression, so it must be included in the file, no?). Therefore I normally choose to manually apply the patch and then proceed to build the package. Best Regards, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unattandend maintainer(s) - what do I do?
Hi! Just in case that I have detected an unattandend maintainer who hasn't fixed bugs at least for half a year and never answeres to direct mails ( have been waiting for an answere now more than a month ), what should I do? I am really interested in fixing that outstanding bugs and I would like to continue that package, but I don't want to steal the package. (I am in the NM queue awaiting DAM approval and account creation) -- kind regards, Michael Moerz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
MD5 Sums and tarballs
Hi, I had many discussions with developers and I still cannot state about the following question: Does the md5 sum of the .orig.tar.gz have to be the same as the one of the upstream tarball ? Some people ofter unpack the upstream tarball and rename the directory so that the latter comply with the Debian Policy. However, this makes the md5sum change. But, in a lot of cases, there are no need for changing the internals of the upstream source. One solution that some gave me is to copy the upstream tarball to the orig.tar.gz and the building process does all the renaming itself. Could some of you give their point of view ? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> http://jerome.marant.free.fr
Mailing list manager packaging issues
Hi, I'm taking over the Sympa mailing list manager with the agreement of its previous maintainer. This mailing list manager comes with a web software that stores archives in the HTML form. My main problem is storing html archives and bounces: I had a deep look into the Debian Policy and the FHS but I didn't find a precise directory where I could store these data. The mailing list manager is storing its data in /var/spool/sympa. Is /var/spool a good place for these ? Do you have any other idea ? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> http://jerome.marant.free.fr
MD5 Sums and tarballs
Hi, I had many discussions with developers and I still cannot state about the following question: Does the md5 sum of the .orig.tar.gz have to be the same as the one of the upstream tarball ? Some people ofter unpack the upstream tarball and rename the directory so that the latter comply with the Debian Policy. However, this makes the md5sum change. But, in a lot of cases, there are no need for changing the internals of the upstream source. One solution that some gave me is to copy the upstream tarball to the orig.tar.gz and the building process does all the renaming itself. Could some of you give their point of view ? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> http://jerome.marant.free.fr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mailing list manager packaging issues
Hi, I'm taking over the Sympa mailing list manager with the agreement of its previous maintainer. This mailing list manager comes with a web software that stores archives in the HTML form. My main problem is storing html archives and bounces: I had a deep look into the Debian Policy and the FHS but I didn't find a precise directory where I could store these data. The mailing list manager is storing its data in /var/spool/sympa. Is /var/spool a good place for these ? Do you have any other idea ? Thanks. -- Jérôme Marant <[EMAIL PROTECTED]> http://jerome.marant.free.fr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
