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
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 change
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. eclip
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.
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: incompa
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
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.
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 so
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 s
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/1c7
Control: tags -1 + fixed-upstream
Upstream have added support for building against either SSL api:
https://github.com/jorisvink/kore/commit/95daf3a62bef0b9c84101eecbb464fd474566f45
Chris.
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 @@
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 *f
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
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/debia
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.
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+gi
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.
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
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:0
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 324c4c
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
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/certp
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.
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
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 d
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 a
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 de
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 s
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 the
Maybe this is a duplicate of:
https://bugs.debian.org/800371
..depending on the solution they arrive at.
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.
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
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 p
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
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 Tes
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),
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 lik
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.
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
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
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, neith
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-
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
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
45 matches
Mail list logo
