Bug#990621: unblock: python-duckpy/3.1.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org
Please unblock package python-duckpy
[ Reason ]
python-duckpy is an unusable package w/o having a Depends on python3-h2
More details with salsa CI links in the corresponding RC bug: #990620 which the
latest upload closes
[ Impact ]
The package will be unusable for bullseye users w/o explicitly
installing python3-h2 on their own
[ Tests ]
Non-superficial autopkgtests have been added in the upload, which helped
to uncover the bug in the first place. Both superficial and
non-superficial autopkgtests are green now.
I also did a bit of manual testing -- looks good!
[ Risks ]
This is a leaf package, no risks
[ 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 python-duckpy/3.1.0-2
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
diff -Nru python-duckpy-3.1.0/debian/changelog
python-duckpy-3.1.0/debian/changelog
--- python-duckpy-3.1.0/debian/changelog2020-09-29 16:16:00.0
+0530
+++ python-duckpy-3.1.0/debian/changelog2021-07-03 01:37:34.0
+0530
@@ -1,3 +1,12 @@
+python-duckpy (3.1.0-2) unstable; urgency=medium
+
+ * Team Upload.
+ * Add autopkgtests
+ * d/examples: Add d/tests/test_duckpy_basic.py as example
+ * d/control: Add Depends on python3-h2 (Closes: #990620)
+
+ -- Nilesh Patra Sat, 03 Jul 2021 01:37:34 +0530
+
python-duckpy (3.1.0-1) unstable; urgency=medium
* Team upload.
diff -Nru python-duckpy-3.1.0/debian/control python-duckpy-3.1.0/debian/control
--- python-duckpy-3.1.0/debian/control 2020-09-29 16:16:00.0 +0530
+++ python-duckpy-3.1.0/debian/control 2021-07-03 00:55:00.0 +0530
@@ -24,7 +24,8 @@
Section: python
Depends: ${misc:Depends},
${python3:Depends},
- python3-bs4
+ python3-bs4,
+ python3-h2
Recommends: ${python3:Recommends}
Suggests: ${python3:Suggests}
Description: simple Python library for searching on DuckDuckGo
diff -Nru python-duckpy-3.1.0/debian/examples
python-duckpy-3.1.0/debian/examples
--- python-duckpy-3.1.0/debian/examples 1970-01-01 05:30:00.0 +0530
+++ python-duckpy-3.1.0/debian/examples 2021-07-03 00:55:00.0 +0530
@@ -0,0 +1 @@
+debian/tests/test_duckpy_basic.py
diff -Nru python-duckpy-3.1.0/debian/tests/control
python-duckpy-3.1.0/debian/tests/control
--- python-duckpy-3.1.0/debian/tests/control1970-01-01 05:30:00.0
+0530
+++ python-duckpy-3.1.0/debian/tests/control2021-07-03 00:54:17.0
+0530
@@ -0,0 +1,3 @@
+Tests: run-unit-test
+Depends: @, python3-pytest
+Restrictions: allow-stderr, needs-internet
diff -Nru python-duckpy-3.1.0/debian/tests/run-unit-test
python-duckpy-3.1.0/debian/tests/run-unit-test
--- python-duckpy-3.1.0/debian/tests/run-unit-test 1970-01-01
05:30:00.0 +0530
+++ python-duckpy-3.1.0/debian/tests/run-unit-test 2021-07-03
00:55:00.0 +0530
@@ -0,0 +1,21 @@
+#!/bin/bash
+set -e
+
+pkg='duckpy'
+CUR_DIR=`pwd`
+
+if [ "$AUTOPKGTEST_TMP" = "" ] ; then
+ AUTOPKGTEST_TMP=`mktemp -d /tmp/${pkg}-test.XX`
+ trap "rm -rf $AUTOPKGTEST_TMP" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cp /usr/share/doc/python3-${pkg}/examples/test_duckpy_basic.py
"$AUTOPKGTEST_TMP"
+
+cd $AUTOPKGTEST_TMP
+
+for py in $(py3versions -s 2> /dev/null)
+do
+echo "Testing with $py in $(pwd):"
+$py -m pytest -v
+done
+echo "PASS"
diff -Nru python-duckpy-3.1.0/debian/tests/test_duckpy_basic.py
python-duckpy-3.1.0/debian/tests/test_duckpy_basic.py
--- python-duckpy-3.1.0/debian/tests/test_duckpy_basic.py 1970-01-01
05:30:00.0 +0530
+++ python-duckpy-3.1.0/debian/tests/test_duckpy_basic.py 2021-07-03
00:54:17.0 +0530
@@ -0,0 +1,34 @@
+import asyncio
+from duckpy import AsyncClient
+from duckpy import Client
+
+def test_functional():
+ client = Client()
+ results = client.search("Python Wikipedia")
+ # Assert first result title is not empty
+ assert results[0]['title'] != ""
+
+ # Assert first result URL is not empty
+ assert results[0]['url'] != ""
+
+ # Prints first result description
+ assert results[0]['description'] != ""
+
+
+async def get_asyncio_results():
+client = AsyncClient()
+results = await cl
Bug#990730: unblock: resfinder/3.2-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org
Please unblock package resfinder
[ Reason ]
resfinder is an unusable package w/o having a Depends on
python3-distutils
It also fixes the corresponding RC bug #990726
[ Impact ]
The package will be unusable for bullseye users w/o explicitly
installing python3-distutils on their own
[ Tests ]
The package has autopkgtests which pass
[ Risks ]
No risks, resfinder is a leaf package
[ 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 resfinder/3.2-3
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
diff -Nru resfinder-3.2/debian/changelog resfinder-3.2/debian/changelog
--- resfinder-3.2/debian/changelog 2020-03-03 11:12:37.0 +0530
+++ resfinder-3.2/debian/changelog 2021-07-06 00:05:05.0 +0530
@@ -1,3 +1,13 @@
+resfinder (3.2-3) unstable; urgency=medium
+
+ * Team Upload.
+ * d/control: Add Missing Depends on python3-distutils
+(Closes: #990726)
+ * d/p/fix_syntaxwarning.patch: Fix syntax warning for
+literal comparison
+
+ -- Nilesh Patra Tue, 06 Jul 2021 00:05:05 +0530
+
resfinder (3.2-2) unstable; urgency=medium
[ Nilesh Patra ]
diff -Nru resfinder-3.2/debian/control resfinder-3.2/debian/control
--- resfinder-3.2/debian/control2020-03-03 11:12:37.0 +0530
+++ resfinder-3.2/debian/control2021-07-06 00:01:06.0 +0530
@@ -19,7 +19,8 @@
resfinder-db,
python3-cgecore,
python3-tabulate,
- ncbi-blast+-legacy
+ ncbi-blast+-legacy,
+ python3-distutils
Description: identify acquired antimicrobial resistance genes
ResFinder identifies acquired antimicrobial resistance genes in total or
partial sequenced isolates of bacteria.
diff -Nru resfinder-3.2/debian/patches/fix_syntaxwarning.patch
resfinder-3.2/debian/patches/fix_syntaxwarning.patch
--- resfinder-3.2/debian/patches/fix_syntaxwarning.patch1970-01-01
05:30:00.0 +0530
+++ resfinder-3.2/debian/patches/fix_syntaxwarning.patch2021-07-06
00:04:19.0 +0530
@@ -0,0 +1,14 @@
+Description: Use == instead of is
+Author: Nilesh Patra
+Last-Update: 2021-07-05
+--- a/resfinder.py
b/resfinder.py
+@@ -364,7 +364,7 @@
+ """
+ """
+ # Check if databases and config file are correct/correponds
+- if databases is '':
++ if databases == '':
+ sys.exit("Input Error: No database was specified!\n")
+ elif databases is None:
+ # Choose all available databases from the config file
diff -Nru resfinder-3.2/debian/patches/series
resfinder-3.2/debian/patches/series
--- resfinder-3.2/debian/patches/series 1970-01-01 05:30:00.0 +0530
+++ resfinder-3.2/debian/patches/series 2021-07-06 00:03:19.0 +0530
@@ -0,0 +1 @@
+fix_syntaxwarning.patch
diff -Nru resfinder-3.2/debian/tests/control resfinder-3.2/debian/tests/control
--- resfinder-3.2/debian/tests/control 2020-03-03 11:12:37.0 +0530
+++ resfinder-3.2/debian/tests/control 2021-07-06 00:01:06.0 +0530
@@ -1,3 +1,3 @@
Tests: run-unit-test
-Depends: @, python3-distutils
+Depends: @
Restrictions: allow-stderr
Bug#990731: unblock: virulencefinder/2.0.3+git20190809.dde157a-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org Please unblock package virulencefinder [ Reason ] virulencefinder is an unusable package w/o having a Depends on python3-distutils It also fixes the corresponding RC bug #990728 [ Impact ] The package will be unusable for bullseye users w/o explicitly installing python3-distutils on their own [ Tests ] The package has autopkgtests which pass [ Risks ] No risks, resfinder is a leaf package [ 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 virulencefinder/2.0.3+git20190809.dde157a-3 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 diff -Nru virulencefinder-2.0.3+git20190809.dde157a/debian/changelog virulencefinder-2.0.3+git20190809.dde157a/debian/changelog --- virulencefinder-2.0.3+git20190809.dde157a/debian/changelog 2020-03-03 11:39:54.0 +0530 +++ virulencefinder-2.0.3+git20190809.dde157a/debian/changelog 2021-07-06 00:36:09.0 +0530 @@ -1,3 +1,11 @@ +virulencefinder (2.0.3+git20190809.dde157a-3) unstable; urgency=medium + + * Team Upload. + * d/control: Add Missing Depends on python3-distutils +(Closes: #990728) + + -- Nilesh Patra Tue, 06 Jul 2021 00:36:09 +0530 + virulencefinder (2.0.3+git20190809.dde157a-2) unstable; urgency=medium * Team Upload. diff -Nru virulencefinder-2.0.3+git20190809.dde157a/debian/control virulencefinder-2.0.3+git20190809.dde157a/debian/control --- virulencefinder-2.0.3+git20190809.dde157a/debian/control2020-03-03 11:39:54.0 +0530 +++ virulencefinder-2.0.3+git20190809.dde157a/debian/control2021-07-06 00:35:45.0 +0530 @@ -23,7 +23,8 @@ python3-tabulate, python3-cgecore, ncbi-blast+, - kma + kma, + python3-distutils Description: identify virulence genes in total or partial sequenced isolates of bacteria The VirulenceFinder service contains one Python script virulencefinder.py which is the script of the latest version of the diff -Nru virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control --- virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control 2020-03-03 11:39:54.0 +0530 +++ virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control 2021-07-06 00:35:29.0 +0530 @@ -1,3 +1,3 @@ Tests: run-unit-test -Depends: @, python3-distutils +Depends: @ Restrictions: allow-stderr
Bug#991470: unblock: q2-sample-classifier/2020.11.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org
Please unblock package q2-sample-classifier
[ Reason ]
This package misses a few needed dependencies, which renders it unusable
[ Impact ]
The package will be broken for the user, and they will have to fetch the
dependencies by themselves
[ Tests ]
Autopkgtests have been added in this release
[ Risks ]
No risks as such
[ 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 q2-sample-classifier/2020.11.1-2
diff -Nru q2-sample-classifier-2020.11.1/debian/changelog
q2-sample-classifier-2020.11.1/debian/changelog
--- q2-sample-classifier-2020.11.1/debian/changelog 2020-12-06
21:40:46.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/changelog 2021-07-25
10:36:56.0 +0530
@@ -1,3 +1,15 @@
+q2-sample-classifier (2020.11.1-2) unstable; urgency=medium
+
+ * Team Upload.
+ * d/control: Add depends on python3-distutils,
+q2-types, q2-feature-table
+ * Add autopkgtests
+ * d/rules: Do not run build time tests with || true
+rather just print the message that this will be dealt
+with in autopkgtests
+
+ -- Nilesh Patra Sun, 25 Jul 2021 10:36:56 +0530
+
q2-sample-classifier (2020.11.1-1) unstable; urgency=medium
* Team upload.
diff -Nru q2-sample-classifier-2020.11.1/debian/control
q2-sample-classifier-2020.11.1/debian/control
--- q2-sample-classifier-2020.11.1/debian/control 2020-12-06
21:40:46.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/control 2021-07-25
10:33:16.0 +0530
@@ -22,6 +22,9 @@
${misc:Depends},
${python3:Depends},
qiime (>= 2020.11.0),
+ python3-distutils,
+ q2-types,
+ q2-feature-table
Description: QIIME 2 plugin for machine learning prediction of sample data
QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
package with a focus on data and analysis transparency. QIIME 2 enables
diff -Nru q2-sample-classifier-2020.11.1/debian/rules
q2-sample-classifier-2020.11.1/debian/rules
--- q2-sample-classifier-2020.11.1/debian/rules 2020-12-06 21:40:46.0
+0530
+++ q2-sample-classifier-2020.11.1/debian/rules 2021-07-25 10:29:27.0
+0530
@@ -13,11 +13,11 @@
rm -rf
debian/q2-sample-classifier/usr/lib/python3.9/site-packages/q2_sample_classifier/__pycache__/
rm -rf
debian/q2-sample-classifier/usr/lib/python3.9/site-packages/q2_sample_classifier/tests/__pycache__/
-# FIXME: modules cannot be registered at build time - ignoring build tests for
now
+#FIXME:
override_dh_auto_test:
-#ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
- dh_auto_test || true
-#endif
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+ echo "I: Delaying true testing to autopkgtests since QIIME2 module
cannot be registered at build time"
+endif
override_dh_auto_clean:
dh_auto_clean
diff -Nru q2-sample-classifier-2020.11.1/debian/tests/control
q2-sample-classifier-2020.11.1/debian/tests/control
--- q2-sample-classifier-2020.11.1/debian/tests/control 1970-01-01
05:30:00.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/tests/control 2021-07-18
17:29:15.0 +0530
@@ -0,0 +1,3 @@
+Tests: run-unit-test
+Depends: @, python3-pytest-cov
+Restrictions: allow-stderr, skip-not-installable
diff -Nru q2-sample-classifier-2020.11.1/debian/tests/run-unit-test
q2-sample-classifier-2020.11.1/debian/tests/run-unit-test
--- q2-sample-classifier-2020.11.1/debian/tests/run-unit-test 1970-01-01
05:30:00.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/tests/run-unit-test 2021-07-25
10:31:17.0 +0530
@@ -0,0 +1,20 @@
+#!/bin/bash
+set -e
+
+pkg=q2_sample_classifier
+
+if [ "${AUTOPKGTEST_TMP}" = "" ] ; then
+ AUTOPKGTEST_TMP=$(mktemp -d /tmp/${pkg}-test.XX)
+ trap "rm -rf ${AUTOPKGTEST_TMP}" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cp -a /usr/lib/python3/dist-packages/${pkg}* "${AUTOPKGTEST_TMP}"
+
+cd "${AUTOPKGTEST_TMP}"
+if [ ! -f /usr/lib/python3/dist-packages/pytest_cov/__init__.py ] ; then
+ echo "Please install package python3-pytest-cov to run this script"
+ exit 1
+fi
+
+# Run build-time tests
+py.test-3 --cov=${pkg}
Bug#991470: unblock: q2-sample-classifier/2020.11.1-2
control: retitle -1 q2-sample-classifier/2020.11.1-3
On Sun, 25 Jul 2021 10:58:22 +0530 Nilesh Patra wrote:
> [...]
Unfortunately, autopkgtests were failing on arm64 and ppc64el for this
release owing to floating point errors
I've fixed this, and uploaded a new release.
Attaching debdiff for the same against -1 in testing.
The points mentioned above apply the same to this release too.
Please consider granting an unblock
Nilesh
unblock q2-sample-classifier/2020.11.1-3
diff -Nru q2-sample-classifier-2020.11.1/debian/changelog
q2-sample-classifier-2020.11.1/debian/changelog
--- q2-sample-classifier-2020.11.1/debian/changelog 2020-12-06
21:40:46.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/changelog 2021-07-25
17:20:25.0 +0530
@@ -1,3 +1,23 @@
+q2-sample-classifier (2020.11.1-3) unstable; urgency=medium
+
+ * Team Upload.
+ * d/p/reduce-precision-in-tests.patch: Add tolerance to 3 tests in order
+to avoid test failuers due to float point errors on non-amd64 arches
+
+ -- Nilesh Patra Sun, 25 Jul 2021 17:20:25 +0530
+
+q2-sample-classifier (2020.11.1-2) unstable; urgency=medium
+
+ * Team Upload.
+ * d/control: Add depends on python3-distutils,
+q2-types, q2-feature-table
+ * Add autopkgtests
+ * d/rules: Do not run build time tests with || true
+rather just print the message that this will be dealt
+with in autopkgtests
+
+ -- Nilesh Patra Sun, 25 Jul 2021 10:36:56 +0530
+
q2-sample-classifier (2020.11.1-1) unstable; urgency=medium
* Team upload.
diff -Nru q2-sample-classifier-2020.11.1/debian/control
q2-sample-classifier-2020.11.1/debian/control
--- q2-sample-classifier-2020.11.1/debian/control 2020-12-06
21:40:46.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/control 2021-07-25
10:33:16.0 +0530
@@ -22,6 +22,9 @@
${misc:Depends},
${python3:Depends},
qiime (>= 2020.11.0),
+ python3-distutils,
+ q2-types,
+ q2-feature-table
Description: QIIME 2 plugin for machine learning prediction of sample data
QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
package with a focus on data and analysis transparency. QIIME 2 enables
diff -Nru
q2-sample-classifier-2020.11.1/debian/patches/reduce-precision-in-tests.patch
q2-sample-classifier-2020.11.1/debian/patches/reduce-precision-in-tests.patch
---
q2-sample-classifier-2020.11.1/debian/patches/reduce-precision-in-tests.patch
1970-01-01 05:30:00.0 +0530
+++
q2-sample-classifier-2020.11.1/debian/patches/reduce-precision-in-tests.patch
2021-07-25 17:19:18.0 +0530
@@ -0,0 +1,39 @@
+Description: Add more tolerance in 3 tests in order to avoid test failures due
to float
+ point errors on non-amd64 arches
+Author: Nilesh Patra
+Last-Update: 2021-07-25
+diff --git a/q2_sample_classifier/tests/test_estimators.py
b/q2_sample_classifier/tests/test_estimators.py
+index 11f7893..a39382b 100644
+--- a/q2_sample_classifier/tests/test_estimators.py
b/q2_sample_classifier/tests/test_estimators.py
+@@ -247,9 +247,9 @@ class EstimatorsTests(SampleClassifierTestPluginBase):
+ pred, self.mdc_chard_fp.to_series(), 'ignore')
+ accuracy = accuracy_score(truth, pred)
+ self.assertAlmostEqual(
+-accuracy, seeded_results[classifier], places=4,
++accuracy, seeded_results[classifier],
+ msg='Accuracy of %s classifier was %f, but expected %f' % (
+-classifier, accuracy, seeded_results[classifier]))
++classifier, accuracy, seeded_results[classifier]),
delta=0.1)
+
+ # test that the plugin methods/visualizers work
+ def test_regress_samples_ncv(self):
+@@ -363,7 +363,7 @@ class EstimatorsTests(SampleClassifierTestPluginBase):
+ regressor, accuracy, seeded_results[regressor]))
+ else:
+ self.assertAlmostEqual(
+-accuracy, seeded_results[regressor], places=4,
++accuracy, seeded_results[regressor], places=2,
+ msg='Accuracy of %s regressor was %f, but expected %f' % (
+ regressor, accuracy, seeded_results[regressor]))
+
+@@ -490,7 +490,7 @@ class EstimatorsTests(SampleClassifierTestPluginBase):
+ self.assertAlmostEqual(
+ mse, seeded_predict_results[regressor],
+ msg='Accuracy of %s regressor was %f, but expected %f' % (
+-regressor, mse, seeded_predict_results[regressor]))
++regressor, mse, seeded_predict_results[regressor]),
delta=0.001)
+
+ # make sure predict still works when features are given in a different
+ # order from training set.
+
diff -Nru q2-sample-classifier-2020.11.1/debian/patches/series
q2-sample-classifier-2020.11.1/debian/patch
Bug#991508: unblock: samtools-legacy/0.1.19+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org
Please unblock package samtools-legacy
[ Reason ]
This package misses a depends on zlib1g-dev rendering it unusable
[ Impact ]
The package will be broken for the user, and they will have to fetch the
dependencies by themselves
[ Tests ]
Autopkgtests have been added in this release
[ Risks ]
Low risk, no change in any installations -- just one dep added w/
autopkgtests
IMO, this is safe
[ 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 samtools-legacy/0.1.19+dfsg-2
diff -Nru samtools-legacy-0.1.19+dfsg/debian/changelog
samtools-legacy-0.1.19+dfsg/debian/changelog
--- samtools-legacy-0.1.19+dfsg/debian/changelog2020-11-16
23:20:39.0 +0530
+++ samtools-legacy-0.1.19+dfsg/debian/changelog2021-07-25
20:41:17.0 +0530
@@ -1,3 +1,11 @@
+samtools-legacy (0.1.19+dfsg-2) unstable; urgency=medium
+
+ * Team Upload.
+ * Add Depends on zlib1g-dev
+ * Add autopkgtests
+
+ -- Nilesh Patra Sun, 25 Jul 2021 20:41:17 +0530
+
samtools-legacy (0.1.19+dfsg-1) unstable; urgency=medium
* Team upload.
diff -Nru samtools-legacy-0.1.19+dfsg/debian/control
samtools-legacy-0.1.19+dfsg/debian/control
--- samtools-legacy-0.1.19+dfsg/debian/control 2020-11-16 23:20:39.0
+0530
+++ samtools-legacy-0.1.19+dfsg/debian/control 2021-07-25 20:39:14.0
+0530
@@ -16,7 +16,8 @@
Architecture: any
Section: libdevel
Depends: ${shlibs:Depends},
- ${misc:Depends}
+ ${misc:Depends},
+ zlib1g-dev
Description: manipulates nucleotide sequence alignments in BAM or SAM format
The BAM library provides I/O and various operations on manipulating nucleotide
sequence alignments in the BAM (Binary Alignment/Mapping) or SAM (Sequence
diff -Nru samtools-legacy-0.1.19+dfsg/debian/tests/control
samtools-legacy-0.1.19+dfsg/debian/tests/control
--- samtools-legacy-0.1.19+dfsg/debian/tests/control1970-01-01
05:30:00.0 +0530
+++ samtools-legacy-0.1.19+dfsg/debian/tests/control2021-07-24
22:33:24.0 +0530
@@ -0,0 +1,3 @@
+Tests: run-unit-test
+Depends: @, build-essential, samtools
+Restrictions: allow-stderr
diff -Nru samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test
samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test
--- samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test 1970-01-01
05:30:00.0 +0530
+++ samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test 2021-07-24
22:43:39.0 +0530
@@ -0,0 +1,34 @@
+#!/bin/bash
+set -e
+
+pkg=cppnumericalsolvers
+CUR_DIR=`pwd`
+
+export LC_ALL=C.UTF-8
+if [ "${AUTOPKGTEST_TMP}" = "" ] ; then
+ AUTOPKGTEST_TMP=$(mktemp -d /tmp/${pkg}-test.XX)
+ trap "rm -rf ${AUTOPKGTEST_TMP}" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cd "${AUTOPKGTEST_TMP}"
+cp ${CUR_DIR}/examples/* .
+
+samtools view -S -b toy.sam > toy.bam
+
+echo "Test 1 -- calDepth"
+gcc calDepth.c -o calDepth -I/usr/include/samtools -lbam -lm -lz -lpthread
+./calDepth toy.bam
+echo "=== PASS "
+
+echo "Test 2 -- chk_indel"
+gcc chk_indel.c -o chk_indel -I/usr/include/samtools -lbam -lm -lz -lpthread
+./chk_indel toy.bam
+echo "=== PASS "
+
+
+echo "Test 3 -- bam2bed"
+gcc bam2bed.c -o bam2bed -I/usr/include/samtools -lbam -lm -lz -lpthread
+./bam2bed toy.bam
+echo "=== PASS "
+
+rm -f toy.bam
Bug#991841: unblock: perm/0.4.0-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org
Please unblock package perm
[ Reason ]
An autopkgtest was recently added to perm on its git repository, which
resulted in uncovering a buffer overflow. Here's the log:
https://salsa.debian.org/med-team/perm/-/jobs/1788156
AIUI, this is a security issue and such issues are RC
[ Impact ]
The users machine will contain a version of perm which can potentially
cause a buffer overflow
[ Tests ]
Autopkgtests have been added for this release
[ Risks ]
Perm is a leaf package, I do not see any risks
[ 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 ]
Some stuff like installing docs in d/docs, or installing autopkgtests in
d/examples might look redundant, but they are needed to run tests in a
sane fashion. These changes are not too major, and are rather harmless.
unblock perm/0.4.0-6
diff -Nru perm-0.4.0/debian/changelog perm-0.4.0/debian/changelog
--- perm-0.4.0/debian/changelog 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/changelog 2021-08-03 00:31:10.0 +0530
@@ -1,3 +1,24 @@
+perm (0.4.0-6) unstable; urgency=medium
+
+ * Team Upload.
+ [ Shruti Sridhar ]
+ * d/tests/data: Add testdata
+ * d/tests: Add autopkgtest
+ * d/example: Install test data as example
+ * d/docs: Install d/README.* and d/tests/run-unit-test
+as documents
+ * d/p/hardening.patch: Add CPPFLAGS which helped detect
+buffer overflow
+ * d/copyright: Test data has been written by Shruti, mentioning
+them in copyright for the same
+
+ [ Nilesh Patra ]
+ * d/p/fix-buffer-overflow.patch: Use strlcpy from libbsd-dev
+instead of strncpy in order to fix buffer overflow
+ * d/control: Add B-D on libbsd-dev
+
+ -- Nilesh Patra Tue, 03 Aug 2021 00:31:10 +0530
+
perm (0.4.0-5) unstable; urgency=medium
* Standards-Version: 4.5.1 (routine-update)
diff -Nru perm-0.4.0/debian/control perm-0.4.0/debian/control
--- perm-0.4.0/debian/control 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/control 2021-08-02 21:22:22.0 +0530
@@ -3,7 +3,7 @@
Uploaders: Andreas Tille
Section: science
Priority: optional
-Build-Depends: debhelper-compat (= 13)
+Build-Depends: debhelper-compat (= 13), libbsd-dev
Standards-Version: 4.5.1
Vcs-Browser: https://salsa.debian.org/med-team/perm
Vcs-Git: https://salsa.debian.org/med-team/perm.git
diff -Nru perm-0.4.0/debian/copyright perm-0.4.0/debian/copyright
--- perm-0.4.0/debian/copyright 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/copyright 2021-08-03 00:31:10.0 +0530
@@ -12,6 +12,10 @@
2014-2017 Andreas Tille
License: Apache-2.0
+Files: debian/tests/data/*
+Copyright: Shruti Sridhar
+License: Apache-2.0
+
License: Apache-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
diff -Nru perm-0.4.0/debian/docs perm-0.4.0/debian/docs
--- perm-0.4.0/debian/docs 1970-01-01 05:30:00.0 +0530
+++ perm-0.4.0/debian/docs 2021-08-02 17:25:32.0 +0530
@@ -0,0 +1,2 @@
+debian/README*
+debian/tests/run-unit-test
\ No newline at end of file
diff -Nru perm-0.4.0/debian/examples perm-0.4.0/debian/examples
--- perm-0.4.0/debian/examples 1970-01-01 05:30:00.0 +0530
+++ perm-0.4.0/debian/examples 2021-08-02 17:25:32.0 +0530
@@ -0,0 +1 @@
+debian/tests/data/*
\ No newline at end of file
diff -Nru perm-0.4.0/debian/patches/fix-buffer-overflow.patch
perm-0.4.0/debian/patches/fix-buffer-overflow.patch
--- perm-0.4.0/debian/patches/fix-buffer-overflow.patch 1970-01-01
05:30:00.0 +0530
+++ perm-0.4.0/debian/patches/fix-buffer-overflow.patch 2021-08-03
00:30:42.0 +0530
@@ -0,0 +1,42 @@
+Description: Use strlcpy from libbsd-dev instead of strncpy in order to avoid
buffer overflow
+Author: Nilesh Patra
+Last-Update: 2021-08-03
+--- a/makefile
b/makefile
+@@ -2,7 +2,7 @@
+ CC = g++ -O2 $(CFLAGS)
+
+ TARGETS = perm
+-LIBS = -lm -lstdc++
++LIBS = -lm -lstdc++ -lbsd
+
+ PER_M = AlignmentsQ.cpp Filename.cpp GenomeNTdata.cpp ReadInBits.cpp PerM.cpp
chromosomeNTdata.cpp\
+ bitsOperationUtil.cpp FileOutputBuffer.cpp HashIndexT.cpp ReadInBitsSet.cpp
SeedPattern.cpp\
+--- a/stdafx.h
b/stdafx.h
+@@ -12,6 +12,7 @@
+ #include
+ #include "time.h"
+ #include "Filename.h"
++#include
+ //#ifdef WIN32
+ #include "chdir.h"
+ //#else
+@@ -174,14 +175,14 @@
+ return(true);
+ }
+
+-inline char* myStrCpy(char* caBuf, const char* str, int iBufSize)
++inline int myStrCpy(char* caBuf, const char* str, int iBufSize)
+ {
+ if (caBuf == NULL) {
+ ERR;
+-return(NULL);
++return(-1);
+ }
+ int iBufS
Bug#991841: unblock: perm/0.4.0-6
control: retitle -1 perm/0.4.0-7
On Tue, 3 Aug 2021 09:39:04 +0200 Sebastian Ramacher
wrote:
>> Control: tags -1 moreinfo
>> +-inline char* myStrCpy(char* caBuf, const char* str, int iBufSize)
>> ++inline int myStrCpy(char* caBuf, const char* str, int iBufSize)
>> + {
>> + if (caBuf == NULL) {
>> + ERR;
>> +-return(NULL);
>> ++return(-1);
>> + }
>> + int iBufSizeMinus1 = iBufSize - 1;
>> +-char* returnV = strncpy(caBuf, str, iBufSizeMinus1);
>> ++int returnV = strlcpy(caBuf, str, iBufSizeMinus1);
> The interesting thing about strlcpy is that you don't have to deal with
> this -1 nonsense and the explicit NUL-termination that follows. In fact,
> this patch now makes every buffer 1 byte smaller. strlcpy copies
> iBufSizeMinus1 - 1 characters in this case. Is that intended?
Aw, crap, no. I got sloppy here. I just did another upload on top of it, to
copy right buffer length, retitled accordingly.
Hopefully this should be fine now.
The debdiff is also attached w/ the version in testing
> I agree that this issue should be fixed, but I'm not sure if it is
> necessary to rush a fix now.
IMO, if this fixed is not merged now, I'll have to push it to next
stable point release, creating more work for everyone, and also passing
in this seemingly RC bug to the first release.
Being a leaf package with a relatively low popcon score, I think it is
not going to do a lot of damage, and I think it
would be really really great if you consider to let this in now, than later.
Upstream is not active, and I do not expect much from them.
Ofcourse, I agree that this creates some last minute noise+work for
the release team and I'm really
sorry about this -- it was discovered just yesterday, and I uploaded
after enough ACKs as soon as I found a relevant workaround.
But I'd be obliged if you consider to let this in.
Nilesh
diff -Nru perm-0.4.0/debian/changelog perm-0.4.0/debian/changelog
--- perm-0.4.0/debian/changelog 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/changelog 2021-08-03 13:17:48.0 +0530
@@ -1,3 +1,31 @@
+perm (0.4.0-7) unstable; urgency=medium
+
+ * Team Upload.
+ * d/p/fix-buffer-overflow.patch: Do not reduce buffer size by 1
+
+ -- Nilesh Patra Tue, 03 Aug 2021 13:17:48 +0530
+
+perm (0.4.0-6) unstable; urgency=medium
+
+ * Team Upload.
+ [ Shruti Sridhar ]
+ * d/tests/data: Add testdata
+ * d/tests: Add autopkgtest
+ * d/example: Install test data as example
+ * d/docs: Install d/README.* and d/tests/run-unit-test
+as documents
+ * d/p/hardening.patch: Add CPPFLAGS which helped detect
+buffer overflow
+ * d/copyright: Test data has been written by Shruti, mentioning
+them in copyright for the same
+
+ [ Nilesh Patra ]
+ * d/p/fix-buffer-overflow.patch: Use strlcpy from libbsd-dev
+instead of strncpy in order to fix buffer overflow
+ * d/control: Add B-D on libbsd-dev
+
+ -- Nilesh Patra Tue, 03 Aug 2021 00:31:10 +0530
+
perm (0.4.0-5) unstable; urgency=medium
* Standards-Version: 4.5.1 (routine-update)
diff -Nru perm-0.4.0/debian/control perm-0.4.0/debian/control
--- perm-0.4.0/debian/control 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/control 2021-08-02 21:22:22.0 +0530
@@ -3,7 +3,7 @@
Uploaders: Andreas Tille
Section: science
Priority: optional
-Build-Depends: debhelper-compat (= 13)
+Build-Depends: debhelper-compat (= 13), libbsd-dev
Standards-Version: 4.5.1
Vcs-Browser: https://salsa.debian.org/med-team/perm
Vcs-Git: https://salsa.debian.org/med-team/perm.git
diff -Nru perm-0.4.0/debian/copyright perm-0.4.0/debian/copyright
--- perm-0.4.0/debian/copyright 2020-11-24 14:40:20.0 +0530
+++ perm-0.4.0/debian/copyright 2021-08-03 00:41:56.0 +0530
@@ -12,6 +12,10 @@
2014-2017 Andreas Tille
License: Apache-2.0
+Files: debian/tests/data/*
+Copyright: Shruti Sridhar
+License: Apache-2.0
+
License: Apache-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
diff -Nru perm-0.4.0/debian/docs perm-0.4.0/debian/docs
--- perm-0.4.0/debian/docs 1970-01-01 05:30:00.0 +0530
+++ perm-0.4.0/debian/docs 2021-08-02 17:25:32.0 +0530
@@ -0,0 +1,2 @@
+debian/README*
+debian/tests/run-unit-test
\ No newline at end of file
diff -Nru perm-0.4.0/debian/examples perm-0.4.0/debian/examples
--- perm-0.4.0/debian/examples 1970-01-01 05:30:00.0 +0530
+++ perm-0.4.0/debian/examples 2021-08-02 17:25:32.0 +0530
@@ -0,0 +1 @@
+debian/tests/data/*
\ No newline at end of file
diff -Nru perm-0.4.0/debian/patches/fix-buffer-overflow.patch
perm-0.4.0/debian/patches/fix-buffer-overflow.patch
--- perm-0.4.0/debian/patches/fix-buffer-overflow.patch 1970-01-01
05:30:00.0 +0530
+++ perm-0.4.0/debian/patches/fix-buf
Bug#991749: unblock: ruby-maven-libs/3.3.9+ds-2
control: retitle -1 unblock: ruby-maven-libs/3.3.9+ds-3 Hi Graham, On Sun, 1 Aug 2021 14:33:35 +0200 Graham Inggs wrote: > Control: tags -1 + moreinfo > > Hi Praveen > > On Sat, 31 Jul 2021 at 21:21, wrote: > > + * Bump debhelper from old 10 to 12. > > Please revert this change. See 'Target fixes' section of the freeze policy > [1]. I reverted this debhelper bump and uploaded a -3 to unstable. Debdiff for both the -3 release v/s -2 release (this one), and -3 v/s -1.1 release (in testing) can be found attached w/ this email Since the -2 changelog states inclusion of d/salsa-ci.yml, but the package did not include it, I added two lines of this file, which should be absolutely harmless by all metrics. Thanks a lot for your work on the release :-) Nilesh diff -Nru ruby-maven-libs-3.3.9+ds/debian/changelog ruby-maven-libs-3.3.9+ds/debian/changelog --- ruby-maven-libs-3.3.9+ds/debian/changelog 2021-08-01 00:23:32.0 +0530 +++ ruby-maven-libs-3.3.9+ds/debian/changelog 2021-08-03 22:02:31.0 +0530 @@ -1,3 +1,10 @@ +ruby-maven-libs (3.3.9+ds-3) unstable; urgency=medium + + * Team Upload. + * Revert debhelper bump from 10 to 12 for bullseye release + + -- Nilesh Patra Tue, 03 Aug 2021 22:02:31 +0530 + ruby-maven-libs (3.3.9+ds-2) unstable; urgency=medium * Team upload. diff -Nru ruby-maven-libs-3.3.9+ds/debian/compat ruby-maven-libs-3.3.9+ds/debian/compat --- ruby-maven-libs-3.3.9+ds/debian/compat 1970-01-01 05:30:00.0 +0530 +++ ruby-maven-libs-3.3.9+ds/debian/compat 2021-08-03 21:59:35.0 +0530 @@ -0,0 +1 @@ +10 diff -Nru ruby-maven-libs-3.3.9+ds/debian/control ruby-maven-libs-3.3.9+ds/debian/control --- ruby-maven-libs-3.3.9+ds/debian/control 2021-08-01 00:23:32.0 +0530 +++ ruby-maven-libs-3.3.9+ds/debian/control 2021-08-03 22:00:16.0 +0530 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian Ruby Team Uploaders: Miguel Landaeta -Build-Depends: debhelper-compat (= 12), +Build-Depends: debhelper (>= 10~), gem2deb Standards-Version: 4.5.1 Vcs-Git: https://salsa.debian.org/ruby-team/ruby-maven-libs.git diff -Nru ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml --- ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml1970-01-01 05:30:00.0 +0530 +++ ruby-maven-libs-3.3.9+ds/debian/salsa-ci.yml2021-08-03 21:59:05.0 +0530 @@ -0,0 +1,4 @@ +--- +include: + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml diff -Nru ruby-maven-libs-3.3.9+ds/debian/changelog ruby-maven-libs-3.3.9+ds/debian/changelog --- ruby-maven-libs-3.3.9+ds/debian/changelog 2021-01-09 17:39:58.0 +0530 +++ ruby-maven-libs-3.3.9+ds/debian/changelog 2021-08-03 22:02:31.0 +0530 @@ -1,9 +1,36 @@ -ruby-maven-libs (3.3.9+ds-1.1) unstable; urgency=medium +ruby-maven-libs (3.3.9+ds-3) unstable; urgency=medium - * Non maintainer upload by the Reproducible Builds team. - * No source change upload to rebuild on buildd with .buildinfo files. + * Team Upload. + * Revert debhelper bump from 10 to 12 for bullseye release - -- Holger Levsen Sat, 09 Jan 2021 13:09:58 +0100 + -- Nilesh Patra Tue, 03 Aug 2021 22:02:31 +0530 + +ruby-maven-libs (3.3.9+ds-2) unstable; urgency=medium + + * Team upload. + + [ Utkarsh Gupta ] + * Add salsa-ci.yml + + [ Debian Janitor ] + * Use secure copyright file specification URI. + * Bump debhelper from old 10 to 12. + * Set debhelper-compat version in Build-Depends. + * Update Vcs-* headers from URL redirect. + * Use canonical URL in Vcs-Git. + + [ Cédric Boutillier ] + * Update team name + * Add .gitattributes to keep unwanted files out of the source package + + [ Pirate Praveen ] + * Add a simple require autopkgtest (to check the version patch) + * Fix maven version detection patch (Thanks to Raul Tambre) (Closes: #989175) + * Bump Standards-Version to 4.5.1 (no changes needed) + * Include NOTICE file in binary package + * Move debian/watch to gemwatch.debian.net + + -- Pirate Praveen Sun, 01 Aug 2021 00:23:32 +0530 ruby-maven-libs (3.3.9+ds-1) unstable; urgency=medium diff -Nru ruby-maven-libs-3.3.9+ds/debian/control ruby-maven-libs-3.3.9+ds/debian/control --- ruby-maven-libs-3.3.9+ds/debian/control 2017-03-10 00:09:43.0 +0530 +++ ruby-maven-libs-3.3.9+ds/debian/control 2021-08-03 22:00:16.0 +0530 @@ -1,13 +1,13 @@ Source: ruby-maven-libs Section: ruby Priority: optional -Maintainer: Debian Ruby Extras Maintainers +Maintainer: Debian Ruby Team Uploaders: Miguel Landaeta Build-Depends: debhelper (>= 10~), gem2deb -Standards-Version: 3.9.8 -Vcs-Git: https://anonscm.debian.org/git/pkg-ruby-extras/ruby-maven-libs.git -Vcs-Browser: https://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-mav
Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nil...@debian.org
[ Reason ]
The package segfauls to !amd64 and !i386 architectures. The version in
bullseye does not have autopkgtests, when we added those and uploaded
_after_ the bullseye release, tests were segfaulting on arm64, ppc64el
and armhf. Note that there has been no new upstream release, just test
addition with a few cosmetics.
Unfortunantely, the failing logs of the 0.3.4-4 version have disappeared
from here[1]
But, trying on a arm64 porter box confirms the experience.
% ./segemehl -x index.idx -d seq1.fa
[SEGEMEHL] Mon Sep 6 18:29:55 2021: reading database sequences.
zsh: segmentation fault ./segemehl -x index.idx -d seq1.fa
% ./segemehl -i index.idx -d seq1.fa -q myseq.fa > mymap.sam
[SEGEMEHL] Mon Sep 6 18:44:08 2021: reading queries in 'myseq.fa'.
...this keeps running forever
This has been fixed in unstable with the relevant patch, and upload[2]
0.3.4-5 and it migrated to testing after everything passes
[1]: https://ci.debian.net/data/autopkgtest/unstable/arm64/s/segemehl/
[2]:
https://tracker.debian.org/news/1251311/accepted-segemehl-034-5-source-into-unstable/
Since I noticed and fixed it before any bug was filed, there does not
exist a corresponding RC bug in the database. Let me know if I should
file one and process BTS commands on that.
[ Impact ]
Users will find a broken segfaulting package on !amd64 and !i386
machines
[ Tests ]
Autopkgtests have been added. I've manually run them on porter boxes,
and it looks good (as it should)
The revision in unstable also has tests passing
https://ci.debian.net/data/autopkgtest/unstable/arm64/s/segemehl/14839955/log.gz
[ Risks ]
Being a leaf package with a not-very-high popcon, risk is pretty low
[ 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
diff -Nru segemehl-0.3.4/debian/changelog segemehl-0.3.4/debian/changelog
--- segemehl-0.3.4/debian/changelog 2021-02-18 15:14:26.0 +0530
+++ segemehl-0.3.4/debian/changelog 2021-09-06 23:46:30.0 +0530
@@ -1,3 +1,11 @@
+segemehl (0.3.4-3+deb11u1) bullseye; urgency=medium
+
+ * d/p/arm64.patch: Fix autopkgtest segaults on !amd64 and !i386
++ Change the signed-ness for needed chars to fix segfault
+ * Add autopkgtests
+
+ -- Nilesh Patra Mon, 06 Sep 2021 23:46:30 +0530
+
segemehl (0.3.4-3) unstable; urgency=medium
* Team Upload.
diff -Nru segemehl-0.3.4/debian/examples segemehl-0.3.4/debian/examples
--- segemehl-0.3.4/debian/examples 1970-01-01 05:30:00.0 +0530
+++ segemehl-0.3.4/debian/examples 2021-09-06 23:45:58.0 +0530
@@ -0,0 +1 @@
+debian/tests/data/*
\ No newline at end of file
diff -Nru segemehl-0.3.4/debian/patches/arm64.patch
segemehl-0.3.4/debian/patches/arm64.patch
--- segemehl-0.3.4/debian/patches/arm64.patch 1970-01-01 05:30:00.0
+0530
+++ segemehl-0.3.4/debian/patches/arm64.patch 2021-09-06 23:43:50.0
+0530
@@ -0,0 +1,75 @@
+Description: Change the signed-ness for several chars to fix segfault
+Author: Nilesh Patra
+Last-Update: 2021-08-24
+--- a/libs/biofiles.c
b/libs/biofiles.c
+@@ -1916,7 +1916,7 @@
+ Uint max, Uint *minlen, Uint *maxlen, unsigned char *minq, unsigned char
*maxq)
+ {
+
+- char ch;
++ signed char ch;
+ char idchar=0;
+ int ret=0;
+ off_t curseqoffset, lastindexoffset=0;
+@@ -2515,7 +2515,7 @@
+ {
+
+ FILE *fp;
+- char ch;
++ signed char ch;
+ char *buffer;
+ char *descrbuffer = NULL;
+ char *seqbuffer = NULL;
+--- a/libs/fileio.c
b/libs/fileio.c
+@@ -498,7 +498,7 @@
+ void
+ bl_freplacestr(char *filename, char *str, Uint len, char stop){
+ int i = 0;
+- char ch;
++ signed char ch;
+ FILE *fp;
+
+ fp = fopen(filename, "rb+");
+@@ -523,7 +523,8 @@
+
+ int
+ bl_fgets(void *space, FILE *fp, char **str) {
+- char ch, *buffer;
++ signed char ch;
++ char *buffer;
+ size_t buffersize = MAXBUFFERSIZE;
+ size_t len = 0;
+
+@@ -549,7 +550,7 @@
+ char*
+ readfile(void* space, char* filename, size_t* strlen) {
+
+- char ch;
++ signed char ch;
+ char *buffer;
+ FILE *fp;
+ size_t buffersize = MAXBUFFERSIZE;
+--- a/libs/merge.c
b/libs/merge.c
+@@ -596,7 +596,7 @@
+ if (!file->complete && !file->eof){
+
+ #ifndef FILEBUFFEREDMERGE
+-char ch;
++signed char ch;
+ Uint buffersize = 1024;
+ buffer = ALLOCMEMORY(NULL, NULL, char, buffersize);
+ len = 0;
+--- a/libs/samheader.c
b/libs/samheader.c
+@@ -460,7 +460,7 @@
+ {
+ FILE *fp;
+ off_t offset = 0;
+- char ch;
++ signed char ch;
+ char *buffer;
+ // char *descrbuffer = NULL;
+ // char *seqbuffer = NULL;
diff -Nru segemehl-0.3.4/debian/patches/series
segemehl-0.3.4/debian/patche
Bug#985276: unblock: fsm-lite/1.0-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org
Please unblock package fsm-lite
(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)
[ Reason ]
The version of fsm-lite i.e. 1.0-4 uses -msse4.2 flag for compiling on
amd64. This is a baseline violation.
Correspondingly, a RC bug had been reported as #985061 and fixed in version
1.0-5
as can be seen here[1]
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985061
[ Impact ]
The program would crash for users with Illegal instruction error on
earlier versions of amd64 CPU, which do not support SSE4.2 instructions.
[ Tests ]
I do not have access to an older CPU to test this very particular
change, but it now does not use sse4.2 instrcutions for compiling, that
should mitigate the issue.
I installed the fixed version regardless, and it looks good for basic
tweaking that I did. (This package does not have autopkgtests yet, so
complete validity is a bit difficult to ascertain) For sure, there is no
"major" changes in the two versions in unstable and testing.
[ Risks ]
This is a leaf package and is also a non key package. There are no huge
changes. Low risk, I'd say
[ 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 fsm-lite/1.0-5
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru fsm-lite-1.0/debian/changelog fsm-lite-1.0/debian/changelog
--- fsm-lite-1.0/debian/changelog 2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/changelog 2021-03-12 20:22:36.0 +0530
@@ -1,3 +1,13 @@
+fsm-lite (1.0-5) unstable; urgency=medium
+
+ * Team upload.
+ * debian/rules: Don't pass -msse4.2, ever. Closes: #985061
+ * Standards-Version: 4.5.1 (routine-update)
+ * watch file standard 4 (routine-update)
+ * debian/upstream/metadata: add GitHub repo
+
+ -- Michael R. Crusoe Fri, 12 Mar 2021 15:52:36 +0100
+
fsm-lite (1.0-4) unstable; urgency=medium
[ Andrius Merkys ]
diff -Nru fsm-lite-1.0/debian/control fsm-lite-1.0/debian/control
--- fsm-lite-1.0/debian/control 2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/control 2021-03-12 20:22:36.0 +0530
@@ -5,7 +5,7 @@
Priority: optional
Build-Depends: debhelper-compat (= 13),
libsdsl-dev
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
Vcs-Browser: https://salsa.debian.org/med-team/fsm-lite
Vcs-Git: https://salsa.debian.org/med-team/fsm-lite.git
Homepage: https://github.com/nvalimak/fsm-lite
diff -Nru fsm-lite-1.0/debian/patches/fix_makefile.patch
fsm-lite-1.0/debian/patches/fix_makefile.patch
--- fsm-lite-1.0/debian/patches/fix_makefile.patch 2020-11-10
22:06:49.0 +0530
+++ fsm-lite-1.0/debian/patches/fix_makefile.patch 2021-03-12
20:22:36.0 +0530
@@ -1,17 +1,16 @@
Description: Support more architectures
Bug-Debian: http://bugs.debian.org/824368
Author: Andreas Tille
-Last-Update: Sun, 15 May 2016 09:04:46 +0200
-
a/Makefile
-+++ b/Makefile
-@@ -1,11 +1,11 @@
+Last-Update: 2021-03-12
+Forwarded: not-needed
+--- fsm-lite.orig/Makefile
fsm-lite/Makefile
+@@ -1,11 +1,10 @@
-SDSL_INSTALL_PREFIX=${HOME}/software
-
-CPPFLAGS=-std=c++11 -I$(SDSL_INSTALL_PREFIX)/include -DNDEBUG -O3 -msse4.2
+CPPFLAGS+=-DNDEBUG
-+CXXFLAGS+=-std=c++11
-+# -O3 -msse4.2
++CXXFLAGS+=-std=c++11 -O3
LIBS=-lsdsl -ldivsufsort -ldivsufsort64
OBJ = configuration.o input_reader.o fsm-lite.o
@@ -21,7 +20,7 @@
test: fsm-lite
./fsm-lite -l test.list -t tmp -v --debug -m 1
-@@ -14,6 +14,6 @@ clean:
+@@ -14,6 +13,6 @@
$(RM) fsm-lite *.o *~
depend:
diff -Nru fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
--- fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/patches/use_debian_packaged_libsdsl.patch
2021-03-12 20:22:36.0 +0530
@@ -1,6 +1,7 @@
Author: Andreas Tille
Last-Update: Fri, 08 Apr 2016 10:01:02 +0200
Description: Upstream hardcodes local path to libsdsl which is removed here
+Forwarded: not-needed
--- a/dependencies.mk
+++ b/dependencies.mk
diff -Nru fsm-lite-1.0/debian/rules fsm-lite-1.0/debian/rules
--- fsm-lite-1.0/debian/rules 2020-11-10 22:06:49.0 +0530
+++ fsm-lite-1.0/debian/rules 2021
Bug#988228: unblock: golang-testify/1.6.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org
Please unblock package golang-testify
[ Reason ]
The build fails on armhf architecture, due to a failing build time test.
This has been fixed in 1.6.1-2
It also fixes the corresponding RC bug: #988101
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988101
[ Impact ]
The package will fail to build from source on armhf
[ Tests ]
It has non-trivial autopkgtests that cover the testing to the changes.
Autopkgtests pass for golang-testify
It also looks good when I tested it locally
[ Risks ]
No risks, trivial change to make it buildable across armhf.
[ 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 golang-testify/1.6.1-2
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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
diff -Nru golang-testify-1.6.1/debian/changelog
golang-testify-1.6.1/debian/changelog
--- golang-testify-1.6.1/debian/changelog 2020-09-28 04:00:48.0
+
+++ golang-testify-1.6.1/debian/changelog 2021-05-08 04:25:09.0
+
@@ -1,3 +1,11 @@
+golang-testify (1.6.1-2) unstable; urgency=medium
+
+ * Team Upload.
+ * d/p/do-not-use-race.patch: Drop -race flag with
+golang in TestFailfastSuiteFailFastOn (Closes: #988101)
+
+ -- Nilesh Patra Sat, 08 May 2021 12:25:09 +0800
+
golang-testify (1.6.1-1) unstable; urgency=medium
* Team upload.
diff -Nru golang-testify-1.6.1/debian/patches/do-not-use-race.patch
golang-testify-1.6.1/debian/patches/do-not-use-race.patch
--- golang-testify-1.6.1/debian/patches/do-not-use-race.patch 1970-01-01
00:00:00.0 +
+++ golang-testify-1.6.1/debian/patches/do-not-use-race.patch 2021-05-08
04:25:09.0 +
@@ -0,0 +1,19 @@
+Description: The "-race" flag for golang is available only for amd64, arm64,
ppc64el. Since this is being used only in a test, it can be dropped
+Author: Nilesh Patra
+Bug-Debian: https://bugs.debian.org/988101
+Last-Update: 2021-05-08
+--- a/suite/suite_test.go
b/suite/suite_test.go
+@@ -552,10 +552,10 @@
+ }
+ func TestFailfastSuiteFailFastOn(t *testing.T) {
+ // To test this with failfast on (and isolated from other intended test
failures in our test suite) we launch it in its own process
+- cmd := exec.Command("go", "test", "-v", "-race", "-run",
"TestFailfastSuite", "-failfast")
++ cmd := exec.Command("go", "test", "-v", "-run", "TestFailfastSuite",
"-failfast")
+ var out bytes.Buffer
+ cmd.Stdout = &out
+- t.Log("Running go test -v -race -run TestFailfastSuite -failfast")
++ t.Log("Running go test -v -run TestFailfastSuite -failfast")
+ err := cmd.Run()
+ t.Log(out.String())
+ if err != nil {
diff -Nru golang-testify-1.6.1/debian/patches/series
golang-testify-1.6.1/debian/patches/series
--- golang-testify-1.6.1/debian/patches/series 1970-01-01 00:00:00.0
+
+++ golang-testify-1.6.1/debian/patches/series 2021-05-08 04:25:09.0
+
@@ -0,0 +1 @@
+do-not-use-race.patch
Bug#991919: transition: r-api-bioc-3.13
On 9/11/21 12:27 PM, Andreas Tille wrote: > Hi, > > the blockers mentioned below are done now. Those who have some > spare time might like to continue with the transition. I will > not contribute relevant things until Tuesday. I did few uploads to get the transition moving forward. Current blocker is for r-bioc-biocsingular which needs r-bioc-scaledmatrix and the latter is still in NEW. For scaledmatrix, I've asked already on the #-ftp IRC as well, hopefully it gets proc soon. This is blocking a few packages, but I'm in the process of uploading the rest which are not directly uploaded. Will upload a few packages tomorrow as well. > There is one thing I would love to be solved soon: I just cheated > with the test suite of biomformat in this patch: > > > https://salsa.debian.org/r-pkg-team/r-bioc-biomformat/-/blob/master/debian/patches/fixme_disable_test_for_the_moment.patch Looking at the error, and also at the calls for those, they are called with `suppressWarnings(read_biom(min_sparse_hdf5))` So probably the file was not good already, since it explicitly tries to suppress warnings. _*Maybe*_ in this release, there were a few changes that rendered the file unusable to for analysis. To me, it does not appear high priority. > I would love if somebody could find a fix - may be by discussing > with upstream. No time, sorry :) Cheers, -- Nilesh Patra Debian Developer, Uploading ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ nil...@debian.org / nileshpatra.info / tchncs.de ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#998057: transition: r-api-bioc-3.14
Hi Sebastian, On Sun, 7 Nov 2021 17:46:56 +0100 Sebastian Ramacher wrote: > > Hi, > > Bioconductor 3.14 was released [1]. > > > > [1] https://bioconductor.org/news/bioc_3_14_release/ > > > > Like for previous r-api-bioc transitions, all reverse dependencies > > need a manual upgrade to the new upstream releases, they are not > > binNMU-able. The Debian R Packages team will do so. > > > > Please set up a tracker manually, since this is a transition of a > > virtual package name. > > Let's do this one after gsl Sorry to get on your nerves, but since it has been a little more than two weeks since you sent this email, is there any update on gsl transition, or is it nearing completion or so? Can bioc start sometime soon? Let me know. Regards, Nilesh signature.asc Description: PGP signature
Bug#998057: Bioc-transition has started (Was: Re: Bug#998057: transition: r-api-bioc-3.14)
On Tue, Nov 23, 2021 at 08:07:49PM +0100, Sebastian Ramacher wrote: > Please go ahead. Thanks a lot. @All, me and Andreas have kick started the transition. Right now, we are at dependency level 2. Should you have free cycles, do not hesitate to chime in. Here is the tracker for $more info[1] [1]: https://release.debian.org/transitions/html/r-api-bioc-3.14.html Regards, Nilesh signature.asc Description: PGP signature
Bug#998057: transition: r-api-bioc-3.14
On 24 November 2021 12:37:49 am IST, Sebastian Ramacher wrote: >Control: tags -1 = confirmed > >On 2021-11-23 23:32:46, Nilesh Patra wrote: >> Hi Sebastian, >> >> On Sun, 7 Nov 2021 17:46:56 +0100 Sebastian Ramacher >> wrote: >> > > Hi, >> > > Bioconductor 3.14 was released [1]. >> > > >> > > [1] https://bioconductor.org/news/bioc_3_14_release/ >> > > >> > > Like for previous r-api-bioc transitions, all reverse dependencies >> > > need a manual upgrade to the new upstream releases, they are not >> > > binNMU-able. The Debian R Packages team will do so. >> > > >> > > Please set up a tracker manually, since this is a transition of a >> > > virtual package name. >> > >> > Let's do this one after gsl >> >> Sorry to get on your nerves, but since it has been a little more than two >> weeks since >> you sent this email, is there any update on gsl transition, or is it nearing >> completion or so? >> Can bioc start sometime soon? > >Please go ahead. If the two transitions need to be untangled, I'll >temporarily remove r-bioc-dirichletmultinomial and r-bioc-tfbstools from >testing. Hi Sebastian, One i386 autopkgtest failure for r-bioc-biocparallel is stalling the entire migration. Rest stuff looks okay. For now, could you please set it to ignore? We will deal with it post migration. Regards, Nilesh
Bug#998057: transition: r-api-bioc-3.14
On 1 December 2021 9:36:00 pm IST, Andreas Tille wrote: >Hi Graham, > >Am Wed, Dec 01, 2021 at 01:33:15PM +0200 schrieb Graham Inggs: >> On Wed, 1 Dec 2021 at 13:03, Nilesh Patra wrote: >> > One i386 autopkgtest failure for r-bioc-biocparallel is stalling the >> > entire migration. Rest stuff looks okay. >> >> There's at least one more regression; in gffread, caused by >> r-bioc-gviz [1]. Please check that each r-bioc* package is ready to >> migrate. > >I absolutely fail to understand why the excuses mechanism is actually >blaming r-bioc-gviz to be responsible to cause that autopkgtest error. >I even fail to understand why it ends up in an error while there are >warnings only. I've re-triggered gffread CI test in Salsa[2] which is >passing. > >Any idea what might be wrong here? > >Kind regards > > Andreas. > >> [1] https://qa.debian.org/excuses.php?package=r-bioc-gviz >[2] https://salsa.debian.org/med-team/gffread/-/jobs/2236429 > Because the version from testing 0.12.1-4 is failing which does not have allow-stderr restriction. The new version 0.12.7 you uploaded has it. The new version is blocked from migrating because of libgclib. libgclib is further blocked from migrating because of ABI breakage. And this change is in NEW. So we are moving in circles. Why are simple changes so slow so god damn difficult to do at times?! I guess a not very good workaround would be to add an explicit breaks for gffread (<< 0.12.1-4~) in r-bioc-gviz that would tell Britney the right thing to do. More ideas welcome. Nilesh
Bug#998057: transition: r-api-bioc-3.14
On 1 December 2021 11:01:12 pm IST, Andreas Tille wrote: >But this is set[3]. If not Salsa-CI should fail. You are testing it on a different version than in testing that's why it passes. If you want to validate, trigger CI on the upload commit for 0.12.1-4 >Moreover, the issue >is not connected at all to any r-bioc-* package since those packages >do not trigger any warning (which is actually issued by libgclib (may >be an upload of this package has triggered any failure - but it remains >unclear why). Actually, it started issuing a warning with regards to some white space/tab problem. Something else changed and it is already failing in testing. But yes, it has little to do with any bioconductor package here. On 1 December 2021 11:04:13 pm IST, Andreas Tille wrote: >But may be if you can work around this with some hinting that is the >easier solution here Yep. That'd be awesome. But we should make a list of all such packages and ping for Graham/Sebastian to propagate the hints accordingly. Probably that's what Graham wanted to say in the first place. Regards, Nilesh
Bug#998057: transition: r-api-bioc-3.14
Hi Graham, On 12/2/21 2:48 AM, Graham Inggs wrote: I've already added hints marking r-bioc-biocparallel/1.28.2-2 urgent and gffread/0.12.1-4 as a bad test, so please do let us know if there are others. Yes, I could spot some more. Please set these to ignore, or Let me know if I should rather workaround to do new uploads with versioned deps. :- * r-bioc-rsamtools -- blocked due to biocparallel in testing * r-bioc-biobase -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-bluster -- blocked due to r-bioc-scran in testing * r-bioc-genomicranges -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-iranges -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-rhdf5lib -- blocked due to r-bioc-rhdf5 in testing * r-bioc-rhdf5filters -- blocked due to r-bioc-rhdf5 in testing * r-bioc-s4vectors -- blocked due to r-bioc-multiassayexperiment in testing * r-bioc-summarizedexperiment -- blocked due to r-bioc-multiassayexperiment in testing Please push urgency for these (just uploaded) :- * r-bioc-scuttle version 1.4.0+dfsg-2 Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)
On 3 December 2021 9:41:48 pm IST, Julien Cristau wrote:
>On Tue, Sep 07, 2021 at 12:27:05AM +0530, Nilesh Patra wrote:
>> diff -Nru segemehl-0.3.4/debian/patches/arm64.patch
>> segemehl-0.3.4/debian/patches/arm64.patch
>> --- segemehl-0.3.4/debian/patches/arm64.patch1970-01-01
>> 05:30:00.0 +0530
>> +++ segemehl-0.3.4/debian/patches/arm64.patch2021-09-06
>> 23:43:50.0 +0530
>> @@ -0,0 +1,75 @@
>> +Description: Change the signed-ness for several chars to fix segfault
>> +Author: Nilesh Patra
>> +Last-Update: 2021-08-24
>> +--- a/libs/biofiles.c
>> b/libs/biofiles.c
>> +@@ -1916,7 +1916,7 @@
>> + Uint max, Uint *minlen, Uint *maxlen, unsigned char *minq, unsigned
>> char *maxq)
>> + {
>> +
>> +- char ch;
>> ++ signed char ch;
>> + char idchar=0;
>> + int ret=0;
>> + off_t curseqoffset, lastindexoffset=0;
>
>Shouldn't `ch` be an `int` instead, to match the return value of getc,
>and type of EOF?
>
>Anyway, I guess this is fine if it works...
Should I upload this to p-u?
Bug#1031134: unblock: python-cogent/2022.10.31a1+dfsg-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: python-cog...@packages.debian.org Control: affects -1 + src:python-cogent Please unblock package python-cogent This package was earlier stuck due to numba incompat with python3.11 and then later due to a redundant build-dep on jupyter-sphinx. This was uploaded recently after other issues got sorted out. [ Reason ] It would be great to have this package back to testing and also in bookworm. [ Impact ] Users would loose this package in new release. [ Tests ] It has autopkgtests which pass as per britney [ Risks ] This is a leaf package so no risk. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ Other info ] I have not attached any debdiff as this is not in testing and hence no reference to take diff against. unblock python-cogent/2022.10.31a1+dfsg-3
Bug#1031136: unblock: python-pynndescent/0.5.8-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package python-pynndescent This package was earlier stuck due to some precision issues on ppc64el. By the time that got sorted, python3.11 came in and one of its dependencies (sparks) depended on numba which was incompatible with python3.11 until very recently. [ Reason ] It would be great to have this package back to testing and also in bookworm. [ Impact ] Users would loose this package in new release. And there are bug reports from users on this package so it is not a lost thing. [ Tests ] It has autopkgtests which are passing in britney at the moment. It also runs built time tests. [ Risks ] It has only one reverse-dependency which is also out of testing at the moment. No risk as such. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ Other info ] I have not attached any debdiff as this is not in testing and hence no reference to take diff against. unblock python-pynndescent/0.5.8-2
Bug#1034063: unblock: ruby-maven-libs/3.3.9+ds-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ruby-maven-l...@packages.debian.org Control: affects -1 + src:ruby-maven-libs Please unblock package ruby-maven-libs [ Reason ] Letting this through helps fix RC bug#1033912 which indicates autopkgtest failure [ Impact ] Package with failing autopkgtest would go through bookworm [ Tests ] Autopkgtests are now passing with new release. Since the test is relatively minimal, a superficial tag has been added. [ Risks ] No risk, this is a leaf package with minimal changes. [ 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 ruby-maven-libs/3.3.9+ds-4
Bug#1010422: transition: r-api-bioc-3.15
On Sun, 1 May 2022 11:42:07 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= wrote: > Hi, > Bioconductor 3.15 has been released [1]. Please hold this off until r-base migrates (which should be soon) -- Best, Nilesh signature.asc Description: PGP signature
Bug#1010422: transition: r-api-bioc-3.15
On 2 May 2022 11:54:34 am IST, Andreas Tille wrote: >Am Mon, May 02, 2022 at 09:39:25AM +0530 schrieb Nilesh Patra: >> On Sun, 1 May 2022 11:42:07 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= >> wrote: >> > Hi, >> > Bioconductor 3.15 has been released [1]. >> >> Please hold this off until r-base migrates (which should be soon) > >As far as I can see the testing migration is blocked by > >Isn't this the just discussed Graphics API issue? There were many more of 'em blocking the transition. I cleaned that up yesterday and reduced it to the one remaining. >I guess your recent upload of 0.1.2.1-3 is supposed to fix this and >is intended to enable the migration, right? > Yes, let's wait until r-base migrates, I guess it'd take a day or two maybe. Anyway we need to wait for bioc transition until we get a thumbs up from release team. Migrating the graphics packages are also a mess now due to no-binNMUs. Need to propagate hacks to get these in testing. All of it could have been avoided if it was properly coordinated, but anyway. >[1] >https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-thematic/21293099/log.gz > -- Best, Nilesh
Bug#1010422: transition: r-api-bioc-3.15
On Tue, May 03, 2022 at 04:04:22PM +0200, Graham Inggs wrote: > Control: tags -1 + moreinfo > > I am now trying to get ggplot2 and friends in testing. Please give > > it time until this weekend to migrate after which I will remove > > my hacks and re-upload. > > Please also look at rmatrix, it is a build-dependency of several > r-bioc-* packages. That'd get in once ggplot2 and friends transition. Should be soonish. > > Let's start bioc transition after this is done. > > Please remove the moreinfo tag once you are ready. Sure, thanks Graham! -- Best, Nilesh signature.asc Description: PGP signature
Bug#1010422: transition: r-api-bioc-3.15
Control: tags -1 - moreinfo Hi Graham/Andreas, On Tue, May 03, 2022 at 04:04:22PM +0200, Graham Inggs wrote: > On Tue, 3 May 2022 at 15:51, Nilesh Patra wrote: > > I am now trying to get ggplot2 and friends in testing. Please give > > it time until this weekend to migrate after which I will remove > > my hacks and re-upload. > > Please also look at rmatrix, it is a build-dependency of several > r-bioc-* packages. I think I did the changes as I wanted to, all graphics packages and all the important cran packages for that matter (including rmatrix) have now migrated. > > Let's start bioc transition after this is done. > > Please remove the moreinfo tag once you are ready. I have done so, I think we can start the transition. Please consider pushing the buttons to get the tracker up :) PS: I will not be able to contribute in any capacity to bioc transition and hope Andreas, you, Dylan et. al. would complete this :) -- Best, Nilesh signature.asc Description: PGP signature
Bug#1010422: transition: r-api-bioc-3.15
On 11 May 2022 2:06:08 pm IST, "Dylan Aïssi" wrote: >Hi all, > >> Am Fri, May 06, 2022 at 06:10:52PM +0530 schrieb Nilesh Patra: >> > >> > I have done so, I think we can start the transition. Please consider >> > pushing >> > the buttons to get the tracker up :) >> > >To be sure, have we the green light from the release team to start >this transition? @Graham, could you let us know? -- Should we start? -- Best, Nilesh
Bug#1010422: Britney fails to pin complete set in "Provides" api transitions [Was: Bug#1010422: transition: r-api-bioc-3.15]
Hi, On 19 May 2022 1:10:23 pm IST, Paul Gevers wrote: >Package: release.debian.org >User: release.debian@packages.debian.org >Usertag: britney > >Hi, > >On 11-05-2022 12:34, Graham Inggs wrote: >> Yes, please go ahead. >> >> Tracker is at: >> https://release.debian.org/transitions/html/r-api-bioc-3.15.html > >There's three package still waiting for an upload, r-bioc-progeny, >r-bioc-monocle and r-bioc-scater. When is the ETA for those? They are blocked by packages in NEW so whenever FTP masters accept these. I think we can workaround these anyway by editing the DESCRIPTION file -- maybe I'll do so and upload either late in the night today or early morning Tom. >Apart from these missing uploads, there's a bunch of autopkgtest regressions >blocking the migration of the set [1]. I have a hunch that quite some >regressions are caused by missing *versioned* (test) dependencies that cause >incompatible sets to be tested. Many of these are also due to versioned depends I guess. > Thinking more about it that could very well be a bug in our migration > software failing to properly handle the Provides which glues this all > together and which is uniquely provided by r-bioc-biocgenerics. Remember that > our migration software tries to determine the minimal (source based) [...] I know, if that could be improved, it'd be awesome otherwise it's a pain to deal with. Even for an earlier r-base transition, I had to do bogus uploads to make Britney happy. It does not make much sense to me to add a breaks for things and clutter d/control. There's no real usecase to be honest since there's already a version dep on r/r-api-bioc respectively. > if the manual pinning helps, we'll need to see how to improve it. Thanks Paul for your work! >[1] https://people.debian.org/~elbrus/ci/regressions.html >[2] >https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-megadepth/21776746/log.gz -- Best, Nilesh
Bug#1010422: Britney fails to pin complete set in "Provides" api transitions [Was: Bug#1010422: transition: r-api-bioc-3.15]
On 19 May 2022 2:25:23 pm IST, Andreas Tille wrote: >Am Thu, May 19, 2022 at 01:41:12PM +0530 schrieb Nilesh Patra: >> >> I think we can workaround these anyway by editing the DESCRIPTION file -- >> maybe I'll do so and upload either late in the night today or early morning >> Tom. > >I do not think that editing DESCRIPTION is the prefered way to >fix our transition. As I wrote in my other mail removing them >from testing manually should do the trick as well, IMHO. I disagree. I don't really think stalling the migration just for a couple of packages is a sensible thing to do. There is not a functional difference (real API change) so keeping a couple of packages outdated (and that too because pre-deps are in new) is no big deal. We already have tons of cran stuff being backdated due to several reasons, I don't think this situation is very different. I know the bioc api is different but there's no functional difference in working of package at all. I would rather do what it takes and complete the transition, so as to unbreak packages and also not consume un-necessary bandwidth of release team members. And so, I'd continue to patch description and upload anyway. If you're very/extremely against it, please do let me know soon so we figure out something else. -- Best, Nilesh
Bug#1010422: Bug#1011265: Britney fails to pin complete set in "Provides" api transitions [Was: Bug#1010422: transition: r-api-bioc-3.15]
Hi Graham, I did some work to cleanup the rest stuff meanwhile, and need your help to ignore some of the CI temporarily to complete the migration; and also because unstable counterparts pass. I have pasted a list at the end of this email, please see to it. -- Best, Nilesh Package Reverse dependency r-bioc-annotationdbiset ignore for r-bioc-annotationhub (version in unstable passes) r-bioc-scran/beachmat Please run tests with new version of biocparallel r-bioc-biocneighborsset r-bioc-bluster to ignore (version in unstable passes) r-bioc-biocparallel set r-bioc-bluster to ignore (version in unstable passes) Other caveats: r-bioc-singler/r-bioc-scran (at the time of writing this email) need to run with new version of biocparallel in unstable and the versions of reverse-deps should point to its unstable version OpenPGP_signature Description: OpenPGP digital signature
Bug#1010422: Bug#1011265: Britney fails to pin complete set in "Provides" api transitions [Was: Bug#1010422: transition: r-api-bioc-3.15]
On 22 May 2022 7:05:18 pm IST, Andreas Tille wrote: >Hi Graham, > >Am Sun, May 22, 2022 at 09:09:01AM +0200 schrieb Graham Inggs: >> It looks like the only blocker now is waiting for r-bioc-scater [1] to age: >> >> Too young, only 2 of 5 days old >> >> It doesn't get 2-day migration because its autopkgtest regressed in >> testing, sometime around 2021-09-23 [2]. > >I've just commited a patch thet ignores the not yet packaged test >dependency which causes the test failure. In any case r-bioc-scater Then please make an upload. >needs to wait for r-cran-rcppml in new - may be some removal from >testing is needed in any case. No, not really. I had already edited the description file in the last upload to unbreak the transition, although I didn't observe the failing test locally. >> [1] https://tracker.debian.org/pkg/r-bioc-scater >> [2] https://ci.debian.net/packages/r/r-bioc-scater/testing/amd64/ > -- Regards, Nilesh
Bug#995636: transition: openssl
Hi, Is there an ETA for this? Asking since openssl is blocking a number of rev-deps from migrating for almost a month by now. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1023731: BioC Transition blocked by new dependencies
On Mon, Nov 21, 2022 at 06:11:41PM +0100, Andreas Tille wrote: > Hi Adrian and others, > > Am Mon, Nov 21, 2022 at 06:33:52PM +0200 schrieb Adrian Bunk: > > > This is really hard to do, thought. The new packages are needing those > > > packages from the transition. I actually injected two packages from > > > higher levels manually to be able to build one of the new packages. So > > > we really need to upload the start of the transition and I do not see > > > any sense in not documenting what we are doing without the transition > > > tracker. > > >... > > > > Your transition is special because you are manually uploading every > > single package involved in the transition. > > > > You could upload everything to experimental, run a local ben tracker > > against experimental, and when the transition is complete in > > experimental contact the release team for the transition in unstable. > > > > The actual transition is then a batch of "Upload to unstable". > > Thanks for all helpful hints. I understand that with some effort over > the current workflow it is possible to do the transition differently. > The only thing which I did not yet understood is the actual drawback of > the current workflow. I do not think that it takes specifically longer > than other transition - we just have a different set of showstoppers to > get it done in 24 hours. Personal experience+opinion: I have been involved with quite a few bioc transitions and often times you and me were the _only_ people who did the entire transition. I have noticed several times that the NEW processing takes quite sometime, and the way forward (for me) has been to manually patch the DESCRIPTION file to patch it to be compatible with new r-bioc api until the dependency from new is accepted. The new processing time tends to create delay with respect to bioc packages migrating to testing and this creats a terrible amount of noise. And then what comes next is a bunch of workarounds to get things moving, and this takes a quite a lot of energy at my end which I'd like to spend somewhere else. I have not been entirely happy with the way it happens, and would like if we can do the transition differently with less friction, less days of wide-uninstallability. The advantage with a reprepo thing that Sebastian suggests is that everything (possibly) will migrate as soon as it is uploaded. Once you have stored the sources into a reprepo, all you need to do is run a script to do all the uploads. > In the past we got support by ftpmaster when > pinging them and explaining the transition issue. Which takes time as well, and at least my experience regarding transition new processing has not been quite same as you. Lastly I also want to higlight that: while bioc transition is in theory a transition (I agree) but to my understanding, there is no _real_ API change. It is just the tool taking the API field from DESCRIPTION file into consideration, and causing FTBFS if it does not match. In principle, building a package that has an older API value in DESCRIPTION file with the newer one does not break anything, it rather looks as updates of various packages disguised as an API change, and at least in debian land, to me it just appears as a broken tool config and not a real transition (like library transition, for example the recent onetbb one). -- Best, Nilesh signature.asc Description: PGP signature
Re: transition: pandas 1.3 -> 1.5
On 6 January 2023 1:26:05 pm IST, "Rebecca N. Palmer" wrote: >Should this go ahead before the freeze? I think yes if the new dask works, >but am open to disagreement. The version of dask is same since few months. What do you mean by new dask? >skbio #1017574 This has been fixed in latest upload of skbio, I closed the bug sometime ago. Thanks, -- Best, Nilesh
Bug#1036047: unblock: nlopt/2.7.1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: nl...@packages.debian.org Control: affects -1 + src:nlopt Please unblock package nlopt [ Reason ] This upload was done due to address a piuparts error while upgrading nlopt from bullseye -> bookworm, see #1035629. [ Impact ] Loss of files in usr/share/doc/libnlopt0 maybe observed, and over-writing files too, which is not desired. [ Tests ] Manual tests done locally by upgrading from version in bullseye to bookworm, and then removing packages individually, and inspected the contents of the doc directories -- did not see any surprises. [ Risks ] As the upload touches only the doc section only, the package is un-affected in terms of it's core (library) functionality. No big risks. [ 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 nlopt/2.7.1-5 diff -Nru nlopt-2.7.1/debian/changelog nlopt-2.7.1/debian/changelog --- nlopt-2.7.1/debian/changelog2022-04-14 15:10:53.0 + +++ nlopt-2.7.1/debian/changelog2023-05-14 09:35:20.0 + @@ -1,3 +1,13 @@ +nlopt (2.7.1-5) unstable; urgency=medium + + * Team Upload. + * Add maintscript to convert libnlopt-dev doc +symlink to directory (Closes: #1035629) + * Add a preinst to remove examples directory in libnlopt0 +which should be present in -dev only + + -- Nilesh Patra Sun, 14 May 2023 09:35:20 + + nlopt (2.7.1-4) unstable; urgency=medium * Team upload diff -Nru nlopt-2.7.1/debian/libnlopt0.preinst nlopt-2.7.1/debian/libnlopt0.preinst --- nlopt-2.7.1/debian/libnlopt0.preinst1970-01-01 00:00:00.0 + +++ nlopt-2.7.1/debian/libnlopt0.preinst2023-05-14 09:35:20.0 + @@ -0,0 +1,6 @@ +#!/bin/sh -e +# directory moved to -dev package, the symlink from past upgrade should be removed +if [ -d /usr/share/doc/libnlopt0/examples ]; then + rm -rf /usr/share/doc/libnlopt0/examples +fi +#DEBHELPER# diff -Nru nlopt-2.7.1/debian/libnlopt-dev.maintscript nlopt-2.7.1/debian/libnlopt-dev.maintscript --- nlopt-2.7.1/debian/libnlopt-dev.maintscript 1970-01-01 00:00:00.0 + +++ nlopt-2.7.1/debian/libnlopt-dev.maintscript 2023-05-14 09:35:20.0 + @@ -0,0 +1 @@ +symlink_to_dir /usr/share/doc/libnlopt-dev libnlopt0 2.7.1-5~
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi On Tue, May 16, 2023 at 03:01:10PM +0200, Andreas Tille wrote: > when fixing bug #1035428 I realised test suite issues with > > r-cran-thematic [1] >-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, > always_valid)`: Graphics API version mismatch > > r-cran-treescape [2] > r-cran-treespace [3] >-> error is given if lambda is outside of [0,1] --- > `medTree(trees, -1)` did not throw an error. > > As far as I can guess at least the first type of error (Graphics API > version mismatch) is caused by the fact that a new upstream version of > r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to > experimental so it seems by accident). I can think of two ways: 1. r-cran-shiny is an arch:all package, so the package itself being built against r-base 4.3.0 is not an issue. The issue is the "r-base-core (>= 4.3.0-1)" that dh-r injects, which is being pulled in the autopkgtests of its reverse-depends. Changing that to "r-base-core (>= 4.2.2.20221110-2)" manually should do the trick. Something on the lines of: override_dh_gencontrol: dh_gencontrol sed "s/r-base-core (>= 4.3.0-1)/r-base-core (>= 4.2.2.20221110-2)" -i debian/r-cran-shiny/DEBIAN/control Ofcourse, the hard-coding of 4.3.0-1 can be converted to some better regular expression. 2. It makes a valid and strong case to use t-p-u (see here[5]) for such an upload, as it isn't a possibility to build against R in testing. You might want to ask release team about it, by filing a bug for release.d.o pseudo-package and/or asking in #debian-release on OFTC. I personally prefer "1" over 2 as it is less noise (and effort). Let me know what you think. > [1] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > [2] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > [3] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > [4] > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 08:26:21AM -0500, Dirk Eddelbuettel wrote: > Note that none of this affects the release. My recommendation is temporarily > suspend the autopkgtest in those affected packages. No, don't do that as they indicate a new r-base being pulled as one of the dependencies (which would be incorrect for a package). In this case, r-cran-shiny has a hard-dependency on r-base. Once that is fixed, rest of the things should be sorted out. -- Best, Nilesh signature.asc Description: PGP signature
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > I personally prefer "1" over 2 as it is less noise (and effort). On second thoughts, I think sending it via testing-proposed-updates would be a better thing to do, as this case perfectly fits the problem. It's be same effort in both cases (one upload + filing a bug with release team). > Let me know what you think. > > [1] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > [2] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > [3] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > [4] > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 09:31:20AM -0500, Dirk Eddelbuettel wrote: > > On 16 May 2023 at 19:49, Nilesh Patra wrote: > | On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > | > I personally prefer "1" over 2 as it is less noise (and effort). > | > | On second thoughts, I think sending it via testing-proposed-updates > | would be a better thing to do, as this case perfectly fits the problem. > | > | It's be same effort in both cases (one upload + filing a bug with release > team). > > Reading 'https://wiki.debian.org/TestingProposedUpdates' does indeed suggest > that this may be one of those situations. I can easily prepare a 4.3.0-2 > with that destination but would prefer if someone from the release could > 'nod', maybe in reply to this email. Uh, no. Maybe you misunderstood my suggestion. The t-p-u way was for r-cran-shiny not the r-base package. This is because r-cran-shiny would want to build against r-base in testing (and not unstable). Uploading a 4.3.0-2 of r-base would mean uploading a new r-base to testing without a proper transition and without re-compilation of API-incompatible graphics related packages -- that'd be quite the havoc in testing (and eventually next stable). It also violates some of the rules of t-p-u -- more details here[1] in case you are interested. r-base can continue to stay where it already is at the moment :) [1]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u -- Best, Nilesh signature.asc Description: PGP signature
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Wed, May 17, 2023 at 08:58:58AM +0200, Andreas Tille wrote: > Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > > I personally prefer "1" over 2 as it is less noise (and effort). > > > > On second thoughts, I think sending it via testing-proposed-updates > > would be a better thing to do, as this case perfectly fits the problem. > > I hope I was following developers reference about t-p-u[6] correctly > and pushed > I've choosen the version 1.7.4+dfsg-3~deb12u1 to match > the requirement that the version is lower than in unstable I guess this should be alright. But as per devref, you may want to choose "1.7.4+dfsg-2+deb12u1". > I wonder whether dput is working with target distribution bookworm since > lintian throws an error. It probably should. There's a d/ch entry I found for argon2 package here[7] in case that helps you. > Release team is in CC - do you think I should > file a bug right now or just after an upload? devref says "Ask for authorization for uploading from the release managers." So I suppose it makes sense to file a bug before you upload and ping them back again once you upload as per "After uploading and successful build on all platforms, contact the release team at debian-release@lists.debian.org and ask them to approve your upload." > > > > [1] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > > [2] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > > [3] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > > [4] > > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > > [5] https://wiki.debian.org/TestingProposedUpdates > [6] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u [7] https://tracker.debian.org/news/1429925/accepted-argon2-020171227-03deb12u1-source-into-testing-proposed-updates/ -- Best, Nilesh signature.asc Description: PGP signature
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Hi Paul, On Thu, Jul 06, 2023 at 08:28:45PM +0200, Paul Gevers wrote: > On 06-07-2023 19:08, Paul Gevers wrote: > > Yes, we'll take care of that where it looks sane to do so (examples of > > that are r-cran-epi); I'll manually schedule the "combined" tests, such > > that they disappear from the excuses if they then pass. > > I'm seeing in several tests where things seem to work when r-cran-tibble > from unstable is involved and fail if the version from unstable is used; > e.g. here: https://ci.debian.net/packages/r/r-cran-rsample/testing/amd64/ > > Is there something special about r-cran-tibble? It didn't grow a dependency > on r-graphics-engine according to > https://buildd.debian.org/status/fetch.php?pkg=r-cran-tibble&arch=amd64&ver=3.2.1%2Bdfsg-2&stamp=1688629916&raw=0 > so it doesn't seem to be involved in that part of the discussion. I think we are hitting this issue here: https://github.com/tidyverse/dplyr/issues/6793 The comment says "Looks like some package in the stack sets R_forceSymbols(dll, TRUE)" and that package is tibble | $ grep -rnw R_forceSymbols | src/init.c:19: R_forceSymbols(dll, TRUE); Since you are building with R from unstable and tibble from testing (built with an older R), it chokes and works when both are new. This attribute has got something to do with R extensions' entry points / dll compatibilty, but I simply do not have enough background with r-core to comment beyond this point, I'm afraid. Best, Nilesh signature.asc Description: PGP signature
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On Thu, Jul 06, 2023 at 09:13:46PM +0200, Sébastien Villemot wrote: > > I'm not sure so please explain in more detail. dh-r was designed to put > > the lowest restriction regarding the versions. I remember some > > discussion some time ago that Dirk thought we should put stronger > > restrictions (and he is sometimes adding version restrictions manually > > that are not helpful for backporting). If I will be sure I understand > > your point exactly I can check the code and the relevant discussion. > > (Feel free to file a bug report about this and we can discuss it there > > if you think this makes more sense.) > > It comes from this line: > https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 > > More precisely the “r-base-core (>= $rbase_version)” part, which > imposes an unnecessarily tight restriction on the r-base-core version. Andreas, if you remember, the code pointed out by Sébastien is the exact same reason we had to t-p-u r-cran-shiny during freeze, See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#15 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035428#40 https://tracker.debian.org/news/1431956/accepted-r-cran-shiny-174dfsg-2deb12u1-source-into-testing-proposed-updates/ Best, Nilesh signature.asc Description: PGP signature
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
On Thu, Jul 06, 2023 at 02:24:57PM -0500, Dirk Eddelbuettel wrote: > [...] I understood some of it (not completely, possibly because of lack of background with R extensions), but thanks a lot for taking the time to explain it to me! > So if tibble does this now, it should only affect tibble itself -- unless of > course a dependent package calls directly into the native code of tibble > (possible, but rare). I found some code in vctrs which do some tibble specific stuff, like https://sources.debian.org/src/r-cran-vctrs/0.6.3-1/src/type-tibble.c/ But I don't think there are calls for native code anywhere. No idea where this comes from, then. > | Since you are building with R from unstable and tibble from testing > | (built with an older R), it chokes and works when both are new. > > Not sure I agree. That should still work. Quick check in Docker (using the > r-base image I maintain) shows it does: > > root@f39da83dba5a:/# dpkg -l r-base-core r-cran-tibble | tail -2 Very weird. That means you're unable to repro the failure in https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-rsample/35451568/log.gz Right? Would you have an idea on the github dplyr issue then? The log seems to be the same as we see in the CI https://github.com/tidyverse/dplyr/issues/6793 > It's simpy that testing has an older one and (esp in the tidyverse) things > change quickly and packages want to be in consistent cohort. But AFAICS, in both the scenarios (with and without failure) it is essentially running with the same version of tidyverse, so ideally pulling tibble from unstable and mixing it with an older tidyverse should break, right? (It's the opposite here and I'm quite confused). > | This attribute has got something to do with R extensions' entry > | points / dll compatibilty, but I simply do not have enough background > | with r-core to comment beyond this point, I'm afraid. > > Hope the above helped a little. Yes, thanks again. Best, Nilesh signature.asc Description: PGP signature
Bug#1040498: Help for Bioconductor transition needed: using Debian packaged libraries in r-bioc-rhdf5filters
On Fri, Jul 21, 2023 at 10:35:57AM +0200, Andreas Tille wrote: > I've just pushed r-bioc-rhdf5filters to salsa[1]. We are replacing code > copies of several compression related libs by the Debian equivalents. > Seems upstream added zstd and thus I added libzstd-dev to Build-Depends > and tried to fix the according patch. But it went more complex. The > issues are occuring when trying to build Pushed a fix to salsa please test before upload and please add my work to d/ch. Best, Nilesh signature.asc Description: PGP signature
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
On Sat, Jul 29, 2023 at 07:44:32PM +0200, Paul Gevers wrote: > Well, I didn't check everything yet (hint is at [1]) but at least the > autopkgtest regression in r-bioc-rhdf5filters (see [2] to find that in > unstable it fails too) should really be solved. I've fixed hdf5filters and uploaded to unstable. This was a fallout with the patch I had supplied earlier. Thanks for pointing it out. Best, Nilesh signature.asc Description: PGP signature
Re: Matrix update triggering need for four rebuilds
On 17 November 2023 11:34:21 pm IST, Dirk Eddelbuettel wrote: > >On 17 November 2023 at 18:43, Andreas Tille wrote: >| Am Fri, Nov 17, 2023 at 10:12:02AM -0600 schrieb Dirk Eddelbuettel: >| > Leaving >| > >| >r-cran-irlba >| >r-cran-openmx >| > >| > for you (unless you got to it already). >| >| To make it pretty clear: I will not simply rebuild these packages before >| we have a promising solution for the future. If you do not agree with >| this you can either >| >|* Ask for Bin-NMU which should be sufficient >|* Do a team upload > >"Our users are our preference". Debian Social Contract. You don't get to play this card with uncoordinated transitions. Nobody is stopping you from doing team uploads for these packages fwiw.
Re: Matrix update triggering need for four rebuilds
On 18 November 2023 12:14:37 am IST, Dirk Eddelbuettel wrote: > >On 17 November 2023 at 23:50, Nilesh Patra wrote: >| >| >| On 17 November 2023 11:34:21 pm IST, Dirk Eddelbuettel >wrote: >| > >| >On 17 November 2023 at 18:43, Andreas Tille wrote: >| >| Am Fri, Nov 17, 2023 at 10:12:02AM -0600 schrieb Dirk Eddelbuettel: >| >| > Leaving >| >| > >| >| >r-cran-irlba >| >| >r-cran-openmx >| >| > >| >| > for you (unless you got to it already). >| >| >| >| To make it pretty clear: I will not simply rebuild these packages before >| >| we have a promising solution for the future. If you do not agree with >| >| this you can either >| >| >| >|* Ask for Bin-NMU which should be sufficient >| >|* Do a team upload >| > >| >"Our users are our preference". Debian Social Contract. >| >| You don't get to play this card with uncoordinated transitions. >| >| Nobody is stopping you from doing team uploads for these packages fwiw. > >I tried to explain that upstream (both the package and CRAN) have no real >handle on this so it is by _definition_ what you refer to (in a denigrating >tone) an uncoordinated transition. The transition that's being talked about is the debian one (not the upstream one). This one to be clear: <https://wiki.debian.org/Teams/ReleaseTeam/Transitions> It is being brought up from time to time of you noticed. >I'll will retreat and focus on things I >can control. Likewise.
Bug#1070856: bookworm-pu: package riseup-vpn/0.21.11+ds1-5+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: riseup-...@packages.debian.org, nil...@debian.org
Control: affects -1 + src:riseup-vpn
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
The bug got introduced due to a change in the external services that riseup-vpn
interacts with (riseup's servers) and failing to identify their letsencrypt
certs.
Full details at Bug#1070270
[ Impact ]
The package is rendered unusable and the user will not be able to use riseup-vpn
and connect to the vpn.
[ Tests ]
Tried this on a fresh stable VM with multiple different angles.
This has also been tried on a stable user's machine and the problem is verified
to have been fixed.
[ Risks ]
This is a leaf package and the changes are fairly minimal. Very low risk to
stable.
[ 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 ]
Add patch to fixup client verification problems with
riseup-vpn which renders the package useless otherwise.
At the moment, the current code is unable to identify the
letsencrypt certs. Used a systempool for the same and create
a newcertpool as a fallback. Also added a Depends in d/control
for ca-certificates for the same reason.
[ Other info ]
Since this is a leaf package and the breakage is due to external services, this
may be a
candidate for stable-updates suite as per
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-the-stable-updates-suite
> Examples of circumstances in which the upload may qualify for such treatment
> are:
> ...
> Uploads to stable-updates should target their suite name in the changelog as
> usual, e.g. bookworm.
Since I was confident that this should be accepted, I did a (source-only)
dput/upload.
diff -Nru riseup-vpn-0.21.11+ds1/debian/changelog
riseup-vpn-0.21.11+ds1/debian/changelog
--- riseup-vpn-0.21.11+ds1/debian/changelog 2023-03-09 09:51:22.0
+0530
+++ riseup-vpn-0.21.11+ds1/debian/changelog 2024-05-10 20:13:39.0
+0530
@@ -1,3 +1,15 @@
+riseup-vpn (0.21.11+ds1-5+deb12u1) bookworm; urgency=medium
+
+ * Add patch to fixup client verification problems with
+riseup-vpn which renders the package useless otherwise.
+At the moment, the current code is unable to identify the
+letsencrypt certs. Used a systempool for the same and create
+a newcertpool as a fallback. Also added a Depends in d/control
+for ca-certificates for the same reason.
+(Closes: #1070270)
+
+ -- Nilesh Patra Fri, 10 May 2024 20:13:39 +0530
+
riseup-vpn (0.21.11+ds1-5) unstable; urgency=medium
* Add procps, iproute2 and iptables to Depends (Closes: #1031905)
diff -Nru riseup-vpn-0.21.11+ds1/debian/control
riseup-vpn-0.21.11+ds1/debian/control
--- riseup-vpn-0.21.11+ds1/debian/control 2023-03-09 09:51:22.0
+0530
+++ riseup-vpn-0.21.11+ds1/debian/control 2024-05-10 20:13:39.0
+0530
@@ -52,6 +52,7 @@
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
+ ca-certificates,
iproute2,
iptables,
pkexec,
diff -Nru riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
--- riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
1970-01-01 05:30:00.0 +0530
+++ riseup-vpn-0.21.11+ds1/debian/patches/add-system-certs.patch
2024-05-10 20:13:39.0 +0530
@@ -0,0 +1,27 @@
+From 14cf64b10a97c29688f252a7d9d3481c8484aa1d Mon Sep 17 00:00:00 2001
+From: max b
+Date: Wed, 8 Mar 2023 12:41:45 -0800
+Subject: [PATCH] Add system certs to bonafide
+
+lilypad/float is now using letsencrypt certs for vpnweb so instead of
+instantiating an empty cert pool, we can just use the system pool and
+then add the manually configured cert for backwards compatibility.
+---
+ pkg/vpn/bonafide/bonafide.go | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/pkg/vpn/bonafide/bonafide.go
b/pkg/vpn/bonafide/bonafide.go
+@@ -94,7 +94,11 @@
+
+ // New Bonafide: Initializes a Bonafide object. By default, no Credentials
are passed.
+ func New() *Bonafide {
+- certs := x509.NewCertPool()
++ certs, err := x509.SystemCertPool()
++ if err != nil {
++ log.Println("Error loading SystemCertPool, falling back to
empty pool")
++ certs = x509.NewCertPool()
++ }
+ certs.AppendCertsFromPEM(config.CaCert)
+ client := &http.Client{
+ Transport: &http.Transport{
diff -Nru riseup-vpn-0.21.11+ds1/debian/patches/series
riseup-vpn-0.21.11+ds1/debian/patches/series
--- riseup-vpn-0.21.11+ds1/debian/patches/series2023-02-26
02:39:10.0 +0530
+++ riseup-vpn-0.21.11+ds1/deb
