Re: generating patches for debian packages
On Fri, Apr 13, 2007 at 12:47:59AM +0100, Darren Salt wrote: I demand that Kamaraju S Kusumanchi may or may not have written... Now I change somefiles inside foo. How can I easily generate a patch so that I can send it to bts/maintainer etc.,? Currently what I do is unpack You could add a new changelog entry (use dch, or do it manually), then $ debuild $ interdiff -zp1 ../foo_1.2-3.diff.gz ../foo_1.2-3+my-patches.diff.gz | filterdiff -x \*/debian/rules ../foo.patch (Doing this requires devscripts and patchutils.) Did you mean debian/changelog instead of rules in there? I like using debdiff instead of interdiff (less to type): $ apt-get source thingy # this will grab the current .dsc file $ cd thingy-* $ make changes $ dch -n describe changes # this will add a NMU versioned change $ debuild -uc -us # this will build the new package and .dsc $ cd .. $ debdiff $(ls -latr thingy_*.dsc | tail -n -2) thingy_change.debdiff If the source uses tools such as dpatch or quilt then that may not work quite so well - you could use the same tools or you could hack it a bit: patch the source (debian/rules patch or debian/rules apply-patches or something like that), configure it (debian/rules configure) then, BEFORE doing anything else, make a copy of the source tree (hard-linking files is good, so long as your text editor breaks links when saving). Diffing is suddenly easier. I used to get hung up trying to figure out which patch system is in use for a package. Lacking a better way, I wrote a script[1] to try and guess for me. I feel like there should be a simpler way, but it eluded me. :) -Kees [1] http://outflux.net/debian/scripts/what-patch -- Kees Cook@outflux.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Adding quilt to the new maintainer guide.
[Thread broken to avoid thread hijacking] Le Fri, Apr 13, 2007 at 01:48:18AM +0200, Bernd Zeimetz a écrit : a lot of packages already use dpatch or quilt, which makes adding new patches to the build process pretty easy. If they're not used yet - adding the neccessary stuff to debian/rules is well explained in the examples. Have a look into the documentation which ships with the dpatch and quilt packages (dpatch is more simple to handle, but quilt is the better system - YMMV). kunpuu|~|$ ls /usr/share/doc/quilt/ AUTHORS changelog.gz quilt.htmlquilt.quiltrc README.gz TODO changelog.Debian.gz copyright quilt.pdf.gz quilt.txt.gz README.MAIL.gz I never found any documentation on how to use quilt in Debian source pacakges. The reason is of course that it is really simple, but how can we guess the name of the file which plays the role of 00list for dpatch? The man page of quilt is horribly complex and hides the fact that using it in a similar way to dpatch or cdbs is very straightforward. kunpuu|~|$ lynx --dump 'http://wiki.debian.org/?action=fullsearchcontext=180value=quilttitlesearch=Titres' | grep results 0 results of about 7742 pages. (0.18 seconds) Writing quilt in the search box of wiki.d.o and pressing enter gives nothing. (Okay, I relalised later that there is a Search in text button) Nevertheless, I tried quilt this week and I like it a lot. Actually, I find it simpler than dpatch because it is not necessary to convert the patches to a special format. I would like to submit a patch to the new maintainer guide to promote quilt together with dpatch. Shall I send a bug report directly, or shall we discuss the patch on this list before ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding quilt to the new maintainer guide.
Hi Charles, * Charles Plessy [EMAIL PROTECTED] [2007-04-13 12:11]: [Thread broken to avoid thread hijacking] Le Fri, Apr 13, 2007 at 01:48:18AM +0200, Bernd Zeimetz a écrit : a lot of packages already use dpatch or quilt, which makes adding new patches to the build process pretty easy. If they're not used yet - adding the neccessary stuff to debian/rules is well explained in the examples. Have a look into the documentation which ships with the dpatch and quilt packages (dpatch is more simple to handle, but quilt is the better system - YMMV). kunpuu|~|$ ls /usr/share/doc/quilt/ AUTHORS changelog.gz quilt.htmlquilt.quiltrc README.gz TODO changelog.Debian.gz copyright quilt.pdf.gz quilt.txt.gz README.MAIL.gz I never found any documentation on how to use quilt in Debian source pacakges. The reason is of course that it is really simple, but how can we guess the name of the file which plays the role of 00list for dpatch? From man quilt: A file called series contains a list of patch file names that defines the order in which patches are applied. The man page of quilt is horribly complex and hides the fact that using it in a similar way to dpatch or cdbs is very straightforward. kunpuu|~|$ lynx --dump 'http://wiki.debian.org/?action=fullsearchcontext=180value=quilttitlesearch=Titres' | grep results 0 results of about 7742 pages. (0.18 seconds) Writing quilt in the search box of wiki.d.o and pressing enter gives nothing. (Okay, I relalised later that there is a Search in text button) I agree with you that it is quite hard to find online documentation about quilt but imho the manual is pretty good. Nevertheless, I tried quilt this week and I like it a lot. Actually, I find it simpler than dpatch because it is not necessary to convert the patches to a special format. I would like to submit a patch to the new maintainer guide to promote quilt together with dpatch. Shall I send a bug report directly, or shall we discuss the patch on this list before ? I would welcome it to discuss it before since different pacakgers, different packaging :) But I agree, would be cool to have them both in the maintainers guide. Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpsDVzicwRhy.pgp Description: PGP signature
Re: generating patches for debian packages
* Kamaraju S. Kusumanchi: unpack the source again into another temp directory and then use diff -r and then delete the temp directory. But this is time consuming. Is there any easy way? I usually load the Debian package into some version control system prior to making changes. For instance, for GIT, it's: git init git add . git commit -m Import PACKAGE VERSION or something like that. All the working copy is a repository systems (Mercurial, darcs, even RCS) work fine for that purpose. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding quilt to the new maintainer guide.
* Charles Plessy ([EMAIL PROTECTED]) [070413 09:28]: Nevertheless, I tried quilt this week and I like it a lot. Actually, I find it simpler than dpatch because it is not necessary to convert the patches to a special format. I would like to submit a patch to the new maintainer guide to promote quilt together with dpatch. Shall I send a bug report directly, or shall we discuss the patch on this list before ? Actually, we hope to get rid of both quilt and dpatch as recommended utilities as soon as the wp source format is used. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding quilt to the new maintainer guide.
Andreas Barth [EMAIL PROTECTED] writes: * Charles Plessy ([EMAIL PROTECTED]) [070413 09:28]: Nevertheless, I tried quilt this week and I like it a lot. Actually, I find it simpler than dpatch because it is not necessary to convert the patches to a special format. I would like to submit a patch to the new maintainer guide to promote quilt together with dpatch. Shall I send a bug report directly, or shall we discuss the patch on this list before ? Actually, we hope to get rid of both quilt and dpatch as recommended utilities as soon as the wp source format is used. Even if you don't use quilt to apply the patches at build time, using the quilt utilities to construct the patches is still a good idea. I've never seen anything that can manage a set of patches as smoothly and as intuitively as quilt. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding quilt to the new maintainer guide.
* Russ Allbery ([EMAIL PROTECTED]) [070413 20:01]: Even if you don't use quilt to apply the patches at build time, using the quilt utilities to construct the patches is still a good idea. I've never seen anything that can manage a set of patches as smoothly and as intuitively as quilt. Fair enough for me - though that doesn't matter if one starts to use git. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
staying in stable but compiling for sid
Hi all I want to run software only from Stable (ie Etch) when I am doing non-debian related work. However, when I am doing debian related work (ex :- fixing some bugs in the BTS) I want to work in unstable (ex :- compile packages for sid). Is this kind of think possible? The easiest idea is to run two machines one with unstable and one with stable. But I dont have the luxury of running two machines. I also thought of installing 2 Debian versions on the same machine and sharing the /home directory. But I am skeptical about compatibility of rc files across different versions. (Ex:- vim 7's rc files may not work with vim 6's rc files etc.,) Is there any other elegant solution? I have heard about chroot, pbuilder etc., Will they be of any help in this scenario? thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
Hi Kamaraju! On 4/13/07, Kamaraju S Kusumanchi [EMAIL PROTECTED] wrote: Is there any other elegant solution? I have heard about chroot, pbuilder etc., Will they be of any help in this scenario? Yep. I would go with pbuilder. ;-) Best regards, Nelson -- bash: ~/bin/program-to-generate-a-random-signature: No such file or directory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
On Fri, 2007-04-13 at 17:33 -0400, Kamaraju S Kusumanchi wrote: Hi all I want to run software only from Stable (ie Etch) when I am doing non-debian related work. However, when I am doing debian related work (ex :- fixing some bugs in the BTS) I want to work in unstable (ex :- compile packages for sid). Is this kind of think possible? The easiest idea is to run two machines one with unstable and one with stable. But I dont have the luxury of running two machines. I also thought of installing 2 Debian versions on the same machine and sharing the /home directory. But I am skeptical about compatibility of rc files across different versions. (Ex:- vim 7's rc files may not work with vim 6's rc files etc.,) Is there any other elegant solution? I have heard about chroot, pbuilder etc., Will they be of any help in this scenario? Yes, this is what you are looking for. http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot http://www.debian.org/doc/manuals/maint-guide/ch-checkit.en.html#s-pbuilder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
On Fri, Apr 13, 2007 at 05:33:29PM -0400, Kamaraju S Kusumanchi wrote: I want to run software only from Stable (ie Etch) when I am doing non-debian related work. However, when I am doing debian related work (ex :- fixing some bugs in the BTS) I want to work in unstable (ex :- compile packages for sid). Is this kind of think possible? You have several choices here: * Use pbuilder to setup a build environment. heavyweight but simple. * Use chroots for building. simple and well understood. These two choices suffer in that you can't get a graphical environment within them. So if you build a package for sid which used Xorg you couldn't test it. To solve that problem you could look at using something else: * Xen Complex to setup perhaps, but flexible. * Qemu Simple to setup, but may be too slow. Steve -- # Commercial Debian GNU/Linux Support http://www.linux-administration.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
2007/4/13, Steve Kemp [EMAIL PROTECTED]: You have several choices here: * Use pbuilder to setup a build environment. heavyweight but simple. * Use chroots for building. simple and well understood. These two choices suffer in that you can't get a graphical environment within them. So if you build a package for sid which used Xorg you couldn't test it. That's not exactly sure. You'll have a bit overhead but you can start X from a chroot. If you want, you can have a look at this: http://www.miriamruiz.es/code/create_chroot_system.sh Sorry, the explanation I did it in Spanish ( http://www.miriamruiz.es/weblog/?p=23 ) , but it's quite easy looking at the script. Greetings, Miry
Re: staying in stable but compiling for sid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Kemp wrote: On Fri, Apr 13, 2007 at 05:33:29PM -0400, Kamaraju S Kusumanchi wrote: I want to run software only from Stable (ie Etch) when I am doing non-debian related work. However, when I am doing debian related work (ex :- fixing some bugs in the BTS) I want to work in unstable (ex :- compile packages for sid). Is this kind of think possible? You have several choices here: * Use pbuilder to setup a build environment. heavyweight but simple. * Use chroots for building. simple and well understood. These two choices suffer in that you can't get a graphical environment within them. So if you build a package for sid which used Xorg you couldn't test it. You can. Just run an sshd inside the chroot and enable X forwarding on the ssh server sitting inside and the ssh client connecting from outside (from an xterm, of course). Reards, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGIALAGJRwVVqzMkMRAmGRAJ4kFtj6jtRmMjAgPo2QpTAP00WG8ACfdUlx ZrXcDGqPwDg43cPl2hJJHrQ= =b7MW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
On Sat, Apr 14, 2007 at 12:15:48AM +0200, Miriam Ruiz wrote: These two choices suffer in that you can't get a graphical environment within them. So if you build a package for sid which used Xorg you couldn't test it. That's not exactly sure. You'll have a bit overhead but you can start X from a chroot. If you want, you can have a look at this: Sure, I primarily thinking of pbuilder when I wrote that. Sorry! Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
On Fri, Apr 13, 2007 at 11:26:24PM +0100, Steve Kemp wrote: On Sat, Apr 14, 2007 at 12:15:48AM +0200, Miriam Ruiz wrote: These two choices suffer in that you can't get a graphical environment within them. So if you build a package for sid which used Xorg you couldn't test it. That's not exactly sure. You'll have a bit overhead but you can start X from a chroot. If you want, you can have a look at this: Sure, I primarily thinking of pbuilder when I wrote that. Sorry! Wait a minute. You mean that the package has to do more than compile successfully? :-) Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: staying in stable but compiling for sid
Le Fri, Apr 13, 2007 at 06:37:41PM -0300, Nelson A. de Oliveira a écrit : On 4/13/07, Kamaraju S Kusumanchi [EMAIL PROTECTED] wrote: Is there any other elegant solution? I have heard about chroot, pbuilder etc., Will they be of any help in this scenario? Yep. I would go with pbuilder. ;-) Hi all, there is also cowbuilder (in the cowdancer package) which does the same but faster. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
index for maint-guide
Hi I think it would be useful, if we can add an index to the maint-guide. It would be cool if index can be added to other documents such as debian-reference-en, but I am more concerned for developer's documents. I can file a wishlist bug, if necessary. thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding quilt to the new maintainer guide.
* Charles Plessy ([EMAIL PROTECTED]) [070413 09:28]: Nevertheless, I tried quilt this week and I like it a lot. Actually, I find it simpler than dpatch because it is not necessary to convert the patches to a special format. I would like to submit a patch to the new maintainer guide to promote quilt together with dpatch. Shall I send a bug report directly, or shall we discuss the patch on this list before ? Le Fri, Apr 13, 2007 at 07:51:40PM +0200, Andreas Barth a écrit : Actually, we hope to get rid of both quilt and dpatch as recommended utilities as soon as the wp source format is used. Hi, this sounds very interesing, what does wp stand for? Where can we find more information? When it is scheduled to be adopted? In the meantime, patching the NM guide may still be relevant. I will submit the following patch to the BTS, but I would be happy to improve it before with the help of the list. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan --- maint-guide.orig.sgml 2007-04-13 10:16:56.0 +0900 +++ maint-guide.sgml 2007-04-14 11:52:12.0 +0900 @@ -1647,7 +1647,7 @@ debuild /example - sect id=dpatchThe prgndpatch/prgn system + sect id=dpatchThe prgndpatch/prgn and prgnquilt/prgnsystems p The simple use of prgndh_make/prgn and prgndpkg-buildpackage/prgn commands will create a single large @@ -1662,29 +1662,35 @@ /footnote p Several methods for the patch set maintenance have been proposed and are in -use with Debian packages. The prgndpatch/prgn system is one of the +use with Debian packages. The prgndpatch/prgn and prgnquilt/prgn systems are of the simplest of such patch maintenance system proposed. Other ones are dbs, cdbs, etc. p -A package which is packaged properly with the prgndpatch/prgn system +A package which is packaged properly with the prgndpatch/prgn or prgnquilt/prgn systems has modifications to the source clearly documented as a set of -p1 patch files with header in filedebian/patches//file and the source tree is untouched outside of filedebian//file directory. If you are asking a sponsor to upload your package, this kind of clear separation and documentation of your changes are very important to expedite the package review by your -sponsor. The usage method of prgndpatch/prgn is explained in -manref section=1 name=dpatch and -manref section=1 name=dpatch-edit-patch. +sponsor. The usage method of prgndpatch/prgn and prgnquilt/prgn is explained in +manref section=1 name=dpatch, +manref section=1 name=dpatch-edit-patch and +manref section=1 name=quilt. +Both programs provide convenience files to include in filedebian/rulesfile: +file/usr/share/dpatch/dpatch.make/file and +file/usr/share/quilt/quilt.make/file. + p When someone (including yourself) provides you with a patch to the -source later, then the package modification under dpatch is quite +source later, then the package modification is quite simple: list compact itemEdit patch to make it a -p1 patch to the source tree. -itemAdd header using prgndpatch patch-template/prgn command. +itemIn the case of prgndpatch/prgn, add header using prgndpatch patch-template/prgn command. itemDrop it into filedebian/patches/file -itemAdd the dpatch filenames to filedebian/patches/00list/file +itemAdd the patch filenames to filedebian/patches/00list/file (for prgndpatch/prgn) +or filedebian/patches/series/file (for prgnquilt/prgn). /list p Also, prgndpatch/prgn has a capability to make patches architecture
Re: staying in stable but compiling for sid
Hello, On Fri, 13 Apr 2007, Steve Kemp wrote: Sure, I primarily thinking of pbuilder when I wrote that. Sorry! You can use unionfs wth a (pbuilder) chroot to test most things without damaging the pristine nature of the build environment. Secondly you need not run a full-fledged X server unless you are testing some accelerated X features. vncserver for example would be able to test most X-related packages. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: staying in stable but compiling for sid
Kamaraju S Kusumanchi wrote: The easiest idea is to run two machines one with unstable and one with stable. But I dont have the luxury of running two machines. Use vmware/kvm/xen/uml/qemu/whatever... so you can run virtual machines (very small ones should be ok for doing small developments and testings) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
