Re: plans for eclipse luna in debian
Well, probably it does not compile because the eclipse version is too
old. Now I am trying to mix Tycho and Eclipse sources.
Il 16/02/2016 22:00, Christopher Hoskin ha scritto:
> Out of curiosity, I thought I'd give this a try and see how far I got.
>
> I downloaded
>
> https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/snapshot/tycho-0.24.0.tar.gz
>
> and copied the files
>
> http://pkgs.fedoraproject.org/cgit/rpms/tycho.git/tree/tycho-bootstrap.sh
> http://pkgs.fedoraproject.org/cgit/rpms/tycho.git/tree/tycho-scripts.sh
>
> into the tycho-0.24.0 folder
>
> I installed the eclipse packaged in Sid:
>
> sudo apt-get install eclipse-rcp eclipse-platform
>
> I then ran
>
> ./tycho-bootstrap.sh 0
>
> With a couple of slight tweaks to the code, it gets a fair way through
> building and installing the bootstrap version of tycho into .m2/.
> Currently it falls over building bundle 5 of 6
> (tycho-bundles/org.eclipse.tycho.p2.resolver.impl) with the errors
> below. I haven't applied any of the Fedora patches - possibly they may
> fix some of these errors.
>
> Not sure if this approach is useful? Happy to keep plodding away at it
> if so.
>
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/publisher/AbstractSiteDependenciesAction.java:17:
> error: cannot find symbol
> import org.eclipse.equinox.internal.p2.updatesite.SiteBundle;
> ^
> symbol: class SiteBundle
> location: package org.eclipse.equinox.internal.p2.updatesite
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/resolver/P2ResolverImpl.java:381:
> error: cannot find symbol
> return
> Boolean.parseBoolean(iu.getProperty(InstallableUnitDescription.PROP_TYPE_PRODUCT));
>
> ^
> symbol: variable PROP_TYPE_PRODUCT
> location: class InstallableUnitDescription
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/publisher/ProductDependenciesAction.java:96:
> error: cannot find symbol
> iud.setProperty(InstallableUnitDescription.PROP_TYPE_PRODUCT,
> Boolean.toString(true));
> ^
> symbol: variable PROP_TYPE_PRODUCT
> location: class InstallableUnitDescription
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/publisher/AbstractSiteDependenciesAction.java:56:
> error: cannot find symbol
> for (SiteBundle bundle : getSiteModel().getBundles()) {
>^
> symbol: method getBundles()
> location: class SiteModel
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/publisher/AbstractSiteDependenciesAction.java:56:
> error: cannot find symbol
> for (SiteBundle bundle : getSiteModel().getBundles()) {
> ^
> symbol: class SiteBundle
> location: class AbstractSiteDependenciesAction
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/publisher/AbstractSiteDependenciesAction.java:84:
> warning: non-varargs call of varargs method with inexact argument type
> for last parameter;
> .
> matchExpression(ExpressionUtil.parse(expression), params);
>
>
> ^
> cast to Object for a varargs call
> cast to Object[] for a non-varargs call and to suppress this warning
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/publisher/model/ProductFile2.java:62:
> error: cannot find symbol
> return getFeatures(INCLUDED_FEATURES | ROOT_FEATURES);
>^
> symbol: variable INCLUDED_FEATURES
> location: class ProductFile2
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/publisher/model/ProductFile2.java:62:
> error: cannot find symbol
> return getFeatures(INCLUDED_FEATURES | ROOT_FEATURES);
>^
> symbol: variable ROOT_FEATURES
> location: class ProductFile2
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/target/ArtifactTypeHelper.java:57:
> error: cannot find symbol
> QueryUtil.createIUProductQuery());
> ^
> symbol: method createIUProductQuery()
> location: class QueryUtil
> tycho-bundles/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/target/ee/CustomEEResolutionHandler.java:62:
> error: cannot find symbol
> if (JREAction.NAMESPACE_OSGI_EE.equals(namespace)) {
> ^
> symbol: variable NAMESPACE_OSGI_EE
> location: class JREAction
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for detail
Re: Bug#814875: [Debian-med-packaging] Bug#814875: libsis-jhdf5-java: FTBFS: jni.h:45:20: fatal error: jni_md.h: No such file or directory
On Wed, Feb 17, 2016 at 09:14:53PM +, Michael Crusoe wrote: > I've attached a patch > You'll need to make use of the `jvm_includes` variable that /usr/share/java/ > java_defaults.mk defines. Thanks a lot - this was the hint I was looking for. :-) Anyway: I do not regard it a sensible change if the change of default-jvm requires extra editing of debian/rules for probably more than this single package. Kind regards Andreas. -- http://fam-tille.de
Tomcat 6 security vulnerabilities in Wheezy
Hi, According to [1] Tomcat 6 in Wheezy is still affected by a couple of security vulnerabilities that were already fixed in Squeeze-LTS and Jessie. Would it be sensible to apply the same changes (backporting the 6.0.41 release to Wheezy too) or are there any reasons why this has not been done before? Has anybody spoken with the Security Team about Tomcat security updates in general? Do they approve of backporting newer upstream releases? Regards, Markus [1] https://security-tracker.debian.org/tracker/source-package/tomcat6 signature.asc Description: OpenPGP digital signature
Re: Tomcat 6 security vulnerabilities in Wheezy
On 02/18/2016 05:45 AM, Markus Koschany wrote: > Hi, > > According to [1] Tomcat 6 in Wheezy is still affected by a couple of > security vulnerabilities that were already fixed in Squeeze-LTS and > Jessie. Would it be sensible to apply the same changes (backporting the > 6.0.41 release to Wheezy too) or are there any reasons why this has not > been done before? Has anybody spoken with the Security Team about Tomcat > security updates in general? Do they approve of backporting newer > upstream releases? > > Regards, > > Markus > > [1] https://security-tracker.debian.org/tracker/source-package/tomcat6 Hi Markus, In the past, the Security Team has been receptive to introducing newer Tomcat releases to address security issues. As always, just let the Security Team know what you are intending to do before any uploads. In this instance, I think introducing 6.0.41 is the right approach. I don't believe there are any reasons why this hasn't been done yet. I have added the Security Team to the cc: in case they have a strong opinion on this specific question. Cheers, tony signature.asc Description: OpenPGP digital signature
Re: Tomcat 6 security vulnerabilities in Wheezy
Le 18/02/2016 14:45, Markus Koschany a écrit : > According to [1] Tomcat 6 in Wheezy is still affected by a couple of > security vulnerabilities that were already fixed in Squeeze-LTS and > Jessie. Would it be sensible to apply the same changes (backporting the > 6.0.41 release to Wheezy too) or are there any reasons why this has not > been done before? Has anybody spoken with the Security Team about Tomcat > security updates in general? Do they approve of backporting newer > upstream releases? Hi Markus, I vaguely remember trying to backport the fixes and giving up due to the complexity. Also the lack of tests in Tomcat 6 makes this operation rather risky. That's why the LTS Team decided to package a more recent release in Squeeze. I don't know if the Security Team would accept a new upstream release for Wheezy. Since the LTS Team is probably going to upgrade the package when they take over the maintenance in April we could ask the Security Team to do this upgrade earlier. Emmanuel Bourg
Re: Tomcat 6 security vulnerabilities in Wheezy
Am 18.02.2016 um 18:10 schrieb Emmanuel Bourg: > Le 18/02/2016 14:45, Markus Koschany a écrit : > >> According to [1] Tomcat 6 in Wheezy is still affected by a couple of >> security vulnerabilities that were already fixed in Squeeze-LTS and >> Jessie. Would it be sensible to apply the same changes (backporting the >> 6.0.41 release to Wheezy too) or are there any reasons why this has not >> been done before? Has anybody spoken with the Security Team about Tomcat >> security updates in general? Do they approve of backporting newer >> upstream releases? > > Hi Markus, > > I vaguely remember trying to backport the fixes and giving up due to the > complexity. Also the lack of tests in Tomcat 6 makes this operation > rather risky. That's why the LTS Team decided to package a more recent > release in Squeeze. > > I don't know if the Security Team would accept a new upstream release > for Wheezy. Since the LTS Team is probably going to upgrade the package > when they take over the maintenance in April we could ask the Security > Team to do this upgrade earlier. I am in favor of this solution, especially because we haven't heard anything negative about this approach for Squeeze-LTS. If the Security Team agrees I am going ahead and backport this release to Wheezy, test the package and send the debdiff to them. Markus signature.asc Description: OpenPGP digital signature
Re: Bug#814901: jabref: at start jabref hangs with the error message "No appenders could be found for logger ..."
Dear Gregor, thanks a lot for your help. I now have a workaround, see below. It was great to work with you :-) On Wed, Feb 17, 2016 at 12:11:47AM +0100, gregor herrmann wrote: [...] > > > >prompt> DEBUG_WRAPPER=1 JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ > > > > jabref > > > > > > > > Xlib: extension "XInputExtension" missing on display ":0". > > > Ha! Here's an extra line, and that's the difference to my output. > > > Now we just need to find out what's missing / different on your > > > system, so that java can't connect to the X server. > > > (But then, your test with OpenJDK 7 should work?) > > I have tried this particular test again five times and did not get the > > Xlib message again. > > Hm. Maybe because there was still a java process lingering around? I tried this test a couple of times more: 1) I get the error message java: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. apart from the usual other erro messages and jabref crashed. 2) dito 3) It actually started and worked. 4) It hung. Then I killed all java processes: $ killall -9 java 5) It actually started and worked. 6) It actually started and worked. 7) It hung. Then I killed all java processes: $ killall -9 java 8) It actually started and worked. 9) It actually started and worked. 10) It hung. Then I killed all java processes: $ killall -9 java Ok, so much statistics for now. I am actually surprised that it worked a couple of time. So far it normally did not work at all. > > > Do other java programs work for you? > > Hm, I don't know. How would I find out? What are common other java > > programs? > > Depends on what you like :) > freemind, josm, tuxguitar are some that I use. > > `apt-cache rdepends default-jre' might give you some ideas. 'libreoffice' runs without problems. > > Ok, I looked a bit on the internet and wanted to write a little mini > > program in java. I figured I need the javac compiler. It is not > > installed on my computer, and it was not in the Debian unstable > > repository under that name either. > > "My" javac is /usr/bin/javac -> /etc/alternatives/javac -> > /usr/lib/jvm/java-8-openjdk-amd64/bin/javac > (from the openjdk-8-jdk package). But I guess installing another > package with software written in Java is easier. Ok, I found it. Now, it is all like that for my computer too. However, I did not bother writing a little java programm anymore, because 'libreoffice' runs ok and shows that java is ok in principle. [...] > > I hope all that gives you a bit more information to work with. > > It's certainly not a lack of information from your side that leaves > me a bit clueless :) Currently I think that the problem lies not with > JabRef but I have no idea what's happening between java and X on your > machine. - My hopes still lie in the Java team and their expertise :) > Or this: After some searching I found https://bugs.debian.org/802701 > which sounds quite similar. And even mentions JabRef ... with the > upstream ticket at https://github.com/JabRef/jabref/issues/393 . And > the Ubuntu bug at > https://bugs.launchpad.net/ubuntu/+source/jabref/+bug/1520294 > > The GitHub issue contains a workaround (changing the look&feel), > maybe this works for you too? (Same info in the Launchpad bug.) Ok, I commented out the line assistive_technologies=org.GNOME.Accessibility.AtkWrapper in file /etc/java-8-openjdk/accessibility.properties and then jabref started 10 times in a row with the usual error messages $ jabref log4j:WARN No appenders could be found for logger (org.java.plugin.ObjectFactory). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Found 2 plugin(s): - net.sf.jabref.export.misq (jar:file:/usr/share/jabref/JabRef-2.10.jar!/plugins/net.sf.jabref.export.misq/plugin.xml) - net.sf.jabref.core (jar:file:/usr/share/jabref/JabRef-2.10.jar!/plugins/net.sf.jabref.core/plugin.xml) but without any problems. Then I uncommented the line again and jabref started to not work reliably again. So that is a workaround for me. Then I tried the other solution. I went to Options -> Preferences -> Advanced and checked the tickbox 'Use other look and feel \\ Class name: com.jgoodies.plaf.plastic.Plastic3DLookAndFeel'.
Re: Tomcat 6 security vulnerabilities in Wheezy
On Thu, Feb 18, 2016 at 06:24:17PM +0100, Markus Koschany wrote: > Am 18.02.2016 um 18:10 schrieb Emmanuel Bourg: > > Le 18/02/2016 14:45, Markus Koschany a écrit : > > > >> According to [1] Tomcat 6 in Wheezy is still affected by a couple of > >> security vulnerabilities that were already fixed in Squeeze-LTS and > >> Jessie. Would it be sensible to apply the same changes (backporting the > >> 6.0.41 release to Wheezy too) or are there any reasons why this has not > >> been done before? Has anybody spoken with the Security Team about Tomcat > >> security updates in general? Do they approve of backporting newer > >> upstream releases? > > > > Hi Markus, > > > > I vaguely remember trying to backport the fixes and giving up due to the > > complexity. Also the lack of tests in Tomcat 6 makes this operation > > rather risky. That's why the LTS Team decided to package a more recent > > release in Squeeze. > > > > I don't know if the Security Team would accept a new upstream release > > for Wheezy. Since the LTS Team is probably going to upgrade the package > > when they take over the maintenance in April we could ask the Security > > Team to do this upgrade earlier. > > I am in favor of this solution, especially because we haven't heard > anything negative about this approach for Squeeze-LTS. If the Security > Team agrees I am going ahead and backport this release to Wheezy, test > the package and send the debdiff to them. Ok, please go ahead. Cheers, Moritz
