Bug#1048703: plm: Fails to build source after successful build
Source: plm
Version: 2.9.2-1
Followup-For: Bug #1048703
Control: tags -1 patch
Dear Maintainer,
The enclosed patch will allow you to solve this bug.
Cheers,
--
Pierre
diff -Nru plm-2.9.2/debian/rules plm-2.9.2/debian/rules
--- plm-2.9.2/debian/rules 2020-10-11 21:54:58.0 +0200
+++ plm-2.9.2/debian/rules 2024-05-13 22:03:35.0 +0200
@@ -26,11 +26,28 @@
%:
dh $@ --with javahelper
+execute_before_dh_auto_configure:
+ # Making backups of files that will be altered during the build
+ for F in $$(find l10n/engine -name "*.po" -o -name "*.pot")
lib/resources/plm.configuration.properties; do \
+ cp $$F $${F}.save ;\
+ done
+
override_dh_auto_clean:
dh_auto_clean
find . -type f -name \*.java.json-simple \
-exec sh -c 'file={} && mv $$file $${file%.json-simple}' \; -print
+override_dh_clean:
+ dh_clean
+ # Removing files left there by the build system.
+ find . -name "*.jar" -delete
+ -rm dist/*.tar.bz2
+ -rm errors-*.txt
+ # Restoring files that were altered during the build
+ for F in $$(find . -name "*.save") ; do \
+ mv $$F $${F%.save} ;\
+ done
+
override_dh_auto_build:
find . -type f -name \*.java -exec grep -q 'import
@JSON_SIMPLE_PACKAGE@' {} \; \
-exec sed -i.json-simple \
Bug#1071082: FTBFS against jgit/6.7.0-1 in unstable
Source: plm
Version: 2.9.2-1
Severity: serious
Tags: ftbfs patch
Dear Maintainer,
I have just uploaded jgit/6.7.0 to unstable, in order to fix a security issue.
However, plm fails to build against it because some -- previously -- deprecated
methods have been removed.
The enclosed patch will allow you to build plm again.
Best,
--
Pierre
diff -Nru plm-2.9.2/debian/control plm-2.9.2/debian/control
--- plm-2.9.2/debian/control2020-10-11 21:54:58.0 +0200
+++ plm-2.9.2/debian/control2024-05-03 16:00:26.0 +0200
@@ -4,7 +4,7 @@
Maintainer: Martin Quinson
Build-Depends: debhelper-compat (= 12), javahelper (>= 0.32), ant, quilt
Build-Depends-Indep: default-jdk, scala, libmiglayout-java,
librsyntaxtextarea-java,
- junit4, libgettext-commons-java, libjson-simple-java, libhttpclient-java,
libhttpmime-java, libjgit-java,
+ junit4, libgettext-commons-java, libjson-simple-java, libhttpclient-java,
libhttpmime-java, libjgit-java (>= 6.7.0),
jython, libgettext-ant-tasks-java, imagemagick,
libmockito-java
Standards-Version: 4.5.0
diff -Nru plm-2.9.2/debian/patches/jgit_6.7.0.patch
plm-2.9.2/debian/patches/jgit_6.7.0.patch
--- plm-2.9.2/debian/patches/jgit_6.7.0.patch 1970-01-01 01:00:00.0
+0100
+++ plm-2.9.2/debian/patches/jgit_6.7.0.patch 2024-05-03 16:00:26.0
+0200
@@ -0,0 +1,26 @@
+Description: replacing methods removed in jgit 6.7.0
+ The method getRef in Repository had been deprecated in previous versions, and
+ is now removed.
+Author: Pierre Gruet
+Forwarded: no
+Last-Update: 2024-05-03
+
+--- a/src/plm/core/model/tracking/GitUtils.java
b/src/plm/core/model/tracking/GitUtils.java
+@@ -126,7 +126,7 @@
+
+ public void mergeRemoteIntoLocalBranch(String userBranchHash) throws
Exception {
+ try {
+- MergeResult res =
git.merge().setCommit(true).setFastForward(MergeCommand.FastForwardMode.FF).setStrategy(MergeStrategy.RECURSIVE).include(git.getRepository().getRef("refs/remotes/origin/"+userBranchHash)).call();
++ MergeResult res =
git.merge().setCommit(true).setFastForward(MergeCommand.FastForwardMode.FF).setStrategy(MergeStrategy.RECURSIVE).include(git.getRepository().findRef("refs/remotes/origin/"+userBranchHash)).call();
+
+ if(res.getMergeStatus() ==
MergeResult.MergeStatus.FAST_FORWARD) {
+ System.out.println(Game.i18n.tr("last session
data successfully retrieved"));
+@@ -376,6 +376,6 @@
+ }
+
+ public Ref getRepoRef(String branch) throws IOException {
+- return git.getRepository().getRef(branch);
++ return git.getRepository().findRef(branch);
+ }
+ }
diff -Nru plm-2.9.2/debian/patches/series plm-2.9.2/debian/patches/series
--- plm-2.9.2/debian/patches/series 2020-10-11 21:54:58.0 +0200
+++ plm-2.9.2/debian/patches/series 2024-05-03 15:59:24.0 +0200
@@ -4,3 +4,4 @@
jython-fixes
json-simple-3.patch
+jgit_6.7.0.patch
Bug#1069970: ITP: libeddsa-java -- implementation of EdDSA in Java
Package: wnpp Severity: wishlist Owner: Debian-Java team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org * Package name: libeddsa-java Version : 0.3.0 Upstream Contact: str4d * URL : https://github.com/str4d/ed25519-java * License : CC0-1.0 Programming Lang: Java Description : implementation of EdDSA in Java This package is needed as a dependency of libmina-sshd-java and of new upstream versions of jgit. I plan to maintain it in the Debian-Java team and to be its first uploader. This implementation of EdDSA is based on the ref10 implementation in SUPERCOP. There are two internal implementations: - A port of the radix-2^51 operations in ref10 - fast and constant-time, but only useful for Ed25519; - A generic version using BigIntegers for calculation - a bit slower and not constant-time, but compatible with any EdDSA parameter specification.
Bug#1066187: lacks dependency on libblaspp-dev
Package: liblapackpp-dev Version: 2023.11.05-1 Severity: normal Dear Maintainer, liblapackpp-dev lacks a dependency on libblaspp-dev. The latter is needed as /usr/lib//cmake/lapackpp/lapackConfig.cmake has a ``find_dependency(blaspp)'' command. Cheers, -- Pierre -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (90, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1064928: FTBFS everywhere
Source: openturns Version: 1.21.1-4 Severity: serious Tags: ftbfs fixed-in-experimental pending Hi, Since latest swig upstream version was uploaded to unstable, openturns FTBFS on all architectures. This can be fixed by applying https://github.com/openturns/openturns/commit/ff713c2520d5874b9a8a02cd313b95156bc3ec72 or alternatively by just waiting version 1.22 enters unstable, as it currently lies in experimental and incorporates this fix. We have to wait for the 64bit time_t transition and also for a proper transition slot for openturns. Best, -- Pierre
Bug#1064215: misses many dependencies
Package: libgrpc-java Version: 1.41.3+ds-2 Severity: normal Dear Maintainer, libgrpc-java should (at least) depend on libanimal-sniffer-java and libperfmark-java, as its pom files declare a dependency on their artifacts. Perhaps a general review of the dependencies would be useful. Best, -- Pierre
Bug#1063873: Building a reverse dependency of the guava-testlib artifact fails
Source: guava-libraries
Version: 32.0.1-1
Severity: important
Dear Maintainer,
When one tries to use the com.google.guava:guava-testlib:debian artifact in a
Maven pom.xml file, during the build one gets the error
[ERROR] Failed to execute goal on project myProject: Could not resolve
dependencies for project myGroup:myProject:jar:myVersion: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the artifact
com.google.guava:guava:bundle:debian has not been downloaded from it before. ->
[Help 1]
because the pom of guava-testlib looks for com.google.guava:guava with the
"bundle" type. I trust we should ship com.google.guava:guava with the "jar"
packaging type instead of "bundle", this is more accurate and compliant with
Debian-Java practices.
For instance I believe the enclosed patch allows one to package guava-libraries
with "jar" artifacts instead of "bundle". Yet I did not try to build the rdeps.
Best,
--
Pierre
--- a/guava-testlib/pom.xml
+++ b/guava-testlib/pom.xml
@@ -34,7 +34,6 @@
${project.groupId}
guava
${project.version}
- bundle
junit
--- a/guava/pom.xml
+++ b/guava/pom.xml
@@ -8,7 +8,7 @@
32.0.1-jre
guava
- bundle
+ jar
Guava: Google Core Libraries for Java
https://github.com/google/guava
Bug#1052519: New upstream version 7.2
Hello, Le 04/02/2024 à 03:59, Otto Kekäläinen a écrit : Thanks for maintaining this package in Debian, it is very useful! Could you please update it to latest version 7.2 so both Trixie and also Ubuntu 24.04 will ship with a fresh version? Thanks I will be having a look shortly! Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062715: FTBFS against openturns 1.22-1 in experimental
Source: persalys Version: 15.0+ds-3 Severity: important Tags: ftbfs Hi, persalys FTBFS against openturns/1.22-1 which is in experimental, waiting for a transition. I am almost sure updating persalys to newest upstream version will solve this. I will care for it soon. -- Pierre
Bug#1061603: openturns: FTBFS with Python 3.12 as default
Control: tags -1 fixed-in-experimental Control: fixed -1 1.22-1 Hi, The issue is fixed in version 1.22-1 in experimental. It will have to wait there a little bit as there are a lot of transitions of dependencies going on due to the 64 bit time_t transition. Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061603: openturns: FTBFS with Python 3.12 as default
Control: tags -1 confirmed Hi, On Sat, 27 Jan 2024 09:36:09 +0200 Graham Inggs wrote: > Source: openturns > Version: 1.21.1-4 > Severity: important > Tags: ftbfs patch > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > Hi Maintainer > > openturns FTBFS with Python 3.12 as the default version (i.e. with > python3-defaults/3.12.1-1 from experimental). I've copied what I hope > is the relevant part of the log below. > > The first failure is due to a change in Python 3.12, and fixed > upstream [1]. The second failure is due to a change in SWIG 4.2.0, > landing in unstable soon, see #1061392, and also fixed upstream [2]. > > Regards > Graham > > > [1] https://github.com/openturns/openturns/commit/fe388ec3e7a8e23ba1a3f7eada320165cba86fca > [2] https://github.com/openturns/openturns/commit/077b6d9d788ec6c4bbd972024ce0f94d3557f5c1 > > > > 46/597 Test #576: pyinstallcheck_SpecFunc_std > ***Failed 0.53 sec > Traceback (most recent call last): > File "/<>/python/test/t_SpecFunc_std.py", line 45, in > assert s1 == 0.0, "sum(x) nonzero" > AssertionError: sum(x) nonzero > > > 305/597 Test #837: pyinstallcheck_DiscreteCompoundDistribution_std > ***Failed 0.31 sec > Traceback (most recent call last): > File "/<>/python/test/t_DiscreteCompoundDistribution_std.py", > line 18, in > ott.assert_almost_equal( > File "/<>/debian/tmp/usr/lib/python3/dist-packages/openturns/testing.py", > line 174, in assert_almost_equal > return _testing.assert_almost_equal(*args) > ^^^ > RuntimeError: Value 0.00128141 is not close enough to 0.00128136 > > Thanks for the report, I am planning to upgrade to newest upstream version soon, and as you suggest, this will fix the test failures. Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055194: transition: openturns
Dear Release Team, I think this bug can be closed now, as the transition has been done. I am not doing it myself in case I might have missed something... Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059562: contributors.debian.org: some contributors are missing
Hi, Le 28/12/2023 à 20:47, Jonathan McDowell a écrit : On Thu, Dec 28, 2023 at 02:07:25PM +0100, Pierre Gruet wrote: I feel some contributors are missing from the page [0]. For instance, I (Pierre Gruet ) have never been on it although I have contributed on a regular basis since 2020. I have no idea of the number of missing people. I feel pointing this out now is relevant as we are currently [1] discussing figures based on the contents of [0]. If I look at https://contributors.debian.org/contributor/pgt/ there are no identifiers listed for you, but does know how to map your username to your real name. Compare this to my page, https://contributors.debian.org/contributor/noodles/, which lists email addresses, fingerprints + logins. Have you tried adding some associations there (and if you can't login, would you like me to?) - without any listed it won't be able to match up incoming data. Thanks for having looked at this bug report! I have been able to follow your suggestions and indeed got added to the list of contributors. I am now wondering whether we could be missing people (DD or not) as it seems the manipulations you described are needed in some cases. This is the sense of this bug report. J. Again, thanks a lot, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059562: contributors.debian.org: some contributors are missing
Package: nm.debian.org Severity: normal X-Debbugs-Cc: raf...@debian.org Hi, I feel some contributors are missing from the page [0]. For instance, I (Pierre Gruet ) have never been on it although I have contributed on a regular basis since 2020. I have no idea of the number of missing people. I feel pointing this out now is relevant as we are currently [1] discussing figures based on the contents of [0]. Best, -- Pierre [0] https://contributors.debian.org/ [1] https://lists.debian.org/debian-project/2023/12/msg00012.html
Bug#1058683: FTBFS against htsjdk/4.0.2+dfsg-1 now in unstable
Source: igv
Version: 2.16.2+dfsg-1
Severity: serious
Tags: patch
Hello,
igv fails to build against new htsjdk/4.0.2+dfsg-1:
/<>/src/main/java/org/broad/igv/track/TribbleFeatureSource.java:352:
error: reference to NamedFeature is ambiguous
if (f instanceof NamedFeature)
FeatureDB.addFeature((NamedFeature) f, genome);
^
both interface org.broad.igv.feature.NamedFeature in org.broad.igv.feature
and interface htsjdk.tribble.NamedFeature in htsjdk.tribble match
/<>/src/main/java/org/broad/igv/track/TribbleFeatureSource.java:352:
error: reference to NamedFeature is ambiguous
if (f instanceof NamedFeature)
FeatureDB.addFeature((NamedFeature) f, genome);
^
both interface org.broad.igv.feature.NamedFeature in org.broad.igv.feature
and interface htsjdk.tribble.NamedFeature in htsjdk.tribble match
There is some ambiguity to be removed, which is solved by the enclosed patch.
Best,
--
Pierre
Description: solving an ambiguity in the tests due to a new class in
htsjdk/4.0.2+dfsg
Author: Pierre Gruet
Forwarded: no
Last-Update: 2023-12-14
--- a/src/main/java/org/broad/igv/track/TribbleFeatureSource.java
+++ b/src/main/java/org/broad/igv/track/TribbleFeatureSource.java
@@ -349,7 +349,7 @@
featureMap.put(igvChr, featureList);
}
featureList.add(f);
-if (f instanceof NamedFeature)
FeatureDB.addFeature((NamedFeature) f, genome);
+if (f instanceof org.broad.igv.feature.NamedFeature)
FeatureDB.addFeature((org.broad.igv.feature.NamedFeature) f, genome);
if (this.isVCF && f instanceof Variant) {
Variant v = (Variant) f;
Bug#1053055: Additional information
Control: tags -1 confirmed Hello Vladimir, On Thu, 23 Nov 2023 11:32:20 +1300 Vladimir Petko wrote: > Dear Maintainers, > > Would it be possible to consider a merge request[1] that addresses this > issue? I am grateful you submitted this merge request, I will look at it shortly! > > Best Regards, > Vladimir. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053055 Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#988426: scilab,scilab-cli,scilab-test: metapackages uninstallable on 32-bit architectures
Control: severity -1 wishlist Control: tags -1 wontfix Hi, I am afraid I am missing the point here: it does not hurt anyone if the metapackages are not installable because their dependencies are not. Additionally scilab-test is huge and it makes no sense to make it Architecture: any and duplicate it for every arch. Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1043161: i2p: CVE-2023-36325
Hi again, Just for the sake of clarity: below I suggested a path to removal but I want to make it clear I don't intend to undertake such action, disrespecting the maintainer. Debian processes have to be respected. Best, -- Pierre Le 10/11/2023 à 10:05, Pierre Gruet a écrit : Hi Salvatore, I am doing some QA overseeeing, I am not the maintainer of i2p. I NMUed it one year and a half ago, nothing has happened since then. On Sun, 06 Aug 2023 21:26:51 +0200 Salvatore Bonaccorso wrote: > Source: i2p > Version: 0.9.48-1.1 > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > Hi, > > The following vulnerability was published for i2p. > > CVE-2023-36325[0]: > | Attackers can de-anonymize i2p hidden services with a message replay > | attack > > Should i2p be removed from unstable? - I feel fixing the CVE would require packaging last upstream version (which fixed it), Debian version is far behind it, upstream has changed its build system so a simple NMU is not the solution; - I don't feel the maintainer still has interest into this package, which he has not touched for 3 years; - There is another RC bug #1031817 needing being worked on, upstream has not addressed it yet; - i2p has not been in a Debian release since buster; - its popcon is quickly decreasing; - there is only one rdep, syndie, with the same maintainer, it has not seen an upload in 4 years and has a near-zero popcon. I would indeed suggest removing the package and syndie (RoQA) after letting some time to the maintainer to respond. Keeping these two packages in unstable seems only harmful right now. What do you think? > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2023-36325 > https://www.cve.org/CVERecord?id=CVE-2023-36325 > [1] https://xeiaso.net/blog/CVE-2023-36325 > > Regards, > Salvatore > > Best, OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1043161: i2p: CVE-2023-36325
Hi Salvatore, I am doing some QA overseeeing, I am not the maintainer of i2p. I NMUed it one year and a half ago, nothing has happened since then. On Sun, 06 Aug 2023 21:26:51 +0200 Salvatore Bonaccorso wrote: > Source: i2p > Version: 0.9.48-1.1 > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > Hi, > > The following vulnerability was published for i2p. > > CVE-2023-36325[0]: > | Attackers can de-anonymize i2p hidden services with a message replay > | attack > > Should i2p be removed from unstable? - I feel fixing the CVE would require packaging last upstream version (which fixed it), Debian version is far behind it, upstream has changed its build system so a simple NMU is not the solution; - I don't feel the maintainer still has interest into this package, which he has not touched for 3 years; - There is another RC bug #1031817 needing being worked on, upstream has not addressed it yet; - i2p has not been in a Debian release since buster; - its popcon is quickly decreasing; - there is only one rdep, syndie, with the same maintainer, it has not seen an upload in 4 years and has a near-zero popcon. I would indeed suggest removing the package and syndie (RoQA) after letting some time to the maintainer to respond. Keeping these two packages in unstable seems only harmful right now. What do you think? > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2023-36325 > https://www.cve.org/CVERecord?id=CVE-2023-36325 > [1] https://xeiaso.net/blog/CVE-2023-36325 > > Regards, > Salvatore > > Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055237: does not conform to the standards for library packaging
Control: severity -1 important Hi, Thanks Andrius for the advice given here. On Wed, 8 Nov 2023 09:44:58 +0200 Andrius Merkys wrote: > Hello, > > On Thu, 02 Nov 2023 18:10:19 +0100 Pierre Gruet wrote: > > Recently catch2/3.4.0-1 was uploaded to Debian, great. Yet the binary packages > > do not follow the layout for libraries that is described in Policy Section 8. > > For instance I think we should provide a shared library and if there are enough > > reasons not to do so (see Policy 8.3), at least the binary package name should > > be changed to libcatch2-dev. > > > > Also this is not a header-only library anymore, the description of the package > > should be changed. > > I agree, binary package could be renamed and descriptions should be > adapted as well. I am not sure about shared library, though. > > First, upstream uses full source package version for soversion. This > means a transition for even a patch level upstream release. I maintain a > couple of packages like this and it is tiring. > > Second, I do not expect any real binary package depending on catch2 > shared library as only test objects are linked with it. But I may be > wrong here. This seems like a good reason to keep a static library, at least for the moment. If there remains only the renaming of the package and its description to be changed, then downgrading the severity looks sensible. > > > As a side note, the upload of the major version 3.x came out with many breaking > > interface changes giving rise to RC bugs in e.g. genomicsdb, netgen, spdlog, > > therion just to name a few, also to failing autopkgtests in many rdeps. I would > > have been more comfortable with such a huge version change being advertised and > > more prepared, with some kind of a library transition process for instance. > > Right. Such changes should be announced beforehand since catch2 is used > widely in the archive. Transition would have been nice indeed. If you, Mathieu, have some insight into the best ways to transition reverse dependencies, I think giving it in the related bug reports would be very helpful. > > > In any case, thanks for your work on catch2, > > Seconded - thanks for maintaining this package. > > Best wishes, > Andrius > > Have a great day, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055237: does not conform to the standards for library packaging
Source: catch2 Version: 3.4.0-1 Severity: serious Dear Maintainer, Recently catch2/3.4.0-1 was uploaded to Debian, great. Yet the binary packages do not follow the layout for libraries that is described in Policy Section 8. For instance I think we should provide a shared library and if there are enough reasons not to do so (see Policy 8.3), at least the binary package name should be changed to libcatch2-dev. Also this is not a header-only library anymore, the description of the package should be changed. As a side note, the upload of the major version 3.x came out with many breaking interface changes giving rise to RC bugs in e.g. genomicsdb, netgen, spdlog, therion just to name a few, also to failing autopkgtests in many rdeps. I would have been more comfortable with such a huge version change being advertised and more prepared, with some kind of a library transition process for instance. In any case, thanks for your work on catch2, Best regards, -- Pierre
Bug#1055194: transition: openturns
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: opentu...@packages.debian.org Control: affects -1 + src:openturns Dear Release Team, I would like to request a transition slot for openturns. It has been accepted to experimental after a SONAME bump as some symbols changed in a not backward-compatible way. It builds correctly. There is only one rdep, persalys, which FTBFS against the new openturns, but the new upstream version of persalys builds correctly in experimental (upstream is the same). I have filled an Important bug anyway, #1055050. The auto-generated Ben file in the transition tracker looks good. Thanks a lot, -- Pierre
Bug#1054556: Raising severity to serious, ceres-solver has reached unstable
Source: colmap Version: 3.8-1 Followup-For: Bug #1054556 Control: severity -1 serious Hi, ceres-solver/2.2.0+dfsg-3 has reached unstable, thus I am raising the severity of this bug to RC. Best, -- Pierre
Bug#1054555: Fixed in experimental
Source: openturns Followup-For: Bug #1054555 Control: tags -1 fixed-in-experimental Hello, Now the version 1.21.1-2 of the package, currently in experimental, builds successfully against ceres-solver/2.2.0+dfsg-2. Cheers, -- Pierre
Bug#1055050: FTBFS against openturns/1.21.1-2 currently in experimental
Source: persalys Version: 13.1.1+ds-1 Severity: important Dear Maintainer (whom I am), openturns will soon undergo a library transition and currently persalys FTBFS against the version of openturns in experimental. Upgrading persalys to its new upstream version solves the issue. Best, -- Pierre
Bug#1053033: [Debichem-devel] Bug#1053033: jmol: FTBFS with default Java 21
Control: tags -1 pending Hi Emmanuel, Le 29/09/2023 à 02:04, Emmanuel Bourg a écrit : On Wed, 27 Sep 2023 11:03:16 +1300 Vladimir Petko wrote: classes: [mkdir] Created dir: /<>/build/classes [javac] Compiling 1117 source files to /<>/build/classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 7 [javac] error: Source option 7 is no longer supported. Use 8 or later. [javac] error: Target option 7 is no longer supported. Use 8 or later. This error no longer occurs with ant/1.10.14-1, but there is another error caused by the addLast() method in the Lst class conflicting with the newly introduced List.addLast() method. Changing the return type of this method should fix the issue. Thanks a lot for the hint, this actually allows one to build with openjdk-17 or openjdk-21. I had started imagining something more complicated... Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1052323: RM: biojava5-live -- ROM; superseded by biojava6-live
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: biojava5-l...@packages.debian.org Control: affects -1 + src:biojava5-live Hello, On behalf of Debian-med team, I am asking you to please remove biojava5-live from unstable. biojava6-live can be used instead and there is no rdep for biojava5-live, so that it can be safely removed and only causes maintenance burden if it remains there. Thanks a lot, -- Pierre
Bug#1050556: ITP: libfailsafe-java -- fault tolerance and resilience patterns Java library
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libfailsafe-java Version : 3.3.2 Upstream Contact: Jonathan Halterman * URL : Jonathan Halterman * License : Apache-2.0 Programming Lang: Java Description : fault tolerance and resilience patterns Java library Failsafe is a lightweight, zero-dependency library for handling failures in Java 8+, with a concise API for handling everyday use cases and the flexibility to handle everything else. It works by wrapping executable logic with one or more resilience policies, which can be combined and composed as needed. Policies include Retry, CircuitBreaker, RateLimiter, Timeout, Bulkhead, and Fallback. Additional modules include OkHttp. This package is needed as a dependency of nextflow. It will be team-maintained by the Debian-Java team.
Bug#1050538: bullseye-pu: package batik/1.12-4+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ba...@packages.debian.org
Control: affects -1 + src:batik
Dear Release Team,
I would like to propose an upload of batik in the next point release.
[ Reason ]
CVE-2022-44729 and CVE-2022-44730 have been filed against batik. They are fixed
in sid (and soon trixie). I discussed with Security team, they said a DSA is
not needed but suggested to fix the CVE in bullseye in a point release.
The two CVE are corrected by backporting upstream changes.
[ Impact ]
The two CVE would remain:
``A malicious SVG can probe user profile / data and send it directly as
parameter to a URL.''
and
``A malicious SVG could trigger loading external resources by default, causing
resource consumption or in some cases even information disclosure.''
[ Tests ]
The rdeps using the classes touched by upstream corrections were rebuilt in a
bullseye chroot. No additional tests were made.
[ Risks ]
Code is quite trivial and it is a direct backport of changes made in version
1.17, currently in sid. Risks due to the changes in the code are quite limited
in my opinion, but batik has many rdeps so you might consider the security
risks are not important enough to deserve an update in a point release.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in oldstable
[X] the issue is verified as fixed in unstable
[ Changes ]
Changes are in 7 files and consist in:
- Blocking loading external resource by default
http://svn.apache.org/viewvc?view=revision=1905049
- Switching to empty whitelist of packages for the class RhinoClassShutter
https://svn.apache.org/viewvc?view=revision=1905011
Thanks for your attention,
--
Pierre
diff -Nru batik-1.12/debian/changelog batik-1.12/debian/changelog
--- batik-1.12/debian/changelog 2022-10-29 16:22:11.0 +0200
+++ batik-1.12/debian/changelog 2023-08-25 11:07:07.0 +0200
@@ -1,3 +1,10 @@
+batik (1.12-4+deb11u2) bullseye; urgency=medium
+
+ * Team upload.
+ * Fixing CVE-2022-44729 and CVE-2022-44730
+
+ -- Pierre Gruet Fri, 25 Aug 2023 11:07:07 +0200
+
batik (1.12-4+deb11u1) bullseye-security; urgency=high
* Team upload.
diff -Nru batik-1.12/debian/patches/CVE-2022-447xx.patch
batik-1.12/debian/patches/CVE-2022-447xx.patch
--- batik-1.12/debian/patches/CVE-2022-447xx.patch 1970-01-01
01:00:00.0 +0100
+++ batik-1.12/debian/patches/CVE-2022-447xx.patch 2023-08-25
11:06:23.0 +0200
@@ -0,0 +1,199 @@
+Description: fixing CVE-2022-44729 and CVE-2022-44730
+ by applying the file changes of upstream commits fixing the CVE
+Author: Pierre Gruet
+Origin: upstream, https://issues.apache.org/jira/browse/BATIK-1347 and
https://issues.apache.org/jira/browse/BATIK-1349
+Forwarded: not-needed
+Last-Update: 2023-08-24
+
+---
a/batik-bridge/src/main/java/org/apache/batik/bridge/DefaultExternalResourceSecurity.java
b/batik-bridge/src/main/java/org/apache/batik/bridge/DefaultExternalResourceSecurity.java
+@@ -74,6 +74,9 @@
+ParsedURL docURL){
+ // Make sure that the archives comes from the same host
+ // as the document itself
++if (DATA_PROTOCOL.equals(externalResourceURL.getProtocol())) {
++return;
++}
+ if (docURL == null) {
+ se = new SecurityException
+ (Messages.formatMessage(ERROR_CANNOT_ACCESS_DOCUMENT_URL,
+---
a/batik-script/src/main/java/org/apache/batik/script/rhino/RhinoClassShutter.java
b/batik-script/src/main/java/org/apache/batik/script/rhino/RhinoClassShutter.java
+@@ -20,6 +20,7 @@
+
+ import org.mozilla.javascript.ClassShutter;
+ import java.util.Arrays;
++import java.util.ArrayList;
+ import java.util.List;
+
+ /**
+@@ -29,7 +30,7 @@
+ * @version $Id: RhinoClassShutter.java 1733416 2016-03-03 07:07:13Z gadams $
+ */
+ public class RhinoClassShutter implements ClassShutter {
+-private static final List WHITELIST =
Arrays.asList("java.io.PrintStream", "java.lang.System", "java.net.URL");
++ public static final List WHITELIST = new ArrayList<>();
+
+ /*
+ public RhinoClassShutter() {
+@@ -58,56 +59,12 @@
+ * Returns whether the given class is visible to scripts.
+ */
+ public boolean visibleToScripts(String fullClassName) {
+-if (fullClassName.startsWith("java.") &&
!WHITELIST.contains(fullClassName) && !fullClassName.endsWith("Permission")) {
+-return false;
+-}
+-
+-// Don't let them mess with script engine's internals.
+-if (fullClassName.startsWith("org.mozilla.javascript"))
+-return false;
+-
+-if (fullClassName.startsWith("org.apache.batik.")) {
+-
Bug#1050537: bookworm-pu: package batik/1.16+dfsg-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ba...@packages.debian.org
Control: affects -1 + src:batik
Dear Release Team,
I would like to propose an upload of batik in the next point release.
[ Reason ]
CVE-2022-44729 and CVE-2022-44730 have been filed against batik. They are fixed
in sid (and soon trixie). I discussed with Security team, they said a DSA is
not needed but suggested to fix the CVE in bookworm in a point release.
The two CVE are corrected by backporting upstream changes.
[ Impact ]
The two CVE would remain:
``A malicious SVG can probe user profile / data and send it directly as
parameter to a URL.''
and
``A malicious SVG could trigger loading external resources by default, causing
resource consumption or in some cases even information disclosure.''
[ Tests ]
The rdepss using the classes touched by upstream corrections were rebuilt in a
bookworm chroot. No additional tests were made.
[ Risks ]
Code is quite trivial and it is a direct backport of changes made in version
1.17, currently in sid. Risks due to the changes in the code are quite limited
in my opinion, but batik has many rdeps so you might consider the security
risks are not important enough to deserve an update in a point release.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Changes are in 7 files and consist in:
- Blocking loading external resource by default
http://svn.apache.org/viewvc?view=revision=1905049
- Switching to empty whitelist of packages for the class RhinoClassShutter
https://svn.apache.org/viewvc?view=revision=1905011
Thanks for your attention,
--
Pierre
diff -Nru batik-1.16+dfsg/debian/changelog batik-1.16+dfsg/debian/changelog
--- batik-1.16+dfsg/debian/changelog2022-10-27 18:27:37.0 +0200
+++ batik-1.16+dfsg/debian/changelog2023-08-24 21:28:00.0 +0200
@@ -1,3 +1,9 @@
+batik (1.16+dfsg-1+deb12u1) bookworm; urgency=medium
+
+ * Fixing CVE-2022-44729 and CVE-2022-44730
+
+ -- Pierre Gruet Thu, 24 Aug 2023 21:28:00 +0200
+
batik (1.16+dfsg-1) unstable; urgency=medium
* New upstream version 1.16+dfsg, fixing security issues:
diff -Nru batik-1.16+dfsg/debian/patches/CVE-2022-447xx.patch
batik-1.16+dfsg/debian/patches/CVE-2022-447xx.patch
--- batik-1.16+dfsg/debian/patches/CVE-2022-447xx.patch 1970-01-01
01:00:00.0 +0100
+++ batik-1.16+dfsg/debian/patches/CVE-2022-447xx.patch 2023-08-24
21:27:27.0 +0200
@@ -0,0 +1,208 @@
+Description: fixing CVE-2022-44729 and CVE-2022-44730
+ by applying the file changes of upstream commits fixing the CVE
+Author: Pierre Gruet
+Origin: upstream, https://issues.apache.org/jira/browse/BATIK-1347 and
https://issues.apache.org/jira/browse/BATIK-1349
+Forwarded: not-needed
+Last-Update: 2023-08-24
+
+---
a/batik-bridge/src/main/java/org/apache/batik/bridge/DefaultExternalResourceSecurity.java
b/batik-bridge/src/main/java/org/apache/batik/bridge/DefaultExternalResourceSecurity.java
+@@ -77,6 +77,9 @@
+ParsedURL docURL){
+ // Make sure that the archives comes from the same host
+ // as the document itself
++if (DATA_PROTOCOL.equals(externalResourceURL.getProtocol())) {
++return;
++}
+ if (docURL == null) {
+ se = new SecurityException
+ (Messages.formatMessage(ERROR_CANNOT_ACCESS_DOCUMENT_URL,
+---
a/batik-script/src/main/java/org/apache/batik/script/rhino/RhinoClassShutter.java
b/batik-script/src/main/java/org/apache/batik/script/rhino/RhinoClassShutter.java
+@@ -21,6 +21,7 @@
+ import org.mozilla.javascript.ClassShutter;
+
+ import java.util.Arrays;
++import java.util.ArrayList;
+ import java.util.List;
+
+ /**
+@@ -30,7 +31,7 @@
+ * @version $Id: RhinoClassShutter.java 1904565 2022-10-13 11:05:28Z ssteiner
$
+ */
+ public class RhinoClassShutter implements ClassShutter {
+-private static final List WHITELIST =
Arrays.asList("java.io.PrintStream", "java.lang.System", "java.net.URL");
++ public static final List WHITELIST = new ArrayList<>();
+
+ /*
+ public RhinoClassShutter() {
+@@ -59,56 +60,12 @@
+ * Returns whether the given class is visible to scripts.
+ */
+ public boolean visibleToScripts(String fullClassName) {
+-if (!WHITELIST.contains(fullClassName) &&
!fullClassName.endsWith("Permission") && !fullClassName.startsWith("org.")) {
+-return false;
+-}
+-
+-// Don't let them mess with script engine's internals.
+-if (fullClassName.startsWith("org.mozilla.javascript"))
+-return false;
+-
+-if (fullClassName.startsWith("org.
Bug#1029202: snippy: Error when using snpeff 5.1
Hi Andreas, Le 24/08/2023 à 11:21, Andreas Tille a écrit : Hi Pierre, I just noticed that snpeff upstream has tagged a new release. I've injected the new tarball into Salsa Git but did not yet worked on the quilt patches that need to be adapted. If you throw an ENOTIME error I could see how far I might come with the changes. If you find some spare time for this issue I'd leave further changes to you. I found some time :-D Upstream changed the location of the build-time tests, putting them in a more canonical place. I updated the patches and d/rules accordingly. This is all pushed to the Salsa repo. However, the script you provided in the bug report [0] is still not working with this newly packaged version 5.1+f+dfsg (tested locally), so probably we should do as you suggested there [1] and provide 5.1+d+dfsg-really5.0+f in unstable, as the script is working with version 5.0+f. Admittedly this is a step back for the library, but as least one would have the use case of your colleagues working. If you still think this is a good idea, I offer to finalize this step back. Kind regards Andreas. Best, -- Pierre [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029202#5 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029202#37 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050170: ITP: libconcurrentunit-java -- simple toolkit for testing multi-threaded Java code
Package: wnpp Severity: wishlist Owner: Debian Java Maintainers X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libconcurrentunit-java Version : 0.4.6 Upstream Contact: Jonathan Halterman * URL : https://github.com/jhalterman/concurrentunit * License : Apache-2.0 Programming Lang: Java Description : simple toolkit for testing multi-threaded Java code ConcurrentUnit was created to help developers test multi-threaded or asynchronous code. It allows one to perform assertions and wait for operations in any thread, with failures being properly reported back to the main test thread. If an assertion fails, the test fails, regardless of which thread the assertion came from. This package is needed as a (transitive) dependency of nextflow. It will be team-maintained by the Debian-Java team.
Bug#1049904: O: dicelab -- tool to compute the statistical distribution of dice rolls
Package: wnpp Severity: normal X-Debbugs-Cc: dice...@packages.debian.org Control: affects -1 + src:dicelab I intend to orphan the dicelab package because of a lack of interest and apparently a poor number of users. Upstream seems to be inactive as the orig website has been unreachable for many months. The package description is: With dicelab you can express most dice rolls (and similar things) in a functional language, and then either roll the expression, or evaluate the statistical distribution. In the latter case you can choose whether you want to simply roll and tally many times, or actually compute the distribution (which is more precise, but takes a long time in some obscure cases). The package is in good shape, although it is affected by #1049747 related to the clean target. Cheers, -- Pierre
Bug#1042690: ceres-solver: FTBFS with Sphinx 7.1, docutils 0.20: rm: cannot remove '/<>/debian/tmp/usr/share/doc/Ceres/html/_static/jquery.js': No such file or directory
Control: tags -1 pending confirmed Hi, On Sun, 30 Jul 2023 20:27:51 +0200 Lucas Nussbaum wrote: > Source: ceres-solver > Version: 2.1.0+really2.1.0+dfsg-1 > Severity: important > Tags: ftbfs > User: python-modules-t...@lists.alioth.debian.org > Usertags: sphinx7.1 > > Hi, > > ceres-solver fails to build with Sphinx 7.1 and docutils 0.20, both of which > are currently available in experimental. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > # make lintian happy > > # https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0 -> /usr/share/javascript/mathjax > > sed -i 's/https:\/\/cdnjs.cloudflare.com\/ajax\/libs\/mathjax\/2.7.1/\/usr\/share\/javascript\/mathjax/g' /<>/debian/tmp/usr/share/doc/Ceres/html/*.html > > sed -i 's/https:\/\/cdn.jsdelivr.net//g' /<>/debian/tmp/usr/share/doc/Ceres/html/*.html > > rm /<>/debian/tmp/usr/share/doc/Ceres/html/_static/doctools.js > > ln -s /usr/share/javascript/sphinxdoc/1.0/doctools.js /<>/debian/tmp/usr/share/doc/Ceres/html/_static/doctools.js > > rm /<>/debian/tmp/usr/share/doc/Ceres/html/_static/jquery.js > > rm: cannot remove '/<>/debian/tmp/usr/share/doc/Ceres/html/_static/jquery.js': No such file or directory > > make[1]: *** [debian/rules:83: override_dh_installdocs-indep] Error 1 > > > The full build log is available from: > http://qa-logs.debian.net/2023/07/30/exp/ceres-solver_2.1.0+really2.1.0+dfsg-1_unstable_sphinx-exp.log > > Please see [1] for Sphinx changelog and [2] for Docutils changelog. > > Also see [3] for the list of deprecated/removed APIs in Sphinx and possible > alternatives to them. > > Some notable changes in Sphinx 6 and Sphinx 7: > > - Sphinx no longer includes jquery.js and underscore.js by default. > Please use python3-sphinxcontrib.jquery package if you are using a custom > template and it still needs jquery. > > - The setup.py build_sphinx command was removed. Please instead call > sphinx-build or "python3 -m sphinx" directly. > > - For packages using the extlinks extension, the caption should contain > exactly one "%s" placeholder (if caption is not None). > > In case you have questions, please Cc sph...@packages.debian.org on reply. > > [1]: https://www.sphinx-doc.org/en/master/changes.html > [2]: https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.20.1:/RELEASE-NOTES.txt > [3]: https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx7.1;users=python-modules-t...@lists.alioth.debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=sphinx7.1=python-modules-t...@lists.alioth.debian.org=1=1=1=1#results > > If you reassign this bug to another package, please marking it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > This is corrected by removing some creations of symlinks in d/rules, pushed to Salsa. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1042857: coinor-libcbc3.1: Fails to install, conflicts with coinor-libcbc3:amd64
On Tue, 1 Aug 2023 23:21:52 +0200 Samuel Thibault wrote: > Package: coinor-libcbc3.1 > Version: 2.10.10+really2.10.10+ds1-2 > Severity: serious > Justification: Fails to install > > Hello, > > While upgrading testing today: > > Preparing to unpack .../coinor-libcbc3.1_2.10.10+really2.10.10+ds1-2_amd64.deb ... > Unpacking coinor-libcbc3.1:amd64 (2.10.10+really2.10.10+ds1-2) ... > dpkg: error processing archive /var/cache/apt/archives/coinor-libcbc3.1_2.10.10+really2.10.10+ds1-2_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/libCbc.so.3.10.10', which is also in package coinor-libcbc3:amd64 2.10.10+ds1-1 > Errors were encountered while processing: > /var/cache/apt/archives/coinor-libcbc3.1_2.10.10+really2.10.10+ds1-2_amd64.deb > needrestart is being skipped since dpkg has failed > > I guess there should be some breaks+replace or some renaming? > > Samuel > > -- System Information: > Debian Release: trixie/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, arm64 > > Kernel: Linux 6.3.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages coinor-libcbc3.1 depends on: > ii coinor-libcgl1 0.60.3+repack1-4 > ii coinor-libclp1 1.17.6-3 > ii coinor-libcoinutils3v5 2.11.4+repack1-2 > ii coinor-libosi1v5 0.108.6+repack1-2 > ii libc6 2.37-6 > ii libgcc-s1 13.1.0-6 > ii libstdc++6 13.1.0-6 > > coinor-libcbc3.1 recommends no packages. > > coinor-libcbc3.1 suggests no packages. > >
Bug#1042016: transition: coinor-cbc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: coinor-...@packages.debian.org Control: affects -1 + src:coinor-cbc Dear Release Team, I would like to ask for a transition slot for coinor-cbc. The package has undergone ABI changes for which a SONAME bump was necessary. The new package has been accepted into experimental and builds correctly on all architectures. The auto-generated Ben file on [0] is fine. The reverse dependencies all build correctly against the new library package. Best regards, -- Pierre [0] https://release.debian.org/transitions/html/auto-coinor-cbc.html
Bug#1041841: transition: pagmo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pa...@packages.debian.org Control: affects -1 + src:pagmo Dear Release Team, I would like to ask for a transition slot for pagmo. libpagmo9 has been accepted in experimental, it builds correctly on all the architectures where it built before, and its only rdep openturns builds successfully against it. The auto-generated Ben file is good. Thanks a lot, Cheers, -- Pierre
Bug#1040694: Proposing a way to solve #1040694
Hello Julien, I am writing to you in addition to the sole bug report as you are the uploader of coinor-cbc. Because we saw an ABI breakage between versions 2.10.8 and 2.10.10 which affects rdeps, I propose to: - Revert the version in unstable to 2.10.8, with upstream version number being 2.10.10+really2.10.8+ds1; - Upload 2.10.10+really2.10.10+ds1 (containing upstream 2.10.10) to experimental with a SOVERSION raised to 3.1 and renaming the shared lib package to coinor-libcbc3.1, hereby using a SOVERSION higher than the upstream one but still being lower than the "4" they could adopt in the future; - Lead a classic library transition so that rdeps are rebuilt. I volunteer to do this if you want, as this is a blocker for my workflows. Please kindly raise concerns if you need to :) Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1040694: Package has to go through a proper transition process
Control: severity -1 serious Control: retitle -1 Package has to go through a proper transition process Hi, After the discussions in https://lists.debian.org/debian-mentors/2023/07/msg00057.html it appears the package should have undergone a transition process and a SONAME bump between versions 2.10.8+ds1-1 and 2.10.10+ds1-1 as there are ABI breakages. I suggest we revert the upstream version to 2.10.8 using a +really version number and then lead the transition itself. But feel free to handle this bug report differently if you wish. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1040694: Segfault in CbcModel::initialSolve
Source: coinor-cbc Version: 2.10.10+ds1-1 Severity: important X-Debbugs-Cc: schuel...@phimeca.com Dear Maintainer, Starting from version 2.10.10+ds1-1 (2.10.8+ds1-1 was OK), one of the build-time tests of openturns started to fail: t_Bonmin_std. Running it with gdb I get: --->8 (gdb) run Starting program: /build/openturns-eQ5lBV/openturns-1.20/builddir/lib/test/t_Bonmin_std [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". class=Bonmin algorithm=B-BB options= mu_oracle=loqo Program received signal SIGSEGV, Segmentation fault. 0x71ce1347 in CbcModel::initialSolve() () from /usr/lib/x86_64-linux-gnu/libCbc.so.3 (gdb) bt #0 0x71ce1347 in CbcModel::initialSolve() () from /usr/lib/x86_64-linux-gnu/libCbc.so.3 #1 0x748a2705 in Bonmin::Bab::branchAndBound(Bonmin::BabSetupBase&) () from /usr/lib/x86_64-linux-gnu/libbonmin.so.4 #2 0x7755b48e in OT::Bonmin::run (this=this@entry=0x7fffe440) at ./lib/src/Base/Optim/Bonmin.cxx:174 #3 0xf285 in main () at ./lib/test/t_Bonmin_std.cxx:131 --->8 which indicates a problem in coinor-cbc. The above backtrace is somewhat reminiscent of the one of the issue https://github.com/coin-or/Cbc/issues/591 which has been fixed in upstream version 2.10.10. I suspect a close issue is showing up here. Thanks a lot for your help, -- Pierre
Bug#1021894: openjfx: FTBFS on arm64 and armhf
Control: affects -1 src:libjogl2-java src:beast2-mcmc Control: severity -1 serious Hi, I am restoring the severity of this FTBFS bug, which has concrete consequences on several packages. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1039521: Summarizing my proposed changes about the Java part of protobuf
Hello again, Le 29/06/2023 à 21:22, László Böszörményi (GCS) a écrit : On Thu, Jun 29, 2023 at 9:15 PM Pierre Gruet wrote: Le 29/06/2023 à 18:41, László Böszörményi (GCS) a écrit : Do you have your proposed package somewhere? I would also like to check it with the updated protobuf package before uploading. You can find it in the public repo https://salsa.debian.org/pgt/protobuf Your package = genomicsdb but I guess it's in the med-team repo [1]. Cheers, Laszlo/GCS [1] https://salsa.debian.org/med-team/genomicsdb Sorry, obviously I misread your request. Yes this is genomicsdb, located at [1]. You may get it and build it against protobuf with the changes I proposed and it should be OK! Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1039521: Summarizing my proposed changes about the Java part of protobuf
Hi Laszlo, Thanks for looking at my proposal, I am glad you consider it fit! Le 29/06/2023 à 18:41, László Böszörményi (GCS) a écrit : Hi Pierre, On Wed, Jun 28, 2023 at 4:39 PM Pierre Gruet wrote: - removing j2objc from the pom.xml so that rdeps don't look for this Debian-unpackaged artifact (touches d/p/no_j2objc.patch); Thanks for all of your work on this! I see you added this as a patch, but not included in the series file. Meaning it will not be applied. It's just an oversight I guess. Other than that it looks good. Sorry, indeed I provided you with an excerpt of a source debdiff, which might not be the most suitable way to do it. Do you have your proposed package somewhere? I would also like to check it with the updated protobuf package before uploading. You can find it in the public repo https://salsa.debian.org/pgt/protobuf I initiated it with version 3.21.12-3 that is currently packaged, and made commits for each change I listed in my previous email. Hopefully this is more handy! Despite what is in d/changelog, I did not intend to NMU, it was only a changelog entry to get a consistent package in order to run my tests locally. Thanks, Laszlo/GCS Please tell me if I may do something else for you here. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1039521: Summarizing my proposed changes about the Java part of protobuf
Control: retitle -1 please rewrite the Java packaging to build rdeps
Control: affects -1 src:genomicsdb
Hello,
This is a summary email for this bug thread as I tested locally some
changes to the packaging, so that rdeps relying on the
/usr/share/java/protobuf-util.jar can build and run.
These changes amount to:
- using javahelper during the build to provide a suitable classpath for
protobuf-util.jar (touching d/control, d/libprotobuf-java.classpath,
d/rules);
- removing j2objc from the pom.xml so that rdeps don't look for this
Debian-unpackaged artifact (touches d/p/no_j2objc.patch);
- adding a "test" scope for junit in the pom.xml so that no rdep looks
for junit while building (touches d/p/series,
d/p/test_scope_for_junit.patch).
All this is in the attached patch, which allows one to build the new
upstream version of genomicsdb. This package is thus affected by the
present bug.
I would be pleased to provide more information or to help with uploading
the proposed fix if you wish.
Best,
--
Pierre
diff -Nru protobuf-3.21.12/debian/control protobuf-3.21.12/debian/control
--- protobuf-3.21.12/debian/control 2022-12-04 13:49:06.0 +0100
+++ protobuf-3.21.12/debian/control 2023-06-27 06:42:22.0 +0200
@@ -29,6 +29,7 @@
# Java
ant
, default-jdk
+ , javahelper
, maven-repo-helper
, libguava-java
, libgoogle-gson-java
diff -Nru protobuf-3.21.12/debian/libprotobuf-java.classpath protobuf-3.21.12/debian/libprotobuf-java.classpath
--- protobuf-3.21.12/debian/libprotobuf-java.classpath 1970-01-01 01:00:00.0 +0100
+++ protobuf-3.21.12/debian/libprotobuf-java.classpath 2023-06-27 06:42:22.0 +0200
@@ -0,0 +1 @@
+usr/share/java/protobuf-util.jar /usr/share/java/gson.jar /usr/share/java/guava.jar /usr/share/java/protobuf.jar
diff -Nru protobuf-3.21.12/debian/patches/no_j2objc.patch protobuf-3.21.12/debian/patches/no_j2objc.patch
--- protobuf-3.21.12/debian/patches/no_j2objc.patch 2022-03-11 01:28:07.0 +0100
+++ protobuf-3.21.12/debian/patches/no_j2objc.patch 2023-06-27 06:41:32.0 +0200
@@ -8,7 +8,7 @@
--- a/java/util/src/main/java/com/google/protobuf/util/Timestamps.java
+++ b/java/util/src/main/java/com/google/protobuf/util/Timestamps.java
-@@ -38,7 +38,7 @@ import static com.google.common.math.Lon
+@@ -38,7 +38,7 @@
//import com.google.errorprone.annotations.CanIgnoreReturnValue;
//import com.google.errorprone.annotations.CompileTimeConstant;
@@ -17,7 +17,7 @@
import com.google.protobuf.Duration;
import com.google.protobuf.Timestamp;
import java.io.Serializable;
-@@ -338,7 +338,6 @@ public final class Timestamps {
+@@ -338,7 +338,6 @@
* @throws IllegalArgumentException if the year is before 1 CE or after CE
*/
@SuppressWarnings("GoodTime") // this is a legacy conversion API
@@ -25,3 +25,19 @@
public static Timestamp fromDate(Date date) {
if (date instanceof java.sql.Timestamp) {
java.sql.Timestamp sqlTimestamp = (java.sql.Timestamp) date;
+--- a/java/util/pom.xml
b/java/util/pom.xml
+@@ -27,11 +27,11 @@
+ error_prone_annotations
+ 2.5.1
+
+-
++
+
+ com.google.code.findbugs
+ jsr305
diff -Nru protobuf-3.21.12/debian/patches/series protobuf-3.21.12/debian/patches/series
--- protobuf-3.21.12/debian/patches/series 2023-04-07 20:12:46.0 +0200
+++ protobuf-3.21.12/debian/patches/series 2023-06-27 06:41:55.0 +0200
@@ -16,3 +16,4 @@
build_32_bit_tests.patch
fix_C++_32bit_tests.patch
fix_Python_32bit_tests.patch
+test_scope_for_junit.patch
diff -Nru protobuf-3.21.12/debian/patches/test_scope_for_junit.patch protobuf-3.21.12/debian/patches/test_scope_for_junit.patch
--- protobuf-3.21.12/debian/patches/test_scope_for_junit.patch 1970-01-01 01:00:00.0 +0100
+++ protobuf-3.21.12/debian/patches/test_scope_for_junit.patch 2023-06-27 06:42:19.0 +0200
@@ -0,0 +1,10 @@
+--- a/java/util/pom.xml
b/java/util/pom.xml
+@@ -50,6 +50,7 @@
+
+ junit
+ junit
++ test
+
+
+ org.mockito
diff -Nru protobuf-3.21.12/debian/rules protobuf-3.21.12/debian/rules
--- protobuf-3.21.12/debian/rules 2023-04-09 07:50:55.0 +0200
+++ protobuf-3.21.12/debian/rules 2023-06-27 06:42:22.0 +0200
@@ -20,9 +20,9 @@
%:
ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x hppa ppc64 riscv64 sh4 sparc64 x32))
- dh $@ --with autoreconf,elpa
+ dh $@ --with autoreconf,elpa,javahelper
else
- dh $@ --with autoreconf -Nelpa-protobuf-mode
+ dh $@ --with autoreconf,javahelper -Nelpa-protobuf-mode
endif
ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1039521: Also caring for junit:junit
Hello again, Sorry, it seems I sent the bug report too early. There should be another change in java/util.pom.xml : the junit artifact misses the "test" scope. Precisely, we should change the junit stanza to junit junit test Else, junit would be needed during the build of rdeps even when one would not run any test (DEB_BUILD_OPTIONS=nocheck e.g.). Thanks again, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1039521: requires unpackaged j2objc artifacts through pom.xml
Package: libprotobuf-java
Version: 3.21.12-3
Severity: important
Tags: patch
Dear Maintainer,
I am in the progress of updating one of my packages, genomicsdb. While doing
so, I stumbled upon an issue in the file
/usr/share/maven-repo/com/google/protobuf/protobuf-java-util/3.21.12/protobuf-java-util-debian.pom
that is shipped by libprotobuf-java. It requires the j2objc-annotations
artifact as one of its dependencies, although this is not available in Debian.
I suggest to enrich a bit the dedicated patch you wrote for src:protobuf in
order to move this dependency out of the way. Right now, the new upstream
version of genomicsdb cannot be built.
The enclosed patch does this.
I will be happy to give more information if needed.
Thanks for considering,
--
Pierre
diff -Nru protobuf-3.21.12/debian/patches/no_j2objc.patch
protobuf-3.21.12/debian/patches/no_j2objc.patch
--- protobuf-3.21.12/debian/patches/no_j2objc.patch 2022-03-11
01:28:07.0 +0100
+++ protobuf-3.21.12/debian/patches/no_j2objc.patch 2023-06-26
20:52:50.0 +0200
@@ -8,7 +8,7 @@
--- a/java/util/src/main/java/com/google/protobuf/util/Timestamps.java
+++ b/java/util/src/main/java/com/google/protobuf/util/Timestamps.java
-@@ -38,7 +38,7 @@ import static com.google.common.math.Lon
+@@ -38,7 +38,7 @@
//import com.google.errorprone.annotations.CanIgnoreReturnValue;
//import com.google.errorprone.annotations.CompileTimeConstant;
@@ -17,7 +17,7 @@
import com.google.protobuf.Duration;
import com.google.protobuf.Timestamp;
import java.io.Serializable;
-@@ -338,7 +338,6 @@ public final class Timestamps {
+@@ -338,7 +338,6 @@
* @throws IllegalArgumentException if the year is before 1 CE or after
CE
*/
@SuppressWarnings("GoodTime") // this is a legacy conversion API
@@ -25,3 +25,19 @@
public static Timestamp fromDate(Date date) {
if (date instanceof java.sql.Timestamp) {
java.sql.Timestamp sqlTimestamp = (java.sql.Timestamp) date;
+--- a/java/util/pom.xml
b/java/util/pom.xml
+@@ -27,11 +27,11 @@
+ error_prone_annotations
+ 2.5.1
+
+-
++
+
+ com.google.code.findbugs
+ jsr305
Bug#1037542: bookworm-pu: package xerial-sqlite-jdbc/3.40.1.0+dfsg-1+deb12u1
Hi Salvatore,
Le 15/06/2023 à 07:21, Salvatore Bonaccorso a écrit :
Hi Pierre,
On Wed, Jun 14, 2023 at 12:01:18AM +0200, Pierre Gruet wrote:
[...]
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog
xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog 2023-02-04
14:24:45.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog 2023-06-13
23:19:59.0 +0200
@@ -1,3 +1,9 @@
+xerial-sqlite-jdbc (3.40.1.0+dfsg-1+deb12u1) bookworm; urgency=medium
+
+ * Using a random UUID for the connection (Fixes CVE-2023-32697 in Bookworm)
+
+ -- Pierre Gruet Tue, 13 Jun 2023 23:19:59 +0200
Can you as well add the Debian bug closer for #1036706 here?
Thanks for looking at my diff. I admit I had not considered closing the
bug here since it has already been declared as closed by the upload to
unstable, I would have issued a BTS command after this proposal hits
bookworm.
Anyway, thanks for educating me on this.
Enclosed is the new source debdiff, everything else in the original
message of this bug thread remains unchanged.
Regards,
Salvatore
Best,
--
Pierre
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog 2023-02-04 14:24:45.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog 2023-06-13 23:19:59.0 +0200
@@ -1,3 +1,10 @@
+xerial-sqlite-jdbc (3.40.1.0+dfsg-1+deb12u1) bookworm; urgency=medium
+
+ * Using a random UUID for the connection (Fixes CVE-2023-32697 in Bookworm,
+Closes: #1036706)
+
+ -- Pierre Gruet Tue, 13 Jun 2023 23:19:59 +0200
+
xerial-sqlite-jdbc (3.40.1.0+dfsg-1) unstable; urgency=medium
* New upstream version 3.40.1.0+dfsg
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch 1970-01-01 01:00:00.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch 2023-06-13 23:17:23.0 +0200
@@ -0,0 +1,28 @@
+Description: fixing CVE-2023-32697
+Author: Pierre Gruet
+Origin: upstream, https://github.com/xerial/sqlite-jdbc/commit/edb4b8adc2447bc04e05b9b908195a4bc7926242
+Bug: https://github.com/xerial/sqlite-jdbc/security/advisories/GHSA-6phf-6h5g-97j2
+Bug-Debian: https://bugs.debian.org/1036706
+Forwarded: not-needed
+Applied-Upstream: edb4b8adc2447bc04e05b9b908195a4bc7926242
+Last-Update: 2023-06-13
+
+--- a/src/main/java/org/sqlite/SQLiteConnection.java
b/src/main/java/org/sqlite/SQLiteConnection.java
+@@ -13,6 +13,7 @@
+ import java.sql.ResultSet;
+ import java.sql.SQLException;
+ import java.util.Properties;
++import java.util.UUID;
+ import java.util.concurrent.Executor;
+ import org.sqlite.SQLiteConfig.TransactionMode;
+ import org.sqlite.core.CoreDatabaseMetaData;
+@@ -303,7 +304,7 @@
+ }
+
+ String tempFolder = new File(System.getProperty("java.io.tmpdir")).getAbsolutePath();
+-String dbFileName = String.format("sqlite-jdbc-tmp-%d.db", resourceAddr.hashCode());
++String dbFileName = String.format("sqlite-jdbc-tmp-%s.db", UUID.randomUUID());
+ File dbFile = new File(tempFolder, dbFileName);
+
+ if (dbFile.exists()) {
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series 2023-02-02 17:16:53.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series 2023-06-13 23:10:58.0 +0200
@@ -7,3 +7,4 @@
skip_OSInfoTest.patch
tests_without_archunit-junit5_and_some_assertions.patch
junit-jupiter-params_artifact.patch
+CVE-2023-32697.patch
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1037542: bookworm-pu: package xerial-sqlite-jdbc/3.40.1.0+dfsg-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: xerial-sqlite-j...@packages.debian.org
Control: affects -1 + src:xerial-sqlite-jdbc
Dear Release team,
I would like to upload xerial-sqlite-jdbc to stable-proposed-updates.
[ Reason ]
Grave bug #1036706 has been filled a few days before the release of Bookworm.
This is a security bug associated to CVE-2023-32697. Although it has been
marked no-dsa by the security team, we exchanged a few emails and our
conclusion was the fix of this bug, which amounts to cherry-pick one commit of
upstream, should land in Bookworm during a point release.
[ Impact ]
CVE-2023-32697 would remain. The Debian-packaged reverse dependencies of the
package are mainly used in a single-user environment, but possibly it is also
used in a network environment by some users for their own programs, and this is
where there might be some hazard.
[ Tests ]
The package was built in a Bookworm chroot and its autopkgtest is passing.
[ Risks ]
Code is very simple, only 2 lines are changed. Upstream has published it
three weeks ago and it has issued new upstream versions since then.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Cherry-picking commit edb4b8adc2447bc04e05b9b908195a4bc7926242 from upstream,
which uses a random UUID instead of the hash of some fixed address in order to
define the DB file name.
Thanks for your help,
Best,
--
Pierre
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog
xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog 2023-02-04
14:24:45.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/changelog 2023-06-13
23:19:59.0 +0200
@@ -1,3 +1,9 @@
+xerial-sqlite-jdbc (3.40.1.0+dfsg-1+deb12u1) bookworm; urgency=medium
+
+ * Using a random UUID for the connection (Fixes CVE-2023-32697 in Bookworm)
+
+ -- Pierre Gruet Tue, 13 Jun 2023 23:19:59 +0200
+
xerial-sqlite-jdbc (3.40.1.0+dfsg-1) unstable; urgency=medium
* New upstream version 3.40.1.0+dfsg
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
1970-01-01 01:00:00.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/CVE-2023-32697.patch
2023-06-13 23:17:23.0 +0200
@@ -0,0 +1,28 @@
+Description: fixing CVE-2023-32697
+Author: Pierre Gruet
+Origin: upstream,
https://github.com/xerial/sqlite-jdbc/commit/edb4b8adc2447bc04e05b9b908195a4bc7926242
+Bug:
https://github.com/xerial/sqlite-jdbc/security/advisories/GHSA-6phf-6h5g-97j2
+Bug-Debian: https://bugs.debian.org/1036706
+Forwarded: not-needed
+Applied-Upstream: edb4b8adc2447bc04e05b9b908195a4bc7926242
+Last-Update: 2023-06-13
+
+--- a/src/main/java/org/sqlite/SQLiteConnection.java
b/src/main/java/org/sqlite/SQLiteConnection.java
+@@ -13,6 +13,7 @@
+ import java.sql.ResultSet;
+ import java.sql.SQLException;
+ import java.util.Properties;
++import java.util.UUID;
+ import java.util.concurrent.Executor;
+ import org.sqlite.SQLiteConfig.TransactionMode;
+ import org.sqlite.core.CoreDatabaseMetaData;
+@@ -303,7 +304,7 @@
+ }
+
+ String tempFolder = new
File(System.getProperty("java.io.tmpdir")).getAbsolutePath();
+-String dbFileName = String.format("sqlite-jdbc-tmp-%d.db",
resourceAddr.hashCode());
++String dbFileName = String.format("sqlite-jdbc-tmp-%s.db",
UUID.randomUUID());
+ File dbFile = new File(tempFolder, dbFileName);
+
+ if (dbFile.exists()) {
diff -Nru xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series
xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series
--- xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series 2023-02-02
17:16:53.0 +0100
+++ xerial-sqlite-jdbc-3.40.1.0+dfsg/debian/patches/series 2023-06-13
23:10:58.0 +0200
@@ -7,3 +7,4 @@
skip_OSInfoTest.patch
tests_without_archunit-junit5_and_some_assertions.patch
junit-jupiter-params_artifact.patch
+CVE-2023-32697.patch
Bug#1037200: please consider backporting valijson to Bullseye
Control: block -1 by 1037212 Hello, Le 07/06/2023 à 20:34, Dima Kogan a écrit : Hi. I'll gladly accept help on this. If you can do this yourself, that would be great! Thanks Thanks for your quick answer; fine then, I will do so :) I could build it in a Bullseye chroot by having also picojson backported, I will ask its maintainer as well, and proceed afterwards. Best wishes, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1037212: Please consider backporting picojson to Bullseye
Source: picojson Severity: wishlist Dear Maintainer, I would be interested in having picojson backported to Bullseye, for myself but also for people working with me. If you want, I would be pleased to do it for you (I am a DD). Best, -- Pierre
Bug#1037200: please consider backporting valijson to Bullseye
Source: valijson Severity: wishlist Dear Maintainer, I would be interested in having a backport of valijson in Bullseye, not only for me but also for other users I know. I would happily do it myself if you wish (I am a DD). Best wishes, -- Pierre
Bug#712781: src:scilab: please use SLICOT Debian package instead of embedded copy
Control: forwarded -1 https://gitlab.com/scilab/scilab/-/issues/13151 Control: tags -1 - moreinfo Hi Sébastien, Le 28/05/2023 à 17:46, Sébastien Villemot a écrit : Hi Pierre, [...] The Debian package src:slicot contains a pre-release of version 5.0 of Slicot, which was the last version distributed by upstream under the GPL (later versions are proprietary). However at some point upstream changed their mind and decided to stop distributing the 5.0 release under the GPL, so they removed it from their website. The website now has only has version 4.5 under the GPL. We kept 5.0 in Debian because there is nothing that prevents us from doing so from a legal point of view. Other projects (e.g. the “control” package for Octave) do the same. But it looks like the version of Slicot embedded in Scilab is even older than 4.5, and corresponds to version 4.0. My guess is that the missing symbols that you get correspond to functions that were removed between 4.0 and 5.0. Unfortunately this probably means that fixing the present bug requires more work than just patching the build system (i.e. Scilab upstream needs to move to a more recent Slicot). Thanks a lot for your help on understand the issue. Admittedly there is quite a lot of work to do here :) I am updating the Forwarded-to URI, this issue is still open upstream. Best wishes, Same to you, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1037155: misses dependency on libboost-json1.81-dev
Package: libboost1.81-all-dev Version: 1.81.0-5 Severity: normal Dear Maintainer, The version of libboost1.81-all-dev currently in unstable and testing does not depend on one of the -dev packages, namely libboost-json1.81-dev, although it should. Best regards, -- Pierre
Bug#808839: How does it affect scilab?
Control: affects -1 - src:scilab Hi Julien, On Thu, 30 Apr 2020 09:41:03 +0200 Julien Puydt wrote: > Hi, > > can I know how it affects scilab? It does not affect scilab, at least not anymore! This can be seen in the version of scilab currently in experimental: 6.1.1+dfsg2-7~exp0. The various examples in the "Math rendering in Scilab graphics" page of help can all be run (there are only some issues with mathml, but there is Bug #1036872 for it). > > Cheers, > > JP > Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1036872: net.sourceforge.jeuclid.MathMLParserSupport fails to parse XML strings
Package: libjeuclid-core-java
Version: 3.1.9-5
Severity: normal
Dear Maintainer,
While running scilab, I met an issue with MathML labels for axes, that were not
showing up. After digging into this, I saw this was a bug in
libjeuclid-core-java and I built the following minimal non-working example:
8<--
import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import org.xml.sax.SAXException;
import net.sourceforge.jeuclid.MathMLParserSupport;
public class Main {
public static void main(String[] args) throws IOException,
ParserConfigurationException, SAXException {
String str = new
String("dydx=1y2");
System.out.println(MathMLParserSupport.parseString(str));
}
}
8<--
The output is:
8<--
[#document: null]
8<--
Thanks a lot for your help on this,
Cheers,
--
Pierre
- System Information:
Debian Release: 12.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing'), (90, 'unstable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libjeuclid-core-java depends on:
ii libbatik-java1.16+dfsg-1
ii libcommons-logging-java 1.2-3
ii libxmlgraphics-commons-java 2.8-2
libjeuclid-core-java recommends no packages.
libjeuclid-core-java suggests no packages.
-- no debconf information
Bug#1035959: unblock: jmol/14.32.83+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: j...@packages.debian.org Control: affects -1 + src:jmol Dear Release Team, I would like to ask for an unblock of package jmol. [ Reason ] I fixed RC bug #1035484 which was just a dangling symlink causing piuparts errors. This was done by removing a line in debian/jmol.links. [ Impact ] No impact for the user, only piuparts is affected. [ Tests ] I did no test as I only removed a symlink, of which target has not been in the package for many months. [ Risks ] No risk, as no rdep is using the deleted symlink. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing [ Other info ] If the unblock is not granted, the users won't notice anything as there would only be a void symlink shipped in the package. I would also be fine with it. Thanks a lot in any case, -- Pierre unblock jmol/14.32.83+dfsg-1 diff -Nru jmol-14.32.83+dfsg/debian/changelog jmol-14.32.83+dfsg/debian/changelog --- jmol-14.32.83+dfsg/debian/changelog 2023-02-02 16:43:13.0 +0100 +++ jmol-14.32.83+dfsg/debian/changelog 2023-05-04 14:24:33.0 +0200 @@ -1,3 +1,10 @@ +jmol (14.32.83+dfsg-2) unstable; urgency=medium + + * Removing symlink to non-existing /usr/share/java/JSpecView.jar +(Closes: #1035484) + + -- Pierre Gruet Thu, 04 May 2023 14:24:33 +0200 + jmol (14.32.83+dfsg-1) unstable; urgency=medium * New upstream version 14.32.83+dfsg diff -Nru jmol-14.32.83+dfsg/debian/jmol.links jmol-14.32.83+dfsg/debian/jmol.links --- jmol-14.32.83+dfsg/debian/jmol.links2022-10-15 22:47:37.0 +0200 +++ jmol-14.32.83+dfsg/debian/jmol.links2023-05-04 14:23:08.0 +0200 @@ -1,6 +1,5 @@ /usr/share/jmol/icon.png/usr/share/pixmaps/jmol-icon.png /usr/share/java/Jmol.jar/usr/share/jmol/Jmol.jar /usr/share/java/JmolData.jar/usr/share/jmol/JmolData.jar -/usr/share/java/JSpecView.jar /usr/share/jmol/JSpecView.jar /usr/share/java/Jvxl.jar/usr/share/jmol/Jvxl.jar /usr/bin/jmol /usr/share/jmol/jmol
Bug#1034757: unblock (pre-approval): scilab/6.1.1+dfsg2-5 libjogl2-java/2.3.2+dfsg-10 gluegen2/2.3.2-9
Control: tags -1 - moreinfo
Hi Paul,
Le 27/04/2023 à 11:38, Paul Gevers a écrit :
Control: tags -1 moreinfo
Hi Pierre,
On Sun, 23 Apr 2023 17:27:30 +0200 Pierre Gruet wrote:
This unblock would lead to new upstream versions (with some packaging
work more
complex than just refreshing patches) of gluegen2 and libjogl2 shipped
into
Bookworm, which I trust to be OK as they have only one rdep, king,
which works
well with them.
Are targeted fixes an option? We're well past new upstreams being
acceptable [1] unless they are targeted fixes themselves.
Thanks for looking at my proposal. I understand well this is not
feasible as is. Indeed the fixes I proposed are quite important as they
require a new upstream version of 2 packages. Also, working around RC
bug #1034752 in src:gluegen2 requires quite a lot of Debian-specific
changes.
So I now propose to do something simpler, in order to have Scilab be
able to start and work plainly except for plotting (which was also the
case in Bullseye anyway), fixing RC bug #1033496.
In order to get a pre-approval, I only did the change locally (source
debdiff attached), will upload to unstable if granted.
Below is my proposal:
[ Reason ]
Currently, the key package scilab/6.1.1+dfsg2-5 in sid/testing does not
start since we have openjdk-17 as default Java machine, see grave bug
#1033496: it is unusable right now.
[ Impact ]
If the unblock is not granted, scilab will remain unusable in Bookworm.
If it is granted, then it will be working except for plotting.
[ Tests ]
I changed one line in the source, built it in a clean chroot, installed
in on my machine running Bookworm and could use all of Scilab features
(plotting aside).
[ Risks ]
No risk, as we would not change the biinaries but only the shell wrapper
that invokes them with the correct environment variables.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes (did them myself) and I approve them
[X] attach debdiffs of the locally built package against the package
in testing
Paul
PS: your message didn't reach our list, which is a bad sign about the
size of the changes.
That's right...!
Best,
--
Pierre
diff -Nru scilab-6.1.1+dfsg2/debian/changelog scilab-6.1.1+dfsg2/debian/changelog
--- scilab-6.1.1+dfsg2/debian/changelog 2023-03-11 16:23:07.0 +0100
+++ scilab-6.1.1+dfsg2/debian/changelog 2023-04-27 12:37:49.0 +0200
@@ -1,3 +1,11 @@
+scilab (6.1.1+dfsg2-6) UNRELEASED; urgency=medium
+
+ * Team upload
+ * Adding another --add-opens clause to the scilab invocation to avoid the
+Exception at GUI start (Closes: #1033496)
+
+ -- Pierre Gruet Thu, 27 Apr 2023 12:37:49 +0200
+
scilab (6.1.1+dfsg2-5) unstable; urgency=medium
* Team upload
diff -Nru scilab-6.1.1+dfsg2/debian/patches/populating_java_options_by_default.patch scilab-6.1.1+dfsg2/debian/patches/populating_java_options_by_default.patch
--- scilab-6.1.1+dfsg2/debian/patches/populating_java_options_by_default.patch 2023-03-11 14:13:54.0 +0100
+++ scilab-6.1.1+dfsg2/debian/patches/populating_java_options_by_default.patch 2023-04-27 12:36:03.0 +0200
@@ -14,7 +14,7 @@
+# We initialize _JAVA_OPTIONS so that the right paths are looked into and we
+# add the needed --add-opens to work with OpenJDK 17.
+if ! echo "${_JAVA_OPTIONS}" | grep -q "java\.library\.path" ; then
-+_JAVA_OPTIONS="${_JAVA_OPTIONS} -Djava.library.path=/usr/lib/jni:/usr/lib/scilab --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED --add-opens=java.desktop/sun.java2d.opengl=ALL-UNNAMED"
++_JAVA_OPTIONS="${_JAVA_OPTIONS} -Djava.library.path=/usr/lib/jni:/usr/lib/scilab --add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED --add-opens=java.desktop/sun.java2d.opengl=ALL-UNNAMED --add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED"
+fi
+
if test ! -z "$SCIVERBOSE"; then
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1034752: embeds non-free headers
Source: gluegen2 Version: 2.3.2-9 Severity: serious Tags: fixed-in-experimental Dear Maintainer, Non-free header files are present in the source of gluegen2, see for instance in make/stub_includes/jni/jni.h: * Copyright 2006 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. Removing these headers and using these of the jdk instead requires some extra work in the rdep libjogl2-java, but it is done in experimental. Best, -- Pierre
Bug#1034716: the count of processes on hold for an AM is not decreased when a process on hold is closed
Package: nm.debian.org Severity: normal Hello, When an application manager puts an application on hold, the number of processes on hold on https://nm.debian.org/public/managers/ increases by one unit for this AM, fine. Now, if this process is closed, I trust the "on hold" counter for the AM should decrease by one unit, which is not the case. As of today, for instance, AM pgt appears as having 1 process on hold on https://nm.debian.org/public/managers/ although this is not the case, he was an AM for a process on hold that got closed afterwards. Thanks, -- Pierre
Bug#959732: Reassigning to libjogl2-java
Control: reassign -1 libjogl2-java Control: merge 1006532 -1 Hello, This is a bug in libjogl2-java, which is fixed in libjogl2-java/2.4.0+dfsg-1~exp1 currently in experimental. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1006532: libjogl2-java: Profile GL4bc is not available on X11GraphicsDevice
Control: tags -1 fixed-in-experimental Control: fixed -1 2.4.0+dfsg-1~exp1 Hello, This bug should not show up anymore with the version 2.4.0+dfsg-1~exp1 currently in experimental. As we are in the freeze process for Bookworm, one should wait the release happens as scilab also needs to be rebuilt agaings this new jogl2 version. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1006532: libjogl2-java: Profile GL4bc is not available on X11GraphicsDevice
Control: affects -1 + scilab Hi, Such error message also shows up in the debug logs when one tries to plot something using scilab. I did a quick-and-dirty try and I think version 2.4.0 of jogl2 fixes this. Anyway, I will tweak it in experimental shortly to figure it out. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1032855: unblock: scilab/6.1.1+dfsg2-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sci...@packages.debian.org Control: affects -1 + src:scilab Dear Release Team, Could you please unblock the key package scilab/6.1.1+dfsg2-5? [ Reason ] - scilab/6.1.1+dfsg2-4 is absolutely unusable as it cannot even start. - It FTBFS. - It looks for versioned artifacts so it breaks everytime a dependency is updated. [ Impact ] Staying with version 6.1.1+dfsg2-4 does not allow one to use scilab even in the naked CLI flavor. [ Tests ] I installed the version 6.1.1+dfsg2-5 on a Bookworm system: - scilab-cli and scilab-adv-cli work plainly, except for plots (bugs in dependencies); - the GUI scilab does not work. Blockers: bugs in dependency libjogl2-java and others still to investigate, as log messages are terse. [ Risks ] The changes are simple, can be easily grasped through the documented patches I added. scilab has only one reverse dependency which is not a Blends metapackage: cantor-backend-scilab, which is already broken as scilab/6.1.1+dfsg2-4 does not start. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing unblock scilab/6.1.1+dfsg2-5 Best, -- Pierre diff -Nru scilab-6.1.1+dfsg2/debian/changelog scilab-6.1.1+dfsg2/debian/changelog --- scilab-6.1.1+dfsg2/debian/changelog 2022-08-16 11:55:44.0 +0200 +++ scilab-6.1.1+dfsg2/debian/changelog 2023-03-11 16:23:07.0 +0100 @@ -1,3 +1,25 @@ +scilab (6.1.1+dfsg2-5) unstable; urgency=medium + + * Team upload + * Raising Standards version to 4.6.2 (no change) + * Adding missing dependencies on libfreehep-graphicsio-java and +libfreehep-util-java + * Fixing the FTBFS occurring during the doc build + * Enabling starting with OpenJDK 17 (Closes: #1012099) + * Selecting unversioned jars instead of versioned ones in the configure phase +(Closes: #1030205) + * Refreshing patches + * Removing unneeded older-than versioned dependencies + * Update lintian override info to new format: ++ debian/source/lintian-overrides: line 2, 4 ++ debian/scilab-minimal-bin.lintian-overrides: line 4 + * debian/copyright: use spaces rather than tabs to start continuation lines. + * Update renamed lintian tag names in lintian overrides. + * Set upstream metadata fields: Repository-Browse. + * Fix day-of-week for changelog entry 5.0.3-1. + + -- Pierre Gruet Sat, 11 Mar 2023 16:23:07 +0100 + scilab (6.1.1+dfsg2-4) unstable; urgency=medium * Add patch to disambiguate pause (Closes: #1017283). @@ -1348,7 +1370,7 @@ * Package moved to main since Scilab is free (CeCILL license) * modelicac, intersci and scilab manpages added - -- Sylvestre Ledru Fri, 1 Oct 2008 13:37:08 +0200 + -- Sylvestre Ledru Wed, 01 Oct 2008 13:37:08 +0200 scilab (4.1.2-6) unstable; urgency=low diff -Nru scilab-6.1.1+dfsg2/debian/control scilab-6.1.1+dfsg2/debian/control --- scilab-6.1.1+dfsg2/debian/control 2022-08-16 11:55:44.0 +0200 +++ scilab-6.1.1+dfsg2/debian/control 2023-03-10 23:21:05.0 +0100 @@ -3,38 +3,36 @@ Priority: optional Maintainer: Debian Science Team Uploaders: Julien Puydt -Build-Depends: debhelper-compat (= 13), gfortran, time, - default-jdk, chrpath, ocaml-nox (>= 3.11.2-3), libnum-ocaml-dev, fakeroot, - tcl-dev, tk-dev, libxml2-dev, libpcre3-dev, libcurl4-openssl-dev, - gettext, libreadline-dev, pkg-config, procps, dpkg-dev (>= 1.16.0), +Build-Depends: debhelper-compat (= 13), gfortran, time, default-jdk, chrpath, + ocaml-nox, libnum-ocaml-dev, fakeroot, tcl-dev, tk-dev, libxml2-dev, + libpcre3-dev, libcurl4-openssl-dev, gettext, libreadline-dev, pkg-config, + procps, dpkg-dev, # numerical libraries libblas-dev | librefblas3-dev | libatlas-base-dev, liblapack-dev, - libarpack2-dev (>= 3.0), libeigen3-dev, + libarpack2-dev, libeigen3-dev, # Java deps - default-jre-headless, libflexdock-java (>= 1.2.3), libjogl2-java (>= 2.3.2), - libgl1-mesa-dev, libjrosetta-java (>= 1.0.1), ant, libjgoodies-looks-java, - libskinlf-java, liblucene4.10-java, libactivation-java, libjaxb-java, + default-jre-headless, libflexdock-java, libjogl2-java, libgl1-mesa-dev, + libjrosetta-java, ant, libjgoodies-looks-java, libskinlf-java, + liblucene4.10-java, libactivation-java, libjaxb-java, # graphic - libfreehep-graphics2d-java, libfreehep-graphicsio-java, libfreehep-graphicsio-emf-java, - libfreehep-util-java, + libfreehep-graphics2d-java, libfreehep-graphicsio-java, + libfreehep-graphicsio-emf-java, libfreehep-util-java, # Documentation - libjeuclid-core-java (>= 3.1.3), libbatik-java (>= 1.7), fop (>= 0.95), - javahelp2, libsaxon-java, libavalon-framework-java, docbook-xsl, - libxml-commons-external-java, + libjeuclid-core-java, libbatik-java, fop, javahelp2, libsaxon-java, + libavalon-framework-java, docbook-xsl, libxml-commons-external-java,
Bug#1011549: openrocket needs newer jogl
Hi tony, On Sun, 12 Feb 2023 10:15:35 -0800 tony mancill wrote: > > Okay, first the good news. There are upstream tags for 2.4.0. I have > started working on adapting the sequence of debian/patches against the > new release. > > But in addition to not yet being done with that, it didn't seem prudent > to try to push this into bookwork at the last minute, and that wouldn't > have given the reverse dependencies any time to react anyway. So I am > going to work towards an upload to experimental soon, and then we can > aim for getting this into unstable/testing after the freeze. I fully understand your position. However I recently looked at scilab, a rdep of jogl, and saw it is severely broken -- although a key package, so it will be shipped in Bookworm anyway. Scilab cannot be run in GUI mode, only in command-line mode with plots not working (after some tweaking I am working on). Locally I tried to update jogl to version 2.4.0 (I had not seen you were working on it, sorry), and to do so I also had to update its dependency gluegen2 to version 2.4.0 (possibly you have already seen it), and then the command-line mode would allow one to make plots. Given the Hard freeze begins in two days, I will only touch scilab and not jogl nor gluegen2 right now. It you want, I can upload my changes to gluegen2 and jogl2 to experimental in the upcoming days. But if you prefer doing it yourself, please tell me and do so when you are ready :) Warm regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1031123: reply: Bug#1031123: RFS: libcommons-collections4-java/4.4-1 [Team] -- Apache Commons Collections - Extended Collections API for Java
Hi min sun, Le 20/02/2023 à 04:23, min sun a écrit : Hi, Pierre Gruet: Thanks for your kind advice. And thanks for your work on this package! I have just uploaded as is to experimental. I will try to remember uploading it to unstable after the release of Bookworm, but please drop an email if I fail to do so. I think it is really fine to care for this package now, but as we are in the soft freeze period, I would upload to experimental: I used japi-compliance-checker to see the differences between the jars in version 4.2-1 and in (your candidate) 4.4-1, and there has been a small number of (upstream) return types changes. The number of reverse-dependencies is too large to be tested with ratt at home. All the warnings are solved and please see Upload #3. But for the ratt, it’s really a headache for me too. Could I leave it for the Debian CI ? Definitely we won't handle this individually with ratt. Still, within a few hours the package will be installed in experimental so it is feasible to manually rebuild the direct (i.e. non transitive) reverse-dependencies while adding the experimental repository. Please tell me if there are any issues still need to be fixed. Best ! Thanks again, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1031123: RFS: libcommons-collections4-java/4.4-1 [Team] -- Apache Commons Collections - Extended Collections API for Java
Hello min sun, Le 13/02/2023 à 10:27, min sun a écrit : Hi, Hilmar Preuße, and tony: Thanks for you guide! I will keep the distribution tag "UNRELEASED" as it is for the sponsor. which I also support. Some teams have put such practice in their policies, like in https://science-team.pages.debian.net/policy/#idm56 The debian/watch was modified to direct to apache archive site ,because: 1.Tag names from github are not well defined[1]. 2.Some github release even introduces nonexisted files[2]. I think the apache site will do a little more strict check before archiving. I uploaded again, please refer to mentors.debian.(Upload #2.) I have just had a look. I am almost ready to upload, I just ask you to address the following, which can be read on [3]: - insecure-copyright-format-uri - silent-on-rules-requiring-root (add the related line in debian/control) - uses-debhelper-compat-file (i.e. drop debian/compat and depend on debhelper-compat (= 13) instead) - also you could really drop debian/README.source and debian/maven.cleanIgnoreRules [1]https://github.com/apache/commons-collections/tags [2]https://lists.debian.org/debian-java/2023/01/msg00029.html [3]https://mentors.debian.net/package/libcommons-collections4-java/ I think it is really fine to care for this package now, but as we are in the soft freeze period, I would upload to experimental: I used japi-compliance-checker to see the differences between the jars in version 4.2-1 and in (your candidate) 4.4-1, and there has been a small number of (upstream) return types changes. The number of reverse-dependencies is too large to be tested with ratt at home. Tell us/me once you are done. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1030445: Reassigning to biojava6-live
Control: reassign -1 biojava6-live Hello, This is a bug in biojava6-live which makes its biojava-structure artifact require unneeded log4j jars. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1030430: Reassigning to biojava6-live
Control: reassign -1 biojava6-live Hello, This is a bug in biojava6-live which makes its biojava-structure artifact require unneeded log4j jars. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1029186: RFS: libcommons-validator-java/1:1.7-1 [Team] -- ease and speed development and maintenance of validation rules
Control: tags -1 moreinfo Hi, On Thu, 19 Jan 2023 07:44:05 + min sun wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "libcommons-validator-java": > > * Package name : libcommons-validator-java > Version : 1:1.7-1 > Upstream contact : http://commons.apache.org/validator/ > * URL : https://commons.apache.org/proper/commons-validator/ > * License : Apache-2.0 > * Vcs : https://salsa.debian.org/java-team/libcommons-validator-java > Section : java > > The source builds the following binary packages: > > libcommons-validator-java - ease and speed development and maintenance of validation rules > libcommons-validator-java-doc - API documentation for Commons Validator > > To access further information about this package, please visit the following URL: > > https://mentors.debian.net/package/libcommons-validator-java/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x https://mentors.debian.net/debian/pool/main/libc/libcommons-validator-java/libcommons-validator-java_1.7-1.dsc > > Changes since the last upload: > > libcommons-validator-java (1:1.7-1) UNRELEASED; urgency=medium > . > * Team upload. > * New upstream release. > * Add commons-csv-java as new dependency. > * Skip running the tests. > There seems to be something wrong at the tip of the master branch, as it contains files (e.g. PROPOSAL.html) which are not in the upstream tarball I get by running uscan from the source dir. Could you please fix it? Also I see there was no commit on the pristine-tar branch related to this new version, please handle the relevant pristine-tar option when using git-buildpackage. > > This new version needs a test dependency called junit-clptr which is not ported to debian currently, I don’t know how to handle this issue and just ignore it,and have to skip the test. > > I tried to enable the test and build locally with bellow command: > dpkg-buildpackage -us -uc > > The test results shows that : > > [WARNING] Tests run: 25, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.025 s - in org.apache.commons.validator.routines.EmailValidatorTest > > [WARNING] Tests run: 576, Failures: 0, Errors: 0, Skipped: 1 > > I think it is harmless to disable the test for now. It is fine to ignore the tests that need junit-clptr (which is the case only in one class as I can see), but if I understand correctly what you write, all other tests are successful? If so, one should only skip the problematic class by patching pom.xml (see third answer in [0] with the maven-surefire-plugin configuration) instead of skipping all the tests. Also keep what you changed in debian/maven.ignoreRules, that's OK. > > I’m not familiar with java packaging and any suggestion or advice is welcome. I hope this helps :) > > Regards, > -- > sun min > Cheers, -- Pierre [0] https://stackoverflow.com/questions/835705/is-there-a-way-to-skip-only-a-single-test-in-maven OpenPGP_signature Description: OpenPGP digital signature
Bug#1027277: ITP: glgrib -- geophysical GRIB2-encoded fields displayer using OpenGL
Package: wnpp Severity: wishlist Owner: Pierre Gruet User: debian-scie...@lists.debian.org Usertags: field..geography X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: glgrib Version : 1.0.0 Upstream Contact: Philippe Marguinaud * URL : https://github.com/pmarguinaud/glgrib * License : GPL-3 Programming Lang: C++ Description : geophysical GRIB2-encoded fields displayer using OpenGL This is an interactive executable, based on GLFW, displaying GRIB2 fields with OpenGL. It offers a GLFW backend for interactive display or an EGL backend for batch processing without X11 display. The interface is written in Perl/Tk. This software is packaged as an useful geographical data visualization tool, comfortable and eye-appealing. We plan to maintain it under the Debian-science team umbrella.
Bug#1026666: Please make liblog4j2-java depend on junit5
Hi again tony, Le 22/12/2022 à 16:16, tony mancill a écrit : Hi Pierre, On Thu, Dec 22, 2022 at 07:31:30AM +0100, Pierre Gruet wrote: Hi tony, Le 21/12/2022 à 22:58, tony mancill a écrit : On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote: Control: retitle -1 Please make liblog4j2-java depend on junit5 Hello, In version 2.19.0-1 of liblog4j2-java, the file /usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom declares the junit-bom artifact as a dependency. It is shipped in junit5. If this dependency is not added, reverse dependencies of liglog4j2-java fail to build (see logs above) as the junit-bom artifact is not found. Hi Pierre, I'm wondering if it wouldn't better to remove junit-bom from log4j pom. I don't believe we actually need junit5 at runtime for log4j2, so packages depending on liblog4j2-java should not have to install junit5. Any concerns with taking that approach and addressing the bug by adjusting the pom shipped with liblog4j2-java? Thanks for having a look; I haven't looked further but I also fail to imagine why junit5 would be needed, so I agree with the proposed fix! I am spot-checking a few of the reverse dependencies now and will upload today. Thank you for identifying the root cause for this set of build failures. Glad I could help! THanks for taking care of the fix. If I may help in any way, please tell me :) Cheers, tony Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1026666: Please make liblog4j2-java depend on junit5
Hi tony, Le 21/12/2022 à 22:58, tony mancill a écrit : On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote: Control: retitle -1 Please make liblog4j2-java depend on junit5 Hello, In version 2.19.0-1 of liblog4j2-java, the file /usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom declares the junit-bom artifact as a dependency. It is shipped in junit5. If this dependency is not added, reverse dependencies of liglog4j2-java fail to build (see logs above) as the junit-bom artifact is not found. Hi Pierre, I'm wondering if it wouldn't better to remove junit-bom from log4j pom. I don't believe we actually need junit5 at runtime for log4j2, so packages depending on liblog4j2-java should not have to install junit5. Any concerns with taking that approach and addressing the bug by adjusting the pom shipped with liblog4j2-java? Thanks for having a look; I haven't looked further but I also fail to imagine why junit5 would be needed, so I agree with the proposed fix! Thanks, tony Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1026666: Please make liblog4j2-java depend on junit5
Control: retitle -1 Please make liblog4j2-java depend on junit5 Hello, In version 2.19.0-1 of liblog4j2-java, the file /usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom declares the junit-bom artifact as a dependency. It is shipped in junit5. If this dependency is not added, reverse dependencies of liglog4j2-java fail to build (see logs above) as the junit-bom artifact is not found. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1025830: beauti2 fails to start
Control: tags -1 help Hello, I tried to investigate further, I feel a window should appear and the action of the user is expected, yet I don't see anything except the initial "Initializing BEAUti..." GUI. My knowledge of jdb did not allow me to understand further what is going on. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1025953: Reassigning to libhmsbeagle
Control: reassign -1 libhmsbeagle 3.1.2+dfsg-12 Control: affects -1 beast-mcmc beast2-mcmc Control: tags -1 pending Hi, Thanks to Remco Bouckaert, the author of beast2, I could find the issue is in libhmsbeagle. Passing --without-opencl to the configure step of libhmsbeagle allows one to avoid errors such as the one you reported. This change does not seem to affect the other reverse dependency of libhmsbeagle, so I am endorsing it. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1026131: Merging and marking as closed
Control: forcemerge 1025838 -1 Hello, This is the same as #1025838, which version 1.11.9+dfsg-3 properly closes. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1025953: beast-mcmc: only usable with OpenCL
Control: forwarded -1 https://github.com/CompEvol/beast2/issues/1069 Hi, Le 12/12/2022 à 17:08, Andreas Tille a écrit : Hi Andrius, Am Mon, Dec 12, 2022 at 04:06:40PM +0200 schrieb Andrius Merkys: When launched on a system without OpenCL, beast-mcmc executable dies: $ beast-mcmc -help OpenCL error: CL_DEVICE_NOT_FOUND from file , line 122. From a quick glance this seems to be happening due to beast-mcmc using OpenCL version of libhmsbeagle1v5 (the line cited in the error message is in libhmsbeagle source). However, beast-mcmc seems to support CLI options to switch to libhmsbeagle1v5 CPU instance (see 'beagle_CPU' in src/dr/app/beast/BeastMain.java). Maybe it is possible to make CPU mode the default to avoid loading OpenCL-dependent libraries. Thanks a lot for the hint. I've tried -beagle_CPU which fails and even -beagle_off[1] which fails as well[2]. Any hint would be welcome It turns out I am meeting the same issue on beast2-mcmc (although not when typing only $ beast2-mcmc -help) and I am currently in touch with upstream for some packaging issues. I just opened the issue referenced on top of this email to get some help, which will also help for beast-mcmc. Andreas. [1] https://salsa.debian.org/med-team/beast-mcmc/-/blob/master/debian/tests/run-unit-test#L12-13 [2] https://salsa.debian.org/med-team/beast-mcmc/-/jobs/3648046#L367 Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1025894: breaks the autopkgtest of nipype
Source: python3-nibabel Version: 4.0.2-1 Severity: serious Hi, It seems the module nibabel.trackvis is not shipped anymore with nibabel 4.0.2, which breaks the autopkgtest of nipype. See for instance https://ci.debian.net/packages/n/nipype/testing/amd64/ Cheers, -- Pierre
Bug#1025830: beauti2 fails to start
Package: beast2-mcmc Version: 2.7.2+dfsg-1 Severity: important Hi, When launching $ beauti2 I get the exception message discussed in bug #1025829, then a window from the beast package manager, then the program terminates. In the console I have Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:261) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) ... 1 more java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at beast.pkgmgmt.launcher.BeastLauncher.run(Unknown Source) at beast.pkgmgmt.launcher.BeautiLauncher.main(Unknown Source) Caused by: java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:273) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) at java.base/java.lang.Thread.run(Thread.java:833) so probably there is an issue when loading openjfx. I whall investigate shortly but nevertheless drop this bug so that it does not get forgotten. Cheers, -- Pierre -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages beast2-mcmc depends on: ii default-jre 2:1.17-73 ii libantlr4-runtime-java 4.7.2-5 ii libcolt-free-java 1.2.0+dfsg-7 ii libhmsbeagle-java 3.1.2+dfsg-12+b1 ii libopenjfx-java 11.0.11+0-1.1 ii openjfx 11.0.11+0-1.1 beast2-mcmc recommends no packages. beast2-mcmc suggests no packages. -- no debconf information
Bug#1025829: prints an exception message at startup
Package: beast2-mcmc Version: 2.7.2+dfsg-1 Severity: normal Hi, When launching $ beast2-mcmc I get an exception message java.lang.NullPointerException: Cannot invoke "java.io.InputStream.close()" because "" is null at beast.pkgmgmt.launcher.BeastLauncher.copyFileUsingStream(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.createBeastPackage(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.installBEASTPackage(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.getPath(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.main(Unknown Source) java.lang.NullPointerException: Cannot invoke "java.io.InputStream.close()" because "" is null at beast.pkgmgmt.launcher.BeastLauncher.copyFileUsingStream(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.createBeastPackage(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.installBEASTPackage(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.getPath(Unknown Source) at beast.pkgmgmt.launcher.BeastLauncher.main(Unknown Source) There is an ongoing discussion in https://github.com/CompEvol/beast2/issues/1060 but I guess the issue is on the Debian packaging side. I shall look at it soon but nevertheless drop this bug so that it does not get forgotten. Cheers, -- Pierre -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages beast2-mcmc depends on: ii default-jre 2:1.17-73 ii libantlr4-runtime-java 4.7.2-5 ii libcolt-free-java 1.2.0+dfsg-7 ii libhmsbeagle-java 3.1.2+dfsg-12+b1 ii libopenjfx-java 11.0.11+0-1.1 ii openjfx 11.0.11+0-1.1 beast2-mcmc recommends no packages. beast2-mcmc suggests no packages. -- no debconf information
Bug#765906: ITP: coinor-bonmin -- mixed-integer nonlinear optimization solver
Control: retitle -1 ITP: coinor-bonmin -- mixed-integer nonlinear optimization solver Control: owner -1 ! Hi, I am willing to package bonmin as it is a (optional) dependency of openturns, which I maintain. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1024675: transition: openturns
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I would like to do the transition of openturns due to ABI changes. The new version is in experimental and builds on all relevant architectures. There is one rdep, persalys, which also builds well. The autogenerated ben file is fine. So I am ready to proceed when you tell me. Cheers, -- Pierre Gruet
Bug#1024039: Current default JDK should be updated in Lintian
Package: lintian Version: 2.115.3 Severity: normal Dear Maintainer, Recently, java-common was updated in unstable and then in testing, it changes the default JDK in Debian from OpenJDK11 to OpenJDK17. Thus I think the line 21 in data/java/constants should be changed from default-bytecode-version = 56 to default-bytecode-version = 61 in order to avoid warnings like --8<-- W: beast2-mcmc: incompatible-java-bytecode-format Java17 version (Class format: 61) N: N: The package contains Java class files with a minimum requirement on the N: listed Java version. This Java version is not supported by the default JVM N: in Debian and is therefore likely to be a mistake. N: N: Please refer to Bug#673276 for details. N: N: Visibility: warning N: Show-Always: no N: Check: languages/java N: --8<-- which I got with beast2-mcmc 2.7.1+dfsg-1. The package was successfully built using OpenJDK17 and is now in unstable. I also just got a similar warning with libjgraph-java, which should hit unstable within a couple of hours. Thanks for all the work on Lintian! Cheers, -- Pierre
Bug#1023948: transition: hmat-oss
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release team, There is a need for a transition of hmat-oss after a change in the ABI. The new package has been uploaded to experimental and can build on all architectures, either on buildds or on porterboxes. Thus I am asking for a transition slot. There are two reverse dependencies, of which I am also the uploader: openturns and persalys. They can also build against the new hmat-oss package. Finally, the Ben file at https://release.debian.org/transitions/html/auto-hmat-oss.html is fine. Cheers, -- Pierre
Bug#1012093: ciftools-java: FTBFS with OpenJDK 17 due to test failures
Source: ciftools-java Version: 4.0.3-1 Control: tags -1 pending After discussing with upstream on the issue the present bug was reported to, it appears the issue is innocuous and I am going to upload the package with the fix they suggested. Cheers, -- Pierre
Bug#1012093: ciftools-java: FTBFS with OpenJDK 17 due to test failures
Source: ciftools-java Version: 4.0.3-1 Followup-For: Bug #1012093 X-Debbugs-Cc: mer...@debian.org Control: forwarded -1 https://github.com/rcsb/ciftools-java/issues/12 Hello, I investigated the test failure a bit and saw tiny differences between a generated gzip file and a reference one. This reminded me of one similar and innocuous issue [0] so that I filled an issue upstream [1]. Let's see. Best, -- Pierre [0] https://github.com/broadinstitute/picard/issues/1840 [1] https://github.com/rcsb/ciftools-java/issues/12
Bug#1012106: libreflectasm-java: FTBFS with OpenJDK 17 due to test failures
Package: libreflectasm-java Version: 1.11.9+dfsg-1 Control: forwarded -1 https://github.com/EsotericSoftware/reflectasm/issues/89 Hello, I tried to dig a bit and found some changes in class loaders in the tests, I tried to summarize my findings in the Github issue I created [0]. Best, -- Pierre [0] https://github.com/EsotericSoftware/reflectasm/issues/89
Bug#1023553: uses option --illegal-access=permit, which was removed in OpenJDK17
Package: gradle Version: 4.4.1-16 Severity: minor Hello, /usr/bin/gradle invokes a gradle build with, among others, --illegal-access=permit Support for --illegal-access has been removed in OpenJDK17. There is a warning message about it in the build logs of Debian packages every time gradle is invoked. Cheers, -- Pierre
Bug#1013156: gdcm: vtk[6,7] removal
Hi Andreas, Le 26/10/2022 à 11:24, Andreas Tille a écrit : Hi Pierre, Am Wed, Oct 26, 2022 at 10:41:51AM +0200 schrieb Pierre Gruet: [1] https://salsa.debian.org/med-team/gdcm/-/jobs/3427720 This is really just a missing include dir, as the problematic header is in /usr/lib/jvm/default-java/include/linux/ . I will be having a look shortly, we should be able to handle this and keep the Java packages if this is the only Java-related issue. Please see the hint of Mathieu. To be clear about this: We'll keep the general Java support libgdcm-java but it seems we need to remove libvtkgdcm-java which is way less frequently used. (For sure if you see any chance to fix this feel free to re-add what was removed in Git - but I guess this is some issue that needs to be fixed upstream.) Kind regards Andreas. Yes, it is likely I overlooked the whole frame of the issue. Will look again later... this Java point seems not to be the most urgent thing. Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1013156: gdcm: vtk[6,7] removal
Hi, Le 26/10/2022 à 10:35, Andreas Tille a écrit : Hi Mathieu, Am Wed, Oct 26, 2022 at 08:10:42AM +0200 schrieb Mathieu Malaterre: On Wed, Oct 26, 2022 at 7:53 AM Andreas Tille wrote: Hi, in the bug log there is some discussion to drop C# and Java VTK bindings. This would mean to drop the packages libvtkgdcm-cil and libvtkgdcm-java. I'm perfectly fine with this and I just pushed a change in d/control where I replaced s/vtk7/vtk9/ globally. The build[1] is currently failing at a probably simple Java issue: /usr/lib/jvm/default-java/include/jni.h:45:10: fatal error: jni_md.h: No such file or directory 45 | #include "jni_md.h" | ^~ compilation terminated. I have no idea whether we might keep on supporting the Java bindings if this can be solved. But I'm pretty sure we should act on droping what needs to be droped in a timely manner to make sure gdcm will remain in testing. Any help is welcome. See my original work at: https://salsa.debian.org/med-team/gdcm/-/commits/debian/experimental/ Ups, sorry for missing this. I've merged your changes into master but the said problem remains[1]. Kind regards Andreas. [1] https://salsa.debian.org/med-team/gdcm/-/jobs/3427720 This is really just a missing include dir, as the problematic header is in /usr/lib/jvm/default-java/include/linux/ . I will be having a look shortly, we should be able to handle this and keep the Java packages if this is the only Java-related issue. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1022258: ITP: libmjson-java -- lean JSON Library for Java with a compact API
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org * Package name: libmjson-java Version : 1.4.0 Upstream Author : Miami-Dade County * URL : https://bolerio.github.io/mjson/ * License : Apache-2.0 Programming Lang: Java Description : lean JSON Library for Java with a compact API mJson is an extremely lightweight Java JSON library with a very concise API. Unlike other JSON libraries, it focuses on manipulating JSON structures in Java without necessarily mapping them to/from strongly typed Java objects. Because of its tiny size, it is well-suited for any application aiming at a small footprint such as mobile applications. mjson is needed as a dependency of htsjdk, which is an important software in the Debian-med ecosystem.
Bug#1021934: ITP: biojava6-live -- Java API to biological data and applications (version 6)
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org * Package name: biojava6-live Version : 6.0.5 Upstream Author : BioJava Developers * URL : https://biojava.org * License : LGPL-2.1 Programming Lang: Java Description : Java API to biological data and applications (version 6) This package presents the Open Source Java API to biological databases and a series of mostly sequence-based algorithms. BioJava is an open-source project dedicated to providing a Java framework for processing biological data. It includes objects for manipulating sequences, file parsers, server support, access to BioSQL and Ensembl databases, and powerful analysis and statistical routines including a dynamic programming toolkit. Important changes in the API at each major version have made it necesssary to have a new source package for every major version of the library. In the Debian-med team, we have already started seeing packages depending on biojava 6 and it would be a very valuable addition to have it into Debian. The package will be team-maintained by the Debian-med team.
Bug#1021899: wrongly reports a typo for rule execute_before_mh_install
Package: lintian-brush Version: 0.132 Severity: normal Dear Maintainer, In the debian/rules file of the source package jmol, I have a rule called execute_before_mh_install and lintian-brush reports a typo-in-debhelper-override-target and changes it to execute_before_dh_install although mh_install is a valid sequence brought up by maven_repo_helper, which one uses to add Maven coordinates for Java projects. Do you think this might get fixed? Best, -- Pierre
Bug#1021485: no version information is shipped in the POMs for the plexus- dependencies
Package: libplexus-interactivity-api-java Version: 1.1-1 Severity: normal Hello, Currently no version information is provided in the shipped POMs for plexus-*, this is because this information is missing in all POMs in the source although the child POMs both declare a dependency on two plexus- artifacts. This leads to errors about "dependencies.dependency.version" being missing when one attempts to build a software depending on plexus-interactivity, e.g. using maven-javadoc-plugin which depends on it. I will make an upload solving this soon. Best, -- Pierre
Bug#1021200: wrong build-dependency libservlet-api-ava
Package: groovy Version: 2.4.21-3 Severity: important Hello, The version 2.4.21-3 of groovy that was uploaded yesterday wrongly includes libservlet-api-ava as a build-dependency. This mispelled package name has been introduced in an attempt to solve Bug #1020429. Build dependencies of groovy and of its rdeps cannot be satisfied. Cheers, -- Pierre
Bug#1019393: hdf5 breaks libsis-jhdf5-java autopkgtest: Could not initialize class
Control: tags -1 + confirmed Hello, The issue showing up in the tests is the native library cannot be loaded properly. Some symbols (at least HDfprintf) cannot be found. I can investigate next week. Surprisingly, using sbuild and working in the chroot after the failure of the tests, running debian/rules override_dh_auto_build debian/rules override_dh_auto_test leads to all the tests passing... Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1017563: RM: theseus [arm64 armel armhf mips64el mipsel ppc64el s390x alpha hppa hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k powerpc ppc64 riscv64 sh4 sparc64 x32] -- ROM; has a dependency av
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, theseus depends on muscle, which is only available on Intel architectures at the moment, see bug #1006161 which led to the removal of muscle on non-Intel arches. Could you please proceed to the removal of theseus from all architectures except amd64 and i386? Thanks a lot for your help, Best regards, - -- Pierre -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmL9R24PHHBndEBkZWJp YW4ub3JnAAoJEGADFqbcJ3R2y7wQAIcWOrPaRQl0H5hS00TxWCfJCQCYXCWKUspB UYfw7cYxMCpVeALbV0gPWnPZ6AxmNVOk6KSd6izGW6wVeFFcBG387mw6h7eMp6al rCWeC8Q/Zc2DHYyTLDM0hkA0DJPoE1tQxIRz9aZN7np8AAW+hOfLtUIMvJinfWwd Q4+3OPyFR7ny2SBVPxNtCsq2+44DgPecUrCJsrY7yS/vnHH56HSiFhPOEfzsoGGz uc+2nBeqC/M9qOsNuQmQG1kM7/+s7rSNHfocmjcWKY+Lyac6Yp4gJ4O0FIHtrNir 2T0hp8Lx71kKOxvJb7DNv2ILusWLK0k6mfSEc0og7BB3UGsUaxux8gkGO3yCCw4L Ya6OM/Yfa2qNTV+p+tg6C01e3lZefKjK8K4R/vtkjAs1pyFjb5spwgY2bgSHT8Hd a7ZFg6apqM6ximjz46DipXR+dn88Zi/+V6AH7IXv35xFMyPd015SFjmEFX1BMlL8 Dt/8riOXPjLb7WFf75EAe88vzADh28yuIqwDfX4Lpbl9OXPxk33QIoiUESi2faCb y66q/1+TOeQqoFS1L1FKC1Q+REW02emGIQ7VDyx16jltQbE8eJdotzBOm60iMbt+ FkqbheCNMawe9n8ltdCM9mPz6CT0puU6D3h/suaYgAvBr5n69t9au6DwfzIHzCwL OXKra+s3 =gHD7 -END PGP SIGNATURE-
Bug#1017527: acceptance-* tests should be marked as 'flaky'
Source: patroni Version: 2.1.4-1 Severity: normal Control: affects -1 src:zookeeper src:psycopg2 Dear Maintainer, The three autopkgtests acceptance-consul, acceptance-etcd and acceptance-zookeeper began failing at a significant frequency recently, at least on armhf, independently of each other. This makes the migration of reverse-dependencies to testing rather difficult, as one basically has to retry the CI tests again and again until the three above-quoted tests pass. Please see the page https://ci.debian.net/packages/p/patroni/testing/armhf/ and the bottoms of the various test logs for an illustration. I think the three acceptance-* tests should be marked with Restrictions: flaky so that they allow for smooth testing migrations of the reverse dependencies. Thanks a lot for considering, Best regards, -- Pierre
Bug#1016046: ITP: genomicsdb -- sparse array storage library for genomics
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org * Package name: genomicsdb Version : 1.4.3 Upstream Author : Intel Health and Lifesciences * URL : https://www.genomicsdb.org/ * License : Expat Programming Lang: C++, Java Description : sparse array storage library for genomics GenomicsDB is built on top of a htslib fork and an internal array storage system for importing, querying and transforming variant data. Variant data is sparse by nature (sparse relative to the whole genome) and using sparse array data stores is a perfect fit for storing such data. The GenomicsDB stores variant data in a 2D array where: - Each column corresponds to a genomic position (chromosome + position); - Each row corresponds to a sample in a VCF (or CallSet in the GA4GH terminology); - Each cell contains data for a given sample/CallSet at a given position; data is stored in the form of cell attributes; - Cells are stored in column major order - this makes accessing cells with the same column index (i.e. data for a given genomic position over all samples) fast. - Variant interval/gVCF interval data is stored in a cell at the start of the interval. The END is stored as a cell attribute. For variant intervals (such as deletions and gVCF REF blocks), an additional cell is stored at the END value of the variant interval. When queried for a given genomic position, the query library performs an efficient sweep to determine all intervals that intersect with the queried position. There is a C++ library and a Java library, we plan to ship both of them. This library is needed as a dependency of gatk, which is a packaging target of the Debian-med team.
Bug#1015926: ITP: persalys -- GUI for uncertainty treatment and variabilities management
Package: wnpp Severity: wishlist Owner: Pierre Gruet User: debian-scie...@lists.debian.org Usertags: field..science X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: persalys Version : 12.0.1 Upstream Author : Airbus-EDF-Phimeca * URL : https://persalys.fr/ * License : LGPL-3+ Programming Lang: C++ Description : GUI for uncertainty treatment and variabilities management Persalys is a graphical user interface for OpenTURNS, dedicated to the treatment of uncertainty and the management of variabilities. The software is a tool between the computer simulation, probabilistic analyses and the data sciences. The interface is available in French or in English. Persalys allows one to: - create mathematical models: analytical, coupling with an external model (finite elements, ...), FMU; - analyse the variability of one's parameters thanks to many methods and visualisation tools; - statistically analyse one's measuring data, infer probability distributions or create metamodels. I am an user of Persalys. I plan to maintain in in the Debian-science team.
