Bug#964688: sigviewer: FTBFS: src/file_handling_impl/biosig_reader.cpp:142:10: error: ‘QFile’ has not been declared
Source: sigviewer Version: 0.6.2-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > g++ -c -pipe -O2 -std=gnu++11 -D_REENTRANT -Wall -Wextra -fPIC > -DVERSION_MAJOR=0 -DVERSION_MINOR=6 -DVERSION_BUILD=2 -DQT_NO_DEBUG_OUTPUT > -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -I. > -I/<>/external/include -Isrc -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/QtXml -isystem > /usr/include/x86_64-linux-gnu/qt5/QtCore -Itmp/release -Itmp/release > -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o > tmp/release/biosig_reader.o src/file_handling_impl/biosig_reader.cpp > src/file_handling_impl/biosig_reader.cpp: In member function ‘QString > sigviewer::BioSigReader::loadFixedHeader(const QString&)’: > src/file_handling_impl/biosig_reader.cpp:142:10: error: ‘QFile’ has not been > declared > 142 | if (!QFile::exists(file_name)) > | ^ > make[1]: *** [Makefile:1867: tmp/release/biosig_reader.o] Error 1 The full build log is available from: http://qa-logs.debian.net/2020/07/09/sigviewer_0.6.2-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964685: libgphoto2: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Source: libgphoto2 Version: 2.5.25-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_makeshlibs -plibgphoto2-6 -X/usr/lib/x86_64-linux-gnu/libgphoto2/ > rm -f debian/libgphoto2-6/DEBIAN/shlibs > install -d debian/libgphoto2-6/DEBIAN > echo "libgphoto2 6 libgphoto2-6 (>= 2.5.25)" >> > debian/libgphoto2-6/DEBIAN/shlibs > chmod 0644 -- debian/libgphoto2-6/DEBIAN/shlibs > dpkg-gensymbols -plibgphoto2-6 -Idebian/libgphoto2-6.symbols > -Pdebian/libgphoto2-6 > -edebian/libgphoto2-6/usr/lib/x86_64-linux-gnu/libgphoto2.so.6.1.0 > mv debian/.debhelper/generated/libgphoto2-6/triggers.new > debian/.debhelper/generated/libgphoto2-6/triggers > dh_makeshlibs -plibgphoto2-port12 -X/usr/lib/x86_64-linux-gnu/libgphoto2_port/ > rm -f debian/libgphoto2-port12/DEBIAN/shlibs > install -d debian/libgphoto2-port12/DEBIAN > echo "libgphoto2_port 12 libgphoto2-port12 (>= 2.5.25)" >> > debian/libgphoto2-port12/DEBIAN/shlibs > chmod 0644 -- debian/libgphoto2-port12/DEBIAN/shlibs > dpkg-gensymbols -plibgphoto2-port12 -Idebian/libgphoto2-port12.symbols > -Pdebian/libgphoto2-port12 > -edebian/libgphoto2-port12/usr/lib/x86_64-linux-gnu/libgphoto2_port.so.12.0.0 > dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see > diff output below > dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols > file: see diff output below > dpkg-gensymbols: warning: debian/libgphoto2-port12/DEBIAN/symbols doesn't > match completely debian/libgphoto2-port12.symbols > --- debian/libgphoto2-port12.symbols (libgphoto2-port12_2.5.25-2_amd64) > +++ dpkg-gensymbolsR1k_fk 2020-07-09 00:51:18.610743369 + > @@ -1,79 +1,154 @@ > libgphoto2_port.so.12 libgphoto2-port12 #MINVER# > * Build-Depends-Package: libgphoto2-dev > - LIBGPHOTO2_5_0@LIBGPHOTO2_5_0 2.5.10 > - LIBGPHOTO2_INTERNAL@LIBGPHOTO2_INTERNAL 2.5.10 > - gp_log@LIBGPHOTO2_5_0 2.5.10 > - gp_log_add_func@LIBGPHOTO2_5_0 2.5.10 > - gp_log_data@LIBGPHOTO2_5_0 2.5.10 > - gp_log_remove_func@LIBGPHOTO2_5_0 2.5.10 > - gp_log_with_source_location@LIBGPHOTO2_5_0 2.5.10 > - gp_logv@LIBGPHOTO2_5_0 2.5.10 > - gp_port_check_int@LIBGPHOTO2_5_0 2.5.10 > - gp_port_check_int_fast@LIBGPHOTO2_5_0 2.5.10 > - gp_port_close@LIBGPHOTO2_5_0 2.5.10 > - gp_port_flush@LIBGPHOTO2_5_0 2.5.10 > - gp_port_free@LIBGPHOTO2_5_0 2.5.10 > - gp_port_get_error@LIBGPHOTO2_5_0 2.5.10 > - gp_port_get_info@LIBGPHOTO2_5_0 2.5.10 > - gp_port_get_pin@LIBGPHOTO2_5_0 2.5.10 > - gp_port_get_settings@LIBGPHOTO2_5_0 2.5.10 > - gp_port_get_timeout@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_get_name@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_get_path@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_get_type@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_append@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_count@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_free@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_get_info@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_load@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_lookup_name@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_lookup_path@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_list_new@LIBGPHOTO2_5_0 2.5.10 > - gp_port_info_new@LIBGPHOTO2_INTERNAL 2.5.10 > - gp_port_info_set_name@LIBGPHOTO2_INTERNAL 2.5.10 > - gp_port_info_set_path@LIBGPHOTO2_INTERNAL 2.5.10 > - gp_port_info_set_type@LIBGPHOTO2_INTERNAL 2.5.10 > - gp_port_library_version@LIBGPHOTO2_5_0 2.5.10 > - gp_port_message_codeset@LIBGPHOTO2_5_0 2.5.10 > - gp_port_new@LIBGPHOTO2_5_0 2.5.10 > - gp_port_open@LIBGPHOTO2_5_0 2.5.10 > - gp_port_read@LIBGPHOTO2_5_0 2.5.10 > - gp_port_reset@LIBGPHOTO2_5_0 2.5.10 > - gp_port_result_as_string@LIBGPHOTO2_5_0 2.5.10 > - gp_port_seek@LIBGPHOTO2_5_0 2.5.10 > - gp_port_send_break@LIBGPHOTO2_5_0 2.5.10 > - gp_port_send_scsi_cmd@LIBGPHOTO2_5_0 2.5.10 > - gp_port_set_error@LIBGPHOTO2_5_0 2.5.10 > - gp_port_set_info@LIBGPHOTO2_5_0 2.5.10 > - gp_port_set_pin@LIBGPHOTO2_5_0 2.5.10 > - gp_port_set_settings@LIBGPHOTO2_5_0 2.5.10 > - gp_port_set_timeout@LIBGPHOTO2_5_0 2.5.10 > - gp_port_settings_get@LIBGPHOTO2_5_0 2.5.10 > - gp_port_settings_set@LIBGPHOTO2_5_0 2.5.10 > - gp_port_timeout_get@LIBGPHOTO2_5_0 2.5.10 > - gp_port_timeout_set@LIBGPHOTO2_5_0 2.5.10 > - gp_port_usb_clear_halt@LIBGPHOTO2_5_0 2.5.10 > - gp_port_usb_find_device@LIBGPHOTO2_5_0 2.5.10 > - gp_port_usb_find_device_by_class@LIBGPHOTO2_5_0 2.5.10 > - gp_port_usb_msg_class_read@LIBGPHOTO2_5_0 2.5.10 > - gp_port_usb_msg_cl
Bug#964696: zyn: FTBFS: pkg-config cannot find lv2core
Source: zyn Version: 1+git.20100609+dfsg0-4 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > LINKFLAGS="-Wl,-z,relro -Wl,-z,now" ./waf configure > --lv2-dir=/<>/debian/zynadd/usr/lib/lv2 > Checking for program gcc : ok /usr/bin/gcc > Checking for program cpp : ok /usr/bin/cpp > Checking for program ar : ok /usr/bin/ar > Checking for program ranlib : ok /usr/bin/ranlib > Checking for compiler could create programs : ok > Checking for compiler could create shared libs : ok > Checking for compiler could create static libs : ok > Checking for flags -O2 : ok > Checking for flags -g -DDEBUG : ok > Checking for flags -g3 -O0 -DDEBUG : ok > Checking for flags -Wall : ok > Checking for gcc : ok > Checking for program g++ : ok /usr/bin/g++ > Checking for program ar: ok /usr/bin/ar > Checking for program ranlib: ok /usr/bin/ranlib > Checking for compiler could create programs: ok > Checking for compiler could create shared libs : ok > Checking for compiler could create static libs : ok > Checking for flags -O2 : ok > Checking for flags -g -DDEBUG : ok > Checking for flags -g3 -O0 -DDEBUG : ok > Checking for flags -Wall : ok > Checking for g++ : ok > LV2 installation directory : > /<>/debian/zynadd/usr/lib/lv2 > Checking for package fftw3 : ok > Checking for package lv2core : not found > pkg-config cannot find lv2core > make[1]: *** [debian/rules:14: override_dh_auto_configure] Error 1 The full build log is available from: http://qa-logs.debian.net/2020/07/09/zyn_1+git.20100609+dfsg0-4_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964686: node-ytdl-core: FTBFS: dh_auto_build: error: cd ./m3u8stream && sh -ex ../debian/nodejs/m3u8stream/build returned exit code 2
Source: node-ytdl-core Version: 2.1.3+dfsg+~cs2.16.2-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > dpkg-buildpackage > - > > Command: dpkg-buildpackage -us -uc -sa -rfakeroot > dpkg-buildpackage: info: source package node-ytdl-core > dpkg-buildpackage: info: source version 2.1.3+dfsg+~cs2.16.2-1 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Xavier Guimard > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture amd64 > debian/rules clean > dh clean --with nodejs >dh_auto_clean --buildsystem=nodejs > rm -rf ./node_modules/.cache > rm -rf html-entities/node_modules/.cache > rm -rf m3u8stream/node_modules/.cache > rm -rf miniget/node_modules/.cache >dh_clean > dpkg-source -b . > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building node-ytdl-core using existing > ./node-ytdl-core_2.1.3+dfsg+~cs2.16.2.orig-html-entities.tar.xz > dpkg-source: info: building node-ytdl-core using existing > ./node-ytdl-core_2.1.3+dfsg+~cs2.16.2.orig-m3u8stream.tar.xz > dpkg-source: info: building node-ytdl-core using existing > ./node-ytdl-core_2.1.3+dfsg+~cs2.16.2.orig-miniget.tar.xz > dpkg-source: info: building node-ytdl-core using existing > ./node-ytdl-core_2.1.3+dfsg+~cs2.16.2.orig.tar.xz > dpkg-source: info: building node-ytdl-core in > node-ytdl-core_2.1.3+dfsg+~cs2.16.2-1.debian.tar.xz > dpkg-source: info: building node-ytdl-core in > node-ytdl-core_2.1.3+dfsg+~cs2.16.2-1.dsc > debian/rules binary > dh binary --with nodejs >dh_update_autotools_config >dh_autoreconf >dh_auto_configure --buildsystem=nodejs > mkdir node_modules > mkdir -p ./node_modules/\@types > ln -s /usr/share/nodejs/\@types/node ./node_modules/\@types/ > ln -s ../html-entities node_modules/html-entities > ln -s ../m3u8stream node_modules/m3u8stream > ln -s ../miniget node_modules/miniget > mkdir -p m3u8stream/node_modules > ln -s ../../miniget m3u8stream/node_modules/miniget > ln -s ../../debian/build_modules/\@types/sax node_modules/\@types/sax >dh_auto_build --buildsystem=nodejs > No build command found, searching known files > Found debian/nodejs/miniget/build > cd ./miniget && sh -ex ../debian/nodejs/miniget/build > + set -e > + set -x > + mkdir -p node_modules/@types > + ln -s ../../../debian/build_modules/@types/sax node_modules/@types/sax > + tsc -p tsconfig.build.json > + rm -rf node_modules > Found debian/nodejs/m3u8stream/build > cd ./m3u8stream && sh -ex ../debian/nodejs/m3u8stream/build > + set -e > + set -x > + mkdir -p node_modules/@types > + ln -s ../../../debian/build_modules/@types/sax node_modules/@types/sax > + tsc -p tsconfig.build.json > src/dash-mpd-parser.ts(187,31): error TS2769: No overload matches this call. > Overload 1 of 2, '(chunk: any, cb?: (error: Error) => void): boolean', gave > the following error. > Argument of type 'string' is not assignable to parameter of type '(error: > Error) => void'. > Overload 2 of 2, '(chunk: any, encoding: BufferEncoding, cb?: (error: > Error) => void): boolean', gave the following error. > Argument of type 'string' is not assignable to parameter of type > 'BufferEncoding'. > dh_auto_build: error: cd ./m3u8stream && sh -ex > ../debian/nodejs/m3u8stream/build returned exit code 2 > make: *** [debian/rules:8: binary] Error 25 The full build log is available from: http://qa-logs.debian.net/2020/07/09/node-ytdl-core_2.1.3+dfsg+~cs2.16.2-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964695: ktexteditor: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j1 test ARGS\+=-j1 returned exit code 2
Source: ktexteditor Version: 5.70.1-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[2]: Entering directory '/<>/obj-x86_64-linux-gnu' > Running tests... > /usr/bin/ctest --force-new-ctest-process -j1 > Test project /<>/obj-x86_64-linux-gnu > Start 1: encoding_utf8.txt_create > 1/67 Test #1: encoding_utf8.txt_create Passed0.03 sec > Start 2: encoding_utf8.txt_diff > 2/67 Test #2: encoding_utf8.txt_diff .. Passed0.01 sec > Start 3: encoding_latin15.txt_create > 3/67 Test #3: encoding_latin15.txt_create . Passed0.03 sec > Start 4: encoding_latin15.txt_diff > 4/67 Test #4: encoding_latin15.txt_diff ... Passed0.01 sec > Start 5: encoding_utf32.txt_create > 5/67 Test #5: encoding_utf32.txt_create ... Passed0.03 sec > Start 6: encoding_utf32.txt_diff > 6/67 Test #6: encoding_utf32.txt_diff . Passed0.01 sec > Start 7: encoding_utf16.txt_create > 7/67 Test #7: encoding_utf16.txt_create ... Passed0.03 sec > Start 8: encoding_utf16.txt_diff > 8/67 Test #8: encoding_utf16.txt_diff . Passed0.01 sec > Start 9: encoding_utf32be.txt_create > 9/67 Test #9: encoding_utf32be.txt_create . Passed0.03 sec > Start 10: encoding_utf32be.txt_diff > 10/67 Test #10: encoding_utf32be.txt_diff ... Passed0.01 sec > Start 11: encoding_utf16be.txt_create > 11/67 Test #11: encoding_utf16be.txt_create . Passed0.03 sec > Start 12: encoding_utf16be.txt_diff > 12/67 Test #12: encoding_utf16be.txt_diff ... Passed0.01 sec > Start 13: encoding_cyrillic_utf8.txt_create > 13/67 Test #13: encoding_cyrillic_utf8.txt_create ... Passed0.03 sec > Start 14: encoding_cyrillic_utf8.txt_diff > 14/67 Test #14: encoding_cyrillic_utf8.txt_diff . Passed0.01 sec > Start 15: encoding_cp1251.txt_create > 15/67 Test #15: encoding_cp1251.txt_create .. Passed0.03 sec > Start 16: encoding_cp1251.txt_diff > 16/67 Test #16: encoding_cp1251.txt_diff Passed0.01 sec > Start 17: encoding_koi8-r.txt_create > 17/67 Test #17: encoding_koi8-r.txt_create .. Passed0.03 sec > Start 18: encoding_koi8-r.txt_diff > 18/67 Test #18: encoding_koi8-r.txt_diff Passed0.01 sec > Start 19: encoding_one-char-latin-15.txt_create > 19/67 Test #19: encoding_one-char-latin-15.txt_create ... Passed0.03 sec > Start 20: encoding_one-char-latin-15.txt_diff > 20/67 Test #20: encoding_one-char-latin-15.txt_diff . Passed0.01 sec > Start 21: kateindenttest_testPython > 21/67 Test #21: kateindenttest_testPython ... Passed0.24 sec > Start 22: kateindenttest_testCstyle > 22/67 Test #22: kateindenttest_testCstyle ... Passed0.53 sec > Start 23: kateindenttest_testCppstyle > 23/67 Test #23: kateindenttest_testCppstyle . Passed0.61 sec > Start 24: kateindenttest_testCMake > 24/67 Test #24: kateindenttest_testCMake Passed0.20 sec > Start 25: kateindenttest_testRuby > 25/67 Test #25: kateindenttest_testRuby . Passed0.60 sec > Start 26: kateindenttest_testHaskell > 26/67 Test #26: kateindenttest_testHaskell .. Passed0.14 sec > Start 27: kateindenttest_testLatex > 27/67 Test #27: kateindenttest_testLatex Passed0.14 sec > Start 28: kateindenttest_testPascal > 28/67 Test #28: kateindenttest_testPascal ...Child > aborted***Exception: 0.57 sec > * Start testing of IndentTest * > Config: Using QtTest library 5.14.2, Qt 5.14.2 (x86_64-little_endian-lp64 > shared (dynamic) release build; by GCC 9.3.0) > QWARN : IndentTest::initTestCase() sonnet.core: Sonnet: No speller backends > available! > QWARN : IndentTest::initTestCase() sonnet.core: No language dictionaries for > the language: "C" > QWARN : IndentTest::initTestCase() sonnet.core: No language dictionaries for > the language: "C" > QWARN : IndentTest::initTestCase() sonnet.core: No language dictionaries for > the language: "C" > QWARN : IndentTest::initTestCase() sonnet.core: No language dictionaries for > the language: "C" > PASS : IndentTest::initTestCase() > QWARN : Inde
Bug#964697: django-mailman3: FTBFS: ValueError: max() arg is an empty sequence
Source: django-mailman3
Version: 1.3.2-1
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200709 ftbfs-bullseye
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> py3versions: no X-Python3-Version in control file, using supported versions
> set -e; \
> for python3 in python3.8; do \
> $python3 /usr/bin/django-admin test --pythonpath=.
> --settings=django_mailman3.tests.settings_test django_mailman3; \
> done
> Creating test database for alias 'default'...
> ....EEE...
> ==
> ERROR: test_attachment_3 (django_mailman3.tests.test_scrub.TestScrubber)
> --
> Traceback (most recent call last):
> File "./django_mailman3/tests/test_scrub.py", line 83, in test_attachment_3
> contents, attachments = scrubber.scrub()
> File "./django_mailman3/lib/scrub.py", line 77, in scrub
> attachments = self._get_all_attachments()
> File "./django_mailman3/lib/scrub.py", line 99, in _get_all_attachments
> part.set_content('')
> File "/usr/lib/python3.8/email/message.py", line 1171, in set_content
> super().set_content(*args, **kw)
> File "/usr/lib/python3.8/email/message.py", line 1101, in set_content
> content_manager.set_content(self, *args, **kw)
> File "/usr/lib/python3.8/email/contentmanager.py", line 37, in set_content
> handler(msg, obj, *args, **kw)
> File "/usr/lib/python3.8/email/contentmanager.py", line 185, in
> set_text_content
> cte, payload = _encode_text(string, charset, cte, msg.policy)
> File "/usr/lib/python3.8/email/contentmanager.py", line 149, in _encode_text
> if max(len(x) for x in lines) <= policy.max_line_length:
> ValueError: max() arg is an empty sequence
>
> ==
> ERROR: test_attachment_4 (django_mailman3.tests.test_scrub.TestScrubber)
> --
> Traceback (most recent call last):
> File "./django_mailman3/tests/test_scrub.py", line 161, in test_attachment_4
> contents, attachments = scrubber.scrub()
> File "./django_mailman3/lib/scrub.py", line 77, in scrub
> attachments = self._get_all_attachments()
> File "./django_mailman3/lib/scrub.py", line 99, in _get_all_attachments
> part.set_content('')
> File "/usr/lib/python3.8/email/message.py", line 1171, in set_content
> super().set_content(*args, **kw)
> File "/usr/lib/python3.8/email/message.py", line 1101, in set_content
> content_manager.set_content(self, *args, **kw)
> File "/usr/lib/python3.8/email/contentmanager.py", line 37, in set_content
> handler(msg, obj, *args, **kw)
> File "/usr/lib/python3.8/email/contentmanager.py", line 185, in
> set_text_content
> cte, payload = _encode_text(string, charset, cte, msg.policy)
> File "/usr/lib/python3.8/email/contentmanager.py", line 149, in _encode_text
> if max(len(x) for x in lines) <= policy.max_line_length:
> ValueError: max() arg is an empty sequence
>
> ==
> ERROR: test_attachment_5 (django_mailman3.tests.test_scrub.TestScrubber)
> --
> Traceback (most recent call last):
> File "./django_mailman3/tests/test_scrub.py", line 184, in test_attachment_5
> contents, attachments = scrubber.scrub()
> File "./django_mailman3/lib/scrub.py", line 77, in scrub
> attachments = self._get_all_attachments()
> File "./django_mailman3/lib/scrub.py", line 95, in _get_all_attachments
> part.set_content('')
> File "/usr/lib/python3.8/email/message.py", line 1171, in set_content
> super().set_content(*args, **kw)
> File "/usr/lib/python3.8/email/message.py", line 1101, in set_content
> content_manager.set_content(self, *args, **kw)
> File "/usr/lib/python3.8/email/contentmanager.py", line 37, in set_content
> handler(msg, obj, *args, **kw)
> File "/usr/lib/python3.8/email/contentmanager.py", line 185, in
> set_text_content
> cte, payload = _encode_text(string, charset, cte, msg.policy)
> File "/usr/lib/python3.8/email/contentmanager.py", line 1
Bug#964687: quassel: FTBFS: qmetatype.h:818:16: error: ambiguous overload for ‘operator<<’ (operand types are ‘QDataStream’ and ‘const DccConfig::IpDetectionMode’)
Source: quassel
Version: 1:0.13.1-3
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200709 ftbfs-bullseye
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> cd /<>/obj-x86_64-linux-gnu/src/common && /usr/bin/c++
> -DHAVE_EXECINFO -DHAVE_KDE -DHAVE_KF5 -DHAVE_QT5 -DHAVE_SSL -DHAVE_SYSLOG
> -DHAVE_UMASK -DHAVE_ZLIB -DQT_CORE_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG
> -DWITH_OXYGEN_ICONS -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
> -I/<>/obj-x86_64-linux-gnu/src/common
> -I/<>/src/common
> -I/<>/obj-x86_64-linux-gnu/src/common/mod_common_autogen/include
> -isystem /usr/include/x86_64-linux-gnu/qt5 -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/QtNetwork -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -Wall
> -Wextra -Wnon-virtual-dtor -fno-strict-aliasing -Wundef -Wcast-align
> -Wpointer-arith -Wformat-security -fno-check-new -fno-common
> -Woverloaded-virtual -fno-operator-names -Wall -Wextra -Wcast-align
> -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
> -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time
> -Wsuggest-override -Wlogical-op -fexceptions -fPIC -fvisibility=hidden
> -fvisibility-inlines-hidden -fPIC -std=gnu++11 -o
> CMakeFiles/mod_common.dir/event.cpp.o -c /<>/src/common/event.cpp
> In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:54,
> from /usr/include/x86_64-linux-gnu/qt5/QtCore/qiodevice.h:45,
> from
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork/qabstractsocket.h:44,
> from
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork/qhostaddress.h:48,
> from
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork/QHostAddress:1,
> from /<>/src/common/dccconfig.h:23,
> from /<>/src/common/dccconfig.cpp:21:
> /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h: In instantiation of
> ‘static void QtMetaTypePrivate::QMetaTypeFunctionHelper Accepted>::Save(QDataStream&, const void*) [with T =
> DccConfig::IpDetectionMode; bool Accepted = true]’:
> /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:1874:39: required from
> ‘void qRegisterMetaTypeStreamOperators(const char*, T*) [with T =
> DccConfig::IpDetectionMode]’
> /<>/src/common/dccconfig.cpp:33:87: required from here
> /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:818:16: error: ambiguous
> overload for ‘operator<<’ (operand types are ‘QDataStream’ and ‘const
> DccConfig::IpDetectionMode’)
> 818 | stream << *static_cast(t);
> | ~~~^~~~
> In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/QDataStream:1,
> from /<>/src/common/syncableobject.h:24,
> from /<>/src/common/dccconfig.h:25,
> from /<>/src/common/dccconfig.cpp:21:
> /usr/include/x86_64-linux-gnu/qt5/QtCore/qdatastream.h:389:1: note:
> candidate: ‘typename std::enable_if::value,
> QDataStream&>::type& operator<<(QDataStream&, const T&) [with T =
> DccConfig::IpDetectionMode; typename std::enable_if::value,
> QDataStream&>::type = QDataStream&]’
> 389 | operator<<(QDataStream &s, const T &t)
> | ^~~~
> In file included from /<>/src/common/dccconfig.cpp:25:
> /<>/src/common/types.h:152:14: note: candidate: ‘QDataStream&
> operator<<(QDataStream&, T) [with T = DccConfig::IpDetectionMode;
> = void]’
> 152 | QDataStream &operator<<(QDataStream &out, T value) {
> | ^~~~
> In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:54,
> from /usr/include/x86_64-linux-gnu/qt5/QtCore/qiodevice.h:45,
> from
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork/qabstractsocket.h:44,
> from
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork/qhostaddress.h:48,
> from
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork/QHostAddress:1,
> from /<>/src/common/dccconfig.h:23,
> from /<>/src/common/dccconfig.cpp:21:
> /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h: In instantiation of
> ‘static void QtMetaTypePrivate::QMetaTypeFunctionHelper Accepted>::Load(QDataStream&, void*) [with T = DccConfig::IpDetectionMode;
> bool Accepted
Bug#964691: omnidb: FTBFS: build-dependency not installable: fonts-glewlwyd
Source: omnidb Version: 2.17.0+ds-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > +--+ > | Install package build dependencies > | > +--+ > > > Setup apt archive > - > > Merged Build-Depends: debhelper (>= 11), dh-python, fonts-glewlwyd, > fonts-roboto-unhinted, libjs-excanvas, libjs-jquery, libjs-jquery-ui, > postgresql-server-dev-all, python3:any | python3-all:any | python3-dev:any | > python3-all-dev:any, build-essential, fakeroot > Filtered Build-Depends: debhelper (>= 11), dh-python, fonts-glewlwyd, > fonts-roboto-unhinted, libjs-excanvas, libjs-jquery, libjs-jquery-ui, > postgresql-server-dev-all, python3:any, build-essential, fakeroot > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > Ign:1 copy:/<>/apt_archive ./ InRelease > Get:2 copy:/<>/apt_archive ./ Release [957 B] > Ign:3 copy:/<>/apt_archive ./ Release.gpg > Get:4 copy:/<>/apt_archive ./ Sources [458 B] > Get:5 copy:/<>/apt_archive ./ Packages [526 B] > Fetched 1941 B in 0s (190 kB/s) > Reading package lists... > Reading package lists... > > Install main build dependencies (apt-based resolver) > > > Installing build dependencies > Reading package lists... > Building dependency tree... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > sbuild-build-depends-main-dummy : Depends: fonts-glewlwyd but it is not > installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. The full build log is available from: http://qa-logs.debian.net/2020/07/09/omnidb_2.17.0+ds-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964683: kid3: FTBFS: sed: can't read /<>/debian/kid3-core/usr/lib/kid3/plugins/imports/Kid3/plugins.qmltypes: No such file or directory
Source: kid3 Version: 3.8.3-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > dh_install > sed '/This file was auto-generated by:/,+1 d' -i \ > > /<>/debian/kid3-core/usr/lib/kid3/plugins/imports/Kid3/plugins.qmltypes > sed: can't read > /<>/debian/kid3-core/usr/lib/kid3/plugins/imports/Kid3/plugins.qmltypes: > No such file or directory > make[1]: *** [debian/rules:32: override_dh_install] Error 2 The full build log is available from: http://qa-logs.debian.net/2020/07/09/kid3_3.8.3-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964701: sssd: FTBFS: ../src/providers/ad/ad_gpo_ndr.c:108:13: error: implicit declaration of function ‘ndr_pull_get_switch_value’; did you mean ‘ndr_pull_set_switch_value’? [-Werror=implicit-funct
Source: sssd Version: 2.2.3-3 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. > -Wall -I.. -I../src/sss_client -I../src -I. -I/usr/include/dbus-1.0 > -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include-I/usr/include/libnl3 > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\" -DVARDIR=\"/var\" > -DSSS_STATEDIR=\"/var/lib/sss\" -DSYSCONFDIR=\"/etc\" -DSHLIBEXT=\"\" > -DSSSDDATADIR=\"/usr/share/sssd\" -DSSSD_LIBEXEC_PATH=\"/usr/libexec/sssd\" > -DSSSD_CONF_DIR=\"/etc/sssd\" -DSSS_NSS_MCACHE_DIR=\"/var/lib/sss/mc\" > -DSSS_NSS_SOCKET_NAME=\"/var/lib/sss/pipes/nss\" > -DSSS_PAM_SOCKET_NAME=\"/var/lib/sss/pipes/pam\" > -DSSS_PAC_SOCKET_NAME=\"/var/lib/sss/pipes/pac\" > -DSSS_PAM_PRIV_SOCKET_NAME=\"/var/lib/sss/pipes/private/pam\" > -DSSS_SEC_SOCKET_NAME=\"/run/secrets.socket\" > -DSSS_SUDO_SOCKET_NAME=\"/var/lib/sss/pipes/sudo\" > -DSSS_AUTOFS_SOCKET_NAME=\"/var/lib/sss/pipes/autofs\" > -DSSS_SSH_SOCKET_NAME=\"/var/lib/sss/pipes/ssh\" > -DLOCALEDIR=\"/usr/share/locale\" > -DBASE_FILE_STEM=\"libsss_ad_la-ad_subdomains\" -Wdate-time > -D_FORTIFY_SOURCE=2 -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith > -Wcast-qual -Wcast-align -Wwrite-strings -Wundef > -Werror-implicit-function-declaration -Winit-self -Wmissing-include-dirs > -fno-strict-aliasing -std=gnu99-isystem /usr/include/mit-krb5 > -DHAVE_IMMEDIATE_STRUCTURES=1 -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 > -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 -I/usr/include/samba-4.0 > -DHAVE_IMMEDIATE_STRUCTURES=1 -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 > -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 -D_GNU_SOURCE=1 > -DHAVE_IMMEDIATE_STRUCTURES=1 -I/usr/include/samba-4.0 > -I/usr/include/samba-4.0 -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security > -I/usr/include/samba-4.0 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -c -o src/providers/ad/libsss_ad_la-ad_subdomains.lo > `test -f 'src/providers/ad/ad_subdomains.c' || echo > '../'`src/providers/ad/ad_subdomains.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -I.. > -I../src/sss_client -I../src -I. -I/usr/include/dbus-1.0 > -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/libnl3 > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include > -DLIBDIR=\"/usr/lib/x86_64-linux-gnu\" -DVARDIR=\"/var\" > -DSSS_STATEDIR=\"/var/lib/sss\" -DSYSCONFDIR=\"/etc\" -DSHLIBEXT=\"\" > -DSSSDDATADIR=\"/usr/share/sssd\" -DSSSD_LIBEXEC_PATH=\"/usr/libexec/sssd\" > -DSSSD_CONF_DIR=\"/etc/sssd\" -DSSS_NSS_MCACHE_DIR=\"/var/lib/sss/mc\" > -DSSS_NSS_SOCKET_NAME=\"/var/lib/sss/pipes/nss\" > -DSSS_PAM_SOCKET_NAME=\"/var/lib/sss/pipes/pam\" > -DSSS_PAC_SOCKET_NAME=\"/var/lib/sss/pipes/pac\" > -DSSS_PAM_PRIV_SOCKET_NAME=\"/var/lib/sss/pipes/private/pam\" > -DSSS_SEC_SOCKET_NAME=\"/run/secrets.socket\" > -DSSS_SUDO_SOCKET_NAME=\"/var/lib/sss/pipes/sudo\" > -DSSS_AUTOFS_SOCKET_NAME=\"/var/lib/sss/pipes/autofs\" > -DSSS_SSH_SOCKET_NAME=\"/var/lib/sss/pipes/ssh\" > -DLOCALEDIR=\"/usr/share/locale\" -DBASE_FILE_STEM=\"libsss_ad_la-ad_gpo\" > -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wshadow -Wstrict-prototypes > -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wundef > -Werror-implicit-function-declaration -Winit-self -Wmissing-include-dirs > -fno-strict-aliasing -std=gnu99 -isystem /usr/include/mit-krb5 > -DHAVE_IMMEDIATE_STRUCTURES=1 -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 > -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 -I/usr/include/samba-4.0 > -DHAVE_IMMEDIATE_STRUCTURES=1 -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 > -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 -D_GNU_SOURCE=1 > -DHAVE_IMMEDIATE_STRUCTURES=1 -I/usr/include/samba-4.0 > -I/usr/include/samba-4.0 -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security > -I/usr/include/samba-4.0 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE > -D_LARGEFILE64_SOURCE -c ../src/providers/ad/ad_gpo.c -fPIC -DPIC -o > src/providers/ad/.libs/libsss_ad_la-ad_
Bug#962698: python-pauvre: FTBFS if the "DISPLAY" environment variable is exported
On Wed, Jul 08, 2020 at 07:36:29PM +0200, etienne.moll...@mailoo.org wrote: > > Besides, running reproducible build checks showed that some test > data and results landed into the binary package python3-pauvre, > so added some cleanup routine in the process. > ... > Thank you Chris for your report! As far as I can see this closes #962702 which was not closed in the changelog entry. Any reason for this? Kind regards Andreas. -- http://fam-tille.de
Bug#964628: python3-stdlib-extensions: FTBFS: unsatisfiable build-dependencies: libpython3.9-dev, libpython3.9-dbg, python3.9-dev:any, python3.9-dbg:any
On 7/9/20 12:54 PM, Lucas Nussbaum wrote: > Source: python3-stdlib-extensions > Version: 3.8.4~rc1-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200709 ftbfs-bullseye > >> The following packages have unmet dependencies: >> sbuild-build-depends-main-dummy : Depends: libpython3.9-dev but it is not >> installable >>Depends: libpython3.9-dbg but it is not >> installable >>Depends: python3.9-dev:any but it is not >> installable >>Depends: python3.9-dbg:any but it is not >> installable the packages are still in NEW.
Bug#964703: libkiwix: FTBFS: ../src/server.cpp:248:29: error: invalid conversion from ‘int (*)(void*, MHD_Connection*, const char*, const char*, const char*, const char*, size_t*, void**)’ {aka ‘int (
Source: libkiwix
Version: 9.2.2+dfsg-3
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20200709 ftbfs-bullseye
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include
> -I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu
> -I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe
> -D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD
> -MQ 'src/25a6634@@kiwix@sha/server.cpp.o' -MF
> 'src/25a6634@@kiwix@sha/server.cpp.o.d' -o
> 'src/25a6634@@kiwix@sha/server.cpp.o' -c ../src/server.cpp
> ../src/server.cpp: In member function ‘bool kiwix::InternalServer::start()’:
> ../src/server.cpp:248:29: error: invalid conversion from ‘int (*)(void*,
> MHD_Connection*, const char*, const char*, const char*, const char*, size_t*,
> void**)’ {aka ‘int (*)(void*, MHD_Connection*, const char*, const char*,
> const char*, const char*, long unsigned int*, void**)’} to
> ‘MHD_AccessHandlerCallback’ {aka ‘MHD_Result (*)(void*, MHD_Connection*,
> const char*, const char*, const char*, const char*, long unsigned int*,
> void**)’} [-fpermissive]
> 248 | &staticHandlerCallback,
> | ^~
> | |
> | int (*)(void*, MHD_Connection*, const
> char*, const char*, const char*, const char*, size_t*, void**) {aka int
> (*)(void*, MHD_Connection*, const char*, const char*, const char*, const
> char*, long unsigned int*, void**)}
> In file included from ../src/server.cpp:39:
> /usr/include/microhttpd.h:2428:45: note: initializing argument 5 of
> ‘MHD_Daemon* MHD_start_daemon(unsigned int, uint16_t,
> MHD_AcceptPolicyCallback, void*, MHD_AccessHandlerCallback, void*, ...)’
> 2428 | MHD_AccessHandlerCallback dh, void *dh_cls,
> | ~~^~
> [13/51] c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include
> -I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu
> -I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe
> -D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD
> -MQ 'src/25a6634@@kiwix@sha/downloader.cpp.o' -MF
> 'src/25a6634@@kiwix@sha/downloader.cpp.o.d' -o
> 'src/25a6634@@kiwix@sha/downloader.cpp.o' -c ../src/downloader.cpp
> [14/51] c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include
> -I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu
> -I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe
> -D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD
> -MQ 'src/25a6634@@kiwix@sha/reader.cpp.o' -MF
> 'src/25a6634@@kiwix@sha/reader.cpp.o.d' -o
> 'src/25a6634@@kiwix@sha/reader.cpp.o' -c ../src/reader.cpp
> [15/51] c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include
> -I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu
> -I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe
> -D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD
> -MQ 'src/25a6634@@kiwix@sha/library.cpp.o' -MF
> 'src/25a6634@@kiwix@sha/library.cpp.o.d' -o
> 'src/25a6634@@kiwix@sha/library.cpp.o' -c ../src/library.cpp
> ninja: build stopped: subcommand failed.
> dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v
> returned exit code 1
> make: *** [debian/rules:5: binary] Error 25
The full build log is available from:
http://qa-logs.debian.net/2020/07/09/libkiwix_9.2.2+dfsg-3_unstable.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.
Bug#964590: RFP: golang-goipp -- IPP core protocol implementation
Le jeudi, 9 juillet 2020, 12.57:53 h CEST Roger Shimizu a écrit : > Dear Didier, > > For go, it's quite straightforward, since there's a tool called > dh-make-golang. I pushed the gits to salsa: > - https://salsa.debian.org/go-team/packages/golang-github-openprinting-goipp > > Help yourself with the rest. Oh, excellent, thanks. Could you give me enough rights on that repository so that I can finish this? btw; https://salsa.debian.org/go-team/packages/golang-github-openprinting-goipp-dev should be deleted, it was a mistake from my dh-make-golang attemps, sorry. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#964710: abinit: FTBFS: /usr/bin/env: ‘python’: No such file or directory
Source: abinit Version: 8.10.3-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > debian/rules build > dh build >debian/rules override_dh_autoreconf > make[1]: Entering directory '/<>' > config/scripts/makemake > /usr/bin/env: ‘python’: No such file or directory > make[1]: *** [debian/rules:33: override_dh_autoreconf] Error 127 The full build log is available from: http://qa-logs.debian.net/2020/07/09/abinit_8.10.3-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964705: zoneminder: FTBFS: build-dependency not installable: fonts-glewlwyd
Source: zoneminder Version: 1.34.16-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > +--+ > | Install package build dependencies > | > +--+ > > > Setup apt archive > - > > Merged Build-Depends: debhelper-compat (= 12), dh-linktree, apache2-dev, > cmake, default-libmysqlclient-dev, libavcodec-dev (>= 6:10~), libavdevice-dev > (>= 6:10~), libavformat-dev (>= 6:10~), libavresample-dev, libavutil-dev (>= > 6:10~), libbz2-dev, libcurl4-gnutls-dev, libdate-manip-perl, > libdbd-mysql-perl, libgcrypt-dev, libjpeg-dev, libjwt-gnutls-dev, > libpcre3-dev, libphp-serialization-perl, libpolkit-gobject-1-dev, > libswscale-dev (>= 6:10~), libsys-mmap-perl, libv4l-dev (>= 0.8.3), > libvlc-dev, libwww-perl, libx264-dev, python3-sphinx, fonts-glewlwyd, > build-essential, fakeroot > Filtered Build-Depends: debhelper-compat (= 12), dh-linktree, apache2-dev, > cmake, default-libmysqlclient-dev, libavcodec-dev (>= 6:10~), libavdevice-dev > (>= 6:10~), libavformat-dev (>= 6:10~), libavresample-dev, libavutil-dev (>= > 6:10~), libbz2-dev, libcurl4-gnutls-dev, libdate-manip-perl, > libdbd-mysql-perl, libgcrypt-dev, libjpeg-dev, libjwt-gnutls-dev, > libpcre3-dev, libphp-serialization-perl, libpolkit-gobject-1-dev, > libswscale-dev (>= 6:10~), libsys-mmap-perl, libv4l-dev (>= 0.8.3), > libvlc-dev, libwww-perl, libx264-dev, python3-sphinx, fonts-glewlwyd, > build-essential, fakeroot > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > Ign:1 copy:/<>/apt_archive ./ InRelease > Get:2 copy:/<>/apt_archive ./ Release [963 B] > Ign:3 copy:/<>/apt_archive ./ Release.gpg > Get:4 copy:/<>/apt_archive ./ Sources [610 B] > Get:5 copy:/<>/apt_archive ./ Packages [677 B] > Fetched 2250 B in 0s (0 B/s) > Reading package lists... > Reading package lists... > > Install main build dependencies (apt-based resolver) > > > Installing build dependencies > Reading package lists... > Building dependency tree... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > sbuild-build-depends-main-dummy : Depends: fonts-glewlwyd but it is not > installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. The full build log is available from: http://qa-logs.debian.net/2020/07/09/zoneminder_1.34.16-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964709: ruby-appraisal: FTBFS: ruby-aruba : Depends: ruby-thor (>= 1.0) but 0.20.3-2 is to be installed
Source: ruby-appraisal Version: 0.5.1-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > +--+ > | Install package build dependencies > | > +--+ > > > Setup apt archive > - > > Merged Build-Depends: bundler, debhelper (>= 9~), gem2deb, rake, ruby-aruba, > ruby-rspec, build-essential, fakeroot > Filtered Build-Depends: bundler, debhelper (>= 9~), gem2deb, rake, > ruby-aruba, ruby-rspec, build-essential, fakeroot > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > Ign:1 copy:/<>/apt_archive ./ InRelease > Get:2 copy:/<>/apt_archive ./ Release [957 B] > Ign:3 copy:/<>/apt_archive ./ Release.gpg > Get:4 copy:/<>/apt_archive ./ Sources [396 B] > Get:5 copy:/<>/apt_archive ./ Packages [475 B] > Fetched 1828 B in 0s (0 B/s) > Reading package lists... > Reading package lists... > > Install main build dependencies (apt-based resolver) > > > Installing build dependencies > Reading package lists... > Building dependency tree... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > ruby-aruba : Depends: ruby-thor (>= 1.0) but 0.20.3-2 is to be installed > E: Unable to correct problems, you have held broken packages. > apt-get failed. The full build log is available from: http://qa-logs.debian.net/2020/07/09/ruby-appraisal_0.5.1-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964707: ruby-factory-girl: FTBFS: ruby-aruba : Depends: ruby-thor (>= 1.0) but 0.20.3-2 is to be installed
Source: ruby-factory-girl Version: 4.7.0-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > +--+ > | Install package build dependencies > | > +--+ > > > Setup apt archive > - > > Merged Build-Depends: debhelper (>= 11~), gem2deb, rake, ruby-activerecord, > ruby-activesupport, ruby-appraisal, ruby-aruba, ruby-bourne, ruby-rspec, > ruby-rspec-its, ruby-sqlite3, ruby-timecop, build-essential, fakeroot > Filtered Build-Depends: debhelper (>= 11~), gem2deb, rake, ruby-activerecord, > ruby-activesupport, ruby-appraisal, ruby-aruba, ruby-bourne, ruby-rspec, > ruby-rspec-its, ruby-sqlite3, ruby-timecop, build-essential, fakeroot > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > Ign:1 copy:/<>/apt_archive ./ InRelease > Get:2 copy:/<>/apt_archive ./ Release [957 B] > Ign:3 copy:/<>/apt_archive ./ Release.gpg > Get:4 copy:/<>/apt_archive ./ Sources [437 B] > Get:5 copy:/<>/apt_archive ./ Packages [519 B] > Fetched 1913 B in 0s (0 B/s) > Reading package lists... > Reading package lists... > > Install main build dependencies (apt-based resolver) > > > Installing build dependencies > Reading package lists... > Building dependency tree... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > ruby-aruba : Depends: ruby-thor (>= 1.0) but 0.20.3-2 is to be installed > E: Unable to correct problems, you have held broken packages. > apt-get failed. The full build log is available from: http://qa-logs.debian.net/2020/07/09/ruby-factory-girl_4.7.0-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964704: openjdk-11: FTBFS: tar: Cowardly refusing to create an empty archive
Source: openjdk-11 Version: 11.0.7+10-3 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > BEGIN jtreg-summary-hotspot > cat jtreg-test-output/jtreg-summary-hotspot.log > --- jtreg console summary for hotspot --- > Cannot determine JTREG_HOME; please set it explicitly > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > Unable to compare jtreg results: no build jtreport found for hotspot/amd64. > Reason: > '/usr/share/doc/openjdk-11-jre-headless//test-amd64/jtreport-hotspot.tar.gz' > does not exist. > --- jtreg console summary for langtools --- > Cannot determine JTREG_HOME; please set it explicitly > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > Unable to compare jtreg results: no build jtreport found for hotspot/amd64. > Reason: > '/usr/share/doc/openjdk-11-jre-headless//test-amd64/jtreport-hotspot.tar.gz' > does not exist. > --- jtreg console summary for jaxp --- > Cannot determine JTREG_HOME; please set it explicitly > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > Unable to compare jtreg results: no build jtreport found for hotspot/amd64. > Reason: > '/usr/share/doc/openjdk-11-jre-headless//test-amd64/jtreport-hotspot.tar.gz' > does not exist. > --- jtreg console summary for jdk --- > Cannot determine JTREG_HOME; please set it explicitly > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > [debian/tests/jtreg-autopkgtest.sh] nothing to cleanup > Unable to compare jtreg results: no build jtreport found for hotspot/amd64. > Reason: > '/usr/share/doc/openjdk-11-jre-headless//test-amd64/jtreport-hotspot.tar.gz' > does not exist. > END jtreg-summary-hotspot > for i in hotspot langtools jaxp jdk; do \ > find jtreg-test-output/$i/JTwork/ -name '*.jtr'; \ > done | sort -u > jtreg-test-output/failed_tests-hotspot.list; \ > GZIP=-9vn tar --ignore-failed-read -C . -c -z -f > jtreg-test-output/failed_tests-hotspot.tar.gz -T > jtreg-test-output/failed_tests-hotspot.list > find: 'jtreg-test-output/hotspot/JTwork/': No such file or directory > find: 'jtreg-test-output/langtools/JTwork/': No such file or directory > find: 'jtreg-test-output/jaxp/JTwork/': No such file or directory > find: 'jtreg-test-output/jdk/JTwork/': No such file or directory > gzip: warning: GZIP environment variable is deprecated; use an alias or script > 99.7% > GZIP=-9vn tar -C . -c -z -f jtreg-test-output/jtreport-hotspot.tar.gz $(find > jtreg-test-output -name JTreport) > tar: Cowardly refusing to create an empty archive > Try 'tar --help' or 'tar --usage' for more information. > make[1]: *** [debian/rules:1065: jtreg-run-check] Error 2 The full build log is available from: http://qa-logs.debian.net/2020/07/09/openjdk-11_11.0.7+10-3_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964708: ruby-rspec: FTBFS: ruby-aruba : Depends: ruby-thor (>= 1.0) but 0.20.3-2 is to be installed
Source: ruby-rspec Version: 3.9.0c1e0m1s2-1 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > +--+ > | Install package build dependencies > | > +--+ > > > Setup apt archive > - > > Merged Build-Depends: coderay, debhelper-compat (= 12), gem2deb (>= 1), git, > ruby-aruba, ruby-childprocess, ruby-diff-lcs, ruby-fakefs, ruby-flexmock, > ruby-json, ruby-minitest, ruby-mocha, ruby-nokogiri, ruby-rr, > ruby-thread-order, build-essential, fakeroot > Filtered Build-Depends: coderay, debhelper-compat (= 12), gem2deb (>= 1), > git, ruby-aruba, ruby-childprocess, ruby-diff-lcs, ruby-fakefs, > ruby-flexmock, ruby-json, ruby-minitest, ruby-mocha, ruby-nokogiri, ruby-rr, > ruby-thread-order, build-essential, fakeroot > dpkg-deb: building package 'sbuild-build-depends-main-dummy' in > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. > Ign:1 copy:/<>/apt_archive ./ InRelease > Get:2 copy:/<>/apt_archive ./ Release [957 B] > Ign:3 copy:/<>/apt_archive ./ Release.gpg > Get:4 copy:/<>/apt_archive ./ Sources [458 B] > Get:5 copy:/<>/apt_archive ./ Packages [544 B] > Fetched 1959 B in 0s (0 B/s) > Reading package lists... > Reading package lists... > > Install main build dependencies (apt-based resolver) > > > Installing build dependencies > Reading package lists... > Building dependency tree... > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > ruby-aruba : Depends: ruby-thor (>= 1.0) but 0.20.3-2 is to be installed > E: Unable to correct problems, you have held broken packages. > apt-get failed. The full build log is available from: http://qa-logs.debian.net/2020/07/09/ruby-rspec_3.9.0c1e0m1s2-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures.
Bug#964702: pdfminer: FTBFS: /bin/sh: 1: rename.ul: not found
Source: pdfminer Version: 20191020+dfsg-2 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20200709 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > make[1]: Entering directory '/<>' > pybuild --install -p 3 > I: pybuild base:217: /usr/bin/python3 setup.py install --root > /<>/debian/python3-pdfminer > running install > running build > running build_py > creating /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/high_level.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/latin_enc.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/psparser.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/ccitt.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/__init__.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/image.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdftypes.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdfinterp.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/ascii85.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdfdocument.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/cmapdb.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/layout.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdfpage.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/lzw.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/encodingdb.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdffont.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/settings.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/glyphlist.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdfparser.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdfdevice.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/rijndael.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/fontmetrics.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/runlength.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/pdfcolor.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/utils.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/arcfour.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > copying pdfminer/converter.py -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer > creating /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/UniJIS-UCS2-HW-H.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/Katakana-H.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/UniJIS-UTF8-H.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/to-unicode-Adobe-GB1.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/HKgccs-B5-H.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/NWP-H.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/CNS2-H.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/GBK-EUC-V.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/90ms-RKSJ-V.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/CNS-EUC-H.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/B5pc-V.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/UniGB-UCS2-V.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/UniJIS-UCS2-V.pickle.gz -> > /<>/.pybuild/cpython3_3_pdfminer/build/pdfminer/cmap > copying pdfminer/cmap/UniJIS2004-UTF16-V.pickle.gz -> > /<>/.
Bug#964589: buster-pu: package fwupd/1.2.5-2
On Thu, Jul 09, 2020 at 12:25:05PM +0100, Adam Barratt wrote: >Control: tags -1 + confirmed > >Thanks. Please go ahead. In incoming now, cheers! -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#964588: stretch-pu: package fwupd/0.7.4-2
On Thu, Jul 09, 2020 at 12:24:05PM +0100, Adam Barratt wrote: >Control: tags -1 + confirmed ... >Thanks. It also confirms that the libebitdo1 dependency gets dropped, >which was one of the things I wanted to check after looking at dak rm. Nod. >Please go ahead. In incoming now. Thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Bug#964590: RFP: golang-goipp -- IPP core protocol implementation
On Thu, Jul 9, 2020 at 8:42 PM Didier 'OdyX' Raboud wrote: > > Le jeudi, 9 juillet 2020, 12.57:53 h CEST Roger Shimizu a écrit : > > Dear Didier, > > > > For go, it's quite straightforward, since there's a tool called > > dh-make-golang. I pushed the gits to salsa: > > - https://salsa.debian.org/go-team/packages/golang-github-openprinting-goipp > > > > Help yourself with the rest. > > Oh, excellent, thanks. Could you give me enough rights on that repository so > that I can finish this? > > btw; > https://salsa.debian.org/go-team/packages/golang-github-openprinting-goipp-dev > should be deleted, it was a mistake from my dh-make-golang attemps, sorry. I think both are done. The gits I pushed to salsa already can be built well. Maybe you can just add yourself to uploader and then upload to NEW queue. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#931195: flash-kernel: Add entry for Olimex A64-Olinuxino
Hi Vagrant, Jonas Smedegaard wrote: > Package: flash-kernel > Followup-For: Bug #931195 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > 2 months have passed by with this issue solved in git but no release. > > What is missing for a release to happen? Any objections against such release? That would include: [ Heinrich Schuchardt ] * Add FriendlyARM NanoPi NEO Plus2. (Closes: #955374) [ Vagrant Cascadian ] * Add support for Pinebook Pro. [ Adam Borowski ] * Add support for Pinebook (Closes: #930098) [ Sunil Mohan Adapa ] * Add entry for Olimex A64-Olinuxino (Closes: #931195) * Add entry for Olimex A64-Olinuxino-eMMC (Closes: #931195) [ Josua Mayer ] * add db entries for SolidRun LX2160A Honeycomb and Clearfog CX. (Closes: #958023) * Add entries for SolidRun Cubox-i Solo/DualLite variants. (Closes: #939261) [ Domenico Andreoli ] * Add entry for Turris MOX (Closes: #961303) I could do a team upload under d-i team, if you want. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#964678: dictionaries-common: FTBFS: Can't locate TheWML/Backends/Slice/Main.pm in @INC
control: reassign -1 slice control: found -1 2.28.0~ds1-1 control: retitle -1 wml/slice must depend on wml package El jue., 9 jul. 2020 a las 13:36, Lucas Nussbaum () escribió: > > Source: dictionaries-common > Version: 1.28.1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200709 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This seems due to new slice package built from wml missing a dependency on wml. Reassigning > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > slice -oUNDEF+I+IW+IA-A-H-W-AH:scripts/maintainer/config-ispell > > scripts/maintainer/config.in > > Can't locate TheWML/Backends/Slice/Main.pm in @INC (you may need to install > > the TheWML::Backends::Slice::Main module) (@INC contains: /usr/share/wml > > /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 > > /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 > > /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base > > /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 > > /usr/local/lib/site_perl) at /usr/bin/slice line 10. > > BEGIN failed--compilation aborted at /usr/bin/slice line 10. > > make[1]: *** [Makefile:147: scripts/maintainer/config-ispell] Error 2 > > The full build log is available from: > > http://qa-logs.debian.net/2020/07/09/dictionaries-common_1.28.1_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures.
Bug#662692: Time When?
On Thu, Jul 09, 2020 at 11:02:50AM +0100, Barak A. Pearlmutter wrote: > Surely the right thing is: > > At the beep, the time will be ... three forty seven and sixteen seconds ... > > BEEP. that actually sounds like a good and doable idea, thanks! do you think you could maybe also provide a patch? :) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#964714: buster-pu: package appstream-glib/0.7.14-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
* Backport upstream fix for FTBFS in the year 2020.
(Closes: #949169)
diff -Nru appstream-glib-0.7.14/debian/changelog
appstream-glib-0.7.14/debian/changelog
--- appstream-glib-0.7.14/debian/changelog 2018-12-05 23:29:52.0
+0200
+++ appstream-glib-0.7.14/debian/changelog 2020-07-09 15:16:46.0
+0300
@@ -1,3 +1,11 @@
+appstream-glib (0.7.14-1+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport upstream fix for FTBFS in the year 2020.
+(Closes: #949169)
+
+ -- Adrian Bunk Thu, 09 Jul 2020 15:16:46 +0300
+
appstream-glib (0.7.14-1) unstable; urgency=medium
* Team upload
diff -Nru
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
---
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
1970-01-01 02:00:00.0 +0200
+++
appstream-glib-0.7.14/debian/patches/0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
2020-07-09 15:16:46.0 +0300
@@ -0,0 +1,40 @@
+From 953c8e529d7291e60a95e580967ed79ce2c9ccf0 Mon Sep 17 00:00:00 2001
+From: Richard Hughes
+Date: Mon, 6 Jan 2020 11:04:56 +
+Subject: trivial: Fix CI by moving 'future' back a bit
+
+2020 seemed like such a long time in the future all those years ago...
+---
+ data/tests/broken.appdata.xml | 2 +-
+ libappstream-glib/as-app-validate.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/data/tests/broken.appdata.xml b/data/tests/broken.appdata.xml
+index f7a5386..cf80f5b 100644
+--- a/data/tests/broken.appdata.xml
b/data/tests/broken.appdata.xml
+@@ -40,7 +40,7 @@
+ This is a duplicate release on the same day!
+
+
+-
++
+
+ This is a release in the future!
+
+diff --git a/libappstream-glib/as-app-validate.c
b/libappstream-glib/as-app-validate.c
+index c1103ac..f50e4e4 100644
+--- a/libappstream-glib/as-app-validate.c
b/libappstream-glib/as-app-validate.c
+@@ -864,7 +864,7 @@ as_app_validate_release (AsApp *app,
+AS_PROBLEM_KIND_ATTRIBUTE_MISSING,
+" has no timestamp");
+ }
+- if (timestamp > 20120101 && timestamp < 20251231) {
++ if (timestamp > 20120101 && timestamp < 20351231) {
+ ai_app_validate_add (helper,
+AS_PROBLEM_KIND_ATTRIBUTE_INVALID,
+" timestamp should be a UNIX
time");
+--
+2.20.1
+
diff -Nru appstream-glib-0.7.14/debian/patches/series
appstream-glib-0.7.14/debian/patches/series
--- appstream-glib-0.7.14/debian/patches/series 1970-01-01 02:00:00.0
+0200
+++ appstream-glib-0.7.14/debian/patches/series 2020-07-09 15:16:46.0
+0300
@@ -0,0 +1 @@
+0001-trivial-Fix-CI-by-moving-future-back-a-bit.patch
Bug#964712: buster-pu: package storebackup/3.2.1-2~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
* Set maintainer to Debian QA Group. (see #856299)
* Add patch to change the way the lockfile is opened in the Perl code.
(Fixes: CVE-2020-7040) (Closes: #949393)
CVE-2020-7040 is "no DSA" in stretch and buster.
diff -Nru storebackup-3.2.1/debian/changelog storebackup-3.2.1/debian/changelog
--- storebackup-3.2.1/debian/changelog 2012-06-17 07:31:31.0 +0300
+++ storebackup-3.2.1/debian/changelog 2020-07-09 14:59:51.0 +0300
@@ -1,3 +1,19 @@
+storebackup (3.2.1-2~deb10u1) buster; urgency=medium
+
+ * QA upload.
+ * Rebuild for buster.
+
+ -- Adrian Bunk Thu, 09 Jul 2020 14:59:51 +0300
+
+storebackup (3.2.1-2) unstable; urgency=medium
+
+ * QA upload.
+ * Set maintainer to Debian QA Group. (see #856299)
+ * Add patch to change the way the lockfile is opened in the Perl code.
+(Fixes: CVE-2020-7040) (Closes: #949393)
+
+ -- Adrian Bunk Wed, 08 Jul 2020 15:54:21 +0300
+
storebackup (3.2.1-1) unstable; urgency=low
* change short description, recommendation from Heinz-Josef Claes
diff -Nru storebackup-3.2.1/debian/control storebackup-3.2.1/debian/control
--- storebackup-3.2.1/debian/control2012-06-16 13:21:56.0 +0300
+++ storebackup-3.2.1/debian/control2020-07-08 15:54:21.0 +0300
@@ -1,7 +1,7 @@
Source: storebackup
Section: utils
Priority: optional
-Maintainer: Ryan Niebur
+Maintainer: Debian QA Group
Build-Depends: debhelper (>= 7.2), perl
Standards-Version: 3.9.3
Homepage: http://www.nongnu.org/storebackup/
diff -Nru storebackup-3.2.1/debian/patches/CVE-2020-7040.patch
storebackup-3.2.1/debian/patches/CVE-2020-7040.patch
--- storebackup-3.2.1/debian/patches/CVE-2020-7040.patch1970-01-01
02:00:00.0 +0200
+++ storebackup-3.2.1/debian/patches/CVE-2020-7040.patch2020-07-08
15:54:21.0 +0300
@@ -0,0 +1,27 @@
+Description: changing the way the lockfile is opened in the Perl code
+Author: Jan Ritzerfeld
+Author: Utkarsh Gupta
+Bug-Debian: https://bugs.debian.org/949393
+Origin: https://www.openwall.com/lists/oss-security/2020/01/20/3/1
+Last-Update: 2020-02-04
+
+--- a/lib/fileDir.pl
b/lib/fileDir.pl
+@@ -22,7 +22,7 @@
+
+ push @VERSION, '$Id: fileDir.pl 364 2012-02-12 14:14:44Z hjc $ ';
+
+-use Fcntl qw(O_RDWR O_CREAT);
++use Fcntl qw(O_RDWR O_CREAT O_WRONLY O_EXCL);
+ use POSIX;
+
+ require 'prLog.pl';
+@@ -404,7 +404,7 @@
+ '-str' => ["creating lock file <$lockFile>"]);
+
+ &::checkDelSymLink($lockFile, $prLog, 0x01);
+-open(FILE, "> $lockFile") or
++sysopen(FILE, $lockFile, O_WRONLY | O_CREAT | O_EXCL) or
+ $prLog->print('-kind' => 'E',
+ '-str' => ["cannot create lock file <$lockFile>"],
+ '-exit' => 1);
diff -Nru storebackup-3.2.1/debian/patches/series
storebackup-3.2.1/debian/patches/series
--- storebackup-3.2.1/debian/patches/series 2012-06-16 13:19:48.0
+0300
+++ storebackup-3.2.1/debian/patches/series 2020-07-08 15:54:21.0
+0300
@@ -1 +1,2 @@
fix-spelling-error-in-manpage
+CVE-2020-7040.patch
Bug#964713: stretch-pu: package storebackup/3.2.1-2~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
* Set maintainer to Debian QA Group. (see #856299)
* Add patch to change the way the lockfile is opened in the Perl code.
(Fixes: CVE-2020-7040) (Closes: #949393)
CVE-2020-7040 is "no DSA" in stretch and buster.
diff -Nru storebackup-3.2.1/debian/changelog storebackup-3.2.1/debian/changelog
--- storebackup-3.2.1/debian/changelog 2012-06-17 07:31:31.0 +0300
+++ storebackup-3.2.1/debian/changelog 2020-07-09 14:54:23.0 +0300
@@ -1,3 +1,19 @@
+storebackup (3.2.1-2~deb9u1) stretch; urgency=medium
+
+ * QA upload.
+ * Rebuild for stretch.
+
+ -- Adrian Bunk Thu, 09 Jul 2020 14:54:23 +0300
+
+storebackup (3.2.1-2) unstable; urgency=medium
+
+ * QA upload.
+ * Set maintainer to Debian QA Group. (see #856299)
+ * Add patch to change the way the lockfile is opened in the Perl code.
+(Fixes: CVE-2020-7040) (Closes: #949393)
+
+ -- Adrian Bunk Wed, 08 Jul 2020 15:54:21 +0300
+
storebackup (3.2.1-1) unstable; urgency=low
* change short description, recommendation from Heinz-Josef Claes
diff -Nru storebackup-3.2.1/debian/control storebackup-3.2.1/debian/control
--- storebackup-3.2.1/debian/control2012-06-16 13:21:56.0 +0300
+++ storebackup-3.2.1/debian/control2020-07-08 15:54:21.0 +0300
@@ -1,7 +1,7 @@
Source: storebackup
Section: utils
Priority: optional
-Maintainer: Ryan Niebur
+Maintainer: Debian QA Group
Build-Depends: debhelper (>= 7.2), perl
Standards-Version: 3.9.3
Homepage: http://www.nongnu.org/storebackup/
diff -Nru storebackup-3.2.1/debian/patches/CVE-2020-7040.patch
storebackup-3.2.1/debian/patches/CVE-2020-7040.patch
--- storebackup-3.2.1/debian/patches/CVE-2020-7040.patch1970-01-01
02:00:00.0 +0200
+++ storebackup-3.2.1/debian/patches/CVE-2020-7040.patch2020-07-08
15:54:21.0 +0300
@@ -0,0 +1,27 @@
+Description: changing the way the lockfile is opened in the Perl code
+Author: Jan Ritzerfeld
+Author: Utkarsh Gupta
+Bug-Debian: https://bugs.debian.org/949393
+Origin: https://www.openwall.com/lists/oss-security/2020/01/20/3/1
+Last-Update: 2020-02-04
+
+--- a/lib/fileDir.pl
b/lib/fileDir.pl
+@@ -22,7 +22,7 @@
+
+ push @VERSION, '$Id: fileDir.pl 364 2012-02-12 14:14:44Z hjc $ ';
+
+-use Fcntl qw(O_RDWR O_CREAT);
++use Fcntl qw(O_RDWR O_CREAT O_WRONLY O_EXCL);
+ use POSIX;
+
+ require 'prLog.pl';
+@@ -404,7 +404,7 @@
+ '-str' => ["creating lock file <$lockFile>"]);
+
+ &::checkDelSymLink($lockFile, $prLog, 0x01);
+-open(FILE, "> $lockFile") or
++sysopen(FILE, $lockFile, O_WRONLY | O_CREAT | O_EXCL) or
+ $prLog->print('-kind' => 'E',
+ '-str' => ["cannot create lock file <$lockFile>"],
+ '-exit' => 1);
diff -Nru storebackup-3.2.1/debian/patches/series
storebackup-3.2.1/debian/patches/series
--- storebackup-3.2.1/debian/patches/series 2012-06-16 13:19:48.0
+0300
+++ storebackup-3.2.1/debian/patches/series 2020-07-08 15:54:21.0
+0300
@@ -1 +1,2 @@
fix-spelling-error-in-manpage
+CVE-2020-7040.patch
Bug#964188: crashes in latest chromium
This should fix it: https://salsa.debian.org/chromium-team/chromium/-/commit/b904fa41d40b967dcc8f6984db52f7a2f6a2c83d We are not building with GCC but this seems to be exactly the place where the crash happens. chromium built with this patch has not crashed for the last few hours for me, while before it would crash in a few minutes. Riku
Bug#662692: Time When?
It should probably be an option. The saytime --boop option. "At the tone, the time will be blah blah blah ... BOOP!"
Bug#954828: debmake: Node.js package support
Hi Pirate Praveen,
My recent 4.3.2-1 upload of debmake to sid enables node.js experimental
support.
Please check this uploaded sid package solved #954828 and respond to me
on questions below.
Once these are done, I will make source-only to get this package
migrated to the testing ;-)
I have not updated manpage yet. Let me explain
-w option now understand -w "nodejs" to use "dh --with nodejs" in
debian/rules.
-b option now understand -b "node-packageneme:nodejs" to specify the
binary package name and type. You can also write as
-b "node-packageneme:no"(This is short-form)
-b "node-packageneme:js"(This is alias)
-b "node-packageneme" (This is automatic type setting by initial
part of name "node-"
If this is a single arch all binary package case, it does right thing
without these options just guessing from package.json existence.
Currently, I don't force binary package dependency to "nodejs" within
debmake since that should be added through ${misc:Depends} . Is it
working? If not, please make "dh --with nodejs" to add "nodejs"
through ${misc:Depends} .
What I am not sure is "Is nodejs the only javascript platform to
address for debmake?".
Osamu
On Wed, 2020-07-08 at 17:27 -0400, Boyuan Yang wrote:
> Source: debmake
> Version: 4.3.2-1
> Tags: sid
>
> Hi Osamu,
>
> Thanks for refreshing debmake package. However, the most recently
> upload was
> not a source-only upload. Please consider making another source-only
> upload so
> that the new version can properly migrate to Debian Testing. The
> details about
> source-only upload can be found at
> https://wiki.debian.org/SourceOnlyUpload .
>
> Thanks,
> Boyuan Yang
Bug#964451: chromium (83.0.4103.116-1~deb10u2) constantly crashes and slow
Package: chromium Version: 83.0.4103.116-1~deb10u2 Followup-For: Bug #964451 Dear Maintainer, Chromium 83.0.4103.116-1~deb10u2 constantly crashes after starting in few minuts. I'm shocked that this is in a stable branch and there are still no fix :( -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 83.0.4103.116-1~deb10u2 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.6-1~deb10u1 ii libavformat587:4.1.6-1~deb10u1 ii libavutil56 7:4.1.6-1~deb10u1 ii libc62.28-10 ii libcairo21.16.0-4 ii libcups2 2.2.10-6+deb10u3 ii libdbus-1-3 1.12.16-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-2+deb10u1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgbm1 18.3.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6+deb10u1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1+deb10u2 ii libopenjp2-7 2.3.0-2+deb10u1 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libpulse012.2-4+deb10u1 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-6 ii libvpx5 1.7.0-3+deb10u1 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-dri3-01.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2.2~deb10u1 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 83.0.4103.116-1~deb10u2 Versions of packages chromium suggests: pn chromium-driver ii chromium-l10n83.0.4103.116-1~deb10u2 pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1+deb10u1 Versions of packages chromium-common recommends: ii chromium-sandbox 83.0.4103.116-1~deb10u2 ii dunst [notification-daemon]1.3.2-1 ii fonts-liberation 1:1.07.4-9 ii gnome-shell [notification-daemon] 3.30.2-11~deb10u1 ii libgl1-mesa-dri18.3.6-2+deb10u1 ii libu2f-udev1.1.9-1 ii notification-daemon3.20.0-4 ii upower 0.99.10-1 Versions of packages chromium-sandbox depends on: ii libc6 2.28-10 -- no debconf information
Bug#964715: buster-pu: package mydumper/0.9.5-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
* Link mydumper against libm. (Closes: #956020)
libmariadb-dev removed some libraries like -lssl and -lm
from Libs in the pkg-config file.
This is correct, and reduces the amount of unnecessary linking.
But in mydumper this exposed a missing -lm
(OpenSSL is not used directly by mydumper).
gcc appears to inline the one call to ceil() on all release
architectures except armel/armhf/mips/mipsel, only on these
architectures did the libmariadb-dev change expose the FTBFS.
diff -Nru mydumper-0.9.5/debian/changelog mydumper-0.9.5/debian/changelog
--- mydumper-0.9.5/debian/changelog 2018-12-19 11:17:53.0 +0200
+++ mydumper-0.9.5/debian/changelog 2020-07-09 15:25:49.0 +0300
@@ -1,3 +1,10 @@
+mydumper (0.9.5-1+deb10u1) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Link mydumper against libm. (Closes: #956020)
+
+ -- Adrian Bunk Thu, 09 Jul 2020 15:25:49 +0300
+
mydumper (0.9.5-1) unstable; urgency=medium
* New upstream release (Closes: #897913)
diff -Nru mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch
mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch
--- mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch
1970-01-01 02:00:00.0 +0200
+++ mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch
2020-07-09 15:25:49.0 +0300
@@ -0,0 +1,26 @@
+From 47b179ace22a2b4f4e5a3e783d6a79cc44a65708 Mon Sep 17 00:00:00 2001
+From: Adrian Bunk
+Date: Fri, 8 May 2020 20:12:57 +0300
+Subject: Link mydumper against libm
+
+This is required due to mydumper.c using ceil().
+---
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index ca9591f..ea4bb85 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -37,7 +37,7 @@ if (WITH_BINLOG)
+ else (WITH_BINLOG)
+ add_executable(mydumper mydumper.c server_detect.c g_unix_signal.c
connection.c getPassword.c)
+ endif (WITH_BINLOG)
+-target_link_libraries(mydumper ${MYSQL_LIBRARIES} ${GLIB2_LIBRARIES}
${GTHREAD2_LIBRARIES} ${PCRE_PCRE_LIBRARY} ${ZLIB_LIBRARIES} stdc++)
++target_link_libraries(mydumper ${MYSQL_LIBRARIES} ${GLIB2_LIBRARIES}
${GTHREAD2_LIBRARIES} ${PCRE_PCRE_LIBRARY} ${ZLIB_LIBRARIES} stdc++ m)
+
+
+ add_executable(myloader myloader.c connection.c getPassword.c)
+--
+2.20.1
+
diff -Nru mydumper-0.9.5/debian/patches/series
mydumper-0.9.5/debian/patches/series
--- mydumper-0.9.5/debian/patches/series2018-12-19 11:17:53.0
+0200
+++ mydumper-0.9.5/debian/patches/series2020-07-09 15:25:49.0
+0300
@@ -1,3 +1,4 @@
0001-manpage-whatis-description.patch
0002-dont-install-documentation-source.patch
0005-fix-cmake-define-ssl
+0001-Link-mydumper-against-libm.patch
Bug#964678: dictionaries-common: FTBFS: Can't locate TheWML/Backends/Slice/Main.pm in @INC
Control: affects -1 + dictionaries-common Hi, Agustin Martin wrote: > This seems due to new slice package built from wml missing a > dependency on wml. Reassigning Thanks for reassigning! It probably is no missing dependency but not properly distributed files over the two generated binary packages. Unfortunately I haven't yet an autopkgtest which tests slice separately. Will have a closer look later today and try to make a slice-only autopkgtest, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#964716: Updating the nut Uploaders list
Source: nut Version: 2.7.4-8 2.7.2-4 2.7.4-12 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Arnaud Quette has retired, so can't work on the nut package anymore (at least with this address). We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. signature.asc Description: PGP signature
Bug#964591: kodi FTBFS with libmicrohttpd 0.9.71
Control: owner -1 = Hi Adrian! This bug was already reported upstream by Gentoo maintainer Chris Andrews: https://github.com/xbmc/xbmc/pull/18131 I will notify the upstream that Leia is also affected so once the fix is merged to master, there will be Leia backport closing this bug. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#964717: cpio: Please make another source-only upload for testing migration
Source: cpio Version: 2.13+dfsg-3 Severity: important Tags: sid Dear Debian cpio maintainers, The latest upload cpio/2.13+dfsg-3 was not a source-only upload and contains an arch:all package. As a result, this version will not migrate to Debian Testing. Please make another source-only upload to allow testing migration. For details, please see https://wiki.debian.org/SourceOnlyUpload . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#964718: ITS: python-invoke
Package: python3-invoke Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Python Modules People (and Fabric maintainer)! It seems that the python-invoke package is not very well maintained by the Openstack team anymore. They used to require it as a dependency, but do not anymore, which explains the lag. They do not have the interest or capacity to keep on maintaining it and the current maintainer(s) agree that the package should be moved out of the openstack umbrella. I can think of two options: 1. the invoke package is moved to team maintenance, under the DPMT umbrella 2. the current Fabric maintainer (asb, in CC), takes over the invoke package, since the two are so close to each other... It can be a combination of those two, ie. the invoke package could move under to DPMT and asb could be uploader, for example... I am also volunteering to be an uploader, but would probably also put the package under DPMT... I have already uploaded a NMU+10 for the 1.4.1 release, yesterday, along with a backport of 1.3.0 to buster... And for the record, I plan to also backport Fabric when the latter lands. I should also mention that zigo, the current invoke maintainer, is the one who suggested to move to DPMT and agrees with this salvage operation. So I guess we have already passed the 5.12.2 bar in that the salvage operation is approve. We just need to figure out who will carry this package forward from here on. Thanks! -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEexZCBNCWcjsBljWrPqHd3bJh2XsFAl8HHZoACgkQPqHd3bJh 2XtT3Af9HuOsDJ9TFmgUjEm9NF1QqljhTGh1VGn5XFi6hARgZG9WXd/pgqSXzM7U vvTxdne4Kyl6kNtqiql4tSGuUZalhE1SrCH31TU7KD9GsNXVukD9la+X6xWsA+tp aW/NcwG4gzv8jyEKDpJF6GIBR7tdxkWd/NrD2myWVsiruecrnnEY/NmcKoZAGymj ZT+GPT+OoGthO+tLxVUiwfAEQIsPs9dL7l7n7vjeZDXo6LlmrOq6Jexb4T2Erkgc EHdKtBPROdYwHjERtQKq9PdKSFDEEiOHmVCvCZjsK3c1gh7i0qgEuU9EId9xtPI6 bgoK63UUO2tp53N71L3pD4i29/G0Yw== =DX9k -END PGP SIGNATURE-
Bug#964641: musescore: FTBFS: qmetatype.h:818:16: error: ambiguous overload for ‘operator<<’ (operand types are ‘QDataStream’ and ‘const Ms::SessionStart’)
tags 964641 + confirmed pending thanks Lucas Nussbaum dixit: >During a rebuild of all packages in sid, your package failed to build Indeed, I’ve got patches for Qt 5.14 compatibility queued but hadn’t had enough tuits to prepare an upload yet. I’ll do that soonish. Thanks, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#964719: vagrant with provider docker don't start because of bad naming
Package: vagrant
Version: 2.2.9+dfsg-1
Severity: normal
Hello
Vagrant running with provider as docker and with default settings will
not start due to its naming, unless .name field is explicitly given in
Vagrantfile. This is not the case for other providers.
Below is the stderr
Command: ["docker", "run", "--name", "_default_1594301896", "-d", "-v",
"/:/vagrant", "docker.io/roboxes/centos6:latest", {:notify=>[:stdout,
:stderr]}]
/usr/bin/docker: Error response from daemon: Invalid container name
(_default_1594301896), only [a-zA-Z0-9][a-zA-Z0-9_.-] are allowed.
See '/usr/bin/docker run --help'
This is solved by having something similar in my Vagrantfile
config.vm.provider "docker" do |d|
d.name = "foo-bar"
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages vagrant depends on:
ii curl7.68.0-1
ii libarchive-tools3.4.0-2
ii openssh-client 1:8.2p1-4
ii rsync 3.1.3-8
ii ruby1:2.7+1
ii ruby-bcrypt-pbkdf 1.0.1-1+b2
ii ruby-childprocess 3.0.0-1
ii ruby-ed255191.2.4-1+b3
ii ruby-erubis 2.7.0-3
ii ruby-i18n 1.8.3-1
ii ruby-listen 3.1.5-2
ii ruby-log4r 1.1.10-4
ii ruby-net-scp3.0.0-1
ii ruby-net-sftp 1:2.1.2-4
ii ruby-net-ssh1:6.1.0-1
ii ruby-rest-client2.0.2-3.1
ii ruby-vagrant-cloud 2.0.3-1
ii ruby-zip2.0.0-2
Versions of packages vagrant recommends:
ii vagrant-libvirt 0.0.45-2
Versions of packages vagrant suggests:
pn virtualbox
-- no debconf information
Bug#964720: Wrong paths to pgpewrap
Package: neomutt
Version: 20180716+dfsg.1-1+deb10u1
Severity: important
Hello,
thank you for maintaining neomutt!
It looks like sometimes at some point the paths to pgpewrap changed from
/usr/libexec/ to /usr/lib/, and the default configuration did not get updated
accordingly:
$ dpkg -L neomutt|grep pgpewrap
/usr/lib/neomutt/pgpewrap
$ rgrep pgpewrap /etc/neomuttrc*
/etc/neomuttrc.d/gpg.rc:# set
pgp_encrypt_only_command="/usr/libexec/neomutt/pgpewrap gpg-2comp -v --batch
--output - --encrypt --textmode --armor --always-trust -- -r %r -- %f"
/etc/neomuttrc.d/gpg.rc:set
pgp_encrypt_only_command="/usr/libexec/neomutt/pgpewrap gpg --batch --quiet
--no-verbose --output - --textmode --armor --encrypt -- --recipient %r -- %f"
/etc/neomuttrc.d/gpg.rc:# set
pgp_encrypt_sign_command="/usr/libexec/neomutt/pgpewrap gpg-2comp
%?p?--passphrase-fd 0? -v --batch --output - --encrypt --sign %?a?-u %a?
%--armor --always-trust -- -r %r -- %f"
/etc/neomuttrc.d/gpg.rc:set
pgp_encrypt_sign_command="/usr/libexec/neomutt/pgpewrap gpg %?p?--pinentry-mode
loopback --passphrase-fd 0? --batch --quiet %--no-verbose --textmode --output -
%?a?--local-user %a? --armor --sign %--encrypt -- --recipient %r -- %f"
As a consequence, neomutt isn't currently able to send encrypted emails by
default.
Enrico
-- Package-specific info:
NeoMutt 20180716
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 5.6.0-0.bpo.2-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1.20181013)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet
Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/lib
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-HR05dz/neomutt-20180716+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
+bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens +getaddrinfo
+gnutls +gpgme +gss +hcache -homespool +idn -locales_hack +lua +meta
+mixmaster +nls +notmuch -openssl +pgp +sasl +smime +start_color
+sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: 10.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: a
Bug#837708: thunar: Segfault after file rename
Package: thunar Version: 1.8.15-1 Followup-For: Bug #837708 Dear Maintainer, just renamed a file and the application segfaulted. Here the journal trace: kernel: thunar[131727]: segfault at 48 ip 556a102c4740 sp 7ffe03738798 error 4 in thunar[556a1029a000+7c000] kernel: Code: 50 00 00 00 e8 21 68 fd ff 48 89 c7 e8 e9 b2 fd ff e9 c9 fe ff ff e8 1f 8a fd ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <48> 8b 47 48 c3 66 66 2e 0f 1f 84 00 00 00 00 00 41 54 49 89 d4 55 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.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunar depends on: ii desktop-file-utils 0.24-1 ii exo-utils 0.12.11-1 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-8 ii libcairo2 1.16.0-4 ii libexo-2-0 0.12.11-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-02.64.3-2 ii libgtk-3-0 3.24.20-1 ii libgudev-1.0-0 233-1 ii libice6 2:1.0.9-2 ii libnotify4 0.7.9-1 ii libpango-1.0-0 1.44.7-4 ii libsm6 2:1.2.3-1 ii libthunarx-3-0 1.8.15-1 ii libxfce4ui-2-0 4.14.1-1+b1 ii libxfce4util7 4.14.0-1 ii libxfconf-0-3 4.14.3-1 ii shared-mime-info1.15-1 ii thunar-data 1.8.15-1 Versions of packages thunar recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.20-1 ii gvfs 1.44.1-1 ii libxfce4panel-2.0-4 4.14.4-1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7 ii thunar-volman 0.9.5-1+b1 ii tumbler 0.2.8-2 ii udisks2 2.9.0-1 ii xdg-user-dirs 0.17-2 Versions of packages thunar suggests: pn thunar-archive-plugin pn thunar-media-tags-plugin -- no debconf information
Bug#964681: klibc: FTBFS: ld: cannot use executable file 'usr/klibc/libc.so' as input to a link (was Re: Bug#964681: klibc: FTBFS: ENOENT (2) => "No such file or directory")
retitle 964681 klibc: FTBFS: ld: cannot use executable file 'usr/klibc/libc.so' as input to a link thanks Lucas Nussbaum dixit: >> ld -m elf_x86_64 --build-id=sha1 -o usr/kinit/ipconfig/shared/ipconfig -e >> main usr/klibc/interp.o --start-group usr/kinit/ipconfig/main.o >> usr/kinit/ipconfig/netdev.o usr/kinit/ipconfig/packet.o >> usr/kinit/ipconfig/dhcp_proto.o usr/kinit/ipconfig/bootp_proto.o -R >> usr/klibc/libc.so /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a --end-group ; cp >> -f usr/kinit/ipconfig/shared/ipconfig usr/kinit/ipconfig/shared/ipconfig.g ; >> true --strip-all -R .comment -R .note --strip-all -R .comment -R .note >> --strip-all -R .comment -R .note usr/kinit/ipconfig/shared/ipconfig >> ld: cannot use executable file 'usr/klibc/libc.so' as input to a link This seems to be the real error. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#964547: thunderbird: I want to move or copy folder structures between mailboxes
On 2020-07-08 18:22, Carsten Schoenert wrote: Am 08.07.20 um 23:51 schrieb Gary Dale: Do you think I want to do it this way? This is how Thunderbird makes me. I've no idea how you do this or want to do this, I was just showing how I simply drag an shove folders for years as it works for years. No matter if I do this between two active accounts or if I shove the folder to the local account. I've migrated a few POP3 account to IMAP over the time and long ago, also with some more complex folder structures, I can't remember that was that difficult in the end. I do it the way you say works. It doesn't. I have to create the first level folder structure in the IMAP account, I don't have to do this, I simply drag the folder ... ...>> I've played around with the behavior of .sdb folder together with .msf If I drag the folder, it creates the folder in the new location but doesn't copy the e-mail. Nor does it include subfolders. Dragging is just another way of creating the folders. files also long ago. Basically you can copy the .sdb folder anywhere, you also need to create an equally named empty file .msf too then, the folder will already then be visible so far I remember, once you tell TB to compress the folder TB will recreate the index data for the folder and all emails are readable again. Except that Thunderbird deletes everything it didn't create. So there are no files for it to reindex. I guess you will find a lot of websites and blogs that explain in deep how to do this if you want or need to do this at that low level side. I will not figure out this for you as this all isn't a Debian issue right now for. Perhaps it's not a Debian issue but it is a Thunderbird issue. I'm running it on Debian so if you are sure it's not Debian specific then shouldn't you pass the issue up the line? However it seems like Thunderbird has its own ideas of what is proper. I suspect that its getting it folder information from the remote server if it's not storing it locally. Either way the folders are wiped out. You again assuming and assuming, that's isn't helpful. No, the data from the email server is getting downloaded by POP3 or IMAP protocol and then stored locally. Turn on the debug mode and you will this for every single email. I don't need a debug mode to see what it does. Debug mode may show the how/why but the effects are still clear. ... The Debian wiki has some more hints about issue reporting, in case you haven't noted this already. https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues There are also some hint on debugging activity, you will need to replace references to icedove with thunderbird mostly. https://wiki.debian.org/Icedove#Debugging The reference to icedove is probably just the folder used to store e-mail. The fact that it says icedove just shows when the accounts were set up in Thunderbird. Before then I was using Netscape with it's integrated mail program - when it got split up, I had to recreate the account setup but mostly kept the mail folders. I have a few newer accounts that go into .icedove but others actually use a very old Netscape file structure on a shared device. I tried moving the IMAP box to .icedove but that doesn't seem to have helped with the problems - not even noticeably speeding up the copies. You don't even have seemed tried to use this possibility to debug what Thunderbird is doing ... I was only saying that you will need to adjust the call for this kind of debugging. The only add-on I have is the one to manually sort the accounts, something that Thunderbird probably should do by itself - seems like an almost trivial operation... People always do differ on such things, and as a corporation the decision makers have to draw a line. If costumers pay the developers for integrating new features it might happen, depending on the priorities. This situation has changed for Thunderbird dramatically as Mozilla has decided that Thunderbird isn't a core part anymore. Imagine if Dolphin developers took the view that dragging a folder to a new location isn't Dolphin's job? Most dialogues that have folder views allow for simple drag & drop rearrangement. The reason I'm going through this is because Yahoo doesn't let me send mail from the POP3 account and Thunderbird stops downloading POP3 e-mail every couple of days. It seemed like time to bite the bullet and switch to IMAP but the process is far more painful than it really should be. Well as said, Yahoo is also a kind of special like Hotmail in the past or Outlook365 in newer days. It's far away to use RFC conform standards. So don't be surprised if not all is working well except you use the webUI. I could ask why doesn't Thunderbird support switching from POP3 to IMAP (and vice versa). On the face of it, it looks like simply changing some names and values - which is what you also seem to be claiming. Instead this is a multi-day effort that I am only partway through. These are all question
Bug#964451: chromium (83.0.4103.116-1~deb10u2) constantly crashes and slow
>>> apt policy chromium chromium: Installed: 83.0.4103.116-1~deb10u2 Candidate: 83.0.4103.116-1~deb10u2 >>> apt policy chromium-sandbox chromium-sandbox: Installed: 83.0.4103.116-1~deb10u2 Candidate: 83.0.4103.116-1~deb10u2 Crash report: [104374:104374:0709/162835.256196:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. malloc_consolidate(): invalid chunk size Received signal 6 #0 0x55706b6e8469 (/usr/lib/chromium/chromium+0x51f9468) #1 0x55706b646193 (/usr/lib/chromium/chromium+0x5157192) #2 0x55706b6e7ff1 (/usr/lib/chromium/chromium+0x51f8ff0) #3 0x7f7bf4e733c0 (/lib/x86_64-linux-gnu/libpthread-2.31.so+0x153bf) #4 0x7f7befa9118b gsignal #5 0x7f7befa70859 abort #6 0x7f7befadb3ee (/lib/x86_64-linux-gnu/libc-2.31.so+0x903ed) #7 0x7f7befae347c Received signal 11 SEGV_MAPERR 7f01c8271787 (/lib/x86_64-linux-gnu/libc-2.31.so+0x9847b) #8 0x7f7befae3c58 #0 0x55706b6e8469 (/lib/x86_64-linux-gnu/libc-2.31.so +0x98c57) #9 0x7f7befae5e03 (/usr/lib/chromium/chromium+0x51f9468) #1 0x55706b646193 (/lib/x86_64-linux-gnu/libc-2.31.so+0x9ae02) #10 0x7f7befae8419 __libc_malloc #11 0x(/usr/lib/chromium/chromium+0x5157192)55706b6ffbee #2 0x55706b6e7ff1 operator new() #12 (/usr/lib/chromium/chromium+0x51f8ff0)0x 55706a2185ba# 3 0x7f7bf4e733c0 (/lib/x86_64-linux-gnu/libpthread-2.31.so +0x153bf) #4 0x7f7befae3ba4 (/usr/lib/chromium/chromium+0x3d295b9) #13 0x5570693299c9 (/lib/x86_64-linux-gnu/libc-2.31.so+0x98ba3) #5 0x7f7befae5e03 (/usr/lib/chromium/chromium+0x2e3a9c8) #14 0x55706b81abbe (/lib/x86_64-linux-gnu/libc-2.31.so+0x9ae02) #6 0x7f7befae8419 (/usr/lib/chromium/chromium+0x532bbbd)__libc_malloc ##157 0x0x55706b81ddb355706b6ffbee (/usr/lib/chromium/chromium+0x532edb2) operator new()# 16# 80x 55706b82182f0x 7f7befd9b0f0 (/usr/lib/chromium/chromium+0x533282e) #std::__cxx11::basic_string<>::reserve()17 #0x955706b82100e 0x7f7befd90c1c (/usr/lib/chromium/chromium+0x533200d) #18 0x55706b81ddef (/usr/lib/chromium/chromium+0x532edee) #19 0x55706b81821f std::__cxx11::basic_stringbuf<>::overflow() #10 0x7f7befd993ba std::basic_streambuf<>::xsputn() #11 0x7f7befd8b784 (/usr/lib/chromium/chromium+0x532921e) #20 0x55706b818cec (/usr/lib/chromium/chromium+0x5329ceb) #21 0x55706b83377b std::__ostream_insert<>() #12 0x55706b6e87b9 (/usr/lib/chromium/chromium+0x534477a) #22 0x55706b6949c2 (/usr/lib/chromium/chromium+0x51f97b8) #13 0x55706b6e8844 (/usr/lib/chromium/chromium+0x51a59c1) #23 0x55706b6a4658 (/usr/lib/chromium/chromium+0x51f9843) #14 (/usr/lib/chromium/chromium+0x51b5657)0x 55706b6589d2# 24 0x55706b6a43f3 (/usr/lib/chromium/chromium+0x51b53f2) #25 0x55706b65c9b6 (/usr/lib/chromium/chromium+0x51699d1) #15 0x55706b65ab1e (/usr/lib/chromium/chromium+0x516d9b5) #(/usr/lib/chromium/chromium+0x516bb1d)26 #0x1655706b6a4c05 0x557069dc362a (/usr/lib/chromium/chromium+0x38d4629) #17 0x557069dc367e (/usr/lib/chromium/chromium+0x51b5c04) #27 0x55706b67ca1d (/usr/lib/chromium/chromium+0x38d467d) #18 0x55706946998f (/usr/lib/chromium/chromium+0x518da1c) #28 0x55706b27785c (/usr/lib/chromium/chromium+0x2f7a98e) #19 0x557069d7d559 (/usr/lib/chromium/chromium+0x4d8885b) #29(/usr/lib/chromium/chromium+0x388e558) 0x#5570699e416820 0x557069d7d79e (/usr/lib/chromium/chromium+0x388e79d) #21 0x557069dc6e67 (/usr/lib/chromium/chromium+0x34f5167) #30 0x5570699e6022 (/usr/lib/chromium/chromium+0x38d7e66) #22 0x557069df2ac2 (/usr/lib/chromium/chromium+0x34f7021) #31 0x5570699e132e (/usr/lib/chromium/chromium+0x3903ac1) #23 0x557069df2d7e (/usr/lib/chromium/chromium+0x34f232d)(/usr/lib/chromium/chromium+0x3903d7d) ##3224 0x0x55706b23a2db557069dc363f (/usr/lib/chromium/chromium+0x38d463e) #25 0x557069dc367e (/usr/lib/chromium/chromium+0x4d4b2da) #33 0x55706b239f5d (/usr/lib/chromium/chromium+0x38d467d) #26 0x55706946998f(/usr/lib/chromium/chromium+0x4d4af5c) #34 0x55706b257da1 (/usr/lib/chromium/chromium+0x2f7a98e) #27 0x557069720f53 (/usr/lib/chromium/chromium+0x4d68da0) #35 0x55706b238671 (/usr/lib/chromium/chromium+0x3231f52) #28 0x557069a4be22 (/usr/lib/chromium/chromium+0x4d49670) #36 0x557068e7119e (/usr/lib/chromium/chromium+0x355ce21) #29 0x55706b81baff ChromeMain #37 0x7f7befa720b3 (/usr/lib/chromium/chromium+0x532cafe)__libc_start_main ##3038 0x0x55706b822274557068e7102a _start r8: r9: (/usr/lib/chromium/chromium+0x5333273)7fff758fe260 r10: #000831 r11: 02460x 55706b82016d r12: 7fff758fe4d0 r13: 0010 r14: 7f7bd4585000 r15: 0001 di: 0002 si: 7fff758fe260 bp: 7fff758fe5b0 bx: 7f7be79a1f00 dx: ax: cx: 7f7befa9118b sp: 7fff758fe260 ip: 7f7befa9118b efl: 0246 cgf: 002b0033 erf: trp: (/usr/lib/chromium/chromium+0x533116c) msk: #32 cr2: 0x 55706b81ee2c[end of stack trace] Calling _exit(1). Core file will not be generated.
Bug#963810: Fwd: Re: Bug#963810: Re: Bug#963810: RFS: mcu8051ide/1.4.9-2 [QA] -- Graphical Integrated Development Environment for 8051
- Original message - From: Andrej Shadura To: debian-ment...@lists.debian.org Subject: Re: Bug#963810: Re: Bug#963810: RFS: mcu8051ide/1.4.9-2 [QA] -- Graphical Integrated Development Environment for 8051 Date: Wednesday, 8 July 2020 20:53 Hi, On Tue, 7 Jul 2020, at 03:55, charlesmel...@outlook.com wrote: > On Mon, 06 Jul 2020 18:49:55 +0200 "Andrej Shadura" wrote: > > Just to make it clear, I have not forgotten about it; in fact, I will > > upload it later today, but I’m finishing some last touches to the package. > > Thanks, I'm new around the mentors so I did not know if I should reply or wait > a little longer. I started to package a few weeks ago so I'd like to receive > some feedback if possible (I know it takes time but would be really helpful). I took your changes with a couple of modifications, mainly split them into separate Git each and reworded the changelog entries. I have also pushed it all to Salsa: https://salsa.debian.org/debian/mcu8051ide.git One change I had to back out was the binary "patch" for the manpage. I’m not sure how well the `include-binaries` feature you used works, but I’ve never used it before, and dgit (which I use to upload packages) refused to allow me to proceed, so I reverted to the changed manpage residing in debian/. Thanks for your contribution, I would be happy to sponsor more packages from you. -- Cheers, Andrej
Bug#963761: node-node-sass: missing versioned dependency relation?: Sass could not find a binding for your current environment
On Fri, 26 Jun 2020 18:27:30 +0200 Paul Gevers wrote: > + grunt sass nodeunit > Loading "gruntfile.js" tasks...ERROR > >> Error: Missing binding > /usr/lib/x86_64-linux-gnu/nodejs/node-sass/vendor/linux-x64-72/binding.node > >> Node Sass could not find a binding for your current environment: > Linux 64-bit with Node.js 12.x > >> > >> Found bindings for the following environments: > >> - Linux 64-bit with Node.js 10.x It seems as if node-node-sass was built with libnode < 72, and is now being executed on machine also having libnode72. While in principle such situations are possible, more than one libnodeX package are very unlikely to be present. It would probably be worth stripping the /linux-x64-72/ part from /usr/lib/x86_64-linux-gnu/nodejs/node-sass/vendor/linux-x64-72/binding.node and disabling the resolving mechanism altogether. Best, Andrius
Bug#964721: weather-util: please make the build reproducible
Source: weather-util
Version: 2.4-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] we noticed that
weather-util could not be built reproducibly.
This is because it embedded:
a) The current build date, varying on the timezone of the build
server.
b) Timestamps of existing filenames, also varying on the timezone of
the build server.
Patch attached that fixes both issues.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
` a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2020-07-09 15:22:07.073550632
+0100
@@ -0,0 +1,74 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2020-07-09
+
+--- weather-util-2.4.orig/weather.py
weather-util-2.4/weather.py
+@@ -1268,56 +1268,56 @@ def correlate():
+ weather_copyright,
+ os.path.basename( sys.argv[0] ),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( time.time() )
++datetime.datetime.utcfromtimestamp(
int(os.environ.get('SOURCE_DATE_EPOCH', time.time())) )
+ ),
+ hashlib.md5( open(gcounties_an, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(gcounties_an) )
++datetime.datetime.utcfromtimestamp(
os.path.getmtime(gcounties_an) )
+ ),
+ gcounties_an,
+ hashlib.md5( open(gcousubs_an, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(gcousubs_an) )
++datetime.datetime.utcfromtimestamp( os.path.getmtime(gcousubs_an)
)
+ ),
+ gcousubs_an,
+ hashlib.md5( open(gplace_an, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(gplace_an) )
++datetime.datetime.utcfromtimestamp( os.path.getmtime(gplace_an) )
+ ),
+ gplace_an,
+ hashlib.md5( open(gzcta_an, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(gzcta_an) )
++datetime.datetime.utcfromtimestamp( os.path.getmtime(gzcta_an) )
+ ),
+ gzcta_an,
+ hashlib.md5( open(cpfzcf_fn, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(cpfzcf_fn) )
++datetime.datetime.utcfromtimestamp( os.path.getmtime(cpfzcf_fn) )
+ ),
+ cpfzcf_fn,
+ hashlib.md5( open(nsd_fn, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(nsd_fn) )
++datetime.datetime.utcfromtimestamp( os.path.getmtime(nsd_fn) )
+ ),
+ nsd_fn,
+ hashlib.md5( open(ourairports_fn, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(ourairports_fn)
)
++datetime.datetime.utcfromtimestamp(
os.path.getmtime(ourairports_fn) )
+ ),
+ ourairports_fn,
+ hashlib.md5( open(overrides_fn, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(overrides_fn) )
++datetime.datetime.utcfromtimestamp(
os.path.getmtime(overrides_fn) )
+ ),
+ overrides_fn,
+ hashlib.md5( open(slist_fn, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(slist_fn) )
++datetime.datetime.utcfromtimestamp( os.path.getmtime(slist_fn) )
+ ),
+ slist_fn,
+ hashlib.md5( open(zlist_fn, "rb").read() ).hexdigest(),
+ datetime.date.isoformat(
+-datetime.datetime.fromtimestamp( os.path.getmtime(zlist_fn) )
++datetime.datetime.utcfromtimestamp( os.path.getmtime(zlist_fn) )
+ ),
+ zlist_fn
+ )
--- a/debian/patches/series 2020-07-09 12:08:21.283653753 +0100
--- b/debian/patches/series 2020-07-09 12:26:27.908128181 +0100
@@ -1,2 +1,3 @@
fhs.patch
pypath.patch
+reproducible-build.patch
--- a/weather.py2020-07-09 12:08:21.263653502 +0100
--- b/weather.py2020-07-09 15:22:05.169514142 +0100
@@ -1268,56 +1268,56 @@
weather_copyright,
os.path.basename( sys.argv[0] ),
datetime.date.isoformat(
-datetime.datetime.fromtimestamp( time.time() )
+datetime.datetime.utcfromtimestamp(
int(os.environ.get('SOURCE_DATE_EPOCH', time.time())) )
Bug#963010: [Pkg-roundcube-maintainers] Bug#963010: Acknowledgement (roundcube-core: roundcube upgrade keeps breaking my instance due to automatic permission changes of config.inc.php)
On 6/17/20 5:23 PM, Guilhem Moulin wrote: > On Wed, 17 Jun 2020 at 17:09:01 +0200, Mirko Vogt wrote: > [..] > (FWIW my “please use the Debian BTS” wasn't an invitation to file a bug > in this case, but to query the BTS to check if the issue was already > reported and/or fixed.) > While I'm not interested in crashing another party without invitation: The issue hit me once again tonight. Same result, same reason. Can I do anything to push this being fixed or workaround this myself without weakening my setup security wise? Thanks!
Bug#961143: gpg-wks-client: /usr/lib/gnupg/gpg-wks-client binary provided outside of $PATH
This surprised me too, but it is apparently an explicit choice made by upstream. gpg-wks-client(1) man page: > gpg-wks-client is not commonly invoked directly and thus it is not > installed in the bin directory. debian/gpg-wks-client.lintian-overrides: > # these binaries are stored in /usr/lib/gnupg, as recommended by upstream: > gpg-wks-client: manpage-without-executable > usr/share/man/man1/gpg-wks-client.1.gz
Bug#964722: debrebuild: please add option for rebuilding in the same path
Package: devscripts Version: 2.20.4 Severity: wishlist User: devscri...@packages.debian.org Usertags: debrebuild Dear Maintainer, please add an option (--rebuild-in-same-path?) for rebuilding in the same path as the .buildinfo specified. Thus the generated sbuild call needs to call sbuild using the --build-path=XXX option, where XXX is the path from the .buildinfo file. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#953205: Possibly fixed in Testing
On Fri, 15 May 2020 09:57:47 -0700 Soren Stoutner wrote: > With the updates in Testing as of 5/15/20, this appears to no longer be > an issue (probably because of some updated dependency). Now it is the > opposite: if `require "uri/generic"` is commented out, an error is > produced. If it is not commented out, updates to Redmine work correctly. So the issue seems to be caused by some dependency, not Redmine itself. If so, could this issue be closed then? Best, Andrius
Bug#964599: Roundcube-core Overwrites Local Changes in _styles.less
Package: roundcube-core Version: 1.4.7+dfsg.1-1~bpo10+1 _styles.less, located in /usr/share/roundcube/skins/elastic/styles, is a file that exists for local customizations of the roundcube templates. The file, as shipped by Debian has one line in it, that reads: /* Here you can put your custom styles that will be appended to the output css file */ However, any customization placed in that file is overwritten upon the next update. Apt doesn't ask whether I want to keep the changes or use the new one -- it simply overwrites my local changes. I suggest that apt prompt the user how to proceed with this file. If there are local changes, then the system should run (or remind the user that they will need to run): lessc -x styles.less > styles.css to import their local customization back into the styles.css after the update. I am using Debian 10.4, kernel 4.19.0-9-amd64, and libc6 2.28-10.
Bug#963010: roundcube-core: roundcube upgrade keeps breaking my instance due to automatic permission changes of config.inc.php
Hi, On Thu, 09 Jul 2020 at 16:53:03 +0200, Mirko Vogt wrote: > Can I do anything to push this being fixed or workaround this myself > without weakening my setup security wise? Thanks! The bug metadata say: Found in versions roundcube-core/1.2.3+dfsg.1-4+deb9u3, roundcube-core/1.3.13+dfsg.1-1~deb10u1, roundcube-core/1.3.10+dfsg.1-1~deb10u1 Fixed in versions roundcube-core/1.4.3+dfsg.1-1 So right now versions in testing, sid, and buster-backports are unaffected, while those in buster, buster-security and stretch and stretch-security (or anything earlier) are affected. Some work has been done in the postinst script in 1.4 so the fix doesn't apply to 1.3.14+dfsg.1-1~deb10u1. It might be possible to write a targeted patch and convince the release team to accept it as a stable-proposed-updates, but I personally don't plan to work on that. -- Guilhem. signature.asc Description: PGP signature
Bug#964723: Ordering of entries: the calibre opens everything problem
Package: mime-support Version: 3.62 Severity: important Hello, thank you for maintaining mime-support. >From what I understand, entries in /etc/mailcap are sorted by package name. As a consequence, people who install, for example, calibre, will find that it opens quite a lot of file types (which it can do), with a higher priority over the software one would expect: calibre comes alphabetically before evince, okular, libreoffice, and most other packages. There is only a limited way to control this system-wide with /etc/mailcap.order, and no way for users to control ordering. As a user, I can grep /etc/mailcap and paste my preferred entries in ~/.mailcap, but at that point I have hardcoded those command lines in a way outside the control of package maintainers. Suppose that a package has an exploitable command line, and given #928037 it might well be, and a new version fixes it in its mime information, my ~/.mailcap will be stuck with the exploitable version forever. Suppose that a package changes command line options and updates its mime information correctly, my ~/.mailcap will be stuck with a nonfunctioning command line, and I'll spend an afternoon trying to figure out why mutt suddenly can't open PDFs anymore, retracing and relearning the chain of commands and configuration files that go on behind the scenes. I personally found it really nontrivial to figure out. I'm trying to resist the temptation to write and package a tool called aaanything that uses aalib to display as many file types as possible, and provides mime informations accordingly, so that it will sort before pretty much any other package. What I did as a workaround in my system[1], was to add entries in my ~/.mailcap that delegate to xdg-open, like: application/pdf; xdg-open %s && sleep 0.3s; test=test -n "$DISPLAY" Is there a reason this kind of behaviour could not be a default? I'm opening this issue to document this kind of surprising and possibly dangerous behaviour coming out of the way mime-support works. I can't think of many options besides delegating to xdg-open: there doesn't seem a way for packages to declare a priority for their mime support, and even if there was, it would be arbitrary. I could think of packaging something that diverted run-mailcap to a wrapper to xdg-open, falling back to the original run-mailcap if xdg-open doesn't have a mapping, or if DISPLAY is not set. I could think of packaging a program called 0xdg-mime that depends on xdg-utils and registers xdg-open as mime handler for as many entries as possible. I really don't feel good about the current situation being the standard user interface for mime handling in Debian. Enrico [1] https://www.enricozini.org/blog/2020/debian/mime-type-associations/ -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled mime-support depends on no packages. Versions of packages mime-support recommends: ii bzip2 1.0.6-9.2~deb10u1 ii file 1:5.35-4+deb10u1 ii xz-utils 5.2.4-1 mime-support suggests no packages. -- no debconf information
Bug#964725: texlive-latex-recommended: Package xparse (required for example via mdframed) gives Undefined control sequence
Package: texlive-latex-recommended
Version: 2020.20200629-1
Severity: important
Dear Maintainer,
An article I was working on started to throw me lots and lots of errors and not
generating any PDF when passed to `pdflatex` after the last upgrade of Texlive.
I reduced the problem to the followint test case:
\documentclass{article}
\usepackage{mdframed}
\begin{document}
haha
\end{document}
The errors I get start with:
% pdflatex test.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2020-02-02> patch level 5
L3 programming layer <2020-04-06>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/mdframed/mdframed.sty
(/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
(/usr/share/texlive/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty))
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
! Undefined control sequence.
l.67 \bool
_new:N \g__expl_reload_bool
?
Same happens if I usepackage on "xparse" rather than "mdframed", tho I'm not
familiar with this package so I'm not sure if it's OK to pass that to
usepackage.
-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.
In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.
*** The Debian TeX Team is *not* a LaTeX Help Desk ***
If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.
Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.
Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!
If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at
http://www.minimalbeispiel.de/mini-en.html (english)
or
http://www.minimalbeispiel.de/mini.html (german)
##
minimal input file
##
other files
##
List of ls-R files
-rw-rw-r-- 1 root staff 80 Apr 3 2016 /usr/local/share/texmf/ls-R
-rw-rw-r-- 1 root root 2270 Jul 8 18:24 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jun 8 04:31 /usr/share/texmf/ls-R ->
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jun 28 21:59 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jun 28 21:59 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
-rw-r--r-- 1 root root 80 Apr 14 2014 /usr/share/texlive/texmf/ls-R
##
Config files
-rw-r--r-- 1 root root 475 Jun 16 17:38 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jun 28 21:59 /usr/share/texmf/web2c/fmtutil.cnf ->
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jun 28 21:59 /usr/share/texmf/web2c/updmap.cfg ->
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5033 Jul 8 18:23
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Aug 24 2006 mktex.cnf
-rw-r--r-- 1 root root 475 Jun 16 17:38 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (100, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=
Bug#964726: buster-pu: package jackson-databind/2.9.8-3+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
I would like to update jackson-databind in Buster. It is currently
affected by 20 CVE which are deemed as no-dsa by the security team.
I have added a patch that extends the blacklist to block more classes
from polymorphic deserialization.
Regards,
Markus
diff -Nru jackson-databind-2.9.8/debian/changelog
jackson-databind-2.9.8/debian/changelog
--- jackson-databind-2.9.8/debian/changelog 2019-10-05 19:39:24.0
+0200
+++ jackson-databind-2.9.8/debian/changelog 2020-07-09 17:21:32.0
+0200
@@ -1,9 +1,22 @@
+jackson-databind (2.9.8-3+deb10u2) buster; urgency=medium
+
+ * Add multiple-CVE-BeanDeserializerFactory.patch and block more classes from
+polymorphic deserialization.
+This fixes 20 CVE that currently affect the package namely,
+CVE-2020-9548, CVE-2020-9547, CVE-2020-9546, CVE-2020-8840, CVE-2020-14195,
+CVE-2020-14062, CVE-2020-14061, CVE-2020-14060, CVE-2020-11620,
+CVE-2020-11619, CVE-2020-3, CVE-2020-2, CVE-2020-1,
+CVE-2020-10969, CVE-2020-10968, CVE-2020-10673, CVE-2020-10672,
+CVE-2019-20330, CVE-2019-17531 and CVE-2019-17267.
+
+ -- Markus Koschany Thu, 09 Jul 2020 17:21:32 +0200
+
jackson-databind (2.9.8-3+deb10u1) buster-security; urgency=high
- * Fix CVE-2019-12384, CVE-2019-14439, CVE-2019-14540, CVE-2019-16335,
+ * Fix CVE-2019-12384, CVE-2019-14439, CVE-2019-14540, CVE-2019-16335,
CVE-2019-16942 and CVE-2019-16943. Several deserialization flaws
-were discovered in jackson-databind which could allow an
-unauthenticated user to perform code execution. The issue was
+were discovered in jackson-databind which could allow an
+unauthenticated user to perform code execution. The issue was
resolved by extending the blacklist and blocking more classes from
polymorphic deserialization.
diff -Nru
jackson-databind-2.9.8/debian/patches/multiple-CVE-SubTypeValidator.patch
jackson-databind-2.9.8/debian/patches/multiple-CVE-SubTypeValidator.patch
--- jackson-databind-2.9.8/debian/patches/multiple-CVE-SubTypeValidator.patch
1970-01-01 01:00:00.0 +0100
+++ jackson-databind-2.9.8/debian/patches/multiple-CVE-SubTypeValidator.patch
2020-07-09 17:21:32.0 +0200
@@ -0,0 +1,151 @@
+From: Markus Koschany
+Date: Thu, 9 Jul 2020 16:54:40 +0200
+Subject: multiple CVE SubTypeValidator
+
+This is the fix for
+CVE-2020-9548, CVE-2020-9547, CVE-2020-9546, CVE-2020-8840, CVE-2020-14195,
+CVE-2020-14062, CVE-2020-14061, CVE-2020-14060, CVE-2020-11620, CVE-2020-11619,
+CVE-2020-3, CVE-2020-2, CVE-2020-1, CVE-2020-10969, CVE-2020-10968,
+CVE-2020-10673, CVE-2020-10672, CVE-2019-20330, CVE-2019-17531 and
+CVE-2019-17267.
+---
+ .../databind/jsontype/impl/SubTypeValidator.java | 93 --
+ 1 file changed, 87 insertions(+), 6 deletions(-)
+
+diff --git
a/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java
b/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java
+index d638af9..1d091a7 100644
+---
a/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java
b/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java
+@@ -49,6 +49,9 @@ public class SubTypeValidator
+ // [databind#1737]; 3rd party
+
//s.add("org.springframework.aop.support.AbstractBeanFactoryPointcutAdvisor");
// deprecated by [databind#1855]
+
s.add("org.springframework.beans.factory.config.PropertyPathFactoryBean");
++// [databind#2680]
++s.add("org.springframework.aop.config.MethodLocatingFactoryBean");
++
s.add("org.springframework.beans.factory.config.BeanReferenceFactoryBean");
+
+ // s.add("com.mchange.v2.c3p0.JndiRefForwardingDataSource"); // deprecated by
[databind#1931]
+ // s.add("com.mchange.v2.c3p0.WrapperConnectionPoolDataSource"); // - "" -
+@@ -74,24 +77,26 @@ public class SubTypeValidator
+ s.add("com.sun.deploy.security.ruleset.DRSHelper");
+ s.add("org.apache.axis2.jaxws.spi.handler.HandlerResolverImpl");
+
+-// [databind#2186]: yet more 3rd party gadgets
++// [databind#2186], [databind#2670]: yet more 3rd party gadgets
+ s.add("org.jboss.util.propertyeditor.DocumentEditor");
+ s.add("org.apache.openjpa.ee.RegistryManagedRuntime");
+ s.add("org.apache.openjpa.ee.JNDIManagedRuntime");
++s.add("org.apache.openjpa.ee.WASRegistryManagedRuntime"); // [#2670]
addition
+ s.add("org.apache.axis2.transport.jms.JMSOutTransportInfo");
+
+-// [databind#2326] (2.9.9): one more 3rd party gadget
++// [databind#2326] (2.9.9)
+ s.add("com.mysql.cj.jdbc.admin.MiniAdmin");
+
+-// [databind#2334]: logback-core
++// [databind#2334]: logback-core (2.9.9.1)
+ s.add("ch.qos.logback.core.db.DriverMana
Bug#963832: RFS: iotop-c/1.0-1 [ITP] -- iotop-c - simple top-like I/O monitor (implemented in C)
Hi Gregor, On Thu, 2020-07-09 at 00:29 +0200, gregor herrmann wrote: > On Wed, 08 Jul 2020 20:09:03 +0300, Boian Bonev wrote: > > should be fixed in the package - that option should come from dpkg- > > buildflags. > > It's not enabled by default, but you can add > > export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow > > to debian/rules to add the flag. > > Cf. dpkg-buildflags(1) -export LDFLAGS=-Wl,-z,now $(shell dpkg-buildflags --get LDFLAGS) +export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow Looks much cleaner in this way. > But I guess in this case a Breaks would be more appropriate than a > Conflicts. > > Cf. 7.3 and 7.4 in Debian Policy > https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks > ff. I have changed Conflicts to Breaks+Replaces and it seems to work OK. Because both packages would install the same file, only Breaks wouldn't do, IMO, correct me if I am worng. > > > I: iotop-c source: testsuite-autopkgtest-missing > > Can't fix that. > > Well, you could write an autopkgtest :) > > Cf. https://ci.debian.net/doc/file.MAINTAINERS.html , > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst > etc. > > (But IMO that's not required for a first upload.) Writing a good test is quite far from trvial for this program. I will need some scartch space to write files to, run couple of processes that do IO in the scratch area according to some predefined pattern, collect the data via iotop (needs root) in batch mode and verify if the collected data matches the expected pattern... I would estimate that as about 2x the complexity of iotop itself. Thanks for your suggestions! With best regards, b.
Bug#964725: texlive-latex-recommended: Package xparse (required for example via mdframed) gives Undefined control sequence
Am 09.07.2020 um 16:55 teilte Stefan Monnier mit:
Hi,
> An article I was working on started to throw me lots and lots of errors and
> not
> generating any PDF when passed to `pdflatex` after the last upgrade of
> Texlive.
>
> I reduced the problem to the followint test case:
>
> \documentclass{article}
> \usepackage{mdframed}
> \begin{document}
> haha
> \end{document}
>
https://tex.stackexchange.com/questions/550158/undefined-control-sequence-in-expl3
says that it could be caused by a local format file sitting below
~/.texmf . Could you check?
Hilmar
--
sigfault
#206401 http://counter.li.org
signature.asc
Description: OpenPGP digital signature
Bug#964727: stretch-pu: package jackson-databind/2.8.6-1+deb9u6
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
I would like to update jackson-databind in Stretch. It is currently
affected by 20 CVE which are deemed as no-dsa by the security team.
I have added a patch that extends the blacklist to block more classes
from polymorphic deserialization.
Regards,
Markus
diff -Nru jackson-databind-2.8.6/debian/changelog
jackson-databind-2.8.6/debian/changelog
--- jackson-databind-2.8.6/debian/changelog 2019-10-05 19:21:48.0
+0200
+++ jackson-databind-2.8.6/debian/changelog 2020-07-09 16:42:01.0
+0200
@@ -1,3 +1,16 @@
+jackson-databind (2.8.6-1+deb9u7) stretch; urgency=medium
+
+ * Add multiple-CVE-BeanDeserializerFactory.patch and block more classes from
+polymorphic deserialization.
+This fixes 20 CVE that currently affect the package namely,
+CVE-2020-9548, CVE-2020-9547, CVE-2020-9546, CVE-2020-8840, CVE-2020-14195,
+CVE-2020-14062, CVE-2020-14061, CVE-2020-14060, CVE-2020-11620,
+CVE-2020-11619, CVE-2020-3, CVE-2020-2, CVE-2020-1,
+CVE-2020-10969, CVE-2020-10968, CVE-2020-10673, CVE-2020-10672,
+CVE-2019-20330, CVE-2019-17531 and CVE-2019-17267.
+
+ -- Markus Koschany Thu, 09 Jul 2020 16:42:01 +0200
+
jackson-databind (2.8.6-1+deb9u6) stretch-security; urgency=high
* Fix CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, CVE-2019-14439,
diff -Nru
jackson-databind-2.8.6/debian/patches/multiple-CVE-BeanDeserializerFactory.patch
jackson-databind-2.8.6/debian/patches/multiple-CVE-BeanDeserializerFactory.patch
---
jackson-databind-2.8.6/debian/patches/multiple-CVE-BeanDeserializerFactory.patch
1970-01-01 01:00:00.0 +0100
+++
jackson-databind-2.8.6/debian/patches/multiple-CVE-BeanDeserializerFactory.patch
2020-07-09 16:42:01.0 +0200
@@ -0,0 +1,189 @@
+From: Markus Koschany
+Date: Thu, 9 Jul 2020 16:39:09 +0200
+Subject: multiple CVE BeanDeserializerFactory
+
+This is the fix for
+CVE-2020-9548, CVE-2020-9547, CVE-2020-9546, CVE-2020-8840, CVE-2020-14195,
+CVE-2020-14062, CVE-2020-14061, CVE-2020-14060, CVE-2020-11620, CVE-2020-11619,
+CVE-2020-3, CVE-2020-2, CVE-2020-1, CVE-2020-10969, CVE-2020-10968,
+CVE-2020-10673, CVE-2020-10672, CVE-2019-20330, CVE-2019-17531 and
+CVE-2019-17267.
+---
+ .../databind/deser/BeanDeserializerFactory.java| 109 ++---
+ 1 file changed, 96 insertions(+), 13 deletions(-)
+
+diff --git
a/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
b/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
+index 77d426c..a594f08 100644
+---
a/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
b/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java
+@@ -54,6 +54,7 @@ public class BeanDeserializerFactory
+ Set s = new HashSet<>();
+ // Courtesy of [https://github.com/kantega/notsoserial]:
+ // (and wrt [databind#1599])
++
+ s.add("org.apache.commons.collections.functors.InvokerTransformer");
+
s.add("org.apache.commons.collections.functors.InstantiateTransformer");
+ s.add("org.apache.commons.collections4.functors.InvokerTransformer");
+@@ -69,10 +70,14 @@ public class BeanDeserializerFactory
+ s.add("java.util.logging.FileHandler");
+ s.add("java.rmi.server.UnicastRemoteObject");
+ // [databind#1737]; 3rd party
+-
s.add("org.springframework.aop.support.AbstractBeanFactoryPointcutAdvisor");
++//s.add("org.springframework.aop.support.AbstractBeanFactoryPointcutAdvisor");
// deprecated by [databind#1855]
+
s.add("org.springframework.beans.factory.config.PropertyPathFactoryBean");
+-//s.add("com.mchange.v2.c3p0.JndiRefForwardingDataSource"); //
deprecated by [databind#1931]
+-//s.add("com.mchange.v2.c3p0.WrapperConnectionPoolDataSource"); // -
"" -
++// [databind#2680]
++s.add("org.springframework.aop.config.MethodLocatingFactoryBean");
++
s.add("org.springframework.beans.factory.config.BeanReferenceFactoryBean");
++
++// s.add("com.mchange.v2.c3p0.JndiRefForwardingDataSource"); // deprecated by
[databind#1931]
++// s.add("com.mchange.v2.c3p0.WrapperConnectionPoolDataSource"); // - "" -
+ // [databind#1855]: more 3rd party
+ s.add("org.apache.tomcat.dbcp.dbcp2.BasicDataSource");
+ s.add("com.sun.org.apache.bcel.internal.util.ClassLoader");
+@@ -82,10 +87,11 @@ public class BeanDeserializerFactory
+ // [databind#2032]: more 3rd party; data exfiltration via xml parsed
ext entities
+ s.add("org.apache.ibatis.parsing.XPathParser");
+
+-// [databind#2052]: ldap approaches; in all cases LDAP connection
String is passed
+-// and access attempt is made:
+-s.add("oracle.jdbc.connector.OracleManagedConnectionFactory");
++// [dat
Bug#964728: gtk-doc-tools: gtkdoc-scangobj fails in mipsel / Loongson when building webkit2gtk
Package: gtk-doc-tools
Version: 1.32-4
Severity: important
Hi,
the mipsel build of webkit2gtk is failing because of gtkdoc-scangobj:
| 2020-06-10 14:02:24,288:scangobj.py:execute_command:1199:WARNING:Running
scanner failed: -6, command: ./webkit2gtk-4.0-scan
| Traceback (most recent call last):
| File "/<>/Tools/gtkdoc/generate-gtkdoc", line 254, in
| build_gtkdoc_for_wkgtk(arguments)
| File "/<>/Tools/gtkdoc/generate-gtkdoc", line 224, in
build_gtkdoc_for_wkgtk
| saw_warnings = generate_documentation(webkit2_generator)
| File "/<>/Tools/gtkdoc/generate-gtkdoc", line 158, in
generate_documentation
| return generate_doc(generator, arguments.skip_html)
| File "/<>/Tools/gtkdoc/generate-gtkdoc", line 145, in
generate_doc
| generator.generate(not skip_html)
| File "/<>/Tools/gtkdoc/gtkdoc.py", line 147, in generate
| self._run_gtkdoc_scangobj()
| File "/<>/Tools/gtkdoc/gtkdoc.py", line 337, in
_run_gtkdoc_scangobj
| self._run_command(['gtkdoc-scangobj', '--module=%s' % self.module_name],
| File "/<>/Tools/gtkdoc/gtkdoc.py", line 218, in _run_command
| raise Exception(('%s produced a non-zero return code %i\n'
| Exception: gtkdoc-scangobj produced a non-zero return code 250
| Command:
| gtkdoc-scangobj --module=webkit2gtk-4.0
This is only happening on the mipsel builds, and I cannot reproduce
the problem in eller.debian.org. Adrian Bunk says it fails on the
Loongson buildds but succeeds on the others.
I have a FTBFS on webkit2gtk because of this (#962616).
Regards,
Berto
Bug#964729: vim-gitgutter doesn't respect the Debian vim policy
Package: vim-gitgutter Version: 0~20200414-1 Severity: important Dear maintainer, It appears this package doesn't follow the Debian vim policy [1]. It's clearly not easy to find (I had to search quite a bit to find it), but I think it's important vim packages try to respect it :) Here are the problems I saw while giving the package a quick test: * the addon is enabled after the installation; it shouldn't * the package doesn't depend on "vim-addon-manager" like other vim plugins do * after the installation, it doesn't show up when running "vim-addon-manager status". I think the "Severity: important" is justified since this breaks what vim users are used to on Debian. Thanks for packaging vim-gitgutter, I'm really looking forward to using it once this is fixed! [1] https://web.archive.org/web/20151022212021/http://pkg-vim.alioth.debian.org/vim-policy.html/index.html -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#964730: ITP: gpsshogi -- Shogi playing program based on OpenShogiLib
Package: wnpp Severity: wishlist Owner: Yann Dirson This is rather an Intent to Resurrect, as gpsshogi was in Debian 2 releases ago. * Package name: gpsshogi Version : 0.7.0 Upstream Author : Team GPS, feat. Daigo Moriwaki * URL : http://gps.tanaka.ecc.u-tokyo.ac.jp/ * License : BSD Programming Lang: C++ Description : Shogi playing program based on OpenShogiLib GPSShogi is a Shogi playing program based on OpenShogiLib and won the 19th World Computer Shogi Championship. This package contains several binaries to play with computer Shogi. - gpsshogi: support the CSA protocol - gpsusi: support the USI protocol - gpsshogi-viewer: GUI application to investigate positions - gpsshell: shell-like client to investigate positions
Bug#964731: kramdown-rfc2629: warning: calling URI.open via Kernel#open is deprecated, call URI.open directly or use URI#open
Package: ruby-kramdown-rfc2629 Version: 1.2.12-0.1 When running kramdown-rfc2629 against ruby 1:2.7+1, i see this warning multiple times: /usr/lib/ruby/vendor_ruby/kramdown-rfc2629.rb:454: warning: calling URI.open via Kernel#open is deprecated, call URI.open directly or use URI#open Perhaps the latest upstream version (1.3.8 appears to be available) resolves it, i'm not sure. --dkg signature.asc Description: PGP signature
Bug#964733: debrebuild: parsable output
Package: devscripts Version: 2.20.4 Severity: wishlist User: devscri...@packages.debian.org Usertags: debrebuild Dear Maintainer, currently srebuild creates output which is ment to (be parsed and) executed, thus it would be really nice if the output was easily parsable, IOW this should be added to line 487: print "SBUILD_CMDLINE=$environment sbuild"; Also it would be great if the base distro would be parsable like this. The fix for that needs to go into line 529: print "BASE_DIST=$base_dist\n"; -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#964730: ITP: gpsshogi -- Shogi playing program based on OpenShogiLib
> Package: wnpp > Severity: wishlist > Owner: Yann Dirson > > This is rather an Intent to Resurrect, as gpsshogi was in Debian > 2 releases ago. > > * Package name: gpsshogi > Version : 0.7.0 > Upstream Author : Team GPS, feat. Daigo Moriwaki > * URL : http://gps.tanaka.ecc.u-tokyo.ac.jp/ > * License : BSD Correction: gpsshogi is GPLv2, only libosl is BSD. > Programming Lang: C++ > Description : Shogi playing program based on OpenShogiLib > > GPSShogi is a Shogi playing program based on OpenShogiLib and won > the 19th > World Computer Shogi Championship. This package contains several > binaries to > play with computer Shogi. >- gpsshogi: support the CSA protocol >- gpsusi: support the USI protocol >- gpsshogi-viewer: GUI application to investigate positions >- gpsshell: shell-like client to investigate positions >
Bug#964732: ITP: libosl -- library for Shogi playing programs
Package: wnpp Severity: wishlist Owner: Yann Dirson * Package name: libosl Version : 0.8. Upstream Author : GPS Team * URL : http://gps.tanaka.ecc.u-tokyo.ac.jp/gpsshogi/pukiwiki.php * License : BSD Programming Lang: C++ Description : library for Shogi playing programs Dependency of gpssogi (ITP #964730)
Bug#964728: gtk-doc-tools: gtkdoc-scangobj fails in mipsel / Loongson when building webkit2gtk
On Thu, 09 Jul 2020 at 17:42:35 +0200, Alberto Garcia wrote: > the mipsel build of webkit2gtk is failing because of gtkdoc-scangobj: ... > This is only happening on the mipsel builds, and I cannot reproduce > the problem in eller.debian.org. Adrian Bunk says it fails on the > Loongson buildds but succeeds on the others. gtkdoc-scangobj works by compiling a small C program that it uses to introspect GObject types. According to the build log, that program exited with status -6 (which is probably Python's representation of it being killed by signal 6, which is SIGABRT?) with no output. The Loongson 3A "is known for having an FPU bug" (see #959845) - perhaps that could be related, if webkit2gtk contains GObject types with G_TYPE_FLOAT or G_TYPE_DOUBLE values? I'm not sure what individual packages can do about this, or why we are using known-faulty CPUs on official buildds. This is likely to be "won't fix" (or rather "can't fix") for gtk-doc-tools, unless someone with a suitably faulty FPU can reproduce the bug and figure out what is going on. Workaround: instead of 8< ifneq (,$(filter nodoc,$(DEB_BUILD_OPTIONS))) EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF else EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON endif 8< webkit2gtk could use something like 8< binaries := $(shell dh_listpackages) ifneq (,$(filter %-doc,$(binaries))) EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=OFF else EXTRA_CMAKE_ARGUMENTS += -DENABLE_GTKDOC=ON endif 8< together with 8< Package: libwebkit2gtk-4.0-doc Build-Profiles: 8< so that you don't run gtk-doc in architecture-specific builds, only in builds that include Architecture: all. That would also be faster, and you might be able to move gtk-doc-tools from Build-Depends to Build-Depends-Indep (usually you can for Meson, but not for Autotools because it's needed at dh_autoreconf time; I don't know which category CMake falls into). smcv
Bug#964734: linux-image-4.19.0-9-amd64: [bisected] i2c timeout loading module ddbridge
Package: src:linux Version: 4.19.118-2+deb10u1 Severity: normal Tags: upstream Dear Maintainer, loading kernel module ddbridge fails with i2c timeouts. The dvb media adapter is unusable. This happened after Linux kernel upgrade from 4.19.98-1+deb10u1 to 4.19.118-2+deb10u1. Git bisect based on the Debian kernel repo on branch buster identified as first bad commit: [1fb0eb795661ab9e697c3a053b35aa4dc3b81165] Update to 4.19.116. Git bisect based on upstream Linux kernel repo on branch v4.19.y identified as first bad commit: [d2345d1231d80ecbea5fb764eb43123440861462] PCI: Add boot interrupt quirk mechanism for Xeon chipsets. Other affected Debian kernel version: 5.6.14+2~bpo10+1 I tested this version via buster-backports, because so far I was unable to build my own kernel from 5.6.y or even 5.7.y. Following kernel from buster backports is working OK: linux-image-5.5.0-0.bpo.2-amd64 (5.5.17-1~bpo10+1) Workaround: == Reverting the mentioned commit d2345d1231d80ecbea5fb764eb43123440861462 on top of 4.19.132 is fixing the problem. Reverting the same commit on 4.19.118 or 4.19.116 is also fixing the problem. I already reported upstream: https://bugzilla.kernel.org/show_bug.cgi?id=208507 Thanks and Regards Berni -- Package-specific info: ** Version: Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/vg0-root ro intel_iommu=on amd_iommu=on ** Not tainted ** Kernel log: [ 11.504445] device eno3 entered promiscuous mode [ 11.532466] device bond0 entered promiscuous mode [ 11.533970] device eno1 entered promiscuous mode [ 11.535680] device eno4 entered promiscuous mode [ 11.619334] device mgmt0 entered promiscuous mode [ 11.702681] device ceph_cluster entered promiscuous mode [ 11.776108] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 11.776114] ddbridge :05:00.0: DDBridge IRS 00f1 [ 12.800112] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 12.801865] ddbridge :05:00.0: DDBridge IRS 00f1 [ 13.824139] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 13.825849] ddbridge :05:00.0: DDBridge IRS 00f1 [ 14.241947] igb :06:00.1 eno2: igb: eno2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 14.245736] IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready [ 14.848109] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 14.849845] ddbridge :05:00.0: DDBridge IRS 00f1 [ 14.909953] igb :06:00.0 eno1: igb: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 14.913760] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready [ 15.872149] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 15.873934] ddbridge :05:00.0: DDBridge IRS 00f1 [ 16.896087] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 16.897888] ddbridge :05:00.0: DDBridge IRS 00f1 [ 17.920092] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 17.920167] ddbridge :05:00.0: DDBridge IRS 00f1 [ 17.920222] ddbridge :05:00.0: Port 0: Link 0, Link Port 0 (TAB 1): NO MODULE [ 18.944076] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 18.944151] ddbridge :05:00.0: DDBridge IRS 00f2 [ 18.944205] ddbridge :05:00.0: I2C cmd=00018001 mon=0803004f [ 19.968101] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 19.968174] ddbridge :05:00.0: DDBridge IRS 00f2 [ 19.968228] ddbridge :05:00.0: I2C cmd=00012001 mon=0803001f [ 20.992082] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 20.992154] ddbridge :05:00.0: DDBridge IRS 00f2 [ 20.992209] ddbridge :05:00.0: I2C cmd=0001dc02 mon=0801002f [ 22.016099] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 22.016172] ddbridge :05:00.0: DDBridge IRS 00f2 [ 22.016226] ddbridge :05:00.0: I2C cmd=0001d201 mon=0803002f [ 23.111415] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 23.111487] ddbridge :05:00.0: DDBridge IRS 00f2 [ 23.111541] ddbridge :05:00.0: I2C cmd=0001d001 mon=0803002f [ 24.228517] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 24.228590] ddbridge :05:00.0: DDBridge IRS 00f2 [ 24.228644] ddbridge :05:00.0: I2C cmd=00015203 mon=0802001f [ 25.345584] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 25.345656] ddbridge :05:00.0: DDBridge IRS 00f2 [ 25.345710] ddbridge :05:00.0: I2C cmd=00013c01 mon=0803002f [ 26.407869] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 26.407941] ddbridge :05:00.0: DDBridge IRS 00f2 [ 26.407995] ddbridge :05:00.0: I2C cmd=00014001 mon=0803001f [ 26.408055] ddbridge :05:00.0: Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE [ 27.431
Bug#964735: ITP: libmodule-build-parse-yapp-perl -- build Parse::Yapp parsers from source
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name: libmodule-build-parse-yapp-perl Version : 0.1.2 Upstream Author : Andrius Merkys * URL : https://metacpan.org/release/Module-Build-Parse-Yapp * License : BSD-3-Clause Programming Lang: Perl Description : build Parse::Yapp parsers from source Module::Build::Parse::Yapp is a subclass of Module::Build made to build Parse::Yapp parsers from the source. Thus, prebuilt parsers do not have to be included in the source distribution. Module::Build::Parse::Yapp looks for *.yp files under 'lib' and produces Perl modules in place of them under 'blib/lib'. Therefore, a grammar file 'lib/A/B/C.yp' will be converted to 'blib/lib/A/B/C.pm' with a package name of 'A::B::C'. Disclaimer: I am also the upstream of this package. I have created this package to combat the inclusion of prebuilt Parse::Yapp-generated parsers (in my own Perl modules, for starters). The problem is described in detail in the discussion about related lintian warning [1][2]. The package is a dependency of liboptimade-filter-perl, which currently is patched to build without it. Remark: This package is to be maintained with Debian Perl Group at [3]. [1] https://lintian.debian.org/tags/source-contains-prebuilt-yapp-parser.html [2] https://bugs.debian.org/921080 [3] https://salsa.debian.org/perl-team/modules/packages/libmodule-build-parse-yapp-perl Andrius
Bug#964736: ITP: public-inbox -- Mailing list archiver
Package: wnpp Severity: wishlist Owner: Uwe Kleine-König * Package name: public-inbox Version : 1.5.0 Upstream Author : Eric Wong and others * URL : https://www.public-inbox.org/ * License : AGPL-3.0 Programming Lang: Perl Description : versatile mailing (list) archiver This software powers https://lore.kernel.org/ and also http://www.public-inbox.org/ itself. It's the server-side counter part for b4 that is already packaged in Debian. Currently I evaluate it to provide an archive for several work related mailing lists. Depending on the outcome of this evaluation I might or might not actually package public-inbox. But as deploying is easy using debian packages I will create at least simple packaging which should at a minimum give a good start for someone to pick up from me. Best regards Uwe
Bug#964099: konversation: tries to join channel before finishing identification
It does right job if I change authentication method to "SASL PLAIN".
Bug#964729: vim-gitgutter doesn't respect the Debian vim policy
Dear Louis-Philippe, The first packaging I did (not published) was using `vim-addon-manager`. Although I switch to dh-vim_addon (and friends) which is not using `vim-addon-manager` anymore. This move has been recommended by James McCoy (who sponsored the package). I guess you spotted a lack of documentation/policy for this new helper: `dh-vim_addon`. I add James in CC. Maybe should we discuss/write a new Policy and/or some guidelines. I already started a TODO list of checks for new/next vim addon packages. I would appreciate some feedback on it, but first let me a few days to make it clean. Here are some additional notes about your comments: > It appears this package doesn't follow the Debian vim policy [1]. It's > clearly not easy to find (I had to search quite a bit to find it), but I > think it's important vim packages try to respect it :) Is this policy still relevant ? Already mentionned above. > * the addon is enabled after the installation; it shouldn't If I well understood James' advices: with `dh-vim_addon` help, vim addon packages should always be enabled if you can disable them through your vimrc with `let g:loaded_gitgutter = 1`. > * the package doesn't depend on "vim-addon-manager" like other vim plugins do It should not anymore, thanks to dh-vim_addon helper. -- Raphaël Medaer
Bug#964729: vim-gitgutter doesn't respect the Debian vim policy
On 2020-07-09 12 h 37, Raphael Medaer wrote: > Dear Louis-Philippe, > > The first packaging I did (not published) was using `vim-addon-manager`. > Although I switch to dh-vim_addon (and friends) which is not using > `vim-addon-manager` anymore. > This move has been recommended by James McCoy (who > sponsored the package). > > I guess you spotted a lack of documentation/policy for this new helper: > `dh-vim_addon`. > I add James in CC. Maybe should we discuss/write a new Policy and/or some > guidelines. > > I already started a TODO list of checks for new/next vim addon packages. I > would appreciate some feedback on it, but first let me a few days to make it > clean. > > Here are some additional notes about your comments: > > > It appears this package doesn't follow the Debian vim policy [1]. It's > > clearly not easy to find (I had to search quite a bit to find it), but I > > think it's important vim packages try to respect it :) > > Is this policy still relevant ? Already mentionned above. No idea, I'm only a vim user and I haven't done any vim work in Debian :) > > > * the addon is enabled after the installation; it shouldn't > > If I well understood James' advices: with `dh-vim_addon` help, vim addon > packages should always be enabled if you can disable them through your vimrc > with `let g:loaded_gitgutter = 1`. This is quite a big change and I guess it breaks my current setup :s I feel this should be publicized and done in coordinated fashion for all the vim packages in preparation for Bullseye. Having a mix of the two behaviors (enabled and disabled by default) sounds like headache. I don't mind moving to something else, but I quite like being able to use vim-addon-manager as a frontend for vim addons. It would be nice if the new packaging guidelines made it somehow possible to continue using that tool. Cheers! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#964177: marked as done (chromium: high cpu load and frequent crashes)
Hi everyone. Unfortunately, I can’t confirm that Chromium no longer crashes. My Chrome version: 83.0.4103.116-1~deb10u2 Trace: [2936:3050:0709/194822.352645:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [2936:3050:0709/194822.352837:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [2973:2973:0709/194822.373032:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. Fontconfig error: Cannot load default config file free(): double free detected in tcache 2 Received signal 6 #0 0x55ae0a0d3469 (/usr/lib/chromium/chromium+0x51f9468) #1 0x55ae0a031193 (/usr/lib/chromium/chromium+0x5157192) #2 0x55ae0a0d2ff1 (/usr/lib/chromium/chromium+0x51f8ff0) #3 0x7f817dbd4110 (/usr/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f) #4 0x7f8178ab6781 gsignal #5 0x7f8178aa055b abort #6 0x7f8178af9038 (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x7e037) #7 0x7f8178b003da (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x853d9) #8 0x7f8178b0221d (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x8721c) #9 0x55ae07f9614b (/usr/lib/chromium/chromium+0x30bc14a) #10 0x55ae087ae5d8 (/usr/lib/chromium/chromium+0x38d45d7) #11 0x55ae087ae67e (/usr/lib/chromium/chromium+0x38d467d) #12 0x55ae07e5498f (/usr/lib/chromium/chromium+0x2f7a98e) #13 0x55ae08768559 (/usr/lib/chromium/chromium+0x388e558) #14 0x55ae0876879e (/usr/lib/chromium/chromium+0x388e79d) #15 0x55ae087b1e67 (/usr/lib/chromium/chromium+0x38d7e66) #16 0x55ae087ddac2 (/usr/lib/chromium/chromium+0x3903ac1) #17 0x55ae087ddd7e (/usr/lib/chromium/chromium+0x3903d7d) #18 0x55ae087ae63f (/usr/lib/chromium/chromium+0x38d463e) #19 0x55ae087ae67e (/usr/lib/chromium/chromium+0x38d467d) #20 0x55ae07e5498f (/usr/lib/chromium/chromium+0x2f7a98e) #21 0x55ae0810bf53 (/usr/lib/chromium/chromium+0x3231f52) #22 0x55ae08436e22 (/usr/lib/chromium/chromium+0x355ce21) #23 0x55ae0a206aff (/usr/lib/chromium/chromium+0x532cafe) #24 0x55ae0a20d274 (/usr/lib/chromium/chromium+0x5333273) #25 0x55ae0a20b16d (/usr/lib/chromium/chromium+0x533116c) #26 0x55ae0a209e2c (/usr/lib/chromium/chromium+0x532fe2b) #27 0x55ae0a202913 (/usr/lib/chromium/chromium+0x5328912) #28 0x55ae0a21e77b (/usr/lib/chromium/chromium+0x534477a) #29 0x55ae0a21ea41 (/usr/lib/chromium/chromium+0x5344a40) #30 0x55ae0a21e040 (/usr/lib/chromium/chromium+0x534403f) #31 0x55ae080f4e26 (/usr/lib/chromium/chromium+0x321ae25) #32 0x55ae080f494c (/usr/lib/chromium/chromium+0x321a94b) #33 0x55ae080f0d51 (/usr/lib/chromium/chromium+0x3216d50) #34 0x55ae080e761b (/usr/lib/chromium/chromium+0x320d61a) #35 0x55ae080d9f1b (/usr/lib/chromium/chromium+0x31fff1a) #36 0x55ae080d9c03 (/usr/lib/chromium/chromium+0x31ffc02) #37 0x55ae080f89a6 (/usr/lib/chromium/chromium+0x321e9a5) #38 0x55ae0a0f028a (/usr/lib/chromium/chromium+0x5216289) #39 0x7f817c7bc9ba (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6.0.2+0x229b9) #40 0x7f817c7bd537 event_base_loop #41 0x55ae0a0f0510 (/usr/lib/chromium/chromium+0x521650f) #42 0x55ae0a08fc05 (/usr/lib/chromium/chromium+0x51b5c04) #43 0x55ae0a067a1d (/usr/lib/chromium/chromium+0x518da1c) #44 0x55ae083d2d93 (/usr/lib/chromium/chromium+0x34f8d92) #45 0x55ae0a0a63f7 (/usr/lib/chromium/chromium+0x51cc3f6) #46 0x55ae0a0e30ce (/usr/lib/chromium/chromium+0x52090cd) #47 0x7f817dbc8f27 start_thread #48 0x7f8178b7831f clone r8: r9: 7f816c8b9950 r10: 0008 r11: 0246 r12: 7f816c8b9bc0 r13: 1000 r14: 0010 r15: 7f816d0bd000 di: 0002 si: 7f816c8b9950 bp: 7f816c8b9ca0 bx: 7f816c8bc700 dx: ax: cx: 7f8178ab6781 sp: 7f816c8b9950 ip: 7f8178ab6781 efl: 0246 cgf: 002b0033 erf: trp: msk: cr2: [end of stack trace] Calling _exit(1). Core file will not be generated. Kind regards, Dmytro
Bug#964734: Patch to revert bad commit
Tags: patch
Attached is a patch to revert the mentioned commit
It is based on kernel v4.19.131.
From: Berni Turmann
Date: Thu, 9 Jul 2020 13:00:00 +0200
Subject: Revert: PCI: Add boot interrupt quirk mechanism for Xeon chipsets
Fixes: commit d2345d1231d80ecbea5fb764eb43123440861462
("PCI: Add boot interrupt quirk mechanism for Xeon chipsets")
With the above mentioned commit included, the ddbridge module is loading,
but dmesg reports i2c timeouts and the dvb card is not working.
This patch fixes the regression introduced with kernel v4.19.116.
Loading of dvb kernel module ddbridge fails.
Affected Hardware: Supermicro Super Server / X10SDV-TLN4F
CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
Affected DVB adapter: Digital Devices Cine S2 V7 Advanced
Index: linux/drivers/pci/quirks.c
===
--- linux.orig/drivers/pci/quirks.c
+++ linux/drivers/pci/quirks.c
@@ -1947,92 +1947,26 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_I
/*
* IO-APIC1 on 6300ESB generates boot interrupts, see Intel order no
* 300641-004US, section 5.7.3.
- *
- * Core IO on Xeon E5 1600/2600/4600, see Intel order no 326509-003.
- * Core IO on Xeon E5 v2, see Intel order no 329188-003.
- * Core IO on Xeon E7 v2, see Intel order no 329595-002.
- * Core IO on Xeon E5 v3, see Intel order no 330784-003.
- * Core IO on Xeon E7 v3, see Intel order no 332315-001US.
- * Core IO on Xeon E5 v4, see Intel order no 333810-002US.
- * Core IO on Xeon E7 v4, see Intel order no 332315-001US.
- * Core IO on Xeon D-1500, see Intel order no 332051-001.
- * Core IO on Xeon Scalable, see Intel order no 610950.
*/
-#define INTEL_6300_IOAPIC_ABAR 0x40 /* Bus 0, Dev 29, Func 5 */
+#define INTEL_6300_IOAPIC_ABAR 0x40
#define INTEL_6300_DISABLE_BOOT_IRQ (1<<14)
-#define INTEL_CIPINTRC_CFG_OFFSET 0x14C /* Bus 0, Dev 5, Func 0 */
-#define INTEL_CIPINTRC_DIS_INTX_ICH (1<<25)
-
static void quirk_disable_intel_boot_interrupt(struct pci_dev *dev)
{
u16 pci_config_word;
- u32 pci_config_dword;
if (noioapicquirk)
return;
- switch (dev->device) {
- case PCI_DEVICE_ID_INTEL_ESB_10:
- pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR,
- &pci_config_word);
- pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
- pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR,
- pci_config_word);
- break;
- case 0x3c28: /* Xeon E5 1600/2600/4600 */
- case 0x0e28: /* Xeon E5/E7 V2 */
- case 0x2f28: /* Xeon E5/E7 V3,V4 */
- case 0x6f28: /* Xeon D-1500 */
- case 0x2034: /* Xeon Scalable Family */
- pci_read_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
- &pci_config_dword);
- pci_config_dword |= INTEL_CIPINTRC_DIS_INTX_ICH;
- pci_write_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
- pci_config_dword);
- break;
- default:
- return;
- }
+ pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR, &pci_config_word);
+ pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
+ pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR, pci_config_word);
+
pci_info(dev, "disabled boot interrupts on device [%04x:%04x]\n",
dev->vendor, dev->device);
}
-/*
- * Device 29 Func 5 Device IDs of IO-APIC
- * containing ABAR—APIC1 Alternate Base Address Register
- */
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
- quirk_disable_intel_boot_interrupt);
-
-/*
- * Device 5 Func 0 Device IDs of Core IO modules/hubs
- * containing Coherent Interface Protocol Interrupt Control
- *
- * Device IDs obtained from volume 2 datasheets of commented
- * families above.
- */
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3c28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0e28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x6f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2034,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x3c28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x0e28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x6f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2034,
- quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
/* Disable boot interrupts on HT-1000 */
#define BC_HT1000_FEATURE_REG 0x64
Bug#962366: gajim crashes at startup
Control: tag -1 + moreinfo Do you try to run Gajim on X11 or on Wayland? On which desktop environment and/or window manager? Thank you!
Bug#962698: python-pauvre: FTBFS if the "DISPLAY" environment variable is exported
Hi Andreas, Andreas Tille, on 2020-07-09 13:39:25 +0200: > On Wed, Jul 08, 2020 at 07:36:29PM +0200, etienne.moll...@mailoo.org wrote: > > > > Besides, running reproducible build checks showed that some test > > data and results landed into the binary package python3-pauvre, > > so added some cleanup routine in the process. > > ... > > Thank you Chris for your report! > > As far as I can see this closes #962702 which was not closed in the > changelog entry. Any reason for this? There is no technical reason in particular. I actually missed the src:python-pauvre bugs listing, and only stuck to the package, where the FTBR bug was not referenced: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=python-pauvre So yes, it should have been closed at the same time. Thank you for spotting this! -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/1, please excuse my verbosity. signature.asc Description: PGP signature
Bug#964737: mpd: Single mode not working the first time
Package: mpd Version: 0.21.5-3 Severity: normal When mpd restarts and the single mode flag is on, the first song transition happens anyway. (That is, when it finishes playing the first song it goes on to the second one in the queue.) When the second song is finished mpd pauses as expected and then continues to work correctly. This sounds somewhat similar to upstream github issue #556, but it is completely reproducible for me. -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages mpd depends on: ii adduser 3.118 ii init-system-helpers 1.56+nmu1 ii libadplug-2.2.1-0v5 2.2.1+dfsg3-1 ii libao41.2.2+20180113-1 ii libasound21.1.8-1 ii libaudiofile1 0.3.6-5 ii libavahi-client3 0.7-4+b1 ii libavahi-common3 0.7-4+b1 ii libavcodec58 7:4.1.6-1~deb10u1 ii libavformat58 7:4.1.6-1~deb10u1 ii libavutil56 7:4.1.6-1~deb10u1 ii libbz2-1.01.0.6-9.2~deb10u1 ii libc6 2.28-10 ii libcdio-cdda2 10.2+0.94+2-4 ii libcdio-paranoia2 10.2+0.94+2-4 ii libcdio18 2.0.0-2 ii libcurl3-gnutls 7.64.0-4+deb10u1 ii libdbus-1-3 1.12.16-1 ii libexpat1 2.2.6-2+deb10u1 ii libfaad2 2.8.8-3 ii libflac8 1.3.2-3 ii libfluidsynth11.1.11-1 ii libgcc1 1:8.3.0-6 ii libgcrypt20 1.8.4-5 ii libgme0 0.6.2-1 ii libicu63 63.1-6+deb10u1 ii libid3tag00.15.1b-14 ii libiso9660-11 2.0.0-2 ii libixml10 1:1.8.4-2 ii libjack-jackd2-0 [libjack-0.125] 1.9.12~dfsg-2 ii libjs-sphinxdoc 1.8.4-1 ii libmad0 0.15.1b-10 ii libmikmod33.3.11.1-4 ii libmms0 0.6.4-3 ii libmodplug1 1:0.8.9.0-2 ii libmp3lame0 3.100-2+b1 ii libmpcdec62:0.1~r495-1+b2 ii libmpdclient2 2.16-1 ii libmpg123-0 1.25.10-2 ii libnfs12 3.0.0-2 ii libogg0 1.3.2-1+b1 ii libopenal11:1.19.1-1 ii libopus0 1.3-1 ii libpcre3 2:8.39-12 ii libpulse0 12.2-4+deb10u1 ii libsamplerate00.1.9-2 ii libshout3 2.4.1-2 ii libsidplayfp4 1.8.8-1 ii libsmbclient 2:4.9.5+dfsg-5+deb10u1 ii libsndfile1 1.0.28-6 ii libsoxr0 0.1.2-3 ii libsqlite3-0 3.27.2-3 ii libstdc++68.3.0-6 ii libsystemd0 241-7~deb10u4 ii libupnp13 1:1.8.4-2 ii libvorbis0a 1.3.6-2 ii libvorbisenc2 1.3.6-2 ii libwavpack1 5.1.0-6 ii libwildmidi2 0.4.3-1 ii libyajl2 2.1.0-3 ii libzzip-0-13 0.13.62-3.2 ii lsb-base 10.2019051400 ii zlib1g1:1.2.11.dfsg-1 mpd recommends no packages. Versions of packages mpd suggests: pn avahi-daemon pn icecast2 ii mpc [mpd-client] 0.31-1 ii ncmpcpp [mpd-client] 0.8.2-0.1 pn pulseaudio -- no debconf information
Bug#964256:
This breaks compilation of wine too, as this requires libfreetype-dev (multiarch). I haven`t been able to compile wine for about a week now. Any news on when this bug is going to be fixed? Regards
Bug#959420: O: free42-nologo -- Free42 is a re-implementation of the HP-42S calculator
Dear Stephen, On Mon, 29 Jun 2020 22:34:20 +0200 Stephen Kitt wrote: > Control: retitle -1 ITA: free42-nologo -- Free42 is a re-implementation of > the HP-42S calculator > Control: owner -1 ! > > On Sat, May 02, 2020 at 10:58:56AM +0200, Tobias Frost wrote: > > The current maintainer of free42-nologo, Christian Stalp > > , > > is apparently not active anymore. Therefore, I orphan this package now. > > I’m working with Christian to get an updated version of the package > ready. I’ll change this to an ITA on my behalf for now, to signal that > I am taking care of the package (whether with Christian, or directly, > or co-maintaining). Just to let you know that, if needed, I’m willing to help with the package. I’d really like to have a recent upstream version included in bullseye, with the alternative decimal floating-point version (#775599). Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#964738: gnome-shell-extensions : On screen keyboard has missing icons for Enter, Shift, Caps-lock, alt keys (relevant icons ar not included in the package)
Package: gnome-shell-extensions Version: 3.36.2-1 Severity: important Dear Maintainer, The on screen keyboard looks exactly like in this report https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2631 where the reporter is using the same package version on sid (i am on testing) $ gresource list /usr/share/gnome-shell/gnome-shell-theme.gresource | grep keyboard /org/gnome/shell/theme/icons/keyboard-caps-lock-filled-symbolic.svg /org/gnome/shell/theme/icons/keyboard-enter-symbolic.svg /org/gnome/shell/theme/icons/keyboard-hide-symbolic.svg /org/gnome/shell/theme/icons/keyboard-layout-filled-symbolic.svg /org/gnome/shell/theme/icons/keyboard-shift-filled-symbolic.svg But those icons are nowhere to be found Downloading them from https://gitlab.gnome.org/GNOME/gnome- shell/-/tree/gnome-3-36/data/theme and manually placing them in /usr/share/gnome-shell/theme/ did not solve the problem either -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.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-shell-extensions depends on: ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gir1.2-atk-1.0 2.36.0-2 ii gir1.2-clutter-1.0 1.26.4+dfsg-1 ii gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5 ii gir1.2-glib-2.0 1.64.1-1 ii gir1.2-gmenu-3.0 3.36.0-1 ii gir1.2-gtk-3.0 3.24.20-1 ii gir1.2-pango-1.0 1.44.7-4 ii gnome-session-bin3.36.0-2+b1 ii gnome-settings-daemon3.36.1-1 ii gnome-shell 3.36.3-1 ii gvfs 1.44.1-1 Versions of packages gnome-shell-extensions recommends: ii gnome-tweaks 3.34.0-3 gnome-shell-extensions suggests no packages. -- no debconf information
Bug#964739: fakechroot: fails to run zypper --root from incorrect path expansion
Package: libfakechroot
Version: 2.19-3.2
Severity: normal
Tags: upstream
Dear Maintainer,
I was attempting to use fakechroot to make a chroot with zypper, like I would
debootstrap, but I needed
`fakechroot fakeroot zypper --root $chroot install rpm` failed to complete,
with errors relating to finding files.
strace reported that it attempted to access the files with the chroot prefix
doubled.
The cause appears to be because zypper opens a file descriptor to the system
root directory for the purposes of leaving the chroot again.
Unfortunately it does so by, after calling in sequence `chdir("/")`,
`chroot($chroot)` then `open(".", O_RDONLY)`, which since zypper hasn't called
`chdir` yet should refer to the system root directory, but fakechroot turns the
relative path in open into an absolute one which results in the file descriptor
referring to the chroot, so it fails to leave the chroot and the stat call that
expects to run outside of the chroot fails.
A program that demonstrates this problem is:
```
#/usr/bin/python3
import os
import tempfile
with tempfile.TemporaryDirectory() as chroot:
# Set up chroot to reflect failure
rpmdir = 'var/lib/rpm'
os.makedirs(os.path.join(chroot, rpmdir))
with open(os.path.join(chroot, rpmdir, "Basenames"), "w") as f:
pass
# Make current directory to root, but change out process root to chroot
os.chdir("/")
os.chroot(chroot)
# get file descriptor of system root directory
# NOTE: Here is where fakechroot breaks
# since it translates it to open(chroot)
dfd = os.open(".", os.O_RDONLY)
# chdir, so now the only way out is the file descriptor
os.chdir("/")
## Some operation that needs to be in the chroot occurs
# Leave the chroot again
os.fchdir(dfd)
os.close(dfd)
os.chroot(".")
os.chdir("/")
# Access contents of chroot
# NOTE: The earlier fakechroot failure causes this to break
# since it thinks we're still in the chroot,
# since dfd was translated to the chroot path rather than outside,
# so the chroot path is translated to a doubled path.
st = os.stat(os.path.join(chroot, rpmdir, "Basenames"))
```
It succeeds running with sudo, but fails with fakechroot fakeroot.
-- System Information:
Debian Release: 10.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libfakechroot depends on:
ii libc6 2.28-10
libfakechroot recommends no packages.
libfakechroot suggests no packages.
-- no debconf information
Bug#948653: mod-gnutls 0.8.2-3+deb9u2 flagged for acceptance
package release.debian.org tags 948653 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: mod-gnutls Version: 0.8.2-3+deb9u2 Explanation: fix test failures when combined with Apache's fix for CVE-2019-10092
Bug#964456: roundcube 1.2.3+dfsg.1-4+deb9u6 flagged for acceptance
package release.debian.org tags 964456 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: roundcube Version: 1.2.3+dfsg.1-4+deb9u6 Explanation: fix cross-site scripting issue via HTML messages with malicious svg/namespace [CVE-2020-15562]
Bug#964411: c-icap-modules 0.4.4-1+deb9u2 flagged for acceptance
package release.debian.org tags 964411 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: c-icap-modules Version: 0.4.4-1+deb9u2 Explanation: support ClamAV 0.102
Bug#964727: jackson-databind 2.8.6-1+deb9u7 flagged for acceptance
package release.debian.org tags 964727 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: jackson-databind Version: 2.8.6-1+deb9u7 Explanation: fix multiple security issues affecting BeanDeserializerFactory [CVE-2020-9548 CVE-2020-9547 CVE-2020-9546 CVE-2020-8840 CVE-2020-14195 CVE-2020-14062 CVE-2020-14061 CVE-2020-14060 CVE-2020-11620 CVE-2020-11619 CVE-2020-3 CVE-2020-2 CVE-2020-1 CVE-2020-10969 CVE-2020-10968 CVE-2020-10673 CVE-2020-10672 CVE-2019-20330 CVE-2019-17531 and CVE-2019-17267]
Bug#964398: libembperl-perl 2.5.0-10+deb9u1 flagged for acceptance
package release.debian.org tags 964398 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: libembperl-perl Version: 2.5.0-10+deb9u1 Explanation: handle error pages from Apache >= 2.4.40
Bug#893548: python-icalendar 3.8-1+deb9u1 flagged for acceptance
package release.debian.org tags 893548 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: python-icalendar Version: 3.8-1+deb9u1 Explanation: fix Python3 dependencies
Bug#892932: websockify 0.8.0+dfsg1-7+deb9u1 flagged for acceptance
package release.debian.org
tags 892932 = stretch pending
thanks
Hi,
The upload referenced by this bug report has been flagged for acceptance into
the proposed-updates queue for Debian stretch.
Thanks for your contribution!
Upload details
==
Package: websockify
Version: 0.8.0+dfsg1-7+deb9u1
Explanation: add messing dependency on python{3,}-pkg-resources
Bug#935739: sendmail 8.15.2-8+deb9u1 flagged for acceptance
package release.debian.org tags 935739 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: sendmail Version: 8.15.2-8+deb9u1 Explanation: fix finding the queue runner control process in "split daemon" mode, "NOQUEUE: connect from (null)", removal failure when using BTRFS
Bug#891657: swt-gtk 3.8.2-3+deb9u1 flagged for acceptance
package release.debian.org tags 891657 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: swt-gtk Version: 3.8.2-3+deb9u1 Explanation: add missing dependency on libwebkitgtk-1.0-0
Bug#964244: xml-security-c 1.7.3-4+deb9u3 flagged for acceptance
package release.debian.org tags 964244 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: xml-security-c Version: 1.7.3-4+deb9u3 Explanation: fix length calculation in the concat method
Bug#964599: [Pkg-roundcube-maintainers] Bug#964599: Roundcube-core Overwrites Local Changes in _styles.less
Control: retitle -1 upgrades overwrites local style customization Control: severity -1 wishlist On Thu, 09 Jul 2020 at 06:09:02 -0500, Bryan Walton (Debian) via Pkg-roundcube-maintainers wrote: > _styles.less, located in /usr/share/roundcube/skins/elastic/styles, is a > file that exists for local customizations of the roundcube templates. The > file, as shipped by Debian has one line in it, that reads: > > /* Here you can put your custom styles that will be appended to the output > css file */ That file (as well as ‘_variables.less’) comes from upstream. Not sure how best to add support for local style customization in the package. * We could build styles.css at postinst stage. This is my least favorite option, because it adds a runtime dependency on node-less, which transitively pulls in 61 new packages (>50MiB additional disk space) at install time on a minimal sid chroot with `--no-install-recommends`. It might also make the package uninstallable if lessc(1) upstream changes their CLI interface. This is not speculation, following a node upgrade less recently failed to write output to stdout. As of the current node-less/3.11.2+dfsg-2, `lessc -x` yields “The compress option has been deprecated. We recommend you use a dedicated css minifier, for instance see less-plugin-clean-css.” I would much rather have FTBS bugs than a broken postinstall script on (some) user systems. We could also ship styles.css, demote the dependency to Suggests: (which makes more sense than a hard Depends: given local style customization are purely optional), and only rebuild it when lessc(1) is found in $PATH *and* local changes are detected, keeping the file intact in case the command fails. However this is not satisfactory either as it'd make tools like debsums(1) might complain that the file doesn't match what's found in the package metadata. Plus the postinst script runs with root privileges and it seems non-ideal at best to run lessc(1) with these privileges. * We could add a note to ‘styles/_*.less’ saying the user needs to manually install node-less and manually run `less -x` after each upgrade. Not ideal either, we might preserve local changes to ‘styles/_*.less’ but will overwrite the CSS anyway. That shifts the burden from package maintainer onto users. Any other option? Avoiding overwriting users changes is the easy part. We could either stop shipping ‘styles/_*.less’, or better symlink these files from ‘/etc/roundcube/skins/elastic’ and let dpkg do the magic. Note that it is pretty usual to overwrite local changes outside of /etc (that is, unless the local admin adds a dpkg diversion); despite what the upstream file reads we never claimed otherwise, so I'm lowering the severity. -- Guilhem. signature.asc Description: PGP signature
Bug#963548: Received signal 11 SEGV_MAPERR
The bug has been reported upstream: https://bugs.chromium.org/p/chromium/issues/detail?id=1102805 Forwarding good news from one of numerous dupes of this Debian bug, thanks Riku: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964451#25 On Thu, 9 Jul 2020 10:29:36 + Riku Voipio wrote: > This should fix it: > > https://salsa.debian.org/chromium-team/chromium/-/commit/b904fa41d40b967dcc8f6984db52f7a2f6a2c83d > > We are not building with GCC but this seems to be exactly the place where the > crash happens. > chromium built with this patch has not crashed for the last few hours for me, > while before it would > crash in a few minutes. > > Riku Regards, Andrey
Bug#964588: fwupd 0.8.3-1 flagged for acceptance
package release.debian.org tags 964588 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: fwupd Version: 0.8.3-1 Explanation: new upstream release; use a CNAME to redirect to the correct CDN for metadata; do not abort startup if the XML metadata file is invalid; add the Linux Foundation public GPG keys for firmware and metadata; raise the metadata limit to 10Mb
Bug#964291: mariadb-10.1 10.1.45-0+deb9u1 flagged for acceptance
package release.debian.org tags 964291 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: mariadb-10.1 Version: 10.1.45-0+deb9u1 Explanation: new upstream stable release; security fixes [CVE-2020-2752 CVE-2020-2812 CVE-2020-2814]
Bug#949367: wpa 2.4-1+deb9u6 flagged for acceptance
package release.debian.org tags 949367 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: wpa Version: 2.4-1+deb9u6 Explanation: fix AP mode PMF disconnection protection bypass [CVE-2019-16275]; fix MAC randomisation issues with some cards
