Holger Levsen:
> On Wed, Dec 27, 2017 at 05:03:11PM +0100, Holger Levsen wrote:
>> On Tue, Dec 26, 2017 at 08:56:18AM +, Chris Lamb wrote:
>>> I believe there are enough people in (or around) our community who dislike
>>> Github (for a variety reasons not productive to debate/repeat again here)
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/139/
Feel free to commit fixes directly to drafts/139.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/137/
Feel free to commit fixes directly to drafts/137.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
https://reproducible.alioth.debian.org/debian/ocaml_4.05.0-10.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.or
Axel Beckert:
> [..]
>
> Even "--fuzzy-threshold 0" to disable any "fuzzy-matching" (whatever
> that is in the context of diffoscope) didn't make a difference.
>
Actually, the problem is the other way round - control.tar.{gz,xz} have
different names and the contents aren't similar enough (I gue
Mike Hommey:
> On Thu, Oct 19, 2017 at 07:15:35PM +0900, Mike Hommey wrote:
>> Attached is my work in progress. I won't finish it right now because
>> it's getting late and I don't have all the optional tools to run the
>> test suite.
>>
>> It's worth noting that this changes the output, and the no
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/135/
Feel free to commit fixes directly to drafts/135.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
https://reproducible.alioth.debian.org/debian/r-base_3.4.2.20171120-1.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.d
Package: dpkg-dev
Version: 1.19.0.4
Severity: wishlist
Tags: patch
Dear Maintainer,
dpkg-buildpackage currently does not automatically list the source .dsc nor
its hash in the call to dpkg-genbuildinfo when doing a binary-only build. This
is understandable because in a binary-only build, dpkg-bui
Holger Levsen:
> On Thu, Nov 16, 2017 at 10:06:00AM +0000, Ximin Luo wrote:
>> Ping, are you ready? I don't see any commits from you in the log...
>
> not yet & on a very bad internet connection atm.
>
> i will publish 133 once it's ready.
>
Hey, just a re
Lisandro Damián Nicanor Pérez Meyer:
> By the way: is there a macro or combination of macros which *default* value
> can be replaced in the use of __FILE__ without caussing regressions?
>
> Because if that's the case it's easier to convince upstream people that
> changing the usage goes in favor
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Yes, we do understand that your workaround solves the issue, but we do also
> understand that we should not be using this workaround in the first place.
>
> Guillem: the thread is long, but be sure that we Qt/KDE maintainers consider
> that this c
Holger Levsen:
> On Tue, Nov 14, 2017 at 01:34:00PM +0000, Ximin Luo wrote:
>> This week's blog post draft is now available for review:
>> https://reproducible.alioth.debian.org/blog/drafts/133/
> [...]
>> I'll wait at least 24 hours from the time of this
Lisandro Damián Nicanor Pérez Meyer:
> On miércoles, 15 de noviembre de 2017 20:35:00 -03 Ximin Luo wrote:
>> Lisandro Damián Nicanor Pérez Meyer:
>>> I was wanting to write this on a keyboard, but let me try on the phone and
>>> see if we can all agree in one
Lisandro Damián Nicanor Pérez Meyer:
> I was wanting to write this on a keyboard, but let me try on the phone and
> see if we can all agree in one point.
>
> There is one *excellent* method to settle this once and forever: submit the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and wh
Pino Toscano:
> Loose meanings do not imply neither the other way around, that you are
> free to break because people cannot do anything with it. Also,
> considering the very same behaviour (short of the different wording in
> documentations) that is established for decades, this is a "de facto"
>
Pino Toscano:
> [..]
>
>> In summary: in no document or standard, does it guarantee or imply
>> that __FILE__ can be taken to represent a real filesystem path.
>> Applications relying on this behaviour are broken and should not be
>> upset when things don't work. As documented in multiple places,
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Xi: you also mentioned that having to file hundreds of patchs seems
> impossible. Well, it seems so, but it is actually not that necessary. Please
> allow me to explain the idea.
>
Thanks for being less inflammatory than Pino.
I agree that event
Pino Toscano:
> In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
>> You're using __FILE__ inappropriately, none of the documentation
>> guarantees or implies that you can access __FILE__ as a real
>> filesystem path. "Surely for relative paths&quo
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/133/
Feel free to commit fixes directly to drafts/133.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
Lisandro Damián Nicanor Pérez Meyer:
> [..]
>
> Sorry, it is not realistic to force us to have a delta from upstream for no
> direct gain.
>
None of the solutions I suggested involve patching upstream, they would be done
in d/rules.
X
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5F
Pino Toscano:
> [..]
>
>> Well let's take a look at the standards:
>> [...]
>
> Even with different wordings, both describe basically the same
> behaviour. And yes, none of them says that __FILE__ is a full path,
> but surely for relative paths the combination of $srcdir + __FILE__
> will give m
Pino Toscano:
> [..]
>
> This is not an annoyance, it is the crux of the problem! __FILE__ is
> something standard, with a very well defined behaviour, upon which
> people rely on: you cannot trash it from one day to another like this,
> saying "too bad" to all its users, even those using it appr
Pino Toscano:
> [..]
>
> A better approach here is to work on removing the invalid & abusing
> usages of __FILE__ from packages, just like it was done for __DATE__.
>
We in fact did not do the latter because it was easier to implement
SOURCE_DATE_EPOCH to fix the expansion of __DATE__, rather t
Pino Toscano:
> [..]
>
> No, the solution is:
> a) *not* break what __FILE__ means
> b) remove the misuses of __FILE__ in packages (not the case of
>QFINDTESTDATA)
>
>> I am not "blaming the user", but pointing to the fact that __FILE__
>> is being used in a surprising way here, which is not
Ximin Luo:
> [..]
>
> (maybe there are other options)
>
If all the test files reside underneath the same directory, like tests/, you
could:
4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests".
This should make the tests pass, whilst keeping
Ximin Luo:
> Ximin Luo:
>> [..]
>>
>> (maybe there are other options)
>>
>
> If all the test files reside underneath the same directory, like tests/, you
> could:
>
> 4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR
Adrian Bunk:
> Control: reassign -1 qtbase5-dev
> Control: reassign 876917 qtbase5-dev
> Control: reassign 876933 qtbase5-dev
> Control: forcemerge -1 876917 876933
> Control: retitle -1 QFINDTESTDATA uses __FILE__
> Control: severity -1 normal
> Control: affects -1 src:karchive src:ki18n src:kcode
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/131/
Feel free to commit fixes directly to drafts/131.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
https://reproducible.alioth.debian.org/debian/r-base_3.4.2-2.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
gregor herrmann:
> [..]
>
> So I guess I'll stay with excluding domain_host for now.
>
> [..]
>
> It looks like currently both 0 and 1 cause problems :)
>
Yes, I've experienced this too. :( I'm hitting what I think might be a bug with
nsenter(1), but I have a potential workaround. It'll take
gregor herrmann:
> [..]
>
> I've now built a package from git HEAD (3efb86f), and .. hm .. I guess
> this bug is fixed, it's just that I'm running into another issue
> which seems related to another recent commit (the domain_host
> feature):
>
> [..]
>
> The recommended `echo 1 > /proc/sys/kerne
gregor herrmann:
> [..]
>
> So currently I have:
>
> - reprotest called as
> env -u TMPDIR -- reprotest --variations=+all,-build_path,-user_group
> --verbosity 1 . -- schroot default 2>&1 | [..]
>
Thanks, this helped me reproduce the bug locally. I was having trouble before,
because the bu
https://reproducible.alioth.debian.org/debian/dpkg_1.19.0.2.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Ximin Luo:
> gregor herrmann:
>> On Thu, 05 Oct 2017 22:59:00 +0000, Ximin Luo wrote:
>>
>>> gregor herrmann:
>>>> [..]
>>>> sudo: Ψ½âÎöÖ÷»ú£ºjadzia
>>>> tail: Ψ´ò¿ª'debian/changelog' ¶ÁȡÊý¾: Ȩϻ¹»
>>>> dpkg-
https://reproducible.alioth.debian.org/debian/dpkg_1.19.0.1.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/129/
Feel free to commit fixes directly to drafts/129.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
https://reproducible.alioth.debian.org/debian/r-base_3.4.2-1.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Daniel Kahn Gillmor:
> On Thu 2017-10-12 03:02:49 +0100, Chris Lamb wrote:
>
>> The GitHub repositories are read-only mirrors. If you are checking out
>> the code as a member of the Reproducible Builds team, then it makes more
>> sense to get it from Alioth, for example:
>>
>> $ git clone git.de
gregor herrmann:
> On Thu, 05 Oct 2017 22:59:00 +0000, Ximin Luo wrote:
>
>> gregor herrmann:
>>> [..]
>>> sudo: Ψ½âÎöÖ÷»ú£ºjadzia
>>> tail: Ψ´ò¿ª'debian/changelog' ¶ÁȡÊý¾: Ȩϻ¹»
>>> dpkg-buildpackage: erreur: fin de debi
gregor herrmann:
> [..]
> sudo: Ψ½âÎöÖ÷»ú£ºjadzia
> tail: Ψ´ò¿ª'debian/changelog' ¶ÁȡÊý¾: Ȩϻ¹»
> dpkg-buildpackage: erreur: fin de debian/changelog a produit une erreur de
> sortie de type 1
> [..]
> sudo: impossible de déterminer le nom de l'hôte jadzia
> tail: no se puede abrir 'debian/ch
gregor herrmann:
> [..]> dpkg-buildpackage: error: fakeroot not found, either install the
> fakeroot
> package, specify a command with the -r option, or run this as root
> [..]
>
> This seems to be related to the "sudo" use in the output above (or
> the funny output in the first line?), or
>
>
Ximin Luo:
> [..]
>
> OTOH, developer reproducibility checkers (such as reprotest) can be a little
> bit more strict. I can imagine something like:
>
> - reprotest runs 3 builds:
> - build 0 with current env
> - build 1 with current env + varying some "blacklis
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/127/
Feel free to commit fixes directly to drafts/127.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
Mattia Rizzolo:
> [..]
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line
> 102, in control
> control_file =
> self.as_container.control_tar.as_container.lookup_file('./control')
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/deb.py", line
> 78, in
Russ Allbery:
> [..] It does mean that discovery of any new
> such environment variable would require a change to our whitelist in
> approach (3), so there would be some lag and the whitelist would become
> long over time (with a corresponding testing load). But (3) does try to
> achieve that use
Ximin Luo:
> [..]
>
> (The last time I erroneously included PATH in the final "excluded" list -
> because we have varied PATH but in a really trivial way on tests.r-b.org for
> ages - but I now agree with you that we shouldn't expect reproducibility when
&
Simon McVittie:
> On Mon, 18 Sep 2017 at 18:00:51 -0700, Vagrant Cascadian wrote:
>> [..]
>>
>> I consider unintended variables that affect the build output a bug, and
>> variables designed and intended to change the behavior of the toolchain
>> expected, reasonable behavior.
>
> There is a *huge*
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/125/
Feel free to commit fixes directly to drafts/125.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
https://reproducible.alioth.debian.org/debian/gcc-7_7.2.0-8.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
https://reproducible.alioth.debian.org/debian/gcc-7_7.2.0-3.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/123/
Feel free to commit fixes directly to drafts/123.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
Vagrant Cascadian:
> On 2017-08-16, Ximin Luo wrote:
>> It looks like the GCC reviewer that looked at my patch this time
>> around, really doesn't like environment variables. They seem to be
>> happy to support the variable (including the syntax) as a command-line
Dan Kegel:
> On Mon, Sep 4, 2017 at 9:26 PM, Vagrant Cascadian wrote:
>> Or maybe GCC is just fundamentally opposed to environment variables at
>> all?
>
> Not completely:
> https://gcc.gnu.org/onlinedocs/cpp/Environment-Variables.html
> does mention SOURCE_DATE_EPOCH :-)
> - Dan
>
We got lucky
https://reproducible.alioth.debian.org/debian/gcc-7_7.2.0-2.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Chris Lamb:
> Hi Holger et. al.,
>
>>> This idea is similar to hardening-wrapper. That is now deprecated, but was
>>> useful as a stepping-stone to more "proper" fixes. Likewise, this shouldn't
>>> be thought of as "the proper fix", [...]
>>
>> when reading this at first, I didnt like the idea of
Source: diffoscope
Version: 85
Severity: normal
X-Debbugs-CC: yzgyy...@outlook.com
A test case failed on FreeBSD because of the different Device ID between two
system.
A commit regarding a similar issue:
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=1390b76
A propose
Hi all,
This week's blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/121/
Feel free to commit fixes directly to drafts/121.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for an
Russ Allbery:
> Bill Allombert writes:
>
>> This is one of the reasons I do not attend DebConf anymore. We are an
>> online organization. Consultation should happen online. Metting are nice
>> but they should not be used to vet consensus and ignore absentees.
>
>> So I object to Adrian being ove
https://reproducible.alioth.debian.org/debian/gcc-7_7.2.0-1.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Russ Allbery:
> Ximin Luo writes:
>
>> Fair enough. I actually spotted that but thought it was better to get
>> "something" into Policy rather than nitpick. I guess other people were
>> thinking similar things. Well, lesson learnt, I will be more forceful
Bill Allombert:
> On Tue, Aug 15, 2017 at 07:49:55PM +, Holger Levsen wrote:
>> Also what you are saying ("a package that is reproducible according to the
>> policy definition must not show up as non-reproducible in tracker/DDPO based
>> on results from the reproducible infrastructure") doesnt
Adrian Bunk:
> On Wed, Aug 16, 2017 at 03:43:00PM +0000, Ximin Luo wrote:
>> Adrian Bunk:
>>> On Wed, Aug 16, 2017 at 11:37:00AM +, Ximin Luo wrote:
>>>> [..]
>>>>
>>>> Fair enough. I actually spotted that but thought it was better to ge
Adrian Bunk:
> On Wed, Aug 16, 2017 at 11:37:00AM +0000, Ximin Luo wrote:
>> [..]
>>
>> Fair enough. I actually spotted that but thought it was better to get
>> "something" into Policy rather than nitpick. I guess other people were
>> thinking similar
Hi list,
It looks like the GCC reviewer that looked at my patch this time around, really
doesn't like environment variables. They seem to be happy to support the
variable (including the syntax) as a command-line flag however.
The original patch fixed ~1800 packages, which were unreproducible du
Federico Brega:
> 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
Adrian Bunk:
> On Wed, Aug 16, 2017 at 10:24:07AM +, Mattia Rizzolo wrote:
>> On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk wrote:
>>
>>> Tracker:
>>> https://tracker.debian.org/pkg/hsqldb1.8.0
>>> "Does not build reproducibly during testing"
>>
>> And indeed it's not reproducible according to p
Bill Allombert:
> On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
>> Adrian Bunk writes:
>>
>>> Future policy versions might change this definition, but whatever latest
>>> policy states has to be the definition used by both packages and the
>>> reproducible builds team.
>>
>>> Anoth
Hi all,
Sorry for the delay due to me getting distracted by DebConf, but this week's
blog post draft is now available for review:
https://reproducible.alioth.debian.org/blog/drafts/119/
Feel free to commit fixes directly to drafts/119.mdwn in
https://anonscm.debian.org/git/reproducible/blog.gi
Sean Whitton:
> [..]
>
> Here is an updated patch addressing these. I reworded it to use
> 'recommended' and changed the tone to better suit policy.
>
> Thank you Ximin, Russ and Johannes!
>
>> "precisification" -> "more precise version"
>
> Our definition is not actually a /version/ of the
>
Sean Whitton:
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..cc4b020 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or
> build system (for
> example, a package that builds the s
https://reproducible.alioth.debian.org/debian/gcc-7_7.1.0-13.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
https://reproducible.alioth.debian.org/debian/gcc-7_7.1.0-12.0~reproducible1.dsc
has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Package: diffoscope
Version: 84
Severity: important
Dear Maintainer,
When testing rustc reproducibility:
$ for i in {1..10}; do diffoscope core-fcc113aeec9d4b78.0.bytecode.0
core-fcc113aeec9d4b78.0.bytecode.1 | wc -l; done
# hangs first time
$ for i in {1..10}; do diffoscope --max-diff-input-l
Daniel Egger:
> Package: diffoscope
> Version: 84
>
> I'm using diffoscope on a Mac and it doesn't have tools like readelf and
> objdump by default and even after installation (e.g. via brew) those would be
> called greadelf and gobjdump instead to not conflict with local tools under
> the same
gcc-6_6.4.0-2.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/
Hans-Christoph Steiner:
>
> The APK format is a ZIP file that always includes the files
> AndroidManifest.xml and classes.dex. Then it also always
> has a JAR signature (i.e. META-INF/). It does not have the
> JAR magic number CAFEBABE in it.
>
Right, I can get that much by looking it up on wi
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/117/
Feel free to commit fixes directly to drafts/117.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for any co
Control: tags -1 - pending
Hans-Christoph Steiner:
> [..]
>
> I'd like a way to force the file type in diffoscope. We are calling it
> from a build process, so we already know all files are going to be APKs.
> Also, I tried to get this added to libfile, but upstream is not willing
> to accept
Mattia Rizzolo:
> I gently remind you of this; I plan to send it out in 2 days.
>
> On Thu, 13 Jul 2017, 9:25 p.m. Mattia Rizzolo, wrote:
>
>> On Thu, Jul 13, 2017 at 11:43:04AM -0700, Vagrant Cascadian wrote:
>>> Happy to review, just let me know where the text is to review! :)
>>
>>
>> Right,
r-base_3.4.1-2.0~reproducible2.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/115/
Feel free to commit fixes directly to drafts/115.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for any co
Eric Dorland:
> Hi folks,
>
> I was trying to fix some unreproduciblity issues with automake and the
> problem of version.texi came to my attention and I haven't seen it
> come up before, but let me know if I just couldn't find it.
>
> According to
> https://www.gnu.org/software/automake/manual/h
gcc-6_6.4.0-1.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/
r-base_3.4.1-1.0~reproducible2.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman
gcc-6_6.3.0-21.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman
Ximin Luo:
> Lasse Collin:
>> posix-shell.m4 comes from gnulib
>>
>> [..]
>>
>> One can force the POSIX shell to a specific value on the configure
>> command line by passing, for example, "gl_cv_posix_shell=/bin/sh" as an
>> argument. It&#
The current version of xz-utils built in current unstable does not seem to be
affected by this issue. Possibly we fixed gettext in the meantime to generate
reproducible timestamps.
It is still affected by #806331 for which I've already written a patch.
X
--
GPG: ed25519/56034877E1F87C35
GPG:
Package: diffoscope
Version: 83
Severity: wishlist
Dear Maintainer,
Several times people on IRC have asked about reprotest reporting file
permissions
differences when building files. This can be reproduced trivially:
$ reprotest 'touch x' x
[..]
│ │ │ -Access: (0644/-rw-r--r--) Uid: ( 1000/inf
r-base_3.4.0.20170622-1.0~reproducible2.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bi
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/113/
Feel free to commit fixes directly to drafts/113.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for any co
Adrian Bunk:
> On Thu, Jun 22, 2017 at 08:26:00AM +0000, Ximin Luo wrote:
>> ...
>> One way to give security that is independent of third parties, is to provide
>> some sort of mathematically-verifiable proof. However the world isn't at
>> that stage yet fo
Adrian Bunk:
> On Wed, Jun 21, 2017 at 10:09:00AM +0000, Ximin Luo wrote:
>> Adrian Bunk:
>>> [..]
>>>
>>> How is that supposed to work when the compiler is not exactly identical?
>>>
>>> As an example, gcc-6 6.3.0-18 and gcc-6 6.3.0-19 w
Adrian Bunk:
> On Wed, Jun 21, 2017 at 09:28:00AM +0000, Ximin Luo wrote:
>> Adrian Bunk:
>>> On Tue, Jun 20, 2017 at 02:47:20PM -0400, Daniel Kahn Gillmor wrote:
>>>> Hi Ian--
>>>>
>>>> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote:
&
gcc-6_6.3.0-19.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman
Adrian Bunk:
> On Tue, Jun 20, 2017 at 02:47:20PM -0400, Daniel Kahn Gillmor wrote:
>> Hi Ian--
>>
>> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote:
>>> A .buildinfo file is not useful for a source-only upload which is
>>> veried to be identical to the intended source as present in the
>>> up
Hi all,
This week's blog post draft is available for review:
https://reproducible.alioth.debian.org/blog/drafts/111/
Feel free to commit fixes directly to drafts/111.mdwn in
https://anonscm.debian.org/git/reproducible/blog.git/
I'll wait at least 24 hours from the time of this email for any co
Ximin Luo:
> Ximin Luo:
>> Package: diffoscope
>> Version: 78
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> diff(1) first reads the contents of one file then the next one:
>>
>> https://sources.debian.net/src/diffutils/1:3.5-3/src/io.
Ximin Luo:
> Package: diffoscope
> Version: 78
> Severity: normal
>
> Dear Maintainer,
>
> diff(1) first reads the contents of one file then the next one:
>
> https://sources.debian.net/src/diffutils/1:3.5-3/src/io.c/#L552
>
> This means that if the "file
Package: diffoscope
Version: 78
Severity: normal
Dear Maintainer,
diff(1) first reads the contents of one file then the next one:
https://sources.debian.net/src/diffutils/1:3.5-3/src/io.c/#L552
This means that if the "files" are actually FIFOs connected to the output of a
process, as they are i
1 - 100 of 265 matches
Mail list logo
