Russ Allbery [EMAIL PROTECTED] writes:
Martin Zobel-Helas [EMAIL PROTECTED] writes:
On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree
Andreas Tille [EMAIL PROTECTED] writes:
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
I personally store
Tyler MacDonald [EMAIL PROTECTED] writes:
Steve Langasek [EMAIL PROTECTED] wrote:
granted there are things like this, but reproducible builds would be
fantastic and well worth the effort.
If you're talking about byte-for-byte identical builds, then no, that
would be a tremendous amount of
On Wed, May 16, 2007 at 10:43:34 +0200, Martin Zobel-Helas wrote:
Hi,
On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
[...]
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with
Hi,
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean, build). We found about 400 packages not having a sane
clean target.
To cite
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean, build). We found about 400 packages not having a sane
clean target.
Wow,
Hi,
On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean,
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
I mean, packages that fail to build the second time have for
sure garbage left around after the former invocation of clean.
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file in place to update it. The
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
I personally store the diff.gz from first build and compare with
* Santiago Vila [Wed, 16 May 2007 10:52:02 +0200]:
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file in place to update it. The second time
you build the package, dpkg-source complains about the .mo files,
as they are binary files and they have
On Wed, May 16, 2007 at 10:11:55AM +0200, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
IMHO, a good test would be to build the
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
IMHO, a good test would be to build the
On Wed, 16 May 2007 10:52:02 +0200 (CEST)
Santiago Vila [EMAIL PROTECTED] wrote:
On Wed, 16 May 2007, Stefano Zacchiroli wrote:
I mean, packages that fail to build the second time have for
sure garbage left around after the former invocation of clean.
Not always. In some cases (for
On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote:
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree
Hi all!
On Mit, 16 Mai 2007, Santiago Vila wrote:
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file in place to update it. The second time
I agree. In texinfo I have the following problem
- upstream ships po/*.gmo
- debian patches patch the .po
On Wed, 16 May 2007, Norbert Preining wrote:
Sounds like a hack. What do other say?
There are different opinions about orig.tar.gz should be equal
to upstream. I tend to the opinion that no precompiled stuff
that can be builded by the source has to be in orig.tar.gz and
in such cases I would
* Andreas Tille [Wed, 16 May 2007 13:27:54 +0200]:
On Wed, 16 May 2007, Norbert Preining wrote:
Sounds like a hack. What do other say?
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files
On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove them from the
orig tarball. I don't think
Le mercredi 16 mai 2007 à 13:15 +0200, Norbert Preining a écrit :
On Mit, 16 Mai 2007, Adeodato Simó wrote:
Deleting the binary files in the clean target. dpkg-source will complain
that they're missing, but will build the package just fine.
Sounds like a hack. What do other say?
That's
Andreas Tille [EMAIL PROTECTED] wrote:
On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove
Norbert Preining wrote:
Now at a second build time we have changes in the binary .gmo files
which cannot be represented.
What is the preferred solution for such a case?
I usually save upstream's generated files somewhere in debian/rules during
build, and copy them back in the clean target.
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote:
as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean, build). We found about 400 packages not having a sane
clean target.
To
Martin Zobel-Helas [EMAIL PROTECTED] writes:
On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
Martin Zobel-Helas [EMAIL PROTECTED] writes:
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
That would surely be the better solution to catch this policy
On Wed, 16 May 07 11:36, Lennart Sorensen wrote:
What about packages that automatically pull in updated autoconf files as
part of the build, or regenerate .po files which were already there, but
due to a new version of the tools generates a different .po file from
what was already there? The
On 16/05/07 at 10:11 +0200, Stefano Zacchiroli wrote:
Isn't twice building too coarse grained to spot actual violation of
this rule? I mean, packages that fail to build the second time have for
sure garbage left around after the former invocation of clean. But it
is not granted that packages
On Wed, May 16, 2007 at 07:57:33PM +0200, Armin Berres wrote:
I may be wrong, but IIRC removing those generated files in the clean
target is the solution if you want a clean .diff.gz.
But dpkg-buildpackage will then spit out lots of warnings about being
unable to store the deletion of a binary
On Wed, May 16, 2007 at 10:00:57AM +, [EMAIL PROTECTED] wrote:
On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote:
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote:
Wouldn't it be better to unpack a package twice in two different
directories, build and
Steve Langasek [EMAIL PROTECTED] wrote:
granted there are things like this, but reproducible builds would be
fantastic and well worth the effort.
If you're talking about byte-for-byte identical builds, then no, that
would be a tremendous amount of effort for no practical gain. There's no
On ke, 2007-05-16 at 16:26 -0700, Tyler MacDonald wrote:
We should expect that given the same source, headers, and libraries, we
would get the same bytes out of a build every time. Any deviation from this
would indicate something different, or erratic. If it doesn't cause
problems, fine, but
Lars Wirzenius [EMAIL PROTECTED] wrote:
printf(This program was compiled on __DATE__ \n);
An example like the above has already been given. Build dates and other
variable information gets put into a lot of output files from
compilations.
Sorry, I was speaking from an overly selfish point
Tyler MacDonald [EMAIL PROTECTED] writes:
We should expect that given the same source, headers, and libraries, we
would get the same bytes out of a build every time.
This just isn't how compilers work. Timestamps are encoded in binaries,
temporary build directories are encoded in debugging
[Lennart Sorensen]
But dpkg-buildpackage will then spit out lots of warnings about being
unable to store the deletion of a binary file in the diff. So it
will look ugly, but work I guess.
dpkg-buildpackage doesn't store _any_ deletions in the diff.gz - the
warning about deletions has nothing
Peter Samuelson wrote:
I'd file a bug asking for this, but clearly the warning is intentional,
so a bug is not likely to get much more attention than #12564, which is
also related.
12564 should be fixable with wig and pen. If it does get fixed then
deleting files in clean will no longer be the
34 matches
Mail list logo
