[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]



Hi Vincent,

I've removed bzr from the build dependencies.

After fiddling with the get-orig-source a bit, I realized that I can't get the same checksum either when running it multiple times. According to a 'diff' of 'tar -tvf' output, the only difference between these generated tarballs was the source files' timestamps. This is probably because bzr is used to fetch the sources every time get-orig-source is ran, and it saves the current time (of checkout) as the timestamp of the files, instead of the code's modification date. For this, there appears to be a wishlist bug filed: https://bugs.launchpad.net/bzr/+bug/245170

Best,
James

On 07/06/15 11:17 PM, Vincent Cheng wrote:
Hi James,

(Sorry for the late reply!)

On Tue, May 19, 2015 at 11:28 AM, James Lu <GLolol1@hotmail.com> wrote:
Hello Vincent,

Okay, I've uploaded a newer version of the package that should fix the
problems you mentioned. Earlier, I was trying to manually sync up
both Karolina's and upstream's debian/ folders (they had different content,
like build-dep versions, etc.), and I must have missed
the watch file. I also added a get-orig-source to debian/rules, which pulls
the revision from Launchpad bzr, removes the INSTALL
symlink, and then repacks.

debian/clean is removed and the changelog is also more verbose now.
You don't need to declare a build-dep on bzr because it's only used by
d/rules get-orig-source, not during the build itself (to be precise,
Policy §7.7 specifies the specific d/rules targets in which the
dependencies listed in various d/control fields must be satisfied to
invoke them; get-orig-source is not one of these targets), so please
remove bzr from your build-deps.

The orig tarball you've uploaded to mentors seems to differ from a
tarball that I've generated locally using your get-orig-source target
(i.e. hashsums don't match).

Regards,
Vincent


Reply to: