Bug#554612: /usr/bin/dpkg-source: include-binaries doesn't work
On Thu, 05 Nov 2009, Mike Hommey wrote:
A bit more information. It *hum*hum* works, actually, and the error
message above was due to remaining stuff in
debian/source/include-binaries.
No, it really doesn't work as expected. It works in lenny but doesn't work
properly in sid. I think it might be due to a behavioural difference
in perl's File::Find...
With --include-binaries if you should really get messages like this:
dpkg-source: info: adding debian/test.png to debian/source/include-binaries
and not:
dpkg-source: info: adding ../test.png to debian/source/include-binaries
debian/source/include-binaries should contain paths relative to the root
directory of the source package.
Effectively find() behaves differently but it's also due to a lack of a
parameter that guaranteed that it would not change the current directory.
So it's a bug of dpkg-source and not of File::Find.
That said, it should work for binaries outside of the debian directory as
it's not the same code path and in that case I get proper messages.
Attached is the suggested patch. Tell me if you have other problems.
Cheers,
--
Raphaël Hertzog
diff --git a/scripts/Dpkg/Source/Package/V2.pm
b/scripts/Dpkg/Source/Package/V2.pm
index 613dff9..b7fe76d 100644
--- a/scripts/Dpkg/Source/Package/V2.pm
+++ b/scripts/Dpkg/Source/Package/V2.pm
@@ -349,8 +349,8 @@ sub do_build {
}
return @result;
};
-find({ wanted = $check_binary, preprocess = $filter_ignore },
- File::Spec-catdir($dir, debian));
+find({ wanted = $check_binary, preprocess = $filter_ignore,
+ no_chdir = 1 }, File::Spec-catdir($dir, debian));
error(_g(detected %d unwanted binary file(s) .
(add them in debian/source/include-binaries to allow their .
inclusion).), $unwanted_binaries) if $unwanted_binaries;
Bug#554612: /usr/bin/dpkg-source: include-binaries doesn't work
On Thu, Nov 05, 2009 at 09:04:45PM +0100, Raphael Hertzog wrote: On Thu, 05 Nov 2009, Mike Hommey wrote: A bit more information. It *hum*hum* works, actually, and the error message above was due to remaining stuff in debian/source/include-binaries. No, it really doesn't work as expected. It works in lenny but doesn't work properly in sid. I think it might be due to a behavioural difference in perl's File::Find... With --include-binaries if you should really get messages like this: dpkg-source: info: adding debian/test.png to debian/source/include-binaries and not: dpkg-source: info: adding ../test.png to debian/source/include-binaries debian/source/include-binaries should contain paths relative to the root directory of the source package. Effectively find() behaves differently but it's also due to a lack of a parameter that guaranteed that it would not change the current directory. So it's a bug of dpkg-source and not of File::Find. That said, it should work for binaries outside of the debian directory as it's not the same code path and in that case I get proper messages. Attached is the suggested patch. Tell me if you have other problems. It seems to work properly with the patch. Would you know when this would posible hit unstable ? ;) Thanks, Mike PS: I do wonder, however, how dpkg-source can be *so much* slower than tar -jxf ; diff -ruN (15 seconds for tar and 2 s for diff vs. 3'30 for dpkg-source in quilt mode and 3' in format 1.0) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554612: /usr/bin/dpkg-source: include-binaries doesn't work
On Thu, 05 Nov 2009, Mike Hommey wrote: No, it really doesn't work as expected. It works in lenny but doesn't work properly in sid. I think it might be due to a behavioural difference in perl's File::Find... In fact no, it's a regression that I introduced in 3525f79792cff51757d99d45f51c96a15e6fa779. Attached is the suggested patch. Tell me if you have other problems. It seems to work properly with the patch. Would you know when this would posible hit unstable ? ;) I don't know when we're going to upload the next version, I certainly hope in the next few weeks, it's been 2 months already since the last upload. Note however that you only need the fix to build the source package so you could in theory upload the resulting package... it can be unpacked everywhere (and rebuilt provided that they are not rebuilding the source package). PS: I do wonder, however, how dpkg-source can be *so much* slower than tar -jxf ; diff -ruN (15 seconds for tar and 2 s for diff vs. 3'30 for dpkg-source in quilt mode and 3' in format 1.0) Check Dpkg::Source::Patch::add_diff_*() to understand why. AFAIK it's there that most of the time is spent. It does a manual comparison of both trees with many checks. To verify run: perl -d:Profile /usr/bin/dpkg-source -b yourpackagedir And look at the first lines of prof.out. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554612: /usr/bin/dpkg-source: include-binaries doesn't work
On Thu, Nov 05, 2009 at 10:13:15PM +0100, Raphael Hertzog wrote: On Thu, 05 Nov 2009, Mike Hommey wrote: No, it really doesn't work as expected. It works in lenny but doesn't work properly in sid. I think it might be due to a behavioural difference in perl's File::Find... In fact no, it's a regression that I introduced in 3525f79792cff51757d99d45f51c96a15e6fa779. Attached is the suggested patch. Tell me if you have other problems. It seems to work properly with the patch. Would you know when this would posible hit unstable ? ;) I don't know when we're going to upload the next version, I certainly hope in the next few weeks, it's been 2 months already since the last upload. Note however that you only need the fix to build the source package so you could in theory upload the resulting package... it can be unpacked everywhere (and rebuilt provided that they are not rebuilding the source package). True, I forgot that buildds don't rebuild the source package. PS: I do wonder, however, how dpkg-source can be *so much* slower than tar -jxf ; diff -ruN (15 seconds for tar and 2 s for diff vs. 3'30 for dpkg-source in quilt mode and 3' in format 1.0) Check Dpkg::Source::Patch::add_diff_*() to understand why. AFAIK it's there that most of the time is spent. It does a manual comparison of both trees with many checks. To verify run: perl -d:Profile /usr/bin/dpkg-source -b yourpackagedir And look at the first lines of prof.out. Oh my... %TimeSec. #calls sec/call F name 32.52 69.811044702 0.001562 Dpkg::Source::Patch::add_diff_file 29.95 64.283744829 0.001434 Dpkg::IPC::fork_and_exec 10.22 21.937044829 0.000489 Dpkg::IPC::wait_child 7.14 15.330997591 0.000157 File::Spec::Unix::abs2rel 4.259.1206 585681 0.16 File::Spec::Unix::canonpath forking diff for each file definitely doesn't help here. But that's another story. Cheers, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
