Processed: tagging 842834
Processing commands for cont...@bugs.debian.org: > tags 842834 + pending Bug #842834 [src:diffoscope] diffoscope: building unchanged in jessie-bpo fails Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 842834: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842834 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#829738: tar: --no-recursion option is ignored when creating archives
This seems to have been an intentional upstream change. --no-recursion now applies only to the following options, until cancelled by a following --recursion. http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20151012/003642.html http://git.savannah.gnu.org/cgit/tar.git/commit/?id=2bd9c15391b0bd6ef0bff76aebf09cfb53003199 The upstream documentation is fixed in Git (post-1.29) to put --no-recursion before -T -. http://git.savannah.gnu.org/cgit/tar.git/commit/?id=a2fd82f62285d647dac968108eee02457255eff7 Anders ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: accessibility of the reproducible builds page
Hi Sebastian, thanks for reaching out to us about the accessibility and layout issues in our webpages! Actually the best way to criticize is simply to send patches fixing stuff. We love those! ;-) Regarding the iframes, I agree those are annoying to use, at least sometimes. We choose them because they allow us to use diffoscope's html output without modification (so we have the navigation menu on the left). Another challenge is: that menu on the left is rather "dynamic", it changes when the same package is tested in another arch/suite. I'd be very glad to get rid off iframes. I've not seen a proposal which works and doesnt requiere fully dynamic pages. Currently the pages use static html… -- cheers, Holger signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] arm64 reproducible build network
Hi Axel, On Tue, Dec 06, 2016 at 09:05:32PM +0100, Axel Beckert wrote: > Not that I want to undermine Martin's efforts, but I wonder if we > should start by taking some more boards into account for arm64, too: we actually have arm64 hardware available now, 8 machines with octocores and 64 gb ram, we're just waiting to use postgresql instead of sqlite so we can handle all the new jobs… -- cheers, Holger signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Build even further in the future to catch more non-determinstic behaviour.
On Sat, Dec 10, 2016 at 12:27:12AM +, Holger Levsen wrote: > I'm not sure but I think that's too much. I think the lifetime of a > stable release is ~5 years, at least after the release, so maybe 7 years > or so, but not 10. Also I'm not sure we deliberatly wont to break stuff > with >3650 days anyway… > > So I'd rather propose 2555+31+2=2588 days… Currently any date later than 2022-11-19 will probably not work, as then the jessie signing keys are expiring and packages could not be installed. Though it could probably be worked around by resigning Release files etc. signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: 回复：转发：Verification of known issues related to reproducible builds
你好: > Thanks for your reply. In fact, your chinese are very good. > > My issues are about the consistency of binary files byte for byte. > Hehe, good to know that what I said made sense. But it's not good enough to talk with, I do have to write mostly in English, sorry! :) It would be much easier to help you, if you can tell us what software you are trying to reproduce the consistency of. Many reproducibility issues (maybe including the ones you described below) they sometimes happen, sometimes do not happen. Until you do this, it's hard for us to give exact answers to your questions. I can only give half-answers to your questions. (See further below.) Ideally you would show us the output of diffoscope, something like this: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/rustc.html It is generated by this program: https://packages.debian.org/sid/diffoscope Unfortunately at this time, it only works well on Debian GNU/Linux and Arch Linux. But we are happy to add support for other platforms, if other people can contribute this. If you want to do that, the source code is here: https://anonscm.debian.org/cgit/reproducible/diffoscope.git/ You can try it online here https://try.diffoscope.org/ but for security reasons, it only tries to process small differences. For files with very large differences, you will need to run diffoscope yourself, locally. > ---原始邮件--- > 发件人: "Ximin Luo" > 发送时间: 2016年12月10日 00:08:58 > 收件人: > "软件重构";"马艳平";"你好"<763413...@qq.com>; > 主题: Re: 转发：Verification of known issues related to reproducible builds > > [..] > > 你好: >> ---原始邮件--- >> 发件人: "自己"<763413...@qq.com> >> 发送时间: 2016年12月7日 10:09:10 >> 收件人: "软件重构"; >> 主题: Verification of known issues related to reproducible builds >> >> >> It is difficult to validate some issues, as bellow: >> 1)timestamps generated by mangosdk spiprocessor >> >> It is difficult to get the class org.mangosdk.spi.processor.SpiProcessor. >> The source code for this and related classes are here: https://sources.debian.net/src/libspi-java/0.2.4-1/src/org/mangosdk/spi/processor/SpiProcessor.java/?hl=56#L56 Older and future versions are / will be here: https://sources.debian.net/src/libspi-java/ >> 2)random order in java jar manifest mf >> >> I got two java .jar files written by Eclipse and command jar respectively. >> But the MANIFEST.MF of both java .jar files were identical. >> Sometimes manifest.mf might be autogenerated by another process, or they might contain extra things that are not in your own manifest.mf, and these extra things might have a random order. If you don't see this issue in your own software, then 都好, 不用着急. :) >> 3)timestamps added by xbean spring >> >> In fact, i do not know how to validate this issue. >> >> 4)random order in plexus comonents xml >> I tried so many times to install Plexus plugin into Eclipse, but never >> success. >> Similar to what I said above - if you don't need xbean nor plexus to build your software, then you don't need to worry about these issues. Ximin -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
