Re: RFS: php-ssh2, php-geoip (new packages)
OoO En ce milieu de nuit étoilée du vendredi 30 mai 2008, vers 03:51, Sergey B Kirpichev [EMAIL PROTECTED] disait: The licence (2.02) is not suitable for main but for php itself. You should convince upstream to upgrade to 3.01 or to a more common license like GPL. Actually, for php-geoip and php-crack it's 3.0. Is this ok? It needs to be 3.01. Sorry. -- panic (No CPUs found. System halted.\n); 2.4.3 linux/arch/parisc/kernel/setup.c pgpkEru1kWxSU.pgp Description: PGP signature
Re: RFS: gnurobots (updated package)
On Wed, 28 May 2008 15:07:20 +0200 Vincent Bernat [EMAIL PROTECTED] wrote: Please, add a debian/watch file. This allows DEHS to check if updates are available and will provide this information in a few pages. For some odd reason, include/map.h is GPLv3+. You should update debian/copyright to include this information. In the future, you can use licensecheck to help you to check licenses. Your package looks fine otherwise. Hi, I've fixed these problems and re-uploaded it to mentors. Thanks, Bradley Smith -- Bradley Smith [EMAIL PROTECTED] GPG: 0xC718D347 signature.asc Description: PGP signature
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: vfu (updated package)
2008/5/29 Vincent Bernat [EMAIL PROTECTED]: OoO En cette fin de nuit blanche du lundi 26 mai 2008, vers 05:15, William Vera [EMAIL PROTECTED] disait: I am looking for a sponsor for the new version 4.06-5 of my package vfu. Hi William! Hi Vincent You should acknowledge latest NMU. Moreover, bug #470615 is not handled How I can do it? at all. You should not expand yourself shlibs:Depends ! The submitter is telling that you should depend on unzip, bzip2, etc. In fact, is not a bug, because vfu say 'support' for list and read, does not depend on them (unzip, bzip2, etc) for build o run the program. debian/control is updated. At least, README.Debian seems outdated. Done -- No fortunes found Thanks for take a time to review mi package Regards -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-ssh2, php-geoip (new packages)
It needs to be 3.01. Sorry. Ok. Now the php-geoip's license is 3.01: http://pecl.php.net/package/geoip/ http://cvs.php.net/viewvc.cgi/pecl/geoip/geoip.c?revision=1.16view=markup The updated package is now up on mentors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnurobots (updated package)
OoO En ce début d'après-midi nuageux du vendredi 30 mai 2008, vers 14:28, Bradley Smith [EMAIL PROTECTED] disait: Please, add a debian/watch file. This allows DEHS to check if updates are available and will provide this information in a few pages. For some odd reason, include/map.h is GPLv3+. You should update debian/copyright to include this information. In the future, you can use licensecheck to help you to check licenses. Your package looks fine otherwise. I've fixed these problems and re-uploaded it to mentors. Uploaded. Thanks! -- No fortunes found pgpxewyIz8cnW.pgp Description: PGP signature
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: dish
OoO En cette soirée bien amorcée du jeudi 29 mai 2008, vers 22:04, Dimitar Ivanov [EMAIL PROTECTED] disait: Thanks for your suggestions and help. I've resolved all issues and uploaded a new package. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dish - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dish/dish_1.16.1-2.dsc I would be glad if someone uploaded this package for me. Hi Dimitar! Sorry for being picky, but you left configure-stamp target which is useless too since you don't have configure target any more. This is a matter of taste, but I would put config_examples/* in debian/examples instead of config_examples. Moreover, you should fix all lintian warnings (use lintian -viI on .changes). For manual page, you can either use a patch management system or use this snippet in install target of debian/rules: sed -i 's/\B-/\\-/g' debian/dish/usr/share/man/man1/* Check what this command really does before using it in debian/rules. -- I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD I WILL NOT AIM FOR THE HEAD -+- Bart Simpson on chalkboard in episode 8F13 pgp409GZoorrF.pgp Description: PGP signature
Re: RFS: gtk-nodoka-engine
OoO En cette nuit nuageuse du vendredi 30 mai 2008, vers 01:09, Christopher James Halse Rogers [EMAIL PROTECTED] disait: The updated package is now up on mentors. Hi Christopher! I have uploaded your package (and I am now using it too)! Thanks for contributing to Debian. -- die_if_kernel(Kernel gets FloatingPenguinUnit disabled trap, regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c pgpVfUWnFlM3K.pgp Description: PGP signature
Re: RFS: vfu (updated package)
OoO Lors de la soirée naissante du vendredi 30 mai 2008, vers 17:25, William Vera [EMAIL PROTECTED] disait: You should acknowledge latest NMU. Moreover, bug #470615 is not handled How I can do it? You just add a line in debian/changelog with Acknowledge NMU. Some time ago, you had to close the corresponding bug too. This is not longer the case but the developers reference still state to acknowledge NMU. at all. You should not expand yourself shlibs:Depends ! The submitter is telling that you should depend on unzip, bzip2, etc. In fact, is not a bug, because vfu say 'support' for list and read, does not depend on them (unzip, bzip2, etc) for build o run the program. debian/control is updated. Did you upload the new package to mentors? I don't find it. -- BOFH excuse #447: According to Microsoft, it's by design pgpPaiKlogmZs.pgp Description: PGP signature
Re: RFS: vfu (updated package)
Hi 2008/5/30 Vincent Bernat [EMAIL PROTECTED]: OoO Lors de la soirée naissante du vendredi 30 mai 2008, vers 17:25, William Vera [EMAIL PROTECTED] disait: You should acknowledge latest NMU. Moreover, bug #470615 is not handled How I can do it? You just add a line in debian/changelog with Acknowledge NMU. Some time ago, you had to close the corresponding bug too. This is not longer the case but the developers reference still state to acknowledge NMU. Done at all. You should not expand yourself shlibs:Depends ! The submitter is telling that you should depend on unzip, bzip2, etc. In fact, is not a bug, because vfu say 'support' for list and read, does not depend on them (unzip, bzip2, etc) for build o run the program. debian/control is updated. Did you upload the new package to mentors? I don't find it. The package is updated Thanks -- BOFH excuse #447: According to Microsoft, it's by design -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vfu (updated package)
OoO Lors de la soirée naissante du vendredi 30 mai 2008, vers 17:25, William Vera [EMAIL PROTECTED] disait: In fact, is not a bug, because vfu say 'support' for list and read, does not depend on them (unzip, bzip2, etc) for build o run the program. Well, without unzip, vfu is unable to read a zip file. Without tar and gzip, it is not able to read a tar.gz. If you look at wrappers in rx/, you see that they use tar, unzip, etc. Moreover, those wrappers are some security issue. They use predictable name in a world writable directory (/tmp/XX.rx.cache). They should use mktemp based filename instead. -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c pgpPvk7WU6YtZ.pgp Description: PGP signature
Need some tips on building Debian packages
Hi I'm new here. I've been asking around for help on building debian packages. I've been building RPMS for about 1 decade, but never tried to build a Debian package. As preparation, I've read through the New Maintainer's Guide and miscellaneous other web pages. I came in through the Ubuntu door. My friends forwarded some questions to a person in your list, who suggested I ask here. Keep in mind that my background is in RPM building, where the emphasis is on distributing pristine source code. I was initially shocked/dismayed by the Debian approach because the source code gets untarred and fiddled with by the packager. Some of the example guides that people referred me to may have been bad examples--packagers were opening the source directory and liberally applying patches and making changes, and all of those fiddles were getting wrapped up into the one big diff file, making it impossible to figure out who did what. I eventually found out that these were bad examples. At the end of the day, the recommendation for Debian packaging is essentially the same as in RedHat: we are aiming to distribute unchanged source that is patched in a clear and orderly way. There's not much information on how to manage patches in the Debian New Maintainer's Guide, but in section 6.4 it does acknowledge the problem and refers to dpatch. I keep wondering, If the goal is to re-distribute 'pristine' source code and patches, why doesn't Debian discourage users from untarring the sourced code?Why can't you make it so the debian directory is not inside the source tree? One response I've received is that we are not RedHat, try to get over it. I wonder how you do your day-to-day work on building debs? I have followed the dh_make approach of opening the source, and dh_make gives me template files in debian for control, rules and such. I understand completely that all these different files are just doing the same thing as the one big SPEC file does in an rpm framework. After configuring those, I try to do a package build. While testing this out, I realize I've made some mistakes while attempting to revise the Makefile to match the packaging requirements. It appears to me that I have to 1) move the debian directory to a safe place, 2) erase the code tree, 3) untar a fresh copy, 4) copy the debian directory back into the source tree, and 5) start over trying to fix the Makefile. Is that how you do it? One suggestion I receive is to do this work in a directory managed by rcs or subversion. I think that would be fine too, but harder to set up when you just want to quickly build some small package that somebody distributed for, say, RedHat or such. And the Debian diff for the package would then pick up all the rcs files, right? In a test case I was working on, the build failed because of a mismatch between the libtool automake that were used to create the source_orig.tar.gz file and the versions available on the current system. As a result, it was necessary to run autogen.sh in the source directory before trying configure. That process creates a bunch of files that should NOT be included in the Debian diff file, such as changes in config.sub or such, but the Debian package does include those things. In building RPMS, the source code patches are applied, but the output from autogen and configure is not wrapped up into the changes that are packaged. It occurred to me that I could try to work around this by using a build directory that is completely outside of the source code tree. In many packages that use autotools, we've found it convenient to build outside of the source tree and add the --srcdir option to the configure command. This leaves the source completely unchanged. I've not succeeded in doing this while building a Debian package, however, because it seems to always want to build stuff in the source tree itself. In the process of changing that, I've become confused about the sorting of installed files into packages. I'm building library packages and haven't yet mastered the problem of installing the files into debian/tmp and then using package.listing files to specify the files that need to be selected for each Debian package. -- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need some tips on building Debian packages
OoO En cette soirée bien amorcée du vendredi 30 mai 2008, vers 22:07, Paul Johnson [EMAIL PROTECTED] disait: I wonder how you do your day-to-day work on building debs? I have followed the dh_make approach of opening the source, and dh_make gives me template files in debian for control, rules and such. I understand completely that all these different files are just doing the same thing as the one big SPEC file does in an rpm framework. After configuring those, I try to do a package build. While testing this out, I realize I've made some mistakes while attempting to revise the Makefile to match the packaging requirements. It appears to me that I have to 1) move the debian directory to a safe place, 2) erase the code tree, 3) untar a fresh copy, 4) copy the debian directory back into the source tree, and 5) start over trying to fix the Makefile. Is that how you do it? One suggestion I receive is to do this work in a directory managed by rcs or subversion. I think that would be fine too, but harder to set up when you just want to quickly build some small package that somebody distributed for, say, RedHat or such. And the Debian diff for the package would then pick up all the rcs files, right? You can use svn-buildpackage. Or git-buildpackage. I use the latest one even for very small modifications. It is then easy to turn a change into upstream source in a patch in debian/patches. In a test case I was working on, the build failed because of a mismatch between the libtool automake that were used to create the source_orig.tar.gz file and the versions available on the current system. As a result, it was necessary to run autogen.sh in the source directory before trying configure. That process creates a bunch of files that should NOT be included in the Debian diff file, such as changes in config.sub or such, but the Debian package does include those things. In the clean rule of debian/rules, you should just remove those generated files. -- No fortunes found pgp3X08osVflK.pgp Description: PGP signature
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: vfu (updated package)
2008/5/30 Vincent Bernat [EMAIL PROTECTED]: OoO Lors de la soirée naissante du vendredi 30 mai 2008, vers 17:25, William Vera [EMAIL PROTECTED] disait: In fact, is not a bug, because vfu say 'support' for list and read, does not depend on them (unzip, bzip2, etc) for build o run the program. Well, without unzip, vfu is unable to read a zip file. Without tar and gzip, it is not able to read a tar.gz. If you look at wrappers in rx/, you see that they use tar, unzip, etc. should include them in control then? Moreover, those wrappers are some security issue. They use predictable name in a world writable directory (/tmp/XX.rx.cache). They should use mktemp based filename instead. Suggests a patch for this case? thanks -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need some tips on building Debian packages
On Fri, 2008-05-30 at 15:07 -0500, Paul Johnson wrote: Keep in mind that my background is in RPM building, where the emphasis is on distributing pristine source code. I was initially shocked/dismayed by the Debian approach because the source code gets untarred and fiddled with by the packager. Wherever possible, changes should be limited to the debian/ directory. Some of the example guides that people referred me to may have been bad examples--packagers were opening the source directory and liberally applying patches and making changes, and all of those fiddles were getting wrapped up into the one big diff file, making it impossible to figure out who did what. Who did what is in debian/changelog and some patches have attributions and comments. I eventually found out that these were bad examples. At the end of the day, the recommendation for Debian packaging is essentially the same as in RedHat: we are aiming to distribute unchanged source that is patched in a clear and orderly way. There's not much information on how to manage patches in the Debian New Maintainer's Guide, but in section 6.4 it does acknowledge the problem and refers to dpatch. dpatch is only one way - CDBS is another, quilt a third and there are moves afoot for a new source format, based on the quilt model. I keep wondering, If the goal is to re-distribute 'pristine' source code and patches, why doesn't Debian discourage users from untarring the sourced code? users? You mean developers and maintainers? Why can't you make it so the debian directory is not inside the source tree? Actually, there are few good reasons to do that and it causes more trouble than it would be worth IMHO. One response I've received is that we are not RedHat, try to get over it. True. I wonder how you do your day-to-day work on building debs? I have followed the dh_make approach of opening the source, and dh_make gives me template files in debian for control, rules and such. Only use dh_make once per package - there should be no need to ever run dh_make again. After configuring those, I try to do a package build. While testing this out, I realize I've made some mistakes while attempting to revise the Makefile to match the packaging requirements. Wherever possible, pass those changes via variables in debian/rules, not by altering the Makefile. Remember that debian/rules *is* a Makefile. It appears to me that I have to 1) move the debian directory to a safe place, 2) erase the code tree, 3) untar a fresh copy, 4) copy the debian directory back into the source tree, and 5) start over trying to fix the Makefile. Is that how you do it? NO! :-) Use the clean target to get back to the distributed source and dh_clean to get a clean debian directory with just the essential files. One suggestion I receive is to do this work in a directory managed by rcs or subversion. I think that would be fine too, but harder to set up when you just want to quickly build some small package that somebody distributed for, say, RedHat or such. And the Debian diff for the package would then pick up all the rcs files, right? No. Use the relevant tool and these will be skipped - cvs-buildpackage, svn-buildpackage etc. In a test case I was working on, the build failed because of a mismatch between the libtool automake that were used to create the source_orig.tar.gz file and the versions available on the current system. As a result, it was necessary to run autogen.sh in the source directory before trying configure. That process creates a bunch of files that should NOT be included in the Debian diff file, such as changes in config.sub or such, but the Debian package does include those things. Then clean them in the clean target (I've got problems like this in one of my own packages, it can be a bit tricky at times but generated files like those *must* be removed in the clean target.) In building RPMS, the source code patches are applied, but the output from autogen and configure is not wrapped up into the changes that are packaged. Use CDBS and it will do the same for you. It occurred to me that I could try to work around this by using a build directory that is completely outside of the source code tree. No. The solution is to use the autotools support to clean the source and dh_clean to clean the debian temporary files. In many packages that use autotools, we've found it convenient to build outside of the source tree and add the --srcdir option to the configure command. This leaves the source completely unchanged. I've not succeeded in doing this while building a Debian package, however, because it seems to always want to build stuff in the source tree itself. In the process of changing that, I've become confused about the sorting of installed files into packages. I'm building library packages and haven't yet mastered the problem of installing the files into debian/tmp and then
Re: Need some tips on building Debian packages
Le Fri, May 30, 2008 at 03:07:57PM -0500, Paul Johnson a écrit : I keep wondering, If the goal is to re-distribute 'pristine' source code and patches, why doesn't Debian discourage users from untarring the sourced code?Why can't you make it so the debian directory is not inside the source tree? One response I've received is that we are not RedHat, try to get over it. Dear Paul, There are ways to build a package without untarring the source code; they usually work by indicating a path to the .dsc file to programs that will build the binary packages in a chroot, such as pbuilder (or its faster cousin cowbuilder), sbuild, ... But because of the way the .dsc file contains md5sums of the other components of the source package, I do not know an easy procedure to edit the diff.gz patch, or the format '2.0' / '3.0 (quilt)' tar archives that contain the debian directory, and re-generate the .dsc file. (Any hint from other readers of the list?) One possible way to go is simply to work in a clean unpacked source package, regenerate the source package in the parent directory using the -S option of dpkg-buildpackage, and use cowbuilder or sbuild. It is quite fast actually. For long-term work, as you read in many answers, we often use a version control system. For packages one does not maintain, it is increasingly possible to benefit from this approach by using the `debcheckout' command, if the maintainer have published the URL of their repository. If you make a package from scratch, then you will definitely have to work out the clean rule of the debian/rules makefile so that after building the binary packages and running 'fakeroot debian/rules clean', the directory tree is identical to its starting state. This is not the most funny part of the packaging, but workarounds such as the use of chroot building systems or version control systems will allow you to procrastinate it if you want. Lastly, to answer your original question, the possibility to build the source and binary packages from the untarred sources in which the debian dir has been transferred is quite useful when the compilation is time consuming and the bug in the packaging is downstream of it. Have a nice day, and welcome in Debian ! -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need some tips on building Debian packages
Hello, On Fri, 30 May 2008, Paul Johnson wrote: I've been asking around for help on building debian packages. changes, and all of those fiddles were getting wrapped up into the one big diff file, making it impossible to figure out who did what. One possible reason to do this is that the person/machine doing a build from source requires *no* tools other than compilers and make (and the library dependencies). In order to keep track of the patches applied, there has been a suggestion that these patches be kept inside the debian/ directory sorted by topic. (Thereby the size of the .diff.gz is roughly doubled.) A more common approach is to use debian/patches and then have the patches applied using some patch management tool. Note that in this case the build process depends on this patch management tool. And the Debian diff for the package would then pick up all the rcs files, right? dpkg-source (which is called by *-buildpackage) has the -i and -I options to ignore certain files/directories. That process creates a bunch of files that should NOT be included in the Debian diff file, such as changes in config.sub or such, but the Debian package does include those things. You can remove them in the clean target. The rule to remember is that the Debian .diff.gz will *not* track files that are removed from the upstream source during the build process. So you can safely regenerate autogenerated upstream files and then remove them if you do not want these changes to go into the diff. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: sclapp and pytagsfs (updated packages)
Hi debian-mentors, I am looking for someone to sponsor updates to my packages sclapp and pytagsfs. I haven't heard from my earlier sponsor for these packages since over three weeks and 4 emails, hence this request to a wider audience. This update builds the following binary packages which the changes as listed. python-sclapp (0.5.1-2) - framework for Python command-line applications - Re-order license sections in copyright so that the license of bulk of sclapp is right at the beginning. http://mentors.debian.net/debian/pool/main/s/sclapp pytagsfs (0.6.0-2) - maps media files to an arbitrary directory structure - Change Section from python to utils - Patch 01_bug_reporting to set the bug reporting location to Debian and not upstream. - Patch 02_fuse_exceptions to catch any exception and log an error when fuse initialisation fails (like the user is not in the fuse group). http://mentors.debian.net/debian/pool/main/p/pytagsfs Both the packages are lintian clean but for a warning in sclapp which is a non-issue IMO (The NEWS file is installed as changelog and I also retained the older CHANGELOG file in /usr/share/doc/sclapp). There is a new upstream version of sclapp (0.5.2) but it was updated for pytagsfs 0.7 series (but 0.7.0 is still at rc1 and unreleased) and upstream hasn't tested pytagsfs 0.6.0 with sclapp 0.5.2. So I am not updating sclapp to 0.5.2 yet. I update a bunch of packages as a DM (and didn't screw up things yet) and in case you don't mind me uploading sclapp / pytagsfs as a DM please do let me know and I will add a DM-Upload-Allowed: yes I am not subscribed to debian-mentors, please Cc: me on responses. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
RFS: hwinfo (updated package)
Dear mentors, I am looking for a sponsor for the new version 14.17-1 of my package hwinfo. It builds these binary packages: hwinfo - Hardware identification system libhd14- Hardware identification system library libhd14-dev - Hardware identification system library and headers libhd14-doc - Hardware identification system library documentation The package appears to be lintian clean. The upload would fix these bugs: 438700 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/h/hwinfo - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/h/hwinfo/hwinfo_14.17-1.dsc I would be glad if someone uploaded this package for me. Kind regards William Vera -- William Vera [EMAIL PROTECTED] PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
