Re: RFS: hatools
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)
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/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)
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
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)
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
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
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)
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)
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
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
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]