Hi, On Sat, Oct 28, 2006, Helge Kreutzmann wrote: > All this in an i386 up to date changeroot, but I doubt it is > architecture specific (can try x86_64 and ppc testing, if needed). > 1. Download gst-plugins0.8 (orig.tar.gz and diff.gz). > 2. Record md5sums: > aab4331c2b134ad935cfdefa380525d4 gst-plugins0.8_0.8.12-5.diff.gz > 4a6c5f5384d148c752311b32c5f9a122 gstreamer0.8_0.8.12.orig.tar.gz > 3. Unpack gstreamer0.8_0.8.12.orig.tar.gz, apply diff.gz and run > debuild. All debs build fine (of course, signing fails).
How do you "apply" the diff? You do use dpkg-source -x, right? > 4. Record md5sums: > 5cad60c0f5b6ae34f92d333b24c4b028 gst-plugins0.8_0.8.12-5.diff.gz > 4a6c5f5384d148c752311b32c5f9a122 gstreamer0.8_0.8.12.orig.tar.gz > As you can see, the diff.gz has a different md5sum. The diff is constructed before the build, so I think you manipulate .diff.gz files incorrectly. When you type "debuild", one of the first things that happens is to build a .diff.gz with dpkg-source -b. This diff might differ with the one you downloaded because the "clean" target is run. You do not need to build the package to reproduce this: 1) apt-get source gst-plugins0.8 (or get the individual files, but make sure you extract with dpkg-source -x) 2) cd unpacked-directory; debclean (or fakeroot debian/rules clean) 3) cd ..; dpkg-source -b <unpacked-directory> You might end up with a slightly different .diff.gz than before; this is common, and while it might be pedantically incorrect, there are cases where this is useful and would be very hard to fix. It was even discussed very recently (on debian-devel@ ISTR) that we change the policy so that the requirement is to have the same diff.gz after two run of the clean targets (and not between an unpack and a run of the clean target). > > 5. Run debuild again. > Now the build fails with: > make[1]: Leaving directory `/debuild/NEU-G/gst-plugins-0.8.12' > patches: debian/patches/20_gst-doc-m4.patch > debian/patches/30_gstcacasink-header-include.patch > debian/patches/50_ladspa-quiet.patch > debian/patches/51_wavpack-big-endian.patch > debian/patches/70_relibtoolize.patch > Trying patch debian/patches/20_gst-doc-m4.patch at level 1...success. > Trying patch debian/patches/30_gstcacasink-header-include.patch at level > 1...success. > Trying patch debian/patches/50_ladspa-quiet.patch at level > 1...0...2...failure. That's presumably another problem, which might be that the package does not clean correctly after build, and that you can't do this: 1) build 2) clean 3) build If this is true, this is a real bug, but not of very important severity either. Since I have some doubts on how you extracted the package, I would prefer if you could confirm which of the problems I described you really have. Bye, -- Loïc Minier <[EMAIL PROTECTED]>
