Re: RFS: hatools

2008-06-23 Thread Igshaan Mesias

Hi

 | On Jun 18, Igshaan Mesias [EMAIL PROTECTED] wrote:
 | 
 |Description : The halockrun program provides a simple way to
 |  implement locking in shell scripts.
 | 
 | What does this offer over lockfile (procmail package) or dotlockfile
 | (liblockfile1 package)?


Aren't those used particularly for mailbox locking? The hatools package
provides a wider application set for locking files.

 Or even flock(1), which is part of util-linux.

The major benefit halockrun has over these tools is that you can't have
stale lock files with its implementation.

It may seems as though a lot of the parameters for procmails lockfile
are just different timeouts to properly handle stale lockfiles.

Since the concept of hatimerun comes from the high-availabity context,
this aspect is very important. The idea (and also the name) of halockrun
as well as for hatimerun comes from the SUN Cluster high availability
product, the implementation also takes reliability very serious.
If you look at dotlockfile manpage, it SEEMS to implement it in a
similar way, but i there's not many timeout parameters, but still seems
to rely on the existence of files, while halockrun actually lock's the
files by kernel functions.

halockrun also works on NFS shares if lockd is running. The node which
hosts the halockrun instance which holds the lock will also take care
not to stale the lock (the kernel again, not the user space). without
having done any deeper checks, ITUMO more robust that dotlockrun.

To point out again I think the strength of halockrun is in its
implementation is that the lock-cleanup is done by the kernel on process
end (no matter how the process ended, it might have had a core-dump) and
not by a user-space procedure. This makes stale locks impossible.

It might appear that both (lockfile and dotlockfile) are aimd for short
living locks  the dotlockfile manpage does not mention anything how it
handles stale locks, but the lockfile_create(3) manpage does. it says
that it might consider a lockfile beeing stale after five minutes. i did
not see how dotlockfile would allow a longer timeout, nor do i know if
dotlockfile uses lockfile_touch() as described in the lockfile_create
manpage.

halockrun was implemented in need to prevent multiple cronjobs running
concurrently. e.g. we had a cronjobs which runns ever 5 minutes, and
_usually_ finishes in less then 5 minutes. if now, we had two jobs
running, doing the same, and each was causing the other be become slower
(more resources required). This again has decreased the chance that the
jobs finish until the next instance will be started by cron. This was
the first application of halockrun. i know some cases where this is even
used for longer running cron-jobs. I unsure whether lockfile or
dotlockfile are suitable tools to use for longer running processes. That
might not complete within an hour.

Further are people using changed start/stop scripts for server processes
like apache or mysqld which are based on halockrun. They start the
process with halockrun, and can check if it still running with halockrun
-t. if they want to send a signal to that process they can also use
halockrun -t to obtain the pid and send a signal (e.g. to stop it
again). Again, this implementation is stale-aware and the lock remains
valid as long as the process is running.

IMHO, the applications of halockrun are also wider then those of the
other two tools mentioned.

Also, lockfile and dotlockfile do not have funtionalilty of hatimerun.
hatimerun was initially required for the cron-job problem. So, If the
job which runs every 5 minutes might take sometimes up to 10 minutes,
there is definitely something wrong if it takes an hour. For that reason
hatimerun was built to kill such processes. hatimerun has the abillity
to send multiple signals, to first ask the process himself to quit, or
later kill it forcefully. In an environment with countless cronjobs,
where sometimes some job just hangs, the hatimerun can make an automatic
recover possible. heh, The importance of hatimerun comes with the fact
that halockrun's locks are not considered stale as long as the process
is not running. Therefore a hanging process could block everything, so
that a reliable timeout is a must. lockfile  dotlockfile also seem to
implement the concept of timeouts, this might reduce the need for a
similar mechanism. howerver, halockrun  hatimerun together make also
sure the the process which belongs to a stale lockfile is killed
(cleaned up) so that other resources occupied by this process are also
freed.

--
Regards
Igshaan Mesias

-- 
View this message in context: 
http://www.nabble.com/RFS%3A-hatools-tp18017206p18063644.html
Sent from the debian-mentors mailing list archive at Nabble.com.


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



Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)

2008-06-23 Thread Magnus Holmgren
On måndagen den 23 juni 2008, George Danchev wrote:
 On Monday 23 June 2008, Cyril Brulebois wrote:
  George Danchev [EMAIL PROTECTED] (22/06/2008):
   In order to shorten my appendix with one line I decided on key ID only
   instead, which is enough for public key diggers.
 
  Even shorter: Sign your mails.

 Bleh 3 words 3 failures ;-) is it really so hard to realize that these
 hints are for people who don't have my public key at hand and want to dig
 it up somehow. 

If you sign your mail, the recipients' mail software can automatically fetch 
the key, like mine does.

 I also disagree that signed mails are shorter, and you would 
 probably that I don't have my secret key at hand any time I post to mailing
 lists. 

The body that we see is shorter. Either way it's not a big deal.

-- 
Magnus Holmgren[EMAIL PROTECTED]
Debian Developer 


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


Re: Updating a package; ediquette and procedure questions

2008-06-23 Thread Siegfried-Angel
2008/6/23 Paul Johnson [EMAIL PROTECTED]:
 2. In Ubuntu, or Debian more generally, what happens when package
 maintainers don't stay up to date?

Ben already answered this point for Debian, so I'll answer it for Ubuntu.

If the package is only in Ubuntu or the version already in Ubuntu is
newer than that one in Debian: file a bug and tag it upgrade. If you
want, update the package yourself, attach the .diff.gz to the bug that
you've filled and subscribe ubuntu-universe-sponsors; also consider
submitting your changes to Debian (in a bug report).

If the same version of the package is in Debian, it is preferred to do
what Ben suggested and wait for Debian to package the new version, but
if the Maintainer is unresponsive (and especially if Feature Freeze is
approaching) just do so yourself as explained above.


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



Re: RFS: ldtp (updated package)

2008-06-23 Thread Kartik Mistry
On Sat, Jun 14, 2008 at 1:00 PM, Vincent Bernat [EMAIL PROTECTED] wrote:
 Hi Kartik!

 You copy config.sub and config.guess from autotools-dev as stated in the
 README.Debian of this package. However, copying those files in the clean
 target changes the diff.gz. Instead,  you might want to add this snippet
 in the config.status target:
snip

Done. Thanks.

 Moreover, you can safely remove CFLAGS settings in debian/rules. This is
 now done by dpkg-buildpackage.

Done. Thanks.

 We  try to  avoid an  uppercased letter  at the  beginning of  the short
 description. This will be difficult to avoid for ldtp package, but maybe
 you might find a way to reword the short description of python-ldtp.

Lintian will warn about spelling mistake if Python is renamed to
python. I have reword other part of short description.

Thanks.

 You  can  also update  Standards-Version  to  3.8.0  which was  released
 recently.

Done.

Updated package can be found at,
http://mentors.debian.net/debian/pool/main/l/ldtp/ldtp_1.1.0-1.dsc

:)

-- 
 Cheers,
 Kartik Mistry | 0xD1028C8D | IRC: kart_
 Blogs: {ftbfs,kartikm}.wordpress.com


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



Fwd: Issue 126 in scim-python: license issue about pinyin_table.txt

2008-06-23 Thread LI Daobing (李道兵)
Dear mentors,

I got a question from the upstream, the source tarball contains GPL
and LGPL code, and this source tarball can generate several packages.
can I release one package in GPL and another in LGPL?

Thanks.


-- Forwarded message --
From:  [EMAIL PROTECTED]
Date: Mon, Jun 23, 2008 at 7:57 AM
Subject: Issue 126 in scim-python: license issue about pinyin_table.txt
To: [EMAIL PROTECTED]


Issue 126: license issue about pinyin_table.txt
http://code.google.com/p/scim-python/issues/detail?id=126

Comment #5 by Shawn.P.Huang:
for 1: thanks. :)
for 2:
Is it possible to create several debian binary packages from signal
tarball, and mark
different debian package with different license? In fedora, I created
several binary
rpms from scim-python tarball with different license. pinyin-table.txt
is needed by
xingma engine, you could put it in xingma package and mark it GPL.
Other parts should
be LGPL. I think fitx only needs the core of scim-python, it does not depend on
xingma engine or other python engines. Do you think this way could
resolve your problem?





--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings



-- 
Best Regards,
 LI Daobing


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



RFS: witty (updated package)

2008-06-23 Thread Pau Garcia i Quiles

Dear mentors,

I am looking for a sponsor for the new version 2.1.3-1
of my package witty.

It builds these binary packages:
witty  - C++ library and application server for web applications [runtime]
witty-dbg  - C++ library and application server for web applications [debug]
witty-dev  - C++ library and application server for web applications [devel]
witty-doc  - C++ library and application server for web applications [doc]

The package appears to be lintian clean.

The upload would fix these bugs: 473096

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/w/witty
- Source repository: deb-src http://mentors.debian.net/debian unstable  
main contrib non-free

- dget http://mentors.debian.net/debian/pool/main/w/witty/witty_2.1.3-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


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



Re: RFS: sshfp - DNS SSHFP records generator

2008-06-23 Thread Maximiliano Curia
Hola Julien Valroff!

El 09/08/2007 a las 12:50 escribiste:
 Dear mentors,
 
 I am looking for a sponsor for my package sshfp.
 
 * Package name : sshfp
   Version  : 1.1.3-1
   Upstream Authors : Paul Wouters [EMAIL PROTECTED] and Jake Appelbaum 
 [EMAIL PROTECTED]
 * URL  : http://www.xelerance.com/software/sshfp/
 * License  : GPL
   Section  : net
 
 It builds these binary packages:
 sshfp  - DNS SSHFP records generator
 
 The package appears to be lintian clean.
 
 The upload would fix these bugs: 413240
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/s/sshfp
 - Source repository: deb-src http://mentors.debian.net/debian unstable main 
 contrib non-free
 - dget http://mentors.debian.net/debian/pool/main/s/sshfp/sshfp_1.1.3-1.dsc

 I would be glad if someone uploaded this package for me.

I had recently being using sshfp, so I believe it would be a useful addition to
the archive. I've made several changes to your package, listed bellow:

- I used the pristine tar.gz, as I don't see any reason not to.
- I had removed the previous contents of debian/changelog, as the pre-debian
  packaging history is of little/no use.
- I removed the patch that replaced © by (c) in the manpage, as manpages now
  support utf-8 encodings.
- I changed packaging from cdbs to dh, as cdbs is too dificult to follow. I
  used dh instead of plain debhelper to keep the debian/rules files small and
  simple. Even though this increased debian/compat to 7. (not really needed,
  but I really don't like cdbs)
- I added dpatch support and dependency. (as a replacement of simplepatchsys)
- I created a patch that fixes some quirks in the Makefile (should be forward
  to upstream).
- I created a patch that fixes some quirks in the manpage (should be forward to
  upstream).
- I changed the debian/copyright file to include the same text as is presented 
in
  the source code.
- I added a debian/watch file (always a good idea to have one).
- I added myself as uploader.
- I added the Homepage: field.
- I upgraded the Standards-Version, no changes needed.

The modified package can be fetch from:
http://maxy.com.ar/debian/sshfp/sshfp_1.1.3-1.dsc

Please review those changes and contact me when you feel that your package is
good to be uploaded.

Thanks,
-- 
UNIX is basically a simple operating system, but you have to be a genius to
understand the simplicity. -- (Dennis Ritchie)
Saludos /\/\ /\  `/


signature.asc
Description: Digital signature


Re: RFS: sshfp - DNS SSHFP records generator

2008-06-23 Thread Julien Valroff
Hi Maximilano,

Le lundi 23 juin 2008 à 14:59 -0300, Maximiliano Curia a écrit :
 Hola Julien Valroff!
 
 El 09/08/2007 a las 12:50 escribiste:
  Dear mentors,
  
  I am looking for a sponsor for my package sshfp.
[...]
  I would be glad if someone uploaded this package for me.
 
 I had recently being using sshfp, so I believe it would be a useful addition 
 to
 the archive. 
I am glad someone is interested in this package.

 I've made several changes to your package, listed bellow:
 
 - I used the pristine tar.gz, as I don't see any reason not to.
The pristine tarball already has a debian/ directory. Keeping it makes
the diff.gz harder to read, but I don't know if there is any consensus
on this point.

I remember having read Daniel Baumann's recommendations [0] when taking
the decision to remove the existing debian/ directory.

 - I had removed the previous contents of debian/changelog, as the pre-debian
   packaging history is of little/no use.
In that case, I totally agree. But it might be a good idea to keep
previous entries in case they are useful to understand current
packaging.

 - I removed the patch that replaced © by (c) in the manpage, as manpages now
   support utf-8 encodings.
great

 - I changed packaging from cdbs to dh, as cdbs is too dificult to follow. I
   used dh instead of plain debhelper to keep the debian/rules files small and
   simple. Even though this increased debian/compat to 7. (not really needed,
   but I really don't like cdbs)
 - I added dpatch support and dependency. (as a replacement of simplepatchsys)
It is a matter of taste, I have nothing against using debhelper. I have
never used dh, but it looks quite nice (I still need to study this
deeper when I have more time)

 - I created a patch that fixes some quirks in the Makefile (should be forward
   to upstream).
 - I created a patch that fixes some quirks in the manpage (should be forward 
 to
   upstream).
great, have you already forwarded these patches?

 - I changed the debian/copyright file to include the same text as is 
 presented in
   the source code.
Maybe this file could be switched to the machine parsable format, what
do you think?

 - I added a debian/watch file (always a good idea to have one).
it is indeed

 - I added myself as uploader.
ok

 - I added the Homepage: field.
Wasn't it already added? I have a version with this field, as well as
the Vcs-* fields - I might have forgotten to upload this new version to
mentors.

I think it would be useful to add these Vcs-* fields once they have
reached a definitive location.

Adding XS-DM-Upload-Allowed: yes would also be a good thing for me if
you don't object to this idea.

 - I upgraded the Standards-Version, no changes needed.
 
 The modified package can be fetch from:
 http://maxy.com.ar/debian/sshfp/sshfp_1.1.3-1.dsc
 
 Please review those changes and contact me when you feel that your package is
 good to be uploaded.
I think everything is great, but still have a doubt about using the
pristine tarball as orig.tar.gz
What do other readers of [EMAIL PROTECTED] think of it?

Would you be interested in co-maintaining this package? Not a lot of
work anyway, but I could then benefit from your experience.

Thanks again for having worked on this package

Cheers,
Julien

[0] http://people.debian.org/~daniel/documents/packaging.html#debian-directory


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



Re: RFS: ldtp (updated package)

2008-06-23 Thread Vincent Bernat
OoO  Peu avant  le début  de l'après-midi  du lundi  23 juin  2008, vers
13:47, Kartik Mistry [EMAIL PROTECTED] disait :

 Updated package can be found at,
 http://mentors.debian.net/debian/pool/main/l/ldtp/ldtp_1.1.0-1.dsc

Uploaded.
-- 
I WILL NOT SKATEBOARD IN THE HALLS
I WILL NOT SKATEBOARD IN THE HALLS
I WILL NOT SKATEBOARD IN THE HALLS
-+- Bart Simpson on chalkboard in episode 7G03


pgp5V7PzBUfYf.pgp
Description: PGP signature


Re: RFS: gnu-standards (updated package. no longer non-free)

2008-06-23 Thread Tim Retout
Hi Kibi,

On Mon, 2008-06-23 at 05:41 +0200, Cyril Brulebois wrote:
 Before that, I'd like you to address the following points:
  - Maybe the Homepage could move from https:// to http://?

Good spot, I didn't think http worked with Savannah.

  - What about making doc-base files less “personal”? You don't really
need to point fingers at the reader and keep using “you” every
sentence. :) Not a high priority thing, but that'd be nice if it were
considered as some point.

Hehe, I've truncated the description of the maintainer's document - the
GNU Coding Standards one wasn't quite so bad, I think.

  - You surely don't need debian/dirs.
  - Nor an empty debian/docs, but see below.
  - Why are you setting SHELL=/bin/bash instead of just not using
bashisms? You could e.g. put the whole file list in debian/docs
instead of using (double) {} constructs in the dh_installdocs call.
  - You could get rid of commented calls in debian/rules as well.
  - Your configure/configure-stamp targets aren't doing anything, why not
deleting them completly?

Yeah, mostly inherited from previous versions of the package - I've now
cleaned debian/rules up, and also removed the 'install' rule which was
looking a bit useless.

  - You could finish the “refresh:” target with an “exit 1” so that you
easily spot that it's getting called (by mistake) during a real
build, because buildds aren't supposed to have net access during the
build.

Hmm, I've removed the refresh rule entirely - there's a description in
debian/copyright for creating the orig tarball. I could create a
get-orig-source rule later, but it would have to fetch from cvs.

  - Did you notice the following? (from lintian)
  E: gnu-standards: doc-base-file-references-missing-file 
 gnu-maintainers-information:24 /usr/share/info/maintain.info.gz
  E: gnu-standards: doc-base-file-references-missing-file 
 gnu-maintainers-information:25 /usr/share/info/maintain.info.gz
  E: gnu-standards: doc-base-file-references-missing-file 
 gnu-coding-standards:24 /usr/share/info/standards.info.gz
  E: gnu-standards: doc-base-file-references-missing-file 
 gnu-coding-standards:25 /usr/share/info/standards.info.gz
After the build, I got: [EMAIL PROTECTED]:/tmp/gnu-standards$ find -name 
 '*.info'
./standards.info
./maintain.info

Oops, debian/gnu-standards.info got missed out of the git commit. The
package on mentors should have been okay, I hope.

  - I had a very quick look at your git history, you may want to use “dch
-t” when modifying the history, so as to get rid of the (IMHO) noisy
trailer line change on every commit. That makes interactive rebase a
bit easier, as well as cherry-picking (although I'm not sure you will
ever need it on this particular package). Of course, if the timestamp
update is intended, feel free to keep doing so, that's just a mere
suggestion. (I'm BTW not using dch -t, but rather dch -a, or manual
modifications to debian/changelog, and only modifying the timestamp,
through dch -r, right before the upload.)

Cool, I'll look at that. Anything that makes changelogs and revision
control nicer is good.

  - You're welcome to target “unstable” if your next upload to mentors
addresses the above points.

Okay, updated at:

http://mentors.debian.net/debian/pool/main/g/gnu-standards/gnu-standards_2008.06.10-1.dsc

Thanks for all the review - I think I need it when I'm packaging at
2am. ;)

-- 
Tim Retout [EMAIL PROTECTED]


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


Re: RFS: unionfs-fuse

2008-06-23 Thread Bernd Schubert
Hallo Kapil,

thanks for your help.

On Saturday 21 June 2008, Kapil Hari Paranjape wrote:
 Hello,

 On Fri, 20 Jun 2008, Bernd Schubert wrote:
  I am looking for a sponsor for my package unionfs-fuse.
 
  http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0.
 9.20-2.dsc

 This should have been:
  -
 http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_20-1
.dsc

sorry my fault. On Friday evening after my first upload I noticed the version 
string was wrong (I created the first internally used package back in last 
September and till Friday evening never noticed the wrong version string).


 The copyright file is buggy:
  - it contains multiple versions of the same lines

Fixed. The generation from copyright.in was bogus.

  - it contains the complete BSD licence instead of refering to
common-licenses

Well, this is a problem. In /usr/share/common-licenses/BSD the first line is

Copyright (c) The Regents of the University of California.
All rights reserved.

I don't see why the University of California should have any rights to the
code. Well, actually they have the right to two of the files we took over 
from BSD, but certainly not to all the others. 
Both licenses are almost identical, but common-licenses/BSD specifically 
is about the *university* license, while ours refers to the real authors.


  - Please comply with section 4.2 of the Maintainer's guide

I tried my best to fulfill these reqirements


 There is no watch file

Thanks, added.


 Is there any chance that unionfs-tools can be used to manage these
 unionfs-fuse file systems?

No, and I doubt it ever will be. We are presently dicussing the optimal way to
implement a control interface, but I don't think there is even the slightest 
chance it will be compatible with the in-kernel unionfs.

I just uploaded a new version:
dget 
http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs-fuse_0.20-2.dsc


Thanks,
Bernd


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



Re: RFS: unionfs-fuse

2008-06-23 Thread Russ Allbery
Bernd Schubert [EMAIL PROTECTED] writes:
 Hallo Kapil,

  - it contains the complete BSD licence instead of refering to
common-licenses

 Well, this is a problem. In /usr/share/common-licenses/BSD the first line is

 Copyright (c) The Regents of the University of California.
 All rights reserved.

 I don't see why the University of California should have any rights to
 the code. Well, actually they have the right to two of the files we took
 over from BSD, but certainly not to all the others.  Both licenses are
 almost identical, but common-licenses/BSD specifically is about the
 *university* license, while ours refers to the real authors.

You're correct.  You can only use /usr/share/common-licenses/BSD for code
that's actually owned by the Regents of the University of California, not
for other code licensed under the same license.

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/


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