On Sat, Jul 15, 2017 at 06:04:58PM +, Daniel Shahaf wrote:
> So: should po file generation allow the caller to control the timestamp
> that would be embedded?
Maybe, or maybe not.
But so far, the non-reproducible Debian packages using gettext I've
seen fail to be reproducible because maintain
On Wed, May 03, 2017 at 01:40:12AM +0200, Matthias Klose wrote:
> > I tried to build this package in stretch with "dpkg-buildpackage -A"
> > but it failed:
>
> fine, but you should make sure that this occurs in a distro environment as
> well.
I always do these test builds using sbuild in a chro
On Wed, Mar 22, 2017 at 03:48:02AM -0700, Mike Swanson wrote:
> root@turanga:sn# strip-nondeterminism ?.zip
> root@turanga:sn# bsdtar -tvf 1.zip
> -rwxr-xr-x 0 0 0 0 Mar 22 03:44 root
> -rw-r--r-- 0 1000 10010 Mar 22 03:44 user
> root@turanga:sn# bsdtar -tvf 2.zip
> -rwx
On Mon, Jan 16, 2017 at 02:19:44PM +, Paul Sherwood wrote:
> On 2017-01-16 11:26, Santiago Vila wrote:
> > Before I use this rationale more times in some discussions out there,
> > I'd
> > like to be sure that there is a consensus.
> >
> > What's
Greetings.
Before I use this rationale more times in some discussions out there, I'd
like to be sure that there is a consensus.
What's the definition of reproducible? It is more like A or more like B?
A. Every time the package is attempted to build, the build succeeds,
and the same .deb are alwa
Version: 67
Hi.
After building this version on stretch today 201 times, with different
autobuilders, the result was 200 successful builds and one sbuild hang.
Compared to the previous 10% failure rate, the sbuild hang is most
likely a completely different issue, so I hereby declare this bug as
"
On Fri, Jan 06, 2017 at 01:43:43PM +, Holger Levsen wrote:
> On Thu, Jan 05, 2017 at 11:36:17PM +0100, Santiago Vila wrote:
> > But let's see again when the package reaches testing.
>
> you could build that package against testing today?! once or a hundred
> times
On Thu, 5 Jan 2017, Ximin Luo wrote:
> I've uploaded version 67 with that commit reverted:
>
> https://people.debian.org/~infinity0/apt/pool/main/d/diffoscope/
Tried 100 times in sid. Built ok 100 times. This is also what happened
to version 66, so I'm not surprised.
But let's see again when th
severity 846116 important
severity 680038 important
severity 828929 important
severity 834686 important
severity 834962 important
severity 842836 important
severity 844083 important
severity 844088 important
severity 844571 important
severity 845164 important
severity 846021 important
severity 8461
Hi.
I have built version 66 one hundred times in unstable.
The builds were made on 19 different autobuilders.
The number of failed builds has been zero.
(Previously it failed 10% of the time).
If you do not remember what kind of change may have fixed this,
then there must be some broken build-dep
On Mon, Dec 26, 2016 at 07:37:55PM +, Chris Lamb wrote:
> Santiago Vila wrote:
>
> > If I do "python3 -m pytest" afterwards this is what it's shown:
> […]
> > Note: This is still diffoscope_63 in stretch, not sure if I should
> > better try the versi
On Sat, 24 Dec 2016, Ximin Luo wrote:
> For all you people that already have single-CPU KVM VMs set up, can you
> please try to reduce your test cases that still reproduce the bug?
>
> For example, can you still reproduce it with `debian/rules clean build`? What
> about `python3 -m pytest`? The
Greetings.
If the reproducible builds autobuilders continue to build with
(the equivalent of) "dpkg-buildpackage", the following FTBFS will be
missed:
Packages which FTBFS in every autobuilder, including "Arch: all" if it
were uploaded in source-only form, like this one:
https://bugs.debian.org/
Greetings.
In notes, Bug#816735 appears in a lot of places as a reason for FTBFS
bugs like this:
ImportError: No module named pep8
The bug is now closed and archived, but many of the packages having this
bug in notes happen to FTBFS again. Example:
https://tests.reproducible-builds.org/debian/
fixed 830168 2.2~git20150611.196c88+dfsg-3
thanks
Sorry, forgot to check unstable.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Package: src:python-sfml
Version: 2.2~git20150611.196c88+dfsg-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
Package: src:fuji
Version: 0.3.0-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
git.eclipse.org/gitroot
Package: src:gnat-gps
Version: 5.3dfsg-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make -C _build/la
Package: src:sfepy
Version: 2016.2-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make[3]: Entering dir
Package: src:knot
Version: 2.2.1-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make -C ./_build/latex
Package: src:pdal
Version: 1.2.0-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
Running Sphinx v1.4.4
m
Package: src:gimp
Version: 2.8.16-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
ranlib libapp.a
libtoo
Package: src:yade
Version: 1.20.0-10
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
writing toc.ncx file.
Package: src:ganeti
Version: 2.15.2-3
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
dir=doc/html/ && \
/
Package: src:wine-development
Version: 1.9.12-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
./tools/ma
Package: src:pytables
Version: 3.2.2-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
Running LaTeX files
Package: src:owncloud-client
Version: 2.2.1+dfsg-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make[6]
Package: src:slepc
Version: 3.6.3.dfsg1-6
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
fakeroot debian
Package: src:sqlalchemy
Version: 1.0.13+ds1-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
Exception oc
Package: src:pyx3
Version: 0.14.1-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make -C _build/latex a
Package: src:pyosmium
Version: 2.7.1-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
FAIL: test_location
Package: src:pyx
Version: 0.12.1-5
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make -C _build/latex al
Package: src:strongswan
Version: 5.4.0-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
configure: exit 1
Package: src:krb5
Version: 1.14.2+dfsg-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
sphinx-build -t
Package: src:pysph
Version: 0~20160514.git91867dc-3
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make d
Package: src:apcupsd
Version: 3.14.12-1.2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
checking for shu
Package: src:verbiste
Version: 0.1.43-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
In file included f
Package: src:uwsgi
Version: 2.0.12-7
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Hello Jonas.
This package currently fails to build in stretch:
[...]
test -x debian/rules
rm -
Package: src:qtwebkit-examples-opensource-src
Version: 5.5.1+dfsg-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
-
Package: src:pandas
Version: 0.18.0+git114-g6c692ae-1
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Hello Yaroslav.
This package currently fails to build in stretch:
[...]
ERROR
Package: src:brltty
Version: 5.3.1-3
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
make[3]: Entering dir
Package: src:gcc-5-cross-ports
Version: 9
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
patching file sr
Package: src:gcc-5-cross
Version: 23
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
patching file src/lto
Package: src:tumiki-fighters
Version: 0.2.dfsg1-7
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
gdc -o t
Package: src:soundscaperenderer
Version: 0.4.2~dfsg-5
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
LaT
Package: src:libgphoto2
Version: 2.5.10-2
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package currently fails to build in stretch:
[...]
libtool: link:
[ Note: this is a reply to a message from reproducible-commits,
trimming the subject just a little bit ]
On Fri, Jun 03, 2016 at 04:49:10PM +, Holger Levsen wrote:
> +ftbfs_build-indep_not_build_on_armhf:
> + description: |
> +Package build-indep target will fail on armhf.
> + determin
reassign 824253 src:linux
close 824253
forcemerge 822393 824253
affects 822393 src:scamper
thanks
On Sat, May 14, 2016 at 09:07:57AM +0100, Chris Lamb wrote:
> Source: scamper
> Version: 20141211d-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-builds@lists.a
severity 820990 wishlist
user reproducible-builds@lists.alioth.debian.org
usertags 820990 + environment
thanks
Adding this one to the collection of bugs tracked by reproducible
builds.
___
Reproducible-builds mailing list
Reproducible-builds@lists.aliot
user reproducible-builds@lists.alioth.debian.org
usertags 820932 - environment
thanks
Sorry, this was not the bug I wanted to tag.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/ma
severity 820932 wishlist
user reproducible-builds@lists.alioth.debian.org
usertags 820932 + environment
thanks
In other words: Build is not reproducible.
I'm adding this one to the collection of bugs tracked by reproducible
builds.
Thanks.
___
Reprodu
On Fri, Nov 27, 2015 at 11:12:50AM +0100, Jérémy Bobbio wrote:
> I think the question can be phrased as: should architecture-independent
> packages be buildable on all architectures?
>
> My own answer would be: yes, as long as they don't mandate a particular
> architecture in their Build-Depends-I
On Thu, Nov 26, 2015 at 09:03:24PM +0100, Sebastiaan Couwenberg wrote:
> Control: tags -1 - moreinfo unreproducible
> Control: tags -1 + help
>
> Hi Santiago,
>
> qgis indeed fails to build in testing, and testing only.
>
> I have no clue what's causing it, but it's I'm pretty sure it's not qgis
On Thu, Nov 26, 2015 at 06:16:30PM +0100, Bas Couwenberg wrote:
> On 2015-11-26 18:10, Santiago Vila wrote:
> >On Thu, Nov 26, 2015 at 05:14:26PM +0100, Bas Couwenberg wrote:
> >>Have you verified that it affects unstable too? Because my unstable
> >>builds succeed ju
On Thu, Nov 26, 2015 at 05:14:26PM +0100, Bas Couwenberg wrote:
> Control: severity -1 important
> Control: tags -1 unreproducible moreinfo
>
> Hi Santiago,
>
> Thanks for your work on reproducible builds.
>
> On 2015-11-26 16:06, Santiago Vila wrote:
> >This pack
Package: src:qgis
Version: 2.8.3+dfsg-5
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious
Dear maintainer:
This package fails to build from source in testing/amd64.
Follows a snippet from the build log:
--
Hi.
Yesterday night, in another email, Holger told me that perhaps those
packages that I added and then removed should be added again.
I started to write this reply but I think it is better to discuss it
here as I think it could be of general interest.
Let me start by saying that IMHO none of t
On Wed, Nov 25, 2015 at 10:57:48PM +0100, Holger Levsen wrote:
> > The "right" fix for this very little anomaly is that they should not
> > be in the list of packages to be built to begin with.
>
> nope, we have something better, see above :) how did you notice?
I was making package lists to chec
On Wed, Nov 25, 2015 at 09:52:55PM +0100, Holger Levsen wrote:
> Hi Santiago,
>
> On Mittwoch, 25. November 2015, Santiago Vila wrote:
> > In addition to scsh-0.6, we should not be trying to build these
> > packages on amd64:
> >
> > cmucl
> >
B1;2802;0cOn Tue, Nov 10, 2015 at 12:41:51AM +, Chris Lamb wrote:
> Santiago Vila wrote:
>
> > So, I don't think that this patch would really be "beneficial to our
> > project", as it will only serve to artificially "improve" the statistics.
On Mon, Nov 09, 2015 at 01:02:40AM +0100, Dhole wrote:
> It would be very beneficial to our project (and other free software
> projects working on reproducible builds) if gcc supported this feature.
Hi.
I have very mixed feelings about this kind of patches.
I fear that by modifying gcc to hide t
Hi.
Our modified doxygen is currently uninstallable in our modified
environment.
# apt-get install doxygen
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situ
On Mon, Oct 26, 2015 at 04:20:00PM +0100, Axel Beckert wrote:
> Hi,
>
> Reiner Herrmann wrote:
> > While working on the "reproducible builds" effort [1], we have noticed
> > that fte could not be built reproducibly.
> > The created tarball with example files is not sorted.
> >
> > The attached pa
On Tue, Oct 20, 2015 at 04:22:32PM +0300, Esa Peuha wrote:
> The solution is to simply build-depend on locales-all instead of
> locales and use the locale files in the default location; [...]
Considering that locales-all has an installed-size of 120 M,
I would not use the "simply" word for that.
Hello Axel.
I can only give partial answers and minor comments, Holger and Mattia
probably have an authoritative answer.
> Are not all chroots used by the reproducible-builds project setup
> the same way?
Assuming that by "setup the same way" we are not talking about all the
things that change b
On Sat, Oct 17, 2015 at 02:36:54PM +0100, Chris Lamb wrote:
> > What should we do with this bug, then? Should we leave it closed even
> > if it's apparently not fixed?:
>
> I am unclear why this requires any special treatment or private
> discussion.
Note: I do not consider this list to be privat
reopen 801376
found 801376 3.4.3-7
thanks
Hi.
Reopening because the problem is still happening.
A few examples:
https://reproducible.debian.net/rb-pkg/unstable/amd64/lttnganalyses.html
https://reproducible.debian.net/rb-pkg/unstable/amd64/websocket-client.html
In both cases the buildinfo says
On Sat, Oct 17, 2015 at 04:57:46PM +0300, Esa Peuha wrote:
> Many apertium language pair packages fail with
>
> localedef -f UTF-8 -i en_US ./debian/tmp/locale/en_US.UTF-8/
> character map file `UTF-8' not found: No such file or directory
> cannot read character map directory `/usr/share/i18n/char
Ok, Chris said, and I agree, that in general we should not submit bugs
without patches.
What should we do with this bug, then? Should we leave it closed even
if it's apparently not fixed?:
https://reproducible.debian.net/dbdtxt/unstable/amd64/websocket-client_0.18.0-2.debbindiff.txt
[ Note: I'm
On Fri, Oct 16, 2015 at 03:22:34PM +0200, Jérémy Bobbio wrote:
> I think it's sound to also remove issues due to Debian-specific
> toolchain once it has been fixed. I don't think there's much value in
> keeping tabs on something like ordering problems in debhelper the
> required `sort` has been add
On Fri, Oct 16, 2015 at 01:40:22PM +0200, Jérémy Bobbio wrote:
> I would say that it's better to keep any issue which other free software
> projects might bump into.
Agreed.
> I know it's far from a clear guideline. In any
> cases, we have the history, as Holger said.
I'd like to avoid having to
On Fri, Oct 16, 2015 at 01:15:33PM +0200, Holger Levsen wrote:
> On Freitag, 16. Oktober 2015, Santiago Vila wrote:
> > Hi. Do we expire issues (not packages) when no package currently have them?
>
> https://reproducible.debian.net/index_issues.html -> scroll down to the
>
Hi. Do we expire issues (not packages) when no package currently have them?
(I would prefer to keep them).
Thanks.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/r
Ooops! Sorry, didn't test it well enough.
This seems to work:
export LC_ALL=C && cp [a-z]*.1 $M
Thanks to Jakub for spotting the error.
(Please keep the Cc: if you can).
Thanks.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alio
Package: autoconf2.13
Version: 2.13-66
Severity: wishlist
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
User: reproducible-builds@lists.alioth.debian.org
Usertags: locale
Tags: patch
Hi.
While working on the “reproducible builds” effort [1], we have noticed
that this package could not
Hi.
Is this really fixed in python3-defaults 3.4.3-7?
There is at least one package still showing the error:
https://reproducible.debian.net/rb-pkg/unstable/amd64/lttnganalyses.html
and the buildinfo file says "python3 (= 3.4.3-7)".
___
Reproducible-
On Mon, Oct 12, 2015 at 01:01:24PM +0200, Holger Levsen wrote:
> check out the pu/reproducible_builds branch…
Ah, ok. Done that as well.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-
3) UNRELEASED; urgency=low
+
+ * scripts/dpkg-buildpackage.pl: Use SOURCE_DATE_EPOCH instead
+of DEB_BUILD_TIMESTAMP, to be in sync with dpkg-deb.
+
+ -- Santiago Vila Mon, 12 Oct 2015 11:35:30 +0200
+
dpkg (1.18.3.0~reproducible2) UNRELEASED; urgency=low
[ Jérémy Bobbio ]
diff -ru d
dpkg_1.18.3.0~reproducible3.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 Mon, Oct 12, 2015 at 11:11:19AM +0300, Niko Tyni wrote:
> On Sun, Oct 11, 2015 at 07:50:49PM +0200, Holger Levsen wrote:
> > On Sonntag, 11. Oktober 2015, Niko Tyni wrote:
> > > It's indeed an unfortunate interaction of dh_installdocs and disorderfs
> > > when installing directory hierarchies.
>
On Sun, Oct 11, 2015 at 12:35:18PM +, Santiago Vila wrote:
> │ -rw-r--r-- 0/0 4 Oct 11 12:08 2015 debian-binary
> │ -rw-r--r-- 0/0 4814 Oct 11 12:08 2015 control.tar.gz
> │ -rw-r--r-- 0/0 250668 Oct 11 12:08 2015 data.tar.xz
> │ +rw-r--r-- 0/0 4 Oct 11 12:10 2015 d
Hi.
Some packages have started to FTBR again:
--- aaa/dialog_1.2-20150920-1_amd64.deb
+++ bbb/dialog_1.2-20150920-1_amd64.deb
├── metadata
│ @@ -1,3 +1,3 @@
│ -rw-r--r-- 0/0 4 Oct 11 12:08 2015 debian-binary
│ -rw-r--r-- 0/0 4814 Oct 11 12:08 2015 control.tar.gz
│ -rw-r--r-- 0/0 250668 Oct
On Sun, Oct 11, 2015 at 12:11:59PM +0200, Holger Levsen wrote:
> On Samstag, 10. Oktober 2015, Santiago Vila wrote:
> > This suggests that the problem is maybe related to one or more of the
> > dh_* tools and/or different filesystem ordering, as the source
> > packages themsel
On Sun, Oct 11, 2015 at 12:11:59PM +0200, Holger Levsen wrote:
> you are subscribed to this list, are you?
Yes, I am. Not that it means I will read it every day but for the
purposes of dropping Cc, yes you can.
Thanks.
___
Reproducible-builds mailing l
Greetings.
I've created a new issue for this:
drwxr-xr-x root/root 0 2012-04-14 07:35:49 ./usr/share/doc-base/
-rw-r--r-- root/root 248 2010-07-03 15:57:43
./usr/share/doc-base/llgal-howto
drwxr-xr-x root/root 0 2012-04-14 07:35:49 ./usr/share/doc/llgal/
-rw-r--r-- root
On Fri, Oct 09, 2015 at 09:30:30PM +0100, Chris Lamb wrote:
> (As an aside, I'm not sure we-the-Reproducible-team should be so keen to
> file toolchain bugs without patches unless we are a little more
> confident about the certainty and/or fix required to resolve them. We
> run the risk of exhausti
retitle 801376 pyversions emits requested versions in non-determinstic order
reassign 801376 python3-defaults 3.4.3-6
tags 801376 + patch
thanks
Cc to control@b.d.o so that the command takes effect.
___
Reproducible-builds mailing list
Reproducible-buil
Hi.
This bug is worse than I expected.
I have a set of ten packages affected by this problem. Every time I
test them, I get a different subset of reproducible and unreproducible
packages among them. This is the data I collected today:
aiozmqNo No Yes
debmake No No N
Source: dh-python
Version: 2.20150826
User: reproducible-builds@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Hello Piotr.
While working on the "reproducible builds" effort [1], we have noticed
that dh-python generates a Depends line which depends on the locale
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
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 l
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
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:
On Sun, Oct 04, 2015 at 01:30:22PM +0200, Andreas Metzler wrote:
> Given this problem
> Package build is not reproducible since the output
> depends on the sort order which is locale dependent
The problem is actually wider than that.
Some packages behave differently because of the locale itse
On Wed, Sep 30, 2015 at 12:25:10PM +0200, Holger Levsen wrote:
> it has been reverted.
Thanks a lot.
Would there be an easy way to discard all the tests which have been
made with a timestamp in the past? I guess nearly 100% of them are
going to be false positives (I first noticed about this in a
On Wed, Sep 30, 2015 at 10:57:20AM +0100, Chris Lamb wrote:
> > There is a minimum of sanity that we should assume on the autobuilders,
>
> Agree in principle..
>
> > namely, that packages are built on a date which is later than the one
> > in the last changelog entry.
>
> .. but why should this
Hi.
Are we building packages in the *past* now?:
https://reproducible.debian.net/rb-pkg/unstable/amd64/base-files.html
There is a minimum of sanity that we should assume on the autobuilders,
namely, that packages are built on a date which is later than the one
in the last changelog entry.
So pl
On Tue, Sep 29, 2015 at 05:08:17PM +0200, Holger Levsen wrote:
> I agree and am wondering if we should actually do this, and limit
> (maintainer)
> notifications to unstable? What do you think?
Are we really spamming people with this?
(spam = unsolicited bulk email)
I know that other "services
Hi.
Using
deb http://reproducible.alioth.debian.org/debian/ ./
even the most simple package created makes lintian to complain:
apt-get -b source base-files
lintian base-files_9.4_amd64.deb
Skipping base-files_9.4_amd64.deb: syntax error at line 19: Duplicate field
package.
$ ar x base-fil
On Mon, Sep 21, 2015 at 06:21:16PM +0100, Chris Lamb wrote:
> > I think it would be even better if we stopped using build dates
> > altogether,
> > i.e. considering them to be irrelevant.
>
> Of course, but that involves diverging from upstream.
Well, it depends.
My theory is that stop using the
1 - 100 of 118 matches
Mail list logo
