Re: RFS: lockrun
On Thu, Jul 03, 2008 at 12:52:46PM -0500, Raphael Geissert wrote: What has upstream's response? If you really want the package in Debian but upstream doesn't want to integrate your patches without a good reason you could anyway package it, drop a few lines in debian/README.Debian and look for a sponsor. The upstream told me that my patch was too much hassle and as he didn't understand the implications for other distributions or users he would not accept it and was unwilling to work on an edited version. An uncooperative upstream and my lack of C skills are not a good combination. You are welcome to take over, it's packaging is largely a fait accompli. Thanks, -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
I am dropping my intended maintainership for the `lockrun` package. Details can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461915 You are more than welcome to convert this back from an RFP and claim ownership. The source code is available here: svn://svn.debian.org/collab-maint/deb-maint/lockrun/trunk Thanks, -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Sat, Jun 21, 2008 at 06:14:41PM +0300, George Danchev wrote: A possible problem could arise when users of your source package decide to exemine the source code and call fakeroot debian/rules patch, but there is still modification left (no matter how innocent it is) to be done against the C code during the package build time. This is not very consistent behaviour unless s/he realizes to exemine your rules file more closely and issue the sed line themselves. Can you think of a solution where your command-option.patch and sed modification could be applied by the patch target ? It is possible, and consider it a wishlist. OTOH I would be fine if someone upload it the way it is. This makes sense, I will take a look shortly to see if I can combine these. You are correct, I forgot about that. I believe it would be best to discuss with upstream to provide any decent versioning scheme, which would let you avoid constructing upstream version from the debian version, not that it is bad, it is just not optimal imho ;-) Of course, upstream has responded to my emails now and although he seems a little reluctant to accept my patch, there is still hope yet. -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with get-orig-source and md5sum
On Thu, Jun 19, 2008 at 08:05:31PM -0400, Felipe Sateler wrote:
David Paleino wrote:
---8---
VERSION=$(shell parsechangelog | grep ^Version | awk -F: '{print $$2}' |
cut -d- -f1) REV=$(shell echo $(VERSION) | awk -F~svn '{print $$2}')
GOS_TMP=$(CURDIR)/get-orig-source-tmp
AFAIK, get-orig-source shouldn't rely on other files to do it's job. I have
always hardcoded the version or date to make the checkout from, to ensure that
only debian/rules is used, and that it can be used from anywhere
(eg, ../src/package/debian/rules get-orig-source).
Not in my experience, parsing the changelog seems to be a perfectly reasonable
thing to do. Why duplicate information when it's not necessary?
--
Noah Slater, http://bytesexual.org/nslater
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Fri, May 30, 2008 at 09:31:00PM +0300, George Danchev wrote: Sure, the CDBS magic is fine, although being magic behind the scene could be dangerous sometimes. It is Debian Policy #4.9 which says: The binary target must be all that is necessary for the user to build the binary package(s) produced from this source package. A `must', but `fakeroot debian/rules binary' yields: sed s/@version@/0~20080520/ lockrun.c lockrun.sed.c cc lockrun.sed.c -o lockrun cp lockrun debian/lockrun/usr/bin help2man -N -n a cron job overrun protection utility ./lockrun lockrun.1 help2man: can't get `--help' info from ./lockrun make: *** [common-install-prehook-impl] Error 2 Seems like cdbs magic doesn't cope with that, but you can still save the day: clean:: unpatch common-install-prehook-impl:: patch This is a bug in CDBS, I have reported it as #486848: http://bugs.debian.org/486848 I have added the following line as a temporary workaround: binary-arch binary-indep: build 2) Regenerating source files (the sed line) during the build process could be a weird source of troubles. Next, we end up having one single C file and two ways of modifying it This has been changed so that we generate lockrun.sed.c from lockrun.c instead. I don't really see any problems with this method. 3) No diff.gz found on mentors - probably a native package done by incident ? Yes, sorry about that, my mistake. Fixed now. 4) You can add a watch file, also. The upstream does not use version numbers so a watch file would be pointless. On Fri, May 30, 2008 at 03:20:27PM -0500, Raphael Geissert wrote: By the way, where did you get this line from? Copyright: Copyright 2008, Stephen J. Friedl [EMAIL PROTECTED] I don't see any statement in the .c file that it is copyrighted. And as the file is in public domain, it may actually be possible that there's no copyright at all. Yes, I think you are correct. Removed now. No, blank lines are allowed in the debian/copyright file. What I meant was that I don't know if you should place the extra lines for License: _after_ their usage. It's strange, nothing else. Fixed. debian/patches/command-option.patch: Did you notice the patch is not clean? :) Binary files lockrun-1.orig/lockrun and lockrun-1.orig.new/lockrun differ I have edited the patch and this problem no longer persists. I sent the patch to the upstream and I have not had any reply yet, I sent another reminder today - until such time I have removed my patched changes that alter the case to the `lockrun` command options. The new package has been uploaded, and as a reminder: dget http://mentors.debian.net/debian/pool/main/l/lockrun/lockrun_0~20080520-1.dsc Thanks, -- Noah Slater, http://bytesexual.org/nslater/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Thu, May 29, 2008 at 07:04:30PM -0500, Raphael Geissert wrote: debian/copyright: Debianized-By: Noah Slater [EMAIL PROTECTED] Debianized-Date: Sat, 08 Mar 2008 22:58:05 + You should read the wiki page again now, those have a different name now. Heh, I was the one who made that change to the proposal so I should have picked up on this sooner. Thanks, fixed now. License: PD [...] License: GAP [...] I am not an expert in this, but AFAIK those shouldn't be in separate lines. No, blank lines are allowed in the debian/copyright file. debian/patches/command-option.patch: - else if ( STRMATCH(arg, -T) || STRMATCH(arg, --maxtime)) + else if ( STRMATCH(arg, -t) || STRMATCH(arg, --maxtime)) Is this really needed? I don't think you should be so intrusive. Unless, of course, upstream agrees to make that change and does it at upstream too. Okay, good point. I have contacted the upstream, will wait his response on this. If he rejects my patch, or that part of it, I will remove naturally. debian/rules: include /usr/share/cdbs/1/rules/buildcore.mk That line is useless, as including debhelper.mk already takes care of that. If you include that file before debhelper.mk, not all parts of debhelper are used, as cdbs doesn't know that you are later going to load debhelper.mk Good point, thanks. Fixed. PACKAGE_NAME = lockrun ... Isn't the cdbs-provided var more than enough? or is it bogus? Wow, I had not seen those before, thanks. Fixed. SOURCE_URI=http://www.unixwiz.net/tools/lockrun.c Have you considered using debian/copyright's Original-Source-Location: instead of hard-coding the uri twice? ;-) Yes, I considered this but these two things serve separate purposes. The Original-Source-Location is typically used for the homepage of upstream software whereas the SOURCE_URI in this case is the actual source file. else CC=cc endif Didn't you say make already defines one by default: ? Just strip the 'else' and 'CC=cc' lines. Sorry, I don't understand this bit. My debian/rules doesn't have these lines. rm -f lockrun lockrun.1 better written as $(RM) lockrun lockrun.1 make's default $(RM) already sets -f. rm -fr $(PACKAGE_DIRECTORY) Like above, but also set -r, e.g. $(RM) -r ... What is the value in doing this? As I understand it, this is only used by implicit rules in make and so isn't really useful for this scenario as it's not going to be overridden by anything. Your package still FTBFS twice in a row because of: sed -i s/@version@/$(PACKAGE_VERSION)/ lockrun.c not being reverted. I have fixed this now. The package has been re-uploaded to mentors.debian.net. Thanks, -- Noah Slater - Bytesexual http://bytesexual.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
Hello, Thank you all for the suggestions/comments, etc. On Sun, May 25, 2008 at 10:43:19AM +0300, George Danchev wrote: I'd rather reply with few questions ;-) -- it seems that the command-option.patch is not applied before building stage causing your help2man call to fail, since the binary knows nothing about --help. What is your idea of how to apply (before building) and unapply (on cleaning) that patch? In my debian/rules I have the following line: include /usr/share/cdbs/1/rules/simple-patchsys.mk This should automatically apply and clean the patches. It works on my system. When you debuild it does CDBS not handle patches on your system? I am using version 0.4.52 and my package Build-Depends on cdbs (= 0.4.42). The patch looks quite innocent, but did you forward it upstream? No I hadn't, so thanks for the suggesttion. I have now emailed Stephen J. Friedl with a link, an explantion and a request that he reviews and includes my patch in his version. Also, you should build your package in a clean sid environment (see debootstrap and cowbuilder), which helps identification of missed build-dependencies, like help2man for instance. Erk, shame on me. I should have known this. Fixed now. gpg: signature packet without keyid Yes, very strange indeed. I use two subkeys but this has been no problem for me on my system or in fact for those who have signed my key. I am using gnupg 1.4.6-3 FWIW. On Sun, May 25, 2008 at 10:56:36PM +0100, Neil Williams wrote: ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) CROSSCC=$(DEB_HOST_GNU_TYPE)-gcc else CROSSCC=$(CC) endif $(CROSSCC) $(CFLAGS) lockrun.c -o lockrun I have updated the package to use this. On Sun, May 25, 2008 at 05:59:35PM -0500, Raphael Geissert wrote: You might want to set a default for $(CC) if using that: CC:=cc make already defines one by default: I have not added this line based on your advice. Would you mind taking another look at this package following these changes? Thanks, -- Noah Slater - Bytesexual http://bytesexual.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Tue, May 20, 2008 at 02:46:59PM +0100, Noah Slater wrote: Done, and re-uploaded to mentors.d.o Hey, is there any chance someone could take another look at this please? Many thanks, -- Noah Slater - Bytesexual http://bytesexual.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mutt-meta
On Wed, May 21, 2008 at 08:27:10PM +0800, Vern Sun wrote: It builds these binary packages: mutt-meta - Meta-package for the Mutt Email Client Environment. What does the package do? There is no description here. I'm not a DD, just an interested mutt user FWIW. :) -- Noah Slater - Bytesexual http://bytesexual.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Fri, May 02, 2008 at 10:54:56AM -0500, Raphael Geissert wrote:
Please upload your key to a public keyserver.
Very strange, my key has been uploaded for months.
[EMAIL PROTECTED]: ~ $ gpg --recv-key 0x8FBFCFBF
gpg: requesting key 8FBFCFBF from hkp server subkeys.pgp.net
gpg: key 61D50B88: public key Noah Slater [EMAIL PROTECTED] imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
I had changed it around the time I sent the original email, maybe this effected
it somehow, I'm not sure. Could you try again please?
Please use 0~MMDD instead
I am now using 0~20080520-1
debian/rules:
gcc lockrun.c -o lockrun
Please don't do that, at least call gcc with CFLAGS:
gcc $(CFLAGS) lockrun.c -o lockrun
I have updated this as per Neil Williams suggestion.
debian/control:
Depends: ${shlibs:Depends}
also use ${misc:Depends}
Done.
Btw, linda is no longer in the archive, you should get rid of the linda
overrides (lintian will complain if you keep them).
Oh really? News to me, thanks! Removed.
The package FTBFS twice in a row with the following message:
This happens when CDBS gets confused about the package not being properly
cleaned between building. At least, it works fine for me now. Can you retry?
Please fix those issues.
Done, and re-uploaded to mentors.d.o
Thanks,
--
Noah Slater - Bytesexual http://bytesexual.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: lockrun
Dear mentors, I am looking for a sponsor for my (very small) package lockrun. * Package name: lockrun Version : 1-1 Upstream Author : Stephen J. Friedl [EMAIL PROTECTED] * URL : http://www.unixwiz.net/tools/lockrun.html * License : Public domain Language: : C Section : admin It builds these binary packages: lockrun- cron job overrun protection utility The lockrun utility serves as a protective wrapper around a standard cron job preventing it from overrunning with any previous invocation. The package appears to be lintian clean. The upload would fix these bugs: 461915 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/lockrun - Source repository: deb-src http://mentors.debian.net/debian unstable main - contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/lockrun/lockrun_1-1.dsc I would be glad if someone uploaded this package for me. Thanks, -- Noah Slater - Bytesexual http://bytesexual.org/ signature.asc Description: Digital signature
Re: Easiest way to Debianise a package?
On Fri, Apr 11, 2008 at 06:00:41PM +0200, Ivan Vucica wrote: I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. You should check out the cdbs package which has an autotools helper. As an example, take a look at the rules for my couchdb package: https://svn.berlios.de/wsvn/erlang-pkg/couchdb/trunk/debian/rules?sc=1 At the top I include: include /usr/share/cdbs/1/rules/buildcore.mk include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk This is enough to build a basic autotools package for you automatically. HTH, -- Noah Slater - Debian GNU/Linux http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
