On Thu, Oct 08, 2015 at 05:39:53PM +, Jérémy Bobbio wrote:
> dpkg_1.18.3.0~reproducible2.dsc has just been uploaded [...]
Note: This release finally fixes the duplicate-files-in-control.tar.gz
problem I reported a few days ago:
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week
Package: diffoscope
Version: 36
seen in rb.d.n:
in experimental, haskell-authenticate-oauth/1.5.1.1-4:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/diffoscope/__main__.py", line 137, in
main
sys.exit(run_diffoscope(parsed_args))
File "/usr/lib/python3/dist-pack
dpkg_1.18.3.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/li
On Donnerstag, 8. Oktober 2015, Holger Levsen wrote:
> btw, the build results today are also still broken:
seems I've fixed this by now.
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducib
Hi,
On Donnerstag, 8. Oktober 2015, Santiago Vila wrote:
> If we are unable to reproduce the environment to begin with, i.e. if
> we don't even give the package the opportunity to show that it's
> reproducible, then it is not the package's fault, and I see no reason
> to mark it as unreproducible.
On Thu, Oct 08, 2015 at 03:25:38PM +, Santiago Vila wrote:
> under the "same" environment (build-depends)
Sorry, I really meant "installed packages and their versions" here.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debia
On Thu, Oct 08, 2015 at 03:01:34PM +, Mattia Rizzolo wrote:
> If that fields differs again [...] it just gives up and mark the
> package as unreproducible
The last item (mark as unreproducible) does not seem right to me.
A package is said to be reproducible when you build it two times
under t
On Thu, Oct 08, 2015 at 04:55:35PM +0200, Holger Levsen wrote:
> Hi,
>
> On Donnerstag, 8. Oktober 2015, Santiago Vila wrote:
> > I've seen several cases where a package is considered not reproducible
> > just because the build environment changed between build1 and build2.
>
> this should not ha
Hi,
btw, the build results today are also still broken:
context: https://reproducible.debian.net/unstable/amd64/sagasu
[16:23] < h01ger> | something looks very fishy here
[16:24] < h01ger> | but i dont get what
[16:25] < h01ger> | the diffoscope diff of the unreproducible builds
.
Hi,
On Donnerstag, 8. Oktober 2015, Santiago Vila wrote:
> I've seen several cases where a package is considered not reproducible
> just because the build environment changed between build1 and build2.
this should not happen… end of the story. If it happens, its a bug in the CI.
and today it als
Hi.
I've seen several cases where a package is considered not reproducible
just because the build environment changed between build1 and build2.
It would be great if, by design, this did never happen, but I
understand this will not be easy to implement.
However, I can think of some workarounds:
11 matches
Mail list logo