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 trem
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 personal
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 obta
On Wed, May 16, 2007 at 04:22:17PM -0700, Steve Langasek wrote:
> 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 b
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
> > t
On Wed, May 16, 2007 at 06:51:24PM +0100, Roger Leigh wrote:
> Please could you file a wishlist bug, so I don't forget about it?
Done: #424846.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/
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 t
[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 nothi
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
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 sel
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,
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. The
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, bui
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 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 pa
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? T
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 p
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 othe
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.
>
>
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
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),
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?
Tha
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 t
* 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, 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
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 f
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 th
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
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 bu
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
* 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 hav
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
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.
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, clea
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,
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
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrule
36 matches
Mail list logo
