Source: quilt
Version: 0.63-8.1
Severity: normal
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Dear Maintainer,
While working on the "reproducible builds" effort [1], we have noticed
that 'quilt' could
Hi all,
Please review the draft for week 120's blog post:
https://reproducible.alioth.debian.org/blog/drafts/120/
Feel free to commit any changes directly to drafts/120.mdwn in Git:
https://anonscm.debian.org/git/reproducible/blog.git/
I am very happy to reword and/or rework prior to
Dear Federico,
> There are two possible solutions[2]: set the environment variable
> QT_HASH_SEED to a constant value before
> pyrcc5 is called (this is my current workaround) or call
> qSetGlobalQHashSeed().
>
> I can help with the implementation if needed.
Neat! Please do so. :)
Probably
Hello,
I'm packaging an application making use of pyrcc5 and I noticed the
nondeterminism it adds.
I see[1] that this is currently description is not correct.
You can see that pyrcc5 uses QHash, which is made to avoid algorithmic
complexity attacks[2]
introducing a randomization.
There are two
Hi Chris,
> Can you give me an example? eg. Where are these binaries located, etc.
> etc. or are they in such bespoke dirs that the ability to override
> externally is required?
The issue here is: the tools are architecture dependent, for ARM binaries
you'll need tools compiled with ARM
Hi Daniel,
> However it doesn't stop there: With objdump you can't just pick
> *any* version but you need one with support for the precisely
> the target architecture you want to look at
Can you give me an example? eg. Where are these binaries located, etc.
etc. or are they in such bespoke dirs
