Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Steven Eker writes: > This is harmless on 64-bit architectures since Index will be a signed > 64-bit integer and if it works on 32-bit architectures, it's a work > around until GMP is fixed (hopefully before 2038). I know this suggestion is unorthodox, and quite possibly moot at this point in the context of official Debian packages -- but you might want to consider formally going through double here, at least on the relevant platforms. Precision loss shouldn't be a concern for another 140 million years or so by my reckoning, and I expect the additional conversion overhead would be negligible in practice. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1065961: sra-sdk: Please drop dependencies on python3-distutils
Graham Inggs writes: > In fact, there is no module for Python 3.12 in python3-distutils, so > these dependencies may already be unnecessary. I hear you, but can't readily determine whether any additional changes would be in order until dh-python drops or downgrades its distutils dependency, which I called out just now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066833 Thanks for the report, though! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1066833: dh-python: depends on legacy python3-distutils
Package: dh-python Version: 6.20240310 Severity: important I'm sure I'm not alone in having a request [1] to ensure a package builds without legacy python3-distutils. However, sra-sdk, for one, uses dh-python, which still depends on python3-distutils. As such, removing the explicit build dependency wouldn't yet break anything, but I can't readily tell what would happen with python3-distutils actually out of the picture. Consequently, I'd appreciate it if dh-python could please go ahead and either downgrade or outright remove its dependency on python3-distutils to facilitate determining what actually still needs it. Thanks! [1] https://bugs.debian/org/1065961 -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Versions of packages dh-python depends on: ii python3 3.11.6-1 ii python3-distutils 3.11.5-1 ii python3-setuptools 68.1.2-2 dh-python recommends no packages. Versions of packages dh-python suggests: ii dpkg-dev 1.22.4 ii flit 3.9.0-2 ii libdpkg-perl 1.22.4 ii python3-build 1.0.3-2 ii python3-installer 0.7.0+dfsg1-2 ii python3-wheel 0.42.0-1 -- debconf-show failed
Bug#1065333: q2-types: test data heavily outweighs actual code
Package: q2-types Version: 2024.2.0-1 Severity: minor The latest q2-types release increased its disk footprint from 800 kB or so to nearly 52 MB. AFAICT, the increase is largely due to the addition of test data, most notably two 19.5+ MB eggnog.db files, a 6.6+ MB eggnog.taxa.db.traverse.pkl accompanying one of them, and six ~720 kB BAM files. If these files are useful for testing the installation, please split them off into a separate binary package that users can install as desired; otherwise, please leave them out altogether. Thanks! -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Versions of packages q2-types depends on: ii libopenblas0 0.3.26+ds-1 ii python3 3.11.6-1 ii python3-biom-format 2.1.15.2-3 ii python3-h5py 3.9.0-5 ii python3-ijson3.2.3-1 hi python3-numpy1:1.23.5-2 ii python3-pandas 1.5.3+dfsg-12 ii python3-setuptools 68.1.2-2 ii python3-skbio0.5.9-4 ii qiime2024.2.0-1 q2-types recommends no packages. q2-types suggests no packages. -- no debconf information
Bug#1063800: Should we restrict libtread-pool to 64bit only
Andreas Tille writes: >Build-Depends libthread-pool 4.0.0 which does not build >for 32bit architectures[1] I see a fix in experimental: https://buildd.debian.org/status/package.php?p=libthread-pool=experimental Why not just reupload it to unstable? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1063115: fltk1.3: NMU diff for 64-bit time_t transition
Steve Langasek writes: > NOTICE: these changes must not be uploaded to unstable yet! Understood. > Please find the patch for this NMU attached. Got it, thanks! On the .symbols front, I'd think it would make more sense either to reset all versions to 0 (the simplest option) or to arrange for unaffected architectures' dependency templates to read e.g. libfltk1.3t64 #MINVER# | libfltk1.3 #MINVER# Sorry if I missed any relevant discussion; I must confess I haven't followed -devel in years. :-/ -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1058886: irqbalance: floods logs with ---...--- lines
Package: irqbalance Version: 1.9.3-1 Severity: normal Since the latest irqbalance upgrade, I've been encountering log lines like 2023-12-17T10:08:10.722658-05:00 v100a irqbalance[4194303]: #012#012#012- every ten seconds, somewhat burying meaningful logs. Could you please suppress these lines, at least in the absence of --debug? (It's also started logging occasional "Selecting irq N for rebalancing" lines, to which I have no such objection.) Thanks! -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Versions of packages irqbalance depends on: ii init-system-helpers 1.66 ii libc62.37-12 ii libcap-ng0 0.8.3-3 ii libglib2.0-0 2.78.3-1 ii libncursesw6 6.4+20231209-1 ii libnuma1 2.0.16-1 ii libsystemd0 254.5-1 ii libtinfo66.4+20231209-1 ii runit-helper 2.15.2 irqbalance recommends no packages. irqbalance suggests no packages. -- debconf-show failed
Bug#1055761: python3-selenium: *WebKit*/RemoteWebDriver __init__ skew
Package: python3-selenium Version: 4.14.0+dfsg-1 Severity: normal Tags: upstream python3-selenium's WebKitGTK and WPEWebKit backends are both unusable even when supplied explicit executable paths to keep them from trying to go through the (understandably) unpackaged driver manager, because *WebKit*WebDriver.__init__ both call super().__init__ with an unsupported desired_capabilities argument (where super() amounts to RemoteWebDriver). With WebKitGTK, for instance, I get Traceback (most recent call last): [...] File "/usr/lib/python3/dist-packages/selenium/webdriver/webkitgtk/webdriver.py", line 66, in __init__ super().__init__( TypeError: WebDriver.__init__() got an unexpected keyword argument 'desired_capabilities' Could you please take a look? Thanks! -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Versions of packages python3-selenium depends on: ii python3 3.11.4-5+b1 ii python3-certifi 2023.7.22-1 ii python3-trio0.22.2-1 ii python3-trio-websocket 0.11.1-1 ii python3-urllib3 1.26.18-1 Versions of packages python3-selenium recommends: ii chromium-driver 119.0.6045.123-1 python3-selenium suggests no packages. -- debconf-show failed
Bug#869510: dhtnode: please handle connection problems gracefully
Amin Bandali writes: > Have you tried specifying a bootstrap node explicitly with '-b'? I have now; I'd missed that the system instance's use of bootstrap.ring.cx stemmed from a configuration file (/etc/default/dhtnode) that nothing else consulted by default. At this point, dhtnode -b bootstrap.ring.cx and dhtnode -b bootstrap.jami.net both work for me; OTOH, I finally have IPv6 access and as such can no longer speak to what happens with only IPv4. > I suggest we close this bug here on the BTS as well. OK, I'm willing to give it the benefit of the doubt. Thanks for your work here, and sorry for the earlier confusion! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1054267: RM: fltk1.1 -- RoQA; leaf library
Bastian Germann writes: > Please remove fltk1.1. I'm on board with this removal in general. > drawxtl is the only reverse build dependency with "libfltk1.1-dev | > libfltk-dev", so it can also build with fltk1.3. IIRC, our autobuilders ignore alternative build dependencies, so the package will still need a sourceful upload; copying its migration bug accordingly. > I am going to file a RM bug when this is autoremoved from testing. Thanks! To confirm, I don't need to do anything active here, just leave this bug open at RC severity and reencourage drawxtl to migrate? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1053904: location-update can take very long to restart
Package: location Version: 0.9.16-2.1 Severity: normal I've found that restarting location-update (as needrestart prompts me to do after upgrading Python or a shared library it uses) can take ages, to the point where I generally give up and kill the systemctl process, letting the start job continue in the background. Curiously, the service starts fine on boot. Could you please take a look? Please let me know if I can provide any further information that would be helpful. Thanks! -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Versions of packages location depends on: ii python3 3.11.4-5+b1 ii python3-location 0.9.16-2.1 location recommends no packages. location suggests no packages. -- debconf-show failed
Bug#891197: ncbi-blast+ is marked for autoremoval from testing
Control: severity 891197 normal u...@debian.org (Aaron M. Ucko) writes: > For the time being, we can switch to an embedded copy of classic PCRE by > dropping the build dependency on libpcre3-dev; that's of course not a > proper fix, but should at least let us downgrade this bug's severity. Done for now (along with some formal improvements); downgrading severity accordingly. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#891197: ncbi-blast+ is marked for autoremoval from testing
Andreas Tille writes: > On Mon, 21 Aug 2023 15:33:03 GMT this bug was set serious with the consequence > that this package and all its dependencies are creating a lot of noise about > testing removals. So I saw; sorry for the resulting noise. > It would be really great if you could explain upstream the situation and > we could fix this bug in the next couple of weeks. I've been working on landing PCRE2 support upstream. It wound up taking longer than I'd initially anticipated because even though all usage is via a wrapper, it's common to want to know where matches actually start and end, and the relevant data type changed with PCRE2. (The wrapper is belatedly gaining a typedef abstracting this change away, but various call sites maintained by different subteams still need formal updating.) For the time being, we can switch to an embedded copy of classic PCRE by dropping the build dependency on libpcre3-dev; that's of course not a proper fix, but should at least let us downgrade this bug's severity. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1040953: bookworm-pu: package sra-sdk/3.0.3+dfsg-6~deb12u1
"Adam D. Barratt" writes: > FWIW the auto-generated debdiff disagrees - > https://release.debian.org/proposed-updates/bookworm_diffs/sra-sdk_3.0.3+dfsg-6~deb12u1.debdiff Please clear the path for another 3.0.3+dfsg-6~deb12u1 upload, thanks. Sorry about that -- I'd compared against my -6 because that was handier on the relevant host, but my so-far customary workflow turned out to have yielded the same exclusion. I found a reasonably clean way of dropping the exclusion without needing a new tag: manually running dpkg-source -b . -Inonexistent I will look into adjusting my workflow to DTRT. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1040953: bookworm-pu: package sra-sdk/3.0.3+dfsg-6~deb12u1
u...@debian.org (Aaron M. Ucko) writes: >> The fix itself looks fine, so please feel free to go ahead (with the >> Closes: removed and possibly with .gitignore restored if appropriate). > > Will do, thanks! Uploaded, final debdiff confirmed not to touch .gitignore. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1040953: bookworm-pu: package sra-sdk/3.0.3+dfsg-6~deb12u1
"Adam D. Barratt" writes: > If you were intending to close this p-u request there, please don't. > The bug will get closed once the updated package is in stable as part > of a point release. Ah, right, I'll leave that off, then. > Is the removal of .gitignore intentional? No, that was an artifact of using an atypical build procedure; sorry for the noise. (I'd held off on committing these tentative changes, so gbp would have required a special flag; I substituted plain debuild but evidently didn't get its flags quite right.) > The fix itself looks fine, so please feel free to go ahead (with the > Closes: removed and possibly with .gitignore restored if appropriate). Will do, thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1040953: bookworm-pu: package sra-sdk/3.0.3+dfsg-6~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: sra-...@packages.debian.org
Control: affects -1 + src:sra-sdk
[ Reason ]
Per #1039621, the new libngs-jni package accidentally wound up with
bad content (unexpanded variables in the key symlink's source *and*
target) that rendered it useless.
[ Impact ]
This package's reverse dependencies, from libngs-java on up, will be
broken unless libncbi-ngs-dev happens to be installed.
[ Tests ]
Various affected packages have autopkgtests, but they evidently missed
the relevant bug, having presumably wound up running with
libncbi-ngs-dev additionally installed. (The tests did catch the
need for architecture restrictions that made it into bookworm, FWIW.)
[ Risks ]
Minimal -- trivial fix, working in testing and unstable with no
further changes from stable.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[v] I reviewed all changes and I approve them
[v] attach debdiff against the package in (old)stable
[v] the issue is verified as fixed in unstable
[ Changes ]
Tweak debian/rules to make the necessary substitutions in
libngs-java.links.in.
[ Other info ]
In reviewing the debdiff, I see that one of my teammates pushed a
debian/salsa-ci.yml update without a corresponding changelog note that
consequently slipped into -6 undocumented; what should I do about it
at this point?
I've held off on cleaning up a long-dangling symlink in a different
binary package (sra-toolkit, #1040391) but can readily throw that in
if you'd like.
diff -Nru sra-sdk-3.0.3+dfsg/debian/.gitignore
sra-sdk-3.0.3+dfsg/debian/.gitignore
--- sra-sdk-3.0.3+dfsg/debian/.gitignore2023-02-24 05:52:27.0
-0500
+++ sra-sdk-3.0.3+dfsg/debian/.gitignore1969-12-31 19:00:00.0
-0500
@@ -1,16 +0,0 @@
-*.debhelper
-*.substvars
-.debhelper
-.javahelper_clean
-debhelper-build-stamp
-files
-lib*-dev
-lib*[0-9]
-libngs-java
-libngs-java-doc
-libngs-java-doc.doc-base.javadoc
-libngs-jni
-libngs-jni.links
-python3-ngs
-sra-toolkit
-tmp
diff -Nru sra-sdk-3.0.3+dfsg/debian/changelog
sra-sdk-3.0.3+dfsg/debian/changelog
--- sra-sdk-3.0.3+dfsg/debian/changelog 2023-02-24 05:52:27.0 -0500
+++ sra-sdk-3.0.3+dfsg/debian/changelog 2023-07-12 22:20:14.0 -0400
@@ -1,3 +1,16 @@
+sra-sdk (3.0.3+dfsg-6~deb12u1) bookworm; urgency=medium
+
+ * Reupload to bookworm (stable). (Closes: #10n).
+
+ -- Aaron M. Ucko Wed, 12 Jul 2023 22:20:14 -0400
+
+sra-sdk (3.0.3+dfsg-6) unstable; urgency=high
+
+ * debian/rules: Expand $(DEB_HOST_MULTIARCH) in libngs-java.links.in.
+(Closes: #1039621.)
+
+ -- Aaron M. Ucko Tue, 27 Jun 2023 22:14:41 -0400
+
sra-sdk (3.0.3+dfsg-5) unstable; urgency=medium
* Limit libngs-java to those architectures where libs are available
diff -Nru sra-sdk-3.0.3+dfsg/debian/rules sra-sdk-3.0.3+dfsg/debian/rules
--- sra-sdk-3.0.3+dfsg/debian/rules 2023-02-24 05:52:27.0 -0500
+++ sra-sdk-3.0.3+dfsg/debian/rules 2023-07-12 22:19:10.0 -0400
@@ -152,7 +152,10 @@
execute_before_dh_link:
# Putting the upstream version number (without the dfsg part) at the
end of
# symlink source in the -jni package.
- sed 's/\(#STRIPPED_UPSTREAM_VERSION#\)/\1$(DEB_VERSION_UPSTREAM)/;
s/#STRIPPED_UPSTREAM_VERSION#\(.*\)+dfsg[0-9]*/\1/' debian/libngs-jni.links.in
> debian/libngs-jni.links
+ sed -e 's/\(#STRIPPED_UPSTREAM_VERSION#\)/\1$(DEB_VERSION_UPSTREAM)/' \
+ -e 's/#STRIPPED_UPSTREAM_VERSION#\(.*\)+dfsg[0-9]*/\1/' \
+ -e 's/\$$[({]DEB_HOST_MULTIARCH[)}]/$(DEB_HOST_MULTIARCH)/g' \
+ debian/libngs-jni.links.in > debian/libngs-jni.links
# require network, not automatically run
# use it when the pom file must be re-downloaded from maven repo
diff -Nru sra-sdk-3.0.3+dfsg/debian/salsa-ci.yml
sra-sdk-3.0.3+dfsg/debian/salsa-ci.yml
--- sra-sdk-3.0.3+dfsg/debian/salsa-ci.yml 2023-02-24 05:52:27.0
-0500
+++ sra-sdk-3.0.3+dfsg/debian/salsa-ci.yml 2023-07-12 22:19:10.0
-0400
@@ -2,3 +2,7 @@
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
+
+variables:
+# Does not build on i386
+ SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 1
Bug#1039089: [PATCH 1/1] correct_posix1e_v1_delimiters: provide path for error messages
Rob Browning writes: > Thanks to Phil Sutter and Johannes Berg (at least) for reporting the > problem. FWIW, I ran into it too, but reported it downstream, as https://bugs.debian.org/1039089; the patch LGTM offhand, though I haven't tested it and presumably no longer have an "organic" test case. Thanks for the fix! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1039621: libngs-jni: Installs shared object in wrong directory
Guillem Jover writes: > /usr/lib/$(DEB_HOST_MULTIARCH)/jni/libncbi-ngs.so > > Where the variable has not been expanded and appears as is. So the > shared object will not be found. Oops, so it does; automatic testing evidently missed that due to running with libncbi-ngs-dev installed. I went with a minimal fix, in part to facilitate getting it into a stable update if anyone considers that warranted. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1039089: bup: _correct_posix1e_v1_delimiters usage mismatch
Package: bup Version: 0.33.1-1 Severity: important Tags: upstream Updating a save that had old-format ACL metadata (from e.g. /var/log/journal) fails with ... File "/usr/lib/bup/bup/metadata.py", line 864, in read result._load_posix1e_acl_rec(port, version=1) File "/usr/lib/bup/bup/metadata.py", line 573, in _load_posix1e_acl_rec acl_rep = self._correct_posix1e_v1_delimiters(acl_rep) TypeError: Metadata._correct_posix1e_v1_delimiters() missing 1 required positional argument: 'path' where AFAICT path is needed only for potential error reporting. The obvious candidate is self.path, which I'll try locally patching _load_posix1e_acl_rec to pass. (_correct_posix1e_v1_delimiters is a static method and as such does in fact need to receive the path explicitly.) Could you please take a look? Thanks! -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.3.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Versions of packages bup depends on: ii git 1:2.40.1-1 ii libacl1 2.3.1-3 ii libc62.36-9 ii libpython3.113.11.4-1 ii libreadline8 8.2-1.3 ii par2 0.8.1-3 ii python3 3.11.2-1+b1 ii python3-pylibacl 0.7.0-2 ii python3-xattr [python3-pyxattr] 0.10.1-1 Versions of packages bup recommends: ii bup-doc 0.33.1-1 ii python3-fuse 2:1.0.5-1+b3 ii python3-tornado 6.2.0-3 bup suggests no packages. -- debconf-show failed
Bug#1034369: C++ help needed
tags 1034369 + patch
thanks
Andreas Tille writes:
> I guess the fix will boil down to a type casting in this line
>
>
> https://salsa.debian.org/med-team/libcereal/-/blob/master/unittests/map.hpp#L65
>
> o_esplmap.insert({random_value(gen), { random_value(gen),
> random_value(gen) }});
>
> unfortunately my C++ knowledge is too limited to know whether it is
> really that simple nor how exactly this line needs to be fixed. The fix
> should be tested at least on arm64 (since the test passes on amd64).
#1034369 looks very similar to #1021394, which worked around
corresponding build-time errors by disabling -Werror but I see left the
autopkgtest's cmake invocation as is; there may be merit in disabling
-Werror on that front too. At any rate, I would recommend properly
addressing the compiler's concerns by changing random_value to
random_value here and in the other unittests/*map.hpp headers to
match the corresponding containers' declarations, per the attached
patch. The relevant platform difference is whether plain char is
signed, as it notably is on x86 but not arm*. (There are other
architectures in each camp.)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Index: b/unittests/map.hpp
===
--- a/unittests/map.hpp
+++ b/unittests/map.hpp
@@ -62,7 +62,7 @@ void test_map()
std::map o_esplmap;
for(int j=0; j<100; ++j)
- o_esplmap.insert({random_value(gen), { random_value(gen), random_value(gen) }});
+ o_esplmap.insert({random_value(gen), { random_value(gen), random_value(gen) }});
std::ostringstream os;
{
Index: b/unittests/multimap.hpp
===
--- a/unittests/multimap.hpp
+++ b/unittests/multimap.hpp
@@ -71,7 +71,7 @@ void test_multimap()
std::multimap o_esplmultimap;
for(int j=0; j<100; ++j)
{
- auto key = random_value(gen);
+ auto key = random_value(gen);
o_esplmultimap.insert({key, { random_value(gen), random_value(gen) }});
o_esplmultimap.insert({key, { random_value(gen), random_value(gen) }});
}
Index: b/unittests/unordered_map.hpp
===
--- a/unittests/unordered_map.hpp
+++ b/unittests/unordered_map.hpp
@@ -54,7 +54,7 @@ void test_unordered_map()
std::unordered_map o_esplunordered_map;
for(int j=0; j<100; ++j)
- o_esplunordered_map.insert({random_value(gen), { random_value(gen), random_value(gen) }});
+ o_esplunordered_map.insert({random_value(gen), { random_value(gen), random_value(gen) }});
std::ostringstream os;
{
Index: b/unittests/unordered_multimap.hpp
===
--- a/unittests/unordered_multimap.hpp
+++ b/unittests/unordered_multimap.hpp
@@ -71,7 +71,7 @@ void test_unordered_multimap()
std::unordered_multimap o_esplunordered_multimap;
for(int j=0; j<100; ++j)
{
- auto key = random_value(gen);
+ auto key = random_value(gen);
o_esplunordered_multimap.insert({key, { random_value(gen), random_value(gen) }});
o_esplunordered_multimap.insert({key, { random_value(gen), random_value(gen) }});
}
Bug#1031853: sra-sdk: Unsatisfied dependency in libngs-java on any platform other than arm64 and amd64
Vladimir Petko writes: > Would it be possible to limit Architecture of libngs-java to amd64 and > arm64 to be inline with native parts? > > [1] > https://ci.debian.net/data/autopkgtest/unstable/armel/s/sra-sdk/31071466/log.gz I'm not sure how I missed this autopkgtest wrinkle earlier, but AIUI the proper fix would be to give the *test* an architecture restriction; adjusting the binary package's architecture would merely result in (minor) duplication within the archive. I do apologize for having to limit effective architecture availability here, but the code's dependency on VDB left me no choice. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1029987: RM: paleomix [mips64el ppc64el] -- ANAIS; indirect dep on libngs-java unsatisfiable
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: paleo...@packages.debian.org, debian-...@lists.debian.org Control: affects -1 + src:paleomix paleomix indirectly depends on libngs-java, which recently dropped support for most architectures in the course of a major upstream release. (The full chain is paleomix -> picard-tools -> libpicard-java -> libhtsjdk-java -> libngs-java; libngs-java 3.x is Architecture: all, but depends on a libngs-jni available only on amd64 and arm64.) Could you please remove paleomix on mips64el and ppc64el to unblock the current libngs-* packages (and sra-sdk more broadly)? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1029474: closed by Scott Kitterman (Re: RM: sra-sdk [i386 x32] -- ANAIS; requires a 64-bit address space)
On 1/23/23 16:24, Debian Bug Tracking System wrote: > It doesn't exist on i386 in instable, so nothing to do here. Whoops, sorry for the noise, and thanks for quickly taking care of the removal requests that actually affected release architectures. > BTW, x32 is a ports architecture that is not managed by the FTP Team. Ah, OK; I wasn't entirely clear on the logistical details. Do you happen to know the SOP for getting cruft cleaned up on that front? I know it doesn't block migration, but I still might as well flag it. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1029478: RM: skesa [i386 x32] -- ANAIS; build dependencies unavailable
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sk...@packages.debian.org Control: affects -1 + src:skesa Per other recent removal requests[1][2][3], skesa's build dependencies are available only on amd64 and (now) arm64 at this point; as such, please remove skesa (and skesa-dbg) on i386 and x32. Thanks! [1] https://bugs.debian.org/1029472 [2] https://bugs.debian.org/1029474 [3] https://bugs.debian.org/1029475
Bug#1029477: RM: dictionary-el -- ROM; redundant as of emacs 28
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: dictionary...@packages.debian.org Control: affects -1 + src:dictionary-el Because dictionary-el uses dh-elpa these days, it integrates only with GNU Emacs, which however incorporated the package into its standard library as of version 28. Upstream has been inactive, so there's not even any marginal benefit to having a second copy at this point. (There would be some marginal benefit with XEmacs, which ships an older version, but that older version is good enough as far as I'm concerned, particularly given that I'd have to revert to old-school packaging to do anything about it.) Please go ahead and remove this package at your convenience. Thanks!
Bug#1029475: RM: ngs-sdk -- ROM; subsumed by sra-sdk 3.x
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sra-...@packages.debian.org Control: affects -1 + src:sra-sdk sra-sdk 3.x subsumed ngs-sdk, albeit with only partial overlap because the C library changed both its basename and its SO version along the way. Also, the two binary packages that carried over became architecture-independent. As such, please remove libngs-sdk2, libngs-sdk2-dbg, and libngs-sdk-dev altogether, and libngs-java and python3-ngs for all architectures *EXCEPT* all. Thanks!
Bug#1029474: RM: sra-sdk [i386 x32] -- ANAIS; requires a 64-bit address space
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sra-...@packages.debian.org Control: affects -1 + src:sra-sdk Fully building sra-sdk requires a 64-bit address space these days. It might be possible to contrive to build some of its binary packages on architectures with 32-bit address spaces, or even on architectures ncbi-vdb doesn't support, but I'm not convinced it's worth the effort. As such, could you please remove sra-toolkit (and sra-toolkit-dbg) on i386 and x32? (I mentioned plural packages above, but that's only the case for 3.x, which had this requirement all along.) Thanks!
Bug#1029472: RM: ncbi-vdb [i386] -- ANAIS; upstream fully dropped i386 support
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: ncbi-...@packages.debian.org Control: affects -1 + src:ncbi-vdb ncbi-vdb 3.x switched to a new build system that supports only a narrow list of architectures, with specific associated settings. i386 isn't on the list, and arranging to add it isn't worth the trouble, particularly given that ncbi-vdb's reverse dependencies mostly require a 64-bit address space these days anyway. (I'll file selective removal requests for them shortly.) As such, could you please remove i386 packages built from ncbi-vdb? FTR, the relevant binary packages are libncbi-vdb2 libncbi-vdb2-dbg libncbi-vdb-dev libkdf5-2 libkdf5-2-dbg libkdf5-dev libncbi-wvdb2 libncbi-wvdb2-dbg libncbi-wvdb-dev libvdb-sqlite2 libvdb-sqlite2-dbg libvdb-sqlite-dev Thanks!
Bug#869510: dhtnode: please handle connection problems gracefully
Petter Reinholdtsen writes: > I guess someone should test and figure out what the status is. The > latest opendht is in Debian unstable and testing now. As of 2.4.10-1, it no longer floods logs, but it doesn't seem to have found anything either: $ dhtnode OpenDHT node [...] running on port [...] (type 'h' or 'help' for a list of possible commands) >> ll OpenDHT node [...] running on port [...] >> 1 ongoing operations Storage has 0 values, using 0 KB IPv4 stats: Known nodes: 0 good, 0 dubious, 0 incoming. 0 searches, 0 total cached nodes IPv6 stats: Known nodes: 0 good, 0 dubious, 0 incoming. 0 searches, 0 total cached nodes Meanwhile, all I see in the log is dhtnode[...]: Bootstrap: bootstrap.ring.cx Thanks for asking! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1028165: libfltk1.3-dev: Missing dependency on fluid?
Hi, Adrian. In principle, the existing Recommends relationship should suffice, even when using FLTK's CMake integration; reverse dependencies should either explicitly build-depend on fluid or explicitly define FLTK_SKIP_FLUID as appropriate. That said, I see that giada already does the latter, so I'll take a closer look when I get a chance. > This was likely broken by 1.3.8-5, the fix for #1017271 did > touch the cmake files: It merely accounted for a change in where CMake placed them, but it's plausible that some other recent change to CMake's behavior broke the logic to honor FLTK_SKIP_FLUID (which I've confirmed remains present). Thanks for the report (reminiscent of [1], FWIW), and sorry for the trouble! [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855040 -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#891197: Please switch to pcre2
Andreas Tille writes: > Finally it seems to boil down to change four files of real code Right, usage is centralized via wrappers, so they'll need extensive changes but with any luck nothing else should (apart from necessary build-system adjustments). At any rate, upstream is now open to moving on, albeit at low priority. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#982384: [Help] Bug 982384: Warnings profile count data file not found
Andreas Tille writes: > Could anybody comment on it / fix it? Per https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fprofile-use: Before you can use this option, you must first generate profiling information. See Instrumentation Options, for information about the -fprofile-generate option. It may be simplest to drop the option, particularly if cross compilation is otherwise possible. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#891197: Please switch to pcre2
Andreas Tille writes: > it would be great if you could use your upstream contact to convince > them to switch to pcre2. Upstream explicitly passed on pcre2 a few years ago, but times have changed; I've opened an internal ticket to revisit the question. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1024155: Fixed in Git [Re: libngs-c++-dev: missing Breaks+Replaces: libncbi-vdb-dev (<< 3), libngs-sdk-dev (<< 3)]
Andreas Tille writes: > I have fixed this issue in Git. Thanks! > I'm wondering about the status of the > ncbi-vdb transition[1]. Isn't it time to upload the packages to > unstable now? Just let me know if you need any help. I first want to get a better picture of where sra-sdk 3.x stands in terms of architecture support, which may be clearer with upgrades to 3.0.1 in place. I've been working on them, but a power outage last weekend delayed me; I'll try to wrap them up this weekend. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1025004: dash: errors in sourced functions reported against wrong files
Package: dash Version: 0.5.11+git20210903+057cd650a4ed-9 Severity: normal I have found that dash defers "bad substitution" errors until actually attempting to evaluate the substitution in question. That in itself is plausibly legitimate, particularly given that bash does the same. However, when such an error stems from a function defined in a sourced file, dash cites it as coming from the file corresponding to the top of the call stack, albeit with a line number indicating the relevant line of the sourced file. Could you please take a look? Thanks! -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 Versions of packages dash depends on: ii debianutils 5.7-0.4 ii dpkg 1.21.9+b1 ii libc62.36-5 dash recommends no packages. dash suggests no packages. -- debconf-show failed
Bug#1024155: libngs-c++-dev: missing Breaks+Replaces: libncbi-vdb-dev (<< 3), libngs-sdk-dev (<< 3)
Andreas Beckmann writes: > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. Good catch, thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1014797: FTBFS: test failures with new libgd3
Andreas Tille writes: > do you have some idea how to fix this bug? Not offhand, sorry. In general, I'm not closely familiar with either this package or the underlying GD library (though I do know Perl); I just added myself to Uploaders a decade ago so I could most cleanly upload a packaging fix (for #624130) and stayed there by inertia. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1012893: [Help] anfo: ftbfs with GCC-12
Étienne Mollier writes: > I believe in the case of anfo, that warnings about auto_ptr / > unique_ptr are red herrings. If I search for "error:"s, then I > get some errors about no match for operator<: Oops, good catch. As for unique_ptr, this is evidently one of those situtations where whoever makes the substitution (possibly upstream after all at some point) will need to make additional changes to make it clear that their usage is safe. In particular, the ...Reader constructors will probably want to accept auto_ptr<> by rvalue reference rather than by value: std::unique_ptr&& is -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1012893: [Help] anfo: ftbfs with GCC-12
Andreas Tille writes: > Could anybody have a look at this gcc failure? Per GCC's hint, please try formally substituting unique_ptr for auto_ptr. I haven't tested that approach for this package, but it's typically a safe drop-in replacement, and generally yields compilation errors in the rare cases where its usage would be problematic. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.
Adrian Bunk writes: > Makes sense. Thanks. > It would also be useful if fltk1.3 would FTBFS when an input file was > not found. Don't worry, I'm already planning to put in such a safeguard at this point. Sorry for missing this possible failure mode earlier. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.
Adrian Bunk writes: > Paths of the input files changed: Ah, yeah, that would do it. Thanks for all your analysis! > The following in debian/rules work for me with current cmake: > CMakeTmp/CMakeFiles/Export/*/FLTK-Targets.cmake \ > CMakeTmp/CMakeFiles/Export/*/FLTK-Targets-none.cmake \ Got it, thanks, though I'm inclined to use find(1) so I'm not specifically tied to new cmake. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.
Adrian Bunk writes: > This makes it appear more likely that the root cause is a bug in FLTK or > a regression in CMake. Ah, yeah, FLTK's packaging post-processes some CMake output; it sounds like the relevant logic needs to be updated to work with current CMake. (Another option might have been to patch CMake's input, but I want to make some across-the-board tweaks that are best centralized modulo this sort of wrinkle.) I'll take a look when I get a chance. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1017421: fltk1.3: reproducible builds: locale-specific month embedded in fltk.pdf
Vagrant Cascadian writes: > The month embedded in the TODAY variable is translatable, and thus > changes depending on the locale of the build environment. Good catch, thanks! > The attached patch updates debian/patches/debian-changes to use a > numeric date, which should be independent of locale. I presume another option would be to run date with LC_ALL set to C, particularly given that the actual content is all in English anyway. > It is unclear if this alone will make fltk1.3 build reproducibly, but it > should reduce the differences even if it does not solve all issues. I seem to recall some other wrinkles, but I'll be happy to move closer to reproducibility regardless. > ++TODAY=`date -ud'$(DEB_DATE)' +'%Y-%m-%s'`; \ ITYM '%Y-%m-%d' or '%F' -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1013940: New version of nfft breaks its autopkgtest (Was: nfft breaks pynfft autopkgtest on i386: Segmentation fault
Andreas Tille writes: > [1] https://salsa.debian.org/science-team/nfft/-/jobs/3041717 | + gcc -Wall -DNFFT_PRECISION_SINGLE -lnfft3f -lfftw3f -o simple_test simple_test.c | /usr/bin/ld: /tmp/ccaUJ49M.o: in function `simple_test_nfft_1d': | simple_test.c:(.text+0x2c): undefined reference to `nfftf_init_1d' [...] Please try listing simple_test.c ahead of the libraries, which the linker otherwise discards as apparently unneeded. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1013608: marked as done (ncbi-entrez-direct: FTBFS: cannot find package "github.com/shirou/gopsutil/mem")
"Debian Bug Tracking System" writes: >* d/rules: Pass right location of gopsutil/mem (Closes: #1013608) Thanks for looking into this report! FWIW, I reckon it should be possible to do away with this dependency altogether by retiring the shim that used it in favor of system golang-github-pbnjay-memory-dev now that the latter exists. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1010110: ncbi-blast+: terminate called after throwing an instance of 'ncbi::CIO_Exception'
Patrice DUROUX writes: > Using the same command line with different versions of the package, Can you please give an example of a command line that reproduces the error? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1010087: waylandpp: please split out a -doc package
Source: waylandpp Version: 0.2.10-1 Severity: minor waylandpp-dev's size increased from 843 kB to 14.4 MB between versions 0.2.8-2 and 0.2.10-1 on amd64, with other architectures presumably also encountering similar increases. AFAICT, this massive increase comes primarily from Doxygen's generated HTML, which is architecture-independent and not usually needed locally; could you please split it out into a separate -doc package? Thanks! -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1003631: dlocate: update-dpkg-list can deadlock
Craig Sanders writes:
> On Wed, Jan 12, 2022 at 06:06:45PM -0500, Aaron M. Ucko wrote:
>> Long story short, update-dpkg-list's batched bidirectional pipe usage wound
>> up deadlocking on a system with 20,000+ provided virtual packages, mostly
>> from installed librust-*-dev packages.
>
> what do you mean by "deadlocking"? some kind of lockup, i presume. what
> exactly happens? roughly how long is the script running before it happens?
As confirmed by strace, each side of the pipe is blocking on a write
call that won't complete until the other side issues a read, because the
kernel's buffer for the pipe has filled up.
I am comfortable with Perl, and having taken another look at the code,
was able to resolve the deadlock by arranging to feed xargs from a
dedicated subprocess, per the attached patch.
Could you please consider applying it?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
diff -u update-dpkg-list~ update-dpkg-list
--- update-dpkg-list~ 2022-01-13 20:52:49.875888185 -0500
+++ update-dpkg-list 2022-01-13 21:41:42.053617442 -0500
@@ -4,6 +4,7 @@
use warnings;
use IPC::Open2;
use File::Basename;
+use POSIX qw(:sys_wait_h);
my $program = basename($0);
@@ -59,14 +60,20 @@
# apt-cache doesn't read stdin, so we have to use xargs to make sure we
# never exceed the bash command line limit.
my $pid = open2(\*ACS, \*XARGS, 'xargs -0r apt-cache show');
+ my $pid2 = fork();
- print XARGS join("\0",@unknown);
- close(XARGS);
+ if ($pid2 == 0) {
+print XARGS join("\0",@unknown);
+exit(0);
+ } else {
+close(XARGS);
+ }
while () {
parse_pkg('ACS',$_);
};
close(ACS);
+ waitpid($pid2, WNOHANG);
};
my $dlist = '/var/lib/dlocate/dpkg-list';
Bug#1003631: dlocate: update-dpkg-list can deadlock
Package: dlocate Version: 1.09 Severity: important Long story short, update-dpkg-list's batched bidirectional pipe usage wound up deadlocking on a system with 20,000+ provided virtual packages, mostly from installed librust-*-dev packages. Could you please take a look? Thanks! -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dlocate depends on: ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg 1.21.1 ii perl 5.32.1-6 Versions of packages dlocate recommends: ii supercat 0.5.7-1 dlocate suggests no packages. -- debconf-show failed
Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same
Dima Kogan writes: > /bin/sh: 1: test: =: unexpected operator For whatever reason, I didn't run into that one; I'll look into it. Thanks for pointing it out and for confirming that all is otherwise well. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1002880: signing-party: caff defaults to retired pool.sks-keyservers.net
Guilhem Moulin writes: > Hi, Hi. Thanks for the quick response! > Seems I forgot to update caffrc.sample :-), but since 2.3-1 caff doesn't > hardcode its own keyserver. Ah, OK. AFAICT, I've been using caff since 2010, so I suppose I shouldn't be surprised that my ~/.caff could use some modernization. :-) In particular, I still have a ~/.caff/gnupghome/options containing keyserver pool.sks-keyservers.net > I'm not sure what's the best substitute at the moment as > hkps://keys.openpgp.org > doesn't send third-party signatures. That's fair. In that case, though, perhaps caff should refrain from suggesting any specific server or pool until there's a sufficiently good choice again. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1002880: signing-party: caff defaults to retired pool.sks-keyservers.net
Package: signing-party Version: 2.11-1 Severity: normal caff has historically defaulted to looking keys up on pool.sks-keyservers.net and recommending that signees upload their keys there. However, per https://sks-keyservers.net/, that pool is no longer in service. Could you please substitute some other server or pool, both in code and in the sample caffrc? Thanks! -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages signing-party depends on: ii gnupg 2.2.27-2 ii libc6 2.33-1 ii libclass-methodmaker-perl 2.24-2+b1 ii libgnupg-interface-perl1.02-1 ii libmailtools-perl 2.21-1 ii libmd0 1.0.4-1 ii libmime-tools-perl 5.509-1 ii libnet-idn-encode-perl 2.500-2 ii libterm-readkey-perl 2.38-1+b2 ii libtext-template-perl 1.60-1 ii perl 5.32.1-6 ii python33.9.7-1 ii qprint 1.1.dfsg.2-2.1 Versions of packages signing-party recommends: ii dialog 1.3-20201126-1 ii exim4-daemon-heavy [mail-transport-agent] 4.95-3 ii libgd-perl [libgd-gd2-perl]2.73-1+b1 ii libpaper-utils 1.1.28+b1 ii whiptail 0.52.21-5+b1 Versions of packages signing-party suggests: pn fonts-noto-cjk ii fonts-noto-mono 20201225-1 ii imagemagick 8:6.9.11.60+dfsg-1.3 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 ii mutt 2.1.4-1 ii neomutt 20211029+dfsg1-1 ii qrencode 4.1.1-1 ii texlive-font-utils 2021.20211217-1 ii texlive-latex-extra 2021.20211217-1 ii texlive-latex-recommended2021.20211217-1 ii texlive-xetex2021.20211217-1 ii wipe 0.24-9 -- debconf-show failed
Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same
u...@debian.org (Aaron M. Ucko) writes: > Only in the context of package builds; in other contexts (ad-hoc builds > against system FLTK), it's currently entirely possible to have only > libfltk1.3-dev installed. I could perhaps downgrade the dependency to a > recommendation, but I don't think it would be unreasonable to leave it > as a full dependency. At any rate, please try the changes I've pushed to https://salsa.debian.org/ucko/fltk1.3. I'm not uploading anything to the archive quite yet because I'd first like to take care of some unrelated cleanups that should be quick but for which I'm out of time at the moment; I'm hoping to get them within the next few days. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same
Dima Kogan writes: > I forgot to mention: dpkg-dev is in build-essential and it's > Architecture:all, so there's no reason to add the dependency. It's > guaranteed to be installed. Only in the context of package builds; in other contexts (ad-hoc builds against system FLTK), it's currently entirely possible to have only libfltk1.3-dev installed. I could perhaps downgrade the dependency to a recommendation, but I don't think it would be unreasonable to leave it as a full dependency. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same
Dima Kogan writes: > Here's a patch to handle fltk-config. Got it, thanks! > I don't use cmake, so would like to not touch FLTK-Targets-none.cmake. > Can you do that? Sure, I'll look into it. I reckon I'll also need to throw in a runtime dependency on dpkg-dev:any, but that should be straightforward and uncontroversial. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same
Dima Kogan writes: > It would be nice if it was Multi-Arch:same. It would make cross-building > easier. Is there any reason it isn't? I see that it ships > /usr/bin/fltk-config, which would need to be moved to a different > package, maybe. Do you want a patch? Thanks for the suggestion. There is a second file that would be a problem as is: /usr/lib/fltk/FLTK-Targets-none.cmake. I don't think the FTP team would take well to introducing a new binary package for a handful of small files. However, it should in principle be possible to make the package multi-arch-friendly by moving the files to architecture-specific paths and arranging to select appropriate instances dynamically. If you're up for putting together such a patch, I'll be happy to consider it; otherwise, I'll try to find time myself. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1002253: Help with possibly broken ar archive
Andreas Tille writes: > I've never seen this before and I wonder whether this is something > I should be concerned about before uploading. Yes, it looks like the build system is set up to produce "thin" archives that can't stand on their own; please try patching the Makefile to drop the T flag from LINK.A (line 72). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1000358: ncbi-blast+: Please rebuild against MBEDTLS 2.16.11
Andreas Tille writes: > I'd be really happy if you would consider separating changes that > require a trip to new. I'm already specifically planning NOT to make any such changes now; sorry if that was unclear. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1000358: ncbi-blast+: Please rebuild against MBEDTLS 2.16.11
Andreas Tille writes: > Will you upload a package with this fix soon or do you need some help > dud to time constraints? I usually do not fiddle around with this > package but deactivating the test and upload should be OK, thought. Thanks for the offer and reminder! I should be able to take care of it within the next day or two, holding off for now on other non-routine changes -- and particularly on implementation of #984871, which would entail a trip through NEW (and moreover has severity wishlist). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1000358: ncbi-blast+: Please rebuild against MBEDTLS 2.16.11
Stefano Rivera writes: > Critical: External MBEDTLS version mismatch: 2.16.9 headers vs. 2.16.11 > runtime Thanks for the report! FTR, the correct fix will be to disable this overstrict version check in favor of trusting dpkg-shlibdeps, as previously done for GNUTLS. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#984243: Help: mothur: ftbfs with GCC-11
Andreas Tille writes: > which has an incomplete number of arguments that is interrupted > by '/usr/bin/ld') That looks like it might simply be an artifact of different buffering policies for standard output and standard error; I expect you'll find the remainder of the command line later on. > Any idea how to specify the number of object files more sensibly > to not explode the command line arguments too much? You (or upstream) could consider using internal static libraries. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#997209: [Help needed] eegdev: FTBFS: ./doc/examples/library-usage/eegdev_acq.c:214: undefined reference to `rpl_free'
Nilesh Patra writes: > I have no idea why it can not find free() -- looks like something changed > with new autotools. > I don't know much about autotools, and need help to figure out what might be > wrong -- would you have any pointers? These errors look like fallout from a new check: > checking whether free is known to preserve errno... no Please try patching doc/examples/Makefile.am to add $(top_builddir)/lib/libgnu.la to both eegdev_acq_LDADD and recinxdf_LDADD. (libeegdev incorporates rpl_free and other needed rpl_* functions with hidden visibility, so purely for its own use.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#984243: Help: mothur: ftbfs with GCC-11
Andreas Tille writes: > I'm wondering why the makefile stopped working just because a new compiler > version is used. :-( Along the way, you pulled in a new upstream version, whose makefile evidently wasn't quite right. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#793549: cmake-data: Can't find fluid with FLTK 1.3.3
Timo Röhling writes: > AFAICT upstream has modified their FLTKConfig.cmake to set > FLTK_FLUID_EXECUTABLE without UseFLTK.cmake; albeit still to "fluid" > without absolute path. Ah, yeah, I see in retrospect that *only* 1.3.3 played poorly with FindFLTK.cmake. > Is this sufficient for you to consider this bug done? Sure, thanks. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#984243: Help: mothur: ftbfs with GCC-11
Andreas Tille writes: > OK, I've implemented this in my last commit. Great, thanks! > Isn't > > # Get the list of all .cpp files, rename to .o files > # > OBJECTS=$(patsubst %.cpp,%.o,$(wildcard $(addsuffix *.cpp,$(subdirs > OBJECTS+=$(patsubst %.c,%.o,$(wildcard $(addsuffix *.c,$(subdirs > OBJECTS+=$(patsubst %.cpp,%.o,$(wildcard *.cpp)) > OBJECTS+=$(patsubst %.c,%.o,$(wildcard *.c)) > > the right way to get the path correctly? Or what do you mean? Please try changing the last two lines to OBJECTS+=$(patsubst %.cpp,%.o,$(wildcard source/*.cpp)) OBJECTS+=$(patsubst %.c,%.o,$(wildcard source/*.c)) to match the relevant sources' actual location; sorry if that was unclear. (The existing setup only covers subdirectories of source, missing that directory's immediate contents.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#984243: Help: mothur: ftbfs with GCC-11
Steffen Möller writes: > My C++ skills are a bit rosty but would removing the typedef for byte > solve the problem? No, because std::byte supports far too few operations [1]. Instead, I'd suggest encouraging upstream to rename their type, and meanwhile locally patching source/uchime_src/makefile to add -std=c++14 to CXXFLAGS, thereby suppressing std::byte for now. I also found massive link errors, resolvable by correcting the top-level Makefile to pick up source/*.cpp and source/*.c rather than the nonexistent *.cpp and *.c. [1] https://en.cppreference.com/w/cpp/types/byte -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#996794: ncbi-acc-download: autopkgtest failure with python-biopython 1.79+dfsg-1~0exp0 in experimental
Étienne Mollier writes: > The issue turned out to be related, and I came up with some > hackery to smoothen the transition to python-biopython 1.79. > The corresponding patch is in attachment. I welcome remarks, > since I'm only half happy with the result, although I tried hard > to make sure it is functionally equivalent. Great, thanks! I suppose it might be slightly cleaner to factor out a helper predicate function. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#996794: ncbi-acc-download: autopkgtest failure with python-biopython 1.79+dfsg-1~0exp0 in experimental
Étienne Mollier writes: > E - LOCUS NC_007194 60 bpDNA > linear CON 03-APR-2018 > E ? ^^^ > ^^ ^^^ ^^ > E + LOCUS NC_0071944918979 bpDNA > linear CON 11-NOV-2009 > E ? ^^^ > ^^ ^^^ ^^ It looks like this test is intended to work offline (as required) and yield short mock records, but for some reason winds up fetching full-length live data instead. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#995349: ncbi-entrez-direct: FTBFS: no required module provides package github.com/fiam/gounidecode/unidecode
Steve Langasek writes: > rchive.go:40:2: no required module provides package > github.com/fiam/gounidecode/unidecode: go.mod file not found in current > directory or any parent directory; see 'go help modules' [etc.] Thanks for the report! AFAICT, my approach to go.mod and go.sum (moving both aside) ran afoul of https://go.dev/blog/go116-module-changes, and the "GO111MODULE=off" workaround noted there won't work for Impish (which rmadison tells me already has 1.17) or likely long for Debian. I have some thoughts about how to craft a proper fix, and will look into doing so when I get a chance. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#994714: ncbi-blast+: makeblastdb output dependent of endianness
Étienne Mollier writes: > the pieces of the puzzle together. Thanks for your explanation, No problem; please feel free to ping me if there's anything else I can clarify. Also, sorry for the badly half-baked metadata update. > Have a nice day, :) Thanks, you too! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#994714: ncbi-blast+: makeblastdb output dependent of endianness
Control: reassign 994714 kleborate/2.1.0-1 Étienne Mollier writes: > At this point, I strongly suspect that, either makeblastdb does > not output properly blastdb files on big endian systems, or > kleborate is not able to decode properly an eventual blastdb > database with big endian specific layout. Hi, Étienne. As of BLAST+ 2.10.0, makeblastdb defaults to making version 5 databases, via the third-party LMDB library that uses an architecture-dependent on-disk layout (differing between little-endian and big-endian systems; I'm not sure offhand about 32-bit vs. 64-bit systems). TTBOMK, BLAST+ is fine on either type of system as long as you don't try to mix and match, so the bug is most likely in kleborate; please try directing makeblastdb to produce traditional version 4 databases by invoking it with the "-blastdb_version 4" flag. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959587 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960756 and especially https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981293 Thanks for checking! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#992993: libapt-pkg6.0: infinite recursion in pkgDepCache::MarkPackage
u...@debian.org (Aaron M. Ucko) writes: > David Kalnischkies writes: > >> Points at my changes in 2.3.3, especially "Mark only provides from >> protected versioned kernel packages", as the most likely culprit. I went ahead with git bisect here; it wound up pointing to 9a54e70c1040379fb06827bacb461c61e341e694 is the first bad commit commit 9a54e70c1040379fb06827bacb461c61e341e694 Author: David Kalnischkies Date: Thu Mar 18 14:40:31 2021 +0100 Reexplore providers of marked packages if some didn't satisfy before [...] Please let me know if you need anything else. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#992993: libapt-pkg6.0: infinite recursion in pkgDepCache::MarkPackage
Package: libapt-pkg6.0 Version: 2.3.8 As of apt 2.3.8, most uses of libapt-pkg segfault; I can't even use reportbug to submit this report! The culprit appears to be infinite recursion in pkgDepCache::MarkPackage: #0 Configuration::FindB (this=0x5556bee0, Name=Name@entry=0x77e29f47 "Debug::pkgAutoRemove", Default=Default@entry=@0x7f7ff3a0: false) at ../apt-pkg/contrib/configuration.cc:453 #1 0x77dc2ff3 in pkgDepCache::MarkPackage (this=0x55636c80, Pkg=..., Ver=..., follow_recommends=@0x7fffdace: true, follow_suggests=@0x7fffdacf: true, reason=0x77e32cfa "Dependency") at ../apt-pkg/depcache.cc:2303 #2 0x77dc3b6a in pkgDepCache::MarkPackage (this=0x55636c80, Pkg=..., Ver=..., follow_recommends=@0x7fffdace: true, follow_suggests=@0x7fffdacf: true, reason=) at ../apt-pkg/depcache.cc:2406 #3 0x77dc3b6a in pkgDepCache::MarkPackage (this=0x55636c80, Pkg=..., Ver=..., follow_recommends=@0x7fffdace: true, follow_suggests=@0x7fffdacf: true, reason=) at ../apt-pkg/depcache.cc:2406 Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::LastInstalledKernel "5.10.0-8-amd64"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "0"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Update ""; APT::Update::Post-Invoke ""; APT::Update::Post-Invoke:: "touch /var/lib/apt/periodic/update-success-stamp 2>/dev/null || true"; APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || true"; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i"; APT::Update::Post-Invoke-Success:: "[ ! -f /var/run/dbus/system_bus_socket ] || /usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt org.debian.apt.CacheChanged || true"; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; fi"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi"; APT::Archives ""; APT::Archives::MaxAge "30"; APT::Archives::MinAge "2"; APT::Archives::MaxSize "500"; APT::Ar
Bug#990741: [nore...@release.debian.org: ncbi-entrez-direct is marked for autoremoval from testing]
Yes, 990743, already granted. It doesn't appear to have reduced the delay below what the autopkgtest already gave, though. -- Aaron On July 15, 2021 12:08:17 AM EDT, Andreas Tille wrote: >Hi Aaron, > >did you filed an unblock request to release.debian.org bug report? > >Kind regards >Andreas. > >- Forwarded message from Debian testing autoremoval watch > - > >Date: Wed, 14 Jul 2021 04:39:03 + >From: Debian testing autoremoval watch >To: ncbi-entrez-dir...@packages.debian.org >Subject: ncbi-entrez-direct is marked for autoremoval from testing > >ncbi-entrez-direct 14.6.20210224+dfsg-3 is marked for autoremoval from >testing on 2021-07-29 > >It is affected by these RC bugs: >990741: ncbi-entrez-direct: efetch and einfo wrappers warn about some >supported options > https://bugs.debian.org/990741 > > > >This mail is generated by: >https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > >Autoremoval data is generated by: >https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl > >___ >Debian-med-packaging mailing list >debian-med-packag...@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > >- End forwarded message - > >-- >http://fam-tille.de -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4
Paul Gevers writes: > On 08-07-2021 21:06, Aaron M. Ucko wrote: >> I should be able to upload around 22:00 UTC. (Also, I take it you're OK >> with the full version, since you didn't indicate otherwise.) Thanks much! > > Yes. Uploaded. Thanks again! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4
Paul Gevers writes: > Hi Aaron, Hi, Paul. > Assuming the upload happens shortly, please go ahead. I should be able to upload around 22:00 UTC. (Also, I take it you're OK with the full version, since you didn't indicate otherwise.) Thanks much! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
[ Introduction / Reason ]
I would like to issue a new ncbi-entrez-direct upload (patch attached)
adjusting two wrapper scripts to account fully for their wrappees'
repertoire of options, or at minimum acknowledging that NCBI's efetch
accepts -docsum as shorthand for -format docsum for the sake of
ncbi-blast+'s get_species_taxids script.
(https://bugs.debian.org/990741 has more details.)
[ Impact ]
Without this patch, on systems with ncbi-entrez-direct and acedb-other
both installed, some legitimate usage of efetch intended to pick up
NCBI's version will yield warnings; likewise for einfo with epub-utils
installed alongside ncbi-entrez-direct. (In some corner cases, these
wrapper scripts might even wind up running the wrong efetch or einfo,
though they should at least warn about doing so.)
[ Tests ]
#990741 has an example of the current misbehavior; with this patch in
place, the only diagnostics should be the single WARNING: line from
NCBI's efetch itself, which is entirely safe to disregard.
[ Risks ]
AFAICT, this patch should not affect any command lines intended for
acedb-other's efetch or epub-utils's einfo, but if you want to be
extra cautious, I can limit it to adding -docsum for efetch for now.
[ 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 ]
I am holding off on uploading anything pending feedback on whether to
go forward with the full patch or a scaled-down version that only adds
an acknowledgment of the -docsum shorthand.
Thanks!
unblock ncbi-entrez-direct/14.6.20210224+dfsg-4
diff --git a/debian/changelog b/debian/changelog
index f8b2667..5bb4c46 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+ncbi-entrez-direct (14.6.20210224+dfsg-4) UNRELEASED; urgency=medium
+
+ * debian/{efetch,einfo}: Refresh %ncbi_supported, taking care to include
+undocumented options. (In particular, ncbi-blast+'s
+get_species_taxids uses efetch's undocumented -docsum shorthand.)
+(Closes: #990741.)
+
+ -- Aaron M. Ucko Mon, 05 Jul 2021 22:12:10 -0400
+
ncbi-entrez-direct (14.6.20210224+dfsg-3) unstable; urgency=medium
* debian/man/eblast.1: Extend deprecation notice to eblast.
diff --git a/debian/efetch b/debian/efetch
index 603bdaa..79a2726 100755
--- a/debian/efetch
+++ b/debian/efetch
@@ -28,6 +28,7 @@ my %ncbi_supported = (
'id' => 's',
'input' => 's',
'format' => 's',
+'docsum' => undef,
'style' => 's',
'mode'=> 's',
'seq_start' => 'i',
@@ -38,10 +39,14 @@ my %ncbi_supported = (
'complexity' => 'i',
'chr_start' => 'i',
'chr_stop'=> 'i',
+'showgi' => undef,
'extend' => 'i',
'extrafeat' => 'i',
+'showgaps'=> undef,
+'show-gaps' => undef,
'start' => 'i',
'stop'=> 'i',
+'api_key' => 's',
'raw' => undef,
'json'=> undef,
'nogi'=> undef,
@@ -49,14 +54,26 @@ my %ncbi_supported = (
'tool'=> 's',
'pipe'=> undef,
'help'=> undef,
+'example' => undef,
+'examples'=> undef,
+'error' => undef,
+'errors' => undef,
'silent' => undef,
'verbose' => undef,
'debug' => undef,
+'oldmode' => undef,
+'newmode' => undef,
'log' => undef,
+'compact' => undef,
'http'=> 's',
'https' => 's',
'alias' => 's',
-'base'=> 's');
+'base'=> 's',
+'web' => 's',
+'step'=> 'i',
+'label' => 's',
+'timer' => undef,
+'version' => undef);
my %ncbi_abbrev = ();
{
diff --git a/debian/einfo b/debian/einfo
index 570c088..a4d202a 100755
--- a/debian/einfo
+++ b/debian/einfo
@@ -26,19 +26,36 @@ my $epub_keys = 't';
my %ncbi_supported = (
'db' => 's',
'dbs' => undef,
+'field' => undef,
'fields' => undef,
+'link'=> undef,
'links' => undef,
+'test'=> undef,
+'tests' => undef,
+'api_key' => undef,
'email' => 's',
'tool'=> 's',
+'repeat' => undef,
+'repeats' => undef,
+'error' => undef,
+'errors' => undef,
'help'=> undef,
'silent' => undef,
'verbose' => undef,
'debug' => undef,
+'oldmode' => undef,
+'newmode' => undef,
'log' => undef,
+'compact' => undef,
'http'=>
Bug#990741: ncbi-entrez-direct: efetch and einfo wrappers warn about some supported options
Package: ncbi-entrez-direct Version: 14.6.20210224+dfsg-3+b2 Severity: serious Justification: maintainer prerogative In the course of checking whether https://bugs.launchpad.net/ubuntu/+source/ncbi-blast+/+bug/1934402 affects ncbi-blast+ in testing and unstable, I observed -- *only* -- a different issue: the efetch wrapper Debian deploys to avoid needing a formal conflict with acedb-other doesn't account for NCBI efetch's undocumented -docsum shorthand, which get_species_taxids uses. The wrapper's heuristics conclude that the NCBI implementation is probably in order, but it's a close call, and somewhat noisy: $ get_species_taxids -n 'Homo sapiens' Launching NCBI efetch rather than AceDB efetch despite misgivings, due to more severe misgivings about AceDB syntax compatibility. If you meant to run AceDB efetch, please explicitly run it via efetch.acedb. AceDB misgivings (1 major, 2 minor): -mode (major) -db (minor) taxonomy json (minor) NCBI misgivings (1 major, 0 minor): -docsum (major) WARNING: Redundant -db 'taxonomy' argument Taxid : 9606 rank : species division : primates scientific name : Homo sapiens common name : human 1 matche(s) found. I could certainly patch get_species_taxids, but would prefer to adjust ncbi-entrez-direct's efetch wrapper, since -docsum is legitimate, just undocumented. A full sweep revealed some other gaps in both this wrapper and the analogous einfo wrapper, mostly around other undocumented options. AFAICT, these arguments are all at *best* unlikely for these commands' homonyms; for instance, -docsum could only correspond to -d Specify database file (avoid this) with an inline value "ocsum"(!) -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncbi-entrez-direct depends on: ii curl7.74.0-1.3 ii libc6 2.31-12 ii libwww-perl 6.52-1 ii libxml-simple-perl 2.25-1 ii perl5.32.1-4 ii wget1.21-1+b1 ncbi-entrez-direct recommends no packages. Versions of packages ncbi-entrez-direct suggests: ii curl 7.74.0-1.3 ii libxml2-utils 2.9.10+dfsg-6.7 ii python33.9.2-3 -- no debconf information
Bug#989922: thunderbird: testing: no external https images; NS_ERROR_NET_INADEQUATE_SECURITY?
Package: thunderbird Version: 1:78.11.0-1 Severity: important X-Debbugs-Cc: team+pkg-mozi...@tracker.debian.org The recent Thunderbird upgrade from 1:78.11.0-1~deb10u1 to 1:78.11.0-1 in testing broke loading of secure (https) external images. I'd expected this upgrade to be a formality; seeing as it evidently wasn't, I suspect fallout from building against libnss3 2:3.66-1 but then running against 2:3.61-1, and have copied the pkg-mozilla team accordingly. I see a new NS_ERROR_NET_INADEQUATE_SECURITY complaint at startup concerning https://live.thunderbird.net/, and error console messages of the form " : server does not support RFC 5746, see CVE-2009-3555" though I'm not entirely certain the latter are new because I don't normally have occasion to consult the error console. ;-) Could you please take a look? Thanks! -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libbotan-2-172.17.3+dfsg-2 ii libbz2-1.0 1.0.8-4 ii libc62.31-12 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4 ii libicu67 67.1-6 ii libjson-c5 0.15-2 ii libnspr4 2:4.29-1 ii libnss3 2:3.61-1 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.1-1 ii libx11-xcb1 2:1.7.1-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxext6 2:1.3.3-1.1 ii libxrender1 1:0.9.10-1 ii psmisc 23.4-2 ii x11-utils7.7+5 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2019.10.06-1 Versions of packages thunderbird suggests: ii apparmor 2.13.6-10 ii fonts-lyx 2.3.6-1 ii libgssapi-krb5-2 1.18.3-5 ii libgtk2.0-0 2.24.33-2 -- no debconf information
Bug#949767: arrayfire update fails in configure step
Andreas Tille writes: > https://salsa.debian.org/science-team/arrayfire/-/jobs/1608881 It looks like you're down to two real errors: CMake Error: File /builds/science-team/arrayfire/debian/output/source_dir/extern/forge/CMakeModules/version.h.in does not exist. CMake Error at CMakeModules/AFconfigure_forge_submodule.cmake:47 (configure_file): configure_file Problem configuring file Please try commenting out the configure_file call at the end of CMakeModules/AFconfigure_forge_submodule.cmake. CMake Error at /usr/share/cmake-3.18/Modules/ExternalProject.cmake:2350 (message): error: could not find git for clone of clFFT-ext Call Stack (most recent call first): /usr/share/cmake-3.18/Modules/ExternalProject.cmake:3206 (_ep_add_download_command) CMakeModules/build_clFFT.cmake:33 (ExternalProject_Add) src/backend/opencl/CMakeLists.txt:15 (include) Please try adding a build dependency on libclfft-dev and replacing src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call to find_package(clFFT) > Thanks a lot for your initial hint No problem. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#949767: arrayfire update fails in configure step
Andreas Tille writes: > /usr/bin/ld: cannot find -lpthreads Thanks for posting a link to the full log! AFAICT, the actual errors appear much earlier, on lines 1573-1593: CMake Error: File /builds/science-team/arrayfire/debian/output/source_dir/extern/forge/CMakeModules/version.h.in does not exist. CMake Error at CMakeModules/AFconfigure_forge_submodule.cmake:47 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): CMakeLists.txt:117 (include) CMake Error at CMakeLists.txt:163 (add_subdirectory): add_subdirectory given source "extern/spdlog" which is not an existing directory. CMake Error at CMakeLists.txt:164 (add_subdirectory): add_subdirectory given source "extern/glad" which is not an existing directory. -- Performing Test has_ignored_attributes_flag -- Performing Test has_ignored_attributes_flag - Success -- Performing Test has_all_warnings_flag -- Performing Test has_all_warnings_flag - Success CMake Error at /usr/share/cmake-3.18/Modules/ExternalProject.cmake:2350 (message): error: could not find git for clone of clFFT-ext Call Stack (most recent call first): /usr/share/cmake-3.18/Modules/ExternalProject.cmake:3206 (_ep_add_download_command) CMakeModules/build_clFFT.cmake:33 (ExternalProject_Add) src/backend/opencl/CMakeLists.txt:15 (include) The subsequent output consists of dumps of CMake's internal logs, which sometimes provide additional clues but need to be taken in context; for instance, the -lpthreads error comes from -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE (ll. 1472-1480). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986592: closed by Debian FTP Masters (reply to u...@debian.org (Aaron M. Ucko)) (Bug#986592: fixed in kaptive 0.7.3-2)
Andreas Tille writes: > Do you have any idea why your means to fix this issue were not > successfully? Ah, yeah, a closer look indicates that the code I patched takes effect only for *silent* crashes, whereas these were fatal exceptions accompanied by error messages. I'll look into broadening this workaround accordingly. Meanwhile, thanks for pinging me -- I'd optimistically skipped subscribing to this bug (but will do so now). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Control: reassign -1 kaptive 0.7.3-1 Andreas Tille writes: > Thanks a lot. Its very relieving to know a competent person behind > this I appreciate the kind words, but am alas unclear on where precisely BLAST+ is going wrong here. That said, I do see that future releases will incorporate an overhaul of some of the relevant portions of libseqdb, which with any luck will help in the long term, but which I'd rather not try to backport at this stage of the release cycle. The good news is that in response to previous issues along these lines (e.g., https://bugs.debian.org/970344), kleborate already supports retrying in single-threaded mode under some circumstances; kaptive just needs to indicate that it should do so, which it currently does only for much older versions. I'll extend the relevant version range shortly, and am reassigning this bug accordingly. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Andreas Tille writes: > Thanks a lot for your investigation. Unfortunately I have no idea how > to proceed from here. Does anybody have an idea? I mean a better idea > than just stating this package does not work on arm64 which would > probably some last resort. Don't worry, I am still looking into this crash, and had primarily intended that comment as a public note to myself -- the crash occured within a (presumably valid) call to ncbi-blast+, and wound up taking quite a few tries to reproduce on the porterbox I was using (amdahl), so once I finally obtained more details, I wanted to make very sure I wouldn't be able to lose them. Sorry for any resulting confusion. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
u...@debian.org (Aaron M. Ucko) writes: > Andreas Tille writes: > >> do you have possibly any hint what might be wrong here? > > Thanks for calling this bug to my attention! Based on reports I've seen > upstream, I suspect the problem may lie in some relatively new > usage-reporting code that Debian should probably disable by default > regardless, in retrospect. I'll look into it. Never mind, this appears to be a different issue, per a backtrace obtained with EXCEPTION_STACK_TRACE_LEVEL=Error and a great deal of patience: Error: tblastn encountered an error: terminate called after throwing an instance of 'ncbi::CMutexException' what(): NCBI C++ Exception: T29 "c++/include/corelib/ncbidiag.hpp", line 417: Error: (CMutexException::eOwner) ncbi::ncbi_namespace_mutex_mt::SSystemMutex::ThrowNotOwned() - Mutex is not owned by current thread Stack trace: /usr/lib/ncbi-blast+/libxncbi.so ???:0 ncbi::CMutexException::CMutexException(ncbi::CDiagCompileInfo const&, ncbi::CException const*, ncbi::CMutexException::EErrCode, std::__cxx11::basic_string, std::allocator > const&, ncbi::EDiagSev) offset=0x3C addr=0x83061d9c /usr/lib/ncbi-blast+/libxncbi.so ???:0 ncbi::ncbi_namespace_mutex_mt::SSystemMutex::ThrowNotOwned() offset=0x88 addr=0x82f76534 /usr/lib/ncbi-blast+/libxncbi.so ???:0 ncbi::ncbi_namespace_mutex_mt::SSystemMutex::Unlock(ncbi::ncbi_namespace_mutex_mt::SSystemFastMutex::ELockSemantics) offset=0x78 addr=0x83057938 /usr/lib/ncbi-blast+/libseqdb.so ???:0 ncbi::CSeqDBLockHold::~CSeqDBLockHold() offset=0x30 addr=0x84305fa0 /usr/lib/ncbi-blast+/libseqdb.so ???:0 ncbi::CSeqDBImpl::GetSeqLength(int) const offset=0x48 addr=0x8432ca1c /usr/lib/ncbi-blast+/libblast.so ???:0 BLAST_SetupPartialFetching offset=0x134 addr=0x84442904 /usr/lib/ncbi-blast+/libblast.so ???:0 offset=0x27938 addr=0x8441f938 /usr/lib/aarch64-linux-gnu/libgomp.so.1 ???:0 offset=0x18CB0 addr=0x81f19cb0 /lib/aarch64-linux-gnu/libpthread.so.0 ???:0 offset=0x8628 addr=0x82027628 /lib/aarch64-linux-gnu/libc.so.6 ???:0 offset=0xD601C addr=0x82c2001c -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Andreas Tille writes: > do you have possibly any hint what might be wrong here? Thanks for calling this bug to my attention! Based on reports I've seen upstream, I suspect the problem may lie in some relatively new usage-reporting code that Debian should probably disable by default regardless, in retrospect. I'll look into it. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986373: dpkg: please preserve unchanged content on upgrades
Package: dpkg Version: 1.20.7.1 Severity: wishlist When upgrading a package, it is by no means unheard of for many of its files to preserve their contents (though not necessarily their metadata). This phenomenon is particularly common for minor upgrades, as with stable updates or many upgrades within development suites (testing, unstable, and experimental). In this era of reproducible builds, it commonly even extends to compiled binaries such as shared libraries, whose upgrades currently always trip needrestart. It would be great if dpkg could handle this scenario with less formal disruption. At minimum, instead of unconditionally renaming .dpkg-new files into place, perhaps it could compare them with the files they are to replace (after confirming that they are in fact regular files) and in the case of an exact match simply resync metadata and remove corresponding .dpkg-new files. A more elaborate approach could reduce peak disk usage in many cases: immediately after creating a .dpkg-new file, compare it with the file it is to replace, and in the case of an exact match discard the .dpkg-new file in favor of an empty file with an extension of (say) .dpkg-newmeta and the desired permissions and ownership. The rename phase would then check for such .dpkg-newmeta files and proceed accordingly. Thanks in advance for considering this suggestion! -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-11 ii liblzma5 5.2.5-2 ii libselinux1 3.1-3 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.2.2 pn debsig-verify -- no debconf information
Bug#892058: Your Debian key is expiring
(Bcc: Felix) Felix Lechner writes: > If you like this service, please leave a favorable comment here [2]. Please count me among those who found these reminders helpful. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#984620: fltk1.1: Please add a Wayland driver
Guillem Jover writes: > Given that the X.Org server is apparently pretty much dead, that other > distributions are also switching to Wayland and that most mainstream > desktop environments now support this natively. It would be nice to > have fltk support this too. Hi, Guillem. That's a fair request, but alas doesn't have a good formal home in Debian at the moment -- I've been using a separate source package for each upstream release series, and per the upstream report's feedback, Wayland support won't be happening for the 1.3 branch (fltk1.3 source package), let alone 1.1 (long dead upstream, to be belatedly retired from Debian post-buster). I expect it would be non-trivial to backport even to 1.3. I suppose I could construe this report as an RFP for fltk1.4, but that code base hasn't yet either had an official upstream release or gained Wayland support. How would you like to proceed? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#983239: libbio-db-ncbihelper-perl: (autopkg)test failures when network is available
Étienne Mollier writes: > I have been looking in the issue below in the package > libbio-db-ncbihelper-perl. If I understood correctly, the main > point of the package is to rely on resources made available on > the Internet. I'm not sure I've been personally involved with this package, but that's my understanding as well. > a perhaps magic index to refer to human genome, but maybe it is > a "well known index".) Per [1], taxonomic ID *numbers* are stable in general, but the associated *names* occasionally change to reflect improved understandings of the underlying science. AFAICT from [2] (as linked from [3]), this change is correct and legitimate; moreover, it looks like 'Actinobacteria' should now appear in $n->common_names, if anyone wants to verify that. [1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7408187/ [2] https://www.microbiologyresearch.org/content/journal/ijsem/10.1099/ijsem.0.003920 [3] https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?mode=Info=1760=3=f=1=1 > In any case, I though upstream would be interested, so I took > the liberty to open an issue in their VCS. Thanks! gregor herrmann writes: > I still think that NO_NETWORK_TESTING=1 should be set in debian/rules > to make sure there's no internet access attempted during the build, > as that is a policy violation. Right, we're just discussing what to do about the autopkgtest. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#917851: Failed build for seqan2 on i386
Andreas Tille writes:
> But other 32bit architectures like armel and armhf are passing[2]. So I
> fail to see why exactly i386 is failing. Is this possibly an effect of
> bug #917851?
Probably not; dropping the bug to a Bcc. Experimentation in an i386
chroot reveals the problem to be specifically with yara_mapper, which
https://salsa.debian.org/med-team/seqan2/-/blob/master/debian/patches/skip-some-apps-on-some-archs
explicitly excludes (along with yara_indexer) on several other 32-bit
platforms. We could go the same route for i386, but AFAICT it suffices
to drop the optimization level back down to -O2 for this specific
application, by adding
# Drop back from global -O3 on i386 to avoid
# "virtual memory exhausted: Operation not permitted"
if ("$ENV{DEB_BUILD_ARCH}" STREQUAL "i386")
target_compile_options (yara_mapper PRIVATE "-O2")
endif ()
to apps/yara/CMakeLists.txt following the add_executable call for
yara_mapper. (If and when debian/rules honors noopt, we should further
conditionalize this call accordingly, but I'm not familiar enough with
cmake to come up with the correct syntax offhand.) We could perhaps try
doing the same for other affected platforms in an upload to
experimental.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#981293: [Help] Re: metastudent-data breaks metastudent autopkgtest: 255
Whoops, I had a typo in that last command; if you go that route, please make it makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" -blastdb_version 4 (I'd first try pushing forward, though.) Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#981293: [Help] Re: metastudent-data breaks metastudent autopkgtest: 255
Control: tags -1 + upstream Andreas Tille writes: > Aaron (or whoever might want to check), do you have any idea? Due to metastudent-data's unwieldiness, I haven't tested thoroughly, but AFAICT the immediate, and with any luck only, problem is more fallout from the switch to BLASTDB version 5 format by default, which we can address in one of two ways: - Patch metastudent-data's build system to include more generated output in install-data-local. It should at minimum allow *.pdb in addition to *.phr, *.pin, and *.psq. Additionally allowing *.pot, *.ptf, and *.pto would cover the full range of current BLAST database components (though the files with those three extensions appear to be relatively specialized and perhaps not strictly necessary), and allowing all of *.p?? would make for best futureproofing. OR - Patch the build system to produce a legacy V4 database, which would ironically require cutting out the legacy formatdb wrapper, by changing the formatdb invocation to makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" -blastb_version 4 Thanks for checking! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#982276: htmldoc: please migrate to fltk1.3
Source: htmldoc Version: 1.9.11-1 Severity: normal htmldoc still builds against FLTK 1.1, for which it is long past time for Debian to drop support. Please migrate to 1.3, which is likely as simple as adjusting htmldoc's build dependencies and ensuring that it uses UTF-8 rather than a legacy text encoding. Also, please note that fltk-config (in both branches) differs from typical *-config scripts in having --libs yield paths to *static* libraries. If your build has been making use of this syntax, please substitute --ldflags to obtain proper dynamic linkage. (FLTK does not yet offer pkg-config metadata, sorry.) For more details, please see the debian-devel thread starting at https://lists.debian.org/msgid-search/udl1rh34720@ucko.debian.net. (I'd omitted htmldoc from the initial crop of reports because it was orphaned at the time and as such eligible for a QA upload. Now that you've adopted the package, this migration formally falls to you.) Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#982266: fltk1.1: ftbfs in sid
Gianfranco Costamagna writes: > dh_missing: error: missing files, aborting Oops! Thanks for pointing it out; I'm surprised the autobuilders didn't. > (this is probably due to compat=13 change) Indeed. I'm on it now, with a mixed approach of skipping fluid installation and meanwhile listing uncompressed man (and cat!) pages in debian/not-installed. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...
Dominic Hargreaves writes: > As a hunch, I changed the default from 'gpg' to '/usr/bin/gpg'. > Could you install this on your system and confirm whether it fixes > the problem? I must confess that I haven't actually fully deployed MonkeySphere, so I can't test the change quite as thoroughly as it perhaps deserves, but AFAICT this tweak is sufficient: I can log in without incident, and both dh_auto_test calls to succeed (albeit noisily) with -- FULLPERL='/usr/bin/perl -t' appended. (Full -T appears to break the test harness, but -t suffices to trigger the PATH-clearing logic.) Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#981647: libgnupg-interface-perl 1.01 breaks ssh-agent msva-perl ...
Package: libgnupg-interface-perl Version: 1.01-1 Severity: important Tags: upstream X-Debbugs-Cc: msva-p...@packages.debian.org Control: affects -1 msva-perl [Copying msva-perl maintainers.] My X session normally boils down to exec /usr/bin/ssh-agent /usr/bin/monkeysphere-validation-agent /usr/bin/im-launch x-session-manager where /usr/bin/monkeysphere-validation-agent resolves (via the alternatives system) to /usr/bin/msva-perl. With this setup, libgnupg-interface-perl 1.01 attempts to run gpg with no PATH and bails because it couldn't find an acceptable version of gpg, thereby immediately crashing msva-perl and my entire X session. I'm not entirely sure what triggers the PATH-clearing here, perhaps the fact that ssh-agent is setgid ssh. Regardless, I'd suggest setting a sane PATH that includes at minimum /bin and /usr/bin rather than clearing PATH entirely. (Explicitly running /usr/bin/gpg might also work.) Could you please take a look? Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgnupg-interface-perl depends on: ii gnupg 2.2.20-1 pn libautodie-perl ii libmoo-perl 2.004004-1 ii libmoox-handlesvia-perl 0.001009-1 ii libmoox-late-perl 0.100-1 ii perl [libmath-bigint-perl] 5.32.0-6 libgnupg-interface-perl recommends no packages. libgnupg-interface-perl suggests no packages. -- no debconf information
Bug#981183: dictionary-el: NMU diff
David Bremner writes: > I have just uploaded (to delayed=2) a no source change rebuild of > dictionary-el. Thanks for prompting me to revisit this package! FTR, I superseded this NMU at the last minute to work in some other formal changes that were in order: dictionary-el (1.10+git20190107-3) unstable; urgency=medium . [ David Bremner ] * Implicitly rebuild with dh-elpa 2.x. . [ Aaron M. Ucko ] * .gitignore: Drop debian (a conditional symlink upstream). * Standards-Version: 4.5.1 (routine-update) * debhelper-compat 13 (routine-update) * Add salsa-ci file (routine-update) * Trim trailing whitespace. * Update watch file format version to 4. * Use secure URI in Homepage field. * Upgrade to newer source format 3.0 (quilt). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#980077: apt-cacher: please recognize new pdiff name format by default
Mark Hindley writes:
> pdiff_files_regexp = (?:^|[/-])2\d{3}-\d{2}-\d{2}-\d{4}\.\d{2}\.gz$
Yeah, that may well suffice after all; I just threw together a quick
tweak on the basis of aptitude's terminal output (which gives nominal
.pdiff extensions), and wanted to err on the side of inclusiveness.
Thanks for sorting it out properly!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
