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
Noah Slater wrote: 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 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. Thanks, Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Wednesday 18 June 2008, Noah Slater wrote: --cut-- Hello, and sorry for the late reply, 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 Sure. I have added the following line as a temporary workaround: binary-arch binary-indep: build Fine. 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. 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. 3) No diff.gz found on mentors - probably a native package done by incident ? Yes, sorry about that, my mistake. Fixed now. OK. 4) You can add a watch file, also. The upstream does not use version numbers so a watch file would be pointless. 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 ;-) -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- 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: 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
On Thursday 29 May 2008, Noah Slater wrote: Hello, Thank you all for the suggestions/comments, etc. Hello, 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). 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 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 (patch and sed ;-) -- readers won't be impressed by that ;-) If you really need that version substitution I suggest to approach the upstream to introduce a date/version variable which could be rolled by their $VCS of choice or the very developers themselves if no $VCS is being involved. 3) No diff.gz found on mentors - probably a native package done by incident ? 4) You can add a watch file, also. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
Noah Slater wrote: On Thu, May 29, 2008 at 07:04:30PM -0500, Raphael Geissert wrote: debian/copyright: 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. 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. 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. 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 debian/rules: else CC=cc endif ... My debian/rules doesn't have these lines. The one I downloaded from mentors.d.n to review _had_ those 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. I tend to prefer the usage of $(RM). It is not a requirement, though. 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. You could simply revert the sed call in clean, rather than creating a second file, but... :) The package has been re-uploaded to mentors.debian.net. As George Danchev, did you notice that you built the source package as a native one? Thanks, Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- 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
Hi there, Noah Slater wrote: ... Would you mind taking another look at this package following these changes? 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. License: PD In the public domain. License: GAP Copying and distribution of this package, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. I am not an expert in this, but AFAIK those shouldn't be in separate lines. Example: Files: debian/* Copyright: Copyright 2008, Noah Slater [EMAIL PROTECTED] License: GAP Copying and distribution of this package, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. 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. 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 PACKAGE_NAME = lockrun ... Isn't the cdbs-provided var more than enough? or is it bogus? 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? ;-) else CC=cc endif Didn't you say make already defines one by default: ? Just strip the 'else' and 'CC=cc' 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 ... Your package still FTBFS twice in a row because of: sed -i s/@version@/$(PACKAGE_VERSION)/ lockrun.c not being reverted. Thanks, Please fix those issues. Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Saturday 24 May 2008, Noah Slater wrote: 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? Hey Noah, 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 ? The patch looks quite innocent, but did you forward it upstream ? 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. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
Neil Williams wrote: Just re-reading what you said: ... CC=cc endif That will cause troubles when using CC=gcc-4.3 dpkg-buildpackage (for example in i386, where 4.3 is not the default gcc). Something like CC=$(CC) should be used (the intention is to preserve the original $(CC), but of course that line won't work). Something like: ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) OURCC=$(DEB_HOST_GNU_TYPE)-$(CC) else OURCC=$(CC) endif $(OURCC) $(CFLAGS) lockrun.c -o lockrun Maybe someone with more knowledge of make could provide some feedback. Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
Noah Slater wrote: 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? $ gpg --verbose --recv-key 0x8FBFCFBF gpg: requesting key 8FBFCFBF from hkp server pgp.mit.edu gpgkeys: key 8FBFCFBF not found on keyserver gpg: no valid OpenPGP data found. gpg: Total number processed: 0 $ gpg --verbose --keyserver hkp://subkeys.pgp.net --recv-key 0x8FBFCFBF gpg: requesting key 8FBFCFBF from hkp server subkeys.pgp.net gpg: armor header: Version: SKS 1.0.10 gpg: pub 4096R/61D50B88 2008-02-06 Noah Slater [EMAIL PROTECTED] gpg: key 61D50B88: invalid subkey binding gpg: using PGP trust model gpg: key 61D50B88: public key Noah Slater [EMAIL PROTECTED] imported gpg: signature packet without keyid ... strange :-/ ... I haven't checked your new package, waiting your reply to George Danchev's message. Btw, IANADD. Thanks, Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Sun, 2008-05-25 at 16:37 -0500, Raphael Geissert wrote: Neil Williams wrote: Just re-reading what you said: ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) CC=$(DEB_HOST_GNU_TYPE)-gcc else CC=cc endif $(CC) $(CFLAGS) lockrun.c -o lockrun ... CC=cc endif That will cause troubles when using CC=gcc-4.3 dpkg-buildpackage (for example in i386, where 4.3 is not the default gcc). Something like CC=$(CC) should be used (the intention is to preserve the original $(CC), but of course that line won't work). Something like: ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) OURCC=$(DEB_HOST_GNU_TYPE)-$(CC) else OURCC=$(CC) endif $(OURCC) $(CFLAGS) lockrun.c -o lockrun OUR is the wrong prefix, CROSSCC is probably better. 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 You might want to set a default for $(CC) if using that: CC:=cc -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: RFS: lockrun
Neil Williams wrote: On Sun, 2008-05-25 at 16:37 -0500, Raphael Geissert wrote: $(OURCC) $(CFLAGS) lockrun.c -o lockrun OUR is the wrong prefix, CROSSCC is probably better. The thing is that it is not always used for cross compiling, so I don't think CROSSCC is the best name either. Seems like we are lacking ideas here :) ... You might want to set a default for $(CC) if using that: CC:=cc make already defines one by default: 8---8 $ cat cc.mk foo: echo $(CC) $ make -f cc.mk foo echo cc cc 8---8 Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- 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: 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: RFS: lockrun
Noah Slater wrote:
...
- dget
http://mentors.debian.net/debian/pool/main/l/lockrun/lockrun_1-1.dsc
$ dget -x
http://mentors.debian.net/debian/pool/main/l/lockrun/lockrun_1-1.dsc
dget: retrieving
http://mentors.debian.net/debian/pool/main/l/lockrun/lockrun_1-1.dsc
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
100 1768 100 17680 0 5471 0 --:--:-- --:--:-- --:--:--
0
dget: retrieving
http://mentors.debian.net/debian/pool/main/l/lockrun/lockrun_1.orig.tar.gz
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
100 2897 100 28970 0 7315 0 --:--:-- --:--:-- --:--:--
253k
dget: retrieving
http://mentors.debian.net/debian/pool/main/l/lockrun/lockrun_1-1.diff.gz
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
100 2537 100 25370 0 2610 0 --:--:-- --:--:-- --:--:--
13146
gpg: Signature made Fri 02 May 2008 07:50:49 CDT using RSA key ID 8FBFCFBF
gpg: Can't check signature: public key not found
dpkg-source: extracting lockrun in lockrun-1
dpkg-source: info: unpacking lockrun_1.orig.tar.gz
dpkg-source: info: applying lockrun_1-1.diff.gz
$ gpg --recv-key 0x8FBFCFBF
gpg: requesting key 8FBFCFBF from hkp server pgp.mit.edu
gpgkeys: key 8FBFCFBF not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
Please upload your key to a public keyserver.
Version: 1-1
I don't see any version number in the source code. Please use 0~MMDD
instead (where MMDD is the download date, or if possible, the
modification date of upstream's .c file), just in case upstream decides to
use version numbers at some point, if ever.
debian/rules:
gcc lockrun.c -o lockrun
Please don't do that, at least call gcc with CFLAGS:
gcc $(CFLAGS) lockrun.c -o lockrun
debian/control:
Depends: ${shlibs:Depends}
also use ${misc:Depends}
Btw, linda is no longer in the archive, you should get rid of the linda
overrides (lintian will complain if you keep them).
The package FTBFS twice in a row with the following message:
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/tmp/lockrun-1'
make[1]: Nothing to be done for `reverse-config'.
make[1]: Leaving directory `/tmp/lockrun-1'
if [ reverse-patches = reverse-patches ]; then rm -f
debian/stamp-patched; fi
patches: debian/patches/command-option.patch
Trying reverse patch debian/patches/command-option.patch at level 1 ...
0 ... 2 ... failure.
make: *** [reverse-patches] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit
status 2
Please fix those issues.
I would be glad if someone uploaded this package for me.
Thanks,
Cheers,
--
Atomo64 - Raphael
Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Fri, 2008-05-02 at 10:54 -0500, Raphael Geissert wrote: debian/rules: gcc lockrun.c -o lockrun Please don't do that, at least call gcc with CFLAGS: gcc $(CFLAGS) lockrun.c -o lockrun Use the proper DEB_HOST_GNU_TYPE variable too so that the package can be cross-built (and use the cc symlink instead of gcc). ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) CC=$(DEB_HOST_GNU_TYPE)-gcc else CC=cc endif $(CC) $(CFLAGS) lockrun.c -o lockrun -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
