Re: jtreg for openjdk-8 in ELTS
Hi! On 02/11/2023 21:24, Thorsten Glaser wrote: Hi ELTS people (mostly pochu, I guess), for openjdk-8 tests, Vladimir tells me we “really” want jtreg5. If it is possible to add a jtreg5 package to jessie and stretch even if it exists nowhere else, perhaps with vendored dependencies where applicable like it is done for jtreg7 in stable now, we can use that. I had started to look at backporting jtreg6, without vendored dependencies. That was a bit painful due to the need of upgrading other packages, which had rdeps. Using vendored deps in this case sounds like a good solution. Not sure whether it will be easier for jtreg5. Vladimir would be able to tell you which dependencies would need to be included, and at which versions, or maybe even help with the package. Any help would be appreciated! libasmtools-java is also needed for fuller coverage but can probably be easily backported. Yeah, since it's is a new package there shouldn't be many issues with introducing that, as it's got no rdeps. Cheers, Emilio
Re: libspring-java support
Hi, On 03/12/2021 23:50, Markus Koschany wrote: Hi Sylvain, Am Freitag, dem 03.12.2021 um 14:28 +0100 schrieb Sylvain Beucler: Hi, This year I worked on libspring-java twice for LTS&ELTS. In both case upstream provided limited information for the CVEs, and for 5 of them we're unable to determine the fixes. https://deb.freexian.com/extended-lts/tracker/source-package/libspring-java Upstream declined to provide information to identify the fixes (which in turn would allow us to determine whether stretch and jessie are affected, and backport the fixes if needed). https://github.com/spring-projects/spring-framework/issues/26821 https://github.com/spring-projects/spring-framework/issues/27647 They made clear that they wouldn't provide this information even if paid, confirming they apply a security-by-obscurity strategy similar to Oracle's. I exchanged with the Debian security team after they witnessed the last exchanges above, and 2 weeks ago they concluded the latest CVE was minor and no action was needed right now. I insisted about the other, prior unfixable CVEs (1/4 impacting buster) but they haven't answered yet. I think we're not in capacity to offer further security support for libspring-java for LTS and ELTS, but I'd like to hear from other team members, especially if they work in the Java team (Markus?) - what do you think? Cheers! Sylvain Beucler Debian LTS Team I have made similar experiences like you when I contacted upstream and asked for more information about previous CVE. I agree with you that their policy makes future security support for us nearly impossible. Currently the main purpose of libspring-java is to build other software from source. We don't ship any application or web project that depends on Spring and exposes users to the currently unfixed CVE which means the current status of all CVE in Stretch/Buster/Bullseye (no-dsa/minor) is correct. It is also very unlikely that Java developers who use Spring/Spring Boot for their web applications depend on one of our Debian packages. In my opinion it is OK to ignore the currently known CVE. I would support adding libspring-java to the list of unsupported packages because of the lack of upstream support. We, as the Java team, should make this clear by mentioning libspring-java in the next release notes for Debian 12. Looks like Spring was marked as EOL in the security-tracker and debian-security-support git, but never uploaded to stretch or announced on debian-lts-announce (unless I missed it). I think this (as well as other packages recently EOL'ed) should be announced there, so users are aware. Should we add this to dla-needed so that someone can take care of it? Cheers, Emilio
Re: openjdk-8 8u275-b01-1
Hi Thorsten, On 02/12/2020 20:39, Thorsten Glaser wrote: On Wed, 2 Dec 2020, Emilio Pozuelo Monfort wrote: Let me know how those tests go and we can proceed from there. It builds, with the usual “most tests pass”, and the test program I threw at it also works. I have released this to stretch and jessie (after some testing on the latter). Cheers, Emilio
Re: openjdk-8 8u275-b01-1
On 02/12/2020 11:21, Thorsten Glaser wrote: Hi Emilio, If you can send a debdiff I'd be happy to take a look. the debdiff between sid and stretch would be trivial, just changelog and the regenerated debian/control file (attached). I’m building it at the moment so I can test it first. Do you also need a debdiff against the version currently in stretch? I can do that as well, but it’s going to be somewhat larger. No need for that. Let me know how those tests go and we can proceed from there. Thanks, Emilio
Re: openjdk-8 8u275-b01-1
Hi Thorsten, On 02/12/2020 10:06, Thorsten Glaser wrote: Hi (E)LTS-people, I’ve just uploaded an OpenJDK 8 regression update to sid, sponsored by my employer (as below). (I’m also building locally for buster, wheezy and various *buntu releases, so all possible systems I may encounter are covered, which is why I’m invested.) Would it help if I also prepared uploads to stretch-security and jessie-something, or do you prefer to continue doing so on your own? If you can send a debdiff I'd be happy to take a look. Thanks, Emilio
Bug#928988: RM: openjdk-7/experimental -- ROM; obsolete, no longer builds
Package: ftp.debian.org Severity: normal Hi, openjdk-7 was kept in experimental in order to prepare updates and see them build, and later backport them to the security suites that still had openjdk-7. However for a while now openjdk-7 hasn't built on experimental anymore, and it's only supported on jessie now, so it makes sense to remove it from experimental and upload the new updates directly to jessie. I talked to Matthias and he acked this plan. Cheers, Emilio
Re: netty-tcnative
On 20/06/18 10:02, Emmanuel Bourg wrote: > Hi Emilio, > > Le 20/06/2018 à 08:53, Emilio Pozuelo Monfort a écrit : > >> There is one remaining issue preventing the removal of netty-tcnative. netty >> build-depends on libnetty-tcnative-java. Is that necessary? > > I haven't checked thoroughly but I'm afraid it is. Netty is often used > to write SSL enabled network services and it relies on netty-tcnative. > We should probably inspect the netty rdeps and see if they use the SSL > related classes to have an idea of the impact of a netty-tcnative removal. Ok, if it's used then there's no need to remove it. I was just surprised it didn't depend on it, but only build-depended. What we should do then is bump tcnative to 2.0 then, and make libnetty-3.9-java depend on tcnative-1.1 if it's not compatible with 2.0. How does that sound? Cheers, Emilio
netty-tcnative
Hi Emmanuel, There is one remaining issue preventing the removal of netty-tcnative. netty build-depends on libnetty-tcnative-java. Is that necessary? If not, we can remove it, otherwise we can update libnetty-tcnative-java to 1.2 and make other rdeps use libnetty-tcnative-1.1-java as we discussed (or even do both). Cheers, Emilio
Re: Bug#681726: Time to remove eclipse from Testing?
On Sun, 4 Feb 2018 19:34:55 +0100 Markus Koschany wrote: > On Wed, 15 Nov 2017 18:01:07 +0200 Adrian Bunk wrote: > [...] > > I tried to sort out what I could find as required for getting the > > ancient eclipse out of testing in [1]: > > > > 1. src:bnd > > You fixed that already. > > > > 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform > > Is there some good way to break this dependency chain? > > > > 3. split libequinox-osgi-java out of src:eclise > > Or as a short-term hack, build only libequinox-osgi-java from src:eclipse. > > I have spent some time this weekend on Eclipse again. I have created a > standalone src:libequinox-osgi-java package and successfully rebuilt all > reverse-dependencies. We only have to make a small adjustment in > src:netbeans and src:libnb-platform18-java and update the osgi patch. > > If there are no objections I could go ahead and upload > libequinox-osgi-java to NEW. > > eclipse-rcp: > > * svnkit: > > There are two Eclipse specific classes that fail to build. As a > workaround we could remove one of them and patch SVNWCUtil. > > * android-sdktools and android-platform-tools-swt > > According to [1] both packages should be removed anyway. > > After that there would be only three packages left (not counting the > eclipse plugins) that build-depend on either eclipse-platform (aspectj) > or eclipse-jdt (lombok, biogenesis) I took a quick look at the current status: | $ dak rm -Rn -s testing eclipse | [...] | Checking reverse dependencies... | # Broken Depends: | pleiades: pleiades | | # Broken Build-Depends: | aspectj: eclipse-platform (>= 3.4.1) | lombok: eclipse-jdt | eclipse-platform-data | svnkit: eclipse-rcp biogenesis build-deps on 'default-jdk | eclipse-jdt', so that's not a problem. pleiades, lombok and svnkit could be removed from testing alongside eclipse. That leaves aspectj as the only blocker: | $ dak rm -Rn -s testing aspectj | [...] | Checking reverse dependencies... | # Broken Depends: | aspectj-maven-plugin: libaspectj-maven-plugin-java | | # Broken Build-Depends: | aspectj-maven-plugin: libaspectj-java (>= 1.8.2) | eclipselink: aspectj | libspring-java: libaspectj-java | openjpa: aspectj | shiro: libaspectj-java Cheers, Emilio
Re: Bug#870258: GCC 7 related library transitions
On 13/03/18 10:25, Matthias Klose wrote:
> On 13.03.2018 09:38, Emilio Pozuelo Monfort wrote:
>> On 03/03/18 10:59, Emilio Pozuelo Monfort wrote:
>>> As you can see it's a bunch of packages building with gcc-6 & g++-6. They
>>> probably
>>> need new upstream versions that support GCC 7. The only exception is
>>> libpam-script
>>> build-depending on libgfortran3 for no apparent good reason. I filed
>>> #889876 for that.
>>
>> I filed bugs for these:
>>
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=gcc-6-rm
>>
>>> As for the GCJ removal, I crafted this list of binary packages. This is
>>> running
>>> for sid, so it catches more stuff.
>>
>>> Some things here need to be updated to use openjdk or default-jdk, e.g.
>>> kamailio, pdftk, libidn...
>>> Other things likely need to be removed since GCJ is no more, e.g. ant-gcj,
>>> ecj-gcj...
>>
>> And for these:
>>
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=gcj-rm
>
> Please could you extend the latter with bug reports where
> default-jdk/default-jre is going to away altogether because it's provided by
> gcj? Things like db5.3 come to my mind ...
default-{jdk,jre} are provided by gcj on hurd and hppa. Worst case we'll have to
remove it and the rdeps on those architectures, but I'll open bugs against
openjdk-9 with a Cc for the porters in case they can take a look at it.
Emilio
Re: zookeeper 3.4.6
On 05/11/14 14:24, Tim Retout wrote: Hello, On the day of the freeze, I have noticed that I never uploaded zookeeper 3.4.6 - there is an untested patch sitting in git that would update it. Zookeeper 3.4.6 allegedly fixes a critical bug to do with joining an ensemble, but also has all these other changes: http://zookeeper.apache.org/doc/r3.4.6/releasenotes.html My understanding is that 3.4.6 is a relatively small bug-fix release, since recent versions of Solr were updated to include this version, so upstream are more confident about it. May I test and upload this version to unstable this evening? Or is the risk too great and I should hold off? I'd totally understand if so, and I'm sorry for leaving this so late. Please file an unblock bug, and attach a debdiff. Also look at the freeze policy and see if your request fulfills it. If in doubt, just send the debdiff in a bug report and we will comment on it. Emilio -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545c9480.4060...@debian.org
Re: Bug#708350: transition: java7
On 02/07/14 10:29, Emilio Pozuelo Monfort wrote: > On 01/07/14 10:42, Matthias Klose wrote: >> I would like to keep openjdk-6 in unstable (with a RC issue so that it >> doesn't >> migrate) to prepare and test security updates. > > You may want to close #720911 then. There were just two packages in testing still depending on openjdk-6, so I removed them from testing together with openjdk-6. There is #675495 so it will not enter jessie again. Closing. Emilio -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53be42d5.4050...@debian.org
Re: Bug#708350: transition: java7
On 01/07/14 10:42, Matthias Klose wrote: > I would like to keep openjdk-6 in unstable (with a RC issue so that it doesn't > migrate) to prepare and test security updates. You may want to close #720911 then. Emilio -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b3c2e6.9080...@debian.org
Re: Bug#708350: transition: java7
Control: block -1 by 750640 720911 Control: block 720911 by 750640 On 30/06/14 00:56, Emilio Pozuelo Monfort wrote: > Hi Steven, > > On 29/06/14 18:58, Steven Chamberlain wrote: >> Hi, >> >> On 24/06/14 16:11, Emilio Pozuelo Monfort wrote: >>> Is there anything left to do here? >> >> I presume openjdk-6 removal is the last thing to be done here. >> ftpmaster can't do that until icedtea-web stops building >> icedtea-6-plugin I think: https://bugs.debian.org/720911#36 > > Is it as easy as just removing that binary package? Or is it more complicated > than that? Is there a bug report about it? Any progress on that? Alright, that is #750640. Apparently src:icedtea-web just needs to stop building the icedtea-6-plugin binary. Matthias, can you do that? Then we can finally drop openjdk-6 from the archive. Regards, Emilio -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b09b40.8020...@debian.org
Re: Bug#708350: transition: java7
Hi Steven, On 29/06/14 18:58, Steven Chamberlain wrote: > Hi, > > On 24/06/14 16:11, Emilio Pozuelo Monfort wrote: >> Is there anything left to do here? > > I presume openjdk-6 removal is the last thing to be done here. > ftpmaster can't do that until icedtea-web stops building > icedtea-6-plugin I think: https://bugs.debian.org/720911#36 Is it as easy as just removing that binary package? Or is it more complicated than that? Is there a bug report about it? Any progress on that? Thanks, Emilio -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b09981.7030...@debian.org
Re: transition: java7
Hi, On 15/05/13 11:42, Matthias Klose wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > jessie won't ship anymore with OpenJDK 6, so we have to build and run using > OpenJDK 7. The good thing is that almost everything will continue to run, we > just have to fix build failures with OpenJDK 7. See [1] for the discussion of > the transition, and [2] for the list of issues which need to get addressed. > > Planning to do the transition in two steps: > > - Change the jre/jdk defaults to OpenJDK 7 from OpenJDK 6 which do have >a working OpenJDK 7. Keep OpenJDK 6 as the default for architectures >with a non-working OpenJDK 7. This decouples the transition from having >to change build dependencies in packages building bindings. >From my point of view this can happen anytime soon, and is mostly >independent from other transitions. This seems to have happened now, right? I see that default-(jre|jdk) depend on openjdk-7-(jre|jdk) everywhere but kbsd. > - When done, drop java support for architectures not having OpenJDK 7 >anymore (mips, mipsel, maybe s390). Nothing needs to be done if >these architectures don't qualify as release architectures anymore. Is that still true? I see that openjdk-7 successfully built on all current release architectures (including mips, mipsel and s390x). Is there anything left to do here? Regards, Emilio -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53a99508.4080...@debian.org
Bug#467332: RFS: bzr-eclipse - Support for Bazaar as a VCS in Eclipse
Package: wnpp Severity: wishlist X-Debbugs-CC: [EMAIL PROTECTED], debian-java@lists.debian.org, [EMAIL PROTECTED] * Package name: bzr-eclipse Version : 0.0.17 Upstream Author : Guillermo González <[EMAIL PROTECTED]> * URL or Web page : http://bazaar-vcs.org/BzrEclipse * License : GPLv2 Description : bzr support for the Eclipse IDE bzr-eclipse is a plugin for Eclipse that enables Bazaar support in the Eclipse SDK (JDT and CDT). The plugin should currently be considered alpha. signature.asc Description: OpenPGP digital signature
