Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
Dear Mentors, I'm surprised this topic hasn't been covered, as I thought it would be important, at least in some cases. For instance, I'm packaging Compiz 0.8.8, for MATE desktop. This, at least initially, requires a lot of code substitutions, and quite a few file/dir renaming. (ex.: gnome -> mate, gconf -> mateconf, metacity -> marco, etc.) I use a home-brewed migration script to generate actions for that. Now, doing `quilt add files_to_rename new_filenames; mv files_to_rename new_filenames; quilt refresh`, alone, would make a huge, unnecessary patch. I might as well modify the upstream tarball and use that as the orig, which, of course, is not proper. But, if I could rename the files just after patching, and rename back just before unpatching, then I can keep a *much* smaller sized debian/patches/*, and also generally more portable. Unfortunately, use of override_dh_quilt_(un)patch isn't feasible as it would require doing dh $@ --with quilt, which is against '3.0 (quilt)' source package format policy. Trying to do both at the same time; "--with quilt" and "3.0 (quilt)" format, results in dpkg-source --after-build breaking the build process, because the override_dh_quilt_unpatch is never invoked at that stage. Going back to source format 1.0 isn't a desirable option. So, I was doing something like: -- dh $@ --with autoreconf override_dh_auto_configure: [ -f new.c ] || mv orig.c new.c ... dh_auto_configure -- $(confflags) override_dh_clean: [ -f orig.c ] || mv new.c orig.c .. dh_clean -- But, unfortunately, that also breaks when dpkg-source --after-build is invoked, because it skips the rules file, and of so override_dh_clean has no effect to it. Same sad story was covered on this list *months* ago, with no proper solution: http://lists.debian.org/debian-mentors/2012/05/msg00131.html It basically ends with: It's a bug, just use "debuild -tc". This basically just tells dpkg-buildpackage to run `fakeroot debian/rules clean`, before it calls `dpkg-source --after-build`. But has this even been reported as a bug, yet? Shouldn't it be? Meanwhile, I thought I could find a straightforward workaround, in debian/rules itself, as I noticed dh_gencontrol happens right before dpkg-source is invoked, and since I already had an override_dh_gencontrol, I tried to separate my reverse-renaming into a seperate sequence, to be called from both override_dh_clean and the former. Like so: -- pre_unpatch: [ -f orig.c ] || mv new.c orig.c ... override_dh_clean: pre_unpatch dh_clean override_dh_gencontrol: pre_unpatch dh_gencontrol -- $(gencontrol_V_opts) -- But that didn't make the slightest difference. Nor did calling dh_clean (which is overridden to reverse-rename files) from override_dh_gencontrol. Nor with override_dh_builddeb. Nothing of all the aforementioned would allow the reverse-renaming in the debuild process before dpkg-source was invoked. Finally, I found something that works: override_dh_builddeb: pre_unpatch dh_builddeb Shouldn't this be mentioned anywhere? At least in 3.0 (quilt) docs? Is renaming files after patching and before unpatching advised against? Is there a better solution? Best, Jasmine -- 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/CAHbMyCaYNYS=moudvvrxzr9m2zk5m9q-d-hxn9mnnvr8v2f...@mail.gmail.com
Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
Sorry, the subject should've --obviously-- been "Patching, renaming, ..., renaming, unpatching" On Wed, Oct 10, 2012 at 4:27 AM, Jasmine Hassan wrote: > Dear Mentors, > > I'm surprised this topic hasn't been covered, as I thought it would be > important, at least in some cases. > > For instance, I'm packaging Compiz 0.8.8, for MATE desktop. This, at > least initially, requires a lot of code substitutions, and quite a few > file/dir renaming. (ex.: gnome -> mate, gconf -> mateconf, metacity -> > marco, etc.) I use a home-brewed migration script to generate actions > for that. > > Now, doing `quilt add files_to_rename new_filenames; mv > files_to_rename new_filenames; quilt refresh`, alone, would make a > huge, unnecessary patch. I might as well modify the upstream tarball > and use that as the orig, which, of course, is not proper. > But, if I could rename the files just after patching, and rename back > just before unpatching, then I can keep a *much* smaller sized > debian/patches/*, and also generally more portable. > > Unfortunately, use of override_dh_quilt_(un)patch isn't feasible as it > would require doing dh $@ --with quilt, which is against '3.0 (quilt)' > source package format policy. > Trying to do both at the same time; "--with quilt" and "3.0 (quilt)" > format, results in dpkg-source --after-build breaking the build > process, because the override_dh_quilt_unpatch is never invoked at > that stage. Going back to source format 1.0 isn't a desirable option. > > So, I was doing something like: > -- > dh $@ --with autoreconf > > override_dh_auto_configure: > [ -f new.c ] || mv orig.c new.c > ... > dh_auto_configure -- $(confflags) > > override_dh_clean: > [ -f orig.c ] || mv new.c orig.c > .. > dh_clean > -- > But, unfortunately, that also breaks when dpkg-source --after-build is > invoked, because it skips the rules file, and of so override_dh_clean > has no effect to it. > > Same sad story was covered on this list *months* ago, with no proper solution: > http://lists.debian.org/debian-mentors/2012/05/msg00131.html > It basically ends with: It's a bug, just use "debuild -tc". > This basically just tells dpkg-buildpackage to run `fakeroot > debian/rules clean`, before it calls `dpkg-source --after-build`. > But has this even been reported as a bug, yet? Shouldn't it be? > > Meanwhile, I thought I could find a straightforward workaround, in > debian/rules itself, as I noticed dh_gencontrol happens right before > dpkg-source is invoked, and since I already had an > override_dh_gencontrol, I tried to separate my reverse-renaming into a > seperate sequence, to be called from both override_dh_clean and the > former. Like so: > -- > pre_unpatch: > [ -f orig.c ] || mv new.c orig.c > ... > > override_dh_clean: pre_unpatch > dh_clean > > override_dh_gencontrol: pre_unpatch > dh_gencontrol -- $(gencontrol_V_opts) > -- > > But that didn't make the slightest difference. Nor did calling > dh_clean (which is overridden to reverse-rename files) from > override_dh_gencontrol. Nor with override_dh_builddeb. Nothing of all > the aforementioned would allow the reverse-renaming in the debuild > process before dpkg-source was invoked. > > Finally, I found something that works: > > override_dh_builddeb: pre_unpatch > dh_builddeb > > Shouldn't this be mentioned anywhere? At least in 3.0 (quilt) docs? > Is renaming files after patching and before unpatching advised against? > Is there a better solution? > > Best, > Jasmine -- 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/cahbmyczabud27cmfiy4bhydmg3kpbyy7ykpcq6moqatiqs0...@mail.gmail.com
Re: (un)patching patched files
Hi, Has this been reported as a bug yet? The only thing I found to work is: pre_unpatch: [ -f orig.c ] || mv new.c orig.c ... override_dh_clean: pre_unpatch dh_clean # This forces the rename right before dpkg-source --after-build override_dh_builddeb: pre_unpatch dh_builddeb Best, Jasmine -- 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/5074df55.8050...@gmail.com
Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
On Wed, Oct 10, 2012 at 8:49 AM, Raphael Hertzog wrote: > Hi, > > On Wed, 10 Oct 2012, Jasmine Hassan wrote: >> For instance, I'm packaging Compiz 0.8.8, for MATE desktop. This, at >> least initially, requires a lot of code substitutions, and quite a few >> file/dir renaming. (ex.: gnome -> mate, gconf -> mateconf, metacity -> >> marco, etc.) I use a home-brewed migration script to generate actions >> for that. > > Compiz has not been forked but you have to patch it heavily because > Gnome/Gconf/Metacity have been forked? Is that right? > Exactly, and gnome 2.x is no longer maintained, nor is Compiz 0.8.8, last in release 0.8.x from April 2011 It was removed from testing, and unstable is still stuck at 0.8.4-1, way behind the latest in the series from ubuntu, (0.8.6-whatever), and its not longer being maintained in ubuntu either, in favor of 0.9.x which is moving in the direction of unity. so ... no 0.9.x will work for gnome 2.x / MATE > In that case, I truly believe that MATE should fork Compiz as well > and provide clean upstream sources (even if they are automatically > generated by a script that does the renames and all). That's what I'm doing. Wolfgang Ulrich has also done similar, for redhat/fedora http://forums.fedoraforum.org/showthread.php?t=276286 I synced all patches from latest applicable 0.8.6 in ubuntu that still apply to 0.8.8, and debian, and a couple from fedora. I believe my fork is superior to Wolfgang's, though I'm packaging for LMDE (LinuxMint Debian Edition) / Debian Testing (what LMDE is based on). > >> huge, unnecessary patch. I might as well modify the upstream tarball >> and use that as the orig, which, of course, is not proper. > > Why not? In case someone decides to take over maintaining the package in unstable (and that it returns to testing), will collide, and apt-pinning is a pain for LMDE devs/maintainers. > > Were you intending to integrate your work in Debian's official compiz > package? (Somehow I doubt that the maintainer would be interested to > clutter his packaging to accomodate MATE) like i said. it fell out of testing (removed), and unstable hasn't been updated by maintainer since 25 Oct 2011 Couple small NMU's, last being 29 May 2012, and even then it is still at 0.8.4-5.2 Someone needs to take over, obviously? Cheers > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Get the Debian Administrator's Handbook: > → http://debian-handbook.info/get/ -- 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/CAHbMyCaKGudB+aP3Jn6SCqOaU=SgMKuiu6=z8gn5n8fp6wn...@mail.gmail.com
Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
Removed Damyan from the loop, as this no longer concerns his article on renaming files & quilt http://pkg-perl.alioth.debian.org/howto/quilt.html Also check http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648022 I believe unstable should move to 0.9.x, and let me fork 0.8.8 for MATE. I have it running rock solid atm, completely integrated with marco 1.4 (metacity's replacement) as the decorator, and even emerald 0.8.8 as an additional option for decorator. Also, moved to dh compat 7 (was 5) and quilt 3.0. And I made all patches dep3 (added all missing headers/descriptions/authors/origins/urls). Too many to list. On Wed, Oct 10, 2012 at 9:04 AM, Jasmine Hassan wrote: > On Wed, Oct 10, 2012 at 8:49 AM, Raphael Hertzog wrote: >> Hi, >> >> On Wed, 10 Oct 2012, Jasmine Hassan wrote: >>> For instance, I'm packaging Compiz 0.8.8, for MATE desktop. This, at >>> least initially, requires a lot of code substitutions, and quite a few >>> file/dir renaming. (ex.: gnome -> mate, gconf -> mateconf, metacity -> >>> marco, etc.) I use a home-brewed migration script to generate actions >>> for that. >> >> Compiz has not been forked but you have to patch it heavily because >> Gnome/Gconf/Metacity have been forked? Is that right? >> > > Exactly, and gnome 2.x is no longer maintained, nor is Compiz 0.8.8, > last in release 0.8.x from April 2011 > It was removed from testing, and unstable is still stuck at 0.8.4-1, > way behind the latest in the series from ubuntu, (0.8.6-whatever), and > its not longer being maintained in ubuntu either, in favor of 0.9.x > which is moving in the direction of unity. so ... no 0.9.x will work > for gnome 2.x / MATE > >> In that case, I truly believe that MATE should fork Compiz as well >> and provide clean upstream sources (even if they are automatically >> generated by a script that does the renames and all). > > That's what I'm doing. Wolfgang Ulrich has also done similar, for > redhat/fedora http://forums.fedoraforum.org/showthread.php?t=276286 > > I synced all patches from latest applicable 0.8.6 in ubuntu that still > apply to 0.8.8, and debian, and a couple from fedora. I believe my > fork is superior to Wolfgang's, though I'm packaging for LMDE > (LinuxMint Debian Edition) / Debian Testing (what LMDE is based on). > >> >>> huge, unnecessary patch. I might as well modify the upstream tarball >>> and use that as the orig, which, of course, is not proper. >> >> Why not? > > In case someone decides to take over maintaining the package in > unstable (and that it returns to testing), will collide, and > apt-pinning is a pain for LMDE devs/maintainers. > >> >> Were you intending to integrate your work in Debian's official compiz >> package? (Somehow I doubt that the maintainer would be interested to >> clutter his packaging to accomodate MATE) > > like i said. it fell out of testing (removed), and unstable hasn't > been updated by maintainer since 25 Oct 2011 > Couple small NMU's, last being 29 May 2012, and even then it is still > at 0.8.4-5.2 > > Someone needs to take over, obviously? > > Cheers > >> >> Cheers, >> -- >> Raphaël Hertzog ◈ Debian Developer >> >> Get the Debian Administrator's Handbook: >> → http://debian-handbook.info/get/ -- 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/cahbmyczuaszbwdjfs8-pz8j8epo1wrhcfdcwev+28g8lzv-...@mail.gmail.com
Re: Re: Renaming files, patching, renaming files, unpatching, and 3.0(quilt)
Bernhard R. Link writes: With "3.0 (quilt)" there usually is no unpatching (except if you use some explicit options). So if you need to revert the names, that would be done in the clean target instead. But I really do not see the point of renaming files if you want to stick close to the original. Actually, if you're building source package (besides binary), after dpkg-genchanges, `dpkg-source --after-build` unapplies every single patch that was applied. -- Jasmine -- 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/5075bee4.2010...@gmail.com
Re: Re: Renaming files, patching, renaming files, unpatching, and 3.0(quilt)
Thibaut Paumard writes: > Raphaël is right: > - you should try to collaborate with other distributions on a > *single* fork. > - your fork should not be called "compiz", please pick a unique > name, such as compiz-mate or matepiz or whatever > There are no distributions. Only a fork in fedora, and at least one patch (no-more-mate-wm-settings.patch) collides with another I synced/migrated from ubuntu's compiz 0.8.6 series (562027-fix-mateconf-ftbfs.patch). https://bugzilla.redhat.com/show_bug.cgi?id=851800 But I'll try, of course. In addition, but I believe you realize that already, your fork and the > mainstream compiz packages should remain co-installable at all time: > you need to rename/move all files, programs, libraries etc. > > Of course. > As for "unstable should move to 0.9.x", that's entirely up to the > compiz maintainers and the release team. Remember we are in a freeze > period, experimental has 0.9.2.1+git... > > Understandable. But there's still no compiz at all in testing :P > Regards, Thibaut. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCAAGBQJQdSrpAAoJEJOUU0jg3ChABMgQAJtWzOKZVVr4SWHU+o1Haeg9 > vUrlEQ73+rivX06d7s0pLI54jfJsosGStDLB2F3Jhur3Q02/UF3z/+8ofXnshZdT > da8TTgV4KdGFabudiic2iGoVk2P1BUsb7xMQHKeQ3i+Nmv9E+QDBrZEUUhOJLGvB > TY7VRGR3cYlXn8/EyO9fkZz/eUhQIFEhhJ0onIC2HnI5oU9A844uYE4tiKu9WK5r > 8ZIOv8v7Qm+s+hHg4GzCgkzw2/wU/MUN6OXGnMQhH7ewloPfyK906Y+Ec7G/nrJ4 > nm5yeEaaMigS4hBuy9veqRD3bZ/mrA9mU7hkVXs1LzChWx74/oGmkvxSembFYld4 > Pu/d+I4jNH9Xe05Qmnha69Py8SLPOJAV55ryHyI4qgJiPuTXuuQw5wmyeva7vyuj > ZugC4hxGWknyIb/zmUj7wgTNPz50E9Eqh1Tmmq9swYuZh+jmaq0VzSdsfBt45V/x > lCVK53J5LYL8gBCJhoZa++f4E+KM9y9ebGL1FOV0BdVNbGwf9OYFpJEY7oeNUqmW > WDNA9QK6BvgRYXbP1T2YbU8ubpPUIRlPiFHG5sZiFz4YysU86kbmtDElHPaTASlD > 1/gy0e6+QLqD7a7YI6THNd622uIgJ3w0JcqU1MZsZ99/ud2rkMWTRBacER4gPJc5 > R1RNxL13tkR7Lu3fnDB5 > =ST8V > -END PGP SIGNATURE- -- Jasmine
Re: Re: Renaming files, patching, renaming files, unpatching, and 3.0(quilt)
Thibaut, I should add that it is counter-productive and discouraging to fork the entire compiz* family just because we can't get 0.8.8 in unstable, which would allow me to simply bring back compiz-mate package that was dropped by a Non-maintainer (Michael) in 0.8.4-5.1 (the pre-last update, on 27 Jan). Since compiz was dropped in testing, it is so much easier for me to build a vanilla compiz 0.8.8 with compiz-mate, for LMDE's repos. I am not interested in forking all compiz packages and renaming every single file just for Debian. heh I hope you all understand the *practicality* in this. Best, Jasmine On Wed, Oct 10, 2012 at 9:14 PM, Jasmine Hassan wrote: > Thibaut Paumard writes: > >> Raphaël is right: >> - you should try to collaborate with other distributions on a >> *single* fork. >> - your fork should not be called "compiz", please pick a unique >> name, such as compiz-mate or matepiz or whatever >> > > There are no distributions. Only a fork in fedora, and at least one patch > (no-more-mate-wm-settings.patch) collides with another I synced/migrated > from ubuntu's compiz 0.8.6 series (562027-fix-mateconf-ftbfs.patch). > https://bugzilla.redhat.com/show_bug.cgi?id=851800 > But I'll try, of course. > > In addition, but I believe you realize that already, your fork and the >> mainstream compiz packages should remain co-installable at all time: >> you need to rename/move all files, programs, libraries etc. >> >> > Of course. > > >> As for "unstable should move to 0.9.x", that's entirely up to the >> compiz maintainers and the release team. Remember we are in a freeze >> period, experimental has 0.9.2.1+git... >> >> > Understandable. But there's still no compiz at all in testing :P > > >> Regards, Thibaut. >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQIcBAEBCAAGBQJQdSrpAAoJEJOUU0jg3ChABMgQAJtWzOKZVVr4SWHU+o1Haeg9 >> vUrlEQ73+rivX06d7s0pLI54jfJsosGStDLB2F3Jhur3Q02/UF3z/+8ofXnshZdT >> da8TTgV4KdGFabudiic2iGoVk2P1BUsb7xMQHKeQ3i+Nmv9E+QDBrZEUUhOJLGvB >> TY7VRGR3cYlXn8/EyO9fkZz/eUhQIFEhhJ0onIC2HnI5oU9A844uYE4tiKu9WK5r >> 8ZIOv8v7Qm+s+hHg4GzCgkzw2/wU/MUN6OXGnMQhH7ewloPfyK906Y+Ec7G/nrJ4 >> nm5yeEaaMigS4hBuy9veqRD3bZ/mrA9mU7hkVXs1LzChWx74/oGmkvxSembFYld4 >> Pu/d+I4jNH9Xe05Qmnha69Py8SLPOJAV55ryHyI4qgJiPuTXuuQw5wmyeva7vyuj >> ZugC4hxGWknyIb/zmUj7wgTNPz50E9Eqh1Tmmq9swYuZh+jmaq0VzSdsfBt45V/x >> lCVK53J5LYL8gBCJhoZa++f4E+KM9y9ebGL1FOV0BdVNbGwf9OYFpJEY7oeNUqmW >> WDNA9QK6BvgRYXbP1T2YbU8ubpPUIRlPiFHG5sZiFz4YysU86kbmtDElHPaTASlD >> 1/gy0e6+QLqD7a7YI6THNd622uIgJ3w0JcqU1MZsZ99/ud2rkMWTRBacER4gPJc5 >> R1RNxL13tkR7Lu3fnDB5 >> =ST8V >> -END PGP SIGNATURE- > > > -- > Jasmine >
Re: (un)patching patched files
while that worked flawlessly, there might be problems on a subsequent build in the same tree, if you were renaming directories. To fix that, I added (to the aforementioned) an override_dh_autoreconf sequence: post_patch: [ -d src/new-dir ] || mv src/orig-dir src/new-dir override_dh_autoreconf: post_patch dh_autoreconf override_dh_auto_clean: if [ -d src/orig-dir -a -d debian/tmp ]; then debian/rules post_patch; fi dh_auto_clean Hope that helps anyone :) On Wed, Oct 10, 2012 at 4:37 AM, Jasmine Hassan wrote: > Hi, > > Has this been reported as a bug yet? > > The only thing I found to work is: > > pre_unpatch: > [ -f orig.c ] || mv new.c orig.c > ... > > override_dh_clean: pre_unpatch > dh_clean > > # This forces the rename right before dpkg-source --after-build > override_dh_builddeb: pre_unpatch > dh_builddeb > > Best, > Jasmine >
