Building packages three times in a row

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Building packages three times in a row

Patrick Winnertz-3
Hi,

as a QA effort the whole archive was rebuilt over the weekend to catch
build-failures, whether a package can be build three tmes in a row (unpack,
build, clean, build,clean, build).
This is the second effort to get rid of those issues. The first effort was
announced by Martin-Zobel Helas on 16 May 2007 [0].

We found again about 400 packages not having a sane clean target.

To cite
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

clean

    This must undo any effects that the build and binary targets may
have had, except that it should leave alone any output files created
in the parent directory by a run of a binary target.

We'll fill bug reports against every package that FTBFS in this way with
Severity: Important.

Furthermore we detect some issues with different package content (compared
to the first build) after the second and third build. This bugs will have
Severity: Serious.

You'll find after we at the end all filled bugs either here [1] or here
[2].

Please note that building a package twice in a row is a release goal for
lenny.

Greetings
Patrick Winnertz


[0]:http://lists.debian.org/debian-devel/2007/05/msg00490.html
[1]:http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@...;tag=qa-doublebuild
[2]:http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@...;tag=qa-debdiff-differ
--
 .''`.   Patrick Winnertz <[hidden email]>
:  :' :  GNU/Linux Debian-Edu Developer
`. `'`   http://www.der-winnie.de http://d.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Patrick Winnertz-3
Am Montag, 10. September 2007 22:34:52 schrieb Patrick Winnertz:

> Hi,
>
> as a QA effort the whole archive was rebuilt over the weekend to catch
> build-failures, whether a package can be build three tmes in a row
> (unpack, build, clean, build,clean, build).
> This is the second effort to get rid of those issues. The first effort
> was announced by Martin-Zobel Helas on 16 May 2007 [0].
>
> We found again about 400 packages not having a sane clean target.
>
> To cite
> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
>
> clean
>
>     This must undo any effects that the build and binary targets may
> have had, except that it should leave alone any output files created
> in the parent directory by a run of a binary target.
>
> We'll fill bug reports against every package that FTBFS in this way with
> Severity: Important.
>
> Furthermore we detect some issues with different package content
> (compared to the first build) after the second and third build. This
> bugs will have Severity: Serious.
>
> You'll find after we at the end all filled bugs either here [1] or here
> [2].
>
> Please note that building a package twice in a row is a release goal for
> lenny.
>
> Greetings
> Patrick Winnertz
>
>
> [0]:http://lists.debian.org/debian-devel/2007/05/msg00490.html
> [1]:http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@...
>ebian.org;tag=qa-doublebuild
> [2]:http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@...
>ebian.org;tag=qa-debdiff-differ
Mmpf... I've to correct the third link... there is a small typo.

You can see the filled bug reports with a different package content after
the build here:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-qa@...;tag=qa-debdiff

Thanks.

Greetings
Patrick Winnertz

--
 .''`.   Patrick Winnertz <[hidden email]>
:  :' :  GNU/Linux Debian-Edu Developer
`. `'`   http://www.der-winnie.de http://d.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Neil Williams-4
In reply to this post by Patrick Winnertz-3
On Mon, 10 Sep 2007 22:34:52 +0200
Patrick Winnertz <[hidden email]> wrote:

> as a QA effort the whole archive was rebuilt over the weekend to catch
> build-failures, whether a package can be build three tmes in a row (unpack,
> build, clean, build,clean, build).

What happens about false-positives? No script is perfect - it appears
that this script has got it wrong in the case of libgpeschedule at least.

> This is the second effort to get rid of those issues. The first effort was
> announced by Martin-Zobel Helas on 16 May 2007 [0].

Something went awry between the two because my packages were fine on
the first one, now just one of them is reported to fail in a way that I
simply cannot replicate.

>     This must undo any effects that the build and binary targets may
> have had, except that it should leave alone any output files created
> in the parent directory by a run of a binary target.

AFAICT the clean target is fine.
 
> Please note that building a package twice in a row is a release goal for
> lenny.

And libgpeschedule does build two, three or more times in a row. I
don't understand why the test routine shows a failure when AFAICT none
exists. The build log makes no sense and appears to be incomplete so I
have no way of replicating the build and no way to "fix" it.

Unless someone can demonstrate whether something is actually going
wrong and give me some ideas on how to fix it, I'm going to have to
close 442636 as an artifact of a broken tool.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Soeren Sonnenburg-12
In reply to this post by Patrick Winnertz-3
On Mon, 2007-09-10 at 22:34 +0200, Patrick Winnertz wrote:
> Hi,
[...]
> Furthermore we detect some issues with different package content (compared
> to the first build) after the second and third build. This bugs will have
> Severity: Serious.

Hmmhh, what do you do about programs etc that encode the build-time in
the binary? I mean they obviously will change between builds?

Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Julien Cristau-6
On Tue, Sep 18, 2007 at 20:49:03 +0200, Soeren Sonnenburg wrote:

> On Mon, 2007-09-10 at 22:34 +0200, Patrick Winnertz wrote:
> > Hi,
> [...]
> > Furthermore we detect some issues with different package content (compared
> > to the first build) after the second and third build. This bugs will have
> > Severity: Serious.
>
> Hmmhh, what do you do about programs etc that encode the build-time in
> the binary? I mean they obviously will change between builds?
>
Hopefully they don't encode the build-time in the file list?

Cheers,
Julien


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Patrick Winnertz-4
Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
> > Hmmhh, what do you do about programs etc that encode the build-time in
> > the binary? I mean they obviously will change between builds?
>
> Hopefully they don't encode the build-time in the file list?
We checked not for files which differ, but only for files which are missing
in the first package. or which are missing in the second package.

For example aptitude:
In the second build the complete .mo files are missing.  

Maybe you get an idea if you look on the logs:
http://people.debian.org/~lucas/logs/2007/doublebuild-09-05/failed-debdiff/


FYI: I filled all FTBFS bugs on Sunday 16.10. Since this is about 10 days
after the rebuilt (I didn't have enough time in between) some packages
were already fixed on Sunday. Sorry to the people who fixed this issues
with a new upload between the rebuild and my bug reports ;-)

Greetings
Patrick

>
> Cheers,
> Julien



--
 .''`.   Patrick Winnertz <[hidden email]>
:  :' :  GNU/Linux Debian-Edu Developer
`. `'`   http://www.der-winnie.de http://d.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Martin Uecker

Patrick Winnertz wrote:
> Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
> > > Hmmhh, what do you do about programs etc that encode the build-time in
> > > the binary? I mean they obviously will change between builds?
> >
> > Hopefully they don't encode the build-time in the file list?
> We checked not for files which differ, but only for files which are missing
> in the first package. or which are missing in the second package.
>

I think it would be really cool if the Debian policy required
that packages could be rebuild bit-identical from source.
At the moment, it is impossible to independly verify the
integricity of binary packages.


Greetings,
Martin

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Neil Williams-4
On Sun, 23 Sep 2007 23:32:59 +0200
Martin Uecker <[hidden email]> wrote:

>
> Patrick Winnertz wrote:
> > Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
> > > > Hmmhh, what do you do about programs etc that encode the build-time in
> > > > the binary? I mean they obviously will change between builds?
> > >
> > > Hopefully they don't encode the build-time in the file list?
> > We checked not for files which differ, but only for files which are missing
> > in the first package. or which are missing in the second package.
> >
>
> I think it would be really cool if the Debian policy required
> that packages could be rebuild bit-identical from source.
> At the moment, it is impossible to independly verify the
> integricity of binary packages.
This has been covered before - certain upstream macros are among many
factors that ensure that this is unlikely. I, for one, use such macros
upstream to indicate the build time of the actual executable installed
so this will change the binary every time it is built.

You have md5sums and GnuPG signatures on the Release files - I see no
benefit from bit-matching.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Martin Uecker

Neil Williams <[hidden email]>:
> Martin Uecker <[hidden email]> wrote:

[...]

> >
> > I think it would be really cool if the Debian policy required
> > that packages could be rebuild bit-identical from source.
> > At the moment, it is impossible to independly verify the
> > integricity of binary packages.
>
> This has been covered before - certain upstream macros are among
> many factors that ensure that this is unlikely. I, for one, use such
> macros upstream to indicate the build time of the actual executable
> installed so this will change the binary every time it is built.

This could be fixed.

> You have md5sums and GnuPG signatures on the Release files - I see
> no benefit from bit-matching.

The build host could be compromised. Not that unlikely.


Martin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Benjamin M. A'Lee-2
On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote:
> Neil Williams <[hidden email]>:
> > This has been covered before - certain upstream macros are among
> > many factors that ensure that this is unlikely. I, for one, use such
> > macros upstream to indicate the build time of the actual executable
> > installed so this will change the binary every time it is built.
>
> This could be fixed.

In every binary that includes the build date in it? There's rather a
lot; off the top of my head, Vim does it, and so does the Linux kernel
AFAIK.

> > You have md5sums and GnuPG signatures on the Release files - I see
> > no benefit from bit-matching.
>
> The build host could be compromised. Not that unlikely.

And if the build host was compromised, how would that help any more than
md5sums and gpg-signing? With access to the build host, whatever list of
bits to match could be changed along with the binary, the md5sum, and
the gpg-signature.

Anyway, surely the point of hashes like md5, sha1, etc, is that it's
much faster to do that than to compare large files bit by bit?

--
Benjamin A'Lee <[hidden email]>
http://subvert.org.uk/~bma/

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Martin Uecker

Benjamin A'Lee <[hidden email]>:

> On Mon, Sep 24, 2007 at 12:54:58AM +0200, Martin Uecker wrote:
> > Neil Williams <[hidden email]>:
> > > This has been covered before - certain upstream macros are among
> > > many factors that ensure that this is unlikely. I, for one, use
> > > such
> > > macros upstream to indicate the build time of the actual
> > > executable
> > > installed so this will change the binary every time it is built.
> >
> > This could be fixed.
>
> In every binary that includes the build date in it? There's rather a
> lot; off the top of my head, Vim does it, and so does the Linux
> kernel AFAIK.

I know. In a world where providing a correctly working clean
target is already an issue, that's pretty far fetched.
But IMHO being able to recreate binaries from source code in
a reproducable way would be a milestone for security and QA.

> > > You have md5sums and GnuPG signatures on the Release files - I
> > > see no benefit from bit-matching.
> >
> > The build host could be compromised. Not that unlikely.
>
> And if the build host was compromised, how would that help any more
> than md5sums and gpg-signing? With access to the build host, whatever
> list of bits to match could be changed along with the binary, the md5sum,
> and the gpg-signature.
>
> Anyway, surely the point of hashes like md5, sha1, etc, is that it's
> much faster to do that than to compare large files bit by bit?

The idea is not to replace hashes by bit-by-bit comparison, but to
be able to *independendly* reproduce binaries from source code in
a bit-identical way. Then third parties can recreate the binaries
and publish recreated hashes. If the recreated hashes are identical
then you can be sure that nobody has tempered with the build process
and the binary is actually created from the unmodified sources. The
current scheme just protects against tempering after signing. That
is actually not very much.


Martin


Reply | Threaded
Open this post in threaded view
|

Re: Building packages with exact binary matches

Neil Williams-4
In reply to this post by Martin Uecker
On Mon, 24 Sep 2007 00:54:58 +0200
Martin Uecker <[hidden email]> wrote:

> Neil Williams <[hidden email]>:
> > Martin Uecker <[hidden email]> wrote:
> > This has been covered before - certain upstream macros are among
> > many factors that ensure that this is unlikely. I, for one, use such
> > macros upstream to indicate the build time of the actual executable
> > installed so this will change the binary every time it is built.
>
> This could be fixed.

Fixed?? What the? You're asserting that this is a PROBLEM to be fixed?
It's good, it's useful, it's helpful. I'm confused, what is wrong with
that?

:-(

IMNSHO, this is not a bug, there is no good reason to prevent upstream
from using such macros and besides, there are other upstream processes
that modify the built binaries every time the build proceeds. Think
Latex and various other generation tools.

Also, any build process generates files that contain different
references and linked objects - if a package hasn't been built for a
while (no new uploads), what on earth is wrong with that not being a
binary-match for a package that was built yesterday against updated
libraries?

See also this thread:
http://lists.debian.org/debian-devel/2007/07/msg00588.html
and
http://lists.debian.org/debian-devel/2007/06/msg01076.html

If the dependencies change between builds, so will the binary.

> > You have md5sums and GnuPG signatures on the Release files - I see
> > no benefit from bit-matching.
>
> The build host could be compromised. Not that unlikely.

That's why the autobuild process is not entirely automated. A real DD
needs to sign off the ported packages.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages with exact binary matches

Martin Uecker


> On Mon, 24 Sep 2007 00:54:58 +0200
> Martin Uecker <[hidden email]> wrote:
>
> > Neil Williams <[hidden email]>:
> > > This has been covered before - certain upstream macros are among
> > > many factors that ensure that this is unlikely. I, for one, use
> > > such macros upstream to indicate the build time of the actual
> > > executable installed so this will change the binary every
> > > time it is built.
> > ac
> > This could be fixed.
>
> Fixed?? What the? You're asserting that this is a PROBLEM to be
> fixed?

If policy would require the exact reproducability of binaries, then
it would be a policy violation.

> It's good, it's useful, it's helpful. I'm confused, what is wrong
> with that?
>
> :-(

I do not see how a date stamp in a binary is really usefull. Often
it is just used as a cheap replacement of fine grained versioning
information. But I do not think that's a good reason. The date on
which a binary is built is actually completely irrelevant from
a technical point of view. What's really usefull is the exact
version of the source code and the build tools. Everything else
should not matter at all!

> IMNSHO, this is not a bug, there is no good reason to prevent
> upstream from using such macros

Ofcourse there is: reproducability

> and besides, there are other upstream processes that modify
> the built binaries every time the build proceeds.
> Think Latex and various other generation tools.

These could be fixed too ;-)

> Also, any build process generates files that contain different
> references and linked objects - if a package hasn't been built for a
> while (no new uploads), what on earth is wrong with that not being a
> binary-match for a package that was built yesterday against updated
> libraries?
>
> See also this thread:
> http://lists.debian.org/debian-devel/2007/07/msg00588.html
> and
> http://lists.debian.org/debian-devel/2007/06/msg01076.html
>
> If the dependencies change between builds, so will the binary.

That's an different issue. I am not complaing about the fact
that binaries can change without source code changes, but that
it is impossible to create an identical package even when you
try.

> > > You have md5sums and GnuPG signatures on the Release files - I
> > > see no benefit from bit-matching.
> >
> > The build host could be compromised. Not that unlikely.
>
> That's why the autobuild process is not entirely automated. A real
> DD needs to sign off the ported packages.

I do not see how this helps. Imagine a build host is compromised
and this is noticed only after a few weeks. Theoretically every
machine which downloaded and installed a package in this time
could be compromised. And even worse: it is practically impossible
to find out wether a package is actually affected!


Martin




Reply | Threaded
Open this post in threaded view
|

Re: Building packages with exact binary matches

Manoj Srivastava
On Mon, 24 Sep 2007 04:56:45 +0200, Martin Uecker <[hidden email]> said:

>> On Mon, 24 Sep 2007 00:54:58 +0200
>> Martin Uecker <[hidden email]> wrote:
>>
>> > Neil Williams <[hidden email]>:
>> > > This has been covered before - certain upstream macros are among
>> > > many factors that ensure that this is unlikely. I, for one, use
>> > > such macros upstream to indicate the build time of the actual
>> > > executable installed so this will change the binary every time it
>> > > is built.
>> > ac This could be fixed.
>>
>> Fixed?? What the? You're asserting that this is a PROBLEM to be
>> fixed?

> If policy would require the exact reproducability of binaries, then it
> would be a policy violation.

        That is not how things work around here.  In a case like this,
 policy will _follow_ most packages being bit-for-bit identical, and
 can't be used as a stick to beat people on the head with.

> I do not see how this helps. Imagine a build host is compromised and
> this is noticed only after a few weeks. Theoretically every machine
> which downloaded and installed a package in this time could be
> compromised. And even worse: it is practically impossible to find out
> wether a package is actually affected!

        Actually, if you do not trust the path down which a binary
 package flows, you can not use any information down that flow path to
 test your implementation.  You need to do a full source audit, and
 build from source -- at which point, you might just install your trused
 binary, instead of trying to verify that the upstream package is the
 same as yours.

        If you find this inadequate, then your best bet to seeing this
 happen is to go ahead and start submitting patches to make package be
 bit-for-bit compatible -- starting with, perhaps, the essential
 packages.  Once you have enough of the packages converted, we can talk
 about making this a policy recommendation.

        I think building gcc builds it several times, and they had a
 neat trick of ignoring the first few bytes of a file which had the time
 stamp, and comparing the rest. You could try using that technique to
 compare files in packages.

        I, for one, think this technically infeasible, but hey, I'll be
 happy to be proved wrong.

        manoj
--
"There can be no offense where none is taken" Japanese proverb
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages with exact binary matches

Ben Finney-2
In reply to this post by Martin Uecker
Martin Uecker <[hidden email]> writes:

> If policy would require the exact reproducability of binaries, then
> it would be a policy violation.

You seem to be suggesting that policy should require this *before* it
becomes common practice. That's not generally how policy is crafted:
Debian policy generally does not prescribe packaging practice, but
rather describes it.

If some practice is a good idea, the way to see it become policy is to
motivate other packagers to follow that practice, until it is common
enough that it is not onerous to describe it as packaging policy that
should always be followed.

Debian policy isn't a stick to beat others with; it's a formal
description of packaging practice that is believed to be good
independent of being written down in policy.

--
 \          "Any sufficiently advanced bug is indistinguishable from a |
  `\                                       feature."  -- Rich Kulawiec |
_o__)                                                                  |
Ben Finney


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Neil Williams-4
In reply to this post by Martin Uecker
On Mon, 24 Sep 2007 02:13:32 +0200
Martin Uecker <[hidden email]> wrote:

> The idea is not to replace hashes by bit-by-bit comparison, but to
> be able to *independendly* reproduce binaries from source code in
> a bit-identical way.

And what is going to happen when I used gcc-4.2.2007foo and you use
gcc-4.2.1 etc.? You have the .orig.tar.gz and you have the .diff.gz.
The standard method is to compare the .orig.tar.gz and then use
'interdiff -z' against the new .diff.gz.

> Then third parties can recreate the binaries
> and publish recreated hashes.

Why? I see no benefit.

> If the recreated hashes are identical
> then you can be sure that nobody has tempered with the build process

You'll *only* get that if the build tools are identical - that isn't
tampering, it is bug fixing. gcc is not bug-free, each new version can
include new bugs or regressions - same applies to autotools, dpkg, etc.etc.

> and the binary is actually created from the unmodified sources.

== compare the .orig.tar.gz - nothing else is needed for that and all
the current tools already handle this portion.

> The
> current scheme just protects against tempering after signing. That
> is actually not very much.

You have to trust a DD at some point. If you can't trust me to build
packages properly, you'll just have to rebuild the entire archive
yourself.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Lucas Nussbaum
In reply to this post by Martin Uecker
On 23/09/07 at 23:32 +0200, Martin Uecker wrote:

>
> Patrick Winnertz wrote:
> > Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
> > > > Hmmhh, what do you do about programs etc that encode the build-time in
> > > > the binary? I mean they obviously will change between builds?
> > >
> > > Hopefully they don't encode the build-time in the file list?
> > We checked not for files which differ, but only for files which are missing
> > in the first package. or which are missing in the second package.
> >
>
> I think it would be really cool if the Debian policy required
> that packages could be rebuild bit-identical from source.
> At the moment, it is impossible to independly verify the
> integricity of binary packages.
We are currently very far from that. If you want to go that direction,
you have to find a several-steps process that would make us go there.

I compared the result of a one build, with the result of a package built
three times, using debdiff. This has several flaws:

- it only compared the list of files. If the same files are there, but
  with totally different size, it won't notice.

- it didn't compare with what is in the archive: packages in the archive
  might be totally different, because they were built at a different
  time (with a different toolchain), or in a dirty environment.

Basically, the goal you should aim at is "rebuilding a package should
generate binary packages similar enough to what's already in the
archive."

Raphael's dpkg-shlibdeps work should also help with that, but it doesn't
seem like #430367 has progressed recently?
--
| Lucas Nussbaum
| [hidden email]   http://www.lucas-nussbaum.net/ |
| jabber: [hidden email]             GPG: 1024D/023B3F4F |

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building packages with exact binary matches

Clint Adams
In reply to this post by Ben Finney-2
On Mon, Sep 24, 2007 at 03:34:35PM +1000, Ben Finney wrote:
> You seem to be suggesting that policy should require this *before* it
> becomes common practice. That's not generally how policy is crafted:
> Debian policy generally does not prescribe packaging practice, but
> rather describes it.

Calling it "policy" is misleading then.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages with exact binary matches

Manoj Srivastava
On Mon, 24 Sep 2007 03:30:48 -0400, Clint Adams <[hidden email]> said:

> On Mon, Sep 24, 2007 at 03:34:35PM +1000, Ben Finney wrote:
>> You seem to be suggesting that policy should require this *before* it
>> becomes common practice. That's not generally how policy is crafted:
>> Debian policy generally does not prescribe packaging practice, but
>> rather describes it.

> Calling it "policy" is misleading then.

        I don't think that follows.  It is not as if packages do not
 have to follow policy once it is written -- either it is a bug in the
 package, or it is a bug in the policy. What we are talking about is how
 changes get into policy.

        In a project that is loosely coupled, geographically
 distributed, and has an extremely flat org chart,  policy changes
 necessarily  have to be conservative; and our preference is changing
 Debian by persuasion and near consensus, not by edicts from above
 (since there is so very little "above").

        This is not to say that policy will _never_ lead the change --
 but that is a very exceptional case, and probably would need to be
 ratified by, say, the tech ctte.

        manoj
--
"I got everybody to pay up front...then I blew up their planet." "Now
why didn't I think of that?"-- Post Bros. Comics
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Building packages three times in a row

Goswin von Brederlow
In reply to this post by Martin Uecker
Martin Uecker <[hidden email]> writes:

> Patrick Winnertz wrote:
>> Am Dienstag, 18. September 2007 21:12:44 schrieb Julien Cristau:
>> > > Hmmhh, what do you do about programs etc that encode the build-time in
>> > > the binary? I mean they obviously will change between builds?
>> >
>> > Hopefully they don't encode the build-time in the file list?
>> We checked not for files which differ, but only for files which are missing
>> in the first package. or which are missing in the second package.
>>
>
> I think it would be really cool if the Debian policy required
> that packages could be rebuild bit-identical from source.
> At the moment, it is impossible to independly verify the
> integricity of binary packages.
>
>
> Greetings,
> Martin

Some tools use randomization to get out of worst case situations or
general optimization. For example when you look for an optimal
allocation of register usage you can do a search by picking a random
register allocation and repeat that a few thousand times to find a
suitable minimum. Or a randomized heap that gives you O(1) time for
all operations instead of O(lg n).

By requiring bit-to-bit identical results you eliminate all such
randomness and could seriously hinder the algorithm available for
tools.

Plus any bugfix in a tool will likely break it anyway as mentioned in
other mails.

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

123