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
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
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
>
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 the defin
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
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 ;)
N
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
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
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
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 version in
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`?
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:
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:
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: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
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
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
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
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
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:
[...]
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
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:
[...]
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
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
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
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:
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
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
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
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
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
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:
[...]
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
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:
[...]
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.
> +
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:
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
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
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:
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
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 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
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.
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
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
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 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
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
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
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
>
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
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
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)".
___
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
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 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
cy=low
+
+ * scripts/dpkg-buildpackage.pl: Use SOURCE_DATE_EPOCH instead
+of DEB_BUILD_TIMESTAMP, to be in sync with dpkg-deb.
+
+ -- Santiago Vila <sanv...@debian.org> Mon, 12 Oct 2015 11:35:30 +0200
+
dpkg (1.18.3.0~reproducible2) UNRELEASED; urgency=low
[ Jérémy Bobbio ]
d
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 t
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
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
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
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--
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
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 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
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:
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
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
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
oducible
> toolchain.
>
> [0] https://wiki.debian.org/ReproducibleBuilds
I think it would be even better if we stopped using build dates altogether,
i.e. considering them to be irrelevant.
The following patch does that:
From: Santiago Vila <sanv...@debian.org>
Subject: Do not us
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
Hmm. I think people should really stop using __DATE__ and __TIME__ as
a "normal" thing.
By patching the compiler, we are actually hiding the problem, not fixing it.
Sure, it will take more time and effort, but this is something that
each upstream author should really do, not something we should
On Tue, Sep 01, 2015 at 06:28:28PM +0200, Jérémy Bobbio wrote:
> Santiago Vila:
> > Excluding .pot files from what is considered to be the "source" might
> > be part of the problem.
>
> See tor-monitor upstream's reaction, for example:
> https://lists.aliot
Package: diffoscope
Version: 31
Greetings. I'm running jessie with several chroots created with
schroot. As a normal user, I do this:
schroot -c sid
diffoscope some.deb someother.deb
and this is the result:
CRITICAL /dev/shm is not available or not on a tmpfs. Unable to create
semaphore.
I
On Wed, Sep 02, 2015 at 02:08:42PM +, Mattia Rizzolo wrote:
> Well, quite a lot of stuff requires shm nowadays.
>
> Consider that we rb people run diffoscope inside scrhoot, and it just
> works. We have
>
> /dev/shm/dev/shmnonerw,bind 0 0
>
> in
Hi.
I have rescheduled several QA packages uploaded yesterday, but some of
them FTBFS and I don't know why. Example:
https://reproducible.debian.net/rb-pkg/unstable/amd64/cdtool.html
Build log says:
The second build failed, even though the first build was successful.
Ok, but where is the
Greetings.
I'd like this issue to be called differently.
Even if I'm a fan of dh these days, issues should better have a
neutral name and be called by the observed *effect* on the resulting
binary packages, not by the desired fix in the source package.
Suggestion:
On Fri, May 15, 2015 at 10:07:34PM +0200, Jérémy Bobbio wrote:
Hi!
Santiago Vila:
I'm thinking about the minimal find command which does the trick.
The proposed line says this:
+ find debian/tmp -depth -newermt '$(BUILD_DATE)' -print0 | \
+ xargs -0r touch
87 matches
Mail list logo
