Bug#1072575: diffoscope: drop dependency on liblz4-tool
tags 1072575 + pending thanks Many thanks. Applied in Git, pending upload later this week: https://salsa.debian.org/reproducible-builds/diffoscope/commit/6a71d08a0b9bd5e0f6551b1056186e58b50bdbde debian/control | 2 +- debian/tests/control | 2 +- diffoscope/external_tools.py | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1072094: ruby-pgplot: please make the build reproducible
Source: ruby-pgplot
Version: 0.2.0-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
ruby-pgplot could not be built reproducibly.
The previous patch was not sufficient as we (apparently) can't
guarantee the mtime of the files in the build directory. A patch is
attached (that patches the existing patch!) that more reliably uses
SOURCE_DATE_EPOCH if its available.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/0001-make-the-build-reproducible.patch 2024-05-28
12:29:06.077839737 +0100
--- b/debian/patches/0001-make-the-build-reproducible.patch 2024-05-28
12:33:57.999806104 +0100
@@ -7,16 +7,19 @@
doc/myrd2html.rb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-diff --git a/doc/myrd2html.rb b/doc/myrd2html.rb
-index 134dc39..a259103 100644
a/doc/myrd2html.rb
-+++ b/doc/myrd2html.rb
-@@ -13,7 +13,7 @@ while /^--/ =~ ARGV[0]
+--- ruby-pgplot-0.2.0.orig/doc/myrd2html.rb
ruby-pgplot-0.2.0/doc/myrd2html.rb
+@@ -13,7 +13,12 @@ while /^--/ =~ ARGV[0]
end
rdfile = ARGV.shift
-$date = File.mtime(rdfile).strftime("%b %d %Y")
-+$date = File.mtime(rdfile).utc.strftime("%b %d %Y ")
++if ENV['SOURCE_DATE_EPOCH'].nil?
++ build_date = Time.now
++else
++ build_date = Time.at(ENV['SOURCE_DATE_EPOCH'].to_i).gmtime
++end
++$date = build_date.utc.strftime("%b %d %Y ")
case $lang
when 'ja'
--- a/doc/myrd2html.rb 2024-05-28 12:29:06.077839737 +0100
--- b/doc/myrd2html.rb 2024-05-28 12:32:04.0 +0100
@@ -13,7 +13,7 @@
end
rdfile = ARGV.shift
-$date = File.mtime(rdfile).utc.strftime("%b %d %Y ")
+$date = File.mtime(rdfile).strftime("%b %d %Y")
case $lang
when 'ja'
Bug#1072093: python-tld: ships test coverage directly under /usr/lib/python3/dist-packages/
Source: python-tld Version: 0.11.11-4 Severity: normal User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that python-tld could not be built reproducibly. This was because it ships test coverage information directly under /usr/lib/python3/dist-packages (which, in turn, contain various timetamps that led to it being detected in this way). I'm not sure it is valuable to ship the test coverage to begin with, but at the very least it probably not be shipped in that shared Python directory. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1070965: rtorrent: does not start due to soname update
Liam Stitt wrote: > libxmlrpc-core-c3t64 has bumped that soname to .4, so presumably a rebuild > will > fix this. A rebuild will indeed fix this, or at least rebuilding rtorrent locally fixes this for me. Can the maintainer therefore please request a binNMU? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1069329: fixed in diffoscope 266
Hi Paul, > Hmm, I still get a hex diff with the test case I posted in the bug: Ah, I foolishly didn't check back with the original test case. The root cause here, if I can call it that, is that we were calling "xz --list --verbose" and not specifying a second "--verbose". This has now been remedied in Git, which will most likely be released on Friday 17th May. I've used your original test case as a literal test fixture, and can confirm it now shows a difference. Given the extra verbose information, I did alas make a related change so that it will not show the "--verbose --verbose" output if there are differences between the files contained within the .xz. Otherwise every single .deb package would show a very lengthy and distracting output. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Holger Levsen wrote: > I'm not sure how --debug output should survive, but you mean just > running diffoscope with an added --debug option? Ah, yeah. It won't survive from Jenkins' log perspective, huh? Hmm, the --debug output could perhaps to be directed straight to an on-disk file. Given that that should be flushed after every line, that should survive an OOM kill. If not, hmm, I'll have a think. Either way, apologies that I'm not more familiar with all the abstraction layers in our setup and thus which might survive an OOM. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Holger Levsen wrote: >> Hm, I can't seem to reproduce the crash with these files. In the first >> instance, can you paste a traceback or similar of the crash in >> question? Maybe it is fixable just from that without having to find >> and upload more files, etc. > > I don't have a traceback as the oom-kill also kills the surrounding > processes... Ah, I was hoping that the systemd slice apparatus would be able to contain any traceback, but now that I think of it, being OOM-killed is not quite the same as CPython-level crash (and thus traceback). > https://tests.reproducible-builds.org/debian/artifacts/r00t-me/trixie_i386_dasel_tmp-kqFaQ/ > is maybe working as in crashing for you? Alas, this works for me and does not crash. I suppose the next thing might be to try and run with --debug? That way, we might be able to determine which file, comparator or external tool was being run when diffoscope invoked the ire of the oom-killer. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1071064: tkgate: please make the build reproducible
Source: tkgate Version: 2.1+repack-6 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that tkgate could not be built reproducibly. This is because the binary package ships test output that varies in a nondeterministic manner. For example: │ │ │ ├── ./usr/share/doc/tkgate-data/examples/verga/probe1.out │ │ │ │┄ Ordering differences only │ │ │ │ @@ -1,9 +1,9 @@ │ │ │ │ -valueof top.i 32'hx @ 0 │ │ │ │ valueof top.a 32'hx @ 0 │ │ │ │ +valueof top.i 32'hx @ 0 │ │ │ │ tell bob top.i 32'h0 @ 0 │ │ │ │ tell bob top.a 32'h0 @ 0 │ │ │ │ tell bob top.i 32'h1 @ 1 │ │ │ │ tell bob top.i 32'h2 @ 2 │ │ │ │ tell bob top.a 32'h2 @ 2 │ │ │ │ tell bob top.i 32'h3 @ 3 │ │ │ │ tell bob top.i 32'h4 @ 4 Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-05-13 18:07:39.124000324 +0100 --- b/debian/rules 2024-05-13 18:18:23.558129447 +0100 @@ -21,3 +21,4 @@ override_dh_auto_test: cd test/ && sh runtests.sh + find test/ -name *.out | xargs rm -f
Bug#1071063: screenkey: malformed debian/changelog
Package: screenkey Version: 1:1.5-4 Severity: serious User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, This might not *strictly* be an RC bug, but the latest upload of screenkey has the following entry in debian/changelog: <<< screenkey (1:1.5-4) unstable; urgency=medium * fixed d/watch * bumped Standards-Version: 4.7.0 * removed the stance X-Python-Version -- >>> Note in particular the missing date. This doesn't break dak, otherwise it would not have been accepted by the archive, but it breaks many other tools (eg. gbp-buildpackage, etc.) as well as other things. For example, the package is not reproducible because SOURCE_DATE_EPOCH cannot be extracted from the debian/changelog. When building the package you should have seen warnings by, for instance, dh_installchangelogs, dpkg-gencontrol, dpkg-genchanges, etc. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1069322: diffoscope crashes when trying to compare unreproducible src:dasel build artifacts
Holger Levsen wrote: > I'm attaching the crashing artifacts now to this bug report, however minus > the orig.tar.gz files, though I suppose that the .deb files are enough to > crash diffoscope anyway... Hm, I can't seem to reproduce the crash with these files. In the first instance, can you paste a traceback or similar of the crash in question? Maybe it is fixable just from that without having to find and upload more files, etc. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1070754: gensio: please make the build reproducible
Source: gensio Version: 2.8.2-6.1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: environment buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that gensio could not be built reproducibly. This is because some shell script wrappers for some files shipped under examples/ were not reproducible. A patch is attached — I think that we were simply missing a couple of files to remove. An alternative might be something like: find debian/**/examples/ -type f -executable -delete [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk ` a/debian/rules 2024-05-08 14:35:03.861131982 +0100 --- b/debian/rules 2024-05-08 14:46:45.619810890 +0100 @@ -41,7 +41,9 @@ debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/basic_client \ debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/basic_server \ debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/basic_server_sync \ - debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/basic_server_sync_fork + debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/basic_server_sync_fork \ + debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/poll_and_gensio \ + debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/use_iods mkdir debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/c++ cp c++/examples/* debian/libgensio-dev/usr/share/doc/libgensio-dev/examples/c++ rm -rf \
Bug#1070416: src:diffoscope: unsatisfied build dependency in testing: aapt
Paul Gevers wrote: > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. Looks like this happened due to these RC bugs: https://bugs.debian.org/1062206 https://bugs.debian.org/1062110 https://bugs.debian.org/1062209 i.e. it wasn't that aapt was removed or barred from testing for some reason specific to aapt's code or license, etc. It is, as I understand it, not impossible that it might return to testing without further intervention on our part..? Otherwise, we can very cleanly remove this build dependency, even keeping the .arsc file support in diffoscope itself. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1069822: python-gvm: please make the build reproducible
Source: python-gvm
Version: 24.3.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
python-gvm could not be built reproducibly.
This is because the docs embed the current build year. A patch is
attached that uses SOURCE_DATE_EPOCH [1] if available.
[0] https://reproducible-builds.org/
[0] https://reproducible-builds.org/docs/source-date-epoch/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/Reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/Reproducible-build.patch 2024-04-25 11:55:22.120958744
+0100
@@ -0,0 +1,33 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-04-25
+
+--- python-gvm-24.3.0.orig/docs/conf.py
python-gvm-24.3.0/docs/conf.py
+@@ -16,7 +16,13 @@
+
+ import os
+ import sys
+-from datetime import datetime
++import time
++import datetime
++
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
+
+ sys.path.insert(0, os.path.abspath(".."))
+
+@@ -24,10 +30,8 @@ import gvm # noqa: E402
+
+ # -- Project information -
+
+-year = datetime.now().year
+-
+ project = "python-gvm"
+-copyright = f"2018 - {year}, Greenbone AG"
++copyright = f"2018 - {build_date.year}, Greenbone AG"
+ author = "Greenbone AG"
+
+ # The short X.Y version
--- a/debian/patches/series 2024-04-25 11:43:24.482946466 +0100
--- b/debian/patches/series 2024-04-25 11:55:21.240959905 +0100
@@ -1,2 +1,3 @@
change-path-unix-sockets.patch
Remove-furo-theme-in-docs.patch
+Reproducible-build.patch
Bug#1069784: python-itemloaders: please make the build reproducible
Source: python-itemloaders
Version: 1.2.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
python-itemloaders could not be built reproducibly.
This is because the manual pages embed the build year in copyright
messages. A patch is therefore attached that seeds the date from
SOURCE_DATE_EPOCH if available.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/0002-Reproducible-build.patch 1970-01-01
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch 2024-04-24
16:57:48.698090140 +0100
@@ -0,0 +1,37 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-04-24
+
+--- python-itemloaders-1.2.0.orig/docs/conf.py
python-itemloaders-1.2.0/docs/conf.py
+@@ -13,7 +13,8 @@
+
+ import os
+ import sys
+-from datetime import datetime
++import time
++import datetime
+ from os import path
+
+ import sphinx_rtd_theme
+@@ -24,6 +25,11 @@ import sphinx_rtd_theme
+ sys.path.append(path.dirname(__file__))
+ sys.path.insert(0, path.dirname(path.dirname(__file__)))
+
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
++
+ # General configuration
+ # -
+
+@@ -51,7 +57,7 @@ master_doc = "index"
+
+ # General information about the project.
+ project = "itemloaders"
+-copyright = "2020\u2013{}, Zyte Group Ltd".format(datetime.now().year)
++copyright = "2020\u2013{}, Zyte Group Ltd".format(build_date.year)
+
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/series 2024-04-24 16:32:44.741767684 +0100
--- b/debian/patches/series 2024-04-24 16:50:13.629191809 +0100
@@ -1 +1,2 @@
0001-Use-local-intersphinx-files.patch
+0002-Reproducible-build.patch
Bug#1069709: dpb: please make the build reproducible
Source: dpb
Version: 0.0~git20240401+4c3057874
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
dpb could not be built reproducibly.
This is because it embedded timestamps in .pdf files and in "generated
on.." comments in various scripts. (Ideally the latter could be
removed entirely.)
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/create-buildscript.sh 2024-04-23 09:54:18.460456472 +0100
--- b/create-buildscript.sh 2024-04-23 10:03:12.374039772 +0100
@@ -11,7 +11,7 @@
"
cat Title.nw Part1.nw Part2.nw Part3.nw Part4.nw Part5.nw Part6.nw >
BuildWithGBPg.nw
-t=`date +%c`
+t=$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" -R)
function build_script()
{
--- a/debian/rules 2024-04-23 09:54:18.460456472 +0100
--- b/debian/rules 2024-04-23 09:59:42.766516568 +0100
@@ -5,6 +5,7 @@
export DH_VERBOSE=1
export DH_OPTIONS=-v
+export FORCE_SOURCE_DATE=1
%:
dh $@
Bug#1069663: dub: please make the build reproducible
Source: dub
Version: 1.36.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
dub could not be built reproducibly.
This is because the build system embeds timestamps in its man pages:
├── ./usr/share/man/man1/dub-add-local.1.gz
│ ├── dub-add-local.1
│ │ @@ -1,8 +1,8 @@
│ │ -.TH DUB-ADD-LOCAL 1 "2025-05-24" "The D Language Foundation" "The D
Language Foundation"
│ │ +.TH DUB-ADD-LOCAL 1 "2024-04-21" "The D Language Foundation" "The D
Language Foundation"
(etc.)
A patch is attached that simply exports dub's custom DIFFABLE
environment variable. This was seemingly introduced to make these
manpages, well, 'diffable' — that is to say, so that they generated in
a deterministic manner.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/rules 2024-04-22 10:34:28.039060412 +0100
--- b/debian/rules 2024-04-22 10:48:00.675980092 +0100
@@ -6,7 +6,7 @@
DEB_VERSION := $(shell dpkg-parsechangelog | awk '/^Version: / { print $$2 }')
export GITVER=$(DEB_VERSION)
-
+export DIFFABLE=1
export DFLAGS=-frelease -fall-instantiations
%:
Bug#1068890: diffoscope: --hard-timeout option
Vagrant Cascadian wrote: > On 2024-04-16, Chris Lamb wrote: >> However, I think this first iteration of --hard-timeout time has a few >> things that would need ironing out first, and potentially make it not >> worth implementing: >> >> (1) You suggest it should start again with "--max-container-depth 3", >> but it would surely need some syntax (or another option?) to control >> that "3" (but for the second time only). > > What about going the other direction ... starting with a very small > value for max-container-depth, and incrementally increasing it, > generating a report (or at least storing sufficient data to generate > one) in between each increment, so you always get some information, but > essentially incrementally increase the resolution? > > Or would that approach just be too inefficient? This is probably a separate required best suited to another issue at this point, but I do like the idea of being able to incrementally increase the resolution over time. Depending on how it worked in practice, there should not be significant overhead in managing this if, say, the commands that could not be run "in time" would have token placeholders internally that rendered to text in the output rather than non-trivial/expensive binary diffs. On the negative side though, I think this would still require a robust way of killing long-running processes as outlined previously. But moreover it would require a HUGE reworking of how diffoscope handles containers and recurses into nested structures in its tree-like style. Indeed, thinking about it, this change would pretty much be exactly the same work needed to make diffoscope run in parallel (!) which hopefully communicates both the scope of the changes that would be needed to achieve this, and that making diffoscope run in parallel also has other benefits.Anyway, mini brain dump over. Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Bug#1068890: diffoscope: --hard-timeout option
Holger Levsen wrote: >> (1) You suggest it should start again with "--max-container-depth 3", >> but it would surely need some syntax (or another option?) to control >> that "3" (but for the second time only). > > another option, --second-pass-max-container-depth or some such > >> (2) In fact, its easy to imagine that one would want to restart with >> other restrictions as well: not just --max-container-depth. For >> instance, excluding external commands like readelf and objdump that >> you know to be slow. > > yes, that's a good idea and IMO should be automatically implied for the > 2nd pass or round or try. It's definitely a "good idea" in the sense that I can definitely see someone wanting to achieve that as an end result:) Yet… upon thinking about it a bit, I don't think it is a good idea at all for diffoscope to grow a bunch of new options or hardcoded defaults for a second run. What (1) and (2) show here is that as soon as a user would like to adjust these second pass options in any way, then the whole interface becomes very unwieldy. Not only that, but from the user's point of view it's neither flexible nor transparent as well, especially when compared to "just" running diffoscope twice with different options. There's no "magic" there, if you see what I mean. Can we implement running diffoscope twice on tests.r-b.org manually first and see how that goes? I'm not 100% against the idea of implementing this in diffoscope eventually, but it would make a lot of sense to try out the "manual" version first and gain some real-world experience first. Regards, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Bug#1069169: gap-polymaking: please make the build reproducible
Source: gap-polymaking Version: 0.8.7-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: umask X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that gap-polymaking could not be built reproducibly. This is because the .tst files *AND* its surrounding directory will retain its group-writeable bit due to the use of dh_fixperms -Xtst, and will thus vary when the package is built with a different umask. A patch is attached that limits the "-Xtst" → "-X.tst" (to prevent the surrounding "/tst/" directory being matched), and then normalises the group-writable bits of the .tst files themselves. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-04-17 11:00:54.347285261 +0100 --- b/debian/rules 2024-04-17 11:10:56.519616668 +0100 @@ -25,7 +25,8 @@ make -C doc install DESTDIR=../debian/gap-polymaking override_dh_fixperms: - dh_fixperms -Xtst + dh_fixperms -X.tst + chmod g-w debian/gap-polymaking/usr/share/gap/pkg/polymaking/tst/*.tst override_dh_installdocs: dh_installdocs README.md
Bug#1069168: sagemath-database-conway-polynomials: please make the build reproducible
Source: sagemath-database-conway-polynomials
Version: 0.9-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
sagemath-database-conway-polynomials could not be built reproducibly.
This is because it shipped .pyc files in the binary package which are
not reproducible. This was caused by dh_python3 not cleaning the build
tree before the .deb was assembled, which, in turn, was because
pybuild could not determine which binary packages to act upon.
Adding ${python3:Depends} to the (single) binary package fixes this
and thus makes the package reproducible.
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/control2024-04-17 11:00:50.303242241 +0100
--- b/debian/control2024-04-17 11:03:45.412887051 +0100
@@ -13,7 +13,7 @@
Package: sagemath-database-conway-polynomials
Architecture: all
Multi-Arch: foreign
-Depends: ${misc:Depends}
+Depends: ${misc:Depends}, ${python3:Depends}
Description: Database of Conway polynomials
This package contains a small database of Conway polynomials, for
primes up to 109987 and a various number of exponents.
Bug#1068890: diffoscope: --hard-timeout option
Holger Levsen wrote: > Anyhow, about my --hard-timeout option idea: > > my idea of "--hard-timeout $time" is that diffoscope terminates itself > after $time, no matter what *and* then re-starts itself with > "--max-container-depth 3" Just to say that I am totally on board with the idea of ensuring we get _something_ out of diffoscope on tests.reproducible-builds.org. Way better than 250 timeouts. However, I think this first iteration of --hard-timeout time has a few things that would need ironing out first, and potentially make it not worth implementing: (1) You suggest it should start again with "--max-container-depth 3", but it would surely need some syntax (or another option?) to control that "3" (but for the second time only). (2) In fact, its easy to imagine that one would want to restart with other restrictions as well: not just --max-container-depth. For instance, excluding external commands like readelf and objdump that you know to be slow. (3) The output might need some comment saying "this was re-run with restrictions as we hit a timeout". (4) My gut feel that it would not be all that great to rely on CPython to really properly clear up child processes after a certain amount of time. Although I believe the most reliable top-level description to do this kind of thing inside CPython is to start a watchdog thread that sleeps until the timeout and then tries to kill everything, but my experience of doing anything like this within Python itself is not great, and essentially always needed something at the process level outside of it for it to be reliable. A container would be even more effective, I'm sure. In other words, I think the best way of achieving the result we want is, alas, by doing it outside of diffoscope at the level of the Jenkins. As in, exactly what you describe here: > Else we could also extend the current code for tests.r-b.o/debian, > which currently > just kills diffoscope after 2h, to then run diffoscope > --max-container-depth 3 :) Is that a massive faff? :/ Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Fay Stegerman wrote: > https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/140 Nice; I have applied this locally in Git and will release shortly. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
tags 1068705 + pending thanks Fay Stegerman wrote: > The attached patch avoids the crash in this case, FWIW. […] Applied in Git with attribution taken from your email. > I would still recommend catching the error for other cases. Fixed as well. And it adds a nice comment displaying the issue. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1068795: pympress: please make the build reproducible
Source: pympress
Version: 1.8.5-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
pympress could not be built reproducibly.
This is because the generated documentation included memory references
such as the following:
pointer =
A patch attached that uses Python's "default = None […] if default is
None: default = realdefault" pattern.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/0005-Reproducible-build.patch 1970-01-01
01:00:00.0 +0100
--- b/debian/patches/0005-Reproducible-build.patch 2024-04-11
09:53:13.602746588 +0100
@@ -0,0 +1,41 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-04-11
+
+--- pympress-1.8.5.orig/pympress/app.py
pympress-1.8.5/pympress/app.py
+@@ -150,11 +150,14 @@ class Pympress(Gtk.Application):
+ Gtk.Application.do_startup(self)
+
+
+-def do_activate(self, timestamp=GLib.get_current_time()):
++def do_activate(self, timestamp=None):
+ """ Activate: show UI windows.
+
+ Build them if they do not exist, otherwise bring to front.
+ """
++if timestamp is None:
++timestamp = GLib.get_current_time()
++
+ if self.gui is None:
+ if self.auto_log_level:
+ self.activate_action('log-level', logging.INFO)
+--- pympress-1.8.5.orig/pympress/pointer.py
pympress-1.8.5/pympress/pointer.py
+@@ -57,7 +57,7 @@ class Pointer(object):
+ builder (:class:`~pympress.builder.Builder`): A builder from which to
load widgets
+ """
+ #: :class:`~GdkPixbuf.Pixbuf` to read XML descriptions of GUIs and load
them.
+-pointer = GdkPixbuf.Pixbuf()
++pointer = None
+ #: `(float, float)` of position relative to slide, where the pointer
should appear
+ pointer_pos = (.5, .5)
+ #: `bool` indicating whether we should show the pointer
+@@ -84,6 +84,7 @@ class Pointer(object):
+
+ def __init__(self, config, builder):
+ super(Pointer, self).__init__()
++self.pointer = GdkPixbuf.Pixbuf()
+ self.config = config
+
+ builder.load_widgets(self)
--- a/debian/patches/series 2024-04-11 09:37:21.205740724 +0100
--- b/debian/patches/series 2024-04-11 09:48:11.045127589 +0100
@@ -1,3 +1,4 @@
0002-intersphinx.patch
0003-README-privacy.patch
0004-Options-privacy.patch
+0005-Reproducible-build.patch
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Fay Stegerman wrote:
> Salsa is probably better for figuring out what to do next, but I get
> these mails too :)
Oh, hey! o/
> unzip does seem to extract all the files, though it errors out. Not sure what
> diffoscope should do here. This is definitely a broken ZIP file.
First; great debugging there, thank you. :)
Okay, separate from your suggestion that a bug should be filed against
libscout with its broken zip file, I think that diffoscope should not
traceback and crash on this particular input. We do this elsewhere with
(most) invalid inputs and it makes a lot of sense here as well.
I'll modify diffoscope tomorrow morning to catch the specific
exception being thrown by Python's builtin zipfile module and add a
suitable message as a user-visible 'comment' — again, something we have
plenty of prior art for elsewhere in the codebase. Thanks again.
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye
Holger Levsen wrote: > when building libscout 2.3.2-3 on current unstable, the result is also > unreproducible, but diffoscope crashes when analysing the diff. I think this is somewhat related to: https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/362 … which was said to be fixed by Fay in cc3b077f6ef97b4e20036e9823926fe633c7d4d0 that released as diffoscope version 263 on 2024-04-05. However, I can see that the current output of libscout/amd64 on tests.reproducible-builds.org is failing with this very version: Tue Apr 9 12:14:14 UTC 2024 I: diffoscope 263 will be used to compare the two builds: From https://gist.github.com/lamby/e5db96d4d61612485a469b826590192e/raw (saved output for posterity) Will loop Fay in via Salsa presently. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1068377: python-oslo.messaging: please make the build reproducible
Thomas Goirand wrote:
> However, a better patch would be to use the sample_default= directive of
> oslo.config, which is printing in the generated doc, whatever the value
> of sample_default, while continuing to keep the default= value that can
> contain something programmatic. This avoids writing the "if blah is
> None" as you've put it.
Ah — now I remember this was introduced a while back for precisely
this reason. Many thanks. :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1068377: python-oslo.messaging: please make the build reproducible
affects 1068377 + zaqar
thanks
Chris Lamb wrote:
> > Whilst working on the Reproducible Builds effort [0], we noticed that
> > python-oslo.messaging could not be built reproducibly.
>
> The underlying bit of code is actually also causing src:magnum to be
> unreproducible as well.
And zaqar. :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1068377: python-oslo.messaging: please make the build reproducible
affects 1068377 + magnum thanks Chris Lamb wrote: > Whilst working on the Reproducible Builds effort [0], we noticed that > python-oslo.messaging could not be built reproducibly. The underlying bit of code is actually also causing src:magnum to be unreproducible as well. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1068377: python-oslo.messaging: please make the build reproducible
Source: python-oslo.messaging
Version: 14.7.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
python-oslo.messaging could not be built reproducibly.
This is because the documentation captures the hostname of the build
system. Specifically:
├── ./usr/share/doc/python3-oslo.messaging/html/configuration/opts.htm
│ │ Type:
│ │ string
│ │ Default:
| │ -ionos11-amd64
│ │ │ │ │ +i-capture-the-hostname
│ │Hostname used by queue manager
Patch attached that uses the Python "blah = None" / "if blah is None"
pattern so that the Python default is the value "None" whilst the
underlying functionality remains the same — ie. defaulting to
socket.gethostname().
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2024-04-04 10:31:01.530250426
+0100
@@ -0,0 +1,35 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-04-04
+
+--- python-oslo.messaging-14.7.0.orig/oslo_messaging/_drivers/impl_rabbit.py
python-oslo.messaging-14.7.0/oslo_messaging/_drivers/impl_rabbit.py
+@@ -246,7 +246,7 @@ rabbit_opts = [
+ default=False,
+ help='Should we use consistant queue names or random ones'),
+ cfg.StrOpt('hostname',
+- default=socket.gethostname(),
++ default=None,
+help='Hostname used by queue manager'),
+ cfg.StrOpt('processname',
+default=os.path.basename(sys.argv[0]),
+@@ -697,6 +697,10 @@ class Connection(object):
+ self.enable_cancel_on_failover = driver_conf.enable_cancel_on_failover
+ self.use_queue_manager = driver_conf.use_queue_manager
+
++self.hostname = driver_conf.hostname
++if self.hostname is None:
++self.hostname = socket.gethostname()
++
+ if self.rabbit_stream_fanout and self.rabbit_qos_prefetch_count <= 0:
+ raise RuntimeError('Configuration Error: rabbit_stream_fanout '
+'need rabbit_qos_prefetch_count to be set to '
+@@ -888,7 +892,7 @@ class Connection(object):
+
+ if self.use_queue_manager:
+ self._q_manager = amqpdriver.QManager(
+-hostname=driver_conf.hostname,
++hostname=self.hostname,
+ processname=driver_conf.processname)
+ else:
+ self._q_manager = None
--- a/debian/patches/series 2024-04-04 10:18:59.452475473 +0100
--- b/debian/patches/series 2024-04-04 10:31:00.538244802 +0100
@@ -1 +1,2 @@
no-functional-test.patch
+reproducible-build.patch
Bug#1068375: ludevit: please make the build reproducible
Source: ludevit Version: 9.2-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that ludevit could not be built reproducibly. This is because it ships an .egg file in the binary package that contains files varying by the current time. A patch is attached that follows dh-python by specifying --single-version-externally-managed and --root=/ such that the .egg file is not created. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-04-04 10:18:55.680431222 +0100 --- b/debian/rules 2024-04-04 10:35:51.167758995 +0100 @@ -33,7 +33,7 @@ dh_testroot dh_prep dh_installdirs - python3 setup.py install --no-compile --prefix $(CURDIR)/debian/ludevit/usr + python3 setup.py install --no-compile --single-version-externally-managed --root=/ --prefix $(CURDIR)/debian/ludevit/usr # Build architecture-independent files here.
Bug#1068374: ttconv: please make the build reproducible
Source: ttconv
Version: 1.0.8-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
ttconv could not be built reproducibly.
This is because the testsuite generates a file (tests.json) with
nondeterministic contents that ends up in the binary package. A patch
is attached that removes this after the test run via
PYBUILD_AFTER_TEST.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
` a/debian/rules 2024-04-04 10:18:51.372380412 +0100
--- b/debian/rules 2024-04-04 10:33:05.582926572 +0100
@@ -4,6 +4,7 @@
export PYBUILD_NAME=ttconv
export PYBUILD_BEFORE_TEST=mkdir -p {build_dir}/src; cp -a src/test
{build_dir}/src; cp -a debian/missing-sources/imsc-tests
{build_dir}/src/test/resources/ttml/
+export PYBUILD_AFTER_TEST=find {build_dir} -name tests.json -type f -delete
%:
dh $@ --buildsystem=pybuild
Bug#1068372: grokevt: please make the build reproducible
Source: grokevt Version: 0.5.0-5 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that grokevt could not be built reproducibly. This is because it ships an .egg file in the binary package that contains files varying by timezone.. A patch is attached that follows dh-python by specifying --single-version-externally-managed and --root=/ such that the .egg file is not created. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/no_egg.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/no_egg.patch 2024-04-04 10:25:05.795926508 +0100 @@ -0,0 +1,17 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2024-04-04 + +--- grokevt-0.5.0.orig/Makefile grokevt-0.5.0/Makefile +@@ -35,8 +35,8 @@ install: all + cp -r $(BUILD_BIN)/* $(BIN_PREFIX) + cp -r $(BUILD_ETC)/* $(ETC_PREFIX) + cp -r $(BUILD_DOC)/* $(DOC_PREFIX) +- if [ "x$(PYTHON_PATH)" != "x" ]; then $(PYTHON_PATH) grokevt-distutils.py install --install-layout=deb --prefix $(PREFIX); fi +- if [ "x$(PYTHON3_PATH)" != "x" ]; then $(PYTHON3_PATH) grokevt-distutils.py install --install-layout=deb --prefix $(PREFIX); fi ++ if [ "x$(PYTHON_PATH)" != "x" ]; then $(PYTHON_PATH) grokevt-distutils.py install --install-layout=deb --single-version-externally-managed --root=/ --prefix $(PREFIX); fi ++ if [ "x$(PYTHON3_PATH)" != "x" ]; then $(PYTHON3_PATH) grokevt-distutils.py install --install-layout=deb --single-version-externally-managed --root=/ --prefix $(PREFIX); fi + $(MAKE) -C doc install + + --- a/debian/patches/series 2024-04-04 10:19:06.124553201 +0100 --- b/debian/patches/series 2024-04-04 10:24:30.719654371 +0100 @@ -1,3 +1,4 @@ example_configuration_path makefile.patch python3-shebang.patch +no_egg.patch
Bug#1068300: eo-spell: please make the build reproducible
Source: eo-spell
Version: 3.7-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: datetime
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
eo-spell could not be built reproducibly.
This is because the build system embeds the output of calling "date":
│ │ │ ├── ./usr/lib/ispell/esperanto.aff
│ │ │ │ @@ -1,13 +1,13 @@
│ │ │ │ # -*- coding: latin-3 -*-
│ │ │ │ # Nomo:eo.aff
│ │ │ │ # Funkcio: Afiksaro por Esperanto-vortaro
│ │ │ │ # Komencita: 1997-08-30 de Sergio Pokrovskij
│ │ │ │ # Versio: 3.5
│ │ │ │ -# Generita:Tue Apr 2 21:52:24 2024
│ │ │ │ +# Generita:Tue Apr 2 21:53:34 2024
Patch attached that replaces this with a call to the Debian-specific
"dpkg-parsechangelog -SDate". However, you could make this distribution
agnostic by calling date(1) seeded by SOURCE_DATE_EPOCH if it exists…
or simply by removing this date entirely.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/1000_reproducible-build.diff 1970-01-01
01:00:00.0 +0100
--- b/debian/patches/1000_reproducible-build.diff 2024-04-03
10:26:23.476786697 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-04-03
+
+--- eo-spell-3.7.orig/src/eo-aff.m4
eo-spell-3.7/src/eo-aff.m4
+@@ -123,7 +123,7 @@ divert(0)dnl
+ # Funkcio:Afiksaro por Esperanto-vortaro
+ # Komencita: 1997-08-30 de Sergio Pokrovskij
+ Versio
+-{# Generita:} esyscmd(date)
++{# Generita:} esyscmd(dpkg-parsechangelog -SDate)
+ #
+ # Copyright 1997 -- 2012 Sergio Pokrovskij
+ #
--- a/debian/patches/series 2024-04-03 10:24:24.558673371 +0100
--- b/debian/patches/series 2024-04-03 10:26:22.340766797 +0100
@@ -1 +1,2 @@
_change-aff-rules.diff
+1000_reproducible-build.diff
Bug#1068176: goldendict-ng: please make the build reproducible
Source: goldendict-ng
Version: 23.12.26-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
goldendict-ng could not be built reproducibly.
This is because it does not specify the "UTC" argument to CMake's
TIMESTAMP macro function, so the build time embedded in the final
binary, whilst based on SOURCE_DATE_EPOCH, varies by the build
timezone.
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/0002-Reproducible-build.patch 1970-01-01
01:00:00.0 +0100
--- b/debian/patches/0002-Reproducible-build.patch 2024-04-01
11:02:36.411764040 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-04-01
+
+--- goldendict-ng-23.12.26.orig/CMakeLists.txt
goldendict-ng-23.12.26/CMakeLists.txt
+@@ -54,7 +54,7 @@ set(CMAKE_AUTORCC ON) # not included in
+ Things required during configuration
+
+ block() # generate version.txt
+-string(TIMESTAMP build_time)
++string(TIMESTAMP build_time UTC)
+ find_package(Git)
+ if (EXISTS "${CMAKE_SOURCE_DIR}/.git" AND GIT_FOUND)
+ execute_process(
--- a/debian/patches/series 2024-04-01 09:53:57.209332464 +0100
--- b/debian/patches/series 2024-04-01 11:02:35.515760642 +0100
@@ -1 +1,2 @@
0001-Disable-checkUpdate-by-default.patch
+0002-Reproducible-build.patch
Bug#1068173: pg-gvm: please make the build reproducible
Source: pg-gvm
Version: 22.6.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: filesystem
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
pg-gvm could not be built reproducibly.
This is because it iterated over input files in the underlying (i.e.
nondeterministic) filesystem order.
A patch is attached that uses sort(1) to sort them, ensuring that it
will work irrespective of the current locale and whether there are
spaces in the build path.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2024-04-01 10:17:16.629152522
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-04-01
+
+--- pg-gvm-22.6.2.orig/CMakeLists.txt
pg-gvm-22.6.2/CMakeLists.txt
+@@ -175,7 +175,7 @@ add_custom_command(
+ OUTPUT ${SQLOUT}
+ COMMAND mkdir -p ${CMAKE_BINARY_DIR}/sqlin
+ COMMAND cp ${SQL} ${CMAKE_BINARY_DIR}/sqlin/
+-COMMAND cd ${CMAKE_BINARY_DIR}/sqlin/ && find -type f | xargs cat >
${CMAKE_BINARY_DIR}/${SQLOUT}
++COMMAND cd ${CMAKE_BINARY_DIR}/sqlin/ && find -type f -print0 | LC_ALL=C
sort -z | xargs -0 cat > ${CMAKE_BINARY_DIR}/${SQLOUT}
+ WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
+ DEPENDS ${SQL})
+
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2024-04-01 10:17:15.685149789 +0100
@@ -0,0 +1 @@
+reproducible-build.patch
Bug#1067947: golang-github-stvp-tempredis: please make the build reproducible
Source: golang-github-stvp-tempredis Version: 0.0~git20231107.8a695b6-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that golang-github-stvp-tempredis could not be built reproducibly. This is because the package build generates a Redis dump.rdb database during the tests. This (nondeterministic) file is then shipped in the binary package. Patch attached that removes these after running the tests. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-29 10:35:18.997786394 + --- b/debian/rules 2024-03-29 10:55:36.280785041 + @@ -2,3 +2,6 @@ %: dh $@ --buildsystem=golang --with=golang + +execute_after_dh_auto_test: + find obj-* -name dump.rdb -delete
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Alberto Bertogli wrote: > If you know of a functional official image that I can use to try to > reproduce the problem, or recently-tested steps I can follow to get > a working qemu install, please let me know. Alas, I can't actually be helpful here. There are no official images as far as I know… and somewhat annoyingly I (ie. a Debian Developer) actually have access to some machines set aside for this purpose. I call this "annoying" because I naturally can't then give you direct SSH access transitively — but I can proxy ideas, of course. Hm, googling the actual error message a little, I think this might be a bigger issue... or perhaps more accurately, at least one that has potentially been also solved elsewhere: * Same think in lightdm: <https://bugs.debian.org/1067561> * Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils <https://www.spinics.net/lists/linux-media/msg230147.html> etc. Does this spark anything worth trying? :-) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Alberto Bertogli wrote:
> I'll try to get a debian install to boot for armhf, but it'll take me a
> bit because it's not straightforward (to put it mildly :).
Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.
> How urgent/important is this issue?
Medium? As it is technically a regression (as in, armhf used to build
before), this was filed with a severity of "serious". What this means
in practical terms is that newer versions of libfiu we upload will not
migrate to the staging area for the next release of Debian.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1067413: RFP: keydb -- persistent key-value database with network interface
affects 1067413 + redis-server
thanks
Hi Guillem,
> I'm CCing Chris, who might perhaps be interested in replacing Redis with
> KeyDB as its spiritual successor and taking this on? Or if not, at least
> to perhaps potentially coordinate some kind of transition, even though
> we've had issues migrating persistent DBs from newer Redis to KeyDB, so
> that might be tricky or not feasible at all.
Thanks for including me here. I had not yet looked into potential
Redis replacements nor the exact and precise details of the new
license etc. and this activity around KeyDB feels like a good start.
I thought I'd let the dust settle for a bit before making any
decisions — perhaps the change even gets reversed (!), and no doubt
there might be new alternatives that will fork the code immediately
prior to the license change.
My personal and professional usage of Redis has dropped off in the
past few years, so it would make more sense for me to help out in a
team maintainership role, at least with respect to KeyDB.
However, I'd be interested in coordinating around some kind of
Redis→KeyDB/something transition if need be.
(Incidentally, why did your work switch to KeyDB?)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1067485: python-pysaml2: please make the build reproducible
Source: python-pysaml2 Version: 7.4.2-3 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that python-pysaml2 could not be built reproducibly. This is because the tests generate a (nondeterministic) file called eptid.db that is then shipped in the binary package. Incidentally, the file is installed directly to the global /usr/lib/python3/dist-packages directory, which is a likely a bug in itself. (Hm, isn't there a Lintian warning for this?) Anyway, patch attached that removes this file after running the tests. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-22 09:31:42.477985685 + --- b/debian/rules 2024-03-22 09:59:35.122321091 + @@ -21,6 +21,9 @@ for i in $$(find . -type d -iname __pycache__) ; do rm -rf $$i ; done dh_auto_clean +execute_after_dh_auto_test: + find .pybuild -type f -name eptid.db -delete + #override_dh_install: # dh_install # set -e ; set -x ; for i in `ls $(CURDIR)/debian/python3-pysaml2/usr/bin/*.py` ; do \
Bug#1067484: node-function-bind: please make the build reproducible
Source: node-function-bind Version: 1.1.2+~cs2.1.14-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that node-function-bind could not be built reproducibly. This is because it ships test coverage information generated using the run of the testsuite. These files in turn contain nondeterministic dates: │ │ │ ├── ./usr/share/nodejs/has/coverage/index.html │ │ │ │ Code coverage generated by │ │ │ │ https://istanbul.js.org/; target="_blank" rel="noopener noreferrer">istanbul │ │ │ │ -at Thu Apr 24 2025 09:17:32 GMT+ (GMT) │ │ │ │ +at Fri Mar 22 2024 02:58:54 GMT+ (GMT) Patch attached that simply removes these files from the binary package. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-22 09:42:48.097059681 + --- b/debian/rules 2024-03-22 09:51:56.744545540 + @@ -9,6 +9,9 @@ %: dh $@ --with nodejs +execute_after_dh_auto_test: + rm -rf has/coverage + override_dh_installdocs: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES))) dh_installdocs
Bug#1067483: postfix: please make the build reproducible
Source: postfix Version: 3.9.0-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that postfix could not be built reproducibly: /usr/share/doc/postfix/examples/makedefs.out # AUXLIBS=-lssl -lcrypto -lsasl2 -lpthread -# AUXLIBS_CDB=-lcdb +# AUXLIBS_PCRE=-lpcre2-8 +# AUXLIBS_PGSQL=-lpq +# AUXLIBS_MYSQL=-lmysqlclient +# AUXLIBS_SQLITE=-lsqlite3 # AUXLIBS_MONGODB=-lmongoc-1.0 -lbson-1.0 This is caused by printing the output of "env" without piping it through sort(1) — see the attached patch. We don't need to specify LC_ALL=C as this is already done on line 189. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1066991: easy way to crash diffoscope
tags 1066991 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/1dc8c79e8307f5772a434ecba549bc923fa28582 diffoscope/comparators/rdata.py | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1067218: gretl: please make the build reproducible
Source: gretl Version: 2023c-2.1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that gretl could not be built reproducibly. This is because the PDF documentation embeds the current date via TeX's \today (etc.). A patch is attached that uses FORCE_SOURCE_DATE to request that TeX sources the current date from SOURCE_DATE_EPOCH instead of the system clock. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-20 10:22:09.435742379 + --- b/debian/rules 2024-03-20 10:41:22.804750818 + @@ -24,6 +24,9 @@ cflags = -O0 -g0 -Wall endif +# Request that TeX seed the \today (etc.) from SOURCE_DATE_EPOCH +export FORCE_SOURCE_DATE = 1 + #export DH_VERBOSE=1 upstream: get-orig-source
Bug#1067113: libhiredis-dev: cmake config incompatible with upstream
[adding to CC]
Sylvain Joubert wrote:
> The CMake config provided by this package seems incompatible with the upstream
> one.
> Currently, the package provides data under the name "Hiredis" with a capital
> leading H, while upstream is named "hiredis" lowercase
> ".../cmake/Hiredis/HiredisConfig{,Version}.cmake" vs.
> ".../cmake/hiredis/hiredis-config.cmake" (see
> https://github.com/redis/hiredis/blob/master/CMakeLists.txt#L137-L150)
>
> This means that a client CMake project can't switch transparently between an
> Debian install and a custom cmake build of hiredis.
>
> Could you rename the cmake configuration provided by Debian to match upstream,
> or even build hiredis using the official CMake support?
I'm looping in Tom Lee here as they added the CMake changes back in
2018 (via #784768?).
Yes, perhaps these changes are simply not needed anymore. However, I
don't quite understand the changes made in 07_cmake.patch completely
to make a determination on my own. I think I might know how to fix
this (eg. change the definition of CMAKE_PATH and then update
libhiredis-dev.install to match?), but, again, I'm just not familiar
enough.
No objection to solving this issue in a general sense, though. :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1067102: librsvg: please make the build reproducible
Source: librsvg Version: 2.57.92+dfsg-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: umask X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that librsvg could not be built reproducibly due to a typo in debian/rules: # debhelper >= 13.4 makes all of /usr/libexec executable, which is not # quite right for installed-tests override_dh_fixperms: dh_fixperms -Xusr/libexec/rsvg/tests ifneq ($(filter %-tests,$(binaries)),) chmod --recursive --changes a+rX,u+w,og-w debian/*-tests/usr/libexec/rsvg/tests endif This should refer to "$(built_binaries)", not "$(binaries)"… and so the line is not run... resulting in the build varying depending on the build system's umask. :) A patch that corrects this typo is attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-18 12:02:58.659721987 + --- b/debian/rules 2024-03-18 12:57:15.97414 + @@ -52,7 +52,7 @@ # quite right for installed-tests override_dh_fixperms: dh_fixperms -Xusr/libexec/rsvg/tests -ifneq ($(filter %-tests,$(binaries)),) +ifneq ($(filter %-tests,$(built_binaries)),) chmod --recursive --changes a+rX,u+w,og-w debian/*-tests/usr/libexec/rsvg/tests endif
Bug#1067101: storm-lang: please make the build reproducible
Source: storm-lang Version: 0.6.20-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that storm-lang could not be built reproducibly: │ │ │ ├── ./usr/share/doc/storm-lang/html/05-Downloads/index.html │ │ │ │ @@ -322,15 +322,15 @@ […] │ │ │ │ │ │ │ │ -Binary releases for 0.6.20-1+debian (2024-02-21) │ │ │ │ +Binary releases for 0.6.20-1+debian (2024-02-23) │ │ │ │ A patch is attached that modifies an *existing* patch to ensure that this date does not vary depending on the build machine's timezone. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/debian/patches/build-files b/debian/patches/build-files index ec9c5ba..b33396c 100644 --- a/debian/patches/build-files +++ b/debian/patches/build-files @@ -145,5 +145,5 @@ Author: Filip Strömbäck +#!/bin/bash + +date=$(sed -En 's/--.*<.*> ([^ ].*)/\1/p' debian/changelog | head -n 1) -+date=$(date --date="$date" "+%Y-%m-%d") ++date=$(date --utc --date="$date" "+%Y-%m-%d") +release/Storm_mps -r root -f markdown.doc.generate -- --clear --date=$date Storm storm doc "$1"
Bug#1067100: bochs: please make the build reproducible
Source: bochs Version: 2.8+dfsg-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that bochs could not be built reproducibly: │ │ │ ├── /usr/share/bochs/BIOS-bochs-latest │ │ │ │ @@ -7548,16 +7548,16 @@ [] │ │ │ │ 0001d810: 5333 2072 6573 756d 6520 6361 6c6c 6564 S3 resume called │ │ │ │ -0001d820: 2025 7820 3078 256c 780a 0030 332f 3137 %x 0x%lx..03/17 │ │ │ │ -0001d830: 2f32 3400 4249 4f53 2042 5549 4c44 2044 /24.BIOS BUILD D │ │ │ │ +0001d820: 2025 7820 3078 256c 780a 0030 342f 3139 %x 0x%lx..04/19 │ │ │ │ +0001d830: 2f32 3500 4249 4f53 2042 5549 4c44 2044 /25.BIOS BUILD D │ │ │ │ 0001d840: 4154 453a 2025 730a 0049 4e54 3138 3a20 ATE: %s..INT18: A patch is attached that seeds this date from SOURCE_DATE_EPOCH if available. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/reproducible-build.patch 2024-03-18 12:53:29.510214179 + @@ -0,0 +1,20 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2024-03-18 + +--- bochs-2.8+dfsg.orig/bios/Makefile.in bochs-2.8+dfsg/bios/Makefile.in +@@ -47,7 +47,12 @@ LOCAL_CXXFLAGS = + + # UPSTREAM_RELEASE_DATE = $(shell grep "Updated:" ../README | sed 's/Updated://') + # BUILDDATE = `date -u -d '$(UPSTREAM_RELEASE_DATE)' '+%m/%d/%y'` +-BUILDDATE = `date -u '+%m/%d/%y'` ++DATE_FMT = +%m/%d/%y ++ifdef SOURCE_DATE_EPOCH ++BUILDDATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u "$(DATE_FMT)") ++else ++BUILDDATE ?= $(shell date "$(DATE_FMT)") ++endif + BIOS_BUILD_DATE = "-DBIOS_BUILD_DATE=\"$(BUILDDATE)\"" + # + # end configurable options -- --- a/debian/patches/series 2024-03-18 12:08:12.631304482 + --- b/debian/patches/series 2024-03-18 12:53:28.550214427 + @@ -7,3 +7,4 @@ cross-build-1.patch narrowing-conversions.patch instrument-stub-class.patch +reproducible-build.patch
Bug#1067099: woof-doom: please make the build reproducible
Source: woof-doom Version: 14.3.0+dfsg-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that woof-doom could not be built reproducibly: │ │ │ │ ├── /usr/share/metainfo/io.github.fabiangreffrath.woof.metainfo.xml │ │ │ │ │ @@ -35,10 +35,10 @@ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ - │ │ │ │ │ + │ │ │ │ │ A patch is attached that uses CMake's "UTC" argument to make sure that this value does not vary due to the build system's timezone. (CMake is already magically making the date inherit from SOURCE_DATE_EPOCH.) [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/reproducible-build.patch 2024-03-18 13:03:40.906056433 + @@ -0,0 +1,12 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2024-03-18 + +--- woof-doom-14.3.0+dfsg.orig/data/CMakeLists.txt woof-doom-14.3.0+dfsg/data/CMakeLists.txt +@@ -1,4 +1,4 @@ +-string(TIMESTAMP PROJECT_DATE "%Y-%m-%d") ++string(TIMESTAMP PROJECT_DATE "%Y-%m-%d" UTC) + + configure_file(io.github.fabiangreffrath.woof.metainfo.in +io.github.fabiangreffrath.woof.metainfo.xml --- a/debian/patches/series 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/series 2024-03-18 13:03:39.342056834 + @@ -0,0 +1 @@ +reproducible-build.patch
Bug#1067098: mpl-sphinx-theme: please make the build reproducible
Source: mpl-sphinx-theme
Version: 3.5.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
mpl-sphinx-theme could not be built reproducibly.
This is because it embedded the build date in the documentation:
│ │ │ ├── ./usr/share/doc/python-mpl-sphinx-theme-doc/html/genindex.html
│ │ │ │ @@ -184,15 +184,15 @@
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - Copyright 2024 - 2024 The Matplotlib development team.
│ │ │ │ + Copyright 2024 - 2025 The Matplotlib development team.
│ │ │ │
(Etc.)
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2024-03-18 12:59:19.650123651
+
@@ -0,0 +1,28 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-03-18
+
+--- mpl-sphinx-theme-3.5.0.orig/docs/conf.py
mpl-sphinx-theme-3.5.0/docs/conf.py
+@@ -1,5 +1,12 @@
++import os
++import time
+ import datetime
+
++build_date = datetime.datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=datetime.timezone.utc,
++)
++
+ # Configuration file for the Sphinx documentation builder for
+ # matplotlib projects.
+
+@@ -10,7 +17,7 @@ is_release_build = tags.has('release')
+
+ project = "Matplotlib Sphinx Theme"
+ copyright = (
+-f"2012 - {datetime.datetime.now().year} The Matplotlib development team"
++f"2012 - {build_date.year} The Matplotlib development team"
+ )
+ author = "Matplotlib Developers"
+
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2024-03-18 12:59:16.218124536 +
@@ -0,0 +1 @@
+reproducible-build.patch
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Dear Alberto,
Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.
Best wishes,
Chris
- Original message -
From: Sebastian Ramacher
To: Debian Bug Tracking System
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error:
symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM
Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=libfiu=armhf=1.2-2=1710292712=0
cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I.
-I../../libfiu/ -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
-Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined
/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined
/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined
/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined
/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1
/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined
/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined
/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined
/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined
/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1
Bug#1066085: q2cli: please make the build reproducible
Source: q2cli Version: 2024.2.0-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that q2cli could not be built reproducibly. This is because it ships nondeterminstic "parsl.log" files in the binary package installed by the package's Python build system. A patch is attached that deletes these files prior to creating the .deb. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-12 10:05:22.980824959 + --- b/debian/rules 2024-03-12 10:34:47.399635439 + @@ -21,6 +21,7 @@ mkdir -p debian/$(DEB_SOURCE)/usr/share/bash-completion/completions mv debian/$(DEB_SOURCE)/usr/bin/tab-qiime debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime chmod -x debian/$(DEB_SOURCE)/usr/share/bash-completion/completions/qiime + find debian/$(DEB_SOURCE) -type f -name parsl.log -delete debian/control: debian/control.in echo "# This file is autogenerated from control.in to update versioned dependencies" > $@
Bug#1066084: tox: please make the build reproducible
Source: tox Version: 4.13.0-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that tox could not be built reproducibly. This is because the build system cannot find ~/.config/tox/config.ini and a warning message to this effect is included in the documentation: │ │ │ ├── ./usr/share/doc/tox/html/cli_interface.html │ │ │ │ @@ -705,15 +705,15 @@ │ │ │ │ -config file ‘/nonexistent/first-build/.config/tox/config.ini’ missing (change via env var TOX_USER_CONFIG_FILE) │ │ │ │ +config file ‘/nonexistent/second-build/.config/tox/config.ini’ missing (change via env var TOX_USER_CONFIG_FILE) │ │ │ │ Patch attached that makes the build system uses the empty (but very determinstistic!) /dev/null as the config file. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-03-12 10:05:10.540815841 + --- b/debian/rules 2024-03-12 10:25:47.884699097 + @@ -10,6 +10,8 @@ # through the git tag, and in turn writing it to version.py. export SETUPTOOLS_SCM_PRETEND_VERSION = $(DEB_VERSION_UPSTREAM) +export TOX_USER_CONFIG_FILE = /dev/null + %: dh $@ --buildsystem=pybuild
Bug#1066083: gnome-maps: please make the build reproducible
Source: gnome-maps
Version: 46~beta-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
gnome-maps could not be built reproducibly.
This is because it embedded the current build date in an XML file:
│ │ │ │ ├── ./usr/share/metainfo/org.gnome.Maps.appdata.xml
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ -
│ │ │ │ │ +
Patch attached that updates the Meson build file to use the
SOURCE_DATE_EPOCH environment variable if it exists.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
` a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2024-03-12 10:25:05.728519725
+
@@ -0,0 +1,20 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-03-12
+
+--- gnome-maps-46~beta.orig/data/meson.build
gnome-maps-46~beta/data/meson.build
+@@ -39,7 +39,12 @@ install_data(
+ today = 'unknown'
+ date = find_program('date', required: false)
+ if date.found()
+- r = run_command(date, '-I')
++ cmd = run_command('sh', '-c', 'echo $SOURCE_DATE_EPOCH')
++ source_date_epoch = cmd.stdout().strip()
++ if source_date_epoch == ''
++source_date_epoch = run_command(date, '+%s').stdout().strip()
++ endif
++ r = run_command(date, '-u', '-d', '@' + source_date_epoch, '-I')
+ if r.returncode() == 0
+ today = r.stdout().strip()
+ endif
--- a/debian/patches/series 2024-03-12 10:05:04.804812036 +
--- b/debian/patches/series 2024-03-12 10:25:04.932516349 +
@@ -0,0 +1 @@
+reproducible-build.patch
Bug#1066042: python-quantities: please make the build reproducible
Source: python-quantities
Version: 0.15.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
python-quantities could not be built reproducibly.
This is because the build process writes a timestamp to a generated
file. A patch is attached that sources this timestamp from SOURCE_DATE_EPOCH
instead of the system clock.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2024-03-11 15:07:58.203181306
+
@@ -0,0 +1,31 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-03-11
+
+--- python-quantities-0.15.0.orig/setup.py
python-quantities-0.15.0/setup.py
+@@ -1,8 +1,14 @@
++import os
++import time
+ from setuptools import Command, setup
+ from setuptools.command.build_py import build_py as _build
+ from setuptools.command.sdist import sdist as _sdist
+-from datetime import datetime
++from datetime import datetime, timezone
+
++build_date = datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=timezone.utc,
++)
+
+ class data(Command):
+
+@@ -24,7 +30,7 @@ class data(Command):
+ with open('quantities/constants/_codata.py', 'w') as f:
+ f.write('# THIS FILE IS AUTOMATICALLY GENERATED\n')
+ f.write('# ANY CHANGES MADE HERE WILL BE LOST\n')
+-f.write(f'# LAST GENERATED: {datetime.now()}\n\n')
++f.write(f'# LAST GENERATED: {build_date}\n\n')
+ f.write('physical_constants = {}\n\n')
+ for line in data:
+ name = line[:55].rstrip().replace('mag.','magnetic')
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2024-03-11 15:05:38.702459132 +
@@ -0,0 +1 @@
+reproducible-build.patch
Bug#1064973: diffoscope fails with struct.error: unpack requires a buffer of 4 bytes
tags 1064973 + pending thanks Ah, I see the issue now; its to do with empty pyc files. Now properly fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/c885c24ad4807a0ec20c0cca9572b395812c85d9 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1064973: diffoscope fails with struct.error: unpack requires a buffer of 4 bytes
Zbigniew Jędrzejewski-Szmek wrote:
> File
> "/usr/lib/python3.12/site-packages/diffoscope/comparators/python.py",
> line 74, in parse_pyc
> modtime = time.asctime(time.gmtime(struct.unpack("
> struct.error: unpack requires a buffer of 4 bytes
I'm trying to track this down further so I can fix the underlying
problem. However, I'm having difficulty reproducing locally. In the
first instance, it would be helpful to know exactly which file within
the .rpm is the one (previously) causing the traceback.
Can you run diffoscope --debug so we can see which .pyc file is the
offending one? I think it is "environment.cpython-312.pyc", but it
would be great to get confirmation. Also knowing your exact Python
version (using python3 --version) would be useful withal.
Best wishes,
--
o
⬋ ⬊ Chris Lamb
o o reproducible-builds.org
⬊ ⬋
o
Bug#1064973: diffoscope fails with struct.error: unpack requires a buffer of 4 bytes
tags 1064973 + pending thanks The traceback/error is fixed in Git, pending upload: https://salsa.debian.org/reproducible-builds/diffoscope/commit/466523ac6fbd1437635f8393fb93c37ff59341b3 We should still fix it so the .pyc is actually parsed though. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1064891: pytest-repeat: please make the build reproducible
James Addison wrote: > I'd neglected to file a bugreport for this, so my mistake here: I'd provided > a merge request[1] to fix this same reproducibility issue. No worries about not filing a bug report. Ironically, I don't think it would have helped in this instance: I don't recall checking whether there was a bug report before filing this one anyway — whoops... Re. the next steps, though, I am not convinced about the utility of shipping entry_points.txt etc. in Debian packages, so I would be more than happy if that bit of code would just be removed. Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Bug#1064892: klepto: please make the build reproducible
Source: klepto
Version: 0.2.5-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
klepto could not be built reproducibly.
This is because one of its functions docstrings was generated
programatically in a nondeterminstic manner:
│ │ │ │ │cryptographic hashing
│ │ │ │ │ - algorithm: one of (None, ‘shake_256’, ‘md5’, ‘md5-sha1’,
‘sha512’,
│ │ │ │ │ - ‘sha1’, ‘sha256’, ‘blake2b’, ‘sha3_224’, ‘sm3’, ‘sha384’,
‘sha3_256’,
│ │ │ │ │ - ‘sha224’, ‘sha3_512’, ‘sha3_384’, ‘sha512_224’, ‘blake2s’,
‘shake_128’,
│ │ │ │ │ - ‘sha512_256’, ‘ripemd160’) The default is algorithm=None,
which uses
│ │ │ │ │ - python’s ‘hash’.
│ │ │ │ │ + algorithm: one of (None, ‘sm3’, ‘sha512_256’, ‘blake2b’,
‘shake_256’,
│ │ │ │ │ + ‘sha512’, ‘sha3_224’, ‘blake2s’, ‘sha384’, ‘sha1’,
‘shake_128’, ‘sha256’,
│ │ │ │ │ + ‘sha3_256’, ‘sha3_512’, ‘md5-sha1’, ‘sha224’, ‘sha512_224’,
‘sha3_384’,
│ │ │ │ │ + ‘md5’, ‘ripemd160’) The default is algorithm=None, which uses
python’s
│ │ │ │ │ + ‘hash’.khhhk
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
` a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2024-02-27 10:46:36.696040794
+
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2024-02-27
+
+--- klepto-0.2.5.orig/klepto/crypto.py
klepto-0.2.5/klepto/crypto.py
+@@ -19,7 +19,7 @@ def algorithms():
+ algs = tuple(hashlib.algorithms_available)
+ except:
+ algs = ('md5', 'sha1', 'sha224', 'sha256', 'sha384', 'sha512')
+-return (None,) + algs
++return (None,) + tuple(sorted(algs))
+
+ def hash(object, algorithm=None):
+ if algorithm is None:
--- a/debian/patches/series 2024-02-27 10:39:57.359562009 +
--- b/debian/patches/series 2024-02-27 10:46:35.712044814 +
@@ -1,2 +1,3 @@
privacy-protection.patch
skip-mysql-test.patch
+reproducible-build.patch
Bug#1064891: pytest-repeat: please make the build reproducible
Source: pytest-repeat
Version: 0.9.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: shell
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
pytest-repeat could not be built reproducibly.
This was because of the use of echo "... \n ..." in debian/rules,
which emits a literal "\n" on shells other than Bash such as dash:
│ │ │ ├──
./usr/lib/python3/dist-packages/pytest_repeat.egg-info/entry_points.txt
│ │ │ │ @@ -1,2 +1 @@
│ │ │ │ -[pytest11]
│ │ │ │ -repeat = pytest_repeat
│ │ │ │ +[pytest11]\nrepeat = pytest_repeat
A patch is attached that uses printf instead.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/rules 2024-02-27 10:40:03.115731187 +
--- b/debian/rules 2024-02-27 10:42:13.759688623 +
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
export PYBUILD_BEFORE_TEST=mkdir {build_dir}/pytest_repeat.egg-info && \
- echo "[pytest11]\nrepeat = pytest_repeat" >
{build_dir}/pytest_repeat.egg-info/entry_points.txt
+ printf "[pytest11]\nrepeat = pytest_repeat\n" >
{build_dir}/pytest_repeat.egg-info/entry_points.txt
%:
dh $@ --buildsystem=pybuild
Bug#1064506: geophar: please make the build reproducible
Source: geophar Version: 18.10+dfsg1-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that geophar could not be built reproducibly. This is because, whilst it does seed the `date_version` string in version.py with the latest date in debian/changelog, it does not account for the timezone of the build system. A patch is attached that adds --utc to the date(1) invocation. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2024-02-23 11:43:47.296787587 + --- b/debian/rules 2024-02-23 11:58:50.431911540 + @@ -54,7 +54,7 @@ sed -i 's%https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML%http://localhost/javascript/mathjax/MathJax.js%' $$f; \ done # modify the version number - date=$$(date --date="@$$(dpkg-parsechangelog --show-field Timestamp)" +"(%Y, %-m, %-d)"); \ + date=$$(date --utc --date="@$$(dpkg-parsechangelog --show-field Timestamp)" +"(%Y, %-m, %-d)"); \ version=$$(dpkg-parsechangelog --show-field Version); \ fileToChange=debian/geophar/usr/share/geophar/wxgeometrie/version.py; \ echo version = $$version, date_version = $$date; \
Bug#1061331: RM: aptfs -- RoM; abandoned upstream
Package: ftp.debian.org Severity: normal Hi, I am both the package maintainer and the upstream maintainer, and I think aptfs should be removed from the archive. Many thanks. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1059767: aptfs: isolation-machine autopkgtest fails: find: ‘target/bash’: Invalid argument
Paul Gevers wrote: > 72s lr-xrwSrwt 3 root root 0 Jan 1 1970 zypper-common -> zypper > 72s lr-xrwSrwt 3 root root 0 Jan 1 1970 zypper-doc -> zypper > 72s dr-x-wSr-t 3 root root 0 Jan 1 1970 zytrax > 72s dr-x-wSr-t 3 root root 0 Jan 1 1970 zziplib > 72s lr-xrwSrwt 3 root root 0 Jan 1 1970 zziplib-bin -> zziplib > 72s dr-x-wSr-t 3 root root 0 Jan 1 1970 zzuf > 72s dr-x-wSr-t 3 root root 0 Jan 1 1970 zzz-to-char > 72s dr-x-wSr-t 3 root root 0 Jan 1 1970 zzzeeksphinx > 72s find: ‘target/bash’: Invalid argument > 72s target/bash > 73s autopkgtest [17:05:06]: test 0001-smoketest: ---] Just to mention that I have been looking into this, but I am a little stymied as it seems to work okay here. What is very curious is that the directory listing works (ie. we can infer that zzuf, zzz-to-char, zzzeeksphinx, etc. has been obtained via APT), but the package download is not working. Still, I should also mention that I am not using, developing or (genuinely) supporting aptfs any longer, so the real solution here might be to remove the package. Best wishes, -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o
Bug#1060316: redis: CVE-2023-41056
Package: redis Version: 5:6.0.16-1+deb11u2 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for redis. CVE-2023-41056[0]: Buffer overflow in certain payloads may lead to remote code execution Info just unembargoed, so links may time some time to update. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-41056 https://www.cve.org/CVERecord?id=CVE-2023-41056 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1060254: mumble: please make the build reproducible
Source: mumble Version: 1.5.517-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that mumble could not be built reproducibly. This is because it embeds the current build date in an XML file: │ │ │ │ ├── ./usr/share/metainfo/info.mumble.Mumble.appdata.xml │ │ │ │ │ @@ -23,13 +23,13 @@ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Light and Dark Theme │ │ │ │ │ https://raw.githubusercontent.com/mumble-voip/mumble/master/screenshots/Mumble.png │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ - │ │ │ │ │ + │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ mumble │ │ │ │ │ │ │ │ │ │ Patch attached. CMake is already following the SOURCE_DATE_EPOCH environment variable if available, but it needs to be instructed to use the UTC timezone. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/50-reproducible-build.diff 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/50-reproducible-build.diff 2024-01-08 10:10:33.875933485 + @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2024-01-08 + +--- mumble-1.5.517.orig/auxiliary_files/CMakeLists.txt mumble-1.5.517/auxiliary_files/CMakeLists.txt +@@ -8,7 +8,7 @@ include(pkg-utils) + + if(NOT BUILD_RELEASE_DATE) + # If BUILD_RELEASE_DATE has not been set, default to time of build +- string(TIMESTAMP BUILD_RELEASE_DATE "%Y-%m-%d") ++ string(TIMESTAMP BUILD_RELEASE_DATE "%Y-%m-%d" UTC) + endif() + + if(overlay) --- a/debian/patches/series 2024-01-08 09:47:51.592354667 + --- b/debian/patches/series 2024-01-08 10:10:33.095927130 + @@ -3,3 +3,4 @@ #44-add-speechd-header.diff 45-add-pid-location-hint.diff 90-debianize-systemd-unit.diff +50-reproducible-build.diff
Bug#1057975: support for libhiredis version 1.1.0 (1.2.0-4) in bullseye and bookworm
tags 1057975 + pending
thanks
David Pilnik wrote:
> I require to use libhiredis in Debian bullseye and bookworm that
> support TLS which is supported only in version (libhiredis1.1.0)
> 1.2.0-4 1.
> Today Debian bullseye and bookworm support this libhiredis version only
> from experimental sources, and we required it in the regular sources.
I've now built all of the reverse-dependencies of libhiredis-dev in
unstable with the experimental version of libhiredis. For reference,
that is:
* ccache
* collectd
* coturn
* drogon
* fastnetmon
* freeradius
* gearmand
* gloo
* gsad
* gvm-libs
* gvmd
* kamailio
* kannel
* libapache2-mod-auth-openidc
* libapache2-mod-oauth2
* liboauth2
* libredis-fast-perl
* libvmod-redis
* libvmod-selector
* mapcache
* ntopng
* opensmtpd-extras
* openvas-scanner
* pg-gvm
* proftpd-dfsg
* proftpd-mod-proxy
* proftpd-mod-statsd
* proftpd-mod-vroot
* python-hiredis
* pytorch
* redis
* rsyslog
* rtpengine
* ruby-hiredis
* suricata
* syslog-ng
* trafficserver
* unbound
* webdis
* zmap
The only FTBFS was zmap, but that's FTBFS using unstable versions as
well. I'll therefore upload the experimental version to unstable now.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#896016: strace: please make the build reproducible
James Addison wrote: > Unfortunately there are plenty of FTBFS failures -- mostly test timeouts on > some architectures, alongside libfaketime errors that seem to affect i386 -- > but those seem like separate problems. Perhaps we could close this bug? Sure thing: as in, I agree that the FTBFS's are a separate problem and also that this bug can be closed. Can you go ahead and do so, presumably with the correct versioning? Many thanks. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1059014: stunnel4: please make the build reproducible
Source: stunnel4 Version: 3:5.70-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that stunnel4 could not be built reproducibly. This is because the stunnel manpage embedded the current build date. A patch is attached that seeds this value from SOURCE_DATE_EPOCH if it is available. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/07-reproducible-build.patch1970-01-01 01:00:00.0 +0100 --- b/debian/patches/07-reproducible-build.patch2023-12-19 10:10:27.992405010 + @@ -0,0 +1,19 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2023-12-19 + +--- stunnel4-5.70.orig/doc/Makefile.am stunnel4-5.70/doc/Makefile.am +@@ -14,9 +14,11 @@ DISTCLEANFILES = $(doc_DATA) + + SUFFIXES = .pod.in .8.in .html.in + ++BUILD_DATE = $(shell date --utc --date=@$(or $(SOURCE_DATE_EPOCH),$(shell date +%s)) +%Y.%m.%d) ++ + .pod.in.8.in: + pod2man -u -n stunnel -s 8 -r $(VERSION) \ +- -c "stunnel4 TLS Proxy" -d `date +%Y.%m.%d` $< $@ ++ -c "stunnel4 TLS Proxy" -d $(BUILD_DATE) $< $@ + + .pod.in.html.in: + pod2html --index --backlink --header \ --- a/debian/patches/series 2023-12-19 09:51:42.220785283 + --- b/debian/patches/series 2023-12-19 10:00:22.317767514 + @@ -3,3 +3,4 @@ 03-runas-user.patch 05-sample-sysconfdir.patch 06-no-openssl-version-check-autopkgtest.patch +07-reproducible-build.patch
Bug#1059013: wxmplot: please make the build reproducible
Source: wxmplot
Version: 0.9.58-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
wxmplot could not be built reproducibly.
This is because it embedded the current build date in the manual
pages. Patch attached that seeds this value from SOURCE_DATE_EPOCH if
available.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/0003-reproducible-build.patch 1970-01-01
01:00:00.0 +0100
--- b/debian/patches/0003-reproducible-build.patch 2023-12-19
09:55:20.149244757 +
@@ -0,0 +1,29 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-12-19
+
+--- wxmplot-0.9.58.orig/doc/conf.py
wxmplot-0.9.58/doc/conf.py
+@@ -7,15 +7,20 @@
+ # serve to show the default.
+
+ import os
++import time
+ import sys
+-from datetime import date
+
+ from packaging.version import parse as version_parse
+
+ import wxmplot
+
++date_str = time.strftime(
++"%Y-%m-%d",
++time.gmtime(int(os.environ.get('SOURCE_DATE_EPOCH', time.time(
++)
++
+ project = 'wxmplot'
+-copyright = f'{date.today()}, Matthew Newville, The University of Chicago'
++copyright = f'{date_str}, Matthew Newville, The University of Chicago'
+
+ release = version_parse(wxmplot.__version__).public
+
--- a/debian/patches/series 2023-12-19 09:51:50.852805288 +
--- b/debian/patches/series 2023-12-19 09:55:19.281243090 +
@@ -1,2 +1,3 @@
sphinx_support_mathjax.patch
0002-removed-sphinxcontrib.video-extension.patch
+0003-reproducible-build.patch
Bug#1058681: python-multipletau: please make the build reproducible
Source: python-multipletau
Version: 0.3.3+ds-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
python-multipletau could not be built reproducibly.
This is because the code to work out its "own" version number uses
the current build date. (It does attempt to use the creation time of
the source files, but I think pybuild is essentially resetting this
to the current time by copying it to its temporary build directories.)
Patch attached that uses SOURCE_DATE_EPOCH if available.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2023-12-14 12:33:24.343253202
+
@@ -0,0 +1,23 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-12-14
+
+--- python-multipletau-0.3.3+ds.orig/multipletau/_version.py
python-multipletau-0.3.3+ds/multipletau/_version.py
+@@ -121,7 +121,15 @@ if True: # pragma: no cover
+ # Get the version from the previously generated `_version_save.py`
+ longversion = load_version(versionfile)
+
+-# 3. last resort: date
++# 3. SOURCE_DATE_EPOCH
++if longversion == "":
++longversion = time.strftime(
++"%Y.%m.%d-%H-%M-%S",
++time.gmtime(int(os.environ.get('SOURCE_DATE_EPOCH', time.time(
++)
++print("Using SOURCE_DATE_EPOCH time as version:
{}".format(longversion))
++
++# 4. last resort: date
+ if longversion == "":
+ print("Could not determine version. Reason:")
+ print(traceback.format_exc())
--- a/debian/patches/series 2023-12-14 10:22:18.989780489 +
--- b/debian/patches/series 2023-12-14 12:33:23.379240195 +
@@ -1,3 +1,4 @@
examples_location.patch
packaged-mathjax.patch
python3.12.patch
+reproducible-build.patch
Bug#1057791: python-hiredis: Not built against system libhiredis library but claimed so
Boyuan Yang wrote:
> Package python-hiredis claimed to be using system libhiredis library through
> a custom patch. However, the built binary library is not linked against
> libhiredis […]
Oh, well spotted. How did you find this? :)
Will look at this once #107 is address. (I suspect that patching
out the "vendor/hiredis/%s.c" glob etc. will be the place to start,
though.)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1057721: openpyxl: please make the build reproducible
Source: openpyxl
Version: 3.1.2+dfsg-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
openpyxl could not be built reproducibly.
This is because the documentation embedded the current build year in
its documentation.
However, a patch is attached that seeds this date from SOURCE_DATE_EPOCH
if available.
[0] https://reproducible-builds.org/
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducibility_docs.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducibility_docs.patch 2023-12-07 14:25:29.745194613
+
@@ -0,0 +1,23 @@
+Description: Make the docs reproducible
+Author: Chris Lamb
+Last-Update: 2023-12-07
+
+--- openpyxl-3.1.2+dfsg.orig/doc/conf.py
openpyxl-3.1.2+dfsg/doc/conf.py
+@@ -68,9 +68,14 @@ master_doc = 'index'
+
+ # General information about the project.
+ project = u'openpyxl'
+-from datetime import date
++import os
++import time
++import datetime
++build_date = datetime.datetime.utcfromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
++)
+
+-copyright = u'2010 - {0}, {1}'.format(date.today().year, openpyxl.__author__)
++copyright = u'2010 - {0}, {1}'.format(build_date.year, openpyxl.__author__)
+
+ # The version info for the project you're documenting, acts as replacement for
+ # |version| and |release|, also used in various other places throughout the
--- a/debian/patches/series 2023-12-07 14:07:11.622651360 +
--- b/debian/patches/series 2023-12-07 14:24:37.929086483 +
@@ -2,3 +2,4 @@
python3p12_compat.patch
privacy.patch
reproducibility.patch
+reproducibility_docs.patch
Bug#1057710: python-aiostream: please make the build reproducible
Source: python-aiostream Version: 0.5.2-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that python-aiostream could not be built reproducibly. This is because the code to drop the cov-generated files was missing another wildcard: --- a/debian/rules 2023-12-07 12:25:27.150528838 + --- b/debian/rules 2023-12-07 12:31:09.076010951 + @@ -5,5 +5,5 @@ execute_after_dh_python3: # Drop cov-generated files - rm -fv debian/*/usr/lib/python3/dist-packages/.coverage + rm -fv debian/*/usr/lib/python3*/dist-packages/.coverage - rm -fvr debian/*/usr/lib/python3/dist-packages/htmlcov + rm -fvr debian/*/usr/lib/python3*/dist-packages/htmlcov Patch also attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2023-12-07 12:25:27.150528838 + --- b/debian/rules 2023-12-07 12:31:09.076010951 + @@ -5,5 +5,5 @@ execute_after_dh_python3: # Drop cov-generated files - rm -fv debian/*/usr/lib/python3/dist-packages/.coverage - rm -fvr debian/*/usr/lib/python3/dist-packages/htmlcov + rm -fv debian/*/usr/lib/python3*/dist-packages/.coverage + rm -fvr debian/*/usr/lib/python3*/dist-packages/htmlcov
Bug#1055229: bookworm-pu: package redis/5:7.0.11-1+deb12u1
Adam D. Barratt wrote: >> redis (5:7.0.11-1+deb12u1) bookworm; urgency=medium >> . >> * Drop ProcSubset=pid hardening flag from the systemd unit files it >> causes >> difficult-to-reproduce crashes with memory allocation errors. A big >> thanks >> to Arnaud Rebillout for the extensive investigation. >> (Closes: #1055039) >> * Update debian/gbp.conf for the debian/bookworm branch. > > Please go ahead. Uploaded. :) -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1056307: bookworm-pu: package lastpass-cli/1.3.7-1+deb12u1
Adam D. Barratt wrote: > The version for a backport needs to be 1.3.7-1~deb12u1, so as to be > lower than the original upload. > > With that change, please go ahead. Uploaded with the corrected version number. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1056649: vectorscan: please make the build reproducible
Source: vectorscan
Version: 5.4.11-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
vectorscan could not be built reproducibly.
This is because it embeds a timezone-sensitive date via CMake's
string(TIMESTAMP …) functionality:
string (TIMESTAMP BUILD_DATE "%Y-%m-%d")
Since version 3.8.0, CMake has seeded the underlying value of these
timestamps from SOURCE_DATE_EPOCH. However, the lack of the optional
"UTC" argument means that this deterministic date will still be
rendered nondeterministically under different timezones.
For example:
├── ./usr/include/hs/hs_version.h
│ @@ -28,15 +28,15 @@
│
│ #ifndef HS_VERSION_H_C6428FAF8E3713
│ #define HS_VERSION_H_C6428FAF8E3713
│
│ /**
│ * A version string to identify this release of Hyperscan.
│ */
│ -#define HS_VERSION_STRING "5.4.11 2023-11-20"
│ +#define HS_VERSION_STRING "5.4.11 2023-11-21"
This string is also included in various vectorscan binaries as well.
A patch attached that simply adds "UTC" to the TIMESTAMP call.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-builds.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-builds.patch 2023-11-24 10:14:29.621651931
+
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-11-24
+
+--- vectorscan-5.4.11.orig/CMakeLists.txt
vectorscan-5.4.11/CMakeLists.txt
+@@ -7,7 +7,7 @@ set (HS_MINOR_VERSION 4)
+ set (HS_PATCH_VERSION 11)
+ set (HS_VERSION ${HS_MAJOR_VERSION}.${HS_MINOR_VERSION}.${HS_PATCH_VERSION})
+
+-string (TIMESTAMP BUILD_DATE "%Y-%m-%d")
++string (TIMESTAMP BUILD_DATE "%Y-%m-%d" UTC)
+ message(STATUS "Build date: ${BUILD_DATE}")
+
+ # Dependencies check
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2023-11-24 10:14:28.081648884 +
@@ -0,0 +1 @@
+reproducible-builds.patch
Bug#1056573: openmrac-data: please make the build reproducible
(0) 91 1970-01-01 00:00:00.00 cone.png.3mt Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/reproducible-build.patch 2023-11-23 10:39:16.406417418 + @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2023-11-23 + +--- openmrac-data-1.1.orig/Makefile openmrac-data-1.1/Makefile +@@ -10,7 +10,7 @@ $(TARGET): *.jpg *.png *.3dm *.3mt *.cmo + while read line; do rm -f $$line.raw; sox $$line.wav --bits 16 $$line.raw; done < wavlist.txt + ls *.jpg *.png *.3dm *.3mt *.cmo *.def *.raw > filelist.txt + rm -f $(TARGET) +- while read line; do tar --owner=root:0 --group=root:0 --mtime='UTC 1970-01-01 00:00:00' -rvf $(TARGET) $$line; done < filelist.txt ++ while read line; do tar --owner=root:0 --group=root:0 --mtime='UTC 1970-01-01 00:00:00' --mode=go=rX,u+rw,a-s -rvf $(TARGET) $$line; done < filelist.txt + sha1sum $(TARGET) > $(TARGET).sha1sum + + clean: --- a/debian/patches/series 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/series 2023-11-23 10:39:00.718283781 + @@ -0,0 +1 @@ +reproducible-build.patch
Bug#1056572: maildir-utils: please make the build reproducible
Source: maildir-utils
Version: 1.10.8-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
maildir-utils could not be built reproducibly:
├── ./usr/share/man/man1/mu-add.1.gz
│ ├── mu-add.1
│ │ @@ -85,15 +85,15 @@
│ │ Dirk-Jan C. Binnema
│ │
│ │ .SH "COPYRIGHT"
│ │ .PP
│ │ This manpage is part of \fBmu\fP 1.10.8.
│ │
│ │ .PP
│ │ -Copyright © 2022-2024 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL version
3
│ │ +Copyright © 2022-2023 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL version
3
│ │ or later \fIhttps://gnu.org/licenses/gpl.html\fP. This is free software:
you are
A patch is attached that seeds this value from the SOURCE_DATE_EPOCH
environment variable.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2023-11-23 10:29:51.399821031
+
@@ -0,0 +1,21 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-11-23
+
+--- maildir-utils-1.10.8.orig/man/meson.build
maildir-utils-1.10.8/man/meson.build
+@@ -66,7 +66,13 @@ man_orgs=[
+
+ env = environment()
+ env.set('LANG', 'C')
+-yearmonth = run_command('date', '+%B %Y', check:true, capture:true, env: env)
++cmd = run_command('sh', '-c', 'echo $SOURCE_DATE_EPOCH')
++# https://reproducible-builds.org/docs/source-date-epoch/#meson
++source_date_epoch = cmd.stdout().strip()
++if source_date_epoch == ''
++ source_date_epoch = run_command('date', '+%s').stdout().strip()
++endif
++yearmonth = run_command('date', '-u', '-d', '@' + source_date_epoch, '+%B
%Y', check:true, capture:true, env: env)
+ ym=yearmonth.stdout().strip()
+
+ foreach src : man_orgs
--- a/debian/patches/series 2023-11-23 10:05:00.063724061 +
--- b/debian/patches/series 2023-11-23 10:29:50.287802884 +
@@ -5,3 +5,4 @@
more-man-page-fixes.patch
typo-fixes.patch
remove-mu4e-builddir.patch
+reproducible-build.patch
Bug#1056571: pelican: please make the build reproducible
Source: pelican
Version: 4.9.1+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
pelican could not be built reproducibly:
├── ./usr/share/doc/pelican/html/content.html
│ @@ -903,15 +903,15 @@
│
│
│
│
│
│
│
│ -Copyright 2010–2023, https://justinmayer.com;>Justin Mayer, Alexis Metaireau, and
contributors
│ +Copyright 2010–2024, https://justinmayer.com;>Justin Mayer, Alexis Metaireau, and
contributors
A patch is attached that seeds this date from the SOURCE_DATE_EPOCH
environment variable.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2023-11-23 10:30:16.704226475
+
@@ -0,0 +1,22 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-11-23
+
+--- pelican-4.9.1+dfsg.orig/docs/conf.py
pelican-4.9.1+dfsg/docs/conf.py
+@@ -1,5 +1,6 @@
+ import datetime
+ import os
++import time
+ import sys
+
+ if sys.version_info >= (3, 11):
+@@ -28,7 +29,7 @@ extensions = [
+ source_suffix = ".rst"
+ master_doc = "index"
+ project = project_data.get("name").upper()
+-year = datetime.datetime.now().date().year
++year =
datetime.datetime.utcfromtimestamp(int(os.environ.get('SOURCE_DATE_EPOCH',
time.time(.year
+ copyright = f"2010\u2013{year}"
+ exclude_patterns = ["_build"]
+ release = project_data.get("version")
--- a/debian/patches/series 2023-11-23 10:05:08.543720337 +
--- b/debian/patches/series 2023-11-23 10:17:42.964110770 +
@@ -1,2 +1,3 @@
default_theme.patch
drop-notmyidea-builtin-themes.patch
+reproducible-build.patch
Bug#1056398: php-doc: please make the build reproducible
Source: php-doc
Version: 20231115~git.99fbf5d+dfsg-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
php-doc could not be built reproducibly.
This is due to embedded timestamps. For example:
│ │ │ ├── ./usr/share/doc/php-doc/html/index.html
│ │ │ │ @@ -98,27 +98,27 @@
│ │ │ │
│ │ │ │ And several
others
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │ - 2023-11-21
│ │ │ │ + 2024-12-23
Patch attached that seeds this date from SOURCE_DATE_EPOCH instead.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2023-11-22 09:35:13.092088512
+
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-11-22
+
+---
php-doc-20231115~git.99fbf5d+dfsg.orig/phd/phpdotnet/phd/PI/DBHTMLHandler.php
php-doc-20231115~git.99fbf5d+dfsg/phd/phpdotnet/phd/PI/DBHTMLHandler.php
+@@ -98,7 +98,7 @@ class PI_DBHTMLHandler extends PIHandler
+ }
+ $format = $this->getAttribute("format");
+ if (!$format) {
+-return $this->format->appendData(date('c'));
++return $this->format->appendData(date('c',
getenv('SOURCE_DATE_EPOCH') ?: time()));
+ }
+ $dateFormat = "";
+ $len = strlen($format);
--- a/debian/patches/series 2023-11-22 09:29:46.742984644 +
--- b/debian/patches/series 2023-11-22 09:35:11.644083656 +
@@ -1,2 +1,3 @@
remove-xkcd-mediaobjects.patch
replace-non-free-stylesheets.patch
+reproducible-build.patch
Bug#1055876: lastpass-cli: lpass login fails with "Error: SSL peer certificate or SSH remote key was not OK."
Domenico Andreoli wrote: > As far as I can see the version in Bookworm is still severely broken > and unusable; it deserves at least a bug to document its state. Indeed; bookworm should either be updated or the package removed. I've filed a proposed update bug here: https://bugs.debian.org/1056307 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1056307: bookworm-pu: package lastpass-cli/1.3.7-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Dear stable release managers,
Please consider lastpass-cli (1.3.7-1+deb12u1) for bookworm:
lastpass-cli (1.3.7-1+deb12u1) bookworm; urgency=medium
.
* Upload latest upstream version to fix compatability with Lastpass's
SSL keys. (Closes: #1055876)
Currently, lastpass-cli is completely non-functioning in bookworm, so
it should either be updated or removed.
The full debdiff is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/debian/changelog b/debian/changelog
index 800751f..68e0043 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,42 @@
+lastpass-cli (1.3.7-1+deb12u1) bookworm; urgency=medium
+
+ * Upload latest upstream version to fix compatability with Lastpass's
+SSL keys. (Closes: #1055876)
+
+ -- Chris Lamb Mon, 20 Nov 2023 10:14:54 +
+
+lastpass-cli (1.3.7-1) unstable; urgency=medium
+
+ * New upstream release. (Closes: #1055876)
+ * Drop 0001-Fix-FTBFS-with-GCC-10.0.patch; applied upstream.
+
+ -- Chris Lamb Mon, 13 Nov 2023 12:40:41 +
+
+lastpass-cli (1.3.6-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Refresh patches.
+
+ -- Chris Lamb Sat, 09 Sep 2023 09:52:20 -0700
+
+lastpass-cli (1.3.5-2) unstable; urgency=medium
+
+ * Always use the Debian version number. (Closes: #1051218)
+
+ -- Chris Lamb Tue, 05 Sep 2023 10:12:30 -0700
+
+lastpass-cli (1.3.5-1) unstable; urgency=medium
+
+ * New upstream release. (Closes: #1050973)
+
+ -- Chris Lamb Thu, 31 Aug 2023 16:37:52 -0700
+
+lastpass-cli (1.3.4-2) unstable; urgency=medium
+
+ * Also clean test/.lpass directory. (Closes: #1048723)
+
+ -- Chris Lamb Tue, 22 Aug 2023 13:44:44 -0700
+
lastpass-cli (1.3.4-1) unstable; urgency=medium
* New upstream release.
diff --git a/.gitignore b/.gitignore
index 495a746..9383e25 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,4 @@ version.h
# IDE
/.idea
+/.vs
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 21c854d..e953cee 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,3 +1,13 @@
+# Vesion 1.3.7
+* Add support for reading encrypted URLs (Tibor Komlossy)
+* Fix GCC 10 compatibility issue #532 (Tibor Komlossy)
+
+# Version 1.3.6
+* Fix version (Béla Ormos)
+
+# Version 1.3.5
+* Updating certificate hashes (Béla Ormos)
+
# Version 1.3.4
* Updating post parameter (Gergely Der)
diff --git a/LASTPASS-VERSION-GEN b/LASTPASS-VERSION-GEN
index d9b0f48..8f75701 100755
--- a/LASTPASS-VERSION-GEN
+++ b/LASTPASS-VERSION-GEN
@@ -4,7 +4,7 @@
# You can find the original at
https://github.com/git/git/blob/master/GIT-VERSION-GEN
LPVF=version.h
-DEF_VER=v1.3.4.GIT
+DEF_VER=v1.3.7.GIT
LF='
'
diff --git a/blob.c b/blob.c
index 69d9f44..f95305f 100644
--- a/blob.c
+++ b/blob.c
@@ -104,6 +104,7 @@ void account_free_contents(struct account *account)
free(account->note);
free(account->name_encrypted);
free(account->group_encrypted);
+ free(account->url_encrypted);
free(account->username_encrypted);
free(account->password_encrypted);
free(account->note_encrypted);
@@ -320,6 +321,10 @@ static int read_boolean(struct chunk *chunk)
return item.data[0] == '1';
}
+static bool check_next_entry_encrypted(struct chunk *chunk) {
+ return (chunk->data + sizeof(uint32_t))[0] == '!';
+}
+
#define entry_plain_at(base, var) do { \
char *__entry_val__ = read_plain_string(chunk); \
if (!__entry_val__) \
@@ -360,6 +365,9 @@ static struct account *account_parse(struct chunk *chunk,
const unsigned char ke
entry_plain(id);
entry_crypt(name);
entry_crypt(group);
+ if (check_next_entry_encrypted(chunk))
+ entry_crypt(url);
+ else
entry_hex(url);
entry_crypt(note);
entry_boolean(fav);
diff --git a/blob.h b/blob.h
index d6c480a..ab6c32d 100644
--- a/blob.h
+++ b/blob.h
@@ -59,7 +59,7 @@ struct account {
char *name, *name_encrypted;
char *group, *group_encrypted;
char *fullname;
- char *url;
+ char *url, *url_encrypted;
char *username, *username_encrypted;
char *password, *password_encrypted;
char *note, *note_encrypted;
diff --git a/debian/control b/debian/control
index 64bb52d..5440be8 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
libxml2-dev,
pkg-config,
xsltproc,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
Homepage: https://github.com/lastpass/lastpass-cli
Vcs-Git: https://salsa.debian.org/lamby/pkg-lastpass-cli.git
Vcs-Browser: https://salsa.debian.org/lamby/pkg-lastpass-cli
diff --git a/debian/patches/0001-Fix-FTBFS-with-GCC-10.0.patch
b/debian/patches/0001-Fix-FTBFS-with-GCC-10.0.patch
deleted file mode 100644
index 4cef68b..000
--- a/debia
Bug#1056117: meson: generates non-determinstic .pkgconfig files
forwarded 1056117 https://github.com/mesonbuild/meson/pull/12528 thanks Jussi Pakkanen wrote: > Please file all changes like these directly upstream. The Meson > packaging prohibits patches that alter functionality. Sure thing. I've done that here: https://github.com/mesonbuild/meson/pull/12528 (Although do note that I've suggested a slightly less intrusive patch for reasons mentioned in the pull request.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1056119: taffybar: please make the build reproducible
Source: taffybar Version: 4.0.1-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: umask X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that taffybar could not be built reproducibly. This is because the permissions of a directory in the binary can vary on the umask: │ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-10-25 06:27:09.00 ./usr/share/taffybar/ │ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-10-25 06:27:09.00 ./usr/share/taffybar/icons/ │ │ │ │ +drwxrwxr-x 0 root (0) root (0)0 2023-10-25 06:27:09.00 ./usr/share/taffybar/ │ │ │ │ +drwxrwxr-x 0 root (0) root (0)0 2023-10-25 06:27:09.00 ./usr/share/taffybar/icons/ Patch attached that manually calls chmod on these directories. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2023-11-17 08:29:54.308271334 + --- b/debian/rules 2023-11-17 08:44:49.533041462 + @@ -7,3 +7,4 @@ binary-fixup/taffybar:: install -m 755 -s -D dist-ghc/build/taffybar/taffybar debian/taffybar/usr/bin/taffybar || true cp -R debian/tmp-inst-ghc/usr/share/taffybar debian/taffybar/usr/share + find debian/taffybar/usr/share -type d -print0 | xargs -0r chmod 755
Bug#1056118: radsecproxy: please make the build reproducible
Source: radsecproxy
Version: 1.10.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed that
radsecproxy could not be built reproducibly.
This was because it embedded the current build date in the manual
pages. A patch is attached that seeds this from SOURCE_DATE_EPOCH
(if available).
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/reproducible-build 2023-11-17 08:43:16.864943941 +
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2023-11-17
+
+--- radsecproxy-1.10.0.orig/configure.ac
radsecproxy-1.10.0/configure.ac
+@@ -12,7 +12,7 @@ AC_PROG_RANLIB
+ AC_CHECK_FUNCS([mallopt])
+ AC_REQUIRE_AUX_FILE([tap-driver.sh])
+
+-RELEASEDATE=m4_esyscmd([date +%Y-%m-%d])
++RELEASEDATE=m4_esyscmd([date --utc --date="@${SOURCE_DATE_EPOCH:-$(date
+%s)}" +%Y-%m-%d])
+ AC_SUBST(RELEASEDATE)
+
+ m4_version_prereq(2.70, [], [AC_PROG_CC_C99])
--- a/debian/patches/series 2023-11-17 08:31:01.036451991 +
--- b/debian/patches/series 2023-11-17 08:43:15.736942848 +
@@ -1 +1,2 @@
fix-spelling
+reproducible-build
Bug#1056117: meson: generates non-determinstic .pkgconfig files
Source: meson
Version: 1.2.3-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort, we noticed that
meson was generates .pkgconfig files that are not reproducible.
For example, here is neatvnc's pkgconfig file:
Name: neatvnc
Description: A Neat VNC server library
Version: 0.7.0
-Requires.private: pixman-1, aml < 0.4.0, aml >= 0.3.0, zlib, libdrm,
libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter,
libavutil
+Requires.private: pixman-1, aml >= 0.3.0, aml < 0.4.0, zlib, libdrm,
libturbojpeg, gnutls, nettle, hogweed, gmp, gbm, libavcodec, libavfilter,
libavutil
Libs: -L${libdir} -lneatvnc
Libs.private: -lm
Cflags: -I${includedir}
A patch is attached that sorts the output, resulting in:
Requires.private: aml < 0.4.0, aml >= 0.3.0, gbm, gmp, gnutls, hogweed,
libavcodec, libavfilter, libavutil, libdrm, libturbojpeg, nettle, pixman-1, zlib
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/mesonbuild/modules/pkgconfig.py b/mesonbuild/modules/pkgconfig.py
index 63025a5..2a0e577 100644
--- a/mesonbuild/modules/pkgconfig.py
+++ b/mesonbuild/modules/pkgconfig.py
@@ -310,7 +310,7 @@ class DependenciesHelper:
result += [name + ' ' + self.format_vreq(vreq) for vreq in
vreqs]
else:
result += [name]
-return ', '.join(result)
+return ', '.join(sorted(result))
def remove_dups(self) -> None:
# Set of ids that have already been handled and should not be added
any more
Bug#1055919: python-ansible-pygments: please make the build reproducible
Stuart Prescott wrote: > I think there's a subtle bug about altering `dirs` while > inside a loop from `os.walk`: I'm quite impressed that you managed to hunt this down — that's very nice work. :) > Which item is not processed in the next iteration by dh_python3 now > depends on the order in which `os.walk` lists the directories. That is > presumably dependent on all manner of things (filesystem? collation? > luck?). It will be dependent entirely on the filesystem being used because `os.walk` merely passes on the underlying filesystem ordering. (The same is true for GNU find as you later query.) Entirely anecdotally, ext4 will be "more orderful", whilst btrfs, possibly due to the way it rebalances its tree data structures, tends to be less so. I raise it only because it can help explain why different folks will get different results locally despite using the same building tools. Building under tmpfs will have different properties as well. Anyway, thank you again. Once this is addressed in dh-python (even as a proposed patch), I'll go through the last few months of bugs that I've filed and see whether they can be closed. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1055919: python-ansible-pygments: please make the build reproducible
[[ looping reproducible-bui...@lists.alioth.debian.org in on this issue ]] Stuart Prescott wrote: > Is there something about the r-b setup that would cause these > directories to be created and appear in the package? Hm, you know, I think there must be. In fact, connecting a few dots in my head, that now makes three recent reproducibility bugs that the buildds are not, if you can excuse the expression, reproducing: 1. https://bugs.debian.org/1055919 (this bug) 2. https://bugs.debian.org/1053353 3. https://bugs.debian.org/1000401 I would be more than willing to conclude that this is an issue in tests.reproducible-builds.org setup. However, I am actually seeing these test files when I build locally as well — and my patch consequently fixes the "problem". Moreover, I am not using the same setup as tests.reproducible-builds.org at all. (Can you confirm whether you see them when building locally?) I won't file any more until this has been more generally resolved. Hopefully I haven't been filing similar issues recently (#1055920?) and not realising it. (Has a build-dependency changed and then the buildd chroots are out of sync? Is that even possible? Am I?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1055920: bidict: please make the build reproducible
Source: bidict Version: 0.22.1-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that bidict could not be built reproducibly. This was because the binary package embeds files generated by the Python "Hypothesis" package during the tests. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2023-11-14 09:26:04.585510834 + --- b/debian/rules 2023-11-14 09:32:18.630291811 + @@ -14,3 +14,6 @@ $(CURDIR)/debian/python-bidict-doc/usr/share/doc/python-bidict-doc/html dh_sphinxdoc endif + +execute_after_dh_auto_test: + find .pybuild -type d -name .pytest_cache -print0 | xargs -0r rm -rfv
Bug#1055919: python-ansible-pygments: please make the build reproducible
Source: python-ansible-pygments Version: 0.1.1-6 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that python-ansible-pygments could not be built reproducibly. This is because the binary package included .pytest_cache and .test-results directories. Patch attached that removes these after running the tests. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2023-11-14 09:25:37.237065158 + --- b/debian/rules 2023-11-14 09:28:11.611381883 + @@ -4,3 +4,6 @@ %: dh $@ --buildsystem=pybuild + +execute_after_dh_auto_test: + find .pybuild -type d \( -name .pytest_cache -or -name .test-results \) -print0 | xargs -0r rm -rfv
Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid
Chris Lamb wrote: >> you mean with 'stable'? ProcSubset=pid definitely exists in >> bookworm, and that's debian stable. > > D'oh, of course! As you might have guessed, I had a "brain typo" and > had completely forgotten that stable = bookworm (and not bullseye). > I'll get onto this presently. This has been filed as #1055229. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1055229: bookworm-pu: package redis/5:7.0.11-1+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu Dear stable release managers, Please consider redis (5:7.0.11-1+deb12u1) for bookworm: redis (5:7.0.11-1+deb12u1) bookworm; urgency=medium . * Drop ProcSubset=pid hardening flag from the systemd unit files it causes difficult-to-reproduce crashes with memory allocation errors. A big thanks to Arnaud Rebillout for the extensive investigation. (Closes: #1055039) * Update debian/gbp.conf for the debian/bookworm branch. The full diff is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diff --git a/debian/changelog b/debian/changelog index 2c77a5d1..2f74a30f 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +redis (5:7.0.11-1+deb12u1) bookworm; urgency=medium + + * Drop ProcSubset=pid hardening flag from the systemd unit files it causes +difficult-to-reproduce crashes with memory allocation errors. A big thanks +to Arnaud Rebillout for the extensive investigation. +(Closes: #1055039) + * Update debian/gbp.conf for the debian/bookworm branch. + + -- Chris Lamb Thu, 02 Nov 2023 15:24:45 +0100 + redis (5:7.0.11-1) unstable; urgency=high * New upstream security release: diff --git a/debian/bin/generate-systemd-service-files b/debian/bin/generate-systemd-service-files index b1e43c86..c7eafabe 100755 --- a/debian/bin/generate-systemd-service-files +++ b/debian/bin/generate-systemd-service-files @@ -96,7 +96,6 @@ LockPersonality=true MemoryDenyWriteExecute=true NoNewPrivileges=true PrivateUsers=true -ProcSubset=pid ProtectClock=true ProtectControlGroups=true ProtectHostname=true diff --git a/debian/gbp.conf b/debian/gbp.conf index 24e95b17..14717f8e 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,3 +1,3 @@ [DEFAULT] -debian-branch=debian/sid -upstream-branch=upstream/sid +debian-branch=debian/bookworm +upstream-branch=upstream/bookworm
Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid
Hi Arnaud > you mean with 'stable'? ProcSubset=pid definitely exists in > bookworm, and that's debian stable. D'oh, of course! As you might have guessed, I had a "brain typo" and had completely forgotten that stable = bookworm (and not bullseye). I'll get onto this presently. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid
Hey Arnaud, > I would say yes, upload to stable as well. I just had a good look and ProcSubset=pid does not exist in redis in stable, so no backport or update needed. (That's good, because updating stable is a not completely straightforward.) > Moreover, I see that ProcSusbset=pid caused some trouble already, that > you fixed in 80470e3dc0ae56db9c9512c38a175783bcfc ;) Ah, I had forgotten about that... And, yes, based on your other remarks it seems like this hardening flag is a little troublesome, so I'm more confident about dropping it. Glad that we (well, you!) managed to solve this problem and thanks for passing it on. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1000401: golang-github-go-git-go-git: please make the build reproducible
Chris Lamb wrote: > However, if you don't see these files when you "dpkg -c" the .deb > files, that suggests something strange is going on... I am seeing them, at least: $ dget --quiet golang-github-go-git-go-git-dev $ dpkg -c golang-github-go-git-go-git-dev_5.4.2-3_all.deb | grep tmp | tail -n10 -rw-r--r-- root/root 1919 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/51/7a2143aae436b802cac429249a4df4b4b39cec drwxr-xr-x root/root 0 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/59/ -rw-r--r-- root/root 1925 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/59/a889a87437c5c9cb1d249f5a38b29102dd2af4 drwxr-xr-x root/root 0 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/91/ -rw-r--r-- root/root 885 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/91/3a3f146a2d1eff37138e668ebb67ff265227b8 drwxr-xr-x root/root 0 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/ee/ -rw-r--r-- root/root 177 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/ee/372bb08322c1e6e7c6c4f953cc6bf72784e7fb drwxr-xr-x root/root 0 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/pack/ -rw-r--r-- root/root111840 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/pack/pack-f2e0a8889a746f7600e07d2246a2e29a72f696be.idx -rw-r--r-- root/root 1542854 2021-11-22 05:37 ./usr/share/gocode/src/github.com/go-git/go-git/plumbing/format/packfile/.tmp/946035611/objects/pack/pack-f2e0a8889a746f7600e07d2246a2e29a72f696be.pack $ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1000401: golang-github-go-git-go-git: please make the build reproducible
Hi Santiago, > The program is already built when the tests are executed. How does the > outcome of the tests affects the package contents? Unfortunately I don't remember the specific details of this, but the testsuite affecting the debs is definitely possible. Specifically, if the ordering of a Debian package build, in rough terms, is: 1. Compile the code (into the working directory) 2. Run the testsuite 3. Build/construct the .debs ... then if the tests modify the working directory (and/or subdirs), then the .debs could definitely reflect those changes, no? However, if you don't see these files when you "dpkg -c" the .deb files, that suggests something strange is going on... Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1055039: redis-server: Crash every two hours (oom), seemingly due to systemd's ProcSubset=pid
tags 1055039 + pending thanks Hey Arnaud! > Long story below. A huge thanks for tracking this down! I've gone ahead and removed ProcSubset=pid from the systemd unit files, and am uploading a version to unstable and experimental right now. However, do you think this warrants an update to stable as well…? Thanks again. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1054574: adminer seems dead upstream, switch to adminerevo ?
Hi Alexandre, > 1) new package src:adminerevo providing adminer and removal of src:adminer > > Advantages : explicit branding > > 2) src:adminer using adminerevo source and building adminer pkg > > Advantages : easy upgrade path (no Provides:, Conflicts:, no conffile > moving around in postinst) > > 3) src:adminer using adminerevo source and building adminerevo pkg > > Advantages : explicit branding for binary package and easier > going back if src:adminer ever comes back alive Hmm. Unfortunately I'm a little bit out of the loop with adminer stuff so I won't be able to provide anything close to reliable guidance. However, I'm a little hesitant re. using the existing src:adminer with the adminerevo source (ie. #2 and #3) on philosophical/aesthetic grounds. It just feels "right" to have a different source package for that. Perhaps consider raising this on debian-devel for clarification, otherwise I'd go with #1. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
