Re: Using Quilt with a new package
Hi everyone, Thanks for all your help. I think that right now the easiest way for me is to handle the modifications by hand as they are not very difficult to manage (just comment out one line in the SQL file). Neverthless, what I wanted is to do this automatically for me :). I will try it again with Quilt 3.0 and see if I can achieve what I want. Thanks for your help, Daniel On Wed, Nov 3, 2010 at 16:45, Goswin von Brederlow wrote: > Scott Howard writes: > >> On Wed, Nov 3, 2010 at 3:00 AM, Charles Plessy wrote: >>> Le Tue, Nov 02, 2010 at 01:02:25PM +0100, Daniel Lombrańa González a écrit : After that, I kept reading about git-buildpackage and it seems that it should be more easy to maintain those differences between the upstream version and the deb one using patches. However, I don't know how I have to do this, as I have been trying it out, and as far as I have get is to create the debian/patches folder (using gbp-pq) with a patch that removes that instruction. However, when building the package using git-buildpackage in the master branch (not in patch-queue/master) the resulting package does not have applied the patch, which is wrong. Is it possible to apply automatically those patches when building the package? (FYI I have tried the 3.0 version, and I don't get it working either, probably because I'm doing something wrong). >>> >> >> Paul is right, it's best to get upstream to make a change so you don't >> need patches, but in case they don't the easiest way is to use source >> 3.0 (quilt) format [1]. That should automatically apply and keep track >> of packages for you with no need to change rules files or add depends. >> >> I don't know what problem you're having, but the following command: >> mkdir debian/source ; echo '3.0 (quilt)' > debian/source/format >> >> would create a file named "format" in debian/source in your package. >> The content of the file should be '3.0 (quilt)'. Now you should just >> use quilt normally. >> >> For example >> quilt new my_new_patch.patch >> quilt add src/file_i_want_to_change.c >> [edit the file] >> quilt refresh > > That won't work, at least not the verry first time. The verry first time > you need to use 'QUILT_PATCHES=debian/patches quilt ...'. When you > unpack a source with dpkg-source it does this for you. > > > An alternative way to create a new patch and from my point of view > easier is to > > - just edit files > > - debuild / dpkg-buildpackage till you are happy > + creates debian/patches/debian-changes-version > > - quilt rename [-P debian-changes-version] my-cool-new-feature.patch > > - $EDITOR debian/patches/my-cool-new-feature.patch > + add patch description to the premade header > >> you now should have your patch in debian/patches along with a file >> named "series" in debian/patches that contains the name of your patch. >> >> You can find better how tos on the internet, but that should be it. >> >> [1] http://wiki.debian.org/Projects/DebSrc3.0 > > And if you want to have patches unapplied add "unapply-patches" to > debian/source/local-options. > > MfG > Goswin > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/87iq0eif7m@frosties.localdomain > > -- ·· http://jarifa.unex.es/ http://www.flickr.com/photos/teleyinex ·· Por favor, NO utilice formatos de archivo propietarios para el intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT, CSV o cualquier otro que no obligue a utilizar un programa de un fabricante concreto para tratar la información contenida en él. ··
Re: Using Quilt with a new package
Scott Howard writes: > On Wed, Nov 3, 2010 at 3:00 AM, Charles Plessy wrote: >> Le Tue, Nov 02, 2010 at 01:02:25PM +0100, Daniel Lombraña González a écrit : >>> >>> After that, I kept reading about git-buildpackage and it seems that it >>> should be more easy to maintain those differences between the upstream >>> version and the deb one using patches. However, I don't know how I >>> have to do this, as I have been trying it out, and as far as I have >>> get is to create the debian/patches folder (using gbp-pq) with a patch >>> that removes that instruction. However, when building the package >>> using git-buildpackage in the master branch (not in >>> patch-queue/master) the resulting package does not have applied the >>> patch, which is wrong. Is it possible to apply automatically those >>> patches when building the package? (FYI I have tried the 3.0 version, >>> and I don't get it working either, probably because I'm doing >>> something wrong). >> > > Paul is right, it's best to get upstream to make a change so you don't > need patches, but in case they don't the easiest way is to use source > 3.0 (quilt) format [1]. That should automatically apply and keep track > of packages for you with no need to change rules files or add depends. > > I don't know what problem you're having, but the following command: > mkdir debian/source ; echo '3.0 (quilt)' > debian/source/format > > would create a file named "format" in debian/source in your package. > The content of the file should be '3.0 (quilt)'. Now you should just > use quilt normally. > > For example > quilt new my_new_patch.patch > quilt add src/file_i_want_to_change.c > [edit the file] > quilt refresh That won't work, at least not the verry first time. The verry first time you need to use 'QUILT_PATCHES=debian/patches quilt ...'. When you unpack a source with dpkg-source it does this for you. An alternative way to create a new patch and from my point of view easier is to - just edit files - debuild / dpkg-buildpackage till you are happy + creates debian/patches/debian-changes-version - quilt rename [-P debian-changes-version] my-cool-new-feature.patch - $EDITOR debian/patches/my-cool-new-feature.patch + add patch description to the premade header > you now should have your patch in debian/patches along with a file > named "series" in debian/patches that contains the name of your patch. > > You can find better how tos on the internet, but that should be it. > > [1] http://wiki.debian.org/Projects/DebSrc3.0 And if you want to have patches unapplied add "unapply-patches" to debian/source/local-options. MfG Goswin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq0eif7m@frosties.localdomain
Re: Using Quilt with a new package
On Wed, Nov 3, 2010 at 3:00 AM, Charles Plessy wrote: > Le Tue, Nov 02, 2010 at 01:02:25PM +0100, Daniel Lombraña González a écrit : >> >> After that, I kept reading about git-buildpackage and it seems that it >> should be more easy to maintain those differences between the upstream >> version and the deb one using patches. However, I don't know how I >> have to do this, as I have been trying it out, and as far as I have >> get is to create the debian/patches folder (using gbp-pq) with a patch >> that removes that instruction. However, when building the package >> using git-buildpackage in the master branch (not in >> patch-queue/master) the resulting package does not have applied the >> patch, which is wrong. Is it possible to apply automatically those >> patches when building the package? (FYI I have tried the 3.0 version, >> and I don't get it working either, probably because I'm doing >> something wrong). > Paul is right, it's best to get upstream to make a change so you don't need patches, but in case they don't the easiest way is to use source 3.0 (quilt) format [1]. That should automatically apply and keep track of packages for you with no need to change rules files or add depends. I don't know what problem you're having, but the following command: mkdir debian/source ; echo '3.0 (quilt)' > debian/source/format would create a file named "format" in debian/source in your package. The content of the file should be '3.0 (quilt)'. Now you should just use quilt normally. For example quilt new my_new_patch.patch quilt add src/file_i_want_to_change.c [edit the file] quilt refresh you now should have your patch in debian/patches along with a file named "series" in debian/patches that contains the name of your patch. You can find better how tos on the internet, but that should be it. [1] http://wiki.debian.org/Projects/DebSrc3.0 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=oxuwkeds8a=gwd2irxa+jtp4j4vsax7r3u...@mail.gmail.com
Re: Using Quilt with a new package
Le Tue, Nov 02, 2010 at 01:02:25PM +0100, Daniel Lombraña González a écrit : > > After that, I kept reading about git-buildpackage and it seems that it > should be more easy to maintain those differences between the upstream > version and the deb one using patches. However, I don't know how I > have to do this, as I have been trying it out, and as far as I have > get is to create the debian/patches folder (using gbp-pq) with a patch > that removes that instruction. However, when building the package > using git-buildpackage in the master branch (not in > patch-queue/master) the resulting package does not have applied the > patch, which is wrong. Is it possible to apply automatically those > patches when building the package? (FYI I have tried the 3.0 version, > and I don't get it working either, probably because I'm doing > something wrong). Dear Daniel, If you would like the quilt patches in debian/patches to be applied at build time and unapplied at clean time, you can have a look at the quilt make command for CDBS in /usr/share/cdbs/1/rules/patchsys-quilt.mk or Debhelper's dh --with quilt. By ‘quilt patches’ I mean that they will need to be listed in debian/patches/series. There is an even simpler solution, /usr/share/cdbs/1/rules/simple-patchsys.mk, but it is deprecated (which makes me sad). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101103070026.ge20...@merveille.plessy.net
Re: Using Quilt with a new package
It seems like you could simply get upstream to split installation instructions out into README.install or similar and not have to worry about patching systems. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinjwnorcsjamkjmlkzm6k=tneftk3hn6cncx...@mail.gmail.com
Using Quilt with a new package
Dear all, I'm creating a new deb package for the software Jarifa ( http://jarifa.unex.es), and I'm wondering when I should use quilt and git-buildpackage to modify at least as possible the upstream version of Jarifa files. Let me explain. Jarifa has a SQL file that by default creates the DB in MySQL. Nevertheless, in the deb package this is managed by dbconfig-common, so I have to remove the instruction of creating the DB in the SQL file. Right now I have done this, by creating a new git repository and modify the source code by hand. After that, I kept reading about git-buildpackage and it seems that it should be more easy to maintain those differences between the upstream version and the deb one using patches. However, I don't know how I have to do this, as I have been trying it out, and as far as I have get is to create the debian/patches folder (using gbp-pq) with a patch that removes that instruction. However, when building the package using git-buildpackage in the master branch (not in patch-queue/master) the resulting package does not have applied the patch, which is wrong. Is it possible to apply automatically those patches when building the package? (FYI I have tried the 3.0 version, and I don't get it working either, probably because I'm doing something wrong). Thanks in advance, Daniel -- ·· http://jarifa.unex.es/ http://www.flickr.com/photos/teleyinex ·· Por favor, NO utilice formatos de archivo propietarios para el intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT, CSV o cualquier otro que no obligue a utilizar un programa de un fabricante concreto para tratar la información contenida en él. ··
