Bug#939767: fuse3: patch restoring "-o nonempty"
Hi László, On Fri, 29 Jan 2021 07:23:35 +0100, László Böszörményi (GCS) wrote: > On Thu, Jan 28, 2021 at 9:18 AM Stephen Kitt wrote: > > I've prepared a patch which restores support for "-o nonempty", thus > > allowing programs using that option with fuse to continue working > > as-is with fuse3 (where the default behaviour is equivalent to "-o > > nonempty"). > The patch itself looks good. I will try to do some testing in the > afternoon, but will apply and upload it with some other changes. Fantastic, thanks! The patch was merged upstream too, https://github.com/libfuse/libfuse/pull/582 Regards, Stephen pgpfGnyOkTiCp.pgp Description: OpenPGP digital signature
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Hi Markus, thanks for the hint about holding and pinning packages. We're aware of that and did exactly the pinning variant for the pacemaker packages, after the broken release ;-) In my opinion the crmsh package should be more strict with the pacemaker-cli-utils package, if this is a possible option. There is always an alternative for crmsh, the pcs package. Maybe that's the reason why the pacemaker package is not so strict with the cli package. But that is beyond my knowledge. Thank you for the support and the update of the package to the current version. Best regards, Thorsten On Thu, 28 Jan 2021 at 18:50, Markus Koschany wrote: > > Hello Thorsten, > > Am Donnerstag, den 28.01.2021, 14:52 +0100 schrieb Thorsten Rehm: > > Hi Markus, > > > > thank you for your reply. > > I've installed a fresh Debian Stretch and I think I know why I had > > such a problem. I believe it's a dependency problem, but I let you > > decide, if this is the case. > > We're always installing the packages "pacemaker" and "crmsh" on our > > systems. As you know, the latter one has a dependency to the > > "pacemaker-cli-utils" package: > > [...] > > Indeed the problem could have been avoided if either the pacemaker-cli-utils > dependency of crmsh or the Recommends: pacemaker-cli-utils in pacemaker was > more strict. However the general issue here is that you instruct apt to > install > specific packages instead of upgrading the existing ones. If your policy > forbids upgrades then I suggest to mark packages you don't want to upgrade as > "on hold" or use apt pinning to change the priority of your packages. Then you > could still use the upgrade command for the remaining packages. I recommend to > install security updates though unless you are absolutely sure your > systems/configurations are not affected. I leave it to the maintainer of > pacemaker if he wants to tighten the Recommends of pacemaker-cli-utils in the > future. > > Regards, > > Markus
Bug#980786: named: after upgrade to bind9=1:9.16.11-1 named is killed with status=11/SEGV
Control: tag -1 pending Hi Damir, > The patch has been merged. Thanks, I'm just testing the fix and will upload it shortly. Bernhard
Bug#981300: [Pkg-electronics-devel] Bug#981300: arduino-core-avr breaks arduino-mk
Hi guys, On Fri, Jan 29, 2021 at 07:00:32AM +0100, Carsten Schoenert wrote: > Control: reassign -1 arduino-mk > Control: rename -1 arduino-mk: needs to depend on arduino >= > 2:1.8.13+dfsg1-1 > Control: severity -1 serious > > Hello Simon, > > thanks for reporting! > > Am 28.01.21 um 22:42 schrieb debi...@the-jedi.co.uk: > > Package: arduino > > Version: 1.8.13+dfsg1-1 > > > > The recent rename of arduino-core to arduino-core-avr breaks the Depends > > in arduino-mk: > > > > Depends: > > arduino-core (>= 1:1.0+dfsg-8), > > This is not fully correct, the old package arduino-core got melted into > arduino, arduino-core-avr is a new dependency of arduino. > > arduino-mk needs to get adjusted, it needs to change this existing > Depends into > > arduino-core (>= 2:1.8.13+dfsg1-1) This is interesting because '2:1.8.13+dfsg1-1' is already greater than or equal to '1:1.0+dfsg-8'. So unless I'm missing something there the current line on 'arduino-mk' control file should be fine. I thought problems like these will not arise thanks to the line in the current arduino control file that says: Provides: arduino-core Which is the bit I fear is not working properly. Maybe a version number needs to be added to that line? I'll give that a try later today. > > So doing a dist-upgrade and pulling in the new arduino, arduino-core-avr > > etc; removes arduino-core and arduino-mk > > The removal of arduino-core is a thing what we want and need, the > removal of ardunino-mk is grounded on the non updated correct adjusted > new dependency. But maybe an updated arduino-mk is now also needed, I > haven't looked into this yet. > > > Also why are you just now packaging arduino-builder when arduino-cli has > > already replaced it? > Yes, there is arduino-cli already out there. But we decided to stick for > now with arduino-builder because arduino-cli brings in a lot of Go > related new package dependencies which we wouldn't get into Debian > before the final package freeze for Debian Bullseye. We wanted to have > the option that it's really likely that we can get arduino and related > packages ready for Bullseye. > And that's also the reason why arduino-builder isn't the most resent > version, this would also need at least three more new Go packages as > build dependency. > > So it's not that we don't want to use arduino-cli, it was a weight out > of what's possible in the given time span. I just want to add here that, as stated by the Arduino Team "[arduino-cli] is currently under active development: anything can change at any time, API and UI must be considered unstable until we release version 1.0.0." Which makes it, in my opinion, unsuitable to released on Debian stable. Regards, -- Rock Storm GPG KeyID: 4096R/C96832FD
Bug#939767: fuse3: patch restoring "-o nonempty"
Hi Stephen, On Thu, Jan 28, 2021 at 9:18 AM Stephen Kitt wrote: > I've prepared a patch which restores support for "-o nonempty", thus > allowing programs using that option with fuse to continue working > as-is with fuse3 (where the default behaviour is equivalent to "-o > nonempty"). The patch itself looks good. I will try to do some testing in the afternoon, but will apply and upload it with some other changes. Thanks, Laszlo/GCS
Bug#981317: ITP: ruby-rdoc -- produces HTML and command-line documentation for Ruby
Package: wnpp Severity: wishlist Owner: Leandro Cunha * Package name : ruby-rdoc Version : 6.3.0 Upstream Author : Eric Hodel * URL : https://github.com/ruby/rdoc * License : Ruby Programming Lang : Ruby Description : RDoc produces HTML and command-line documentation for Ruby projects. RDoc includes the rdoc and ri tools for generating and displaying documentation from the command-line. [1] https://rubygems.org/gems/rdoc [2] https://ruby.github.io/rdoc -- Cheers, Leandro Cunha Debian Contributor and developer.
Bug#981316: leptonlib: reduce Build-Depends
Source: leptonlib Version: 1.79.0-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap leptonlib participates in dependency loops relevant to architecture bootstrap. Rather than look into such a hard problem, I looked into easily droppable dependencies. It turns out that libzzip-dev is entirely unused and not mentioned anywhere in the source beyond debian/control. gnuplot-nox is only required for testing and can be annotated . Please consider applying the attached patch. Helmut diff --minimal -Nru leptonlib-1.79.0/debian/changelog leptonlib-1.79.0/debian/changelog --- leptonlib-1.79.0/debian/changelog 2020-01-02 20:02:45.0 +0100 +++ leptonlib-1.79.0/debian/changelog 2021-01-28 20:38:08.0 +0100 @@ -1,3 +1,12 @@ +leptonlib (1.79.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Reduce Build-Depends: (Closes: #-1) ++ Annotated gnuplot-nox as it is only required for testing. ++ Drop unused libzzip-dev. + + -- Helmut Grohne Thu, 28 Jan 2021 20:38:08 +0100 + leptonlib (1.79.0-1) unstable; urgency=medium * New upstream release diff --minimal -Nru leptonlib-1.79.0/debian/control leptonlib-1.79.0/debian/control --- leptonlib-1.79.0/debian/control 2020-01-02 20:02:45.0 +0100 +++ leptonlib-1.79.0/debian/control 2021-01-28 20:38:06.0 +0100 @@ -1,7 +1,7 @@ Source: leptonlib Priority: optional Maintainer: Jeff Breidenbach -Build-Depends: debhelper (>= 10.0.0), libtiff-dev, libpng-dev, libgif-dev (>= 4.1.6), libwebp-dev (>= 0.4.0), libopenjp2-7-dev, automake, pkg-config, gnuplot-nox, libzzip-dev +Build-Depends: debhelper (>= 10.0.0), libtiff-dev, libpng-dev, libgif-dev (>= 4.1.6), libwebp-dev (>= 0.4.0), libopenjp2-7-dev, automake, pkg-config, gnuplot-nox Standards-Version: 4.1.3 Section: graphics
Bug#981315: mark node-tslib Multi-Arch: foreign
Source: node-tslib
Version: 2.1.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:browserpass
browserpass cannot be cross built from source, because its transitive
dependency on node-tslib is not satisfiable. In general, Architecture:
all packages can never satisfy cross Build-Depends unless marked
Multi-Arch: foreign or annotated :native. In this case, the foreign
marking is reasonable as node-tslib is a pure javascript library without
any dependencies nor maintainer scripts. Please consider applying the
attached patch.
Helmut
diff --minimal -Nru node-tslib-2.1.0/debian/changelog
node-tslib-2.1.0/debian/changelog
--- node-tslib-2.1.0/debian/changelog 2021-01-18 12:17:12.0 +0100
+++ node-tslib-2.1.0/debian/changelog 2021-01-28 21:11:36.0 +0100
@@ -1,3 +1,10 @@
+node-tslib (2.1.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark node-tslib Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Thu, 28 Jan 2021 21:11:36 +0100
+
node-tslib (2.1.0-1) unstable; urgency=medium
* Team upload
diff --minimal -Nru node-tslib-2.1.0/debian/control
node-tslib-2.1.0/debian/control
--- node-tslib-2.1.0/debian/control 2021-01-18 12:07:57.0 +0100
+++ node-tslib-2.1.0/debian/control 2021-01-28 21:11:31.0 +0100
@@ -16,6 +16,7 @@
Package: node-tslib
Architecture: all
+Multi-Arch: foreign
Depends:
${misc:Depends}
Description: Implementation of tslib for javascript
Bug#981314: freeglut: drop unused Build-Depends: libxt-dev
Source: freeglut Version: 2.8.1-6 Tags: patch User: helm...@debian.org Usertags: rebootstrap freeglut participates in dependency loops relevant to architecture bootstrap. Rather than look into such a hard problem, I looked into easily droppable dependencies and found that freeglut does not use libxt-dev in any way. Please consider applying the attached patch to drop it. Helmut diff --minimal -Nru freeglut-2.8.1/debian/changelog freeglut-2.8.1/debian/changelog --- freeglut-2.8.1/debian/changelog 2020-05-09 13:54:39.0 +0200 +++ freeglut-2.8.1/debian/changelog 2021-01-29 07:04:12.0 +0100 @@ -1,3 +1,10 @@ +freeglut (2.8.1-6.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused Build-Depends: libxt-dev. (Closes: #-1) + + -- Helmut Grohne Fri, 29 Jan 2021 07:04:12 +0100 + freeglut (2.8.1-6) unstable; urgency=medium [ Steve Langasek ] diff --minimal -Nru freeglut-2.8.1/debian/control freeglut-2.8.1/debian/control --- freeglut-2.8.1/debian/control 2020-05-01 21:55:48.0 +0200 +++ freeglut-2.8.1/debian/control 2021-01-29 07:04:11.0 +0100 @@ -12,7 +12,6 @@ libx11-dev, libxext-dev, libxi-dev, - libxt-dev, libxxf86vm-dev [amd64 i386] Standards-Version: 4.5.0 Vcs-Browser: https://salsa.debian.org/debian/freeglut
Bug#981313: cvs: reduce Build-Depends
Source: cvs
Version: 2:1.12.13+real-27
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
cvs participates in dependency loops relevant to architecture bootstrap.
Instead of looking into such a difficult problem, I used reproducible
builds to look for easily droppable dependencies. It turns out that a
regular build of cvs exactly reproduces the binary artifacts of a build
with the attached patch applied (without d/changelog). Comparing the
build logs does not reveal skipped tests or like that. As such the
reduction seems safe:
* Drop bsdmainutils.
* Drop procps.
* Reduce texlive-{fonts,latex}-recommended to texlive-base.
Please consider applying the patch.
Helmut
diff -u cvs-1.12.13+real/debian/changelog cvs-1.12.13+real/debian/changelog
--- cvs-1.12.13+real/debian/changelog
+++ cvs-1.12.13+real/debian/changelog
@@ -1,3 +1,12 @@
+cvs (2:1.12.13+real-27.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Reduce Build-Depends: (Closes: #-1)
++ Drop unused bsdmainutils and procps.
++ Reduce texlive-{fonts,latex}-recommended to texlive-base.
+
+ -- Helmut Grohne Thu, 28 Jan 2021 20:46:20 +0100
+
cvs (2:1.12.13+real-27) unstable; urgency=low
* Hardcode path to /bin/mktemp during configure to build reproducibly
diff -u cvs-1.12.13+real/debian/control cvs-1.12.13+real/debian/control
--- cvs-1.12.13+real/debian/control
+++ cvs-1.12.13+real/debian/control
@@ -3,9 +3,9 @@
Priority: optional
Maintainer: Thorsten Glaser
Homepage: http://www.nongnu.org/cvs/
-Build-Depends: debhelper (>= 11), bsdmainutils,
- ghostscript, groff, libbsd-dev, libkrb5-dev | heimdal-dev, procps,
- texinfo, texlive-latex-recommended, texlive-fonts-recommended, zlib1g-dev
+Build-Depends: debhelper (>= 11),
+ ghostscript, groff, libbsd-dev, libkrb5-dev | heimdal-dev,
+ texinfo, texlive-base, zlib1g-dev
Standards-Version: 4.3.0
Rules-Requires-Root: no
VCS-git: https://evolvis.org/anonscm/git/alioth/cvs.git -b master
Bug#981312: lensfun: drop unused Build-Depends: libpng-dev
Source: lensfun Version: 0.3.2-5 Tags: patch User: helm...@debian.org Usertags: rebootstrap lensfun participates in dependency loops relevant to architecture bootstrap. Rather than looking into such a difficult problem, I looked for easily droppable dependencies. It turns out that lensfun does not actually use libpng-dev. It's an optional dependency used for builing lenstool, but the relevant flag (-DBUILD_LENSTOOL=ON) is not passed. Please consider applying the attached patch to drop it. Helmut diff --minimal -Nru lensfun-0.3.2/debian/changelog lensfun-0.3.2/debian/changelog --- lensfun-0.3.2/debian/changelog 2020-01-31 11:39:30.0 +0100 +++ lensfun-0.3.2/debian/changelog 2021-01-28 20:32:33.0 +0100 @@ -1,3 +1,11 @@ +lensfun (0.3.2-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused Build-Depends: libpng-dev as -DBUILD_LENSTOOL=ON is not +passed. (Closes: #-1) + + -- Helmut Grohne Thu, 28 Jan 2021 20:32:33 +0100 + lensfun (0.3.2-5) unstable; urgency=medium * Switch Vcs-* fields to salsa.debian.org. diff --minimal -Nru lensfun-0.3.2/debian/control lensfun-0.3.2/debian/control --- lensfun-0.3.2/debian/control2020-01-31 11:23:11.0 +0100 +++ lensfun-0.3.2/debian/control2021-01-28 20:32:32.0 +0100 @@ -5,7 +5,6 @@ Pino Toscano Build-Depends: debhelper-compat (= 12), cmake, pkg-config, python3, libglib2.0-dev, dh-python, - libpng-dev, doxygen, python3-docutils, Standards-Version: 4.5.0
Bug#981310: tcm FTCBFS: uses the build architecture compiler
Source: tcm Version: 2.20+TSQD-6 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs tcm fails to cross build from source, because it does not pass cross tools to make. Since it does not use the standard variable names, using dh_auto_build is not helpful here. Passing them explicitly makes tcm cross build. Please consider applying the attached patch. Helmut diff --minimal -Nru tcm-2.20+TSQD/debian/changelog tcm-2.20+TSQD/debian/changelog --- tcm-2.20+TSQD/debian/changelog 2020-08-02 22:17:38.0 +0200 +++ tcm-2.20+TSQD/debian/changelog 2021-01-28 16:57:06.0 +0100 @@ -1,3 +1,9 @@ +tcm (2.20+TSQD-7) UNRELEASED; urgency=medium + + * Fix FTCBFS: Pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Thu, 28 Jan 2021 16:57:06 +0100 + tcm (2.20+TSQD-6) unstable; urgency=medium * QA upload. diff --minimal -Nru tcm-2.20+TSQD/debian/rules tcm-2.20+TSQD/debian/rules --- tcm-2.20+TSQD/debian/rules 2020-08-02 22:08:21.0 +0200 +++ tcm-2.20+TSQD/debian/rules 2021-01-28 16:57:06.0 +0100 @@ -3,6 +3,8 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +include /usr/share/dpkg/buildtools.mk + CFLAGS = -Wall -g CFLAGS += -fcommon @@ -27,7 +29,9 @@ build-stamp: configure-stamp dh_testdir - $(MAKE) CFLAGS='$(CFLAGS) -DCONFIG_INSTALL=\"/etc/tcm/\" -DTCM_INSTALL_DIR=\"/usr\" -DTCM_INSTALL_LIB=\"/usr/lib/\" -DTCM_INSTALL_SHARE=\"/usr/share/doc/tcm-doc/\" -DCONFIG_FILE=\"tcm.conf\" -DHELP_DIR=\"/usr/share/doc/tcm-doc/help/\" -DCOLOR_FILE=\"colorrgb.txt\" -DBANNER_FILE=\"banner.ps\"' \ + $(MAKE) Cc='$(CC)' \ + CC='$(CXX)' \ + CFLAGS='$(CFLAGS) -DCONFIG_INSTALL=\"/etc/tcm/\" -DTCM_INSTALL_DIR=\"/usr\" -DTCM_INSTALL_LIB=\"/usr/lib/\" -DTCM_INSTALL_SHARE=\"/usr/share/doc/tcm-doc/\" -DCONFIG_FILE=\"tcm.conf\" -DHELP_DIR=\"/usr/share/doc/tcm-doc/help/\" -DCOLOR_FILE=\"colorrgb.txt\" -DBANNER_FILE=\"banner.ps\"' \ TCM_INSTALL_DIR=/usr \ CONFIG_INSTALL=/etc/tcm/ \ TCM_INSTALL_DOC=/usr/share/doc/tcm-doc \
Bug#981311: mecab: drop unused Build-Depends: python3-setuptools
Source: mecab Version: 0.996-14 Tags: patch User: helm...@debian.org Usertags: rebootstrap mecab participates in dependency loops relevant to architecture bootstrap. Rather than looking into such a difficult problem, I looked into easily droppable dependencies. It turns out that the python extension uses distutils rather than setuptools. Therefore python3-setuptools can be dropped from Build-Depends. Please consider applying the attached patch. Helmut diff --minimal -Nru mecab-0.996/debian/changelog mecab-0.996/debian/changelog --- mecab-0.996/debian/changelog2020-05-30 16:58:11.0 +0200 +++ mecab-0.996/debian/changelog2021-01-28 19:46:55.0 +0100 @@ -1,3 +1,11 @@ +mecab (0.996-14.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop unused python3-setuptools from Build-Depends as it uses distutils. +(Closes: #-1) + + -- Helmut Grohne Thu, 28 Jan 2021 19:46:55 +0100 + mecab (0.996-14) unstable; urgency=medium * debian/tests/control diff --minimal -Nru mecab-0.996/debian/control mecab-0.996/debian/control --- mecab-0.996/debian/control 2020-05-30 16:58:11.0 +0200 +++ mecab-0.996/debian/control 2021-01-28 19:46:54.0 +0100 @@ -4,7 +4,7 @@ Maintainer: Natural Language Processing (Japanese) Build-Depends: debhelper-compat (= 13), perl:native, perl-xs-dev, chrpath, - dh-python, python3-all-dev, python3-setuptools, + dh-python, python3-all-dev, gem2deb, default-jdk, swig, Uploaders: Taku YASUI ,
Bug#981300: arduino-core-avr breaks arduino-mk
Control: reassign -1 arduino-mk Control: rename -1 arduino-mk: needs to depend on arduino >= 2:1.8.13+dfsg1-1 Control: severity -1 serious Hello Simon, thanks for reporting! Am 28.01.21 um 22:42 schrieb debi...@the-jedi.co.uk: > Package: arduino > Version: 1.8.13+dfsg1-1 > > The recent rename of arduino-core to arduino-core-avr breaks the Depends > in arduino-mk: > > Depends: > arduino-core (>= 1:1.0+dfsg-8), This is not fully correct, the old package arduino-core got melted into arduino, arduino-core-avr is a new dependency of arduino. arduino-mk needs to get adjusted, it needs to change this existing Depends into arduino-core (>= 2:1.8.13+dfsg1-1) > So doing a dist-upgrade and pulling in the new arduino, arduino-core-avr > etc; removes arduino-core and arduino-mk The removal of arduino-core is a thing what we want and need, the removal of ardunino-mk is grounded on the non updated correct adjusted new dependency. But maybe an updated arduino-mk is now also needed, I haven't looked into this yet. > Also why are you just now packaging arduino-builder when arduino-cli has > already replaced it? Yes, there is arduino-cli already out there. But we decided to stick for now with arduino-builder because arduino-cli brings in a lot of Go related new package dependencies which we wouldn't get into Debian before the final package freeze for Debian Bullseye. We wanted to have the option that it's really likely that we can get arduino and related packages ready for Bullseye. And that's also the reason why arduino-builder isn't the most resent version, this would also need at least three more new Go packages as build dependency. So it's not that we don't want to use arduino-cli, it was a weight out of what's possible in the given time span. -- Regrads Carsten
Bug#981176: RFP: doas -- minimal replacement for sudo
Hi, On Thu, Jan 28, 2021 at 11:50:33PM +0100, Scupake wrote: > Hello, > > I think the package is mostly ready for review! > "Mostly" because I have no idea how to fix the > "maintainer-script-lacks-debhelper-token" warning. See https://lintian.debian.org/tags/maintainer-script-lacks-debhelper-token.html for a smallish hint. Usually each maintainer-script starts with something like (or mor commented): | #!/bin/sh | | set -e | | #DEBHELPER# | [...] Where then debhelper can replace code snippets. Regards, Salvatore
Bug#981296: [Pkg-javascript-devel] Bug#981296: node-ws: FTBFS: Error: Cannot find module '@types/node'
Control: tags -1 - moreinfo Control: tags -1 + experimental Control: reassign -1 nodejs Control: found -1 14.13.0~dfsg-1 Control: retitle -1 nodejs: missing ts definitions Control: notfound -1 12.20.1~dfsg-3 Le 29/01/2021 à 05:53, Xavier a écrit : > Control: tags -1 + moreinfo > > Le 28/01/2021 à 21:12, Andreas Beckmann a écrit : >> Source: node-ws >> Version: 7.4.1+~cs18.0.6-2 >> Severity: serious >> Tags: ftbfs >> Justification: fails to build from source (but built successfully in the >> past) >> >> Hi, >> >> node-ws/experimental recently started to FTBFS. An earlier build of the >> same version has succeeded, so this new failure is likely due some change >> in a (transitive) build dependency. The version in sid is not affected. >> >> debian/rules binary >> dh binary >>dh_update_autotools_config >>dh_autoreconf >>dh_auto_configure --buildsystem=nodejs >> mkdir node_modules >> ln -s /usr/share/nodejs/debug ./node_modules/ >> mkdir -p ./node_modules/\@types >> ln -s /usr/share/nodejs/\@types/debug ./node_modules/\@types/ >> ln -s /usr/share/nodejs/\@types/mocha ./node_modules/\@types/ >> internal/modules/cjs/loader.js:905 >> throw err; >> ^ >> >> Error: Cannot find module '@types/node' > > Hi, > > this is very strange: @types/node is provided by nodejs itself (since > 12.20), so I don't understand this issue (and I'm unable to reproduce > this issue of course). Sorry, I didn't see that it was related to experimental
Bug#981296: [Pkg-javascript-devel] Bug#981296: node-ws: FTBFS: Error: Cannot find module '@types/node'
Control: tags -1 + moreinfo Le 28/01/2021 à 21:12, Andreas Beckmann a écrit : > Source: node-ws > Version: 7.4.1+~cs18.0.6-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > Hi, > > node-ws/experimental recently started to FTBFS. An earlier build of the > same version has succeeded, so this new failure is likely due some change > in a (transitive) build dependency. The version in sid is not affected. > > debian/rules binary > dh binary >dh_update_autotools_config >dh_autoreconf >dh_auto_configure --buildsystem=nodejs > mkdir node_modules > ln -s /usr/share/nodejs/debug ./node_modules/ > mkdir -p ./node_modules/\@types > ln -s /usr/share/nodejs/\@types/debug ./node_modules/\@types/ > ln -s /usr/share/nodejs/\@types/mocha ./node_modules/\@types/ > internal/modules/cjs/loader.js:905 > throw err; > ^ > > Error: Cannot find module '@types/node' Hi, this is very strange: @types/node is provided by nodejs itself (since 12.20), so I don't understand this issue (and I'm unable to reproduce this issue of course).
Bug#981279: lintian: False positive: pkg-js-autopkgtest-file-does-not-exist packages/*/test
Le 28/01/2021 à 21:05, Felix Lechner a écrit : > Hi, > > On Thu, Jan 28, 2021 at 11:42 AM Xavier wrote: >> >> I tested your patch, it fixes the problem. > > Merged. The commit still carries your name. Hope that's okay with you. > > Kind regards > Felix Lechner Thanks!
Bug#981309: systemsettings: Shortcuts not storable or remembered in multiple System Settings locations
On Thu, 28 Jan 2021, jaggz wrote: > 1. In Desktop Effects, when assigning a shortcut in an effect's settings, and > clicking OK, immediately popping up its settings again will show the new > shortcut has not been assigned. This is consistently reproducible. Hmm, I am already running 5.20.90, and there there is no way to set a shortcut in a Desktop effect setting - at least not in the ones I have checked. Maybe this is simply not supported? > 2. In Custom Shortcuts, I am able to assign a shortcut (that wasn't accepting > the keystroke a week ago -- possibly a different bug, but maybe related. It That was fixed with kxmlgui 5.78 that entered testing on 24/1. Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
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#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.
I'm unsure what to do here, it seems to me that there is a problem with systemd using DynamicUser and sssd when the service uses dbus. Perhaps this should be re-assigned to systemd. > -Original Message- > From: Thomas Stewart > Sent: Thursday, January 28, 2021 1:36 > To: Limonciello, Mario > Cc: 943...@bugs.debian.org > Subject: RE: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh > fwupd metadata and update motd. > > > [EXTERNAL EMAIL] > > Yes, I'm using sssd against FreeIPA. > > Tom > > > On 28 January 2021 02:12:11 GMT, "Limonciello, Mario" > wrote: > >Are you by chance using NFS mounted directories? Or external entity > >for authentication such as LDAP or SSSD?
Bug#981309: systemsettings: Shortcuts not storable or remembered in multiple System Settings locations
Package: systemsettings Version: 4:5.20.5-2 Severity: important X-Debbugs-Cc: jagg...@gmail.com Dear Maintainer, * What led up to the situation? I was walking down 6th avenue when... Okay, so with a relatively new install and even with a new test user, shortcuts aren't staying set. It presents itself in different ways. For example: 1. In Desktop Effects, when assigning a shortcut in an effect's settings, and clicking OK, immediately popping up its settings again will show the new shortcut has not been assigned. This is consistently reproducible. 2. In Custom Shortcuts, I am able to assign a shortcut (that wasn't accepting the keystroke a week ago -- possibly a different bug, but maybe related. It accepts the keystroke assignment now). However, I just experienced going back to it after a day (possibly a reboot) and one of them being gone. I'd put this bug aside for now since I don't yet know a clear way to reproduce it. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemsettings depends on: ii kio 5.78.0-2 ii kpackagetool5 5.78.0-3 ii libc6 2.31-9 ii libkf5activities5 5.78.0-2 ii libkf5activitiesstats1 5.78.0-2 ii libkf5auth5 5.78.0-2 ii libkf5authcore5 5.78.0-2 ii libkf5completion5 5.78.0-2 ii libkf5configcore5 5.78.0-3 ii libkf5configgui55.78.0-3 ii libkf5configwidgets55.78.0-2 ii libkf5coreaddons5 5.78.0-2 ii libkf5crash55.78.0-3 ii libkf5dbusaddons5 5.78.0-2 ii libkf5declarative5 5.78.0-2 ii libkf5i18n5 5.78.0-2 ii libkf5iconthemes5 5.78.0-2 ii libkf5itemmodels5 5.78.0-2 ii libkf5itemviews55.78.0-2 ii libkf5kcmutils5 5.78.0-3 ii libkf5kiogui5 5.78.0-2 ii libkf5kiowidgets5 5.78.0-2 ii libkf5package5 5.78.0-3 ii libkf5quickaddons5 5.78.0-2 ii libkf5service-bin 5.78.0-2 ii libkf5service5 5.78.0-2 ii libkf5widgetsaddons55.78.0-2 ii libkf5windowsystem5 5.78.0-2 ii libkf5xmlgui5 5.78.0-2 ii libkworkspace5-54:5.20.5-3 ii libqt5core5a5.15.2+dfsg-2 ii libqt5gui5 5.15.2+dfsg-2 ii libqt5qml5 5.15.2+dfsg-2 ii libqt5quick55.15.2+dfsg-2 ii libqt5quickwidgets5 5.15.2+dfsg-2 ii libqt5widgets5 5.15.2+dfsg-2 ii libstdc++6 10.2.1-6 ii qml-module-org-kde-kcm 5.78.0-2 ii qml-module-org-kde-kirigami25.78.0-2 ii qml-module-org-kde-kitemmodels 5.78.0-2 ii qml-module-qtquick-controls 5.15.2-2 ii qml-module-qtquick-layouts 5.15.2+dfsg-2 ii qml-module-qtquick2 5.15.2+dfsg-2 systemsettings recommends no packages. systemsettings suggests no packages. -- no debconf information
Bug#980786: named: after upgrade to bind9=1:9.16.11-1 named is killed with status=11/SEGV
Hello, The patch has been merged. Sincerely yours, *Damir Islamov* email: da...@trefle.ru В письме от вторник, 26 января 2021 г. 16:30:12 +07 пользователь Bernhard Schmidt написал: > Am 26.01.21 um 10:15 schrieb Ondřej Surý: > > Hi, > > > Control: severity -1 important > > > >> resolved and I've marked the bug with RC severity > > > > Bernhard, wait what? This is not a grave bug at all, it doesn’t make > > package unusable to everybody, but just in this specific ACL > > configuration. > Not all, no, but some of them, and it's probably not easy for everyone > affected to find this quickly. > > The RC severity does not have adverse effects (bind9's popcon is way too > high to trigger autoremoval) except for users getting warned by > apt-listbugs and having a bit higher visibility. As soon as the patch is > merged we should upload a -2. > > Bernhard signature.asc Description: This is a digitally signed message part.
Bug#981308: s6: Please provide at least some documentation pointing to the HTML documentation in s6-doc and package relation to s6-doc
Package: s6 Version: 2.10.0.1-1 Severity: normal Hi, the only (!) hint on where to find documentation to s6 in the s6 package is in the lintian override file /usr/share/lintian/overrides/s6: # upstream only has HTML documents(in s6-doc package) for every binary no-manual-page That's definitely not enough. So please add at least either * a dummy man page for every s6 binary in $PATH, pointing to the HTML documentation in s6-doc, or * add a README.Debian file pointing to the HTML documentation in s6-doc. _And_ please add either a "Recommends: s6-doc" (preferred, since it's the only documentation) or "Suggests: s6-doc" to the s6 package. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages s6 depends on: ii libc6 2.31-9 ii libexecline2.7 2.7.0.1-1 ii libs6-2.10 2.10.0.1-1 ii libskarnet2.10 2.10.0.1-1 Versions of packages s6 recommends: ii execline 2.7.0.1-1 s6 suggests no packages. -- no debconf information
Bug#970633: tt-rss: CVE-2020-25787 CVE-2020-25788 CVE-2020-25789
Dear maintainers, It appears that updating the package to latest upstream will fix the security issues. With soft freeze coming up, I was wondering about the status of tt-rss for Bullseye. It is an important part of FreedomBox and many users would be affected by its loss. If time is the issue, I can assist with packaging work and testing. Let me know. Thanks, -- Sunil
Bug#981307: pbuilder: Still refers to Alioth a lot in documentation
Control: retitle -1 pbuilder: Still refers to Alioth and git.debian.org a lot in documentation Hi, one addendum: Axel Beckert wrote: > Even on https://pbuilder-team.pages.debian.net/pbuilder/ there are 12 > occurrences of "alioth". And three occurrences of "git.debian.org" > Please check all occurrences of "alioth" and "Alioth" … and "git.debian.org" … > in the code and especially the documentation, and replace it with > according references to Salsa or > https://pbuilder-team.pages.debian.net/. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#981307: pbuilder: Still refers to Alioth a lot in documentation
Package: pbuilder Version: 0.231 Severity: normal Hi, while reading the pdebuild(1) man page, I was surprised to see this text near the end of the man page: The homepage is http://pbuilder.alioth.debian.org Even on https://pbuilder-team.pages.debian.net/pbuilder/ there are 12 occurrences of "alioth". And every mentioning except the mailing list's e-mail address are surely no more valid. Please check all occurrences of "alioth" and "Alioth" in the code and especially the documentation, and replace it with according references to Salsa or https://pbuilder-team.pages.debian.net/. Thanks! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages pbuilder depends on: ii cdebconf [debconf-2.0] 0.256 ii cdebootstrap0.7.7+b13 ii debconf [debconf-2.0] 1.5.74 ii debootstrap 1.0.123 ii dpkg-dev1.20.7.1 Versions of packages pbuilder recommends: ii devscripts 2.20.5 ii eatmydata 105-9 ii fakeroot 1.25.3-1.1 ii iproute2 5.10.0-3 ii net-tools 1.60+git20181103.0eebece-1 ii pseudo [fakeroot] 1.9.0+git20200626+067950b-2 pn sudo Versions of packages pbuilder suggests: ii cowdancer 0.89 ii gdebi-core 0.9.5.7+nmu4 -- debconf information: * pbuilder/rewrite: false pbuilder/nomirror: pbuilder/mirrorsite: http://ftp.ch.debian.org/debian/
Bug#981306: neomutt: Please consider updating to commit 396a61b of 28 Jan 2021 which fixes a bug in MIME forwarding
Package: neomutt
Version: 20201120+dfsg.1-1
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear Maintainer,
Please refer to neomutt issue:
https://github.com/neomutt/neomutt/issues/2788
Which details a bug that breaks the forwarding of messages that contain a
multipart/alternative MIME block. This has now been fixed upstream by
commit 396a61b:
https://github.com/neomutt/neomutt/commit/396a61b106ea16a8ea528a86fff5e0ab141df2fc
I hope this fix can be included before the Bullseye freeze.
Thanks!
- - Nate
- -- Package-specific info:
NeoMutt 20201120
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 5.10.0-2-amd64 (x86_64)
ncurses: ncurses 6.2.20201114 (compiled with 6.2.20201114)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.6.15
libnotmuch: 5.3.0
storage: tokyocabinet
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
{--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-Ulxxh7/neomutt-20201120+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens
+getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify
-locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl
+smime +sqlite +start_color +sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
- -- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (700, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_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 neomutt depends on:
ii libc6 2.31-9
ii libgnutls30 3.7.0-5
ii libgpg-error0 1.38-2
ii libgpgme111.14.0-1+b2
ii libgssapi-krb5-2 1.18.3-4
ii libidn11 1.33-3
ii liblua5.4-0 5.4.2-2
ii libncursesw6 6.2+20201114-2
ii libnotmuch5 0.31.3-2
ii libsasl2-22.1.27+dfsg-2
ii libsqlite3-0 3.34.1-1
ii libtinfo6 6.2+20201114-2
ii libtokyocabinet9 1.4.48-13
ii sensible-utils0.0.14
Versions of packages neomutt recommends:
ii libsasl2-modules 2.1.27+dfsg-2
ii locales 2.31-9
ii mime-support 3.66
Versions of packages neomutt suggests:
ii aspell 0.60.8-2
ii ca-certificates20210119
ii exim4-daemon-light [mail-transport-agent] 4.94-12
ii gnupg 2.2.20-1
ii ispell 3.4.02-2
pn mixmaster
ii openssl1.1.1i-2
ii urlview0.9-21+b1
Versions of packages neomutt is related to:
ii neomutt 20201120+dfsg.1-1
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQHBBAEBCgArFiEEG5vcSeqIHtMzWHg79yYl4u2+1ZgFAmATUl8NHG4wbmJAbjBu
Yi51cwAKCRD3JiXi7b7VmGZfDACbVoq7dgKJndqHbW9s7wQU9OtiBaZDOWCRoR2G
OqQyCByMSiG8sU4+v2QrFw3dxqNt27lVfVqPecwQOedV9eViENRbzoYyZu8ky7wD
A3Qx0LL03izCsF9kU70jRKKBLYEveBndyHbCGZjeVeD3QvBhvNqiHJoDezkkI1/O
0gBNJKHhh0HwF8dGPY0GKBCWh49GXcoggGZpWC8/K//AGB6LFZ66WfvMHO1Gmjw8
+tx7DALsgDdY32n38u2Ycc/nXlqUQfvayvyhHbUFfC4HzNtu3NqO7VKdW
Bug#981305: RFS: blop-lv2/1.0.2-1 - Mike Rawes' LADSPA plugins ported to LV2
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "blop-lv2": * Package name: blop-lv2 Version : 1.0.2-1 Upstream Author : David Robillard * URL : https://drobilla.net/software/blop-lv2/ * License : GPL-3+, BSD-3-clause * Vcs : https://salsa.debian.org/multimedia-team/blop-lv2 Section : sound It builds those binary packages: blop-lv2 - Mike Rawes' LADSPA plugins ported to LV2 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/blop-lv2/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/blop-lv2/blop-lv2_1.0.2-1.dsc Changes for the initial release: blop-lv2 (1.0.2-1) unstable; urgency=medium . * Initial release (Closes: #981304) Regards, Dennis OpenPGP_signature Description: OpenPGP digital signature
Bug#981252: polymake: tests fail on mips{64,}el
Benjamin Lorenz writes: > Hello David, > > On 28/01/2021 12.59, David Bremner wrote: > > please try the attached patch, the issue is that this testcase should > not be run when flint is disabled. > > I will do some tests with the new flint 2.7 soon to check whether the > mips(64) situation has improved. Hi Benjamin; The patch worked, thanks very much. I guess I'll upload the patched version, unless you are planning a point release in the next few days. David
Bug#981299: RFS: lebiniou/3.53.2-2 -- user-friendly, powerful music visualization / VJing tool
On Thu, Jan 28, 2021 at 10:43:36PM +0100, Olivier Girondel wrote: > * Package name: lebiniou >Version : 3.53.2-2 > Changes since the last upload: > > * debian/tests/control: Fix typo. Alas, it still fails: autopkgtest [00:57:46]: test command1: /usr/share/lebiniou/test/lebiniou-test.sh autopkgtest [00:57:46]: test command1: [--- [i] Setting up environment... [i] Random seed: 1611878266 [i] FFmpeg: ffmpeg version 4.3.1-8 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 10 (Debian 10.2.1-6) configuration: --prefix=/usr --extra-version=8 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-pocketsphinx --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat58. 45.100 / 58. 45.100 libavdevice58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc55. 7.100 / 55. 7.100 [i] Encoding video #1... /usr/share/lebiniou/test/lebiniou-test.sh: line 26: lebiniou: command not found done. [i] Encoding video #2... /usr/share/lebiniou/test/lebiniou-test.sh: line 31: lebiniou: command not found done. [i] Generated videos and logs: ls: cannot access '/tmp/autopkgtest.2nc4Id/autopkgtest_tmp/*.mp4': No such file or directory -rw-rw-r-- 1 kilobyte kilobyte 0 Jan 28 23:57 /tmp/autopkgtest.2nc4Id/autopkgtest_tmp/video1.log -rw-rw-r-- 1 kilobyte kilobyte 0 Jan 28 23:57 /tmp/autopkgtest.2nc4Id/autopkgtest_tmp/video2.log [i] Comparing logs: * video1.log: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /tmp/autopkgtest.2nc4Id/autopkgtest_tmp/video1.log * video2.log: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /tmp/autopkgtest.2nc4Id/autopkgtest_tmp/video2.log [+] Success. [i] Extracting per-packet SHA256 hashes: * video1.mp4... done. * video2.mp4... done. [i] Generated hashes: -rw-rw-r-- 1 kilobyte kilobyte 0 Jan 28 23:57 /tmp/autopkgtest.2nc4Id/autopkgtest_tmp/out1.sha256 -rw-rw-r-- 1 kilobyte kilobyte 0 Jan 28 23:57 /tmp/autopkgtest.2nc4Id/autopkgtest_tmp/out2.sha256 [i] Comparing per-packet hashes: [+] Success. autopkgtest [00:57:47]: test command1: ---] autopkgtest [00:57:47]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL stderr: /usr/share/lebiniou/test/lebiniou-test.sh: line 26: lebiniou: command not found autopkgtest [00:57:47]: test command1: - - - - - - - - - - stderr - - - - - - - - - - /usr/share/lebiniou/test/lebiniou-test.sh: line 26: lebiniou: command not found /usr/share/lebiniou/test/lebiniou-test.sh: line 31: lebiniou: command not found ls: cannot access '/tmp/autopkgtest.2nc4Id/autopkgtest_tmp/*.mp4': No such file or directory autopkgtest [00:57:47]: summary You need the test to depend on "lebiniou" explicitly. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#980284: Additional information
Hello, this behaviour also appears on Arch Linux: With Kernel Packages 5.9.x there was no problem, since 5.10.x I have the same problem with ITE8708 CIR transceiver on NUC7PJYH and ITE8713 CIR transceiver on NUC5CPYB. I'm using a rc-6 remote. NUC7PJYH, with broken 5.10.11: ir-keytable Found /sys/class/rc/rc0/ with: Name: ITE8708 CIR transceiver Driver: ite-cir Default keymap: rc-rc6-mce Input device: /dev/input/event5 LIRC device: /dev/lirc0 Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm Enabled kernel protocols: lirc nec rc-6 bus: 25, vendor/product: 1283:, version: 0x Repeat delay = 500 ms, repeat period = 125 ms ir-ctl -f Receive features /dev/lirc0: - Device can receive raw IR - Can report decoded scancodes and protocol - Resolution 8 microseconds - Set receive carrier - Receiving timeout 1180480 microseconds - Can set receiving timeout min 1180480 microseconds, max 125 microseconds Send features /dev/lirc0: - Device can send raw IR - IR scancode encoder - Set carrier - Set duty cycle NUC5CPYB, with broken 5.10.11 ir-keytable Found /sys/class/rc/rc0/ with: Name: ITE8713 CIR transceiver Driver: ite-cir Default keymap: rc-rc6-mce Input device: /dev/input/event4 LIRC device: /dev/lirc0 Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm Enabled kernel protocols: lirc nec rc-6 bus: 25, vendor/product: 1283:, version: 0x Repeat delay = 500 ms, repeat period = 125 ms ir-ctl -f Receive features /dev/lirc0: - Device can receive raw IR - Can report decoded scancodes and protocol - Resolution 8 microseconds - Set receive carrier - Receiving timeout 1180480 microseconds - Can set receiving timeout min 1180480 microseconds, max 125 microseconds Send features /dev/lirc0: - Device can send raw IR - IR scancode encoder - Set carrier - Set duty cycle With Kernel 5.9.14 the timing is different and everything works fine (here for NUC5CPYB): ir-ctl -f Receive features /dev/lirc0: - Device can receive raw IR - Can report decoded scancodes and protocol - Resolution 8 microseconds - Set receive carrier - Receiving timeout 15625 microseconds - Can set receiving timeout min 1181 microseconds, max 125 microseconds Send features /dev/lirc0: - Device can send raw IR - IR scancode encoder - Set carrier - Set duty cycle
Bug#975160: librecad: diff for NMU version 2.1.3-1.3
Dear maintainer, I've prepared an NMU for librecad (versioned as 2.1.3-1.3) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru librecad-2.1.3/debian/changelog librecad-2.1.3/debian/changelog --- librecad-2.1.3/debian/changelog 2019-05-16 14:11:05.0 +0300 +++ librecad-2.1.3/debian/changelog 2021-01-29 01:22:36.0 +0200 @@ -1,3 +1,10 @@ +librecad (2.1.3-1.3) unstable; urgency=medium + + * Non-maintainer upload. + * Backport upstream fix for FTBFS with Qt 5.15. (Closes: #975160) + + -- Adrian Bunk Fri, 29 Jan 2021 01:22:36 +0200 + librecad (2.1.3-1.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru librecad-2.1.3/debian/patches/0001-Fix-build-with-Qt-5.15-missing-QPainterPath-include.patch librecad-2.1.3/debian/patches/0001-Fix-build-with-Qt-5.15-missing-QPainterPath-include.patch --- librecad-2.1.3/debian/patches/0001-Fix-build-with-Qt-5.15-missing-QPainterPath-include.patch 1970-01-01 02:00:00.0 +0200 +++ librecad-2.1.3/debian/patches/0001-Fix-build-with-Qt-5.15-missing-QPainterPath-include.patch 2021-01-29 01:22:36.0 +0200 @@ -0,0 +1,37 @@ +From 81741a875847c806c05f0f3a4610e69b3c3002aa Mon Sep 17 00:00:00 2001 +From: Andreas Sturmlechner +Date: Wed, 20 May 2020 14:12:15 +0200 +Subject: Fix build with Qt 5.15 (missing QPainterPath include) + +--- + librecad/src/lib/engine/lc_splinepoints.cpp | 1 + + librecad/src/lib/gui/rs_painterqt.h | 1 + + 2 files changed, 2 insertions(+) + +diff --git a/librecad/src/lib/engine/lc_splinepoints.cpp b/librecad/src/lib/engine/lc_splinepoints.cpp +index 5eaed81b..e6324ec1 100644 +--- a/librecad/src/lib/engine/lc_splinepoints.cpp b/librecad/src/lib/engine/lc_splinepoints.cpp +@@ -21,6 +21,7 @@ along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + **/ + ++#include + #include + #include "lc_splinepoints.h" + +diff --git a/librecad/src/lib/gui/rs_painterqt.h b/librecad/src/lib/gui/rs_painterqt.h +index 878753cb..a0b432e0 100644 +--- a/librecad/src/lib/gui/rs_painterqt.h b/librecad/src/lib/gui/rs_painterqt.h +@@ -29,6 +29,7 @@ + #define RS_PAINTERQT_H + + #include ++#include + + #include "rs_painter.h" + #include "rs_pen.h" +-- +2.20.1 + diff -Nru librecad-2.1.3/debian/patches/series librecad-2.1.3/debian/patches/series --- librecad-2.1.3/debian/patches/series 2019-05-16 14:11:05.0 +0300 +++ librecad-2.1.3/debian/patches/series 2021-01-29 01:22:36.0 +0200 @@ -2,3 +2,4 @@ librecad-desktop.pach 0001-fix-build-with-Qt-5.11.patch CVE-2018-19105.patch +0001-Fix-build-with-Qt-5.15-missing-QPainterPath-include.patch
Bug#979521: openboard-common depends on libjs-jquery-i18n-properties that was removed from unstable
Hi, Am Donnerstag, 28. Januar 2021 schrieb Rogério Brito: > Package: openboard > Version: 1.5.4+dfsg1-1 > Followup-For: Bug #979521 > > Hi. > > Having libjs-jquery-i18n-properties reintroduced would be really nice, since > it is an alternative to xournal. > > More software for teaching, especially in these pandemic times is *very* > important. > > > Thanks, > > Rogério Brito. jquery-i18n-properties is waiting in NEW for acceptance... Mike -- Sent from my Fairphone powered by SailfishOS
Bug#981304: ITP : blop-lv2 - Mike Rawes' LADSPA plugins ported to LV2
Package: wnpp Severity: wishlist Owner: d_br...@kabelmail.de * Package name : blop-lv2 Version : 1.0.2 Upstream Author : David Robillard * URL : https://gitlab.com/drobilla/blop-lv2/ * License : GPL-3+, BSD-3-clause Programming Lang: C, Python, C++ Description : Mike Rawes' LADSPA plugins ported to LV2 Hey guys, i'll upload this package to mentors soon. :-) Best, Dennis OpenPGP_signature Description: OpenPGP digital signature
Bug#981303: elpa-elpher: does not handle clone-buffer properly
Package: elpa-elpher Version: 2.10.2-2 Dear maintainer, In Emacs' non-file-visiting text-browsing modes like Info-mode and EWW buffers, it is common to use M-x clone-buffer RET if you want to do something like follow a link while keeping the text containing the link available in a buffer. With Elpher in particular, you might want to leave a page open in another frame to come back to while looking at something else. It should be possible to do this like so: M-x elpher RET g gopher://foo M-x clone-buffer RET [note that this leaves *elpher*<2> selected] g gopher://bar Expected result, based on how those other modes work: *elpher* buffer continues to display gopher://foo, *elpher*<2> buffer loads gopher://bar, no window changes. Actual result: current window switches to view *elpher*, *elpher* buffer loads gopher://bar, *elpher*<2> continues to display gopher://foo. The problem is that Elpher always uses *elpher* instead of the buffer which was active when the key 'g' was pressed. If you have more than one *elpher* buffer the behaviour will be even less useful. -- Sean Whitton signature.asc Description: PGP signature
Bug#981302: mandos-client: fails to fexecve plugins due to missing /dev/fd symlink
Package: mandos-client Version: 1.8.13-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: +debian-bts-2...@eero.xn--hkkinen-5wa.fi During initial ramdisk, the Mandos plugin runner tries to execute plugins including the mandos-client plugin using fexecve but that fails with ENOENT due to a missing /dev/fd -> /proc/self/fd symlink. Therefore, the package fails to provide a password for an encrypted root file system and thus renders package unusable. The problem can be fixed by creating the missing symlink before the plugin runner is run. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-2-amd64 (SMP w/1 CPU thread) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi-FI:fi:en-GB:en-US:de-DE:de-CH:sv-FI:sv-SE:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages mandos-client depends on: ii adduser3.118 ii cryptsetup 2:2.3.4-2 ii cryptsetup-initramfs 2:2.3.4-2 ii debconf [debconf-2.0] 1.5.74 ii dpkg-dev 1.20.7.1 ii gnutls-bin 3.7.0-5 ii initramfs-tools0.139 ii libavahi-common3 0.8-3 ii libavahi-core7 0.8-3 ii libc6 2.31-9 ii libglib2.0-0 2.66.4-1 ii libgnutls303.7.0-5 ii libgpgme11 1.14.0-1+b2 ii libnl-3-2003.4.0-1+b1 ii libnl-route-3-200 3.4.0-1+b1 Versions of packages mandos-client recommends: ii ssh 1:8.4p1-3 mandos-client suggests no packages. -- Configuration Files: /etc/mandos/plugin-runner.conf changed: --options-for=mandos-client:--connect=aa.bb.cc.dd:nnn (obscured) -- debconf information: mandos-client/key_id:
Bug#641542: 2nd Contact
We have been trying to reach you as regards the estate of Late George Brumley, you were made one of the beneficiaries of his estate. Do get back to me at your earliest convenience. The Trustees
Bug#981176: RFP: doas -- minimal replacement for sudo
Hello, I think the package is mostly ready for review! "Mostly" because I have no idea how to fix the "maintainer-script-lacks-debhelper-token" warning. Links: https://salsa.debian.org/debian/doas https://mentors.debian.net/package/doas -- Scupake :D 4737A2C0A769B53AE82F77922BD8BE5CDD5ADA16 signature.asc Description: PGP signature
Bug#981297: ITP: smbus2 -- another pure Python implementation of the python-smbus package
Yes, that's it. "Yet" another. Anton Am Do., 28. Jan. 2021 um 23:06 Uhr schrieb Philipp Kern : > On 28.01.21 21:44, Anton Gladky wrote: > > * Package name: smbus2 > > Version : 0.4.1 > > Upstream Author : Karl-Petter Lindegaard > > * URL : https://github.com/kplindegaard/smbus2 > > * License : MIT > > Programming Lang: Python > > Description : another pure Python implementation of the > > python-smbus package > > Do you mean "another implementation of python-smbus, written in pure > Python"? Like this it sounds like yet another one was needed, with no > real justification in the description. > > Kind regards > Philipp Kern >
Bug#981301: elvish: please document where you want tab completion directives installed
Package: src:elvish
Version: 0.15.0~rc3-1
Control: affects -1 src:rust-sequoia-sq src:rust-sequoia-sqv
I'm packaging a few rust binaries built using the "clap" crate, which
auto-generates completion files for bash, fish, zsh, elvish, and
powershell.
I know how to ship the bash, fish, and zsh tab completion directives.
But i don't know how to ship the elvish tab completion directives, or
how to test that they work as expected. i'm including an example sq.elv
that is produced by the rust-sequoia-sq package when it's built, for
reference.
It would be great if we could document in the elvish source package
debian/ directory at least (or even better, in the binary package, in
/usr/share/doc/elvish).
If it's already documented someplace and i'm just unaware, feel free to
close this report with a pointer to the right location!
Thanks for maintaining elvish in debian!
--dkg
edit:completion:arg-completer[sq] = [@words]{
fn spaces [n]{
repeat $n ' ' | joins ''
}
fn cand [text desc]{
edit:complex-candidate $text &display-suffix=' '(spaces (- 14 (wcswidth
$text)))$desc
}
command = 'sq'
for word $words[1:-1] {
if (has-prefix $word '-') {
break
}
command = $command';'$word
}
completions = [
&'sq'= {
cand --known-notation 'Adds NOTATION to the list of known notations'
cand -f 'Overwrites existing files'
cand --force 'Overwrites existing files'
cand -h 'Prints help information'
cand --help 'Prints help information'
cand -V 'Prints version information'
cand --version 'Prints version information'
cand decrypt 'Decrypts a message'
cand encrypt 'Encrypts a message'
cand sign 'Signs messages or data files'
cand verify 'Verifies signed messages or detached signatures'
cand armor 'Converts binary to ASCII'
cand dearmor 'Converts ASCII to binary'
cand inspect 'Inspects data, like file(1)'
cand key 'Manages keys'
cand keyring 'Manages collections of keys or certs'
cand certify 'Certifies a User ID for a Certificate'
cand packet 'Low-level packet manipulation'
cand help 'Prints this message or the help of the given
subcommand(s)'
}
&'sq;decrypt'= {
cand -o 'Writes to FILE or stdout if omitted'
cand --output 'Writes to FILE or stdout if omitted'
cand -n 'Sets the threshold of valid signatures to N'
cand --signatures 'Sets the threshold of valid signatures to N'
cand --signer-cert 'Verifies signatures with CERT'
cand --recipient-key 'Decrypts with KEY'
cand --dump-session-key 'Prints the session key to stderr'
cand --dump 'Prints a packet dump to stderr'
cand -x 'Prints a hexdump (implies --dump)'
cand --hex 'Prints a hexdump (implies --dump)'
cand -h 'Prints help information'
cand --help 'Prints help information'
cand -V 'Prints version information'
cand --version 'Prints version information'
}
&'sq;encrypt'= {
cand -o 'Writes to FILE or stdout if omitted'
cand --output 'Writes to FILE or stdout if omitted'
cand --recipient-cert 'Encrypts for all recipients in CERT-RING'
cand --signer-key 'Signs the message with KEY'
cand --mode 'Selects what kind of keys are considered for
encryption.'
cand --compression 'Selects compression scheme to use'
cand -t 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand --time 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand -B 'Emits binary data'
cand --binary 'Emits binary data'
cand -s 'Adds a password to encrypt with'
cand --symmetric 'Adds a password to encrypt with'
cand --use-expired-subkey 'Falls back to expired encryption subkeys'
cand -h 'Prints help information'
cand --help 'Prints help information'
cand -V 'Prints version information'
cand --version 'Prints version information'
}
&'sq;sign'= {
cand -o 'Writes to FILE or stdout if omitted'
cand --output 'Writes to FILE or stdout if omitted'
cand --merge 'Merges signatures from the input and SIGNED-MESSAGE'
cand --signer-key 'Signs using KEY'
cand -t 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand --time 'Chooses keys valid at the specified time and sets the
signature''s creation time'
cand --notation 'Adds a notation to the certification.'
cand -B 'Emits binary data'
cand --b
Bug#981297: ITP: smbus2 -- another pure Python implementation of the python-smbus package
On 28.01.21 21:44, Anton Gladky wrote: > * Package name : smbus2 > Version : 0.4.1 > Upstream Author : Karl-Petter Lindegaard > * URL : https://github.com/kplindegaard/smbus2 > * License : MIT > Programming Lang: Python > Description : another pure Python implementation of the > python-smbus package Do you mean "another implementation of python-smbus, written in pure Python"? Like this it sounds like yet another one was needed, with no real justification in the description. Kind regards Philipp Kern
Bug#981073: dolphin: Dolphin uses 100% CPU
I have multiple 8TB disks with a lot of files. I did some more testing and interestingly I can no longer reproduce the problem no matter how hard I try. I did do multiple tests before filing the bug to confirm it was consistently reproducible. So I'm not sure if an update or something else has changed. I have no objections to closing the bug as it is no longer an issue for me.
Bug#981300: arduino-core-avr breaks arduino-mk
Package: arduino Version: 1.8.13+dfsg1-1 The recent rename of arduino-core to arduino-core-avr breaks the Depends in arduino-mk: Depends: arduino-core (>= 1:1.0+dfsg-8), So doing a dist-upgrade and pulling in the new arduino, arduino-core-avr etc; removes arduino-core and arduino-mk Also why are you just now packaging arduino-builder when arduino-cli has already replaced it? Regards. -- Simon John
Bug#976960: systemd: Please package systemd-userdb and systemd-homed
Followup-For: Bug #976960 Package: systemd Version: 247.2-5 I think that systemd-homed should be packaged from Debian just for the simple reason of giving users choice. > I still fail to see the use-case for homed, tbh and the current > implementation still requires quite a few hacks (see the fosdem 2020 > talk of Lennart and the problems e.g. with SSH keys). For example I have a persistent live system installed on a USB stick that I share with some friends. Full disk encryption would be hard to implement and not that useful, and it would be better to encrypt on a per-user basis. SSH is not an issue in this case, since a USB stick does not need to be accessed remotely. I know that this is not the most common use case, but giving the user choice and not imposing anything controversial by default is a better approach, in my opinion.
Bug#981299: RFS: lebiniou/3.53.2-2 -- user-friendly, powerful music visualization / VJing tool
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lebiniou": * Package name: lebiniou Version : 3.53.2-2 Upstream Author : Olivier Girondel * URL : https://biniou.net * License : GPL-2+ Section : graphics It builds this binary package: lebiniou - user-friendly, powerful music visualization / VJing tool The package appears to be lintian-clean. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lebiniou Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.53.2-2.dsc Changes since the last upload: * debian/tests/control: Fix typo. Regards, -- Olivier Girondel
Bug#981232: unblock: perl/5.32.1-1
On Thu, Jan 28, 2021 at 10:21:21PM +0100, Paul Gevers wrote: > Hi Dominic, > > On 28-01-2021 22:05, Dominic Hargreaves wrote: > >>> 5.32.1 would need a binnmu of a few leaf packages > >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl > >>> libcommon-sense-perl) as usual. > >> > >> Just to be clear, these binNMU's would be needed too if we would go for > >> the cherry-pick option? > > > > No, the binaries relate to a change of upstream version number > > which ends up being encoded in these packages. If we cherry pick > > fixes, the binNMUs wouldn't be needed. > > But then, that relation is strictly speaking too tight? Is that > something that can be improved (without jumping through hoops)? Maybe > not for this time, but for future changes. Normally perl packages look > for the perl-something-api right? Which would make it clear that this is > no transition. The packages in the mini-transition have a full version dependency built into them - it's not API/ABI related. It's been a while but we've looked at improving this before and it's not really practical given the assumptions built into the upstream code. It's also generally not been an issue to do the binNMUs. > Would you have also asked us if you wouldn't have needed the binNMU's? Yes, since https://release.debian.org/bullseye/freeze_policy.html says changes to build-essential may only be made with pre-approval...
Bug#878875: [Pkg-javascript-devel] Bug#878875: Packaging twemoji
Quoting Felix Natter (2021-01-28 21:39:27) > Jonas Smedegaard writes: > > Quoting Felix Natter (2021-01-24 16:12:39) > >> Unfortunately, I cannot package all of twemoji, because it has a > >> generated file without source: > >> https://github.com/twitter/twemoji-parser/blob/master/src/lib/regex.js > >> > >> I contacted a twitter developer (2020) [1] and she said that it > >> could take a while until they publish the relevant library. > >> > >> [1] Justine De Caires jdecai...@twitter.com > > > > please consider raising the question at their issue tracker > > https://github.com/twitter/twemoji-parser/issues - and then share a > > reference to that public conversation here. > > Here is the ticket: > https://github.com/twitter/twemoji-parser/issues/14 Thanks! -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#976788: Patch to fix: nouveau DRM timeout causes machine to freeze
Hi,
A patch [1] has been proposed by Bastian Beranek [2] to fix the issue.
The issue has been found to affect NV50/Tesla GPUs on kernels 5.9+ and
renders the system unusable.
I've personally tested the patch (and its earlier variant) on the 5.10
kernel for the past couple of weeks without issue and it has passed an
initial review [3] by the nouveau maintainers.
The upstream patch appears to be some way off making it into mainline
before it can be backported to 5.10, so given the scope and effects of
the bug, I'm submitting it here to be considered to patch the bullseye
kernel in the interim.
I include the contents of the patch at the end of this mail for your
convenience.
Cheers,
Phil
[1]
https://gitlab.freedesktop.org/drm/nouveau/uploads/8844d508dbe905daf9802007dc1c7e03/0001-drm-gpu-nouveau-dispnv50-Restore-pushing-of-all-data.patch
[2] https://gitlab.freedesktop.org/drm/nouveau/-/issues/14#note_773217
[3]
https://lists.freedesktop.org/archives/nouveau/2021-January/037782.html
--
From 7fcdc2555c9055049c0bc67866012e9dc9b49d89 Mon Sep 17 00:00:00 2001
From: Bastian Beranek
Date: Mon, 18 Jan 2021 13:19:32 +0100
Subject: [PATCH v3] drm/gpu/nouveau/dispnv50: Restore pushing of all
data.
Commit f844eb485eb056ad3b67e49f95cbc6c685a73db4 introduced a regression
for
NV50, which lead to visual artifacts, tearing and eventual crashes.
In the changes of f844eb485eb056ad3b67e49f95cbc6c685a73db4 only the
first line
was correctly translated to the new NVIDIA header macros:
- PUSH_NVSQ(push, NV827C, 0x0110, 0,
- 0x0114, 0);
+ PUSH_MTHD(push, NV827C, SET_PROCESSING,
+ NVDEF(NV827C, SET_PROCESSING, USE_GAIN_OFS, DISABLE));
The lower part ("0x0114, 0") was probably omitted by accident.
This patch restores the push of the missing data and fixes the
regression.
Signed-off-by: Bastian Beranek
Fixes: f844eb485eb056ad3b67e49f95cbc6c685a73db4
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/14
---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 6 +-
drivers/gpu/drm/nouveau/dispnv50/base827c.c | 6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/base507c.c
b/drivers/gpu/drm/nouveau/dispnv50/base507c.c
index 302d4e6fc52f..788db043a342 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/base507c.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base507c.c
@@ -88,7 +88,11 @@ base507c_image_set(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw)
NVVAL(NV507C, SET_CONVERSION, OFS, 0x64));
} else {
PUSH_MTHD(push, NV507C, SET_PROCESSING,
- NVDEF(NV507C, SET_PROCESSING, USE_GAIN_OFS, DISABLE));
+ NVDEF(NV507C, SET_PROCESSING, USE_GAIN_OFS, DISABLE),
+
+ SET_CONVERSION,
+ NVVAL(NV507C, SET_CONVERSION, GAIN, 0) |
+ NVVAL(NV507C, SET_CONVERSION, OFS, 0));
}
PUSH_MTHD(push, NV507C, SURFACE_SET_OFFSET(0, 0),
asyw->image.offset[0] >> 8);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/base827c.c
b/drivers/gpu/drm/nouveau/dispnv50/base827c.c
index 18d34096f125..093d4ba6910e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/base827c.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base827c.c
@@ -49,7 +49,11 @@ base827c_image_set(struct nv50_wndw *wndw, struct
nv50_wndw_atom *asyw)
NVVAL(NV827C, SET_CONVERSION, OFS, 0x64));
} else {
PUSH_MTHD(push, NV827C, SET_PROCESSING,
- NVDEF(NV827C, SET_PROCESSING, USE_GAIN_OFS, DISABLE));
+ NVDEF(NV827C, SET_PROCESSING, USE_GAIN_OFS, DISABLE),
+
+ SET_CONVERSION,
+ NVVAL(NV827C, SET_CONVERSION, GAIN, 0) |
+ NVVAL(NV827C, SET_CONVERSION, OFS, 0));
}
PUSH_MTHD(push, NV827C, SURFACE_SET_OFFSET(0, 0),
asyw->image.offset[0] >> 8,
--
2.30.0
Bug#981232: unblock: perl/5.32.1-1
Hi Dominic, On 28-01-2021 22:05, Dominic Hargreaves wrote: >>> 5.32.1 would need a binnmu of a few leaf packages >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl >>> libcommon-sense-perl) as usual. >> >> Just to be clear, these binNMU's would be needed too if we would go for >> the cherry-pick option? > > No, the binaries relate to a change of upstream version number > which ends up being encoded in these packages. If we cherry pick > fixes, the binNMUs wouldn't be needed. But then, that relation is strictly speaking too tight? Is that something that can be improved (without jumping through hoops)? Maybe not for this time, but for future changes. Normally perl packages look for the perl-something-api right? Which would make it clear that this is no transition. Would you have also asked us if you wouldn't have needed the binNMU's? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#980571: please forward to upstream
[Alexandre Viau] > Would you please forward this patch to upstream? The patch originates from upstream. It has been floating on the IRC channel for a while already. -- Happy hacking Petter Reinholdtsen
Bug#981232: unblock: perl/5.32.1-1
On Thu, Jan 28, 2021 at 09:21:54PM +0100, Paul Gevers wrote: > (Your bug title is wrong, as you can't use that version anymore as it's > already in experimental ;) ) > > On 28-01-2021 00:39, Dominic Hargreaves wrote: > > My preference is to upload 5.32.1 in whole as it's probably overall > > less risky, and less maintenance work, but there is the option of > > cherry-picking the targetted fixes too. > > > > 5.32.1 would need a binnmu of a few leaf packages > > (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl > > libcommon-sense-perl) as usual. > > Just to be clear, these binNMU's would be needed too if we would go for > the cherry-pick option? No, the binaries relate to a change of upstream version number which ends up being encoded in these packages. If we cherry pick fixes, the binNMUs wouldn't be needed. Dominic
Bug#977101: knot: duplicate zones, segfault when generating new DNSSEC keys
On Thu, 21 Jan 2021 13:28:58 +0800 Gedalya wrote: > Hi Jan, > > For some reason I didn't get your message via email, but saw it when looking > at the Debian bug. A message sent to n...@bugs.debian.org is forwarded to the maintainer, but not to the submitter. For a message to be forwarded to the submitter, the author needs to use the address nnn-submit...@bugs.debian.org, or CC the submitter. See "Followup messages" in https://www.debian.org/Bugs/Developer > > I see a fix for this in 3.0.4 (89c9a233). When that's packaged I'll try to > confirm that this is fixed. > > Thank you! 3.0.4 is now in NEW. I've also uploaded a release to https://people.debian.org/~santiago/debian/santiago-unstable/ Could you try it please? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#979977: [Pkg-raspi-maintainers] Bug#979977: raspi-firmware: Seems to ignore latest installed kernel (5.10.0-1-armmp-lpae) while the booting kernel is older (5.10.0-trunk-armmp-lpae)
On donderdag 28 januari 2021 18:04:29 CET Gunnar Wolf wrote:
> latest_initrd=$(ls -1 /boot/initrd.img-* | grep -v '\.dpkg-bak$' | sort
> -V -r | head -1) if [ -z "$latest_initrd" ]; then
> echo "raspi-firmware: no initrd found in /boot/initrd.img-*, cannot
> populate /boot/firmware" exit 0
> fi
>
> So... Yes, it behaves as you report. Modifying the logic to search in
> /tmp/boot:
>
> $ touch /tmp/boot/vmlinuz-{5.10.0-trunk-armmp-lpae,5.10.0-1-armmp-lpae}
> $ latest_kernel=$(ls -1 /tmp/boot/vmlinuz-* | grep -v '\.dpkg-bak$' |
> sort -V -r | head -1) $ echo $latest_kernel
> /tmp/boot/vmlinuz-5.10.0-trunk-armmp-lpae
>
> Now... What to do here?
ls -1t ? (And get rid of the "sort -V -r")
signature.asc
Description: This is a digitally signed message part.
Bug#979714: mpdecimal: upgrade to libmpdec3
The official release is out now: https://www.bytereef.org/software/mpdecimal/releases/mpdecimal-2.5.1.tar.gz 9f9cd4c041f99b5c49ffb7b59d9f12d95b683d88585608aa56a6307667b2b21f Differences between rc1 and the release: - one build fix - two doc fixes Stefan Krah
Bug#981298: ITP: smbus2 -- another pure Python implementation of the python-smbus package
Package: wnpp Severity: wishlist Owner: Anton Gladky X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: smbus2 Version : 0.4.1 Upstream Author : Karl-Petter Lindegaard * URL : https://github.com/kplindegaard/smbus2 * License : MIT Programming Lang: Python Description : another pure Python implementation of the python-smbus package another pure Python implementation of the python-smbus package Currently supported features are: Get i2c capabilities (I2C_FUNCS) SMBus Packet Error Checking (PEC) support read_byte write_byte read_byte_data write_byte_data read_word_data write_word_data read_i2c_block_data write_i2c_block_data write_quick process_call read_block_data write_block_data block_process_call i2c_rdwr - combined write/read transactions with repeated start
Bug#981297: ITP: smbus2 -- another pure Python implementation of the python-smbus package
Package: wnpp Severity: wishlist Owner: Anton Gladky X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: smbus2 Version : 0.4.1 Upstream Author : Karl-Petter Lindegaard * URL : https://github.com/kplindegaard/smbus2 * License : MIT Programming Lang: Python Description : another pure Python implementation of the python-smbus package another pure Python implementation of the python-smbus package Currently supported features are: Get i2c capabilities (I2C_FUNCS) SMBus Packet Error Checking (PEC) support read_byte write_byte read_byte_data write_byte_data read_word_data write_word_data read_i2c_block_data write_i2c_block_data write_quick process_call read_block_data write_block_data block_process_call i2c_rdwr - combined write/read transactions with repeated start
Bug#878875: [Pkg-javascript-devel] Bug#878875: Packaging twemoji
hello Jonas, Jonas Smedegaard writes: > Quoting Felix Natter (2021-01-24 16:12:39) >> >> Control: retitle -1 RFP: twemoji -- Open-sourced Twitter emoji images >> >> hello Debian developers, >> >> twemoji contains SVGs for twitter emojis as well as javascript >> code to generate this in web/node.js apps. >> >> Unfortunately, I cannot package all of twemoji, because it has a >> generated file without source: >> https://github.com/twitter/twemoji-parser/blob/master/src/lib/regex.js >> >> I contacted a twitter developer (2020) [1] and she said that it could >> take a while until they publish the relevant library. >> >> [1] Justine De Caires jdecai...@twitter.com > > please consider raising the question at their issue tracker > https://github.com/twitter/twemoji-parser/issues - and then share a > reference to that public conversation here. Here is the ticket: https://github.com/twitter/twemoji-parser/issues/14 Best Regards, -- Felix Natter
Bug#981232: unblock: perl/5.32.1-1
Control: tags -1 moreinfo Hi Dominic, (Your bug title is wrong, as you can't use that version anymore as it's already in experimental ;) ) On 28-01-2021 00:39, Dominic Hargreaves wrote: > I should have probably > written all that in a bug instead so it can be tracked effectively. Indeed. > As always, perl point releases are pretty conservative and we've > effectively imported them into s-p-u before. > > All the reset of the context is in that post so I won't repeat it. Wouldn't have hurt though. > My preference is to upload 5.32.1 in whole as it's probably overall > less risky, and less maintenance work, but there is the option of > cherry-picking the targetted fixes too. > > 5.32.1 would need a binnmu of a few leaf packages > (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl > libcommon-sense-perl) as usual. Just to be clear, these binNMU's would be needed too if we would go for the cherry-pick option? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#981084: dh-elpa should provide dh-sequence-elpa
control: tag -1 + pending Hello, On Mon 25 Jan 2021 at 06:13PM +01, Helmut Grohne wrote: > Package: dh-elpa > Version: 2.0.6 > Tags: patch > > Please provide dh-sequence-elpa. Doing so allows using it declaratively. > Instead of adding "--with elpa" to the dh invocation, one can then add > dh-sequence-elpa to Build-Depends. Using the dependency technique, use > of the addon can be restricted to indep-only builds by moving it to > Build-Depends-Indep. Also the sequence can be conditionalized using > build profiles. (Though using build profiles requires fixing #981014.) Someone already sent in a salsa merge request for this a week or so ago and I applied their patch. -- Sean Whitton signature.asc Description: PGP signature
Bug#748553: Conflicting types on logout - possible mixup of functions?
Hi! For context please read old report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748553 I think your analysis is wrong, telnet/commands.c logout() is not related to utmp stuff at all, and cleansess.c should not be using it. The problem here is that telnet/commands.c was re-defining a system function, so fixed like this: https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=d92d17e98af1ae393bb9762112519a7bedbe1a8f /Simon signature.asc Description: This is a digitally signed message part
Bug#981296: node-ws: FTBFS: Error: Cannot find module '@types/node'
Source: node-ws
Version: 7.4.1+~cs18.0.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
node-ws/experimental recently started to FTBFS. An earlier build of the
same version has succeeded, so this new failure is likely due some change
in a (transitive) build dependency. The version in sid is not affected.
debian/rules binary
dh binary
dh_update_autotools_config
dh_autoreconf
dh_auto_configure --buildsystem=nodejs
mkdir node_modules
ln -s /usr/share/nodejs/debug ./node_modules/
mkdir -p ./node_modules/\@types
ln -s /usr/share/nodejs/\@types/debug ./node_modules/\@types/
ln -s /usr/share/nodejs/\@types/mocha ./node_modules/\@types/
internal/modules/cjs/loader.js:905
throw err;
^
Error: Cannot find module '@types/node'
Require stack:
- /build/node-ws-7.4.1+~cs18.0.6/[eval]
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
at Function.resolve (internal/modules/cjs/helpers.js:94:19)
at [eval]:1:21
at Script.runInThisContext (vm.js:132:18)
at Object.runInThisContext (vm.js:309:38)
at internal/process/execution.js:77:19
at [eval]-wrapper:6:22
at evalScript (internal/process/execution.js:76:60)
at internal/main/eval_string.js:23:3 {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/build/node-ws-7.4.1+~cs18.0.6/[eval]' ]
}
### @types/node is required by debian/nodejs/./extlinks but not available
make: *** [debian/rules:12: binary] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Andreas
node-ws_7.4.1+~cs18.0.6-2.log.gz
Description: application/gzip
Bug#981279: lintian: False positive: pkg-js-autopkgtest-file-does-not-exist packages/*/test
Hi, On Thu, Jan 28, 2021 at 11:42 AM Xavier wrote: > > I tested your patch, it fixes the problem. Merged. The commit still carries your name. Hope that's okay with you. Kind regards Felix Lechner
Bug#897381: update
I've noticed that this issue occurs when the nvidia driver has been updated. Attempting to start kitty will result in a message like this in dmesg: [183910.448118] NVRM: API mismatch: the client has the version 460.39, but NVRM: this kernel module has the version 460.32.03. Please NVRM: make sure that this kernel module and all NVIDIA driver NVRM: components have the same version. At the moment the only option seems to be to avoid nvidia-driver updates unless I'm ready to reboot, which is probably not a bad idea anyway.
Bug#981295: ITP: bio-vcf -- domain specific language (DSL) for processing the VCF format
Package: wnpp Severity: wishlist Subject: ITP: bio-vcf -- domain specific language (DSL) for processing the VCF format Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: bio-vcf Version : 0.9.5 Upstream Author : Pjotr Prins * URL : https://rubygems.org/gems/bio-vcf/ * License : MIT Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : domain specific language (DSL) for processing the VCF format Bio-vcf provides a domain specific language (DSL) for processing the VCF format. Record named fields can be queried with regular expressions, e.g. . sample.dp>20 and rec.filter !~ /LowQD/ and rec.tumor.bcount[rec.alt]>4 . Bio-vcf is a new generation VCF parser, filter and converter. Bio-vcf is not only very fast for genome-wide (WGS) data, it also comes with a really nice filtering, evaluation and rewrite language and it can output any type of textual data, including VCF header and contents in RDF and JSON. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/bio-vcf
Bug#981289: udunits breaks gnudatalanguage autopkgtest
Control: notfound -1 gnudatalanguage Dear udunits maintainer, unfortunately, the test log of gnudatalanguage is a bit confusing; these are the relevant lines from it: % Compiled module: TEST_CONSTANTS. % IMSL_CONSTANT: UDUNITS: failed to load the default unit database % IMSL_CONSTANT: UDUNITS: failed to load the default unit database % Execution halted at: TEST_CONSTANTS 36 /tmp/autopkgtest-lxc.tr9rpg1n/downtmp/build.2hE/src/testsuite/test_constants.pro % $MAIN$ This looks that udunits didn't find its unit database. Since from the log one can see that the libudunits2-data package was loaded, I would guess that there is some problem with the library. When looking into the failed CI test for gyoto, the message is a bit similar: In gyoto.C: Error initializing libgyoto: Converters.C:56 in void Gyoto::Units::Init(): error initializing arcsec unit Could you check that? Best regards Ole
Bug#981294: src:metastudent-data: fails to migrate to testing for too long: autopkgtest regression
Source: metastudent-data Version: 2.0.1-4 Severity: serious Control: close -1 2.0.1-5 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 981293 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:metastudent-data in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=metastudent-data OpenPGP_signature Description: OpenPGP digital signature
Bug#981293: metastudent-data breaks metastudent autopkgtest: 255
Source: metastudent-data, metastudent Control: found -1 metastudent-data/2.0.1-5 Control: found -1 metastudent/2.0.1-8 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload (60 days ago) of metastudent-data the autopkgtest of metastudent fails in testing when that autopkgtest is run with the binary packages of metastudent-data from unstable. It passes when run with only packages from testing. In tabular form: passfail metastudent-data from testing2.0.1-5 metastudentfrom testing2.0.1-8 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of metastudent-data to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=metastudent-data https://ci.debian.net/data/autopkgtest/testing/amd64/m/metastudent/10073288/log.gz autopkgtest [10:33:51]: test run-unit-test: [--- The Rost Lab recommends you install the pp-popularity-contest package that provides pp_popcon_cnt: sudo apt-get install pp-popularity-contest Error occurred: Exception Creating tmpDir... Using /tmp/autopkgtest-lxc.27xrgf95/downtmp/autopkgtest_tmp/metastudentr2yep04q Copying input file to tmpDir... Loading Gene Ontology... Running Blast MFO !!!Error!!! /usr/bin/blastpgp -i /tmp/autopkgtest-lxc.27xrgf95/downtmp/autopkgtest_tmp/metastudentr2yep04q/fasta_splits/split_0.fasta -o /tmp/autopkgtest-lxc.27xrgf95/downtmp/autopkgtest_tmp/metastudentr2yep04q/fasta_splits/split_0.fasta.blast -d /usr/share/metastudent-data/dataset_201401/MFO/goasp.fasta -e 1.0 -j 3 -b 1000 -v 1000 1>/tmp/autopkgtest-lxc.27xrgf95/downtmp/autopkgtest_tmp/metastudentr2yep04q/fasta_splits/split_0.fasta.blast.out 2>/tmp/autopkgtest-lxc.27xrgf95/downtmp/autopkgtest_tmp/metastudentr2yep04q/fasta_splits/split_0.fasta.blast.err 255 Deleting temp directories... == Metastudent finished == Traceback (most recent call last): File "/usr/bin/metastudent", line 775, in runIt(tempfile, inputFastaFilePath, outputFilePath, outputBlast, blastKickstartDatabasePaths, File "/usr/bin/metastudent", line 202, in runIt runBlast(fastaFilePathLocal, database, blastOutputFilePathLocal, tmpDirPath, configMap["BLAST_EVAL_%s" % ( File "/usr/lib/python3/dist-packages/metastudentPkg/runMethods.py", line 46, in runBlast raise Exception Exception autopkgtest [10:33:53]: test run-unit-test: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#981279: lintian: False positive: pkg-js-autopkgtest-file-does-not-exist packages/*/test
Le 28/01/2021 à 20:35, Felix Lechner a écrit : > Hi Xavier, > > Does this MR > > https://salsa.debian.org/lintian/lintian/-/merge_requests/350 > > do the same as your commit > > https://salsa.debian.org/yadd/lintian/-/commit/0aff1f22 > > ? > > Kind regards > Felix Lechner Hi, I tested your patch, it fixes the problem. Thanks!
Bug#981279: lintian: False positive: pkg-js-autopkgtest-file-does-not-exist packages/*/test
Hi Xavier, Does this MR https://salsa.debian.org/lintian/lintian/-/merge_requests/350 do the same as your commit https://salsa.debian.org/yadd/lintian/-/commit/0aff1f22 ? Kind regards Felix Lechner On Thu, Jan 28, 2021 at 8:33 AM Xavier Guimard wrote: > > Package: lintian > Version: 2.104.0 > Severity: normal > X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org > > Hi, > > lintian looks enable to understand `packages/*/test` expression when > trying to verify that files declared in debian/tests/pkg-js/files exist. >
Bug#978279: marked as pending in afew
> > I see that you are a DM, If you agree to add yourself to the uploader's > field, I'll happily grant permissions. Thanks! I updated, and included myself in the uploader's field. > > > > I believe the packaging is finished, so if you would do a short review > > and upload it, it would be appreciated. > > > > Looks good, however I'm unsure about this one change: > > * Why add yourself to copyright?[1] Usually this is done by the person who > debianizes the initial package which is Free Ekanayaka >IMHO, this should be reverted. I reverted the commit. I wasn't aware of this, I'm quite sure I've seen people adding their names to this field before. > > [1]: > https://salsa.debian.org/python-team/packages/afew/-/commit/b1431c378d6e44f4e706570b238ffed072c3b61b > Both changes has been pushed to salsa Håvard
Bug#981146: loggedfs: fails: fusermount: unknown option 'nonempty'
On Thu, 28 Jan 2021 16:50:50 +0800, Paul Wise wrote: > On Thu, 2021-01-28 at 09:17 +0100, Stephen Kitt wrote: > > ... except it does, which is the problem you ran into: > > Argh, forgot about the cause of that issue... > > > See #939767 for my proposed fix... > > Seems like that needs sending upstream. Yup, that was the plan, thanks for the prod: https://github.com/libfuse/libfuse/pull/582 Regards, Stephen pgpxPEdNiYeoV.pgp Description: OpenPGP digital signature
Bug#979521: openboard-common depends on libjs-jquery-i18n-properties that was removed from unstable
Package: openboard Version: 1.5.4+dfsg1-1 Followup-For: Bug #979521 Hi. Having libjs-jquery-i18n-properties reintroduced would be really nice, since it is an alternative to xournal. More software for teaching, especially in these pandemic times is *very* important. Thanks, Rogério Brito. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openboard depends on: ii libavcodec58 7:4.3.1-7 ii libavformat58 7:4.3.1-7 ii libavutil56 7:4.3.1-7 ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libgomp1 10.2.1-6 ii libpoppler102 20.09.0-3.1 ii libqt5core5a 5.15.2+dfsg-2 ii libqt5gui55.15.2+dfsg-2 ii libqt5multimedia5 5.15.2-2 ii libqt5multimediawidgets5 5.15.2-2 ii libqt5network55.15.2+dfsg-2 pn libqt5script5 ii libqt5svg55.15.2-2 pn libqt5webkit5 ii libqt5widgets55.15.2+dfsg-2 ii libqt5xml55.15.2+dfsg-2 pn libquazip5-1 ii libssl1.1 1.1.1i-2 ii libstdc++610.2.1-6 ii libswresample37:4.3.1-7 ii libswscale5 7:4.3.1-7 ii libx11-6 2:1.7.0-2 pn openboard-common ii zlib1g1:1.2.11.dfsg-2 openboard recommends no packages. Versions of packages openboard suggests: pn openboard-contrib -- Rogério Brito : rbr...@gmail.com : GPG key 4096R/BCFC http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#981292: buster-pu: package cairo/1.16.0-4+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: po...@debian.org
Low severity security fix, synched up with Emilio on IRC for the upload.
Cheers,
Moritz
diff -Nru cairo-1.16.0/debian/changelog cairo-1.16.0/debian/changelog
--- cairo-1.16.0/debian/changelog 2019-03-15 08:57:56.0 +0100
+++ cairo-1.16.0/debian/changelog 2021-01-22 00:02:52.0 +0100
@@ -1,3 +1,9 @@
+cairo (1.16.0-4+deb10u1) buster; urgency=medium
+
+ * CVE-2020-35492 (Closes: #CVE-2020-35492)
+
+ -- Moritz Mühlenhoff Fri, 22 Jan 2021 00:02:52 +0100
+
cairo (1.16.0-4) unstable; urgency=medium
* Team upload
diff -Nru cairo-1.16.0/debian/patches/CVE-2020-35492.patch
cairo-1.16.0/debian/patches/CVE-2020-35492.patch
--- cairo-1.16.0/debian/patches/CVE-2020-35492.patch1970-01-01
01:00:00.0 +0100
+++ cairo-1.16.0/debian/patches/CVE-2020-35492.patch2021-01-22
00:02:52.0 +0100
@@ -0,0 +1,47 @@
+From 03a820b173ed1fdef6ff14b4468f5dbc02ff59be Mon Sep 17 00:00:00 2001
+From: Heiko Lewin
+Date: Tue, 15 Dec 2020 16:48:19 +0100
+Subject: [PATCH] Fix mask usage in image-compositor
+
+[trimmed test case, since not used in Debian build]
+
+---
+ src/cairo-image-compositor.c| 8 ++--
+
+--- cairo-1.16.0.orig/src/cairo-image-compositor.c
cairo-1.16.0/src/cairo-image-compositor.c
+@@ -2601,14 +2601,14 @@ _inplace_src_spans (void *abstract_rende
+ unsigned num_spans)
+ {
+ cairo_image_span_renderer_t *r = abstract_renderer;
+-uint8_t *m;
++uint8_t *m, *base = (uint8_t*)pixman_image_get_data(r->mask);
+ int x0;
+
+ if (num_spans == 0)
+ return CAIRO_STATUS_SUCCESS;
+
+ x0 = spans[0].x;
+-m = r->_buf;
++m = base;
+ do {
+ int len = spans[1].x - spans[0].x;
+ if (len >= r->u.composite.run_length && spans[0].coverage == 0xff) {
+@@ -2646,7 +2646,7 @@ _inplace_src_spans (void *abstract_rende
+ spans[0].x, y,
+ spans[1].x - spans[0].x, h);
+
+- m = r->_buf;
++ m = base;
+ x0 = spans[1].x;
+ } else if (spans[0].coverage == 0x0) {
+ if (spans[0].x != x0) {
+@@ -2675,7 +2675,7 @@ _inplace_src_spans (void *abstract_rende
+ #endif
+ }
+
+- m = r->_buf;
++ m = base;
+ x0 = spans[1].x;
+ } else {
+ *m++ = spans[0].coverage;
diff -Nru cairo-1.16.0/debian/patches/series cairo-1.16.0/debian/patches/series
--- cairo-1.16.0/debian/patches/series 2019-03-15 08:57:56.0 +0100
+++ cairo-1.16.0/debian/patches/series 2021-01-22 00:02:52.0 +0100
@@ -4,3 +4,4 @@
06_hurd-map-noreserve.patch
git-pdf-add-missing-flush.patch
ft-Use-FT_Done_MM_Var-instead-of-free-when-available-in-c.patch
+CVE-2020-35492.patch
Bug#981291: RFP: librewolf -- community-maintained fork of librefox, privacy and security-focused browser based on firefox
Package: wnpp Severity: wishlist X-Debbugs-Cc: thejeremy@gmail.com * Package name: librewolf Version : 84.0.2-1 Upstream Author : LibreWolf Community * URL : https://librewolf-community.gitlab.io/ * License : (MPL GPL LGPL) Programming Lang: (C, Python, Bash) Description : community-maintained fork of librefox, privacy and security-focused browser based on firefox This is a fork of Firefox stripped of some of the functions considred by many to be privacy and security violations such as the Mozilla telemetry. The project has lately matured and grown in popuarity so I believe it would be appreciated by many Debian users.
Bug#981290: golang-k8s-klog -- Leveled execution logs for Go (fork of https://github.com/golang/glog)
Package: wnpp Severity: wishlist Owner: Arthur Diniz * Package name : golang-k8s-klog Version : 2.5.0-1 Upstream Author : Kubernetes * URL : https://github.com/kubernetes/klog * License : Apache-2.0 Programming Lang: Go Description : Leveled execution logs for Go (fork of https://github.com/golang/glog) klog is a permanent fork of https://github.com/golang/glog. The decision to create klog was one that wasn't made lightly, but it was necessary due to some drawbacks that are present in glog (https://github.com/golang/glog ). Ultimately, the fork was created due to glog not being under active development.
Bug#981284: [Pkg-libvirt-maintainers] Bug#981284: libvirt-daemon-driver-storage-iscsi-direct: Should recommend qemu-block-extra
On Thu, 28 Jan 2021, Guido Günther wrote: Hi, On Thu, Jan 28, 2021 at 11:52:41AM -0500, Matthew Gabeler-Lee wrote: Package: libvirt-daemon-driver-storage-iscsi-direct Version: 6.9.0-4 Severity: normal If using qemu, the libvirt iscsi-direct backend won't work without installing the qemu-block-extra package. So, like libvirt-daemon recommends qemu, I think this package should recommend the qemu iscsi support package. Care enough to send an MR here https://salsa.debian.org/libvirt-team/libvirt Sure thing, filed https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/95 Note: I don't have a bullseye builder environment setup yet, so I've not actually verified lack of typos there yet. But it looks like a CI pipeline should help out there :) -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#978279: marked as pending in afew
Hi Nilesh The reason I haven't uploaded is because I'm not a DD, so I don't have the necessary permissions. I believe the packaging is finished, so if you would do a short review and upload it, it would be appreciated. Regards, Håvard On Thu, 28 Jan 2021 17:56:32 +0530 Nilesh Patra wrote: > Hi Håvard > > Looks like you've fixed this, but not uploaded yet. > Is there anything missing, or should I upload this one? > > Regards, > Nilesh > > > On Thu, 14 Jan 2021 11:09:50 + =?UTF-8?B?SMOldmFyZCBGbGFnZXQgQWFzZW4=?= > wrote: > > Control: tag -1 pending > > > > Hello, > > > > Bug #978279 in afew reported by you has been fixed in the > > Git repository and is awaiting an upload. You can see the commit > > message below and you can check the diff of the fix at: > > > > https://salsa.debian.org/python-team/packages/afew/-/commit/ef9a6c241721ec0de127ab3d4e889483fec7c94a > > > > > > Remove regenerated file by scm. Closes: #978279 > > > > > > (this message was generated automatically) > > -- > > Greetings > > > > https://bugs.debian.org/978279 > > > > > > >
Bug#981289: udunits breaks gnudatalanguage autopkgtest
Source: udunits, gnudatalanguage Control: found -1 udunits/2.2.28-2 Control: found -1 gnudatalanguage/0.9.9-13 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of udunits the autopkgtest of gnudatalanguage fails in testing when that autopkgtest is run with the binary packages of udunits from unstable. It passes when run with only packages from testing. In tabular form: passfail udunitsfrom testing2.2.28-2 gnudatalanguagefrom testing0.9.9-13 all others from testingfrom testing I copied some of the output at the bottom of this report. There is no /dev/sda on most of our workers. Currently this regression is blocking the migration of udunits to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=udunits https://ci.debian.net/data/autopkgtest/testing/amd64/g/gnudatalanguage/10074185/log.gz % WARNING: your version of the GraphicsMagick library will truncate images to 16 bits per pixel % Compiled module: TEST_FILE_TEST. % Compiled module: ERRORS_ADD. % TEST_FILE_TEST_UNIX: Error on operation : This special file /dev/sda should exist ! % TEST_FILE_TEST_UNIX: Error on operation : This special file /dev/sda must be a block device ! % Compiled module: BANNER_FOR_TESTSUITE. % Compiled module: GDL_IDL_FL. % TEST_FILE_TEST_UNIX: === % TEST_FILE_TEST_UNIX: = = % TEST_FILE_TEST_UNIX: = 2 errors encountered during TEST_FILE_TEST_UNIX tests = % TEST_FILE_TEST_UNIX: = = % TEST_FILE_TEST_UNIX: === % Compiled module: ERRORS_CUMUL. % Compiled module: FILE_WHICH. % Compiled module: PATH_SEP. % TEST_FILE_TEST_GET_MODE: Error on operation : This file /tmp/autopkgtest-lxc.tr9rpg1n/downtmp/build.2hE/src/testsuite/Saturn.jpg has a bad mode ! % TEST_FILE_TEST_GET_MODE: Error on operation : This file /dev/sda should exist ! % TEST_FILE_TEST_GET_MODE: === % TEST_FILE_TEST_GET_MODE: = = % TEST_FILE_TEST_GET_MODE: = 2 errors encountered during TEST_FILE_TEST_GET_MODE tests = % TEST_FILE_TEST_GET_MODE: = = % TEST_FILE_TEST_GET_MODE: === % TEST_FILE_TEST_FILE_BASIC: NO errors encountered during TEST_FILE_TEST_FILE_BASIC tests % TEST_FILE_TEST_FILE_SYMLINK: NO errors encountered during TEST_FILE_TEST_FILE_SYMLINK tests % TEST_FILE_TEST_DIR_BASIC: NO errors encountered during TEST_FILE_TEST_DIR_BASIC tests % TEST_FILE_TEST_DIR_SYMLINK: NO errors encountered during TEST_FILE_TEST_DIR_SYMLINK tests % TEST_FILE_TEST_DIR_DANGLING: Error on operation : dir. 2 not removed % TEST_FILE_TEST_DIR_DANGLING: Error on operation : dir. 2 still symlink % TEST_FILE_TEST_DIR_DANGLING: === % TEST_FILE_TEST_DIR_DANGLING: = = % TEST_FILE_TEST_DIR_DANGLING: = 2 errors encountered during TEST_FILE_TEST_DIR_DANGLING tests = % TEST_FILE_TEST_DIR_DANGLING: = = % TEST_FILE_TEST_DIR_DANGLING: === % TEST_FILE_TEST: == % TEST_FILE_TEST: == % TEST_FILE_TEST: = 6 errors encountered during TEST_FILE_TEST tests = % TEST_FILE_TEST: == % TEST_FILE_TEST: == OpenPGP_signature Description: OpenPGP digital signature
Bug#981267: lzip: enable hardening flags
Package: lzip Version: 1.22-1 Dear Maintainer, please enable full hardening flags, e.g. by adding 'export DEB_BUILD_MAINT_OPTIONS = hardening=+all' to debian/rules. Best regards, Christian Göttsche
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Hello Thorsten, Am Donnerstag, den 28.01.2021, 14:52 +0100 schrieb Thorsten Rehm: > Hi Markus, > > thank you for your reply. > I've installed a fresh Debian Stretch and I think I know why I had > such a problem. I believe it's a dependency problem, but I let you > decide, if this is the case. > We're always installing the packages "pacemaker" and "crmsh" on our > systems. As you know, the latter one has a dependency to the > "pacemaker-cli-utils" package: [...] Indeed the problem could have been avoided if either the pacemaker-cli-utils dependency of crmsh or the Recommends: pacemaker-cli-utils in pacemaker was more strict. However the general issue here is that you instruct apt to install specific packages instead of upgrading the existing ones. If your policy forbids upgrades then I suggest to mark packages you don't want to upgrade as "on hold" or use apt pinning to change the priority of your packages. Then you could still use the upgrade command for the remaining packages. I recommend to install security updates though unless you are absolutely sure your systems/configurations are not affected. I leave it to the maintainer of pacemaker if he wants to tighten the Recommends of pacemaker-cli-utils in the future. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#981288: /usr/bin/jacal: references build-time dir; vicinity lacks a /; bashism
Package: jacal
Version: 1c7-1
The /usr/bin/jacal script provided by the current jacal package
fails to set SCHEME_LIBRARY_PATH and JACALDIR correctly:
#! /bin/sh
SCHEME_LIBRARY_PATH=/usr/share/slib
export SCHEME_LIBRARY_PATH
JACALDIR=/build/jacal-PHwb3U/jacal-1c7/debian/jacal/usr/lib/jacal/
VERSION=1c7
Specifically, SCHEME_LIBRARY_PATH (library-vicinity) is expected
to be a prefix (i. e., contain a trailing /), not directory name;
and JACALDIR somehow contains build-time prefix (in place of
a run-time one.)
Also, while we’re at it, I think that the script should make it
possible for the user to override either or both of the variables.
That is, I’d rather have it start with:
#! /bin/sh
: "${SCHEME_LIBRARY_PATH:=/usr/share/slib/}"
export SCHEME_LIBRARY_PATH
: "${JACALDIR:=/usr/lib/jacal/}"
VERSION=1c7
(Which is not without its downsides, but is otherwise consistent
with how, say, shells allow for PATH to be overridden arbitrarily.)
FTR, the built-time directory name capture is somehow despite
debian/rules [1] containing:
# These are from upstream's install target, turned into correctness.
debian/jacal/usr/bin/jacal:
-mkdir -p $$(dirname $@)
echo '#! /bin/bash' > $@
echo JACALDIR=/usr/lib/jacal/ >> $@
echo VERSION=$(version) >> $@
cat jacal.sh>> $@
chmod +x $@
[1] http://sources.debian.org/data/main/j/jacal/1c7-1/debian/rules
--
FSF associate member #7257 http://am-1.org/
Bug#981287: jupyterlab-server: autopkgtest regression: No module named 'anyio'
Source: jupyterlab-server Version: 2.0.0-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of jupyterlab-server the autopkgtest of jupyterlab-server fails in testing when that autopkgtest is run with the binary packages of jupyterlab-server from unstable. It passes when run with only packages from testing. In tabular form: passfail jupyterlab-serverfrom testing2.0.0-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=jupyterlab-server https://ci.debian.net/data/autopkgtest/testing/amd64/j/jupyterlab-server/10075204/log.gz autopkgtest [12:11:40]: test import: [--- Traceback (most recent call last): File "", line 1, in File "/tmp/autopkgtest-lxc.a1pp7mfm/downtmp/build.ywI/src/jupyterlab_server/__init__.py", line 4, in from .app import LabServerApp File "/tmp/autopkgtest-lxc.a1pp7mfm/downtmp/build.ywI/src/jupyterlab_server/app.py", line 11, in from jupyter_server.extension.application import ExtensionApp, ExtensionAppJinjaMixin File "/usr/lib/python3/dist-packages/jupyter_server/extension/application.py", line 20, in from jupyter_server.serverapp import ServerApp File "/usr/lib/python3/dist-packages/jupyter_server/serverapp.py", line 72, in from .services.contents.filemanager import AsyncFileContentsManager, FileContentsManager File "/usr/lib/python3/dist-packages/jupyter_server/services/contents/filemanager.py", line 15, in from anyio import run_sync_in_worker_thread ModuleNotFoundError: No module named 'anyio' autopkgtest [12:11:43]: test import: ---] OpenPGP_signature Description: OpenPGP digital signature
Bug#981283: Should the daemon started at postinst?
On 2021-01-28 11:30 a.m., u...@net9.ga wrote:
Package: nsd
Version: 4.1.26-1
Severity: normal
The bottom lines of the package installation were:
Preparing to unpack .../nsd_4.1.26-1_amd64.deb ...
Job for nsd.service failed because the control process exited with error
code.
See "systemctl status nsd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nsd, action "start" failed.
* nsd.service - Name Server Daemon
Loaded: loaded (file:/lib/systemd/system/nsd.service
/lib/systemd/system/nsd.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Wed
2021-01-27 16:38:05 EST; 12ms ago
Docs: man:nsd(8) man:nsd(8)
Process: 536 ExecStart=/usr/sbin/nsd -d (code=exited, status=1/FAILURE)
Main PID: 536 (code=exited, status=1/FAILURE)
Jan 27 16:38:05 systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Jan 27 16:38:05 systemd[1]: nsd.service: Failed with result 'exit-code'.
Jan 27 16:38:05 systemd[1]: Failed to start Name Server Daemon.
dpkg: error processing package nsd (--configure):
installed nsd package post-installation script subprocess returned error
exit status 1
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u5) ...
Errors were encountered while processing:
nsd
Sub-process /usr/bin/dpkg returned an error code (1)
The package is left in an half-Conf state.
I think the problem is not having a working nsd configuration files. Which
is a bit trickier to solve. Just setting appropriate configuration files
and
You should check "journalctl -u nsd" and see why it is failing to start.
A common situation is when systemd-resolved stub listener has already
bound port 53. You can check with:
{ ss -nlt; ss -nlu; } | grep :53
If that's the case, setting DNSStubListener=no in
/etc/systemd/resolved.conf and restarting systemd-resolved usually fixes it.
HTH,
Simon
Bug#981084: dh-elpa should provide dh-sequence-elpa
Starting with David's question (paraphrased beyond recognition): "Will it break stuff if I add this Provides?" Nothing will break. As long as /exactly one/ binary package has that "Provides" and installing the package will in fact ensure that the add-on is functional, then everything will be fine. And even then, it only starts to break if anyone starts to use the virtual package (in which case, their package will FTBFS making it exceptionally difficult for themselves to push that breakage on to you). So worst case, you get a minor bug that you did it wrong and it is not functional after all leaving you with one line of cruft in your d/control. All in all, I think you will manage! ;) Now, on to various claims about why I wrote stuff the way I did. :) Mattia Rizzolo: > On Thu, Jan 28, 2021 at 02:42:14PM +0100, Helmut Grohne wrote: >> debhelper knows about addons. Traditionally, you could enable them via >> "--with foo". That turned out to be difficult when you want an addon for >> for an architecture-independent package (e.g. sphinx) and can skip it >> for arch-only builds. Therefore a separate way to enable addons was >> added. When you add dh-sequence-foo to Build-Depends, it'll be enabled. > > I *believe* the driving reason about supporting the new dh-sequence-foo > notation in Build-Depends(|-arch|-indep) was not that, but mostly about > DRYing the packaging and reducing the size of d/rules (so as to have a > more declarative and less imperative packaging). > To be honest, I am not sure what was the driving factor for what any more, so I cannot say whether you are right or wrong here. :) However, I do remember that supporting the conditional add-ons was always going to be via a declarative interface (but that could still go both ways). >> This change is a bit of an edge case wrt freeze. Having it in bullseye >> would be good for one reason: Once someone backports packages that do >> depend on dh-sequence-elpa, one also has to use a backported dh-elpa >> unless you add the provides now. So in the interest of simplifying >> backports to bullseye, I'd say you should include it now. > > Yes, please add such thing. It's something very small, but the improved > DRYness is always very nice :) > Agreed, I think it would be safe for bullseye. Admittedly, I am not a member of the RT any more, so this holds less weight than it used too. :) ~Niels
Bug#981286: node-mimic-response: autopkgtest regression on !amd64: Cannot find module 'iconv'
Source: node-mimic-response
Version: 3.1.0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of node-mimic-response the autopkgtest of
node-mimic-response fails in testing when that autopkgtest is run with
the binary packages of node-mimic-response from unstable. It passes when
run with only packages from testing. In tabular form:
passfail
node-mimic-responsefrom testing3.1.0-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=node-mimic-response
https://ci.debian.net/data/autopkgtest/testing/arm64/n/node-mimic-response/10071183/log.gz
autopkgtest [16:14:29]: test pkg-js-autopkgtest: [---
# Using package.json
# Node module name is mimic-response
# Build files found:
# Test files found: test.js
# Files/dir to be installed from source: test.js
# Copy test files
# Copy debian/tests/pkg-js content
'debian/tests/pkg-js' ->
'/tmp/autopkgtest-lxc.ahpnqplz/downtmp/autopkgtest_tmp/smokeVIaf0R/debian/tests/pkg-js'
'debian/tests/pkg-js/test' ->
'/tmp/autopkgtest-lxc.ahpnqplz/downtmp/autopkgtest_tmp/smokeVIaf0R/debian/tests/pkg-js/test'
# Found debian/tests/test_modules directory, let's copy it
'/tmp/autopkgtest-lxc.ahpnqplz/downtmp/autopkgtest_tmp/smokeVIaf0R/node_modules/create-cert'
-> '../debian/tests/test_modules/create-cert'
'/tmp/autopkgtest-lxc.ahpnqplz/downtmp/autopkgtest_tmp/smokeVIaf0R/node_modules/create-test-server'
-> '../debian/tests/test_modules/create-test-server'
'/tmp/autopkgtest-lxc.ahpnqplz/downtmp/autopkgtest_tmp/smokeVIaf0R/node_modules/es6-promisify'
-> '../debian/tests/test_modules/es6-promisify'
'/tmp/autopkgtest-lxc.ahpnqplz/downtmp/autopkgtest_tmp/smokeVIaf0R/node_modules/p-event'
-> '../debian/tests/test_modules/p-event'
'/tmp/autopkgtest-lxc.ahpnqplz/downtmp/autopkgtest_tmp/smokeVIaf0R/node_modules/pem'
-> '../debian/tests/test_modules/pem'
# Searching module in /usr/lib/nodejs/mimic-response
# Searching module in /usr/lib/*/nodejs/mimic-response
# Searching module in /usr/share/nodejs/mimic-response
# Found /usr/share/nodejs/mimic-response
# Searching files to link in /usr/share/nodejs/mimic-response
'./index.d.ts' -> '/usr/share/nodejs/mimic-response/index.d.ts'
'./index.js' -> '/usr/share/nodejs/mimic-response/index.js'
'./package.json' -> '/usr/share/nodejs/mimic-response/package.json'
# Launch debian/tests/pkg-js/test with sh -ex
+ jest --ci --testRegex test.js
FAIL ./test.js
● Test suite failed to run
Cannot find module 'iconv' from
'../../../../../usr/share/nodejs/raw-body/index.js'
Require stack:
/usr/share/nodejs/raw-body/index.js
/usr/share/nodejs/body-parser/lib/read.js
/usr/share/nodejs/body-parser/lib/types/json.js
/usr/share/nodejs/body-parser/index.js
/usr/share/nodejs/express/lib/express.js
/usr/share/nodejs/express/index.js
debian/tests/test_modules/create-test-server/src/index.js
test.js
235 |
236 | const relativePath = (0,
_slash().default)(path().relative(this._options.rootDir, from)) || '.';
> 237 | throw new _ModuleNotFoundError.default(`Cannot find
module '${moduleName}' from '${relativePath}'`, moduleName);
| ^
238 | }
239 |
240 | _isAliasModule(moduleName) {
at Resolver.resolveModule
(../../../../../usr/share/nodejs/jest-resolve/build/index.js:237:11)
at Object.
(../../../../../usr/share/nodejs/raw-body/index.js:17:13)
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time:4.099 s
Ran all test suites.
autopkgtest [16:14:35]: test pkg-js-autopkgtest: ---]
OpenPGP_signature
Description: OpenPGP digital signature
Bug#887035: cron: Logging to STDOUT when in foreground mode
For the use case of containerized environments BusyBox already provides a cron applet with custom logging capabilities: busybox crond -f -L /dev/stdout
Bug#951770: libpam-radius-auth: do not release in bullseye without active maintainer
Hi Carsten, hi Christoph, On Thu, Jan 28, 2021 at 05:15:46PM +0100, Carsten Schoenert wrote: > retitle -1 ITA: picking up maintenance of libpam-radius-auth > > Hello Salvatore, > > Am Fri, Feb 21, 2020 at 03:03:12PM +0100 schrieb Salvatore Bonaccorso: > > Source: libpam-radius-auth > > Version: 1.4.0-3 > > Severity: serious > > Justification: should not be released in bullseye without active maintainer > > > > libpam-radius-auth has been orphaned in Debian since several years and > > QA maintained. It did had at least the CVE-2015-9542 security issue. > > > > There are no packages blocking a potential removal, so the package > > should get an active maintainer to be part of bullseye ideally. > > Christoph Goehre and myself are taking over the maintenace of this > package, we use RADIUS authentication daily on our day job and we have a > strong interrest that this package will stay in Debian. ;) That is perfect, thank you in this case of taking care of it! Regards, Salvatore
Bug#981285: Please move fdk-aac to main
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-multime...@lists.debian.org Subject: Please move fdk-aac to main Package: ftp.debian.org Severity: normal Hello, Currently the fdk-aac[0] package is in non-free. That package would be needed by both pulseaudio (via gstreamer) and pipewire to provide AAC support for bluetooth headsets and speakers. After some discussion with people on #debian-gnome, it looks like that the licence of the package might actually be free after all. Both the GNU project[1] and Fedora[2] are considering it Free. Could you please have a look at this an maybe move the package to main? Note that this would remove the need of src:gst-plugins-bad1.0-contrib that is currently waiting in the NEW queue. Kind Regards, Laurent Bigonville [0] https://tracker.debian.org/pkg/fdk-aac [1] https://www.gnu.org/licenses/license-list.html#fdk [2] https://fedoraproject.org/wiki/Licensing/FDK-AAC
Bug#981284: [Pkg-libvirt-maintainers] Bug#981284: libvirt-daemon-driver-storage-iscsi-direct: Should recommend qemu-block-extra
Hi, On Thu, Jan 28, 2021 at 11:52:41AM -0500, Matthew Gabeler-Lee wrote: > Package: libvirt-daemon-driver-storage-iscsi-direct > Version: 6.9.0-4 > Severity: normal > > If using qemu, the libvirt iscsi-direct backend won't work without > installing the qemu-block-extra package. So, like libvirt-daemon recommends > qemu, I think this package should recommend the qemu iscsi support > package. Care enough to send an MR here https://salsa.debian.org/libvirt-team/libvirt ? Cheers, -- Guido > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, > 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads) > 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) > > Versions of packages libvirt-daemon-driver-storage-iscsi-direct depends on: > ii libc6 2.31-9 > ii libgcc-s1 10.2.1-6 > ii libglib2.0-02.66.4-1 > ii libiscsi7 1.19.0-3 > ii libvirt-daemon 6.9.0-4 > ii libvirt06.9.0-4 > > libvirt-daemon-driver-storage-iscsi-direct recommends no packages. > > libvirt-daemon-driver-storage-iscsi-direct suggests no packages. > > -- no debconf information > > ___ > Pkg-libvirt-maintainers mailing list > pkg-libvirt-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
Bug#979306: QVTKOpenGLWidget.h: No such file or directory
Package: libvtk9-qt-dev Version: 9.0.1+dfsg1-8 Followup-For: Bug #979306 As far as avogadrolibs goes, replacing QVTKOpenGLWidget with QVTKOpenGLStereoWidget seems to be sufficient to remove the deprecated function (though it will also need help to find /usr/include/vtk-9.0/). However I suggest nevertheless that QVTKOpenGLWidget.h should still be provided by libvtk9-qt-dev. It's deprecated, https://vtk.org/doc/nightly/html/classQVTKOpenGLWidget.html, but that doesn't mean it's eliminated yetx. The point of the deprecated functions is provide client applications notification and time to upgrade to the new API. So the header still needs to be provided by libvtk9-qt-dev in order to achieve that. Doesn't the upstream build system still install the deprecated header?
Bug#981284: libvirt-daemon-driver-storage-iscsi-direct: Should recommend qemu-block-extra
Package: libvirt-daemon-driver-storage-iscsi-direct Version: 6.9.0-4 Severity: normal If using qemu, the libvirt iscsi-direct backend won't work without installing the qemu-block-extra package. So, like libvirt-daemon recommends qemu, I think this package should recommend the qemu iscsi support package. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/16 CPU threads) 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) Versions of packages libvirt-daemon-driver-storage-iscsi-direct depends on: ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.4-1 ii libiscsi7 1.19.0-3 ii libvirt-daemon 6.9.0-4 ii libvirt06.9.0-4 libvirt-daemon-driver-storage-iscsi-direct recommends no packages. libvirt-daemon-driver-storage-iscsi-direct suggests no packages. -- no debconf information
Bug#981283: Should the daemon started at postinst?
Package: nsd Version: 4.1.26-1 Severity: normal The bottom lines of the package installation were: Preparing to unpack .../nsd_4.1.26-1_amd64.deb ... Job for nsd.service failed because the control process exited with error code. See "systemctl status nsd.service" and "journalctl -xe" for details. invoke-rc.d: initscript nsd, action "start" failed. * nsd.service - Name Server Daemon Loaded: loaded (file:/lib/systemd/system/nsd.service /lib/systemd/system/nsd.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Wed 2021-01-27 16:38:05 EST; 12ms ago Docs: man:nsd(8) man:nsd(8) Process: 536 ExecStart=/usr/sbin/nsd -d (code=exited, status=1/FAILURE) Main PID: 536 (code=exited, status=1/FAILURE) Jan 27 16:38:05 systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE Jan 27 16:38:05 systemd[1]: nsd.service: Failed with result 'exit-code'. Jan 27 16:38:05 systemd[1]: Failed to start Name Server Daemon. dpkg: error processing package nsd (--configure): installed nsd package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.8.5-2) ... Processing triggers for systemd (241-7~deb10u5) ... Errors were encountered while processing: nsd Sub-process /usr/bin/dpkg returned an error code (1) The package is left in an half-Conf state. I think the problem is not having a working nsd configuration files. Which is a bit trickier to solve. Just setting appropriate configuration files and dpkg-reconfigure nsd /usr/sbin/dpkg-reconfigure: nsd is broken or not fully installe Doesn't work. I opted to dpkg -i /var/cache/apt/archives/nsd_4.1.26-1_amd64.deb -- u34
Bug#979977: raspi-firmware: Seems to ignore latest installed kernel (5.10.0-1-armmp-lpae) while the booting kernel is older (5.10.0-trunk-armmp-lpae)
tags 979977 + confirmed
thanks
Ummh, interesting...
Latest kernel and initrd are found by the following simplistic,
lexicographic logic:
latest_kernel=$(ls -1 /boot/vmlinuz-* | grep -v '\.dpkg-bak$' | sort -V -r
| head -1)
if [ -z "$latest_kernel" ]; then
echo "raspi-firmware: no kernel found in /boot/vmlinuz-*, cannot populate
/boot/firmware"
exit 0
fi
latest_initrd=$(ls -1 /boot/initrd.img-* | grep -v '\.dpkg-bak$' | sort -V
-r | head -1)
if [ -z "$latest_initrd" ]; then
echo "raspi-firmware: no initrd found in /boot/initrd.img-*, cannot
populate /boot/firmware"
exit 0
fi
So... Yes, it behaves as you report. Modifying the logic to search in
/tmp/boot:
$ touch /tmp/boot/vmlinuz-{5.10.0-trunk-armmp-lpae,5.10.0-1-armmp-lpae}
$ latest_kernel=$(ls -1 /tmp/boot/vmlinuz-* | grep -v '\.dpkg-bak$' | sort
-V -r | head -1)
$ echo $latest_kernel
/tmp/boot/vmlinuz-5.10.0-trunk-armmp-lpae
Now... What to do here? I think dpkg --compare-versions here agreees
with the simplistic ordering set by ls:
$ if dpkg --compare-versions 5.10.0-trunk-armmp-lpae gt 5.10.0-1-armmp-lpae
then
echo trunk is larger
else
echo 1 is larger
fi
trunk is larger
How would you suggest to check for this?
Bug#843113: better missing kernel headers message
Control: found -1 2.8.4-1 I've encountered a similar issue today: Setting up linux-image-5.10.0-2-amd64 (5.10.9-1) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-1-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-1-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-5.10.0-2-amd64 I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-2-amd64 /etc/kernel/postinst.d/dkms: dkms: WARNING: Linux headers are missing, which may explain the above failures. please install the linux-headers-5.10.0-2-amd64 package to fix this. There are no "above failures", so reading this warning message is somewhat misleading. Of course, if dkms needs some extra package, it should ideally depend on it in some way, but this seems to be nontrivial and is already covered by other bug reports, such as #762061 and #951404. But perhaps it is possible to make the above warning conditional and only print it if there actually were any errors?
Bug#981282: The autopkgtests are currently failing
Package: pikepdf Version: 1.17.3+dfsg-3 Despite the recent upload which cherry picked fixes for the qpdf version tests are still failing https://ci.debian.net/packages/p/pikepdf/unstable/amd64/ Cheers,
Bug#981281: ITP: r-cran-cachem -- cache GNU R objects with automatic pruning
Package: wnpp Severity: wishlist Subject: ITP: r-cran-cachem -- cache GNU R objects with automatic pruning Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-cachem Version : 1.0.1 Upstream Author : Winston Chang, * URL : https://cran.r-project.org/package=cachem * License : MIT Programming Lang: GNU R Description : cache GNU R objects with automatic pruning Key-value stores with automatic pruning. Caches can limit either their total size or the age of the oldest object (or both), automatically pruning objects to maintain the constraints. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-cachem
Bug#979450: booth: autopkgtest fails on ci-worker-ppc64el-01 (but apparently not on other ppc64el workers)
On Thu, Jan 28, 2021 at 03:52:41PM +0100, Paul Gevers wrote: > Grr. I'm now sure they don't. Although we generate new containers every > day, it seems that the configuration of those containers in > /var/lib/lxc/* *doesn't* get refreshed. I have just destroyed all > containers before creating new ones, and now they contain this. So, > somehow our container recreation is flawed. > > I ran a booth, pdns and pdns-recursor autopkgtest manually on this host, > and they now pass. > > I've reassigned the bugs to autopkgtest, it needs to be fixed there IMHO. autopkgtest-build-lxc has an update mode where it only recreates rootfs for existing containers but not anything else outside of that. The safest way would probably be to create a container with a new name, run some tests and if it looks good rename over the previous container. -- Valentin
Bug#981280: ITP: r-cran-sass -- GNU R Syntactically Awesome Style Sheets ('Sass')
Package: wnpp
Severity: wishlist
Subject: ITP: r-cran-sass -- GNU R Syntactically Awesome Style Sheets ('Sass')
Package: wnpp
Owner: Andreas Tille
Severity: wishlist
* Package name: r-cran-sass
Version : 0.3.1
Upstream Author : Joe Cheng,
* URL : https://cran.r-project.org/package=sass
* License : MIT
Programming Lang: GNU R
Description : GNU R Syntactically Awesome Style Sheets ('Sass')
An 'SCSS' compiler, powered by the 'LibSass' library. With this,
R developers can use variables, inheritance, and functions to generate
dynamic style sheets. The package uses the 'Sass CSS' extension language,
which is stable, powerful, and CSS compatible.
Remark: This package is maintained by Debian R Packages Maintainers at
https://salsa.debian.org/r-pkg-team/r-cran-sass
Bug#981279: lintian: False positive: pkg-js-autopkgtest-file-does-not-exist packages/*/test
Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org Hi, lintian looks enable to understand `packages/*/test` expression when trying to verify that files declared in debian/tests/pkg-js/files exist.
