ersion.
Emmanuel Bourg
Hi Chris,
Thank you for spotting this issue. The Servlet API shouldn't be listed
in the Class-Path attribute since this dependency is provided by the
Servlet container.
Why do you think this is a serious issue? How does this affect your
application?
Emmanuel Bourg
ies with jackson-* >= 2.8
Let's just remove the package.
Emmanuel Bourg
Le 18/12/2016 à 02:18, tony mancill a écrit :
> If someone else on the Java Team could give it a once over, I'd appreciate it.
Hi Tony,
Thank you for the fix, it looks good to me. There won't be links for the
Java EE APIs though, but that's not important.
Emmanuel Bourg
for
/etc/tomcat8/Catalina. I didn't to keep the stable update minimal.
Emmanuel Bourg
these owned by group tomcat8, could
> they be left as root:root and world-accessible?
Good question, I tend to agree. That's probably the next step, this is
being discussed in #833257.
Emmanuel Bourg
link and not a file.
I know these packages are broken/outdated, but they are the only
examples of how web applications are supposed to be packaged in Debian.
Emmanuel Bourg
p-writable.
This is worth trying. The catch is that other packages also install
files into /etc/tomcat8/Catalina/localhost, so they all have to set the
permissions properly. I'll probably go down this path if someone has a
good argument supporting the use of copyXML=true.
Emmanuel Bourg
xes the issue you reported.
https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=02570d6
The script still chmods the Catalina directory but this one can't be
replaced by a symlink.
Emmanuel Bourg
root:root? That would be less disruptive for the stable and oldstable
updates than removing /etc/tomcat8 completely.
Emmanuel Bourg
oves the webapp configuration the administrator is
going to be angry (but arguably less than having his system hacked).
Emmanuel Bourg
tomcat{7,8,9} package that would be easier.
This would be similar to the jetty8 and jetty9 packages sharing the same
'jetty' user (but in this case the user is also removed when the package
is uninstalled, this is problematic when the old package is removed
after the new one is installed).
Emmanuel Bourg
rmissions for
all users and setgid root after the purge. Any local user can then take
control of the system.
Emmanuel Bourg
something like "chmod -R 640 /etc/tomcat8" right
before the chown is an appropriate solution to this issue?
Emmanuel Bourg
[1] https://anonscm.debian.org/cgit/pkg-java/tomcat6.git/commit/?id=f67781f
Hi Hilko,
Do you think elasticsearch should be removed from unstable?
Emmanuel Bourg
prime time
yet and will probably not be part of the Stretch release.
Emmanuel Bourg
[1] https://www.elastic.co/downloads/elasticsearch
ome back to
> Debian in a clean fashion.
Jitsi isn't a problem, don't worry. If you need any help with the Java
dependencies used by Jitsi feel free to ping the Java Team and we'll be
happy to give a hand.
Emmanuel Bourg
This issue was actually caused by libspring-java/4.3.4-1, see #844428
for more info.
Emmanuel Bourg
are causing
the FTBFS (this was also seen in other rdeps of libspring-java, and
there are probably more to come).
Emmanuel Bourg
Le 13/11/2016 à 20:49, Vincent Danjean a écrit :
> Emmanuel: do you think that gradle 3.1 can be uploaded?
I'll try to upload it today.
Emmanuel Bourg
Thank you for the report Vincent. libnative-platform-java/0.11 should
probably declare that it breaks gradle (<< 3.1~).
Emmanuel Bourg
radle-debian-helper?
Emmanuel Bourg
resolving the python dependency.
Emmanuel Bourg
antlr"
> and call it good).
Hi Tony,
I think I fixed the issue with the migration script, the authors file
was missing an entry for the root user. Could you give it another try?
Emmanuel Bourg
Control: tags -1 + help
I took a look at this issue, most of the errors can be fixed by adding
the -std=gnu++98 flag when building the fxpackager module (by patching
the LINUX.launcherlibrary.ccFlags line in the buildSrc/linux.gradle file).
There is one error left though:
the one from the machine building the package, or
another machine on your network?
Is it possible that the tests hit a TCP connection limit on the host?
Emmanuel Bourg
00 00 00 00 00 00 00 00 |?...|
9f50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
*
a000
Maybe these files are just stubs used by the compiler to create
real resources files?
Emmanuel Bourg
Le 20/10/2016 à 00:06, Santiago Vila a écrit :
> You are absolutely right. Sorry for the duplicates.
No need to be sorry. Your reports and the reproducible build
notifications help us greatly to detect and fix the build issues
quickly, thanks a lot for your time.
Emmanuel Bourg
Control: notfound -1 2.9.0-1
Control: close -1
This issue was a side effect of #757536. It went away with the upload of
eclipse/3.8.1-9
plugin
openjpa
wagon
Emmanuel Bourg
Thank you very much for the patch Adrian, I confirm it works. I'll
upload a new version soon.
What is the recommended way to depend on GCC? Should the package depend
on g++ (>= 4:6), or should it depend on gcc-6 with a build adjusted to
use it?
Emmanuel Bourg
I haven't figured out the root cause of this issue but I've modified the
groovy package such that its build fails when AntBuilder is missing from
groovy-all.jar. That will allow me to upload a working package, but I
expect the build to be unstable with a 50% success rate.
Emmanuel Bourg
ded the version 2.4.7-2.
The bugs such as 839847 can be reassigned to groovy and merged into this
one.
Emmanuel Bourg
What is the expected contract for a package providing ruby-interpreter?
Do it just have to offer a /usr/bin/ruby alternative?
Emmanuel Bourg
not access central (https://repo.maven.apache.org/maven2) in
offline mode and the artifact cglib:cglib-nodep:jar:3.x has not been
downloaded from it before. -> [Help 1]
This means that a dependency can't be resolved (here cglib:cglib-nodep:jar:3.x
which is currently subject to a transitio
The error "jvmtifiles/jvmti.h: No such file or directory" isn't the
cause of the build failure. This error has been fixed upstream (see
https://bugs.openjdk.java.net/browse/JDK-8152067) and it can be avoided
by setting the USE_PRECOMPILED_HEADER=0 environment variable.
The fatal errors are the
e issue.
I modified the cup package to enable the legacydot option during the
build and it solved the libxalan2-java FTBFS. I plan to upload the
fixed cup package soon.
Emmanuel Bourg
[1] http://jflex.de/changelog.html
[2] https://sources.debian.net/src/cup/0.11a%2B20060608-7/flex/Lexer.jflex/#L103
s a bit reluctant to upgrade again bnd and maven-bundle-plugin for
stretch but we have a good reason to do it now.
Emmanuel Bourg
lib used to hide the mistake.
I'm going to fix ant-contrib, sorry for the trouble.
Emmanuel Bourg
This is caused by the BCEL 6.0 update, I'll look into it.
This looks like an xbean bug. maven-xbean-plugin has an optional
dependency on Ant so the libxbean-java package doesn't have to depend on
ant, but the XBeanMojo class does use BuildException from Ant to report
errors [1]. It should use a MojoExecutionException from Maven instead,
or the Ant
), , (, >, =, cronometer, libjcommon-java, libjfreechart-java,
>> libswingx-java, ,
Hi Lucas,
You caught this one quickly but this is already fixed in javahelper/0.58
:), no need to report more occurrences.
Emmanuel Bourg
resteasy has been updated and I triaged the remaining tomcat6 bugs.
I think we can proceed with the removal now.
rds-Version field could be deprecated (and considering the time we
spend bumping the value of this field twice a year for ~500 packages
actively maintained by the Java team, such a simplification would be
welcome).
Emmanuel Bourg
-java
currently declares a compliance to the version 3.9.6 of the policy. Does
it mean the new rule doesn't apply to it yet? :)
Emmanuel Bourg
y issue induced though,
because this means the package generated will be different when built
with or without network access.
libcommons-codec-java is still built with Ant. Switching to
maven-debian-helper should fix this issue.
Emmanuel Bourg
[1]
https://sources.debian.net/src/libcommons-codec
e web server implementation known as TJWS based on the
Servlet API 2.5. It's used for exposing REST services. Fortunately it is
being deprecated upstream and we don't really need it in Debian. I
prepared an update removing it but it requires jaxrs-api which is
currently in the NEW queue.
Emmanuel Bourg
Control: reassign -1 mockito 1.10.19-1
Control: affects -1 xmlgraphics-commons
On 07/15/2016 06:24 PM, Chris Lamb wrote:
> [junit] Caused by: java.lang.ClassNotFoundException:
> net.sf.cglib.proxy.Callback
> [junit] at
>
Le 14/07/2016 à 12:24, Hector Oron a écrit :
> In a recent build in a porterbox this packages still fails to build from
> sources.
Yes a new version of eclipse is required to solve this issue. Luca
Vercelli is working on it.
Le 3/07/2016 à 00:38, Daniel Schepler a écrit :
> [ERROR] Failed to execute goal on project oscache: Could not resolve
> dependencies for project opensymphony:oscache:jar:2.4.1: Cannot access
> central (https://repo.maven.apache.org/maven2) in offline mode and the
> artifact antlr:antlr:jar:2.x
lexus:plexus-component-metadata:jar:1.5.5 has
> not been downloaded from it before. -> [Help 1]
Hi Daniel,
I'm unable to reproduce this error with pbuilder. Are you using locally
rebuilt packages?
Emmanuel bourg
Thank you for the report Chris. Other packages like sisu-guice are
affected by the same issue. It seems to be caused by the optional
dependency on ant in cglib, but I don't understand why Maven fails to
resolve the dependency. It fails even when ant is installed.
Emmanuel Bourg
Le 31/05/2016 à 15:04, Chris Lamb a écrit :
> libspring-java fails to build from source in unstable/amd64:
This is a transient error caused by the upgrade of Spring from 4.0.x to
4.1.x. If you rebuild libspring-java/4.1.9-1 the error should go away.
Emmanuel Bourg
Thank you for the notice Moritz. Tika isn't really used in Debian yet, I
packaged it as a dependency of Apache JMeter but didn't enable it. I'll
fix it in unstable, but I don't think it's worth fixing in Jessie.
Emmanuel Bourg
Le 17/05/2016 à 21:52, Markus Koschany a écrit :
> Hmm, they don't ship a parent pom in 2.3 anymore. I will see if I can
> simply reuse the old one.
The project still has a parent pom though:
https://github.com/easymock/objenesis/blob/2.3/pom.xml
I suggest using the GitHub tag archive as
Control: retitle -1 objenesis: Missing parent pom
Control: reassign -1 objenesis 2.3-1
Control: affects -1 stapler wagon2
Thank you for the report Chris. This error is caused by objenesis/2.3-1,
the parent pom is missing in the update. It affects all reverse
dependencies using Maven.
Control: reassign -1 ant
Control: affects -1 jhighlight
This is a bug caused by the patch to make the javadocs reproducible in
ant/1.9.7-1. jhighlight sets the javadoc encoding with an extra argument
() instead of the 'encoding' attribute of the
javadoc task, and the patch doesn't handle this
Control: reassign -1 groovy2
Control: retitle -1 groovy2 should not release with stretch
Reassigning to groovy2 since groovy has been updated to the latest 2.x
release and groovy2 will eventually be removed once the reverse
dependencies are transitioned back to the original package.
used in
Debian. So the Piccolo parser is indeed used.
Piccolo is a rather old parser, I don't think it's worth packaging it. I
suggest patching xmlbeans to use the standard JDK parser instead.
Emmanuel Bourg
Thank you for the report Sebastian. This looks like a bug in javac, this
issue should probably be reassigned to the openjdk-8 package.
ity.
What is the other issue you encountered?
Emmanuel Bourg
Thank you for the report Michael. This should be fixed with
libspring-java/4.0.9-3 uploaded yesterday. Could you check with the
latest version?
Emmanuel Bourg
Le 3/04/2016 19:59, Mattia Rizzolo a écrit :
> Rebuilding it also makes it gains a openjdk-8-jdk dep, go figure...
This is a bug in javahelper, we have to address it.
Emmanuel Bourg
leases
before backporting them.
Emmanuel Bourg
Le 25/03/2016 18:07, Moritz Muehlenhoff a écrit :
> stretch should only provide one version of Tomcat.
I agree, however like tomcat6 we'll keep the src:tomcat7 package to
build the Servlet API only (libservlet3.0-java). I plan to do this a
couple of months before the freeze.
Emmanuel Bourg
Le 09/03/2016 18:06, Markus Koschany a écrit :
> but they apparently stopped tagging new releases some time ago.
I think they migrated the source repository from Subversion to Git, the
GitHub mirror has the latest release tags:
https://github.com/apache/activemq/releases
signature.asc
t have to redefine it to use plexus-utils 2.x
instead of 1.1 to fix this class of issues. I'll do that in the next
update of maven-debian-helper.
Emmanuel Bourg
[1]
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/internal/PlexusUtilsInjector.java
Control: severity -1 important
I'm downgrading the severity to important for the following reasons:
- this issue has been there for years in the previous tomcat packages
- the actual policy violation seems to be debatable
- the RC bug prevents the latest version containing security fixes from
urrent JDK.
Emmanuel Bourg
they accidentally relied on the dependencies pulled
by velocity through maven-debian-helper.
Emmanuel Bourg
be built for these
> architectures.
Hi Matthias,
I fixed this two days ago in java-common/0.56. The architectures
supporting the plugin are now whitelisted in java_defaults.mk. I hope I
got this right this time.
Emmanuel Bourg
the policy.
What behavior would you expect in this situation? Ignoring the update?
Merging the changes? (ucf has a --three-way option to allow merging the
changes, I don't know if it would help here).
Emmanuel Bourg
Le 11/02/2016 21:01, Andreas Tille a écrit :
> any hint why this test that worked before might fail since end of
> December?
I got a quick look and I can't explain this test failure. It doesn't
seem very important though, you could just disable this test.
Emmanuel Bourg
Control: retitle -1 RM: jenkins -- ROM; multiple security issues, FTBFS,
unmaintained in Debian
Control: reassign -1 ftp.debian.org
Le 19/01/2016 17:11, Ansgar Burchardt a écrit :
> I suggest to remove the package from Debian. If there are no
> objections, I'll reassign the request to the
. Any help from an Eclipse expert would be welcome.
Emmanuel Bourg
Thank you foe the report Michael. This issue has already been reported
as #812472.
Emmanuel Bourg
ns-task-reactor
jenkins-test-annotations
jenkins-trilead-ssh2
jenkins-winstone
jenkins-xstream
maven-hpi-plugin
maven-stapler-plugin
sezpoz
stapler
stapler-adjunct-codemirror
stapler-adjunct-timeline
Emmanuel Bourg
Control: reassign libcommons-net-java 3.4-1
This issue is caused by the latest update of libcommons-net-java. The
OSGi metadata were mistakenly dropped in the version 3.4-1.
Emmanuel Bourg
Control: reassign -1 svnclientadapter 1.10.3-3
This issue was caused by the bnd 2.1.0 transition on svnclientadapter.
The jar in the version 1.10.3-3 no longer contains the Export-Package
attribute.
This issue is similar to #808487. It's caused by incomplete OSGi
metadata in the axis, wsdl4j and javamail packages.
Control: reassign -1 fop 1:2.0+dfsg-3
Control: severity -1 important
doxia-sitetools is affected by the same issue.
This was caused by the fop/1:2.0+dfsg-3 upload, its Maven pom has a
dependency on avalon-framework:avalon-framework-api but Avalon in Debian
is installed as
Control: forwarded -1 https://github.com/bndtools/bnd/issues/724
Control: reassign -1 bnd 2.4.1-1
I confirm this is a bnd issue. This was fixed in bnd 3.0.
The fix is trivial I'll backport it.
Le 1/01/2016 19:15, Chris Lamb a écrit :
> javamail fails to build from source in unstable/amd64. This machine
> has lots of RAM, so likely something else wrong?
Thank you for the report Chris, this looks like another issue with bnd 2.4.
Le 21/12/2015 21:59, Markus Koschany a écrit :
> At the moment I don't see a way to fix this in jboss-xnio
> or undertow though.
We can workaround this issue by reverting to the compiler plugin 2.5.
Build depending on libmaven-compiler-plugin-2.5-java and adding the
following to the pom works
Le 11/12/2015 21:16, Miguel Landaeta a écrit :
> To package libspring-java new upstream releases is a task that would
> be very appreciated although is not easy but with the recent progress
> in Maven and Gradle helpers (thanks to Emmanuel again!) maybe this is
> something more feasible nowadays.
by Spring 4.0.x except:
- com.jayway.jsonpath:json-path:0.9.1
- org.apache.taglibs:taglibs-standard-jstlel:1.2.1
I haven't checked the new dependencies for Spring 4.1 yet.
Emmanuel Bourg
released. There are no reverse dependencies on this package, we should
remove it.
Emmanuel Bourg
Package: maven
Version: 3.3.3-4
Severity: grave
Maven 3.3.9 breaks gradle due to a new dependency on commons-lang3.
It should transition to testing after gradle/2.7-4
control: close -1
libgroboutils-java is now in testing.
Hi Martin,
If you look closely at the log it "downloads" from
/usr/share/maven-repo. It isn't fetching jars from a remote repository
but copy them from the local repository.
I confirm that scala depends on itself. Did you remove it from the build
dependencies?
Emmanuel Bourg
Le 09/11/2015 09:26, Moritz Muehlenhoff a écrit :
> Indeed, I intended to file a separate bug for those (but I was unsure
> whether
> jenkins used the system-wide lib as opposed to the released versions from
> jenkins upstream)
libjenkins-java depends on libcommons-collections3-java, but
affected.
Emmanuel Bourg
Le 04/11/2015 16:24, Andreas Tille a écrit :
> Any volunteer to upgrade libsequence-library-java to (possibly) fix #802356?
done :)
I applied the patch, thank you for the help Hans.
Emmanuel Bourg
an intermediary abstract class.
As for testing I face the issue, some help from upstream developers
would be welcome.
Emmanuel Bourg
d, the affected architectures have a combined popcon of
0.3%. I don't think it's fair to push the severity to serious and risk a
removal that would affect all the other architectures.
Emmanuel Bourg
itectures explicitly so the builders can attempt the build and
identify the portability issue. For example with openjfx, I initially
restricted the build to i386/amd64 but I was later asked to remove the
limitation (#765397).
Emmanuel Bourg
one version around.
libnetty-java is going to be updated to the version 4.x. We have to keep
two versions of this library because the APIs aren't compatible. The 3.x
line is still maintained upstream, so that should be fine for now.
Emmanuel Bourg
rading openjfx to the version 8u60 but
I got another build failure :( Leave me some time to investigate this
further.
Emmanuel Bourg
control: tags -1 pending
I'm preparing an update to the version 2.0.9 that will solve this issue.
501 - 600 of 774 matches
Mail list logo
