Bug#794372: Oh, the transition!
I have been reminded that there's a nasty C++ transition going on, so these might be transient (i.e. fixed when the upstream libraries are done transitioning). Feel free to close as invalid, drop priority, or whatever! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793319: FTBFS: ImportError: cannot import name component_re
On Wed, Aug 12, 2015 at 04:31:15PM +0300, Gediminas Paulauskas wrote: > Now that Bug#779324 is fixed, a simple rebuild would fix the problem. Looks good, yep.
Bug#793518: [pkg-go] Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.
On Mon, Jul 27, 2015 at 07:26:10PM +0200, Michael Stapelberg wrote: > control: tags -1 + unreproducible > > Chris, was this an issue on your end? Or am I misinterpreting something? > The problem seems to have gone away. I was running local builds in response to errors on the reproducible-builds builder. Their builder has rebuilt sucessfully since then, and I have also just rebuilt sucessfully. Perhaps it was fixed by dependency changes? Proof I'm not mad: my build log from local: https://paste.debian.net/286717/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793518: [pkg-go] Bug#793518: FTBFS: TestString fails: ini_test.go:167: Dict cannot be stringified as expected.
On Mon, Jul 27, 2015 at 10:45:17PM +0200, Michael Stapelberg wrote: > Actually, my bad, the commit I referenced is already in the package in the > form of a patch. > > In your https://paste.debian.net/286717/, I don’t see any mention of the > patch, though…? Does your build environment not apply patches? When running > gbp buildpackage --git-pbuilder, I see: > [..] Unless I'm missing something, the patch is not in the version in unstable/testing. Looking at the git repo linked from tracker.d.o, https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-glacjay-goini.git/ the patch was added after the release was tagged. The paste link is building from unstable, so (correctly) isn't seeing the patch? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#792064: [Pkg-javascript-devel] Bug#792064: FTBFS: tests fail with CAP_DAC_OVERRIDE and without networking
On Sun, Jul 12, 2015 at 05:56:08PM +0200, Luca Bruno wrote: > However, as this seems to be part of repro-build (which I do care about), you > can find a patch here that should fix it. Let me know if it works. Woo, thanks! > > If you have CAP_DAC_OVERRIDE (e.g. you're running the build as root), > > Isn't this an incredibly bad practice? That builder (one I'm in the middle of writing!) runs stuff as "uid 0" inside an unprivileged LXC (i.e. in a new uid/pid/mount/... namespace), which is (I believe) supported for security, i.e. it should be safe. It's easy enough to flip the builder over to using a normal user inside the container, in the future. I was under the impression that there was a policy entry requiring stuff to be buildable as root, so I thought I'd let it run as root for now. Otoh, I can't actually find said policy entry, nor one for requiring packages to build without networking; perhaps the latter covered simply by the requirement that there's no dependency on anything outside of main. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#792221: libnet-frame-device-perl: FTBFS without networking: t/04-new-default and t/05-new-target fail
On Mon, Jul 13, 2015 at 01:19:29AM +0200, gregor herrmann wrote:
> > Full build log:
> > https://reproducible.debian.net/rb-pkg/unstable/amd64/libnet-frame-device-perl.html
>
> It seems to be a bit more complicated than that.
>
> With "USENETWORK=no" I indeed see the failures:
> ...
> # Using Test.pm version 1.26
> Dubious, test returned 101 (wstat 25856, 0x6500)
> Failed 1/1 subtests
> Possible precedence issue with control flow operator at
> /tmp/buildd/libnet-frame-device-perl-1.10/blib/lib/Net/Frame/Device.pm line
> 63.
> Net::Frame::Device: updateFromTarget: unable to get dnet
> t/05-new-target.t
> 1..1
> # Running under perl version 5.020002 for linux
> # Current time local: Sun Jul 12 23:16:50 2015
> # Current time GMT: Sun Jul 12 23:16:50 2015
> # Using Test.pm version 1.26
> Dubious, test returned 101 (wstat 25856, 0x6500)
> Failed 1/1 subtests
>
>
> but only during the build, when cowbuilder drops me into a shell, a
> manual `prove --blib --verbose t/*.t' works fine.
I was manually re-testing things inside lxc (with eth0 down), and can
hit the failure even with `prove`:
% lxc-attach -n sid2
root@sid2:~# cd libnet-frame-device-perl-1.10/
root@sid2:~/libnet-frame-device-perl-1.10# ifdown eth0
[...]
root@sid2:~/libnet-frame-device-perl-1.10# prove --blib --verbose t/*.t
t/01-use.t ...
[...]
t/04-new-default.t ...
1..1
# Running under perl version 5.020002 for linux
# Current time local: Mon Jul 13 07:23:47 2015
# Current time GMT: Mon Jul 13 07:23:47 2015
# Using Test.pm version 1.26
Possible precedence issue with control flow operator at
/home/faux/libnet-frame-device-perl-1.10/blib/lib/Net/Frame/Device.pm line 63.
Net::Frame::Device: updateFromDefault: unable to get dnet
Dubious, test returned 101 (wstat 25856, 0x6500)
Failed 1/1 subtests
t/05-new-target.t
1..1
# Running under perl version 5.020002 for linux
# Current time local: Mon Jul 13 07:23:47 2015
# Current time GMT: Mon Jul 13 07:23:47 2015
# Using Test.pm version 1.26
Possible precedence issue with control flow operator at
/home/faux/libnet-frame-device-perl-1.10/blib/lib/Net/Frame/Device.pm line 63.
Net::Frame::Device: updateFromTarget: unable to get dnet
Dubious, test returned 101 (wstat 25856, 0x6500)
Failed 1/1 subtests
Is it my imagination, or does that "unable to get dnet" message appear
in the 05 test only for me?
---
And, because I failed to send the e-mail before getting distracted, I
did some debugging:
The (apparent) error is it calling intf_get_dst('1.1.1.1') which
"retrieves the configuration for the best interface with which to
reach the specified dst.", which fails.
Indeed, I can reproduce this for 04 by blackholing 1.1.1.1 (I don't
actually know what this does, but it sounds cool):
root@sid2:~/libnet-frame-device-perl-1.10# prove --blib --verbose t/*.t
>/dev/null 2>&1 && echo passed
passed
root@sid2:~/libnet-frame-device-perl-1.10# ip r add blackhole 1.1.1.1/32
root@sid2:~/libnet-frame-device-perl-1.10# prove --blib --verbose t/*.t
t/04-new-default.t ...
1..1
[...]
Possible precedence issue with control flow operator at
/home/faux/libnet-frame-device-perl-1.10/blib/lib/Net/Frame/Device.pm line 63.
Net::Frame::Device: updateFromDefault: unable to get dnet
Dubious, test returned 101 (wstat 25856, 0x6500)
Failed 1/1 subtests
t/05-new-target.t
1..1
[...]
# Using Test.pm version 1.26
Possible precedence issue with control flow operator at
/home/faux/libnet-frame-device-perl-1.10/blib/lib/Net/Frame/Device.pm line 63.
$VAR1 = {
'gatewayIp' => '10.0.3.1',
[...]
root@sid2:~/libnet-frame-device-perl-1.10# ip r del 1.1.1.1
Does that help you reproduce it? I suspect the answer is simply to disable
these tests if there isn't public connectivity (or just generally), however.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778421: haskell-hscurses: FTBFS haskell-devscripts (>= 0.9) isn't in unstable
Package: src:haskell-hscurses
Version: 1.4.2.0-1
Severity: wishlist
Dear Maintainer,
The package depends on haskell-devscripts (>= 0.9), which is only in
experimental, not sid.
pbuilder:
The following NEW packages will be installed:
cdbs{a} ghc{a} ghc-doc{a} ghc-haddock{a} ghc-prof{a} libbsd-dev{a}
libbsd0{a} libffi-dev{a} libghc-exceptions-dev{a}
libghc-exceptions-doc{a} libghc-exceptions-prof{a} libghc-mtl-dev{a}
libghc-mtl-doc{a} libghc-mtl-prof{a} libghc-transformers-dev{a}
libghc-transformers-prof{a} libgmp-dev{a} libgmpxx4ldbl{a}
libncurses5-dev{a} libtinfo-dev{a}
0 packages upgraded, 20 newly installed, 0 to remove and 0 not upgraded.
Need to get 65.4 MB of archives. After unpacking 761 MB will be used.
The following packages have unmet dependencies:
pbuilder-satisfydepends-dummy : Depends: haskell-devscripts (>= 0.9) but it is
not going to be installed.
Unable to resolve dependencies! Giving up...
[...]
Abort.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775010: libmaven-archiver-java: please allow pom.properties' date to be deterministic
Package: libmaven-archiver-java
Version: 2.5-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that many Java packages would not build reproducibly because Maven emits
a build date in the "pom.properties" file generated by maven-archiver
(as used by maven-jar-plugin) [2].
Ideally, this date would be removed.
I believe that it's there by accident:
* it's in a comment so it's hard (but not impossible) for people to access
* it's written by java.lang.Properties, not intentionally by Maven code
* it's not updated by any of the code in maven-archiver to update the file
However, in order to maintain nearly total backwards compatability, the
attached patch causes the original behaviour to be maintained unless a
BUILD_DATE environment variable is set. The plan is for this to
(eventually) be set by something like javahelper. Patch should apply to
2.5, 2.6 and trunk at time of writing (2.7-SNAPSHOT).
Your thoughts would be appreciated. There are some alternative
solutions being gathered on the wiki [3].
Cheers.
[1]: https://wiki.debian.org/ReproducibleBuilds
[2]:
https://reproducible.debian.net/issues/timestamps_in_maven_pom_files_issue.html
[3]: https://wiki.debian.org/ReproducibleBuilds/TimestampsInMavenPomProperties
>From d725546a99257c1fe6b03a7321142e6d564665d7 Mon Sep 17 00:00:00 2001
From: "Chris West (Faux)"
Date: Fri, 9 Jan 2015 21:19:43 +
Subject: [PATCH] honour BUILD_DATE when generating pom.properties
---
.../apache/maven/archiver/PomPropertiesUtil.java | 88 +-
.../maven/archiver/PomPropertiesUtilTest.java | 34 +
2 files changed, 121 insertions(+), 1 deletion(-)
create mode 100644 src/test/java/org/apache/maven/archiver/PomPropertiesUtilTest.java
diff --git a/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java b/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java
index 5e0a41b..605a2f1 100644
--- a/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java
+++ b/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java
@@ -25,6 +25,17 @@ import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.io.OutputStreamWriter;
+import java.io.Writer;
+import java.io.BufferedWriter;
+import java.text.SimpleDateFormat;
+import java.text.ParseException;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
+import java.util.Date;
+import java.util.List;
+import java.util.Map;
import java.util.Properties;
import org.apache.maven.project.MavenProject;
@@ -85,7 +96,7 @@ public class PomPropertiesUtil
OutputStream os = new FileOutputStream( outputFile );
try
{
-properties.store( os, GENERATED_BY_MAVEN );
+storeWithCustomTimestamp(properties, os);
os.close(); // stream is flushed but not closed by Properties.store()
os = null;
}
@@ -117,4 +128,79 @@ public class PomPropertiesUtil
archiver.addFile( pomPropertiesFile, "META-INF/maven/" + groupId + "/" + artifactId + "/pom.properties" );
}
+
+/**
+ * Java always writes the date in a comment. We have to reimplement the method to change the date.
+ */
+static void storeWithCustomTimestamp(Properties properties, OutputStream os) throws IOException {
+final BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(os, "8859_1"));
+try {
+writer.append("#" + GENERATED_BY_MAVEN);
+writer.newLine();
+writer.append("#" + computeBuildDate().toString());
+writer.newLine();
+final List> entries =
+new ArrayList>(properties.entrySet());
+Collections.sort(entries, new Comparator>() {
+public int compare(Map.Entry left, Map.Entry right) {
+return String.valueOf(left.getKey()).compareTo(String.valueOf(right.getKey()));
+}
+});
+for (Map.Entry property : entries) {
+writer.write(property.getKey() + "=" + escapeForProperties(String.valueOf(property.getValue(;
+writer.newLine();
+}
+} finally {
+writer.flush();
+writer.close();
+}
+}
+
+private static Date computeBuildDate() {
+final String envVariable = System.getenv("BUILD_DATE");
+if (null != envVariable) {
+try {
+return new SimpleDateFormat("EEE, dd MMM HH:mm:ss zzz").parse(envVariable);
+} catch (ParseException e) {
+System.err.println("maven-archiver: BUILD_DATE not in recognised format");
+e.printStackTrace();
+// fall through
+}
+}
+return new Date();
+}
+
+static
Bug#775010: libmaven-archiver-java: please allow pom.properties' date to be deterministic
On Sat, Jan 10, 2015 at 10:19:19PM +0100, Emmanuel Bourg wrote: > Thank you for the update. It's safe to assume the date always follow the > comment specified, the Javadoc for the store() method states: > > "Next, a comment line is always written, consisting of an ASCII # > character, the current date and time (as if produced by the toString > method of Date for the current time), and a line separator as generated > by the Writer." Sweet. > The call to Arrays.sort() isn't necessary but it doesn't hurt. I couldn't see any evidence that the properties would always come out in the same order; it looks like it defers to Hashtable, which definitely doesn't have defined iteration order (in theory, but probably does in practice (unless any of that security-driven randomized hashCode stuff went in (which I can't see any evidence of))). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#802059: Already reported against glibmm2.4
Maybe this is a duplicate of: https://bugs.debian.org/800371 ..depending on the solution they arrive at.
Bug#802105: iodine: FTBFS: Assertion 'addr_len == sizeof(struct sockaddr_in)' failed
On Sat, Oct 17, 2015 at 05:58:13PM +0200, gregor herrmann wrote: > I'm lowering the severity of the bug for now, since this doesn't > look like a bug in the code itself but like a weird interaction > between the test suite and pbuilder's optional use of namespaces. > Heh. I try and eliminate these cases by rebuilding them on lxc (which it also failed in the same way), but lxc /also/ has weird uses of namespaces, so.. :)
Bug#789832: unburden-home-dir: FTBFS: t/unexpected-cases.t fails on amd64
On Thu, Jun 25, 2015 at 12:03:04AM +0200, Axel Beckert wrote: > > t/undo.t ... ok > > t/unexpected-cases.t ... > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/98 subtests > thanks for the report, but I couldn't reproduce this, neither with > 0.3.3 nor with the HEAD of the git repository. And > https://reproducible.debian.net/rb-pkg/unstable/amd64/unburden-home-dir.html > shows different tests failing, but not t/unexpected-cases.t. > > Can you please explain a little bit more about your setup? pbuilder or > sbuild? On which file system where the tests run? (And if the > reporting machine was not the same as the machine where the issue > happend: Which locale was set? Which init system was used? Which > kernel was running?) etc. Hah. After far too much staring, the test which is failing for me is: ok 93 - Make list file t/zo4O_qcnum/list unreadable ok 94 - Call 'perl bin/unburden-home-dir -C t/zo4O_qcnum/config -c /dev/null -L t/zo4O_qcnum/list -l /dev/null' not ok 95 - Check STDERR # Failed test 'Check STDERR' # at t/lib/Test/UBH.pm line 260. # --- Got # +++ Expected # @@ -1 +1,2 @@ # -'' # +'List file t/8mn4dawfHl/list isn\'t readable, skipping at # unburden-home-dir line . # +' # Looks like you failed 1 test of 98. It's running chmod foo && cat foo, and expecting it to fail. It succeeds for me as I have a better simulation of root: I'm running the build as very-nearly root on a VM. (root in an unpriviliged LXC container). The full build log isn't much more useful; sorry for missing some important parts in the initial report: https://paste.debian.net/260610/ My specific bug is probably invalid, in this case? I don't think we expect the builds to pass as root. Weird test, though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#805249: pyparted: FTBFS: PartedException: Unknown disk flag, 1000.
Hmm. I re-test things on my local builder before reporting them, so I've definitely been able to reproduce this failure. My builder is much more normal than jenkins: it uses apt to resolve packages, and things like that. If you don't have any ideas then I can run the build a few more times and see if I can catch what's up.
Bug#745224: FTBFS on amd64/sid
Control: severity -1 serious The package fails to build on amd64 in sid with the same errors. Full build log (reproduced outside of pbuilder locally): https://reproducible.debian.net/rb-pkg/unstable/amd64/stretchplayer.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776292: -Werror is on by default, so FTBFS in sid
Control: severity -1 serious The package fails to build in sid, as -Werror is on by default. Full build log (checked locally): https://reproducible.debian.net/rb-pkg/unstable/amd64/ffrenzy.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790800: ..or maybe this is just transition noise
This is happening to other packages too, and I can't find the .moc files I thought were bundled before; maybe it's just transition related and will go away? See e.g. qapt: https://reproducible.debian.net/rb-pkg/unstable/amd64/qapt.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#791410: m17n-db: FTBFS due to missing Build-Conflicts: locales-all
On Mon, Jul 06, 2015 at 03:37:04PM +0530, Harshula wrote: > Hi, > > Could you please elaborate on what changed to cause this side-effect? There was no change to your package or any other package; it has (as far as I'm aware) always been legal to have locales-all instead of locales. It's just likely that nobody has ever tried this before... > > Thanks, > # > > On 04/07/15 18:47, Chris West (Faux) wrote: > > Source: m17n-db > > Version: 1.6.5-1 > > Severity: important > > Tags: sid stretch > > User: reproducible-bui...@lists.alioth.debian.org > > Usertags: ftbfs > > > > Dear Maintainer, > > > > The package fails to build when locales-all is installed. > > locales-all "provides" locales, but doesn't really have all the stuff > > everyone expects. > > There is some discussion available in https://bugs.debian.org/788353 > > > > Please apply the recommended solution, adding: > > Build-Conflicts: locales-all > > > > > > Specific error: > > > > config.status: creating po/Makefile > > config.status: executing depfiles commands > > ---ERROR---ERROR---ERROR > > Can't find source files for generating charset maps. > > Run the script "./get-glibc.sh", and try again. > > Or, read the installation procedure in the file README. > > --with-charmaps=--DIRECTORY-OF-GLIBC-SOURCE--/localedata/charmaps > > ---ERROR---ERROR---ERROR > > dh_testdir > > /usr/bin/make > > make[1]: Entering directory '/tmp/buildd/m17n-db-1.6.5' > > Making all in po > > make[2]: Entering directory '/tmp/buildd/m17n-db-1.6.5/po' > > make[2]: Nothing to be done for 'all'. > > make[2]: Leaving directory '/tmp/buildd/m17n-db-1.6.5/po' > > Making all in LANGDATA > > make[2]: Entering directory '/tmp/buildd/m17n-db-1.6.5/LANGDATA' > > (for f in [a-z][a-z].lnm [a-z][a-z][a-z].lnm; do \ > > l=`basename $f .tbl`; \ > > sed -n -e "/($l /s/(\([a-z]*\)[^\"]*\"\([^\"]*\)\")/\1|\2/p" < $f; \ > > done) > native.ext > > mawk -f LANGUAGE.awk '-F|' < ISO-639-2.txt > LANGUAGE.tbl > > make[2]: Leaving directory '/tmp/buildd/m17n-db-1.6.5/LANGDATA' > > make[2]: Entering directory '/tmp/buildd/m17n-db-1.6.5' > > make[2]: *** No rule to make target '8859-2.map', needed by 'all-am'. Stop. > > > > > > Full build log: > > https://reproducible.debian.net/rb-pkg/unstable/amd64/m17n-db.html > > > > -- System Information: > > Debian Release: stretch/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 3.19.0-21-generic (SMP w/8 CPU cores) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#808640: [Pkg-freeipa-devel] Bug#808640: custodia: FTBFS: Could not find any downloads that satisfy the requirement sphinx<1.3.0
On Tue, Dec 29, 2015 at 08:06:06AM +0200, Timo Aaltonen wrote: > > So what's special about this build env compared to normal sbuild, where > it builds just fine? > The build runs without networking, like the main buildds, and the Ubuntu buildds. The Policy requires builds to complete without depending on external resources, and we implement this by banning networking. In this case, it looks like the package is trying to use code from pypi, (i.e. the binaries included in the package wouldn't be built from the source code in Debian), which is a serious bug. Ubuntu buildd: https://launchpad.net/ubuntu/+source/custodia/0.1.0-2/+build/8184393
Bug#859542: puma: libssl-1.1 supported upstream
tags -1 + fixed-upstream thanks This is fixed upstream by this commit: https://github.com/puma/puma/commit/12a856ee63551809ffeb70cb8bfc405d2210febd Please apply the fix, or package the new version. Chris.
Bug#858931: isakmpd: Patch
Control: tags -1 + patch
The attached patch moves the code over to using the appropriate
accessors for OpenSSL 1.1 in most cases. I have disabled 40-bit
DES, and not ported that code, as the crypto is comically useless
in the modern world.
Chris.
diff --git a/isakmpd-20041012/apps/certpatch/certpatch.c b/isakmpd-20041012/apps/certpatch/certpatch.c
index 0a0125a..a619db6 100644
--- a/isakmpd-20041012/apps/certpatch/certpatch.c
+++ b/isakmpd-20041012/apps/certpatch/certpatch.c
@@ -147,8 +147,6 @@ main (int argc, char **argv)
* EVP_get_digest_byname.
*/
- SSLeay_add_all_algorithms ();
-
/* Use a certificate created by ssleay and add the appr. extension */
printf ("Reading ssleay created certificate %s and modify it\n",
certin);
@@ -171,7 +169,7 @@ main (int argc, char **argv)
}
/* Get the digest for the actual signing */
- digest = EVP_get_digestbyname (OBJ_nid2sn (OBJ_obj2nid (cert->sig_alg->algorithm)));
+ digest = EVP_get_digestbyname (OBJ_nid2sn (X509_get_signature_nid(cert)));
if (!X509_set_version (cert, 2))
{
@@ -293,7 +291,7 @@ main (int argc, char **argv)
BIO_free (file);
printf ("Creating Signature: PKEY_TYPE = %s: ",
- pkey_priv->type == EVP_PKEY_RSA ? "RSA" : "unknown");
+ EVP_PKEY_id(pkey_priv) == EVP_PKEY_RSA ? "RSA" : "unknown");
err = X509_sign (cert, pkey_priv, digest);
printf ("X509_sign: %d ", err);
if (!err)
diff --git a/isakmpd-20041012/crypto.c b/isakmpd-20041012/crypto.c
index d74191e..2995119 100644
--- a/isakmpd-20041012/crypto.c
+++ b/isakmpd-20041012/crypto.c
@@ -105,12 +105,13 @@ struct crypto_xf transforms[] = {
#define DC (void *)
#endif
+#ifdef USE_DES
enum cryptoerr
des1_init(struct keystate *ks, u_int8_t *key, u_int16_t len)
{
- /* des_set_key returns -1 for parity problems, and -2 for weak keys */
- des_set_odd_parity(DC key);
- switch (des_set_key(DC key, ks->ks_des[0])) {
+ /* DES_set_key returns -1 for parity problems, and -2 for weak keys */
+ DES_set_odd_parity(DC key);
+ switch (DES_set_key(DC key, ks->ks_des[0])) {
case -2:
return EWEAKKEY;
default:
@@ -131,19 +132,20 @@ des1_decrypt(struct keystate *ks, u_int8_t *d, u_int16_t len)
des_cbc_encrypt(DC d, DC d, len, ks->ks_des[0], DC ks->riv,
DES_DECRYPT);
}
+#endif
#ifdef USE_TRIPLEDES
enum cryptoerr
des3_init(struct keystate *ks, u_int8_t *key, u_int16_t len)
{
- des_set_odd_parity(DC key);
- des_set_odd_parity(DC(key + 8));
- des_set_odd_parity(DC(key + 16));
+ DES_set_odd_parity(DC key);
+ DES_set_odd_parity(DC(key + 8));
+ DES_set_odd_parity(DC(key + 16));
/* As of the draft Tripe-DES does not check for weak keys */
- des_set_key(DC key, ks->ks_des[0]);
- des_set_key(DC(key + 8), ks->ks_des[1]);
- des_set_key(DC(key + 16), ks->ks_des[2]);
+ DES_set_key(DC key, ks->ks_des[0]);
+ DES_set_key(DC(key + 8), ks->ks_des[1]);
+ DES_set_key(DC(key + 16), ks->ks_des[2]);
return EOKAY;
}
@@ -154,7 +156,7 @@ des3_encrypt(struct keystate *ks, u_int8_t *data, u_int16_t len)
u_int8_tiv[MAXBLK];
memcpy(iv, ks->riv, ks->xf->blocksize);
- des_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
+ DES_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
ks->ks_des[1], ks->ks_des[2], DC iv, DES_ENCRYPT);
}
@@ -164,7 +166,7 @@ des3_decrypt(struct keystate *ks, u_int8_t *data, u_int16_t len)
u_int8_tiv[MAXBLK];
memcpy(iv, ks->riv, ks->xf->blocksize);
- des_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
+ DES_ede3_cbc_encrypt(DC data, DC data, len, ks->ks_des[0],
ks->ks_des[1], ks->ks_des[2], DC iv, DES_DECRYPT);
}
#undef DC
diff --git a/isakmpd-20041012/crypto.h b/isakmpd-20041012/crypto.h
index 1095c7e..902c359 100644
--- a/isakmpd-20041012/crypto.h
+++ b/isakmpd-20041012/crypto.h
@@ -108,7 +108,7 @@ struct keystate {
u_int8_tiv2[MAXBLK];
u_int8_t *riv, *liv;
union {
- des_key_schedule desks[3];
+ DES_key_schedule *desks[3];
#ifdef USE_BLOWFISH
blf_ctx blfks;
#endif
diff --git a/isakmpd-20041012/debian/control b/isakmpd-20041012/debian/control
index cc5ddfd..cf3a994 100644
--- a/isakmpd-20041012/debian/control
+++ b/isakmpd-20041012/debian/control
@@ -3,7 +3,7 @@ Maintainer: Jochen Friedrich
Priority: optional
Section: net
Standards-Version: 3.8.4
-Build-Depends: debhelper (>= 7.0.50~), libssl1.0-dev | libssl-dev (<< 1.1.0~), libgmp-dev, libpcap-dev, linux-kernel-headers
+Build-Depends: debhelper (>= 7.0.50~), libssl-dev, libgmp-dev, libpcap-dev, linux-kernel-headers
Package: isakmpd
Priority: optional
diff --git a/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep b/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep
index 32104ed..4c2edb3 100644
--- a/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep
+++ b/isakmpd-20041012/sysdep/linux/GNUmakefile.sysdep
@@ -39,7 +39,7 @@ CFLAGS+= -DHAVE_GETNAMEINFO -DUSE_OLD_SOCKADDR -DHAVE_PCAP \
-I/usr/include/openssl
FEATURES= debug tripledes blowfish cast ec aggressive x509
-FEATURES+= dpd na
Bug#859227: mixmaster: ssl 1.1 support
Control: tags -1 + patch
The attached patch moves the code over to using the openssl 1.1 api. It
is entirely renames / accessors.
Chris.
diff --git a/mixmaster-3.0.0/Src/crypto.c b/mixmaster-3.0.0/Src/crypto.c
index 1025b6d..e860a67 100644
--- a/mixmaster-3.0.0/Src/crypto.c
+++ b/mixmaster-3.0.0/Src/crypto.c
@@ -82,6 +82,7 @@ static int read_seckey(BUFFER *buf, SECKEY *key, const byte id[])
int len, plen;
byte *ptr;
int err = 0;
+ BIGNUM *key_n, *key_e, *key_d, *key_p, *key_q, *key_dmp1, *key_dmq1, *key_iqmp;
md = buf_new();
bits = buf->data[0] + 256 * buf->data[1];
@@ -94,32 +95,36 @@ static int read_seckey(BUFFER *buf, SECKEY *key, const byte id[])
ptr = buf->data + 2;
- key->n = BN_bin2bn(ptr, len, NULL);
+ key_n = BN_bin2bn(ptr, len, NULL);
buf_append(md, ptr, len);
ptr += len;
- key->e = BN_bin2bn(ptr, len, NULL);
+ key_e = BN_bin2bn(ptr, len, NULL);
buf_append(md, ptr, len);
ptr += len;
- key->d = BN_bin2bn(ptr, len, NULL);
+ key_d = BN_bin2bn(ptr, len, NULL);
ptr += len;
- key->p = BN_bin2bn(ptr, plen, NULL);
+ key_p = BN_bin2bn(ptr, plen, NULL);
ptr += plen;
- key->q = BN_bin2bn(ptr, plen, NULL);
+ key_q = BN_bin2bn(ptr, plen, NULL);
ptr += plen;
- key->dmp1 = BN_bin2bn(ptr, plen, NULL);
+ key_dmp1 = BN_bin2bn(ptr, plen, NULL);
ptr += plen;
- key->dmq1 = BN_bin2bn(ptr, plen, NULL);
+ key_dmq1 = BN_bin2bn(ptr, plen, NULL);
ptr += plen;
- key->iqmp = BN_bin2bn(ptr, plen, NULL);
+ key_iqmp = BN_bin2bn(ptr, plen, NULL);
ptr += plen;
+ RSA_set0_key(key, key_n, key_e, key_d);
+ RSA_set0_factors(key, key_p, key_q);
+ RSA_set0_crt_params(key, key_dmp1, key_dmq1, key_iqmp);
+
digest_md5(md, md);
if (id)
err = (memcmp(id, md->data, 16) == 0) ? 0 : -1;
@@ -134,6 +139,7 @@ static int read_pubkey(BUFFER *buf, PUBKEY *key, const byte id[])
int len;
byte *ptr;
int err = 0;
+ BIGNUM *key_n, *key_e;
md = buf_new();
bits = buf->data[0] + 256 * buf->data[1];
@@ -144,13 +150,14 @@ static int read_pubkey(BUFFER *buf, PUBKEY *key, const byte id[])
ptr = buf->data + 2;
- key->n = BN_bin2bn(ptr, len, NULL);
+ key_n = BN_bin2bn(ptr, len, NULL);
buf_append(md, ptr, len);
ptr += len;
- key->e = BN_bin2bn(ptr, len, NULL);
+ key_e = BN_bin2bn(ptr, len, NULL);
buf_append(md, ptr, len);
ptr += len;
+ RSA_set0_key(key, key_n, key_e, NULL);
digest_md5(md, md);
if (id)
@@ -164,17 +171,22 @@ static int write_seckey(BUFFER *sk, SECKEY *key, byte keyid[])
byte l[128];
int n;
BUFFER *b, *temp;
+ const BIGNUM *key_n, *key_e, *key_d, *key_p, *key_q, *key_dmp1, *key_dmq1, *key_iqmp;
+
+ RSA_get0_key(key, &key_n, &key_e, &key_d);
+ RSA_get0_factors(key, &key_p, &key_q);
+ RSA_get0_crt_params(key, &key_dmp1, &key_dmq1, &key_iqmp);
b = buf_new();
temp = buf_new();
- n = BN_bn2bin(key->n, l);
+ n = BN_bn2bin(key_n, l);
assert(n <= 128);
if (n < 128)
buf_appendzero(b, 128 - n);
buf_append(b, l, n);
- n = BN_bn2bin(key->e, l);
+ n = BN_bn2bin(key_e, l);
assert(n <= 128);
if (n < 128)
buf_appendzero(b, 128 - n);
@@ -187,37 +199,37 @@ static int write_seckey(BUFFER *sk, SECKEY *key, byte keyid[])
buf_appendc(sk, 4);
buf_cat(sk, b);
- n = BN_bn2bin(key->d, l);
+ n = BN_bn2bin(key_d, l);
assert(n <= 128);
if (n < 128)
buf_appendzero(sk, 128 - n);
buf_append(sk, l, n);
- n = BN_bn2bin(key->p, l);
+ n = BN_bn2bin(key_p, l);
assert(n <= 64);
if (n < 64)
buf_appendzero(sk, 64 - n);
buf_append(sk, l, n);
- n = BN_bn2bin(key->q, l);
+ n = BN_bn2bin(key_q, l);
assert(n <= 64);
if (n < 64)
buf_appendzero(sk, 64 - n);
buf_append(sk, l, n);
- n = BN_bn2bin(key->dmp1, l);
+ n = BN_bn2bin(key_dmp1, l);
assert(n <= 64);
if (n < 64)
buf_appendzero(sk, 64 - n);
buf_append(sk, l, n);
- n = BN_bn2bin(key->dmq1, l);
+ n = BN_bn2bin(key_dmq1, l);
assert(n <= 64);
if (n < 64)
buf_appendzero(sk, 64 - n);
buf_append(sk, l, n);
- n = BN_bn2bin(key->iqmp, l);
+ n = BN_bn2bin(key_iqmp, l);
assert(n <= 64);
if (n < 64)
buf_appendzero(sk, 64 - n);
@@ -234,15 +246,17 @@ static int write_pubkey(BUFFER *pk, PUBKEY *key, byte keyid[])
{
byte l[128];
int n;
+ const BIGNUM *key_n, *key_e, *key_d;
buf_appendc(pk, 0);
buf_appendc(pk, 4);
- n = BN_bn2bin(key->n, l);
+ RSA_get0_key(key, &key_n, &key_e, &key_d);
+ n = BN_bn2bin(key_n, l);
assert(n <= 128);
if (n < 128)
buf_appendzero(pk, 128 - n);
buf_append(pk, l, n);
- n = BN_bn2bin(key->e, l);
+ n = BN_bn2bin(key_e, l);
assert(n <= 128);
if (n < 128)
buf_appendzero(pk, 128 - n);
@@ -383,23 +397,23 @@ int pk_encrypt(BUFFER *in, BUFFER *keybuf)
}
int buf_crypt(BUFFER *buf, BUFFER *key, BUFFER *iv, int enc)
{
- des_key_schedule ks1;
- des_key_schedule ks2;
- des_key_schedule ks3;
- des_cblock i;
+ DES_key_schedule *ks1;
+ DES_key_schedule *ks2;
+ DES_key_schedule *k
Bug#859549: patch
Control: tags -1 + patch The attached patch fixes the configure script to not check for a removed symbol. Interestingly, the symbol hasn't really existed for a long, long time, and its removal isn't even in the changelog; I had to read the source. `CRYPTO_lock` was its name. Chris. commit 324c4c7e78be0e802093294ff24e5d0865fce733 Author: Chris West (Faux) Date: Thu Jun 1 16:36:59 2017 + check for a symbol that actually exists diff --git a/partimage-0.6.9/configure.ac b/partimage-0.6.9/configure.ac index bb2ff61..267a140 100644 --- a/partimage-0.6.9/configure.ac +++ b/partimage-0.6.9/configure.ac @@ -240,7 +240,7 @@ if test "$SSL" = "yes"; then AC_CHECKING([ for SSL Library and Header files ... ]) AC_SEARCH_HEADERS(rsa.h crypto.h x509.h pem.h ssl.h err.h, $SSL_HDR_DIR /usr/include/ssl /usr/include/openssl /usr/include, -[ AC_CHECK_LIB(crypto, CRYPTO_lock, [LIBS="$LIBS -lcrypto"], +[ AC_CHECK_LIB(crypto, CRYPTO_free, [LIBS="$LIBS -lcrypto"], AC_MSG_ERROR([ Required for SSL Crypto Library not found. ]) ) AC_CHECK_LIB(ssl, SSL_CTX_new, diff --git a/partimage-0.6.9/debian/control b/partimage-0.6.9/debian/control index 928fc98..441bb9b 100644 --- a/partimage-0.6.9/debian/control +++ b/partimage-0.6.9/debian/control @@ -4,13 +4,14 @@ Priority: optional Maintainer: Debian QA Group Build-Depends: cdbs, debhelper (>= 8), + dh-autoreconf, autotools-dev, libbz2-dev, libnewt-dev, zlib1g-dev, comerr-dev, e2fslibs-dev (>= 1.25), - libssl1.0-dev | libssl-dev (<< 1.1.0~), + libssl-dev, libpam0g-dev, gettext Standards-Version: 3.9.8 diff --git a/partimage-0.6.9/debian/rules b/partimage-0.6.9/debian/rules index bc179ba..39852f6 100755 --- a/partimage-0.6.9/debian/rules +++ b/partimage-0.6.9/debian/rules @@ -2,6 +2,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk +include /usr/share/cdbs/1/rules/autoreconf.mk DEB_CONFIGURE_EXTRA_FLAGS := --with-log-dir=/var/log/partimage \ --with-debug-level=1 \
Bug#851092: patch
Control: tags -1 + patch
Control: forwarded -1 https://github.com/boxbackup/boxbackup/issues/16
The above patch changes a single object into a pointer, and changes
init/cleanup into new/free.
Chris.
commit 9d2bf90676206957a502e9ec1c3cfe4f4b40b0cc
Author: Chris West (Faux)
Date: Thu Jun 1 17:01:16 2017 +
dynamically allocate EVP_CTX
diff --git a/boxbackup-0.11.1~r2837/debian/control b/boxbackup-0.11.1~r2837/debian/control
index 5cbdba6..d422125 100644
--- a/boxbackup-0.11.1~r2837/debian/control
+++ b/boxbackup-0.11.1~r2837/debian/control
@@ -12,7 +12,7 @@ Build-Depends:
docbook-xsl,
libdb-dev (>= 4.7),
libedit-dev,
- libssl1.0-dev,
+ libssl-dev,
libtest-lwp-useragent-perl,
xsltproc,
zlib1g-dev
diff --git a/boxbackup-0.11.1~r2837/lib/crypto/CipherContext.cpp b/boxbackup-0.11.1~r2837/lib/crypto/CipherContext.cpp
index e5cd9b0..f23317f 100644
--- a/boxbackup-0.11.1~r2837/lib/crypto/CipherContext.cpp
+++ b/boxbackup-0.11.1~r2837/lib/crypto/CipherContext.cpp
@@ -49,7 +49,7 @@ CipherContext::~CipherContext()
if(mInitialised)
{
// Clean up
- EVP_CIPHER_CTX_cleanup(&ctx);
+ EVP_CIPHER_CTX_free(ctx);
mInitialised = false;
}
#ifdef HAVE_OLD_SSL
@@ -84,9 +84,9 @@ void CipherContext::Init(CipherContext::CipherFunction Function, const CipherDes
// Initialise the cipher
#ifndef HAVE_OLD_SSL
- EVP_CIPHER_CTX_init(&ctx); // no error return code, even though the docs says it does
+ ctx = EVP_CIPHER_CTX_new();
- if(EVP_CipherInit_ex(&ctx, rDescription.GetCipher(), NULL, NULL, NULL, Function) != 1)
+ if(EVP_CipherInit_ex(ctx, rDescription.GetCipher(), NULL, NULL, NULL, Function) != 1)
#else
// Store function for later
mFunction = Function;
@@ -102,19 +102,19 @@ void CipherContext::Init(CipherContext::CipherFunction Function, const CipherDes
{
#ifndef HAVE_OLD_SSL
// Let the description set up everything else
- rDescription.SetupParameters(&ctx);
+ rDescription.SetupParameters(ctx);
#else
// With the old version, a copy needs to be taken first.
mpDescription = rDescription.Clone();
// Mark it as not a leak, otherwise static cipher contexts
// cause spurious memory leaks to be reported
MEMLEAKFINDER_NOT_A_LEAK(mpDescription);
- mpDescription->SetupParameters(&ctx);
+ mpDescription->SetupParameters(ctx);
#endif
}
catch(...)
{
- EVP_CIPHER_CTX_cleanup(&ctx);
+ EVP_CIPHER_CTX_free(ctx);
throw;
}
@@ -135,7 +135,7 @@ void CipherContext::Reset()
if(mInitialised)
{
// Clean up
- EVP_CIPHER_CTX_cleanup(&ctx);
+ EVP_CIPHER_CTX_cleanup(ctx);
mInitialised = false;
}
#ifdef HAVE_OLD_SSL
@@ -172,7 +172,7 @@ void CipherContext::Begin()
}
// Initialise the cipher context again
- if(EVP_CipherInit(&ctx, NULL, NULL, NULL, -1) != 1)
+ if(EVP_CipherInit(ctx, NULL, NULL, NULL, -1) != 1)
{
THROW_EXCEPTION(CipherException, EVPInitFailure)
}
@@ -218,14 +218,14 @@ int CipherContext::Transform(void *pOutBuffer, int OutLength, const void *pInBuf
}
// Check output buffer size
- if(OutLength < (InLength + EVP_CIPHER_CTX_block_size(&ctx)))
+ if(OutLength < (InLength + EVP_CIPHER_CTX_block_size(ctx)))
{
THROW_EXCEPTION(CipherException, OutputBufferTooSmall);
}
// Do the transform
int outLength = OutLength;
- if(EVP_CipherUpdate(&ctx, (unsigned char*)pOutBuffer, &outLength, (unsigned char*)pInBuffer, InLength) != 1)
+ if(EVP_CipherUpdate(ctx, (unsigned char*)pOutBuffer, &outLength, (unsigned char*)pInBuffer, InLength) != 1)
{
THROW_EXCEPTION(CipherException, EVPUpdateFailure)
}
@@ -265,7 +265,7 @@ int CipherContext::Final(void *pOutBuffer, int OutLength)
}
// Check output buffer size
- if(OutLength < (2 * EVP_CIPHER_CTX_block_size(&ctx)))
+ if(OutLength < (2 * EVP_CIPHER_CTX_block_size(ctx)))
{
THROW_EXCEPTION(CipherException, OutputBufferTooSmall);
}
@@ -273,7 +273,7 @@ int CipherContext::Final(void *pOutBuffer, int OutLength)
// Do the transform
int outLength = OutLength;
#ifndef HAVE_OLD_SSL
- if(EVP_CipherFinal_ex(&ctx, (unsigned char*)pOutBuffer, &outLength) != 1)
+ if(EVP_CipherFinal_ex(ctx, (unsigned char*)pOutBuffer, &outLength) != 1)
{
THROW_EXCEPTION(CipherException, EVPFinalFailure)
}
@@ -302,11 +302,11 @@ void CipherContext::OldOpenSSLFinal(unsigned char *Buffer, int &rOutLengthOut)
// Old version needs to use a different form, and then set up the cipher again for next time around
int outLength = rOutLengthOut;
// Have to emulate padding off...
- int blockSize = EVP_CIPHER_CTX_block_size(&ctx);
+ int blockSize = EVP_CIPHER_CTX_block_size(ctx);
if(mPaddingOn)
{
// Just use normal final call
- if(EVP_CipherFinal(&ctx, Buffer, &outLength) != 1)
+ if(EVP_CipherFinal(ctx, Buffer, &outLength) != 1)
{
THROW_EXCEPTION(CipherException, EVPFinalFailure)
}
@@ -319,13 +319,13 @@ void CipherContext::OldOpenSSLFinal(unsigned char *Buffer, int &rOutLengthOut)
{
// NASTY -- fiddling around with internals like this is bad.
// But only way to get this w
Bug#851092: upstream
Upstream have committed a better version of the patch for their latest version, which also fixes a load of deprecation warnings: https://github.com/boxbackup/boxbackup/commit/edd3687f067c68b131822e0064cdeff5bf7a3835
Bug#828413: fixed upstream
Control: tags -1 + fixed-upstream Upstream have resolved the issues, e.g. in cf1e808e2ffa1f26644fb5d2cb82a919f323deba. Packaging the newer tag (0.7.5) should pick up the fixes.
Bug#866908: doclint still haunts us
Control: reopen -1 Control: found 9~b181-2 The shipped javadoc command in 9~b181-2 still complains, as this bug report mentions; the testcase above still fails. I believe the patch, while updated, is not being applied: https://sources.debian.net/src/openjdk-9/9~b181-2/debian/rules/#L393 Please save us from this evil! Chris.
Bug#872797: RM? Abandoned upstream in 2004, FTBFS with openjdk-9, few rdeps
Source: avalon-framework Priority: wishlist Could we RM this package? It was officially abandoned by upstream in 2004[1]. There was an upload to Maven Central in 2007, but it doesn't seem to have gone through source control: the last commit was in 2004. It FTBFS with openjdk-9, will require the source patching. The reverse depends (in sid, today) are: * libfop-java (>= 1:2.1-7) As fop is really popular, the popcon of libavalon-framework-java is very artificially inflated. It is in the build-deps of nearly everything. fop depends on only the configuration parser (and, in test, logging), which I am trying to get upstream to remove[2], and have a patch for HEAD[3]. * jmeter (2.13-3) * libexcalibur-logger-java (2.1-6) jmeter upstream (3.2) has moved off this logging framework to slf4j, dropping the dependency on avalon-framework. The logging framework has no other rdeps, so could also be removed. * libtrang-java (20131210+dfsg+1-6) libtrang upstream have also removed references to avalon-framework. * libjaxe-java (3.5-8) Part of the "jaxe" XML editor, dead upstream. I'm going to have a look at fixing it. * scilab-full-bin (5.5.2-5) Pretty sure this doesn't actually depend on avalon-framework at all; looks like it's just trying to pull it in to fix fop? I'm not entirely sure, hard to test without rebuilding Debian's fop without avalon. Thanks, Chris. 1: https://avalon.apache.org/closed.html 2: https://issues.apache.org/jira/browse/FOP-2733 3: https://github.com/apache/fop/compare/trunk...FauxFaux:trunk
Bug#872797: jaxe also seems to just be trying to fix fop
jaxe also seems to just trying to fix fop problems; i.e. it has no real dependence on avalon as far as I can see. Again, hard to test without trying a rebuild of a fixed fop. Chris.
Bug#872945: FTBFS with openjdk-9-jdk
Source: dicomscope Priority: normal This package fails to build against openjdk-9, for which there should soon be a transition. The changes look like they should be easy to fix: error: [options] source value 1.5 is obsolete and will be removed in a future release error: [options] target value 1.5 is obsolete and will be removed in a future release These are literally true; -source/-target 1.6 or higher must be passed. And: ./processCommunication/ProcessTable.java:216: error: incompatible types: Object cannot be converted to Vector dataVector.setElementAt(dummy, row2); ^ ./viewer/sr/VerificationDialog.java:294: error: incompatible types: Object cannot be converted to Vector dataVector.setElementAt(dummy, row2); ^ These are normally caused by swing having gained generics for methods that previously accepted raw types, and can be fixed by adding wildcards (in a way that doesn't break compilation on Java 8). Cheers, Chris.
Bug#872946: FTBFS with openjdk-9
Source: charactermanaj Priority: normal This package fails to build with Java 9, for which there will hopefully soon be a transition. Please fix it. Build log excerpt: /build/charactermanaj-0.998+git20150728.a826ad85/src/charactermanaj/ui/util/SpinnerWheelSupportListener.java:53: error: incompatible types: Comparable cannot be converted to Comparable Comparable max = nmodel.getMaximum(); ^ where CAP#1 is a fresh type-variable: CAP#1 extends Object from capture of ? /build/charactermanaj-0.998+git20150728.a826ad85/src/charactermanaj/ui/util/SpinnerWheelSupportListener.java:55: error: incompatible types: Comparable cannot be converted to Comparable Comparable min = nmodel.getMinimum(); ^ where CAP#1 is a fresh type-variable: CAP#1 extends Object from capture of ? These errors are normally because javax.swing classes have gained some generics, where previously they had raw types. Some extra wildcards, or generics, may be required. Cheers, Chris.
Bug#873021: RM? FTBFS with openjdk-9, outdated, no rdeps
Source: ha-jdbc Priority: wishlist This library package has no rdeps, is a release-candidate version from 2009, there are new major versions upstream. The currently packaged version fails to build with the current openjdk-9-jdk betas. Can we remove it? Cheers, Chris.
Bug#873030: RM? Superseded by Java 7, abandoned upstream, FTBFS on 9, 1 rdep
Source: jpathwatch Priority: wishlist Can we RM this package? It fails to build on Java 9. It has been abandoned by upstream in 2012, as Java 7 provides the functionality without all the hacks. It has one rdep: eclipse-pydev, which uses it only at build time, for a single test, I believe. eclipse-pydev-data seems to be ending up with it as an actual depends, but I hope that's a bug. Chris.
Bug#698240: build-rdeps also fails with lz4'd sources
Control: severity -1 important build-rdeps also fails with lz4'd sources, which appears to have become the default in sid at some point? It's the case in the "official" debian:sid Docker images, without any config I can see set. As the tool is broken on a default install, without me having changed any configuration, this bug is Important. Chris.
Bug#873249: FTBFS with Java 9: javadoc classpath with maven?
On Sat, Aug 26, 2017 at 12:25:16PM +0200, Emmanuel Bourg wrote: > With Java 8 a warning was displayed, but with Java 9 it's now > an error. The only workaround I've found besides fixing the classpath is > > Do you know how many packages are affected by this issue? I'd guess ~4 of the ~50 I looked at, so maybe 30 packages total? I can't grep up a better answer as many packages fail their build before getting to the javadoc generation. This one specifically is weird as it's maven, and maven is probably supposed to be using the same classpath for the build as for the javadoc generation. And the main build has succeeded, or we wouldn't be here.
Bug#859784: ssl 1.1 fix
Control: tags -1 + patch
Control: forwarded https://github.com/tobez/validns/pull/64
A patch to fix compilation with openssl 1.1 is attached.
The patch doesn't apply cleanly to upstream, so I sent them a different
patch.
Chris.
diff --git a/validns-0.8+git20160720/debian/control b/validns-0.8+git20160720/debian/control
index 3714846..d31cb26 100644
--- a/validns-0.8+git20160720/debian/control
+++ b/validns-0.8+git20160720/debian/control
@@ -3,7 +3,7 @@ Section: net
Priority: extra
Maintainer: Casper Gielen
Uploaders: Joost van Baal-Ilić
-Build-Depends: debhelper (>= 9), libssl1.0-dev, libjudy-dev, libtest-command-simple-perl, dpkg-dev (>= 1.16.1~)
+Build-Depends: debhelper (>= 9), libssl-dev, libjudy-dev, libtest-command-simple-perl, dpkg-dev (>= 1.16.1~)
Standards-Version: 3.9.8
Homepage: http://www.validns.net/
Vcs-Git: https://anonscm.debian.org/git/collab-maint/validns.git
diff --git a/validns-0.8+git20160720/dnskey.c b/validns-0.8+git20160720/dnskey.c
index fecc62a..14f2cc2 100644
--- a/validns-0.8+git20160720/dnskey.c
+++ b/validns-0.8+git20160720/dnskey.c
@@ -154,6 +154,7 @@ int dnskey_build_pkey(struct rr_dnskey *rr)
unsigned int e_bytes;
unsigned char *pk;
int l;
+ BIGNUM *n, *e;
rsa = RSA_new();
if (!rsa)
@@ -174,11 +175,12 @@ int dnskey_build_pkey(struct rr_dnskey *rr)
if (l < e_bytes) /* public key is too short */
goto done;
- rsa->e = BN_bin2bn(pk, e_bytes, NULL);
+ e = BN_bin2bn(pk, e_bytes, NULL);
pk += e_bytes;
l -= e_bytes;
- rsa->n = BN_bin2bn(pk, l, NULL);
+ n = BN_bin2bn(pk, l, NULL);
+ RSA_set0_key(rsa, n, e, NULL);
pkey = EVP_PKEY_new();
if (!pkey)
diff --git a/validns-0.8+git20160720/nsec3checks.c b/validns-0.8+git20160720/nsec3checks.c
index 69c6553..97be1ce 100644
--- a/validns-0.8+git20160720/nsec3checks.c
+++ b/validns-0.8+git20160720/nsec3checks.c
@@ -28,7 +28,7 @@
static struct binary_data name2hash(char *name, struct rr *param)
{
struct rr_nsec3param *p = (struct rr_nsec3param *)param;
- EVP_MD_CTX ctx;
+ EVP_MD_CTX *ctx;
unsigned char md0[EVP_MAX_MD_SIZE];
unsigned char md1[EVP_MAX_MD_SIZE];
unsigned char *md[2];
@@ -45,22 +45,23 @@ static struct binary_data name2hash(char *name, struct rr *param)
/* XXX Maybe use Init_ex and Final_ex for speed? */
- EVP_MD_CTX_init(&ctx);
- if (EVP_DigestInit(&ctx, EVP_sha1()) != 1)
+ ctx = EVP_MD_CTX_new();
+ if (EVP_DigestInit(ctx, EVP_sha1()) != 1)
return r;
- digest_size = EVP_MD_CTX_size(&ctx);
- EVP_DigestUpdate(&ctx, wire_name.data, wire_name.length);
- EVP_DigestUpdate(&ctx, p->salt.data, p->salt.length);
- EVP_DigestFinal(&ctx, md[mdi], NULL);
+ digest_size = EVP_MD_CTX_size(ctx);
+ EVP_DigestUpdate(ctx, wire_name.data, wire_name.length);
+ EVP_DigestUpdate(ctx, p->salt.data, p->salt.length);
+ EVP_DigestFinal(ctx, md[mdi], NULL);
for (i = 0; i < p->iterations; i++) {
- if (EVP_DigestInit(&ctx, EVP_sha1()) != 1)
+ if (EVP_DigestInit(ctx, EVP_sha1()) != 1)
return r;
- EVP_DigestUpdate(&ctx, md[mdi], digest_size);
+ EVP_DigestUpdate(ctx, md[mdi], digest_size);
mdi = (mdi + 1) % 2;
- EVP_DigestUpdate(&ctx, p->salt.data, p->salt.length);
- EVP_DigestFinal(&ctx, md[mdi], NULL);
+ EVP_DigestUpdate(ctx, p->salt.data, p->salt.length);
+ EVP_DigestFinal(ctx, md[mdi], NULL);
}
+ EVP_MD_CTX_free(ctx);
r.length = digest_size;
r.data = getmem(digest_size);
diff --git a/validns-0.8+git20160720/rrsig.c b/validns-0.8+git20160720/rrsig.c
index 81f24b4..d6ea0c5 100644
--- a/validns-0.8+git20160720/rrsig.c
+++ b/validns-0.8+git20160720/rrsig.c
@@ -26,7 +26,7 @@
struct verification_data
{
struct verification_data *next;
- EVP_MD_CTX ctx;
+ EVP_MD_CTX *ctx;
struct rr_dnskey *key;
struct rr_rrsig *rr;
int ok;
@@ -180,7 +180,7 @@ void *verification_thread(void *dummy)
if (d) {
int r;
d->next = NULL;
- r = EVP_VerifyFinal(&d->ctx, (unsigned char *)d->rr->signature.data, d->rr->signature.length, d->key->pkey);
+ r = EVP_VerifyFinal(d->ctx, (unsigned char *)d->rr->signature.data, d->rr->signature.length, d->key->pkey);
if (r == 1) {
d->ok = 1;
} else {
@@ -232,7 +232,7 @@ static void schedule_verification(struct verification_data *d)
} else {
int r;
G.stats.signatures_verified+
Bug#859717: Skipfish uses deleted openssl functionality
One of the failures here is using SSL_CIPHER->algo_strength, which has been removed with, as far as I can see, no replacement. I've raised a bug against OpenSSL upstream to consider exposing this: https://github.com/openssl/openssl/issues/3795 Chris.
Bug#850890: patch
Control: tags -1 + patch
Attached is a trivial patch which fixes the build on OpenSSL 1.1.
Chris.
diff --git a/opennebula-4.12.3+dfsg/debian/control b/opennebula-4.12.3+dfsg/debian/control
index 5cd7e8e..df9dc68 100644
--- a/opennebula-4.12.3+dfsg/debian/control
+++ b/opennebula-4.12.3+dfsg/debian/control
@@ -11,7 +11,7 @@ Build-Depends: debhelper (>= 9), dh-systemd, dh-linktree, javahelper
,flex
,libmysql++-dev
,libsqlite3-dev
- ,libssl1.0-dev
+ ,libssl-dev
,libws-commons-util-java
,libxml2-dev
,libxmlrpc-c++8-dev
diff --git a/opennebula-4.12.3+dfsg/src/common/NebulaUtil.cc b/opennebula-4.12.3+dfsg/src/common/NebulaUtil.cc
index 90a0a17..f528998 100644
--- a/opennebula-4.12.3+dfsg/src/common/NebulaUtil.cc
+++ b/opennebula-4.12.3+dfsg/src/common/NebulaUtil.cc
@@ -154,18 +154,18 @@ string * one_util::base64_decode(const string& in)
string one_util::sha1_digest(const string& in)
{
-EVP_MD_CTX mdctx;
+EVP_MD_CTX *mdctx;
unsigned char md_value[EVP_MAX_MD_SIZE];
unsigned int md_len;
ostringstream oss;
-EVP_MD_CTX_init(&mdctx);
-EVP_DigestInit_ex(&mdctx, EVP_sha1(), NULL);
+mdctx = EVP_MD_CTX_new();
+EVP_DigestInit_ex(mdctx, EVP_sha1(), NULL);
-EVP_DigestUpdate(&mdctx, in.c_str(), in.length());
+EVP_DigestUpdate(mdctx, in.c_str(), in.length());
-EVP_DigestFinal_ex(&mdctx,md_value,&md_len);
-EVP_MD_CTX_cleanup(&mdctx);
+EVP_DigestFinal_ex(mdctx,md_value,&md_len);
+EVP_MD_CTX_free(mdctx);
for(unsigned int i = 0; i
Bug#851069: Builds fine with modern libssl
This package builds fine, and all the tests pass fine, with modern libssl. The version dependence on older versions has been there since the package was first uploaded; I am unable to work out why it was added: maybe a dependent library which has now been fixed? All that's necessary to close this bug is to change the debian/control dependence to the current version. Chris.
Bug#863568: ..and of course I forgot the attachment
diff --git a/cfengine3-3.9.1/cf-key/cf-key-functions.c b/cfengine3-3.9.1/cf-key/cf-key-functions.c
index 7c53ee5..5287b2c 100644
--- a/cfengine3-3.9.1/cf-key/cf-key-functions.c
+++ b/cfengine3-3.9.1/cf-key/cf-key-functions.c
@@ -48,6 +48,7 @@ RSA *LoadPublicKey(const char *filename)
{
FILE *fp;
RSA *key;
+const BIGNUM *n, *e;
fp = safe_fopen(filename, "r");
if (fp == NULL)
@@ -69,7 +70,9 @@ RSA *LoadPublicKey(const char *filename)
fclose(fp);
-if (BN_num_bits(key->e) < 2 || !BN_is_odd(key->e))
+RSA_get0_key(key, &n, &e, NULL);
+
+if (BN_num_bits(e) < 2 || !BN_is_odd(e))
{
Log(LOG_LEVEL_ERR, "Error while reading public key '%s' - RSA Exponent is too small or not odd. (BN_num_bits: %s)",
filename, GetErrorStr());
diff --git a/cfengine3-3.9.1/cf-serverd/server_classic.c b/cfengine3-3.9.1/cf-serverd/server_classic.c
index 5e610da..f50dc01 100644
--- a/cfengine3-3.9.1/cf-serverd/server_classic.c
+++ b/cfengine3-3.9.1/cf-serverd/server_classic.c
@@ -569,6 +569,7 @@ static void SetConnectionData(ServerConnectionState *conn, char *buf)
static int CheckStoreKey(ServerConnectionState *conn, RSA *key)
{
RSA *savedkey;
+const BIGNUM *key_n, *key_e, *savedkey_n, *savedkey_e;
const char *udigest = KeyPrintableHash(ConnectionInfoKey(conn->conn_info));
assert(udigest != NULL);
@@ -579,7 +580,10 @@ static int CheckStoreKey(ServerConnectionState *conn, RSA *key)
"A public key was already known from %s/%s - no trust required",
conn->hostname, conn->ipaddr);
-if ((BN_cmp(savedkey->e, key->e) == 0) && (BN_cmp(savedkey->n, key->n) == 0))
+RSA_get0_key(key, &key_n, &key_e, NULL);
+RSA_get0_key(savedkey, &savedkey_n, &savedkey_e, NULL);
+
+if ((BN_cmp(savedkey_e, key_e) == 0) && (BN_cmp(savedkey_n, key_n) == 0))
{
Log(LOG_LEVEL_VERBOSE,
"The public key identity was confirmed as %s@%s",
@@ -772,6 +776,7 @@ char iscrypt, enterprise_field;
/* proposition C2 - Receive client's public key modulus */
RSA *newkey = RSA_new();
+BIGNUM *newkey_n, *newkey_e;
{
int len_n = ReceiveTransaction(conn->conn_info, recvbuffer, NULL);
@@ -783,7 +788,7 @@ RSA *newkey = RSA_new();
return false;
}
-if ((newkey->n = BN_mpi2bn(recvbuffer, len_n, NULL)) == NULL)
+if ((newkey_n = BN_mpi2bn(recvbuffer, len_n, NULL)) == NULL)
{
Log(LOG_LEVEL_ERR, "Authentication failure: "
"private decrypt of received public key modulus failed "
@@ -804,16 +809,19 @@ RSA *newkey = RSA_new();
return false;
}
-if ((newkey->e = BN_mpi2bn(recvbuffer, len_e, NULL)) == NULL)
+if ((newkey_e = BN_mpi2bn(recvbuffer, len_e, NULL)) == NULL)
{
Log(LOG_LEVEL_ERR, "Authentication failure: "
"private decrypt of received public key exponent failed "
"(%s)", CryptoLastErrorString());
+BN_free(newkey_n);
RSA_free(newkey);
return false;
}
}
+RSA_set0_key(newkey, newkey_n, newkey_e, NULL);
+
/* Compute and store hash of the client's public key. */
{
Key *key = KeyNew(newkey, CF_DEFAULT_DIGEST);
@@ -891,18 +899,21 @@ RSA *newkey = RSA_new();
/* proposition S4, S5 - If the client doesn't have our public key, send it. */
{
+const BIGNUM *n, *e;
if (iscrypt != 'y')
{
Log(LOG_LEVEL_DEBUG, "Sending server's public key");
char bignum_buf[CF_BUFSIZE] = { 0 };
+RSA_get0_key(PUBKEY, &n, &e, NULL);
+
/* proposition S4 - conditional */
-int len_n = BN_bn2mpi(PUBKEY->n, bignum_buf);
+int len_n = BN_bn2mpi(n, bignum_buf);
SendTransaction(conn->conn_info, bignum_buf, len_n, CF_DONE);
/* proposition S5 - conditional */
-int len_e = BN_bn2mpi(PUBKEY->e, bignum_buf);
+int len_e = BN_bn2mpi(e, bignum_buf);
SendTransaction(conn->conn_info, bignum_buf, len_e, CF_DONE);
}
}
diff --git a/cfengine3-3.9.1/cf-serverd/server_common.c b/cfengine3-3.9.1/cf-serverd/server_common.c
index 64e04a4..e4e01e2 100644
--- a/cfengine3-3.9.1/cf-serverd/server_common.c
+++ b/cfengine3-3.9.1/cf-serverd/server_common.c
@@ -557,7 +557,7 @@ void CfEncryptGetFile(ServerFileGetState *args)
unsigned char iv[32] =
{ 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3, 4, 5, 6, 7, 8 };
int blocksize = CF_BUFSIZE - 4 * CF_INBAND_OFFSET;
-EVP_CIPHER_CTX ctx;
+EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
char *key, enctype;
struct stat sb;
ConnectionInfo *conn_info = args->conn->conn_info;
@@ -581,7 +581,7 @@ void CfEncryptGetFile(ServerFileGetState *args)
FailedTransfer(conn_info);
}
-EVP_CIPHER_CTX_init(&ctx);
+EVP_CIPHER_CTX_init(ctx);
if ((fd = safe_open(filename, O_RDONLY)) == -1)
{
@@ -630,20 +630,20 @@ void CfEncryptGetFile(ServerFileGetState *args)
Bug#859053: trivial compilation fix
Control: tags -1 + patch The attached trivial patch fixes compilation in my sid chroot. Chris. diff --git a/libofetion-2.2.2/debian/control b/libofetion-2.2.2/debian/control index 64a8b55..279cd46 100644 --- a/libofetion-2.2.2/debian/control +++ b/libofetion-2.2.2/debian/control @@ -4,7 +4,7 @@ Priority: optional Maintainer: Debian Chinese Team DM-Upload-Allowed: yes Uploaders: Aron Xu , Asias He -Build-Depends: debhelper (>= 7), cmake, libxml2-dev, libssl1.0-dev | libssl-dev (<< 1.1.0~), libsqlite3-dev, pkg-config +Build-Depends: debhelper (>= 7), cmake, libxml2-dev, libssl-dev, libsqlite3-dev, pkg-config Standards-Version: 3.9.2 Homepage: http://code.google.com/p/ofetion/ diff --git a/libofetion-2.2.2/fetion_login.c b/libofetion-2.2.2/fetion_login.c index 6cdcc1c..457cdc7 100644 --- a/libofetion-2.2.2/fetion_login.c +++ b/libofetion-2.2.2/fetion_login.c @@ -85,7 +85,7 @@ char* generate_response(const char *nouce, const char *userid, bne = BN_new(); BN_hex2bn(&bnn, modulus); BN_hex2bn(&bne, exponent); - r->n = bnn; r->e = bne; r->d = NULL; + RSA_set0_key(r, bnn, bne, NULL); // RSA_print_fp(stdout, r, 5); flen = RSA_size(r); out = (unsigned char*)malloc(flen);
Bug#858939: fixed upstream
Control: tags -1 + fixed-upstream Upstream have added support for building against either SSL api: https://github.com/jorisvink/kore/commit/95daf3a62bef0b9c84101eecbb464fd474566f45 Chris.
Bug#859551: fixed upstream
Control: tags -1 + fixed-upstream pgbouncer contains an embedded copy of libusual, where the problems appear to lie. Upstream have picked up an updated embedded copy of libusual[1], and now builds fine. The libusual fixes are pretty spread out, e.g. https://github.com/libusual/libusual/commit/1c7798405869bb56e9c055dcf1f115b409f82ed1 https://github.com/libusual/libusual/commit/0e56f729d74e4af6c19fe60f6e2b47f5e717dcac Doesn't seem worth trying to backport them? Chris. 1: https://github.com/pgbouncer/pgbouncer/commit/2a064d04b346f3496f82682ffe997c3bca7d5f67
Bug#859960: gcj-jdk: dh_javadoc: please add -notimestamp to invocation
The bug is not really in gcj, it's in a script in gcc-defaults, which ends up in the binary named gcj-jdk for some bizarre reason. However, I've just been looking further, and it looks like the script is literally only used by jaminid, and that jaminid looks pretty abandoned upstream, and has no deps or rdeps, and the maintainer is idle. So maybe both can be removed, and the archive can be a better place. https://codesearch.debian.net/search?q=dh_javadoc+path%3Adebian%2Frules
Bug#860098: writer2latex: please make the javadoc build reproducible
Source: writer2latex Version: 1.4-1 User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Priority: wishlist The javadoc in writer2latex contains timestamps, which prevent the package from building reproducibly. Please pass the -notimestamp argument to javadoc. This can be done by adding: ..to the "javadocs" https://sources.debian.net/src/writer2latex/1.4-1/build.xml/#L298 https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/writer2latex.html Cheers.
Bug#842635: Incorrect output on i386 due to UB
Package: docbook-to-man User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain Version: 1:2.0.0-35 X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org On i386 (but not armhf or amd64), docbook-to-man inserts random characters into the output. e.g. it will sometimes generate an "I" instead of a literal tab. I chased the bug around the code, and it looks like /usr/bin/instant has some UB in main.c: https://sources.debian.net/src/docbook-to-man/1:2.0.0-35/Instant/main.c/#L799 memcpy(&buf[1], &buf[2], strlen(buf)-1); .. for bufs like " n\\011". The resulting buf contains \111, which maps to capital I, eventually. Cool coincidence, eh. Patch (for this case!) is simply s/memcpy/memmove/, but I doubt this is the only case where this can happen.
