Bug#974551: linphone: missing build-dependency on python-pystache
Source: linphone Version: 3.12.0-3.1 Severity: serious User: trei...@debian.org Usertags: edos-uninstallable Hi, linphone build-depends on python-pystache. However, sid has only python3-pystache. -Ralf.
Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)
Control: retitle -1 libcharls-dev needs Breaks: libdcmtk-dev (<< 3.6.5-1~) On Thu, Nov 12, 2020 at 8:13 AM Adrian Bunk wrote: > > On Thu, Nov 12, 2020 at 08:09:11AM +0100, Mathieu Malaterre wrote: > > On Thu, Nov 12, 2020 at 8:06 AM Adrian Bunk wrote: > > > > > > Control: reopen -1 > > > > > > On Thu, Nov 12, 2020 at 08:02:07AM +0100, Mathieu Malaterre wrote: > > > > Control: fixed -1 2.1.0+dfsg-7 > > > > > > > > https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22 > > > > > > > > dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while > > > > libcharls-dev is SOVERSION=2, so I'll not add the Replaces. > > > > > > The conflict is on the unversioned libcharls.so symlink. > > > > Could you confirm you saw that dcmtk 3.6.5-1 does *not* ship > > libcharls.so anymore ? > > https://buildd.debian.org/status/logs.php?pkg=odin=2.0.4-0.2%2Bb1=amd64 OK, I understand the issue now. Thanks
Bug#968335: kernel crash: WARNING: CPU: 0 PID: 0 at lib/percpu-refcount.c:155 percpu_ref_switch_to_atomic_rcu+0xf8/0x120
Unfortunately, my machine crashed again last night. No special activity, no stressing things going on - just full 100% standstill. Nothing visible in either syslog or kern.log. On screen just the regular login prompt (no GUI, just terminal login) but the cursor was absent and the system didn't react to keyboard. So, also unfortunately, no error log or crash information at all. So don't know if the crashes I experience are in any way related to this kernel bug #968335 Any suggestions how I can get any further information out of this system in future crashes? Kind regards, Matthijs
Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)
On Thu, Nov 12, 2020 at 08:09:11AM +0100, Mathieu Malaterre wrote: > On Thu, Nov 12, 2020 at 8:06 AM Adrian Bunk wrote: > > > > Control: reopen -1 > > > > On Thu, Nov 12, 2020 at 08:02:07AM +0100, Mathieu Malaterre wrote: > > > Control: fixed -1 2.1.0+dfsg-7 > > > > > > https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22 > > > > > > dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while > > > libcharls-dev is SOVERSION=2, so I'll not add the Replaces. > > > > The conflict is on the unversioned libcharls.so symlink. > > Could you confirm you saw that dcmtk 3.6.5-1 does *not* ship > libcharls.so anymore ? https://buildd.debian.org/status/logs.php?pkg=odin=2.0.4-0.2%2Bb1=amd64 > Thanks for your help cu Adrian
Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)
On Thu, Nov 12, 2020 at 8:06 AM Adrian Bunk wrote: > > Control: reopen -1 > > On Thu, Nov 12, 2020 at 08:02:07AM +0100, Mathieu Malaterre wrote: > > Control: fixed -1 2.1.0+dfsg-7 > > > > https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22 > > > > dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while > > libcharls-dev is SOVERSION=2, so I'll not add the Replaces. > > The conflict is on the unversioned libcharls.so symlink. Could you confirm you saw that dcmtk 3.6.5-1 does *not* ship libcharls.so anymore ? Thanks for your help
Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)
Control: reopen -1 On Thu, Nov 12, 2020 at 08:02:07AM +0100, Mathieu Malaterre wrote: > Control: fixed -1 2.1.0+dfsg-7 > > https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22 > > dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while > libcharls-dev is SOVERSION=2, so I'll not add the Replaces. The conflict is on the unversioned libcharls.so symlink. cu Adrian
Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)
Control: fixed -1 2.1.0+dfsg-7 https://salsa.debian.org/med-team/charls/-/blob/debian/2.1.0+dfsg-7/debian/control#L22 dcmtk 3.6.5 ships a convenient copy of CharLS with SOVERSION=1, while libcharls-dev is SOVERSION=2, so I'll not add the Replaces.
Bug#974550: golang-github-gomodule-redigo-dev: New upstream version available, using lower version number
Package: golang-github-gomodule-redigo-dev Version: 2.0.0-1 Severity: normal Hi, while it looks like version 2.0.0-1 of the golang-github-gomodule-redigo-dev package matches the latest upstream version, this doesn't seem to really match reality. Looking at https://github.com/gomodule/redigo/tags we have the following versions/tags with their corresponding "release date" next them: v1.8.2 on 2020-06-08 v1.8.1 on 2020-05-06 v1.8.0 on 2020-04-30 v1.7.2 on 2020-04-30 v1.7.1 on 2020-04-30 v1.7.0 on 2018-12-13 v2.0.0 on 2018-03-14(!) So v2.0.0 is actually the oldest version, while upstream's newest version as of today is v1.8.2, due to a version number downgrade to 1.7.0 after the 2.0.0 release back in 2018). We can either only introduce an epoch version :-/ - or hope for upstream raising their version number, I tried to bring this up at upstream at https://github.com/gomodule/redigo/issues/532 regards -mika-
Bug#959550: FTBFS: dh_sphinxdoc: error: debian/python-distributed-doc/usr/share/doc/python-distributed-doc/html/_static/js/html5shiv.min.js is missing
Hello, I can't replicate this ftbfs in my local sbuild now. I think there's a chance it was a problem in sphinx-rtd-theme-common that was separately resolved. I'm going to downgrade this bug to normal, and deal with my other replicatable RC bugs. If it goes away after a new release, I'll close this bug. Diane signature.asc Description: This is a digitally signed message part
Bug#974543: Acknowledgement (segmentation fault on launch)
I am able to work around this problem on Debian Buster by adding the line: |imports.gi.versions.GtkSource = "3.0";| to the beginning of the file: | | |/usr/share/sushi/js/viewers/text.js| | |
Bug#974549: aspcud: FTBFS agsinst boost_1.74
Package: aspcud Severity: important Tags: ftbfs Usertags: boost174 Dear maintainer, it was discovered that your package failed to build against boost_1.74. Logs can be found here [1]. Most relevant part is probably this: libcudf/src/dependency.cpp:476:85: error: _2 was not declared in this scope 476 | boost::sort(candidates, boost::bind(::edgeSort, this, _1, _2)); | ^~ It is planned to push boost_1.74 as the default version in Debian/Bullseye. [1] http://qa-logs.debian.net/2020/10/27-boost/boost/aspcud_1.9.4-2_unstable_boost.log Best regards Anton -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#974548: aspcud: FTBFS agsinst boost_1.74
Package: aspcud Severity: important Tags: ftbfs Usertags: boost174 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, it was discovered that your package failed to build against boost_1.74. Logs can be found here [1]. Most relevant part is probably this: /<>/libcudf/src/dependency.cpp:476:85: error: ‘_2’ was not declared in this scope 476 | boost::sort(candidates, boost::bind(::edgeSort, this, _1, _2)); It is planned to push boost_1.74 as the default version in Debian/Bullseye. [1] http://qa-logs.debian.net/2020/10/27-boost/boost/aspcud_1.9.4-2_unstable_boost.log Best regards Anton - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+sWRsRHGdsYWRrQGRl Ymlhbi5vcmcACgkQ0+Fzg8+n/wZnsw/9H4NMfjEccQhiENCcVn3newZlbmuRnTLw Mrzo5XbzSKHjRyKfpxzUvajcXTnRCwTTzS7XqzKCImZl+rAsQqNzEqhoHcvBSmCl FSd/ppYM6tmxBTp+whxcglqsuaVIOx8AveruN338vOqxktDHwGh65AKd05MmC0kb lg4OBDsJj9S9bQtNZLVyWdtM1j7eqL83m8084hcHa+nA/a4d/KToiYIQAVJAhFFZ ZyOVK9Ba+kHU0n728Tw8jQzh+vWdZCl/yAgeW3f5tp1T6Gafd0VbiClyMqgsOv/f CH52MMFwkPYwld5z7CSrUtxv2DeTOAlP8VIBaFyQu06LZbAeeXypHQxFyNfhUmWW G+TDXg3sG2fCgF8WbVVKOEmLYAwMOwxJqkoMvxRn6nw9Ps88Zkr8HouFG6qClugG DFZWBms5SRB5rD1BrCc5i1m6lb5AGhhfHC/Yz2kOixh2oml/PtjdfpX1VS5H+GDj YYGyF6QIveIj4hCJBKobwNb/Cn/MoCZbqFYHwUp/xAly2L2XQPI0bmPHLtCHvSxz 5JlgnH7tnuetJYxyAE2b55H3rfJn2X6s2clZdwtYpoXNU5QZLze0qdljLSkF1pb9 IDy51/9jbtBg1AojI7BLxZ7HvFqYXiWBNAzWAWRcgxXt3qeLbjEw2TufsvcVuUWl 2syIHuUhywI= =lA4R -END PGP SIGNATURE-
Bug#974107: Segfault when running isenkram-lookup
Attached please find the stdout from Ubuntu's autopkgtest when running the test-command-line script in amd64. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj test-command-line-stdout.gz Description: application/gzip
Bug#974037: Fails to build on mipsel
Control: severity -1 important Control: tags -1 ftbfs On Mon, Nov 09, 2020 at 11:40:14AM +0100, Guido Günther wrote: > Package: src:rust-gtk > Version: 0.7.0-1 > Severity: serious It is not RC when the package was never built on an architecture. > rust-gtk fails to build on mipsel like: > > https://buildd.debian.org/status/fetch.php?pkg=rust-gtk=mipsel=0.7.0-1=1596355821=0 > > The relevant bit seems to be > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > error: could not compile `gtk`. > > So i wonder if that can be handled by a give back on a machine with more > RAM? The buildds where it was tried have either 4 GB or 8 GB RAM. Which is not the problem when you are running out of address space. Address space available for a program (like a compiler instance) on the 32bit release architectures: 2 GB mipsel 3 GB armel/armhf 4 GB i386 built on amd64 With g++ the most common workaround is building with -g1, I don't have experience how to work around excessive memory usage in rust. > Cheers, > -- Guido cu Adrian
Bug#971142: varnish-modules: diff for NMU version 0.16.0-2.1
On Wed, Nov 11, 2020 at 11:02:24AM +0100, Stig Sandbeck Mathisen wrote: > Adrian Bunk writes: > > > Control: tags 971142 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for varnish-modules (versioned as 0.16.0-2.1) and > > uploaded it to DELAYED/14. Please feel free to tell me if I should > > cancel it. > > Hello Adrian, Hi Stig, > Thank you for taking the time to do a package upload with a patch for > this bug. Feel free to leave in the delayed queue, or upload immediately > if you have the time. thanks, rescheduled for immediate upload. cu Adrian
Bug#974547: ITP: golang-github-adam-hanna-arrayoperations -- Small library for performing union, intersect, difference and distinct operations on slices in golang
Package: wnpp Severity: wishlist Owner: Stephen Gelman * Package name: golang-github-adam-hanna-arrayoperations Version : 0.2.6-1 Upstream Author : Adam Hanna * URL : https://github.com/adam-hanna/arrayOperations * License : Expat Programming Lang: Go Description : Small library for performing union, intersect, difference and distinct operations on slices in goLang A small library for performing union, intersect, difference and distinct operations on slices in goLang This is a dependency for the latest version of termshark
Bug#928131: [Pkg-julia-devel] Bug#928131: Bug#928131: julia: FTBFS on arm64 and armhf
On Wed, 11 Nov 2020, peter green wrote: > The correct commit is > https://github.com/JuliaLang/julia/commit/971e769479a2947a55cc253dc9750fd2a361367a Thanks, included in the git repo, will be in the next upload. Best 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#974545: fraqtive FTBFS: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined
Source: fraqtive Version: 0.4.8-11 Severity: serious Tags: ftbfs fraqtive fails to build from source in unstable: | g++ -c -pipe -g -Wall -Wextra -D_REENTRANT -fPIC -DHAVE_SSE2 -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -I. -I. -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtXml -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I../tmp -I../tmp -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o ../tmp/debug/configurationdata.o configurationdata.cpp | configurationdata.cpp: In member function ‘bool ConfigurationData::checkAccess(const QString&)’: | configurationdata.cpp:183:70: warning: ‘QStringList QString::split(QChar, QString::SplitBehavior, Qt::CaseSensitivity) const’ is deprecated: Use Qt::SplitBehavior variant instead [-Wdeprecated-declarations] | 183 | QStringList pathParts = path.split( '/', QString::SkipEmptyParts ); | | ^ | In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qhashfunctions.h:44, | from /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:47, | from /usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:45, | from /usr/include/x86_64-linux-gnu/qt5/QtCore/QVariant:1, | from configurationdata.h:22, | from configurationdata.cpp:19: | /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:610:17: note: declared here | 610 | QStringList split(QChar sep, SplitBehavior behavior, | | ^ | g++ -c -pipe -g -Wall -Wextra -D_REENTRANT -fPIC -DHAVE_SSE2 -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -I. -I. -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtXml -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I../tmp -I../tmp -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o ../tmp/debug/datafunctions.o datafunctions.cpp | datafunctions.cpp: In function ‘QPolygonF DataFunctions::interpolateCubic(const QPolygonF&)’: | datafunctions.cpp:128:26: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined | 128 | QPainterPath path; | | ^~~~ | make[2]: *** [Makefile:1161: ../tmp/debug/datafunctions.o] Error 1 | make[2]: Leaving directory '/<>/src' | make[1]: *** [Makefile:47: sub-src-make_first] Error 2 | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j1 returned exit code 2 | make: *** [debian/rules:16: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 This seems to be recent and caused by some other package being updated. Helmut
Bug#974546: klatexformula FTBFS: error: invalid use of incomplete type ‘class QPainterPath’
Source: klatexformula
Version: 4.0.0-4
Severity: serious
Tags: ftbfs
klatexformula fails to build from source in unstable:
| [ 27%] Building CXX object
src/klftools/CMakeFiles/klftools.dir/klfflowlistwidget.cpp.o
| cd /<>/obj-x86_64-linux-gnu/src/klftools && /usr/bin/c++
-DKLF_SRC_BUILD -DKLF_VERSION_MAJ=4 -DKLF_VERSION_MIN=0 -DKLF_VERSION_REL=0
-DKLF_VERSION_STRING=\"4.0.0\" -DKLF_WS=\"x11\" -DKLF_WS_X11 -DQT_CORE_LIB
-DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_XML_LIB -Dklftools_EXPORTS
-I/<>/obj-x86_64-linux-gnu/src/klftools
-I/<>/src/klftools -isystem /usr/include/x86_64-linux-gnu/qt5
-isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/x86_64-linux-gnu/qt5/QtXml -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fPIC -o
CMakeFiles/klftools.dir/klfflowlistwidget.cpp.o -c
/<>/src/klftools/klfflowlistwidget.cpp
| In file included from /<>/src/klftools/klfflowlistwidget.cpp:29:
| /<>/src/klftools/klfflowlayout.h:65:96: warning: ‘constexpr
QFlags::QFlags(QFlags::Zero) [with Enum = Qt::AlignmentFlag;
QFlags::Zero = int QFlags::Private::*]’ is deprecated:
Use default constructor instead [-Wdeprecated-declarations]
|65 | virtual void addWidget(QWidget *w, int hstretch = 0, int vstretch =
0, Qt::Alignment align = 0);
| |
^
| In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1304,
| from
/usr/include/x86_64-linux-gnu/qt5/QtGui/qtguiglobal.h:43,
| from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qtwidgetsglobal.h:43,
| from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qwidget.h:43,
| from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QWidget:1,
| from /<>/src/klftools/klfflowlistwidget.cpp:24:
| /usr/include/x86_64-linux-gnu/qt5/QtCore/qflags.h:123:80: note: declared here
| 123 | QT_DEPRECATED_X("Use default constructor instead")
Q_DECL_CONSTEXPR inline QFlags(Zero) noexcept : i(0) {}
| |
^~
| In file included from /<>/src/klftools/klfflowlistwidget.cpp:31:
| /<>/src/klftools/klfflowlistwidget_p.h:286:16: error: field
‘box’ has incomplete type ‘QPainterPath’
| 286 | QPainterPath box;
| |^~~
| In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/qbrush.h:49,
| from /usr/include/x86_64-linux-gnu/qt5/QtGui/qpalette.h:46,
| from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qwidget.h:48,
| from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QWidget:1,
| from /<>/src/klftools/klfflowlistwidget.cpp:24:
| /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix.h:54:7: note: forward
declaration of ‘class QPainterPath’
|54 | class QPainterPath;
| | ^~~~
| In file included from /<>/src/klftools/klfflowlistwidget.cpp:31:
| /<>/src/klftools/klfflowlistwidget_p.h:287:16: error: field
‘crossbox’ has incomplete type ‘QPainterPath’
| 287 | QPainterPath crossbox;
| |^~~~
| In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/qbrush.h:49,
| from /usr/include/x86_64-linux-gnu/qt5/QtGui/qpalette.h:46,
| from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qwidget.h:48,
| from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QWidget:1,
| from /<>/src/klftools/klfflowlistwidget.cpp:24:
| /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix.h:54:7: note: forward
declaration of ‘class QPainterPath’
|54 | class QPainterPath;
| | ^~~~
| In file included from /<>/src/klftools/klfflowlistwidget.cpp:31:
| /<>/src/klftools/klfflowlistwidget_p.h: In member function
‘virtual void KLFFlowListItemWidget::resizeEvent(QResizeEvent*)’:
| /<>/src/klftools/klfflowlistwidget_p.h:223:24: error: invalid
use of incomplete type ‘class QPainterPath’
| 223 | box = QPainterPath();
| |^
| In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/qbrush.h:49,
| from /usr/include/x86_64-linux-gnu/qt5/QtGui/qpalette.h:46,
| from
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qwidget.h:48,
| from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QWidget:1,
| from /<>/src/klftools/klfflowlistwidget.cpp:24:
| /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix.h:54:7: note: forward
declaration of ‘class QPainterPath’
|54 | class QPainterPath;
| | ^~~~
| In file included from /<>/src/klftools/klfflowlistwidget.cpp:31:
|
Bug#973939: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#973939: fixed in ismrmrd 1.4.2.1-3)
Control: reopen -1 On Wed, Nov 11, 2020 at 11:33:06AM +, Debian Bug Tracking System wrote: >... > ismrmrd (1.4.2.1-3) unstable; urgency=medium >... >* Fix binary-all FTBFS > Closes: #973939 >... Unfortunately this did not work: https://buildd.debian.org/status/fetch.php?pkg=ismrmrd=all=1.4.2.1-3=1605091989=0 cu Adrian
Bug#974544: libcharls-dev needs Breaks+Replaces: libdcmtk-dev (<< 3.6.5-1~)
Package: libcharls-dev Version: 2.1.0+dfsg-6 Severity: serious See #973723.
Bug#974543: segmentation fault on launch
Package: gnome-sushi Version: 3.30.0-2 Severity: grave Hello Sushi does not seem to work on Debian Buster. If I select e.g. some mp3 file in Nautilus filemanager and press the space bar then nothing happens. The same happens if I select file of some other type. I also get this error in the /var/log/syslog Nov 12 06:16:13 miksuh-laptop kernel: [10482.886638] sushi-start[11917]: segfault at 0 ip 7ff7a1aaf64f sp 7ffe20adb3c0 error 6 in libgjs.so.0.0.0[7ff7a1a75000+67000] Nov 12 06:16:13 miksuh-laptop kernel: [10482.886648] Code: 00 e8 a5 7c fc ff 4c 8b 04 24 48 8d 0d 5d 41 03 00 48 8b 7c 24 18 89 c6 31 d2 31 c0 e8 4a 9e fc ff 48 8b 7b 18 e8 11 8e fc ff <41> c7 07 01 00 00 00 e9 82 00 00 00 0f 1f 44 00 00 48 8b bb 78 01 When I try to launch sushi from the command line it segfaults with the followin error: Gjs-Message: 06:06:08.541: JS WARNING: [/usr/share/sushi/js/viewers/text.js 26]: Requiring Gdk but it has 2 versions available; use imports.gi.versions to pick one Gjs-Message: 06:06:08.563: JS WARNING: [/usr/share/sushi/js/viewers/text.js 30]: Requiring GtkSource but it has 2 versions available; use imports.gi.versions to pick one (sushi-start:11595): Gjs-WARNING **: 06:06:08.564: JS ERROR: Error: Requiring Sushi, version none: Requiring namespace 'GtkSource' version '3.0', but '4' is already loaded @/usr/share/sushi/js/viewers/text.js:33:7 Segmentation fault This seems to be the same bug as reported upstream here: https://gitlab.gnome.org/GNOME/sushi/-/issues/12 -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-sushi depends on: ii gir1.2-clutter-1.0 1.26.2+dfsg-10 ii gir1.2-clutter-gst-3.0 3.0.26-2 ii gir1.2-evince-3.0 3.30.2-3+deb10u1 ii gir1.2-gdkpixbuf-2.02.38.1+dfsg-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gst-plugins-base-1.0 1.14.4-2 ii gir1.2-gstreamer-1.01.14.4-1 ii gir1.2-gtk-3.0 3.24.5-1 ii gir1.2-gtkclutter-1.0 1.8.4-4 ii gir1.2-gtksource-3.03.24.9-2 ii gir1.2-pango-1.01.42.4-8~deb10u1 ii gir1.2-webkit2-4.0 2.28.4-1~deb10u1 ii gstreamer1.0-plugins-good 1.14.4-1 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libclutter-1.0-01.26.2+dfsg-10 ii libclutter-gst-3.0-03.0.26-2 ii libclutter-gtk-1.0-01.8.4-4 ii libevdocument3-43.30.2-3+deb10u1 ii libevview3-33.30.2-3+deb10u1 ii libfreetype62.9.1-3+deb10u2 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgirepository-1.0-1 1.58.3-2 ii libgjs0g1.54.3-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer-plugins-base1.0-0 1.14.4-2 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libgtksourceview-3.0-1 3.24.9-2 ii libharfbuzz0b 2.3.1-1 ii libmusicbrainz5-2 5.1.0+git20150707-9 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libx11-62:1.6.7-1+deb10u1 ii nautilus3.30.5-2 gnome-sushi recommends no packages. Versions of packages gnome-sushi suggests: ii gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2 -- no debconf information
Bug#974531: krb5: Please include upstream fix "Unregister thread key in SPNEGO finalization"
I don't plan to ever put 1.17.2 into unstable; I plan to ask to move 1.18.2 into unstable shortly. LTS is beyond my horizon of caring. I won't stand in your way, and if you never became a DD, I'll be happy to review and sponsor anything you need, but that's not where my energy goes.
Bug#974428: in.telnetd crashes on running Nessus security scan
The same crash is observed in the following package too. package: telnetd-ssl version: 0.17.41+0.2-3.2+b1
Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable
On Wed, Nov 11, 2020 at 05:07:44PM +, Simon McVittie wrote: > Distribution-specific SONAME bumps, without coordination with upstreams, > cause incompatibilities for years to come (see: libcurl) and I would > strongly prefer to avoid them. I agree it is an unfortunate situation that upstream does this, but a) it's a debian policy violation and b) it introduces unchecked out of bounds accesses, which are always potential security bugs. This is especially troublesome as the mere display of text from untrusted sources can trigger this. If you think that this bug report is a bit muddled I can open a new bug only about the policy vioaltion and memory corruption issue, so there is no confusion about header files or other incompatiiblities, which are a separate issue. > It is also the upstream developer who decides which parts of a library are > or aren't considered to be part of the public API/ABI. True, but in this case, the developer has decided that the relevant parts ARE part of the public ABI. A developer cannot undo this, just as a developer cannot make 1=2, no matter how much she or he insist on it. (which the pango developers don't do btw., it's not disputed that the relevant parts are part of the public ABI, all that the pango developers have said is that they don't have the manpower to bump the soname when on breaking changes). > Yes, reclassifying public API/ABI as private breaks derived projects > that were relying on it, Not only that, they also introduce random memory corruption and potential security bugs. Please note that the problem is not reclassifying the public ABI as private, the problem is breaking the ABI without bumping the soname introducing serious actual bugs. Reclassifying thew ABI as private would not have caused this, neither would breaking the ABI and bumping the soname cause this kind of issue. > and it's unfortunate that the Pango maintainers were unaware > that derived projects were relying on this part of the API The pango maintainers obviously were aware of that, because it's documented in the pango documentation multiple timesa and in the nissue I reported they admitted they were aware of it, but don't care (apparently because it is just too much work, a fair point). > *could* make a Debian-specific fork of Pango, and link our GTK/etc. Bumping the soname is not forking pango, but required by debian policy. Note that bumping thew soname is all that's required to fix this issue, even if the fix is not to my liking, but keep in mind this escalated from "some ABI/API is no longer accessible" to " > I'm sorry that this has broken your use-case, but I don't think taking > an adversarial tone is going to help you to achieve the result you are > aiming for. Can you point out where I have taken "adversial tone"? What I reported is a policy violation and apart from that a serious issue (unchecked memory accesses that can be triggered simply by displaying text). > People who perceive that they are being attacked will tend to > become increasingly defensive and unwilling to change their position, > which is presumably the opposite of what you want. I suppose the bets way to proceed for you is to not feel attacked - I am not aware of attacking you, and if you wrongly got the impression I did, rest assured that this was not the intent of my words, I respect you as a fellow human and so on. Since this is cleared up, I hope we can go back to the actual etchnical issues here? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\
Bug#974542: [sddm] Resets /etc/X11/default-display-manager on upgrade
Package: sddm Version: 0.18.0-1+deb10u1 Severity: minor --- Please enter the report below this line. --- The scripts run on package upgrade replace default display manager value. The default should not change silently if current DM is valid. --- System information. --- Architecture: Kernel: Linux 5.9.8+ Debian Release: 10.6 900 stable-debugdebug.mirrors.debian.org 900 stable security.debian.org 900 stable ftp.pl.debian.org 900 stable dl.winehq.org 900 proposed-updates ftp.pl.debian.org 850 buster-backports ftp.pl.debian.org 800 testing ftp.pl.debian.org 700 unstableftp.pl.debian.org 600 experimentalftp.pl.debian.org 540 oldstable security.debian.org 540 oldstable ftp.pl.debian.org 500 unstable-debug debug.mirrors.debian.org 500 testing-debug debug.mirrors.debian.org 500 proposed-updates-debug debug.mirrors.debian.org 100 buster-backports-debug debug.mirrors.debian.org 1 experimental-debug debug.mirrors.debian.org --- Package information. --- Depends (Version) | Installed ===-+- adduser | 3.118 qml-module-qtquick2 | 5.11.3-4 x11-common | 1:7.7+19 xserver-xorg| 1:7.7+19 OR xserver | debconf (>= 0.5) | 1.5.71 OR debconf-2.0 | libc6 (>= 2.14) | libgcc1 (>= 1:3.0) | libpam0g (>= 0.99.7.1) | libqt5core5a(>= 5.11.0~rc1) | libqt5dbus5 (>= 5.6.0~) | libqt5gui5 (>= 5.6.0~beta) | libqt5network5 (>= 5.6.0~) | libqt5qml5 (>= 5.0.2) | libqt5quick5 (>= 5.0.2) | libstdc++6 (>= 5.2) | libsystemd0 | libxcb-xkb1 | libxcb1 | Recommends (Version) | Installed =-+-=== haveged | 1.9.1-7 libpam-systemd| 241-7~deb10u4 sddm-theme-debian-maui| OR sddm-theme| Suggests (Version) | Installed ===-+-=== libpam-kwallet5 | 5.14.5-1 qtvirtualkeyboard-plugin|
Bug#974541: ITP: deepin-gtk-theme -- Deepin Gtk Themes
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : deepin-gtk-theme Version : 17.10.11 Upstream Author : iceleaf916 * URL : https://github.com/linuxdeepin/deepin-gtk-theme License : LGPL-3+ Programming Lang : CSS Description : Deepin Gtk Themes This package contains GTK2 and GTK3 application theme for the Deepin desktop environment,such as dark and light color configurations. . It is part of Deepin software and DDE (Deepin Desktop Environment). . I intend to co-maintain this package inside pkg-deepin group.
Bug#974206: closed by Ben Hutchings (Re: Bug#974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway)
Control: reopen -1 On Wed, 2020-11-11 at 19:34 +0200, Harald Hannelius wrote: > On Wed, 11 Nov 2020, Debian Bug Tracking System wrote: > > > This is an automatic notification regarding your Bug report > > which was filed against the debian-installer package: > > > > #974206: debian-installer: When entering an IPv6 address, fe80::1 should be > > a valid gateway > > > > It has been closed by Ben Hutchings . > > > No, this is a link-local address so you have to also specify the > > interface name, e.g. "fe80::1%eth0", > > The installer could then give a hint that %eth0 should be added, or any > interface name that was used in the previous step when the interface got > it's IP-address. The user doesn't know the correct name for the interface at > that stage, it might be ens3, eth0, wlan0, eno1, wlp1s3 or something else. > > I can't remember when I have had to add the interface name to the gateway > since this configuration is usually added in the context of the interface > being configured. OK, yes, good point. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou signature.asc Description: This is a digitally signed message part
Bug#971875: RFS: austin/2.0.0-1 -- Frame stack sampler for CPython
On Thu, 8 Oct 2020 23:03:31 +0100 Gabriele wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "austin": > > * Package name: austin >Version : 2.0.0-1 >Upstream Author : Gabriele N. Tornetta > * URL : https://github.com/P403n1x87/austin > * License : GPL-3+ > * Vcs : https://github.com/P403n1x87/austin >Section : devel would you be interested in joining the Debian Python team ( https://wiki.debian.org/Teams/PythonTeam) and maintaining austin under its umbrella? it's generally easier to find sponsors for python-related projects there. btw, it would also be good if you could package austin-tui :)
Bug#974537: [Pkg-fonts-devel] Bug#974537: fonts-noto-core: Fallback font selection changed and incorrect glyph displayed
Hi astian, Thanks for a detailed bugreport! Quoting astian (2020-11-11 21:31:00) > With version 20200323-1, when attempting to render code points such as > 0x3001 and 0x3002, fontconfig would choose "Noto Sans CJK JP" [0] as > fallback for "Monospace". This was expected behaviour, I want to see > Japanese punctuation glyphs. > 0: /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc > > Binary packages for version 20200323-1 seem to be gone from the archive > but version 20181227-1 also shows the wanted behaviour. Some are here: https://snapshot.debian.org/binary/fonts-noto-core/ > After updating to version 20201027-3 and later also 20201109-1, > fontconfig chooses "Noto Sans Mongolian" [1]. This results in > unintended glyphs. > 1: /usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf I understand that this changed. But is it a bug? I mean, is it universally preferred to use Japanese over Mongolian for those characters? > STR: > > a) Run: >$ LANG=en_US.UTF-8 pango-view --font monospace -t $'\u3001' > Or even: >$ LANG=en_US.UTF-8 pango-view -t $'\u3001' Oh, that's a neat way to render unicode characters, didn't know that one. Failed for me at first, however, so here is another little trick: locale en_US.UTF-8 is not generally enabled, but locale C.UTF-8 is. > b) Run: >$ fc-match --sort monospace family style file | grep -i -e cjk -e mongo > Or even: >$ fc-match --sort : family style file | grep -i -e cjk -e mongo > Expected behaviour: > > a) The pango-view window shows the Japanese comma glyph (see for > example "Noto Sans CJK JP" in fontforge). > > b) A Japanese font is preferred: >Noto Sans CJK > JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc >Noto Sans > Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf > > Actual behaviour: > > a) The pango-view window shows a different glyph (from "Noto Sans > Mongolian"). > > b) A Mongolian font is preferred: >Noto Sans > Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf >Noto Sans CJK > JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc When I try the above with packages in unstable as of today, I get what looks to me as the comma glyph, even though fc-cache indeed shows Mongolian as prioritized. > This looks like a regression and it is one for me, but I guess it > could also be a configuration issue involving fontconfig. I have no > custom fontconfig configuration, though, so if somehow this is not > considered a regression, perhaps you could recommend a configuration > that would restore the previous behaviour for me? Sorry, I am not clever with fontconfig and the fonts-noto-core package includes only a small configuration related to older name Droid: /etc/fonts/conf.avail/30-droid-noto.conf I notice that package fonts-noto-cjk ships a more extensive configuration seemingly related to identifying as "monospace": /usr/share/fontconfig/conf.avail/70-fonts-noto-cjk.conf Perhaps it helps to edit that CJK configuration to add binding="strong" also to the monospace sections? Please to report back if that helps, and whether or not you think this is universally a preferred setup or we should perhaps introduce some flexibility in these packages - i.e. a mechanism to let Mongolians prioritize their glyphs and let Japansese prioritize theirs. Kind regards, - Jonas -- * 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#904723: [Pkg-javascript-devel] Bug#904723: Why is the last version of node-diff not in unstable?
Hi Julien, Quoting Julien Puydt (2020-11-11 21:37:48) > you have uploaded 4.0.1 to experimental in august 2019 ; is there a > reason why it didn't get into unstable? > > I ask because I want to work on shipping the TypeScript types with the > package... and the definition are for v4. > > So basically, I want to work on the package, but don't want to step on > your toes. Thanks for looking into this - and thanks for keeping me in the loop. I did not work any further on that package. Reason I stopped was that I realized it might require testing a bunch of reverse dependencies, and I postponed that... - and have since then been busy elsewhere. If you want, then please go ahead and do that migration work. I have no special insight into it, and have no special ties to the node-diff package really, so if you like then add yourself as uploader and maintain it :-) Kind regards, - Jonas -- * 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#974536: libssh2-1: Prevents salt from performing SSH key auth
Package: libssh2-1 Version: 1.8.0-2.1 Severity: normal Dear Maintainer, Please see https://github.com/saltstack/salt/issues/58898 for further information. LibSSH update needs to be pushed out in order to resolve public key authentication issues with pygit2. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libssh2-1 depends on: ii libc62.28-10 ii libgcrypt20 1.8.4-5 ii zlib1g 1:1.2.11.dfsg-1 libssh2-1 recommends no packages. libssh2-1 suggests no packages. -- no debconf information
Bug#974100: lxqt: LXQt packages are obsolete
Hi, it is intended not to upgrade packages in Debian (10 Buster) stable. Except optional backports. However for Debian (11 Bullseye) testing and unstable LXQt should be upgraded, at least before the upcoming freeze [1]. As mentioned in [2] LXQt Debian packages are currently unmaintained. [1] https://release.debian.org/bullseye/freeze_policy.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959963 Cheers, Amy
Bug#973902: RFS: btrfs-progs/5.9-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities
Hi Gianfranco, Thank you for sponsoring! Gianfranco Costamagna writes: > Hello > Sponsored after adding > * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools, > because these are not applicable to the backport. > > to changelog... > G. > I don't understand why adding this line was required, because I'm using best-practises for backports (merged changelog), and merging tag from testing, rather than forking for each release, and I'm generating the .changes file relative to the last upload to buster-backports (which is why this entry didn't appear the 5.9-1~bpo10+1 entry). Full changelog for buster-backports shows: btrfs-progs (5.9-1~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. -- Nicholas D Steeves Thu, 05 Nov 2020 16:18:31 -0500 btrfs-progs (5.9-1) unstable; urgency=medium * New upstream release. -- Adam Borowski Fri, 23 Oct 2020 21:22:35 +0200 btrfs-progs (5.7-1~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools, because these are not applicable to the backport. -- Nicholas D Steeves Tue, 28 Jul 2020 20:31:55 -0400 btrfs-progs (5.7-1) unstable; urgency=medium Regards, Nicholas signature.asc Description: PGP signature
Bug#974172: libmutter-7-0: Impossible to unlock the screen with wayland+gdm, keybard and mouse unresponsive
Dear Simon, Thanks a lot for your answer. On Wed, 11 Nov, 2020 at 10:32, Simon McVittie wrote: Control: notfound -1 3.38.0-2 Control: found -1 3.38.1-2 Control: tags -1 + moreinfo On Wed, 11 Nov 2020 at 00:46:39 +0100, Gali Drudis-Sole wrote: After upgrading the system, locking the screen of gnome-shell under wayland, made it impossible to unlock the screen. This works fine for me, and presumably other GNOME users, so there must be something specific to your system that is relevant. Good. I hope to find it. What messages appeared in the system log (systemd journal) at the time that this happened? These two lines apear just after locking the system (gdm started with [debug] Enable=true). Nothing else is shown when I try to enter the password to unlock the screen: Nov 11 23:04:29 mobian gsd-usb-protect[2319]: Error calling USBGuard DBus to change the protection after a screensaver event: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.usbguard1 was not provided by any .service files Nov 11 23:04:29 mobian gnome-shell[2141]: Bogus presentation time 0 travelled back in time, using current time. Are you using any GNOME Shell extensions? None. Downgrading gir1.2-mutter-7 and libmutter-7-0 to version 3.38.0-2 solved the issue. You reported this as a bug in version 3.38.0-2, but here you've said that version 3.38.0-2 *doesn't* have the bug. What version did you upgrade to that triggered this? (For now I've assumed 3.38.1-2.) Sorry, that was my error when reporting the bug. Version 3.38.0-2 DOES WORK, but upgrading to the current testing version (3.38-1.2) DOES NOT WORK. The system is a pinetab running mobian Mobian is a Debian derivative, and is not identical to Debian. If this is caused or triggered by a change made by Mobian, then changes in Debian will not fix it. It might be better to report bugs in Mobian to the Mobian developers. You are right. It could be some change in mobian that is incompatible with the upgrade of gir1.2-mutter-7 and libmutter-7-0. If you think that's the case, I'll report the bug to Mobian developers, as you suggest. smcv
Bug#974540: qgis: after update to qgis 3.10.11 not started
Package: qgis Version: 1:3.10.11+15buster Severity: important Dear Maintainer, After update to qgis 3.10.11 not start (crashes). the terminal shows an error: ":~$ qgis QGIS died on signal 11 (aborted)". This happened after yesterday's QGIS 3.10.11 updates in https://qgis.org/debian-ltr -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=lt_LT.utf8, LC_CTYPE=lt_LT.utf8 (charmap=UTF-8), LANGUAGE=lt_LT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qgis depends on: ii libc62.28-10 ii libexiv2-14 0.25-4+deb10u1 ii libexpat12.2.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdal20 [gdal-abi-2-4-0] 2.4.0+dfsg-1+b1 ii libgeos-c1v5 3.7.1-1 ii libgsl23 2.5+dfsg-6 ii libgslcblas0 2.5+dfsg-6 ii libpq5 12.3-1.pgdg90+1 ii libproj135.2.0-1 ii libqca-qt5-2 2.1.3-2 ii libqgis-3d3.10.111:3.10.11+15buster ii libqgis-analysis3.10.11 1:3.10.11+15buster ii libqgis-app3.10.11 1:3.10.11+15buster ii libqgis-core3.10.11 1:3.10.11+15buster ii libqgis-gui3.10.11 1:3.10.11+15buster ii libqgis-native3.10.111:3.10.11+15buster ii libqscintilla2-qt5-132.10.4+dfsg-2.1 ii libqt53dcore55.11.3+dfsg-2 ii libqt53dextras5 5.11.3+dfsg-2 ii libqt53dinput5 5.11.3+dfsg-2 ii libqt53dlogic5 5.11.3+dfsg-2 ii libqt53drender5 5.11.3+dfsg-2 ii libqt5concurrent55.11.3+dfsg1-1+deb10u4 ii libqt5core5a 5.11.3+dfsg1-1+deb10u4 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u4 ii libqt5gui5 5.11.3+dfsg1-1+deb10u4 ii libqt5keychain1 0.9.1-2 ii libqt5network5 5.11.3+dfsg1-1+deb10u4 ii libqt5positioning5 5.11.3+dfsg-2 ii libqt5printsupport5 5.11.3+dfsg1-1+deb10u4 ii libqt5qml5 5.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5quickwidgets5 5.11.3-4 ii libqt5serialport55.11.3-2 ii libqt5sql5 5.11.3+dfsg1-1+deb10u4 ii libqt5svg5 5.11.3-2 ii libqt5webkit55.212.0~alpha2-21 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u4 ii libqt5xml5 5.11.3+dfsg1-1+deb10u4 ii libqwt-qt5-6 6.1.4-1 ii libspatialindex5 1.9.0-1 ii libspatialite7 4.3.0a-5+b2 ii libsqlite3-0 3.27.2-3 ii libstdc++6 8.3.0-6 ii libzip4 1.5.1-4 ii ocl-icd-libopencl1 [libopencl1] 2.2.12-2 ii python3-qgis 1:3.10.11+15buster ii qgis-common 1:3.10.11+15buster ii qgis-providers 1:3.10.11+15buster ii qt5-image-formats-plugins5.11.3-2 Versions of packages qgis recommends: ii qgis-plugin-grass 1:3.10.11+15buster Versions of packages qgis suggests: pn gpsbabel -- no debconf information
Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu
Hi Francesco,
Quoting Francesco Poli (2020-09-04 18:18:32)
> > I am using the attached script to build my own autopkgtest qemu images and
> > it
> > works fine for me. Maybe you want to try again?
>
> I have just retried with my script (which seems to do the same things as
> yours, except that it does set the unshare mode, since I have
> kernel.unprivileged_userns_clone = 0).
>
> Unfortunately, I still see the same guestfish error:
>
> I: automatically chosen mode: fakechroot
> I: chroot architecture amd64 is equal to the host's architecture
> I: automatically chosen format: tar
> I: using ${HOME}/Downloads/TEST/mmdebstrap.Cd9NV53RA7 as tempdir
> [...]
> I: creating tarball...
> I: done
> I: removing tempdir ${HOME}/Downloads/TEST/mmdebstrap.Cd9NV53RA7...
> I: success in 107.2860 seconds
> libguestfs: error: /usr/bin/supermin exited with error status 1.
> To see full error messages you may need to enable debugging.
> Do:
> export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
> and run the command again. For further information, read:
> http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
> You can also run 'libguestfs-test-tool' and post the *complete* output
> into a bug report or message to the libguestfs mailing list.
>
> Once again, the .qcow2 image is tiny and the .img does not boot with
>
> $ qemu-system-x86_64 -enable-kvm -m 512 \
> -serial unix:/tmp/ttyS0,server,nowait -drive \
> "file=./debian-unstable.img,format=raw,cache=unsafe,if=virtio,index=0"
>
> After attempting all possible boot devices, including a network boot,
> it bails out with "No bootable device" error message.
I have some more insights. After having gotten the mmdebstrap/guestfish thing
running on salsaci, debci and jenkins I also happened to see stuff that looked
very similar to the errors you are seeing. Going over my last emails to this
thread, the guestfish command I told you about was indeed missing something:
the installation of mbr.bin. So a better guestfish command is this one:
guestfish -N debian-unstable.img=disk:8G -- \
part-disk /dev/sda mbr : \
mkfs ext2 /dev/sda1 : \
mount /dev/sda1 / : \
tar-in debian-unstable.tar / : \
copy-in "extlinux.conf" / : \
upload /usr/lib/SYSLINUX/mbr.bin /mbr.bin : \
copy-file-to-device /mbr.bin /dev/sda size:440 : \
rm /mbr.bin : \
extlinux / : \
sync : \
umount / : \
part-set-bootable /dev/sda 1 true : \
shutdown
I have no idea why, but on my system, the disk boots even without writing
mbr.bin to the first 440 byte of the disk. Just to make sure, here is my
extlinux.conf:
default linux
timeout 0
label linux
kernel /vmlinuz
append initrd=/initrd.img root=/dev/vda1 rw net.ifnames=0 console=ttyS0
Also, you reported that the guestfish call fails for you and that if you set
LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 then you get lots of lines like:
guestfsd: receive_file: reading length word
guestfsd: receive_file: got chunk: cancel = 0x0, len = 8192, buf =
0x560e1b866690
These lines come from the tar-in command. If it fails at that stage, maybe your
disk size is not large enough for your tarball and that's why it fails?
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#974539: aspcud: FTBFS agsinst boost_1.74
Package: aspcud Severity: important Tags: ftbfs Usertags: boost174 Dear maintainer, it was discovered that your package failed to build against boost_1.74. Logs can be found here [1]. Most relevant part is probably this: libcudf/src/dependency.cpp:476:85: error: _2 was not declared in this scope 476 | boost::sort(candidates, boost::bind(::edgeSort, this, _1, _2)); | ^~ It is planned to push boost_1.74 as the default version in Debian/Bullseye. [1] http://qa-logs.debian.net/2020/10/27-boost/boost/aspcud_1.9.4-2_unstable_boost.log Best regards Anton
Bug#974538:
It's quite interesting to submit a bug report without a working window manager, but I think this may be related to the commit https://salsa.debian.org/qt-kde-team/kde/kscreenlocker/-/commit/2320b40c8d6f3ba316c83a31bdba79dc8db6d208 not listing the symbol _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEvy . I am not sure if there are any other symbols which might be needed.
Bug#974533: new upstream (20201110 ) for RAPL/Platypus fixes
On Wed, 11 Nov 2020, Daniel Baumann wrote: > as you might be aware, Intel "just" released a new microcode release.. > containing amongst other things "fixes" for the RAPL/Platypus issues. I am preparing updated packages, yes. Regardless of whether one cares about SGX, the INTEL-SA-00381 fixes are relevant and so are the several critical errata fixes and regression fixes in this update. Unfortunately, *as expected*, this microcode update causes fail-to-boot issues on some platforms. I will delay the upload to Debian unstable a couple days to try to get a better picture of the possible collateral damage. Also, currently there are no plans of a fast-track security update for this microcode update. This decision was made in agreement with the Debian security team. -- Henrique Holschuh
Bug#967049: java.lang.IllegalArgumentException: Width and height must be >= 0 since upgrade to 11.0.8+10
Package: openjdk-11-jre Version: 11.0.9+11-1~deb10u1 Followup-For: Bug #967049 Also I don't think it ever occured to me before cca begining of Oct/2020 as my first report was this: https://josm.openstreetmap.de/ticket/19900 And it looks like I've only upgraded from 11.0.8+10-1~deb10u1 to 11.0.9+11-1~deb10u1 on 30.Oct.2020., so I can confirm bug was present in 11.0.8+10-1~deb10u1 too, but probably not in any earlier versions. So it looks like possible security.debian.org regression? % ls -l /var/log/dpkg.log* -rw-r--r-- 1 root root 68779 Nov 11 17:38 /var/log/dpkg.log -rw-r--r-- 1 root root 64403 Oct 31 01:14 /var/log/dpkg.log.1 -rw-r--r-- 1 root root 6676 Oct 11 17:31 /var/log/dpkg.log.2.gz -rw-r--r-- 1 root root 794 Sep 21 21:06 /var/log/dpkg.log.3.gz -rw-r--r-- 1 root root 2702 Sep 11 01:36 /var/log/dpkg.log.4.gz % zfgrep openj /var/log/dpkg.log* /var/log/dpkg.log.1:2020-10-30 05:19:40 upgrade openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-configured openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status unpacked openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-installed openjdk-11-jre:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status unpacked openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 upgrade openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-configured openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status unpacked openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:40 status half-installed openjdk-11-jre-headless:amd64 11.0.8+10-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 status unpacked openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 configure openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 status unpacked openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:51 status half-configured openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status installed openjdk-11-jre-headless:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 configure openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status unpacked openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status half-configured openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 /var/log/dpkg.log.1:2020-10-30 05:19:52 status installed openjdk-11-jre:amd64 11.0.9+11-1~deb10u1 -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages openjdk-11-jre depends on: ii libc62.28-10 ii libgif7 5.1.4-3 ii libgl1 1.1.0-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.36-6 ii libx11-6 2:1.6.7-1+deb10u1 ii libxext6 2:1.3.3-1+b2 ii openjdk-11-jre-headless 11.0.9+11-1~deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openjdk-11-jre recommends: ii fonts-dejavu-extra 2.37-1 pn libatk-wrapper-java-jni openjdk-11-jre suggests no packages. -- no debconf information
Bug#974538: libkscreenlocker5: kwin cannot start due to missing libkscreenunlocker5 symbols
Package: libkscreenlocker5 Version: 5.19.5-4 Severity: serious Justification: Policy 8.1 X-Debbugs-Cc: bunge...@chromium.org $ kwin --replace kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEvy $ ldd /lib/x86_64-linux-gnu/libkwin.so.5 libKScreenLocker.so.5 => /lib/x86_64-linux-gnu/libKScreenLocker.so.5 (0x7f0adc697000) -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/32 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libkscreenlocker5 depends on: ii kpackagetool5 5.74.0-2 ii libc6 2.31-4 ii libkf5configcore5 5.74.0-2 ii libkf5configgui5 5.74.0-2 ii libkf5coreaddons5 5.74.0-2 ii libkf5crash5 5.74.0-2 ii libkf5declarative5 5.74.0-2 ii libkf5globalaccel-bin 5.74.0-2 ii libkf5globalaccel5 5.74.0-2 ii libkf5i18n55.74.0-3 ii libkf5idletime55.74.0-2 ii libkf5notifications5 5.74.0-2 ii libkf5package5 5.74.0-2 ii libkf5quickaddons5 5.74.0-2 ii libkf5waylandclient5 4:5.74.0-2 ii libkf5waylandserver5 4:5.74.0-2 ii libkf5windowsystem55.74.0-2 ii libkf5xmlgui5 5.74.0-2+b1 ii libpam0g 1.3.1-5 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5dbus55.15.1+dfsg-2 ii libqt5gui5 5.15.1+dfsg-2 ii libqt5network5 5.15.1+dfsg-2 ii libqt5qml5 5.15.1+dfsg-3 ii libqt5quick5 5.15.1+dfsg-3 ii libqt5widgets5 5.15.1+dfsg-2 ii libqt5x11extras5 5.15.1-2 ii libseccomp22.4.4-1+b1 ii libstdc++6 10.2.0-16 ii libwayland-client0 1.18.0-2~exp1.1 ii libwayland-server0 1.18.0-2~exp1.1 ii libx11-6 2:1.6.12-1 ii libxcb-keysyms10.4.0-1+b2 ii libxcb11.14-2 ii libxi6 2:1.7.10-1 ii psmisc 23.3-1 Versions of packages libkscreenlocker5 recommends: ii kde-config-screenlocker 5.19.5-4 libkscreenlocker5 suggests no packages. -- no debconf information
Bug#974212: Info received (kwin-x11 crashes, windows missing decorations)
This seems to be resolved in 4:5.19.5-3
Bug#967049: java.lang.IllegalArgumentException: Width and height must be >= 0 since upgrade to 11.0.8+10
Package: openjdk-11-jre Version: 11.0.9+11-1~deb10u1 Followup-For: Bug #967049 Dear Maintainer, Same issue happened to me: https://josm.openstreetmap.de/ticket/20060 It happens only rarely for me so I can't reproduce at will unfortunately. I'm not using any DE, but icewm with X11 if it matters. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=hr_HR.UTF-8, LC_CTYPE=hr_HR.UTF-8 (charmap=UTF-8), LANGUAGE=hr_HR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages openjdk-11-jre depends on: ii libc62.28-10 ii libgif7 5.1.4-3 ii libgl1 1.1.0-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.36-6 ii libx11-6 2:1.6.7-1+deb10u1 ii libxext6 2:1.3.3-1+b2 ii openjdk-11-jre-headless 11.0.9+11-1~deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openjdk-11-jre recommends: ii fonts-dejavu-extra 2.37-1 pn libatk-wrapper-java-jni openjdk-11-jre suggests no packages. -- no debconf information
Bug#974164: marked as pending in devscripts
Mattia Rizzolo writes: > Bug #974164 in devscripts 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/debian/devscripts/-/commit/4164cdce33b5d668b0ae3435eaa7028c4d172590 Thanks! -- Brian May
Bug#974164: /usr/bin/debchange: hardcodes Jessie for --lts option
Mattia Rizzolo writes: > You should be able to do that with -D already. For the record, that only helps set the distribution field. The automatically generated version number is still wrong (+deb8u1 instead of +deb9u1). -- Brian May
Bug#974201: Now blocking
Hi, I advanced quite well since this morning, so right now getting node- rimraf up to date and with definitions is on the top of my todo list. I'll work locally at first, but will probably upload in a few days, unless it's a problem for you? Cheers
Bug#904723: Why is the last version of node-diff not in unstable?
Hi Jonas, you have uploaded 4.0.1 to experimental in august 2019 ; is there a reason why it didn't get into unstable? I ask because I want to work on shipping the TypeScript types with the package... and the definition are for v4. So basically, I want to work on the package, but don't want to step on your toes. Cheers, JP
Bug#974537: fonts-noto-core: Fallback font selection changed and incorrect glyph displayed
Package: fonts-noto-core Version: 20201109-1 Severity: normal Dear Maintainer, With version 20200323-1, when attempting to render code points such as 0x3001 and 0x3002, fontconfig would choose "Noto Sans CJK JP" [0] as fallback for "Monospace". This was expected behaviour, I want to see Japanese punctuation glyphs. 0: /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc Binary packages for version 20200323-1 seem to be gone from the archive but version 20181227-1 also shows the wanted behaviour. After updating to version 20201027-3 and later also 20201109-1, fontconfig chooses "Noto Sans Mongolian" [1]. This results in unintended glyphs. 1: /usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf STR: a) Run: $ LANG=en_US.UTF-8 pango-view --font monospace -t $'\u3001' Or even: $ LANG=en_US.UTF-8 pango-view -t $'\u3001' b) Run: $ fc-match --sort monospace family style file | grep -i -e cjk -e mongo Or even: $ fc-match --sort : family style file | grep -i -e cjk -e mongo Expected behaviour: a) The pango-view window shows the Japanese comma glyph (see for example "Noto Sans CJK JP" in fontforge). b) A Japanese font is preferred: Noto Sans CJK JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc Noto Sans Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf Actual behaviour: a) The pango-view window shows a different glyph (from "Noto Sans Mongolian"). b) A Mongolian font is preferred: Noto Sans Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf Noto Sans CJK JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc This looks like a regression and it is one for me, but I guess it could also be a configuration issue involving fontconfig. I have no custom fontconfig configuration, though, so if somehow this is not considered a regression, perhaps you could recommend a configuration that would restore the previous behaviour for me? Thanks. -- Package-specific info: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-=--= ii fontconfig 2.13.1-4.2amd64generic font configuration library - support binaries ii libfreetype6:amd64 2.10.2+dfsg-4 amd64FreeType 2 font engine, shared library files ii libxft2:amd64 2.3.2-2 amd64FreeType-based font drawing library for X -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#973472: fetchmail: Fails to connect using SSL
On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote: > On Fri, Nov 6, 2020 at 9:09 AM Michal Palenik wrote: > > for those stumbling on this via searching, the workaround mentioned > > above is: > [...] > > apt -t unstable install libssl1.1:amd64 > Thanks for possibly the best solution. Meanwhile OpenSSL 1.1.1h-1 > migrated to testing; closing this bug report. That is not a fix. Fetchmail should not be checking the version. The libssl1.1 package will ensure that the correct versioned depenencies are there. There might be cases that an older version than the one you compiled against might not work, when not using Debian's dependencies system, but in that case you'll get a linker error. Kurt
Bug#974490: lmod: autopkgtest must be marked superficial
Hi Aaron, On 11-11-2020 20:41, Aaron Zauner (azet) wrote: > Again: if you think it should be marked superficial that's fine by me. Yes please. Paul signature.asc Description: OpenPGP digital signature
Bug#953860: how to reproduce
On Tue, 14 Apr 2020 11:26:57 +1000 Russell Coker
wrote:
> On Saturday, 11 April 2020 5:19:00 PM AEST Michael Biebl wrote:
> > > type=AVC msg=audit(1586512443.135:71139): avc: granted { unlink
} for
> > > pid=293 comm="systemd-journal"
> > > name="
user-1001@165b61313e51499ab58ffd33d611e714--
> > > .journal" dev="sdb2" ino=2093618
> > > scontext=system_u:system_r:syslogd_t:s0
> > > tcontext=system_u:object_r:systemd_journal_t:s0 tclass=file
> > > type=AVC msg=audit(1586565837.001:94320): avc: granted { unlink
} for
> > > pid=293 comm="systemd-journal"
> > > name="
user-1001@165b61313e51499ab58ffd33d611e714--
> > > .journal" dev="sdb2" ino=2095421
> > > scontext=system_u:system_r:syslogd_t:s0
> > > tcontext=system_u:object_r:systemd_journal_t:s0 tclass=file
> >
> > Is another user/process accessing the journal file at the time the
> > delete happens?
>
> Not through any deliberate user action. I'm the only user of the
system and I
> wasn't running any journalctl command. Does systemd do such stuff
internally?
Can you please report this upstream at
https://github.com/systemd/systemd/issues and report back with the
issue number.
I'm not really familiar with SELinux to be able to make sense of those
log messages. Upstream might.
Thanks,
Michael
signature.asc
Description: This is a digitally signed message part
Bug#961694: Updating to 3.6 should solve this
With the release of libnitrokey 3.6 on September 19, this functionality now seems to be officially available upstream. The nitrokey-authenticator package which is an rdep for this mentions in its description "The application supports both, Nitrokey Pro2 and LibremKey. For the latter, however, you need to have libnitrokey version 3.6 or newer" (which is not yet packaged for Debian).
Bug#882210: RE: ITP: jgmenu -- simple modern standalone X11 menu
On Sun, 30 Aug 2020 16:39:36 -0300 Leandro Cunha wrote: > Hi, > > I intend to place this package in the official Debian archives. I am going > to be working on it according to the Debian Developer Reference and Debian > Policy. The bug has already been changed to ITP and it is now the > construction of this package for this to be completed. > Thanks! > > -- > Cheers, > Leandro Cunha > Debian Contributor, developer and student in Systems of Information course. Hi Leandro, what is the package upload status? I was going to pick up this bug for a while and upload this package into the repository as a replacement for openbox-menu, which is upstream dead. -- .''`. Mateusz Łukasik : :' : l0calh0st.pl `. `' Debian Member - mat...@linuxmint.pl `-GPG: D93B 0C12 C8D0 4D7A AFBC FA27 CCD9 1D61 11A0 6851
Bug#971760: systemd: Error messages about XDG autostart after logging in as root
On Wed, Nov 11, 2020 at 08:53:53PM +0100, Michael Biebl wrote: > Hi Kurt > > Am Freitag, den 16.10.2020, 09:57 +0200 schrieb Kurt Roeckx: > > On Thu, Oct 15, 2020 at 11:26:04PM +0200, Michael Biebl wrote: > > > Am 06.10.20 um 23:36 schrieb Kurt Roeckx: > > > > On Tue, Oct 06, 2020 at 10:57:12PM +0200, Michael Biebl wrote: > > > > > Am 06.10.20 um 22:53 schrieb Kurt Roeckx: > > > > > > > > > > > What I all mentioned in my initial email: > > > > > > - It gets logged to the kernel and console. > > > > > > > > > > I can't reproduce that. Do you have some custom syslog > > > > > configuration? > > > > > > > > I only seem to get it the first time I log in as root. > > > > > > I still have trouble reproducing the issue of getting those log > > > messages > > > on the console. > > > What kind of syslogger are you using? Can you share the complete > > > syslog > > > config? > > > > I'm using sysklogd. > > Given that sysklogd is no longer supported and available in the archive > since a few releases, I'm unable to reproduce the issue concerning the > error messages you get on the console. > > The error messages themselves have been tweaked significantly in 246.6- > 2. See [1]. > > Thus closing this issue. > > If you still get (unexpected) warning messages on the console with a > default Debian system using rsyslog, please reopen. I guess I still have sysklogd installed from when that was the default. I'll switch to rsyslog, and let you know on the next reboot. Kurt
Bug#974534: RFS: openbox-menu/0.8.0+hg20161009-2 [RC] -- openbox pipe-menu to display entries in *.desktop files
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "openbox-menu": * Package name: openbox-menu Version : 0.8.0+hg20161009-2 Upstream Author : [fill in name and email of upstream] * URL : https://bitbucket.org/fabriceT/openbox-menu * License : GPL-3+ * Vcs : https://github.com/mati75/openbox-menu.git Section : x11 It builds those binary packages: openbox-menu - openbox pipe-menu to display entries in *.desktop files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/openbox-menu/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/openbox-menu/openbox-menu_0.8.0+hg20161009-2.dsc Changes since the last upload: openbox-menu (0.8.0+hg20161009-2) unstable; urgency=medium . [ Helmut Grohne ] * Fix FTCBFS: Don't run tests during dh_auto_build. (Closes: #878370) . [ Mateusz Łukasik ] * Acknowledge NMU, thanks to Adrian Bunk. * Fix FTBFS with gcc-10. (Closes: #957633) * debian/control: + Bump Standards-Version to 4.5.0 + Bump dh version to 13. * debian/copyright: Welcome 2020. Regards, -- Mateusz Łukasik
Bug#962573: Include SRBDS Support
retitle 962573 new upstream (0.44) thanks Hi, there's a new version released now, which includes SRBDS. Regards, Daniel
Bug#974535: RFS: udevil/0.4.4-3 [RC] -- Alternative storage media interface
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "udevil": * Package name: udevil Version : 0.4.4-3 Upstream Author : [fill in name and email of upstream] * URL : https://ignorantguru.github.com/udevil/ * License : LGPL-2+, Makefile.in, permissive, GPL-3+ * Vcs : https://github.com/mati75/udevil.git Section : utils It builds those binary packages: udevil - Alternative storage media interface To access further information about this package, please visit the following URL: https://mentors.debian.net/package/udevil/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/u/udevil/udevil_0.4.4-3.dsc Changes since the last upload: udevil (0.4.4-3) unstable; urgency=medium . [ Debian Janitor ] * Trim trailing whitespace. * Use secure copyright file specification URI. * debian/copyright: use spaces rather than tabs to start continuation lines. * Depend on newer debhelper (>= 9.20160709) rather than dh-systemd. (Closes: #958609) * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse. * Drop unnecessary dh arguments: --with=systemd . [ Mateusz Łukasik ] * Bump dh version to 13 and drop compat file. * Bump Standards-Version to 4.5.0. (no changes needed) Regards, -- Mateusz Łukasik
Bug#974533: new upstream (20201110 ) for RAPL/Platypus fixes
Package: intel-microcode Severity: normal Hi Henrique as you might be aware, Intel "just" released a new microcode release.. containing amongst other things "fixes" for the RAPL/Platypus issues. Regards, Daniel
Bug#974427: ITP: chance -- It is a Utility library to generate anything random like strings, numbers, etc.
Package: wnpp Severity: wishlist Owner: Jobin J X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : chance Version : 1.1.7 Upstream Author : Victor Quinn * URL : https://github.com/chancejs/chancejs * License : Expat Programming Lang: JavaScript Description : It is a Utility library to generate anything random like strings, numbers, etc. Chance is a minimalist generator of random strings, numbers, etc. to help reduce some monotony particularly while writing automated tests or anywhere else you need anything random. Hi Debian Maintainers, chance is a utility library to generate random strings, numbers etc. It is a dependency of HedgeDoc (early name was CodiMD).The source link of the project is https://github.com/codimd The upstream of this chance is developed by Victor Quinn and licensed under Expat license.The upstream is available at https://github.com/chancejs/chancejs This debian package will be maintained by Debian JavaScript Team. I think this chance will be helpful for Debian Javascript team . Thanks, JOBIN J
Bug#973287: systemd autopkgtest-virt-lxc failure on arm64
Control: tags -1 + moreinfo upstream Am Mittwoch, den 28.10.2020, 17:56 +0900 schrieb Ryutaroh Matsumoto: > Source: systemd > Version: 246.6-2 > Severity: normal > X-Debbugs-Cc: debian-...@lists.debian.org > > Dear Maintainer, > > autopkgtest-virt-lxc abnormally exits on arm64 as follows. > It does not even print " summary" as usual. > (I used Raspberry Pi 4B running latest Debian testing, > and the kernel the genuine Debian package.) > The following error can be consistently reproduced. > > autopkgtest [14:33:32]: test boot-and-services: [-- > - > lxc > Removed /etc/systemd/system/default.target. > Created symlink /etc/systemd/system/default.target → > /lib/systemd/system/graphical.target. > bash: line 1: 5113 Killed /tmp/autopkgtest- > lxc.28n1_agf/downtmp/build.vKC/src/debian/tests/boot-and-services 2> > >(tee -a /tmp/autopkgtest-lxc.28n1_agf\ > /downtmp/boot-and-services-stderr >&2) > >(tee -a /tmp/autopkgtest- > lxc.28n1_agf/downtmp/boot-and-services-stdout) > autopkgtest [14:33:34]: test process requested reboot with marker > boot1 > : failure: timed out waiting for container autopkgtest- > lxc-udvsoo to start; last runlevel "unknown > " > autopkgtest [14:35:58]: ERROR: testbed failure: cannot send to > testbed: [Errno 32] Broken pipe > > > I also run autopkgtest-virt-lxc on all the packages with > Priority standard, and 95% of them were OK, so > autopkgtest-virt-lxc seems somewhat reliable on arm64, though arm64 > qemu > testbed cannot be built as > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038 > (I cannot exclude the possibility of bug in autopkgtest.) > > I note that autopkgtest-virt-lxc fails in glibc and glib2.0 on arm64 > as > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973271 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038 > > > Complete log of autopkgtest is attached as zip file. Unfortunately I lack the necessary hardware to reproduce this issue. Can you please forward this to upstream yourself at https://github.com/systemd/systemd It's likely that upstream has further questions which are best answered by you. Regards, Michael signature.asc Description: This is a digitally signed message part
Bug#974490: lmod: autopkgtest must be marked superficial
PS: I'm barely maintaining this package anymore due to the amount of work I have at the moment and me not working in the hpc sector anymore. But I get regular bug reports and fixes for this package. Lucas Nussbaum was asking around for a new maintainer, but while apparently quite a few people use it, no one wants to actively maintain it. Recently another person wrote me he maintains a current PPA for Ubuntu - I wasn't even aware of that. Aaron On Wed 11. Nov 2020 at 20:41, Aaron Zauner (azet) wrote: > Hi, > > > On 11.11.2020, at 20:30, Paul Gevers wrote: > > > > Hi Aaron, > > > >> On 11-11-2020 20:11, Sudip Mukherjee wrote: > >> Hi Aaron, > >> > >>> On Wed, Nov 11, 2020 at 7:02 PM Aaron Zauner (azet) > wrote: > >>> > >>> Hey, > >>> > >>> That command does load everything that lmod needs in terms of > dependencies and checks the environment. It's not a proper test suite but > none exists so far, and I think this is sufficient to see if there's any > bugs related to dependencies or the main function of the tool. writing a > empty module to test lmod won't be any more effective. > > > > I have no clue what lmod does. > > Loads different environments for different compilers, blas and other > libraries as toolchains for development, usually on high performance > computing systems. it's based on "environment modules" an old tool from the > HPC world that's very out of date but has a lot of modern and fast features > to change the environment to the toolchain you need to work with for eg > local development or sending cluster jobs. > > > > >> I think what you said exactly matches my description in the bug. :) > > > > So do I. > > > Executing that command is considered to be a trivial test, which > does not provide significant coverage for a package as a whole. > But these tests are a useful way to detect regressions in dependencies > and prevent them from breaking your package. > >> > >>> > >>> If you can find a better alternative I'm all in, this was the best I > could come up with when packaging initially. If you still think it should > be marked superficial please do so. > > > > So, can you elaborate why you think that this test is substantially > > testing your package. E.g. we have (for now) accepted that meta packages > > actually do not much more than testing dependencies? But e.g. Python > > modules or Node modules that just do an include are superficial. And so > > are all tests that just print the version number although that "load > > everything that X needs in terms of dependencies". These tests are > > valuable, except they are not enough to warrant the exception that we > > are giving packages with non-superficial tests during regular migration > > (reduced age) and the bullseye freeze (longer period of uploading > > without needing the release team). > > As I said I'm not aware that there's any test suite for lmod or I'd have > included it. Writing a dummy module for the system toolchain gcc glibc etc > won't really tell anything useful about lmod itself. Again: if you think it > should be marked superficial that's fine by me. > > Aaron > > > > > Paul > > >
Bug#974490: lmod: autopkgtest must be marked superficial
Hi, > On 11.11.2020, at 20:30, Paul Gevers wrote: > > Hi Aaron, > >> On 11-11-2020 20:11, Sudip Mukherjee wrote: >> Hi Aaron, >> >>> On Wed, Nov 11, 2020 at 7:02 PM Aaron Zauner (azet) wrote: >>> >>> Hey, >>> >>> That command does load everything that lmod needs in terms of dependencies >>> and checks the environment. It's not a proper test suite but none exists so >>> far, and I think this is sufficient to see if there's any bugs related to >>> dependencies or the main function of the tool. writing a empty module to >>> test lmod won't be any more effective. > > I have no clue what lmod does. Loads different environments for different compilers, blas and other libraries as toolchains for development, usually on high performance computing systems. it's based on "environment modules" an old tool from the HPC world that's very out of date but has a lot of modern and fast features to change the environment to the toolchain you need to work with for eg local development or sending cluster jobs. > >> I think what you said exactly matches my description in the bug. :) > > So do I. > Executing that command is considered to be a trivial test, which does not provide significant coverage for a package as a whole. But these tests are a useful way to detect regressions in dependencies and prevent them from breaking your package. >> >>> >>> If you can find a better alternative I'm all in, this was the best I could >>> come up with when packaging initially. If you still think it should be >>> marked superficial please do so. > > So, can you elaborate why you think that this test is substantially > testing your package. E.g. we have (for now) accepted that meta packages > actually do not much more than testing dependencies? But e.g. Python > modules or Node modules that just do an include are superficial. And so > are all tests that just print the version number although that "load > everything that X needs in terms of dependencies". These tests are > valuable, except they are not enough to warrant the exception that we > are giving packages with non-superficial tests during regular migration > (reduced age) and the bullseye freeze (longer period of uploading > without needing the release team). As I said I'm not aware that there's any test suite for lmod or I'd have included it. Writing a dummy module for the system toolchain gcc glibc etc won't really tell anything useful about lmod itself. Again: if you think it should be marked superficial that's fine by me. Aaron > > Paul >
Bug#974532: src:libctl: fails to migrate to testing for too long: FTBFS
Source: libctl Version: 4.5.0-4 Severity: serious Control: close -1 4.5.0-5 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 970233 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:libctl 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=libctl signature.asc Description: OpenPGP digital signature
Bug#974490: lmod: autopkgtest must be marked superficial
Hi Aaron, On 11-11-2020 20:11, Sudip Mukherjee wrote: > Hi Aaron, > > On Wed, Nov 11, 2020 at 7:02 PM Aaron Zauner (azet) wrote: >> >> Hey, >> >> That command does load everything that lmod needs in terms of dependencies >> and checks the environment. It's not a proper test suite but none exists so >> far, and I think this is sufficient to see if there's any bugs related to >> dependencies or the main function of the tool. writing a empty module to >> test lmod won't be any more effective. I have no clue what lmod does. > I think what you said exactly matches my description in the bug. :) So do I. >>> Executing that command is considered to be a trivial test, which >>> does not provide significant coverage for a package as a whole. >>> But these tests are a useful way to detect regressions in dependencies >>> and prevent them from breaking your package. > >> >> If you can find a better alternative I'm all in, this was the best I could >> come up with when packaging initially. If you still think it should be >> marked superficial please do so. So, can you elaborate why you think that this test is substantially testing your package. E.g. we have (for now) accepted that meta packages actually do not much more than testing dependencies? But e.g. Python modules or Node modules that just do an include are superficial. And so are all tests that just print the version number although that "load everything that X needs in terms of dependencies". These tests are valuable, except they are not enough to warrant the exception that we are giving packages with non-superficial tests during regular migration (reduced age) and the bullseye freeze (longer period of uploading without needing the release team). Paul signature.asc Description: OpenPGP digital signature
Bug#974344: don't display "Debci reports failed tests" for outdated package versions
On Wed, 11 Nov 2020 15:08:47 +0100, Matthias Klose wrote: > doko: because that's the latest test result available; if britney > didn't schedule a "pure unstable" test, then you don't get one. due to > capacity > limitations we stopped scheduling pure unstable tests automatically As an unsolicited side note, I found the quick "pure unstable" tests extremely helpful for catching regressions in reverse dependencies early, and I hope the resource issues can be fixed in order to re-enable them at some point. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: St Louis Jimmy Oden: Florida hurricane signature.asc Description: Digital Signature
Bug#957369: ipband: diff for NMU version 0.8.1-5.1
Control: tags 957369 + patch Control: tags 957369 + pending -- Dear maintainer, I've prepared an NMU for ipband (versioned as 0.8.1-5.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it. -- Regards Sudip diff -Nru ipband-0.8.1/debian/changelog ipband-0.8.1/debian/changelog --- ipband-0.8.1/debian/changelog 2016-12-06 14:13:55.0 + +++ ipband-0.8.1/debian/changelog 2020-11-11 19:11:52.0 + @@ -1,3 +1,10 @@ +ipband (0.8.1-5.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix ftbfs with GCC-10. (Closes: #957369) + + -- Sudip Mukherjee Wed, 11 Nov 2020 19:11:52 + + ipband (0.8.1-5) unstable; urgency=low * Step up to Standards version 3.9.8, no changes. diff -Nru ipband-0.8.1/debian/patches/07_fix_gcc-10.patch ipband-0.8.1/debian/patches/07_fix_gcc-10.patch --- ipband-0.8.1/debian/patches/07_fix_gcc-10.patch 1970-01-01 01:00:00.0 +0100 +++ ipband-0.8.1/debian/patches/07_fix_gcc-10.patch 2020-11-11 19:02:50.0 + @@ -0,0 +1,123 @@ +Description: Fix ftbfs with GCC-10 + +Author: Sudip Mukherjee +Bug-Debian: https://bugs.debian.org/957369 +Forwarded: no + +--- + +--- ipband-0.8.1.orig/ipband.h ipband-0.8.1/ipband.h +@@ -174,40 +174,40 @@ Global variables + extern char pcap_version[]; + + /* Internal use */ +-intisig_m;/* Interupt flag for capture loop */ +-intpreload_m; /* Subnets are preloaded flag */ +-char *pcapdev_m;/* Device to listen to */ +-pcap_t *pcapfile_m; /* Pcap input file descriptor */ +-intpcapoffset_m; /* IP header offset */ +-time_t started_m; /* Time when we started */ ++extern intisig_m; /* Interupt flag for capture loop */ ++extern intpreload_m; /* Subnets are preloaded flag */ ++extern char *pcapdev_m; /* Device to listen to */ ++extern pcap_t *pcapfile_m;/* Pcap input file descriptor */ ++extern intpcapoffset_m; /* IP header offset */ ++extern time_t started_m; /* Time when we started */ + +-ll_srvc_t *ll_tcp_cache; /* Resolved tcp services cache */ +-ll_srvc_t *ll_udp_cache; /* Resolved udp services cache */ ++extern ll_srvc_t *ll_tcp_cache; /* Resolved tcp services cache */ ++extern ll_srvc_t *ll_udp_cache; /* Resolved udp services cache */ + + + /* Variables holding option values */ +-intdebug_m; /* Debug option */ +-intdo_html; /* Generate HTML output */ +-char *filtercmd_m; /* Pcap filter string */ +-char *repfname_m; /* Subnet report output file */ +-char *htmlfname_m; /* HTML report output file */ +-char *htmltitle_m; /* HTML Title */ +-intmask_m;/* Network aggregation mask bits */ +-intcycle_m; /* Number of sec to average data */ +-intrcycle_m; /* How long in sec bandwidth ++extern intdebug_m;/* Debug option */ ++extern intdo_html;/* Generate HTML output */ ++extern char *filtercmd_m; /* Pcap filter string */ ++extern char *repfname_m;/* Subnet report output file */ ++extern char *htmlfname_m; /* HTML report output file */ ++extern char *htmltitle_m; /* HTML Title */ ++extern intmask_m; /* Network aggregation mask bits */ ++extern intcycle_m;/* Number of sec to average data */ ++extern intrcycle_m; /* How long in sec bandwidth + threshold may be exceeded */ +-float thresh_m; /* Bandwidth threshold in kBps */ +-intfork_m;/* Fork flag */ +-inttop_m; /* No of top connections in report */ +-char *config_m; /* Config file name */ +-char *mailto_m; /* E-mail address for reporting */ +-char *mailfoot_m; /* Footer file for e-mail report */ +-char *mtastring_m; /* MTA command string */ +-intreport_aggr_m; /* Flag to report aggr exceed time */ +-intpromisc_m; /* Use promiscious mode? */ +-int*iplist_m; /* List of local networks */ +-intniplist_m; /* Number of local networks */ +-intlenadj_m; /* IP packet length adjustment in bytes */ ++extern float thresh_m; /* Bandwidth threshold in kBps */ ++extern intfork_m; /* Fork flag */ ++extern inttop_m; /* No of top connections in report */ ++extern char *config_m; /* Config file name */ ++extern char *mailto_m; /* E-mail address for reporting */ ++extern char *mailfoot_m;/* Footer file for e-mail report */ ++extern char *mtastring_m; /* MTA command string */
Bug#974096: golang-github-c-bata-go-prompt: autopkgtest regression: cannot use (type *unix.Termios) as type *syscall.Termios in argument to termios.Tcgetattr
Hi Aloïs, On 10-11-2020 23:31, Aloïs Micard wrote: > I've now read the documentation here [1]. Hmm, I don't think that page describes your situation. [POLICY] looks more appropriate. [POLICY] https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks > Just to confirm, does the following changes > looks goods to you? > > - I'll add the following to d/control of golang-github-pkg-term > > ``` > Breaks: golang-github-c-bata-go-prompt (<<0.2.3+git20181109.b6d2b43-2), > golang-github-jaguilar-vt100 (<<0.0~git20201024.81de19c-1) > ``` Yes. Depending on how you support backports or other schemes, you could add a tilde (~) at the end. > (the version indicated here are the newest that haven't migrated to > testing) I assume you have the right version. > - And made a new release + upload it to unstable. > > To sum up: > > Is declaring that new version of golang-github-pkg-term breaks > old version of golang-github-c-bata-go-prompt & > golang-github-jaguilar-vt100 > enough to make the 3 packages migrate to testing? If nothing else is broken, yes. The migration software will trigger the autopkgtests together with such a relation. Paul
Bug#974531: krb5: Please include upstream fix "Unregister thread key in SPNEGO finalization"
Package: krb5 Version: 1.17-10 Hi maintainers, We're affected by the bug fixed in this upstream krb5 commit: https://github.com/krb5/krb5/commit/07ff54d0 I'm mostly filing this because we want this patch in Stretch LTS, but I think the process for that is including it in Sid and Buster first. I see that the patch is included in the latest 1.18 upload to experimental. It was backported to upstream's 1.17 branch here: https://github.com/krb5/krb5/commit/994f5f51 but 1.17.2 hasn't been released yet. I'd be happy to help by providing debdiffs or packages to sponsor or whatever if that's useful, but I'm guessing I should just wait for 1.17.2 to be released and reach unstable, and then file bugs for Buster and Stretch LTS? Thanks, -- Geoffrey Thomas geo...@twosigma.com
Bug#974530: SyntaxWarning: "is not" with a literal. Did you mean "!="?
Package: bleachbit
Version: 3.9.0-1
Severity: normal
Dear Maintainer,
On the current daily apt-get update && apt-get dist-upgrade I got some
SyntaxWarnings:
Setting up python3 (3.8.6-1) ...
running python rtupdate hooks for python3.8...
/usr/share/bleachbit/bleachbit/__init__.py:260: SyntaxWarning: "is not" with a
literal. Did you mean "!="?
if msgctxt is not None and msgctxt is not "":
/usr/share/dstat/dstat_mysql_keys.py:41: SyntaxWarning: 'str' object is not
callable; perhaps you missed a comma?
if op.debug > 1: print('%s: exception' (self.filename, e))
/usr/share/dstat/dstat_squid.py:48: SyntaxWarning: 'str' object is not
callable; perhaps you missed a comma?
if op.debug > 1: print('%s: exception' (self.filename, e))
Thanks in advance
xiscu
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing'), (10, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bleachbit depends on:
ii gir1.2-gtk-3.03.24.23-2
ii libgtk-3-03.24.23-2
ii policykit-1 0.105-29
ii python3 3.8.6-1
ii python3-chardet 3.0.4-7
ii python3-gi3.38.0-1+b1
ii python3-requests 2.24.0+dfsg-1
bleachbit recommends no packages.
bleachbit suggests no packages.
-- no debconf information
Bug#972070: bluez-obexd: Failure to browse files, Failed to execute program org.bluez.obex: No such file or directory
I noticed the same bug when file transfer via BT would not work anymore. Some research brought up a very similar, resolved bug in the Gentoo bug tracker [1]. The cause of the problem appears to be a non-working placeholder in the binary path of the obex service file (/usr/share/dbus-1/services/org.bluez.obex.service): > Exec=@libexecdir@/obexd instead of > Exec=/usr/lib/bluetooth/obexd [1] https://bugs.gentoo.org/show_bug.cgi?id=698394#c6 Regards, Jan
Bug#974529: gnumed-client: new upstream available
Package: gnumed-client Version: 1.8.3+dfsg-1 Severity: wishlist Tags: upstream Dear maintainers, upstream has released 1.8.4 which fixes a few bugs. We kindly ask for packaging, as time allows. This also applies to gnumed-server. Is there anything we can do to fix the watchfile ? Thanks, Karsten -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug') Architecture: i386 (i686) Kernel: Linux 5.9.0-1-686-pae (SMP w/2 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnumed-client depends on: ii aspell 0.60.8-1 ii file 1:5.38-5 ii gnumed-common1.8.3+dfsg-1 ii hunspell 1.7.0-3 ii imagemagick 8:6.9.11.24+dfsg-1+b1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.24+dfsg-1+b1 ii ispell 3.4.00-8 ii python3 3.8.6-1 ii python3-enchant 3.0.1-1 ii python3-gnuplot 1.8-8 ii python3-hl7 0.4.1-1 ii python3-httplib2 0.18.1-1 ii python3-lxml 4.6.1-1 ii python3-pip 20.1.1-2 ii python3-psutil 5.7.3-1 ii python3-pyudev 0.21.0-3 ii python3-wxgtk4.0 4.0.7+dfsg-6+b1 ii texlive-latex-base 2020.20200925-1 Versions of packages gnumed-client recommends: ii aeskulap0.2.2-beta2+git20190406.ef77f01-3 ii amide 1.0.5-13+b1 ii audiofile-tools 0.3.6-5 ii chktex 1.7.6-3 ii dcmtk 3.6.4-2.1+b1 ii elinks [www-browser]0.13.2-1 ii extract 1:1.10-1 ii firefox-esr [www-browser] 78.3.0esr-2 ii ginkgocadx 3.8.8-4 ii gnumed-doc 1.8.3+dfsg-1 ii gpg 2.2.20-1 ii gtklp 1.3.1-1 ii konqueror [www-browser] 4:20.04.3-1 ii lacheck 1.26-17 ii libimage-exiftool-perl 12.09+dfsg-1 ii libreoffice-writer 1:7.0.3-3 ii ntp 1:4.2.8p15+dfsg-1 ii p7zip-full 16.02+dfsg-8 pn pdftk ii poppler-utils 20.09.0-3 ii printer-driver-cups-pdf [cups-pdf] 3.0.1-6 ii python3-docutils0.16+dfsg-3 ii python3-pyqrcode1.2.1-4 ii python3-unidecode 1.1.1-3 ii python3-vobject 0.9.6.1-0.2 ii qpdf10.0.3-1 ii texlive-latex-extra 2020.20200925-1 ii texlive-latex-recommended 2020.20200925-1 ii w3m [www-browser] 0.5.3-38+b1 ii wgerman-medical 20160103-4 ii xdg-utils 1.1.3-2 ii xmedcon 0.16.2+dfsg-1 ii xsane 0.999-9 Versions of packages gnumed-client suggests: pn autokey-qt | autokey-gtk ii edfbrowser 1.79+dfsg-1 ii entangle3.0-1+b1 pn freediams pn gimp | kolourpaint4 ii gnumed-server 22.13-1 ii incron 0.5.12-2 pn konsolekalendar pn korganizer ii libchipcard-tools 5.1.5rc2-4 ii nvram-wakeup1.1-4+b1 pn pgadmin3 ii python3-uno 1:7.0.3-3 ii qrisk2 0.1.20150729-5 pn shutdown-at-night pn wakeonlan | etherwake | gwakeonlan -- no debconf information
Bug#913345: Video seek causes video track to lag when the "Hurry up" setting is not enabled in VLC 3.X
As I already reported in the upstream bug: I tested this again with VLC 3.0.11 on Debian 9.13 and 10.6 and video seek seems to work fine now. However, I am not sure which exact VLC version resolved my problem (it could be any of the following versions: 3.0.7, 3.0.8, 3.0.10 or 3.0.11). Anyway, feel free to close the bug. Regards, Bakhelit
Bug#974528: Regression: built-in ethernet on PINE A64+ stopped working (dwmac-sun8i)
Package: src:linux Version: 5.9.1-1 Severity: important X-Debbugs-Cc: andreimpope...@gmail.com Dear Maintainers, Everything appears to be fine (link is up, address assigned, etc.) yet ping, wget, etc. all time out. Same issue also with 5.9.6-1 while 5.8.14-1 and previous versions work fine. Kind regards, Andrei -- Package-specific info: ** Version: Linux version 5.9.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.9.1-1 (2020-10-17) ** Command line: root=LABEL=pb64p rootwait rw rootflags=noatime ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 11.264769] systemd[1]: Listening on Journal Socket. [ 11.293028] systemd[1]: Listening on Network Service Netlink Socket. [ 11.324904] systemd[1]: Listening on udev Control Socket. [ 11.356578] systemd[1]: Listening on udev Kernel Socket. [ 11.390069] systemd[1]: Mounting Huge Pages File System... [ 11.426027] systemd[1]: Mounting POSIX Message Queue File System... [ 11.461564] systemd[1]: Mounting NFSD configuration filesystem... [ 11.501742] systemd[1]: Mounting RPC Pipe File System... [ 11.543167] systemd[1]: Mounting Kernel Debug File System... [ 11.578157] systemd[1]: Mounting Kernel Trace File System... [ 11.608230] systemd[1]: Condition check resulted in Kernel Module supporting RPCSEC_GSS being skipped. [ 11.638763] systemd[1]: Starting Set the console keyboard layout... [ 11.678568] systemd[1]: Starting Create list of static device nodes for the current kernel... [ 11.695407] RPC: Registered named UNIX socket transport module. [ 11.717285] RPC: Registered udp transport module. [ 11.717289] RPC: Registered tcp transport module. [ 11.717291] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 11.794544] systemd[1]: Starting Load Kernel Module drm... [ 11.827394] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [ 11.858512] systemd[1]: Starting Journal Service... [ 11.972471] systemd[1]: Starting Load Kernel Modules... [ 12.017036] systemd[1]: Starting Remount Root and Kernel File Systems... [ 12.050318] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 12.089900] systemd[1]: Starting Coldplug All udev Devices... [ 12.134653] systemd[1]: Mounted Huge Pages File System. [ 12.165035] systemd[1]: Mounted POSIX Message Queue File System. [ 12.197041] systemd[1]: Mounted NFSD configuration filesystem. [ 12.229460] systemd[1]: Mounted RPC Pipe File System. [ 12.260981] systemd[1]: Started Journal Service. [ 13.029351] random: crng init done [ 13.043435] random: 7 urandom warning(s) missed due to ratelimiting [ 13.423065] fuse: init (API version 7.31) [ 13.455286] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) [ 13.550228] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null) [ 13.576018] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null) [ 14.072349] audit: type=1400 audit(1605103249.756:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=261 comm="apparmor_parser" [ 14.113776] audit: type=1400 audit(1605103249.756:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=262 comm="apparmor_parser" [ 14.142128] audit: type=1400 audit(1605103249.756:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=262 comm="apparmor_parser" [ 14.180524] audit: type=1400 audit(1605103249.756:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=263 comm="apparmor_parser" [ 14.214473] audit: type=1400 audit(1605103249.756:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=263 comm="apparmor_parser" [ 14.240863] audit: type=1400 audit(1605103249.756:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=263 comm="apparmor_parser" [ 14.745315] sunxi-wdt 1c20ca0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) [ 14.780462] mc: Linux media interface: v0.10 [ 14.781214] sun8i-ce 1c15000.crypto: Set mod clock to 3 (300 Mhz) from 2400 (24 Mhz) [ 14.824192] sun8i-ce 1c15000.crypto: will run requests pump with realtime priority [ 14.842889] sun8i-ce 1c15000.crypto: will run requests pump with realtime priority [ 14.871585] sun8i-ce 1c15000.crypto: will run requests pump with realtime priority [ 14.888372] sun8i-ce 1c15000.crypto: will run requests pump with realtime priority [ 14.909217] sun8i-ce 1c15000.crypto: Register cbc(aes) [ 14.966708] videodev: Linux video capture interface: v2.00 [ 15.098064] lima 1c4.gpu: gp - mali400 version major 1 minor 1 [ 15.110923] lima 1c4.gpu: pp0 - mali400 version major 1 minor 1 [ 15.123213] lima 1c4.gpu: pp1 - mali400
Bug#974527: add changelog merger
Package: python3-debmutate Version: 0.13 Severity: wishlist It would be useful if debmutate provided a way to do a three-way merge of changelogs. Some work in progress in https://salsa.debian.org/jelmer/debmutate/-/tree/changelog-merge -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-debmutate depends on: ii python3 3.8.6-1 ii python3-debian 0.1.38 python3-debmutate recommends no packages. python3-debmutate suggests no packages. -- no debconf information
Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles
I'm experiencing this as well. I've installed webext-ublock-origin-firefox, and each time I restart the browser, uBlock Origin isn't enabled (no toolbar icon, and ads not blocked) until I go into about:addons and toggle it off and back on. HTTPS Everywhere, installed via the upstream addon mechanism, seems to function just fine after a restart. So this does seem specific to system addons.
Bug#974132: dak: fail to upgrade database to 125
Control: tag -1 + moreinfo
Christian Marillat writes:
> dak@christian ~ % dak update-db
> Determining dak database revision ...
> dak database schema at 124
> dak version requires schema 125
>
> Updates to be applied:
> Traceback (most recent call last):
> File "/usr/bin/dak", line 254, in
> main()
> File "/usr/bin/dak", line 233, in main
> module.main()
> File "/usr/lib/python3/dist-packages/dak/update_db.py", line 252, in main
> app.init()
> File "/usr/lib/python3/dist-packages/dak/update_db.py", line 240, in init
> self.update_db()
> File "/usr/lib/python3/dist-packages/dak/update_db.py", line 177, in
> update_db
> dakdb = __import__("dakdb", globals(), locals(), ['update' + str(i)])
> ModuleNotFoundError: No module named 'dakdb'
You seem to have patched dak to install somewhere. It works with the
non-installed version (at least the CI system is happy), so I suspect
this is related to your changes.
Possibly also Python 3 changes to import are also relevant (the
absolut_import stuff).
I'm tagging this moreinfo for now.
Ansgar
Bug#974212: kwin-x11 crashes, windows missing decorations
Hello I have similar behaviour and I have managed to capture the backtrace from the fault (below). Let me know if I can help with anything else. Thanks Tim Backtrace Application: KWin (kwin_x11), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f4bf57d78c0 (LWP 143875))] Thread 4 (Thread 0x7f4beebe8700 (LWP 143888)): #0 futex_abstimed_wait_cancelable (private=0, abstime=0x7f4beebe7c50, clockid=-289506352, expected=0, futex_word=0x55f64fc93484) at ../sysdeps/nptl/futex-internal.h:320 #1 __pthread_cond_wait_common (abstime=0x7f4beebe7c50, clockid=-289506352, mutex=0x55f64fc93430, cond=0x55f64fc93458) at pthread_cond_wait.c:520 #2 __pthread_cond_timedwait (cond=0x55f64fc93458, mutex=0x55f64fc93430, abstime=0x7f4beebe7c50) at pthread_cond_wait.c:656 #3 0x7f4bfbc52aa4 in QWaitCondition::wait(QMutex*, QDeadlineTimer) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f4bfbc50ae1 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f4bfbc4cb01 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f4bfb06aea7 in start_thread (arg=) at pthread_create.c:477 #7 0x7f4bfd3ead4f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7f4be700 (LWP 143880)): #0 0x7f4bfd3e0456 in __ppoll (fds=0x7f4be800d0b8, nfds=1, timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:44 #1 0x7f4bfbe7f779 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #2 0x7f4bfbe80e13 in QEventDispatcherUNIX::processEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x7f4bfbe2ab7b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f4bfbc4b9be in QThread::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f4bfa18ba27 in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5 #6 0x7f4bfbc4cb01 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f4bfb06aea7 in start_thread (arg=) at pthread_create.c:477 #8 0x7f4bfd3ead4f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f4bf50d7700 (LWP 143878)): #0 0x7f4bfd3e035f in __GI___poll (fds=0x7f4bf50d6be8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f4bfbb62d02 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1 #2 0x7f4bfbb6498a in xcb_wait_for_event () from /lib/x86_64-linux-gnu/libxcb.so.1 #3 0x7f4bf53f4260 in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #4 0x7f4bfbc4cb01 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f4bfb06aea7 in start_thread (arg=) at pthread_create.c:477 #6 0x7f4bfd3ead4f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f4bf57d78c0 (LWP 143875)): [KCrash Handler] #4 0x7f4bfbccdef0 in QString::operator=(QString const&) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f4bfd0fd10c in ?? () from /lib/x86_64-linux-gnu/libkwin.so.5 #6 0x7f4bee034910 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/org.kde.kdecoration2/breezedecoration.so #7 0x7f4bee0387f9 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/org.kde.kdecoration2/breezedecoration.so #8 0x7f4bee038a28 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/org.kde.kdecoration2/breezedecoration.so #9 0x7f4bfd0fed52 in KWin::Decoration::DecorationBridge::createDecoration(KWin::AbstractClient*) () from /lib/x86_64-linux-gnu/libkwin.so.5 #10 0x7f4bfd0d34cc in KWin::Client::createDecoration(QRect const&) () from /lib/x86_64-linux-gnu/libkwin.so.5 #11 0x7f4bfd0d7758 in KWin::Client::updateDecoration(bool, bool) () from /lib/x86_64-linux-gnu/libkwin.so.5 #12 0x7f4bfd16b246 in KWin::Client::manage(unsigned int, bool) () from /lib/x86_64-linux-gnu/libkwin.so.5 #13 0x7f4bfd2079a5 in KWin::Workspace::createClient(unsigned int, bool) () from /lib/x86_64-linux-gnu/libkwin.so.5 #14 0x7f4bfd20ba1f in KWin::Workspace::initWithX11() () from /lib/x86_64-linux-gnu/libkwin.so.5 #15 0x7f4bfd20cd51 in KWin::Workspace::init() () from /lib/x86_64-linux-gnu/libkwin.so.5 #16 0x7f4bfd20d56d in KWin::Workspace::Workspace(QString const&) () from /lib/x86_64-linux-gnu/libkwin.so.5 #17 0x7f4bfd168054 in KWin::Application::createWorkspace() () from /lib/x86_64-linux-gnu/libkwin.so.5 #18 0x7f4bfd4b9e6c in ?? () from /lib/x86_64-linux-gnu/libkdeinit5_kwin_x11.so #19 0x7f4bfbe62796 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #20 0x7f4bfd4ba2cc in ?? () from /lib/x86_64-linux-gnu/libkdeinit5_kwin_x11.so #21 0x7f4bfbe62796 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #22 0x7f4bfce44633 in ?? () from /lib/x86_64-linux-gnu/libKF5WindowSystem.so.5 #23 0x7f4bfbe5811f in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #24 0x7f4bfc8ee14f in
Bug#466946: Bug#504044: On starting (and stopping) rngd
Hi Neil, >First, regarding the rng-tools version looks rather out of date. From what yes. As I explicitly wrote in the first message, this is about the *heavily* patched “Debian classic” version of rng-tools 2.x; the package with 5.x is called rng-tools5 currently, and updating it is tracked elsewhere¹. >I'd strongly suggest updating to the latest >version to avoid some of the problems described in the bug As stated multiple times², “updating” is actually a major loss of functionality and therefore not possible for many users, which is why rng-tools-debian contains the heavily patched old version. It’s basically a fork. (Feel free to merge those patches upstream, or, considering the drift, it’d probably be more like, reimplement the same functionality with the same options on top of the newer upstream version.) Until then, the entirety(!) of this thread is about rng-tools 2.x. >As for the question regarding starting rngd on multiple cores, I can't No, this would also apply to single cores. The question is about starting rngd multiple times, for example if there are multiple entropy sources, or rather, if the start is controlled by different causes. For example, one is started at boot and uses virtio-rng, another is started by udev when the WLAN chip containing an RNG comes online, and a third is started manually in a pipe with stunnel to retrieve entropy from a central server over the network. (Worst-case scenario, I guess.) Basically… does the Linux kernel take incoming entropy from all three instances? (The -W flag probably needs to be the same…) Does it hurt any, or does it help any? bye, //mirabilos ① https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922677 in the package rng-tools5, which is maintained by a completely different person as well, so I can’t comment on it ② in https://bugs.launchpad.net/ubuntu/+source/rng-tools/+bug/1333293 first, but also multiple times in #951799 and #919893 -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Bug#974112: Bug Package: kwin-x11 Source: kwin Version: 4:5.17.5-4
Hi, I also had to downgrade the lib: *libkscreenlocker5.* 1. wget ' https://snapshot.debian.org/archive/debian/20201030T214408Z/pool/main/k/kdecoration/libkdecorations2-5v5_5.17.5-2_amd64.deb ' 2. wget https://snapshot.debian.org/archive/debian/20201030T214408Z/pool/main/libk/libkscreen/libkf5screen-bin_5.17.5-3_amd64.deb 3. wget https://snapshot.debian.org/archive/debian/20201030T214408Z/pool/main/libk/libkscreen/libkf5screen7_5.17.5-3_amd64.deb 4. wget https://snapshot.debian.org/archive/debian/20200215T052412Z/pool/main/k/kscreenlocker/libkscreenlocker5_5.17.5-2_amd64.deb 5. sudo dpkg -i ./libk*.deb 6. reboot Ciao *Negiot* Special Thanks to *Sherpya* for libkscreenlocker5. https://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=sherpya%40netfarm.it
Bug#974434: RM: python3-antlr3 -- ROM; Not needed anymore if removing Congress
Package: ftp.debian.org Severity: normal Hi, If we remove congress (which I just asked in #974433), then there's no need for python3-antlr3 either, so let's please get this one removed from Debian as well (before Bullseye). Cheers, Thomas Goirand (zigo)
Bug#974433: RM: congress -- ROM; No longer maintained upstream, FTBFS
Package: ftp.debian.org Severity: normal Hi, Unfortunately, Congress isn't maintained upstream, and it cannot build anymore. Please remove it from the archive, as I cannot maintain it without upstream support. Cheers, Thomas Goirand (zigo)
Bug#974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway
Samuel Thibault, le mer. 11 nov. 2020 18:36:21 +0100, a ecrit: > Ben Hutchings, le mer. 11 nov. 2020 17:02:11 +, a ecrit: > > On Wed, 2020-11-11 at 11:25 +0200, Harald Hannelius wrote: > > > I needed to enter an IPv6-address in the installer. When entering > > > fe80::1 as a gateway the installer stops with an error that the > > > address isn't reachable. The address fe80::1 is indeed a valid > > > address for a gateway. > > > > No, this is a link-local address so you have to also specify the > > interface name, e.g. "fe80::1%eth0", > > Mmm, but in manual network configuration we already select the interface > in a previous question, don't we? (meaning we shouldn't have to specify it again, plus in some hardware cases the interface name is really complex so we really don't want to make the user have to type it) Samuel
Bug#974206: closed by Ben Hutchings (Re: Bug#974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway)
On Wed, 11 Nov 2020, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the debian-installer package: #974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway It has been closed by Ben Hutchings . No, this is a link-local address so you have to also specify the interface name, e.g. "fe80::1%eth0", The installer could then give a hint that %eth0 should be added, or any interface name that was used in the previous step when the interface got it's IP-address. The user doesn't know the correct name for the interface at that stage, it might be ens3, eth0, wlan0, eno1, wlp1s3 or something else. I can't remember when I have had to add the interface name to the gateway since this configuration is usually added in the context of the interface being configured. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
Bug#974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway
Ben Hutchings, le mer. 11 nov. 2020 17:02:11 +, a ecrit: > On Wed, 2020-11-11 at 11:25 +0200, Harald Hannelius wrote: > > I needed to enter an IPv6-address in the installer. When entering > > fe80::1 as a gateway the installer stops with an error that the > > address isn't reachable. The address fe80::1 is indeed a valid > > address for a gateway. > > No, this is a link-local address so you have to also specify the > interface name, e.g. "fe80::1%eth0", Mmm, but in manual network configuration we already select the interface in a previous question, don't we? Samuel
Bug#974432: xfce4-notifyd fails to start in ssh session; long timeout
Package: xfce4-notifyd Version: 0.4.3-1 Severity: normal (Possibly related to #899377, but that report isn't about remote sessions.) When dbus-daemon tries to start xfce4-notifyd from within an ssh session (with X forwarding), this fails after a 2-minute timeout. Typical log entries: Nov 11 16:57:49 HOST systemd[18064]: Starting XFCE notifications service... Nov 11 16:57:49 HOST xfce4-notifyd[32729]: Unable to init server: Could not connect: Connection refused Nov 11 16:57:49 HOST xfce4-notifyd[32729]: cannot open display: Nov 11 16:57:49 HOST systemd[18064]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE Nov 11 16:57:49 HOST systemd[18064]: xfce4-notifyd.service: Failed with result 'exit-code'. Nov 11 16:57:49 HOST systemd[18064]: Failed to start XFCE notifications service. Nov 11 16:59:49 HOST dbus-daemon[32186]: [session uid=UID pid=32186] Failed to activate service 'org.freedesktop.Notifications': timed out (service_start_timeout=12ms) In this example, the startup attempt was triggered with notify-send test (which hangs until the timeout) but I've also seen this triggered by other activity. These are fairly ordinary buster systems, with (in particular) libgtk-3-0 version 3.24.5-1. systemd-cgls shows this dbus-daemon as running as part of dbus.service in the user slice, with the following arguments: /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only I believe this to be normal (I didn't tweak the configuration in this respect) but wonder how daemons in the user slice are supposed to choose between the displays of the user's various active sessions. Still, this bug report is specifically about xfce4-notifyd not handling this more gracefully (e.g., by just going into headless, do-not-disturb mode if no sensible screen can be found; or at the very least by bailing out quickly and quietly rather than after two minutes), not about the flaws of dbus-daemon or systemd (or possibly ssh, if one thinks D-Bus should be forwarded).
Bug#466946: Bug#911043: On starting (and stopping) rngd
I read over the bug, and I have a few thoughts here First, regarding the rng-tools version looks rather out of date. From what I see, the latest version in the debian archives is 5-1, which is horribly old (circa 2004). The latest version is 6.10, and is almost a complete re-write, containing a useable systemd unit file, and also should work with sysv-init. It also contains several entropy sources, including a jitter source entropy generator to fall back on should other sources not be available for whatever reason. I'd strongly suggest updating to the latest version to avoid some of the problems described in the bug As for the question regarding starting rngd on multiple cores, I can't recommend that. rngd automatically detects the number of cores and starts threads on each for certain entropy sources, affining the cpus properly to generate maximum entropy without disrupting the system As for having trouble with ordering (i.e. if /dev/hwrng isn't ready when rngd starts), I'd use udev rules to trigger on the addition of an entropy source to just restart the rngd service, that shouldn't be too hard. That said though, if you use the included rngd.service, its blocked on WantedBy multi-user.target, so on a general boot it shouldn't start until all the hardware drivers are loaded and initalized. If you need it earlier than that, you can use dracut to start it in the initramfs, and shut it down on switch-root to get early entropy from the jitter source. Let me know if you have other questions Best Neil On Tue, Nov 10, 2020 at 3:09 PM Henrique de Moraes Holschuh wrote: > > > On Tue, Nov 10, 2020, at 16:05, Thorsten Glaser wrote: > > So we additionally have the case where the character device > > exists but is not usable… oh my. > > This was common enough that rngd should know about it and bail out with an > error if it doesn't gey proper random numbers from its input during > startup. At least I vaguely recall adding that logic, including a timeout. > > And it won't feed the entropy pool with obvious crap no matter what, > although you can easily fool it of you want, a typical device malfunction > (all zeroes, patterns with too much bias, all ones...) Won't get past it's > simplistic fitness testing (the old fips one). > > So you'd start it and it will bail up sometime later because the entropy > source is unfit for use. On systemd you should watch that and don't > restart it aggressively or you'll waste one cpu core worth of busywork in > the worst case. Best case it sleeps. > > -- > Henrique de Moraes Holschuh > -- /*** *Neil Horman *nhor...@gmail.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/
Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable
On Wed, 11 Nov 2020 at 02:18:52 +0100, Marc Lehmann wrote: > it's trivial to avoid in debian by bumping the > soname, so old binaries don't cause bad things to happen to users Distribution-specific SONAME bumps, without coordination with upstreams, cause incompatibilities for years to come (see: libcurl) and I would strongly prefer to avoid them. The upstream developer of a library "owns" the namespace of SONAME version numbers; if we bump the SONAME version, then we cannot complain when the upstream later uses the same version number for a different ABI, leaving us unable to ever re-converge. It is also the upstream developer who decides which parts of a library are or aren't considered to be part of the public API/ABI. Yes, reclassifying public API/ABI as private breaks derived projects that were relying on it, and it's unfortunate that the Pango maintainers were unaware that derived projects were relying on this part of the API; and yes, we *could* make a Debian-specific fork of Pango, and link our GTK/etc. to a Debian-specific Pango branch instead of the upstream Pango; but that doesn't seem a sustainable thing to do. I'm sorry that this has broken your use-case, but I don't think taking an adversarial tone is going to help you to achieve the result you are aiming for. People who perceive that they are being attacked will tend to become increasingly defensive and unwilling to change their position, which is presumably the opposite of what you want. smcv
Bug#504044: On starting (and stopping) rngd
Johannes Berg dixit: >There's virtio-rng in recent kernels, so you could just boot a VM and >connect the host's /dev/random to that. Right, I’d even tested that, but the other changes are still rather intrusive, and I think testing those with real hardware would be better. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#974164: /usr/bin/debchange: hardcodes Jessie for --lts option
On Wed, Nov 11, 2020 at 07:57:36AM +1100, Brian May wrote: > It would be good if it was possible to override the default somehow. > e.g. via another command line argument. You should be able to do that with -D already. Regardless, the only good solution regarding this specific set of issues is to have a distro-info-data being updated regularly, like ubuntu does but for whatever reason in Debian we are not buying it :( (that's also missing https://bugs.debian.org/782685 for what LTS is concerned) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#974431: [lemonldap-ng] all minified js files are empty
Package: src:lemonldap-ng
Version: 2.0.9+ds1
Severity: important
Hello,
As part of LLNG's debian/rules, minified js files are recreated. The
method for doing so errors out with '--comments=/Copyr/i' being
unrecognized and because of shell redirection, empty files are created
without aborting the build process:
$ ls -l /usr/share/lemonldap-ng/manager/htdocs/static/js/manager.*js
-rw-r--r-- 1 root root 31793 10 aug 12.25
/usr/share/lemonldap-ng/manager/htdocs/static/js/manager.js
-rw-r--r-- 1 root root 0 7 sep 08.51
/usr/share/lemonldap-ng/manager/htdocs/static/js/manager.min.js
The build log from the reproducible-builds project are available here:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/lemonldap-ng_2.0.9+ds-1.rbuild.log.gz
This makes the manager web interface fail to load at all (with angular
complaining about the non-existance of the llngManager module), and the
portal has issues (all "views"/tabs in the portal are rendered in a
single page -- but unlike the manager is still functional, at least for
logging in).
The corresponding step in upstream's Makefile has diverged slightly, and
syncing them would probably fix the errors. Currently (as of
2.0.9+ds-1), the code in debian/rules looks like this:
# Generate minified files removed by uscan
for i in $$(find $(TMP)/$(LMSHAREDIR) -type f -name '*.js'); do \
echo -n "compressing $$i: "; \
uglifyjs --comments='/Copyr/i' $$i >$${i%%.js}.min.js; \
echo done; \
done
The error given for each invokation is:
ERROR: invalid option --comments=/Copyr/i
I note especially that a recent change in upstream's Makefile is
removing the '=' between the --comments flag and its argument. I would
propose syncing the uglifyjs invokations, and add an `|| exit 1` or
similar to the command, so that future errors in uglifyjs aborts the
build.
merci beaucoup pour tout votre travail,
--
olof
Bug#972070: bluez-obexd: Failure to browse files, Failed to execute program org.bluez.obex: No such file or directory
That seems to be the problem here, yes. Although it was fixed upstream in 5.51 via https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/obexd/src/obex.service.in?id=78bce480093799c287ac8561b9407fa48796a130, the Debian package ships the unreplaced @libexecdir@ in /usr/share/dbus-1/services/org.bluez.obex.service as the source package patches in its own org.bluez.obex.service.in instead of the up-to-date obex.service.in.
Bug#972614: False positive for package-does-not-install-examples
Hi Julien, On Wed, Nov 11, 2020 at 5:57 AM Julien Puydt wrote: > > I run lintian 2.101.0, on node-posix-getopt 1.2.0+20150728-4. I figured it out. You run Lintian only on the source (dsc). That's why it's good to include the command. This is indeed a false positive. Kind regards Felix Lechner
Bug#974421: Wrong title
Of course, title should read: TexMaths 0.48.2 NOT working in Debian unstable
Bug#968484: wireshark hard-wired to libsystemd0?
Due to this issue, I've just spent 40 minutes of my life determining Wireshark's dependencies and compiling it from source. In case it helps: - use Wireshark 3.2.8, not the latest stable; - you don't need to install, Wireshark works fine from the build directory. I do feel some nostalgia for the olden times, when using Debian still meant you could request a package and get the dependencies resolved automatically. > Why on earth would a network traffic analyzer depend on system init? If you maintain any sort of free software nowadays, you'll spend a non-negligible amount of time summarily closing pull requests that add a gratuitious dependency on libsystemd. It's not a conspiracy, the kids doing that act in good faith, they really mean to help improve the ecosystem. -- Juliusz "Grumpy Old Man" Chroboczek
Bug#974430: plasma-workspace-wayland: Undefined symbols: Need rebuild ?
Package: plasma-workspace-wayland Version: 4:5.17.5-4 Severity: grave Justification: renders package unusable Dear Maintainer, This package crash. Log contains the following error, that point to a missing deps or a missing rebuild: /usr/lib/x86_64-linux-gnu/libkwin.so.5: undefined symbol: _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv Thanks -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-rt-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-workspace-wayland depends on: ii kwayland-integration 5.17.5-3 iu kwin-wayland 4:5.19.5-3 ii libc6 2.31-4 ii libkf5configcore5 5.74.0-2 ii libqt5core5a 5.15.1+dfsg-2 ii libqt5dbus5 5.15.1+dfsg-2 ii libstdc++610.2.0-16 ii plasma-workspace 4:5.17.5-4 ii qtwayland55.15.1-3 plasma-workspace-wayland recommends no packages. plasma-workspace-wayland suggests no packages. -- no debconf information
Bug#970885: adriconf : first trial of packaging
Hi Rogério and all, I've done a trial to package the tool adriconf. It works, but it misses several things: * the .desktop file from the flatpak directory should be copied. But I am very new debian packaging and I don't know how to override some rule to do that. * no manpage * the tests are generated but not ran at package build I can provide the source package if it can help someone. Regards,
Bug#974347: inkscape: measurement tool suport for compass mode
Hi Vangelis, While everything you said looks nice and cool, I'm afraid this forum is not really fit for such requests, since development of software like inkscape is not handled within Debian. Could I ask you to open these issues directly at the upstream place, at https://gitlab.com/inkscape/inbox ? I recommend you open multiple issues for multiple tasks :) If you report back here with a link once you did so, I can then monitor the status as well. Thank you for reporting your suggestions! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#974429: ITP: mobian-plymouth-theme -- Mobian theme for plymouth
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris X-Debbugs-Cc: debian-de...@lists.debian.org, arnaud.ferra...@gmail.com * Package name: mobian-plymouth-theme Version : 1 Upstream Author : Arnaud Ferraris * URL : https://salsa.debian.org/Mobian-team/mobian-plymouth-theme * License : GPL+LGPL Programming Lang: Plymouth Description : Mobian theme for plymouth Mobian is a Debian blend targetting mobile devices, such as phones and tablets. This package provides the default plymouth theme for Mobian, and will be maintained by the Mobian team.
Bug#972614: False positive for package-does-not-install-examples
Hi Julien, On Wed, Nov 11, 2020 at 5:57 AM Julien Puydt wrote: > > I run lintian 2.101.0, on node-posix-getopt 1.2.0+20150728-4. I am on stable. Are you? Kind regards Felix Lechner
