Bug#985891: [bastula/dicompyler] Please do not use private module matplotlib._cntr (#137)
Hi Aditya, On Fri, Apr 09, 2021 at 08:18:15PM -0700, Aditya Panchal wrote: > Hope you are doing well. It is possible to use the `legacycontour` package > available here: https://github.com/matplotlib/legacycontour and follow the > instructions by Alan listed here: > https://github.com/bastula/dicompyler/issues/122. That should at least allow > the program to function correctly with `matplotlib >= 2.2`. This will not the problem for the Debian package. The module `legacycontour` is not (yet) packaged for Debian and since we are in freeze currently no new packages are permitted. > Another option that is possible is to swap to `measure_contours` from > `scikit-image` as outlined here: > https://github.com/bastula/dicompyler/issues/122#issuecomment-570842862 but > introduces a much heavier dependency. One of the goals of dicompyler is to be > lightweight. I admit I have no idea about the goals and features of dicompyler. I'm not using it and simply took over the maintenance in Debian from some developer who left the team to salvage it for the users of the Debian package. So if you can provide a working patch I will include it in the Debian package which will safe it for the next stable release - otherwise it will be removed from there which would be a shame. Kind regards, Andreas.
Processed: cloning 986479, reassign -1 to src:rsnapshot ..., severity of -1 is serious
Processing commands for cont...@bugs.debian.org: > clone 986479 -1 Bug #986479 [ftp.debian.org] RM rsnapshot -- RoM; RoQA; no longer maintained by upstream Bug 986479 cloned as bug 986709 > reassign -1 src:rsnapshot Bug #986709 [ftp.debian.org] RM rsnapshot -- RoM; RoQA; no longer maintained by upstream Bug reassigned from package 'ftp.debian.org' to 'src:rsnapshot'. Ignoring request to alter found versions of bug #986709 to the same values previously set Ignoring request to alter fixed versions of bug #986709 to the same values previously set > retitle -1 rsnapshot: not suitable for stable release Bug #986709 [src:rsnapshot] RM rsnapshot -- RoM; RoQA; no longer maintained by upstream Changed Bug title to 'rsnapshot: not suitable for stable release' from 'RM rsnapshot -- RoM; RoQA; no longer maintained by upstream'. > severity -1 serious Bug #986709 [src:rsnapshot] rsnapshot: not suitable for stable release Severity set to 'serious' from 'normal' > thanks Stopping processing here. Please contact me if you need assistance. -- 986479: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986479 986709: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986709 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986701: mosquitto: CVE-2021-28166
This will be fixed soon, I would like to include an autopkgtest in the package, otherwise this would have been updated already. On Fri, 9 Apr 2021 at 20:27, Salvatore Bonaccorso wrote: > > Source: mosquitto > Version: 2.0.9-1 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerability was published for mosquitto. > > CVE-2021-28166[0]: > | In Eclipse Mosquitto version 2.0.0 to 2.0.9, if an authenticated > | client that had connected with MQTT v5 sent a crafted CONNACK message > | to the broker, a NULL pointer dereference would occur. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2021-28166 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28166 > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=572608 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore
Bug#986592: marked as done (kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread)
Your message dated Fri, 09 Apr 2021 22:18:25 + with message-id and subject line Bug#986592: fixed in kaptive 0.7.3-2 has caused the Debian Bug report #986592, regarding kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 986592: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: kleborate Version: 2.0.1-1 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), Your package has an autopkgtest, great. However, I looked into the history of your autopkgtest [1] and I noticed the it fails regularly on ppc64el, while a rerun passes. I copied some of the output at the bottom of this report. It's not always the same place where the issue acures. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Paul PS: if you fix this for bullseye, our migration tooling will not correctly detect it can migrate according to the freeze rules due to it scheduling tests on i386 and armhf where no arch specific package is built. Ping me and if otherwise OK, I'll hint it through. [1] https://ci.debian.net/packages/k/kleborate/testing/arm64/ https://ci.debian.net/data/autopkgtest/testing/arm64/k/kleborate/11152715/log.gz autopkgtest [09:23:49]: test run-unit-test: [--- strain species ST virulence_score Yersiniabactin YbSTColibactin CbST Aerobactin AbSTSalmochelin SmSTRmpADC RmSTrmpA2 wzi K_locus Klebs_HS11286 Klebsiella pneumoniae ST111 ybt 9; ICEKp3 15 - 0 - 0 - 0 - 0 - wzi74 KL103 Klebs_Kp1084Klebsiella pneumoniae ST232 ybt 1; ICEKp10 47 clb 2 37 - 0 - 0 - 0 - wzi172 KL1 MGH78578Klebsiella pneumoniae ST380 - 0 - 0 - 0 - 0 - 0 - wzi50 KL15 (KL17,KL51,KL52) NTUH-K2044 Klebsiella pneumoniae ST234 ybt 2; ICEKp1 326 - 0 iuc 1 1 iro 1,iro 3 19,18 rmp 3; ICEKp1,rmp 1; KpVP-1 30-1LV,26 rmpA2_3-47% wzi1KL1 strain species ST virulence_score resistance_scoreYersiniabactin YbSTColibactin CbSTAerobactin AbSTSalmochelin SmST RmpADC RmST rmpA2 wzi K_locus AGly_acquired Col_acquiredFcyn_acquired Flq_acquiredGly_acquiredMLS_acquiredPhe_acquiredRif_acquired Sul_acquiredTet_acquiredTgc_acquiredTmt_acquiredBla_acquired Bla_inhR_acquired Bla_ESBL_acquired Bla_ESBL_inhR_acquired Bla_Carb_acquired Bla_chr SHV_mutations Omp_mutations Col_mutations Flq_mutations truncated_resistance_hits spurious_resistance_hits Klebs_HS11286 Klebsiella pneumoniae ST111 3 ybt 9; ICEKp3 15 - 0 - 0 - 0 - 0 - wzi74 KL103 aadA2^;rmtB;strA.v1^;strB.v1- - - - - - - sul2tet(G).v1 - dfrA12* TEM-1;TEM-1;TEM-1 - CTX-M-14;CTX-M-14 - KPC-2 SHV-11.v1 35Q OmpK35-40% PmrB-10%GyrA-83I;ParC-80I aac(3)-IId*?-0% floR.v2*?;sul1?-63% Klebs_Kp1084Klebsiella pneumoniae ST232 0 ybt 1; ICEKp10 47 clb 2 37 - 0 - 0 - 0 - wzi172 KL1 - - - - - - - - - - - - - - - - - SHV-11.v1^ 35Q - - - - - MGH78578Klebsiella pneumoniae ST380 1 - 0 - 0 - 0 - 0 - 0 - wzi50 KL15 (KL17,KL51,KL52) aac(6')-Ib'.v1;aadA*;ant(2'')-Ia;aph(3')-Ia;strA.v1;strB.v1 - - - - - catA1*;cmlA5- sul1;sul2 tet(D) - - TEM-1D.v1^;TEM-1D.v1^ - SHV-12 - - SHV-11.v1^ 238S;240K;35Q;35Q OmpK35-86% - GyrA-83Y OXA-9.v1*-42% - NTUH-K2044 Klebsiella pneumoniae ST234 0 ybt 2; ICEKp1 326
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Control: reassign -1 kaptive 0.7.3-1 Andreas Tille writes: > Thanks a lot. Its very relieving to know a competent person behind > this I appreciate the kind words, but am alas unclear on where precisely BLAST+ is going wrong here. That said, I do see that future releases will incorporate an overhaul of some of the relevant portions of libseqdb, which with any luck will help in the long term, but which I'd rather not try to backport at this stage of the release cycle. The good news is that in response to previous issues along these lines (e.g., https://bugs.debian.org/970344), kleborate already supports retrying in single-threaded mode under some circumstances; kaptive just needs to indicate that it should do so, which it currently does only for much older versions. I'll extend the relevant version range shortly, and am reassigning this bug accordingly. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Processed: Re: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Processing control commands: > reassign -1 kaptive 0.7.3-1 Bug #986592 [src:kleborate] kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread Bug reassigned from package 'src:kleborate' to 'kaptive'. No longer marked as found in versions kleborate/2.0.1-1. Ignoring request to alter fixed versions of bug #986592 to the same values previously set Bug #986592 [kaptive] kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread Marked as found in versions kaptive/0.7.3-1. -- 986592: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x
On 8 April 2021 at 11:29, Graham Inggs wrote: | Control: forwarded -1 https://deb.li/6f4z | | TMB upstream have submitted a bug report [1] to R-forge. | | > Headers need update corresponding to new SuiteSparse version 5.7.1 | > | > SuiteSparse was recently updated from version 4.2.1 to 5.7.1, however without updating the header `inst/cholmod.h` accordingly. Notably the cholmod_common struct no longer has a member 'print_function'. See also https://github.com/glmmTMB/glmmTMB/issues/665 | | | [1] https://r-forge.r-project.org/tracker/index.php?func=detail=6714_id=61=294 Fantastic. On 9 April 2021 at 10:43, Graham Inggs wrote: | Control: tags -1 + fixed-upstream | | Fixed in Matrix upstream svn rev 3376 [1]. | | | [1] https://r-forge.r-project.org/scm/viewvc.php?view=rev=matrix=3376 Even better. Big BIG Thank You for persistently chasing that to the end. Thank you! Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Processed: found 986251 in 3.1.2-0+deb10u1
Processing commands for cont...@bugs.debian.org:
> found 986251 3.1.2-0+deb10u1
Bug #986251 {Done: Salvatore Bonaccorso }
[src:python-bleach] python-bleach: CVE-2021-23980
Marked as found in versions python-bleach/3.1.2-0+deb10u1.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
986251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: tagging 986525, bug 986525 is forwarded to https://github.com/aio-libs/yarl/issues/563
Processing commands for cont...@bugs.debian.org:
> tags 986525 + upstream
Bug #986525 [src:yarl] yarl: FTBFS: dh_auto_test: error: pybuild --test
--test-pytest -i python{version} -p 3.9 returned exit code 13
Added tag(s) upstream.
> forwarded 986525 https://github.com/aio-libs/yarl/issues/563
Bug #986525 [src:yarl] yarl: FTBFS: dh_auto_test: error: pybuild --test
--test-pytest -i python{version} -p 3.9 returned exit code 13
Set Bug forwarded-to-address to 'https://github.com/aio-libs/yarl/issues/563'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
986525: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986525
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#986692: crash at startup
I can confirm this, and the backtrace looks similar: #0 0x00080005 in ?? () #1 0x77a1d879 in _Unwind_ForcedUnwind_Phase2 (exc=0x55614e90, context=0x7fffdd70, frames_p=0x7fffdc78) at ../../../src/libgcc/unwind.inc:170 #2 0x77a1e14d in _Unwind_Resume (exc=exc@entry=0x55614e90) at ../../../src/libgcc/unwind.inc:243 #3 0x55560c65 in __gnu_cxx::new_allocator::~new_allocator (this=, __in_chrg=) at /usr/include/c++/9/ext/new_allocator.h:89 #4 std::allocator::~allocator (this=0x7fffdeb0, __in_chrg=) at /usr/include/c++/9/bits/allocator.h:153 #5 std::__cxx11::basic_string, std::allocator >::_Alloc_hider::~_Alloc_hider (this=, __in_chrg=) at /usr/include/c++/9/bits/basic_string.h:150 #6 std::__cxx11::basic_string, std::allocator >::~basic_string (this=, __in_chrg=) at /usr/include/c++/9/bits/basic_string.h:658 #7 Levels::addLevel (this=, file="/usr/share/numptyphysics/L99_Gravity_Test.nph", rank=99, index=-1) at Levels.cpp:117 valgrind says: Invalid read of size 8 at 0x4DFA810: ??? (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1) by 0x4DFB14C: _Unwind_Resume (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1) by 0x114C64: ~new_allocator (new_allocator.h:89) by 0x114C64: ~allocator (allocator.h:153) by 0x114C64: ~_Alloc_hider (basic_string.h:150) by 0x114C64: ~basic_string (basic_string.h:658) by 0x114C64: Levels::addLevel(std::__cxx11::basic_string, std::allocator > const&, int, int) [clone .cold] (Levels.cpp:117) by 0x11C9B3: Levels::addPath(char const*) (Levels.cpp:93) by 0x11C8CD: Levels::addPath(char const*) (Levels.cpp:104) by 0x12C7FE: runGame (App.cpp:184) by 0x12C7FE: run (App.cpp:110) by 0x12C7FE: npmain(int, char**) (App.cpp:372) by 0x1174FA: main (OsFreeDesktop.cpp:133) Address 0x68ec6b8 is 0 bytes after a block of size 24 alloc'd at 0x4838DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x12BD89: runGame (App.cpp:173) by 0x12BD89: run (App.cpp:110) by 0x12BD89: npmain(int, char**) (App.cpp:372) by 0x1174FA: main (OsFreeDesktop.cpp:133) Some debugging suggests that the string being destroyed when it crashes is the "My Levels" std::string created from the static const char MISC_COLLECTION[] in Levels::addLevel() (no idea what is the problem with this code). -- WBR, wRAR signature.asc Description: PGP signature
Bug#986701: mosquitto: CVE-2021-28166
Source: mosquitto Version: 2.0.9-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for mosquitto. CVE-2021-28166[0]: | In Eclipse Mosquitto version 2.0.0 to 2.0.9, if an authenticated | client that had connected with MQTT v5 sent a crafted CONNACK message | to the broker, a NULL pointer dereference would occur. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-28166 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28166 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=572608 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#984614: snort in Bullseye
Control: found -1 2.9.15.1-2 Hi, it appears this conffile handling problem is caused by a not good enough attempt to move the old conffile /etc/cron.daily/5snort to /etc/cron.daily/snort-common. This was introduced in version 2.9.15.1-2 commit 8780db8c, to snort-common.preinst: +# rename probably existing cron job with old name +if [ -e /etc/cron.daily/5snort ]; then +mv /etc/cron.daily/5snort /etc/cron.daily/snort-common +fi It would appear trivial to change this to use dpkg-maintscript-helper mv_conffile instead. Someone with enough interest in snort should probably just make this change and upload it. Chris
Processed: Re: Bug#984614: snort in Bullseye
Processing control commands: > found -1 2.9.15.1-2 Bug #984614 [snort-common] snort-common: prompting due to modified conffiles which were not modified by the user: /etc/cron.daily/snort-common Marked as found in versions snort/2.9.15.1-2. -- 984614: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984614 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986274: marked as done (pikepdf: CVE-2021-29421)
Your message dated Fri, 09 Apr 2021 18:03:35 + with message-id and subject line Bug#986274: fixed in pikepdf 1.17.3+dfsg-5 has caused the Debian Bug report #986274, regarding pikepdf: CVE-2021-29421 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 986274: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986274 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: pikepdf Version: 1.17.3+dfsg-4 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for pikepdf. CVE-2021-29421[0]: | models/metadata.py in the pikepdf package 1.3.0 through 2.9.2 for | Python allows XXE when parsing XMP metadata entries. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-29421 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29421 [1] https://github.com/pikepdf/pikepdf/commit/3f38f73218e5e782fe411ccbb3b44a793c0b343a Regards, Salvatore --- End Message --- --- Begin Message --- Source: pikepdf Source-Version: 1.17.3+dfsg-5 Done: Sean Whitton We believe that the bug you reported is fixed in the latest version of pikepdf, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 986...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sean Whitton (supplier of updated pikepdf package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 09 Apr 2021 10:41:33 -0700 Source: pikepdf Architecture: source Version: 1.17.3+dfsg-5 Distribution: unstable Urgency: medium Maintainer: Debian Python Team Changed-By: Sean Whitton Closes: 986274 Changes: pikepdf (1.17.3+dfsg-5) unstable; urgency=medium . * Cherry pick upstream commit 3f38f73 to fix CVE-2021-29421 (Closes: #986274). Checksums-Sha1: 32a1140b0c700106e134541b6096e75a0eb5c0eb 2622 pikepdf_1.17.3+dfsg-5.dsc 7ae743164f5476ff6edd7ce880f53f20dca85097 1931744 pikepdf_1.17.3+dfsg-5.debian.tar.xz Checksums-Sha256: 9ce694335d212af62ac7f8617a32272b1b712c44cebf78bb9db3796e7587a467 2622 pikepdf_1.17.3+dfsg-5.dsc 0d952305f6084f0f5a533e3ca2c93581136835617ad9537c60be31f4ac285a41 1931744 pikepdf_1.17.3+dfsg-5.debian.tar.xz Files: 9013cd58e618a309206807aeacc27d17 2622 python optional pikepdf_1.17.3+dfsg-5.dsc 0d55215747e4ac87a2ca0248934580e9 1931744 python optional pikepdf_1.17.3+dfsg-5.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmBwkfAACgkQaVt65L8G YkBPjg//YxnNOGlljquo72O/4e+kaBJClaEUgiOAkaB4AZPVRhKAC9YElK3f5WDi OHrlkh31UMMjwH+lCUKD2ZVpd2D/vxa5RVH71qTUMs8msfX9ac0I6fSU1nuMlGXJ o50NnGS2+U7khNn/W9Nw1GCoKnsA87+FyegInCTStbLt2nf1zheSh3pbHvJrdB4l 45fUgM3qUkxddP3FB8upJei+/L4qlgDARL1Mc9dGIUGCdIHa6KRfpLOZKcqcMa7H igNa9WYnmyVmUgDzqclaRoCdfGQLBAPPcvHLkEg6aFjJuCrSwY7akF4R1BlkJFVX lVnmC/jk7byIoC2rK4IyBIiYcDBlTTVtty+FauM3X4G6lY3Vd6qkeLwrimavR/Sy /JsHfUgKpV79yAKqO1inH13L7MmK9IKiISUzntuEgC4jspsnbP8vek7ZJbONYw34 iTYKJ9J439aDcI4BGf3afBvQuPSrV6CtEElMCEVYvlZ6JoDRiWhrPNOhaN9yLlaF 9NNe7GeaC69C9fnECyjqMN/fGlcRoVePsEav2KPt+Gtq4AjjLDzyz/z6DQnNg/VK iZ4/1fWH5EnxGiMfUNW9PROpxy+wk0xly9rNWfTtZRmn60Ww9XJRp+wNanKIkw6z I1venVzlY3Gd6FYOEHlISIrvPVohGpORpARpoR1KzF9MS3yNtI4= =yJkU -END PGP SIGNATURE End Message ---
Bug#986695: prometheus-mongodb-exporter: MongoDB exporter segfaults when connecting with relatively recent MongoDB databases
Package: prometheus-mongodb-exporter Version: 1.0.0+git20180522.e755a44-1+b20 Severity: grave Tags: upstream Justification: renders package unusable Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Paragoumba To: Debian Bug Tracking System Subject: prometheus-mongodb-exporter: Mongodb Exporter segfaults with new versions of MongoDB Message-ID: <161798894396.8376.16006048479438587500.report...@5h4d0w-tp.pulseheberg.com> X-Mailer: reportbug 7.5.3~deb10u1 Date: Fri, 09 Apr 2021 19:22:23 +0200 Package: prometheus-mongodb-exporter Version: 1.0.0+git20180522.e755a44-1+b20 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, * What led up to the situation? I tried to install prometheus-mongodb-exporter to export statistics about my MongoDB instance. After multiple attempt to make it connect to the database, I stopped the systemd service and ran it by hand and noticed it segfaults upon connecting. * What exactly did you do (or not do) that was effective (or ineffective)? I checked multiple times the config and that proved to be ineffective. The problem doesn't come from a faulty configuration. The package is incompatible with the newer versions of MongoDB * What was the outcome of this action? It still segfaults * What outcome did you expect instead? I expect the software to connect successfully and export data It appears that the upstream github repository (https://github.com/dcu/mongodb_exporter) from which this package is built hasn't been updated in two years. This other repo (https://github.com/percona/mongodb_exporter) contains the same sources but is actively maintained. I know it's not unusual for the Debian packages to be several version late but this version is completely unusable and the only solution for now is to not use the package in the Debian repositories and to install it from source. -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/8 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prometheus-mongodb-exporter depends on: ii daemon 0.6.4-1+b2 ii libc6 2.28-10 prometheus-mongodb-exporter recommends no packages. prometheus-mongodb-exporter suggests no packages. -- Configuration Files: /etc/default/prometheus-mongodb-exporter changed [not included] -- debconf-show failed -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/8 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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prometheus-mongodb-exporter depends on: ii daemon 0.6.4-1+b2 ii libc6 2.28-10 prometheus-mongodb-exporter recommends no packages. prometheus-mongodb-exporter suggests no packages. -- Configuration Files: /etc/default/prometheus-mongodb-exporter changed [not included] -- debconf-show failed
Bug#986692: crash at startup
here the backtrace Type "apropos word" to search for commands related to "word"... Reading symbols from numptyphysics... Reading symbols from /usr/lib/debug/.build-id/1c/669beb5cdc6578b37b1e53e575baefe21524ff.debug... (gdb) r Starting program: /usr/games/numptyphysics [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x762e7700 (LWP 724966)] Thread 1 "numptyphysics" received signal SIGSEGV, Segmentation fault. 0x779f308f in _Unwind_Resume () from /lib/x86_64-linux-gnu/libgcc_s.so.1 (gdb) l 118 OsFreeDesktop.cpp: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x779f308f in _Unwind_Resume () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #1 0x55560c58 in __gnu_cxx::new_allocator::~new_allocator (this=, __in_chrg=) at /usr/include/c++/10/ext/new_allocator.h:89 #2 std::allocator::~allocator (this=, __in_chrg=) at /usr/include/c++/10/bits/allocator.h:162 #3 std::__cxx11::basic_string, std::allocator >::_Alloc_hider::~_Alloc_hider (this=out>, __in_chrg=) at /usr/include/c++/10/bits/basic_string.h:150 #4 std::__cxx11::basic_string, std::allocator >::~basic_string (this=, __in_chrg=) at /usr/include/c++/10/bits/basic_string.h:658 #5 Levels::addLevel (this=, file="/usr/share/numptyphysics/L99_Gravity_Test.nph", rank=99, index=-1) at Levels.cpp:117 #6 0x555682f1 in Levels::addPath (this=0x5560cff0, path=0x555f3ef0 "/usr/share/numptyphysics/L99_Gravity_Test.nph") at Levels.cpp:93 #7 0x55568070 in Levels::addPath (this=this@entry=0x5560cff0, path=path@entry=0x5559ba6a "/usr/share/numptyphysics") at /usr/include/c++/10/bits/basic_string.h:186 #8 0x55575214 in App::runGame (height=480, width=800, files=..., this=0x7fffdfe0) at App.cpp:184 #9 App::run (this=0x7fffdfe0) at App.cpp:110 #10 0x55573726 in npmain (argc=argc@entry=1, argv=argv@entry=0x7fffe1b8) at App.cpp:372 #11 0x55562c0b in main (argc=1, argv=0x7fffe1b8) at OsFreeDesktop.cpp:133
Bug#986692: crash at startup
Package: numptyphysics Version: 0.2+svn157-0.4 Severity: grave X-Debbugs-Cc: pi...@debian.org the prgram do not start and crash at startup -- System Information: Debian Release: bullseye/sid APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages numptyphysics depends on: ii fonts-femkeklaver1.0-3 ii libc62.31-11 ii libfontconfig1 2.13.1-4.2 ii libgcc-s1 [libgcc1] 10.2.1-6 ii libsdl-image1.2 1.2.12-12 ii libsdl-ttf2.0-0 2.0.11-6 ii libsdl1.2debian 1.2.15+dfsg2-6 ii libstdc++6 10.2.1-6 ii libx11-6 2:1.7.0-2 ii zlib1g 1:1.2.11.dfsg-2 numptyphysics recommends no packages. numptyphysics suggests no packages. -- no debconf information
Bug#985739: unblock: krb5/1.18.3-5
Control: tags 986051 confirmed moreinfo Hi Sam, On Sun, Mar 28, 2021 at 02:13:29PM -0400, Sam Hartman wrote: > [ Reason ] > In #985739 it was pointed out that internal symbols disappeared from > libk5crypto. > My bad; I noticed this, confirmed they were not externally visible, approved > the symbols file change, but didn't think about the upgrade implications. > > What happens is that if the new libk5crypto3 is unpacked before the > new libkrb5-3, the old libkrb5-3 breaks. In the bug, the user managed > to get into a position where pam_krb5 was broken and logins didn't > work. I was able to reproduce this issue with the following steps: I started from the debian-10-generic-amd64-20210208-542.qcow2 buster cloud image, and made sure root was able to login on the console (by setting a password). After this, installing libk5crypto3 and libpam-modules from bullseye (and the dependencies pulled in by apt) triggers this issue. At that point, root is no longer able to log in on the console (I was able to login via ssh using a key). Installing libkrb5-3 from bullseye fixes the issue. The issue can also be triggered by installing libpam-krb5 (from buster), and only upgrading libk5crypto3 to bullseye. > So, update the breaks, or add an equals binary:Version depends, no big, right? > > While I wasn't looking, krb5 has apparently become part of > pseudo-essential. > login->libpam-modules->libnsl->libtirpc3->libgssapi-krb5-2->libk5crypto3|libkrb5-3 > The only reason I even know that is because I've been tracking pam. > > Long term, we don't want that. > > As a result, it's probably the case in #985739 that pam_unix is broken as > well as pam_krb5. > > I'm not really an expert on all the ways that dependency resolution > gets complex for essential packages. I do know that dependencies for > essential packages are supposed to be pre-depends. That's not > currently the case for anything in krb5, or for libkeyutils, > libcomerr-2, etc. > > So, we have a few options. > > 1) Add the breaks. Things are fairly stable in this part of the > dependency graph; it was 2016 when libk5crypto last had an > internally-incompatible break. That will probably work in practice. > > On #debian-devel, Adrian Bunk argues that it should be a versioned conflicts > not a break > because it's essential. I'm not sure--I think in most situations the > fact that you cannot unpack the breaking package without deconfiguring > the broken package means that apt will simply reorder things so that > libk5crypto3 comes before libkrb5-3 and all happens to be well with > the breaks. I did some tests with modified binaries with either the breaks or the conflicts. Both result in the same upgrade order. Looking at policy 7.4, the argument for conflicts could be that this is a case "that must prevent both packages from being unpacked at the same time, not just configured". https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts I don't know if there is any situation where apt/dpkg would unpack libk5crypto3 before libkrb5-3 if the breaks is present, so I don't know if it makes any difference in practice. Note that it's possible to install only libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0 from bullseye on a buster system, and have a working system (note that I didn't test if kerberos is actually working in this case, as I don't have a kerberos setup). This means that I'm fairly confident that apt will be able to solve this issue without creating other breakage, by just upgrading these packages first (which it does in my tests). I would unblock an upload with either the breaks or the conflicts. > 2) Do we also want to add the pre-depends to krb5. I'm nervous adding > additional pre-depends this late in the process. > > 3) Do we want to add pre-depends to the entire dependency chain from > libpam-modules to libkeyutils|libcom-err2? I think this is > technically correct, but I am uncomfortable with it. I agree that adding pre-depends at this point doesn't sound like something that we should try. > 4) Do we want to do enough surgery to pam to avoid krb5 being > essential. With my pam hat on in January, I concluded it was too late > in the process for me to feel comfortable adequately testing a (not > yet developed) patch. That was before I realized how big of a deal it > might be that krb5 had become essential. > The solution basically involves making pam_unix dlopen its dependencies for > nis rather than link-time dependencies. So, ugly games with c macros or > wrappers trying to get some internally typed NIS APIs right. > I definitely do not have time to develop the patch, although I could > potentially make time to review and help test. > I consider this risky for bullseye. I agree here as well. > I think my recommendation is go approve the breaks change, and hope that's > good enough in practice. OK. Please remove the moreinfo tag from the unblock bug when the
Processed: Re: diaspora-installer: fails to install: Your bundle is locked to mimemagic (0.3.5), but that version could not be found
Processing control commands: > forwarded -1 https://github.com/diaspora/diaspora/issues/8229 Bug #986286 [diaspora-installer] diaspora-installer: fails to install: Your bundle is locked to mimemagic (0.3.5), but that version could not be found Set Bug forwarded-to-address to 'https://github.com/diaspora/diaspora/issues/8229'. -- 986286: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986286 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986286: diaspora-installer: fails to install: Your bundle is locked to mimemagic (0.3.5), but that version could not be found
Control: forwarded -1 https://github.com/diaspora/diaspora/issues/8229 On Fri, 02 Apr 2021 14:21:14 +0200 Andreas Beckmann > Fetching gem metadata from https://gems.diasporafoundation.org/.. > Fetching gem metadata from https://rubygems.org/.. > [ESC][31mYour bundle is locked to mimemagic (0.3.5), but that version could not be found > in any of the sources listed in your Gemfile. If you haven't changed sources, > that means the author of mimemagic (0.3.5) has removed it. You'll need to update > your bundle to a version other than mimemagic (0.3.5) that hasn't been removed > in order to install.[ESC][0m > dpkg: error processing package diaspora-installer (--configure): A lot of projects are affected by this change, https://www.theregister.com/2021/03/25/ruby_rails_code/
Bug#985054: #985054 - pending migration
Pinging this bug to avoid autoremoval, before migration of a fixed package could happen. One would hope the autoremovals logic would take care of such things, but apparently not. Chris
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
On Fri, Apr 09, 2021 at 08:13:52AM -0400, Aaron M. Ucko wrote: > Don't worry, I am still looking into this crash, and had primarily > intended that comment as a public note to myself -- the crash occured > within a (presumably valid) call to ncbi-blast+, and wound up taking > quite a few tries to reproduce on the porterbox I was using (amdahl), so > once I finally obtained more details, I wanted to make very sure I > wouldn't be able to lose them. Sorry for any resulting confusion. Thanks a lot. Its very relieving to know a competent person behind this Andreas. -- http://fam-tille.de
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Andreas Tille writes: > Thanks a lot for your investigation. Unfortunately I have no idea how > to proceed from here. Does anybody have an idea? I mean a better idea > than just stating this package does not work on arm64 which would > probably some last resort. Don't worry, I am still looking into this crash, and had primarily intended that comment as a public note to myself -- the crash occured within a (presumably valid) call to ncbi-blast+, and wound up taking quite a few tries to reproduce on the porterbox I was using (amdahl), so once I finally obtained more details, I wanted to make very sure I wouldn't be able to lose them. Sorry for any resulting confusion. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#986565: marked as done (unusable with current git)
Your message dated Fri, 09 Apr 2021 12:03:25 + with message-id and subject line Bug#986565: fixed in git-flow 1.12.3-2 has caused the Debian Bug report #986565, regarding unusable with current git to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 986565: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986565 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: git-flow Version: 1.12.3-1 Severity: grave Tags: patch Today 'flow' is not a supported git command: $git flow git: 'flow' is not a git command. See 'git --help'. The most similar commands are reflog show Running it under strace reveals that git looks for commands under /usr/libexec/git-core, while git-flow installs things under /usr/lib/git-core Perhaps this is caused by a change in the search path in git and git-flow needs to adapt. Replacing /usr/lib/git-core with /usr/libexec/git-core in debian/install.mk seems to fix the problem. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-flow depends on: ii git [git-core] 1:2.31.0-1 ii git-core1:2.15.0~rc0-1 git-flow recommends no packages. git-flow suggests no packages. -- debconf-show failed --- End Message --- --- Begin Message --- Source: git-flow Source-Version: 1.12.3-2 Done: Laszlo Boszormenyi (GCS) We believe that the bug you reported is fixed in the latest version of git-flow, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 986...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Laszlo Boszormenyi (GCS) (supplier of updated git-flow package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 09 Apr 2021 13:39:24 +0200 Source: git-flow Architecture: source Version: 1.12.3-2 Distribution: unstable Urgency: medium Maintainer: Laszlo Boszormenyi (GCS) Changed-By: Laszlo Boszormenyi (GCS) Closes: 986565 Changes: git-flow (1.12.3-2) unstable; urgency=medium . [ Damyan Ivanov ] * Fix installation directory (closes: #986565). Checksums-Sha1: 613292e306cf6b47389cec3435de1fccfdcd0600 2005 git-flow_1.12.3-2.dsc ef2674249e3d43951e84c4f9ca3342ccee4c7496 4620 git-flow_1.12.3-2.debian.tar.xz Checksums-Sha256: 90a49b056d6ea5d77ea99a3aebc6c1122299f95cbc308f3feca3fca0ad07ec79 2005 git-flow_1.12.3-2.dsc a46ce9c4ee3f3b37c10ad60c727f424ec9e2a0a7b2202b9d64c9bf43c09a85b3 4620 git-flow_1.12.3-2.debian.tar.xz Files: 48d6ecff8afb5018a753e64ac871810e 2005 vcs optional git-flow_1.12.3-2.dsc c061a9a2056c8ae2e868eef9e3f984a0 4620 vcs optional git-flow_1.12.3-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEfYh9yLp7u6e4NeO63OMQ54ZMyL8FAmBwPqQACgkQ3OMQ54ZM yL/lchAAgsDGU4uyCGVKX58N7t69YeAGxR8woF4HmlCht+rPQhwioFWZun1X5e2g 78yBR7P7H/9JcFKbvQ4ACCttLd0iPsHSNqFNMxwIclcIsJcyBB/YEyeFPlyK3ljB b8whz6fXMfLNsutA7vNyHWzJibnMktghbefuaYbIN0/hRthFkNmjws5rRMXknflS Sa+Wd3jnBSa4pYvZUbKM08c9lg1+8Z7J87/IYqrtGlMeIVe8lyAjVj2JwgJggUlX LKf/2VfbqY/roWNQzyE1Rsqi7inUHUIPHAzQK+w5t6T5bzvL+qPGpes5P7fQWZJU RMduxRe9z8h34AS+VWKN3wE42iZl7sp4lyx9XpOAWnR44tVZlmI9+PCSOm7kdwQX Lva6AVtsUZbKLTtfI7GCh9otNCudDcTR0izeOFcpLV1T5RpsGGkwxM1thq5nWX0P IQWZEeCDIHnpB/hbZWJ2trUbr62BwGYWztwLElcxOYk3dAKia96HD6q+jDPFolb1 KygxhwINhpmkkdAG5cs2/eM2mBHQdG7WDdZQf+PwvNHShqY09JBNToCmG1wBm0rb jXRVaKtVuz+o42yTo8k9TuxcGNdTyKK5+qi21LpUVVaJ9upxGZw9NRsr3LsXsvSO rtJ4A2xt0GZS5+CP3Nll25C/CC6WALdVoYu5xJ/FoHBL/9btQvc= =//Pg -END PGP SIGNATURE End Message ---
Bug#986665: $HOME not writable when using schroot
Le 9/04/21 à 11:09, Simon McVittie a écrit :
On Fri, 09 Apr 2021 at 10:37:59 +0200, Laurent Bigonville wrote:
The dep8 specification says:
Tests can expect that the ``$HOME`` environment variable to be set
to a directory that exists and is writeable by the user running the test.
But when using schroot (not tried anythong else), $HOME is set to the
HOME of the user running the autopkgtest and does not exists in the
schroot. So either the spec is wrong or the implementation.
What schroot configuration are you using? Relevant information:
* your user's home directory
* the file in /etc/schroot/chroot.d defining the chroot you're using
* /etc/schroot/${profile}/fstab, where ${profile} is taken from the
chroot's configuration
If you are using profile=default (which is the default if left unspecified),
/etc/schroot/default/fstab usually bind-mounts the real /home.
If you are using profile=sbuild, /etc/schroot/sbuild/fstab usually does
not, making it unsuitable for autopkgtest-virt-schroot.
Using a chroot that contains a pre-created home directory for the user
running autopkgtest is also an option, but this is not currently something
that can be set up automatically.
I'm indeed using the "sbuild" profile, but I don't think that anybody
would want to have their real home bind mounted in the chroot and mixed
with the one from the tests
Shouldn't HOME be pointing a temporary directory like for AUTOPKGTEST_TMP ?
I would recommend using autopkgtest-virt-lxc or autopkgtest-virt-qemu:
those are considerably better-tested in practice than -schroot.
I should maybe look at that, but my schroot setup is usually enough for me
Bug#986427: marked as done (psgml: causes emacs-gtk to fail to upgrade from buster to bullseye)
Your message dated Fri, 09 Apr 2021 11:18:47 + with message-id and subject line Bug#986427: fixed in psgml 1.4.0-12 has caused the Debian Bug report #986427, regarding psgml: causes emacs-gtk to fail to upgrade from buster to bullseye to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 986427: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986427 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: psgml Version: 1.4.0-11 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'buster'. It installed fine in 'buster', then the upgrade to 'bullseye' fails. This problem was observed by first performing 'apt-get upgrade' (which upgrades psgml) followed by 'apt-get dist-upgrade' (which upgrades emacs-gtk). It does not happen if only 'apt-get dist-upgrade' is executed, i.e. both packages are upgraded in one run. --install-recommends was disabled during all these tests From the attached log (scroll to the bottom...): [... during apt-get upgrade ...] Preparing to unpack .../78-psgml_1.4.0-11_all.deb ... Remove psgml for emacs remove/psgml: Ignoring emacsen flavor emacs. Remove psgml for emacs remove/psgml: Ignoring emacsen flavor emacs. Unpacking psgml (1.4.0-11) over (1.4.0-7) ... [...] Setting up psgml (1.4.0-11) ... Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs Install psgml for emacs install/psgml: Byte-compiling for emacs...Loading /etc/emacs/site-start.d/00debian.el (source)... In toplevel form: psgml.el:719:26:Warning: (lambda (foo) ...) quoted with ' rather than with #' In sgml-mode: psgml.el:1225:52:Warning: assignment to free variable `which-func-format' In sgml-set-buffer-multibyte: psgml-parse.el:365:16:Warning: assignment to free variable `mc-flag' In sgml-set-active-dtd-indicator: psgml-parse.el:2898:47:Warning: assignment to free variable `which-func-mode' In sgml-kill-markup: psgml-edit.el:247:4:Warning: value returned from (/= 0 (skip-chars-forward " ")) is unused psgml-edit.el:247:4:Warning: value returned from (= 0 (skip-chars-forward " ")) is unused psgml-edit.el:247:4:Warning: value returned from (= (skip-chars-forward " ") 0) is unused In sgml-edit-external-entity: psgml-edit.el:1975:62:Warning: Use `with-current-buffer' rather than save-excursion+set-buffer psgml-edit.el:1977:24:Warning: `process-kill-without-query' is an obsolete function (as of 22.1); use `process-query-on-exit-flag' or `set-process-query-on-exit-flag'. In sgml-append-to-help-buffer: psgml-edit.el:2177:36:Warning: Use `with-current-buffer' rather than save-excursion+set-buffer In sgml-show-structure: psgml-edit.el:2412:6:Warning: Use `with-current-buffer' rather than save-excursion+set-buffer In end of data: psgml-edit.el:2475:1:Warning: the function `string-to-int' is not known to be defined. In sgml-parse-entity-type: psgml-dtd.el:646:8:Warning: value returned from (/= 0 (skip-chars-forward " ")) is unused psgml-dtd.el:646:8:Warning: value returned from (= 0 (skip-chars-forward " ")) is unused psgml-dtd.el:646:8:Warning: value returned from (= (skip-chars-forward " ") 0) is unused psgml-dtd.el:646:8:Warning: value returned from (= (skip-chars-forward " ") 0) is unused psgml-dtd.el:646:8:Warning: value returned from (= (skip-chars-forward " ") 0) is unused In sgml-write-dtd: psgml-dtd.el:1010:9:Warning: assignment to free variable `file-type' In end of data: psgml-dtd.el:1016:1:Warning: the function `string-to-int' is not known to be defined. Done compiling WARNING: tempfile is deprecated; consider using mktemp instead. Creating config file /etc/emacs/site-start.d/50psgml-init.el with new version done. [... during subsequent apt-get dist-upgrade ...] Preparing to unpack .../02-emacs-gtk_1%3a27.1+1-3_amd64.deb ... Remove psgml for emacs remove/psgml: Removing for emacs... done. Remove emacsen-common for emacs emacsen-common: Handling removal of emacsen flavor emacs Unpacking emacs-gtk (1:27.1+1-3) over (1:26.1+1-3.2+deb10u2) ... [...] Setting up emacs-gtk (1:27.1+1-3) ... Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs Install psgml for emacs install/psgml: Byte-compiling for emacs...cp: cannot stat 'Makefile-el': No such file or directory ERROR: install
Bug#986666: marked as done (greenbone-security-assistant trying to access the network during the build)
Your message dated Fri, 9 Apr 2021 11:21:42 +0200 with message-id and subject line Re: Bug#98: greenbone-security-assistant trying to access the network during the build has caused the Debian Bug report #98, regarding greenbone-security-assistant trying to access the network during the build to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 98: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:greenbone-security-assistant Version: 20.8.0-2 Severity: serious greenbone-security-assistant ftbfs, trying to access the network. even after adding node-babel-cli as a b-d: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/12280131/+listing-archive-extra The build succeeds in Debian, because the buildds have network access. --- End Message --- --- Begin Message --- Hi, On Fri, 09 Apr 2021, Matthias Klose wrote: > greenbone-security-assistant ftbfs, trying to access the network. The package was moved to contrib precisely because of this. It requires download of dependencies during the build. We had a discussion on debian-devel at that time: https://lists.debian.org/debian-devel/2020/12/threads.html#00215 (Feel free to exclude it from Ubuntu since this bug is a direct consequence of a failing build in Ubuntu.) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS--- End Message ---
Bug#986665: $HOME not writable when using schroot
On Fri, 09 Apr 2021 at 10:37:59 +0200, Laurent Bigonville wrote:
> The dep8 specification says:
>
> Tests can expect that the ``$HOME`` environment variable to be set
> to a directory that exists and is writeable by the user running the test.
>
> But when using schroot (not tried anythong else), $HOME is set to the
> HOME of the user running the autopkgtest and does not exists in the
> schroot. So either the spec is wrong or the implementation.
What schroot configuration are you using? Relevant information:
* your user's home directory
* the file in /etc/schroot/chroot.d defining the chroot you're using
* /etc/schroot/${profile}/fstab, where ${profile} is taken from the
chroot's configuration
If you are using profile=default (which is the default if left unspecified),
/etc/schroot/default/fstab usually bind-mounts the real /home.
If you are using profile=sbuild, /etc/schroot/sbuild/fstab usually does
not, making it unsuitable for autopkgtest-virt-schroot.
Using a chroot that contains a pre-created home directory for the user
running autopkgtest is also an option, but this is not currently something
that can be set up automatically.
I would recommend using autopkgtest-virt-lxc or autopkgtest-virt-qemu:
those are considerably better-tested in practice than -schroot.
smcv
Bug#985245: marked as done (src:ppmd: reintroduced with lower version number, different project?)
Your message dated Fri, 09 Apr 2021 09:00:12 + with message-id and subject line Bug#985245: fixed in python-ppmd 0.3.3-2 has caused the Debian Bug report #985245, regarding src:ppmd: reintroduced with lower version number, different project? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 985245: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985245 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: ppmd Version: 0.3.3-1 Severity: normal src:ppmd has been reintroduced with lower version number than before it was removed and as far as I can tell with a different upstream project. I expect this will confuse the BTS version tracking and seems like it violates some aspect of Debian or ftp-master policy, but I'm not sure. The consequences to user systems should be minimal since the two source packages produce different binary packages. Should the new source package be renamed to python-ppmd? Any further thoughts? https://tracker.debian.org/pkg/ppmd https://sources.debian.org/src/ppmd/ https://sources.debian.org/src/ppmd/0.3.3-1/ https://sources.debian.org/src/ppmd/0.3.3-1/debian/control https://sources.debian.org/src/ppmd/0.3.3-1/debian/watch https://sources.debian.org/src/ppmd/10.1-5/ https://sources.debian.org/src/ppmd/10.1-5/debian/control https://sources.debian.org/src/ppmd/10.1-5/debian/watch -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- Source: python-ppmd Source-Version: 0.3.3-2 Done: Sandro Tosi We believe that the bug you reported is fixed in the latest version of python-ppmd, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 985...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sandro Tosi (supplier of updated python-ppmd package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 15 Mar 2021 20:44:47 -0400 Source: python-ppmd Binary: python-ppmd-doc python3-ppmd python3-ppmd-dbgsym Architecture: source all amd64 Version: 0.3.3-2 Distribution: unstable Urgency: medium Maintainer: Sandro Tosi Changed-By: Sandro Tosi Description: python-ppmd-doc - documentation for the ppmd Python library python3-ppmd - PPMd compression/decompression library Closes: 985245 Changes: python-ppmd (0.3.3-2) unstable; urgency=medium . * Reintroduce it as python-ppmd, to avoid conflicts with an old pkg; Closes: #985245 Checksums-Sha1: 95ebca2ee7bda3891a35ec77377409941ffe8e1b 2112 python-ppmd_0.3.3-2.dsc 5c21a75a8d22339f14ec3855ca642a3e18a481ed 450356 python-ppmd_0.3.3.orig.tar.gz 4b1a995f6c74cc9af336de57f6f19ed5da68c8b9 2292 python-ppmd_0.3.3-2.debian.tar.xz f264275d17e006c48506d48a9297e26f2981579d 21820 python-ppmd-doc_0.3.3-2_all.deb 55df42a81540eb76cd7d24d43b729aeebe8a3db6 8937 python-ppmd_0.3.3-2_amd64.buildinfo ef1a36a0930a5500650a6be90e7234dabc4b7238 57416 python3-ppmd-dbgsym_0.3.3-2_amd64.deb bb2c5395048b53e6609552a9efd2b9e624d29da4 28484 python3-ppmd_0.3.3-2_amd64.deb Checksums-Sha256: a8c78b605a86c8b542f41082d949701f6ec6e5c2a2753b20437dab6290b8cb50 2112 python-ppmd_0.3.3-2.dsc 4c8826df6944100e5cb86ba776a97435d6f50e6f59b45f38c4362ec3d9ea5c98 450356 python-ppmd_0.3.3.orig.tar.gz ecdee22075326e7b855bebb1c156a52cd9d09aac92a5b805154b3416d29474ab 2292 python-ppmd_0.3.3-2.debian.tar.xz 0e1b23aafcb523f30b5129c27ebde7e254a4705ff5ec997d73d68466dadea0a0 21820 python-ppmd-doc_0.3.3-2_all.deb e4b47544fae4ca0f6f42b594229c859a4d69b1f525895734ecff38dad3adfc29 8937 python-ppmd_0.3.3-2_amd64.buildinfo 41977f12fca2ea1632d4f767125416a3c41c2663f3c32520b668d203fff20f1b 57416 python3-ppmd-dbgsym_0.3.3-2_amd64.deb 2886136efdac9ba27ca689769b245710d1c0e25728e0c1a69ffbdf45d7f1 28484 python3-ppmd_0.3.3-2_amd64.deb Files: 18e105d4e5c82d78bcaa4beb04b19b55 2112 python optional python-ppmd_0.3.3-2.dsc a8d0a0c6482b24e6e08015dfa69eb545 450356 python optional python-ppmd_0.3.3.orig.tar.gz 368a93c7562c067676796b2ae9e450bb 2292 python optional python-ppmd_0.3.3-2.debian.tar.xz e3e0880d7f7adea786ae2bcbff1d63f3 21820 doc optional python-ppmd-doc_0.3.3-2_all.deb
Bug#986666: greenbone-security-assistant trying to access the network during the build
Package: src:greenbone-security-assistant Version: 20.8.0-2 Severity: serious greenbone-security-assistant ftbfs, trying to access the network. even after adding node-babel-cli as a b-d: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/12280131/+listing-archive-extra The build succeeds in Debian, because the buildds have network access.
Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x
Control: tags -1 + fixed-upstream Fixed in Matrix upstream svn rev 3376 [1]. [1] https://r-forge.r-project.org/scm/viewvc.php?view=rev=matrix=3376
Processed: Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x
Processing control commands: > tags -1 + fixed-upstream Bug #980809 [src:rmatrix] rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x Added tag(s) fixed-upstream. -- 980809: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980809 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures
Processing control commands:
> reopen -1
Bug #985401 {Done: Guillem Jover } [dpkg] dpkg: libreoffice
buster->bullseye upgrade failures
Bug reopened
Ignoring request to alter fixed versions of bug #985401 to the same values
previously set
--
985401: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985401
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures
Control: reopen -1 On 08/04/2021 19.22, Guillem Jover wrote: Otherwise, I don't see a bug in dpkg for this here. And I'd be inclined to close this. I've managed to solve most of the upgrade paths by propagating some Conflicts from libreoffice-common to libreoffice-core, s.t. the packages get removed right away and are not deconfigured first (which causes the Conflicts encountered later to be ignored). What I see left for dpkg is the missing verboseness when it is actually removing the conflicting package: Preparing to unpack .../0-ure_7.0.4-4~deb11anbe2_amd64.deb ... Unpacking ure (1:7.0.4-4~deb11anbe2) over (6.1.5-3+deb10u7) ... Preparing to unpack .../1-libreoffice-style-colibre_7.0.4-4~deb11anbe2_all.deb ... Unpacking libreoffice-style-colibre (1:7.0.4-4~deb11anbe2) over (1:6.1.5-3+deb10u7) ... dpkg: considering removing libreoffice-draw in favour of libreoffice-core ... dpkg: yes, will remove libreoffice-draw in favour of libreoffice-core Preparing to unpack .../2-libreoffice-core_7.0.4-4~deb11anbe2_amd64.deb ... Unpacking libreoffice-core (1:7.0.4-4~deb11anbe2) over (1:6.1.5-3+deb10u7) ... Preparing to unpack .../3-libreoffice-common_7.0.4-4~deb11anbe2_all.deb ... Unpacking libreoffice-common (1:7.0.4-4~deb11anbe2) over (1:6.1.5-3+deb10u7) ... Selecting previously unselected package libreoffice-draw. Preparing to unpack .../4-libreoffice-draw_7.0.4-4~deb11anbe2_amd64.deb ... Unpacking libreoffice-draw (1:7.0.4-4~deb11anbe2) ... which makes it hard to understand the last failing case: Removing libreoffice-style-tango (1:6.1.5-3+deb10u7) ... dpkg: considering removing libreoffice-core in favour of libreoffice-common ... dpkg: yes, will remove libreoffice-core in favour of libreoffice-common dpkg: considering removing libreoffice-draw in favour of libreoffice-common ... dpkg: yes, will remove libreoffice-draw in favour of libreoffice-common dpkg: considering removing libreoffice-impress in favour of libreoffice-common ... dpkg: yes, will remove libreoffice-impress in favour of libreoffice-common (Reading database ... Preparing to unpack .../0-libreoffice-common_7.0.4-4~deb11anbe2_all.deb ... De-configuring libreoffice-draw (1:6.1.5-3+deb10u7), to allow removal of libreoffice-core (1:6.1.5-3+deb10u7) ... De-configuring libreoffice-impress (1:6.1.5-3+deb10u7), to allow removal of libreoffice-core (1:6.1.5-3+deb10u7) ... dpkg-maintscript-helper: error: file '/usr/lib/libreoffice/share/registry/ogltrans.xcd' not owned by package 'libreoffice-common:all' dpkg-maintscript-helper: error: file '/usr/lib/libreoffice/share/registry/impress.xcd' not owned by package 'libreoffice-common:all' dpkg-maintscript-helper: error: file '/usr/lib/libreoffice/share/registry/graphicfilter.xcd' not owned by package 'libreoffice-common:all' dpkg-maintscript-helper: error: file '/usr/lib/libreoffice/share/registry/draw.xcd' not owned by package 'libreoffice-common:all' dpkg-maintscript-helper: error: directory '/usr/lib/libreoffice/share/registry' contains files not owned by package libreoffice-common:all, cannot switch to symlink dpkg: error processing archive /tmp/apt-dpkg-install-1xO0pR/0-libreoffice-common_7.0.4-4~deb11anbe2_all.deb (--unpack): new libreoffice-common package pre-installation script subprocess returned error exit status 1 rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or directory rmdir: failed to remove '/var/lib/libreoffice': No such file or directory Selecting previously unselected package libreoffice-draw. dpkg: considering deconfiguration of libreoffice-common, which would be broken by installation of libreoffice-draw ... dpkg: yes, will deconfigure libreoffice-common (broken by libreoffice-draw) dpkg: considering deconfiguration of libreoffice-core, which would be broken by installation of libreoffice-draw ... dpkg: yes, will deconfigure libreoffice-core (broken by libreoffice-draw) Preparing to unpack .../1-libreoffice-draw_7.0.4-4~deb11anbe2_amd64.deb ... De-configuring libreoffice-core (1:6.1.5-3+deb10u7) ... De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ... Unpacking libreoffice-draw (1:7.0.4-4~deb11anbe2) over (1:6.1.5-3+deb10u7) ... Replacing files in old package libreoffice-core (1:6.1.5-3+deb10u7) ... Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ... Selecting previously unselected package libreoffice-core. Preparing to unpack .../2-libreoffice-core_7.0.4-4~deb11anbe2_amd64.deb ... Unpacking libreoffice-core (1:7.0.4-4~deb11anbe2) ... Selecting previously unselected package libreoffice-impress. Preparing to unpack .../3-libreoffice-impress_7.0.4-4~deb11anbe2_amd64.deb ... Unpacking libreoffice-impress (1:7.0.4-4~deb11anbe2) ... Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ... Why is dpkg going to deconfigure some packages that it has scheduled for removal? Reordering the removals
Bug#986665: $HOME not writable when using schroot
Package: autopkgtest Version: 5.16 Severity: serious Hello, The dep8 specification says: Tests can expect that the ``$HOME`` environment variable to be set to a directory that exists and is writeable by the user running the test. But when using schroot (not tried anythong else), $HOME is set to the HOME of the user running the autopkgtest and does not exists in the schroot. So either the spec is wrong or the implementation. Kind regards, Laurent Bigonville -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages autopkgtest depends on: ii apt-utils 2.2.2 ii libdpkg-perl1.20.7.1 ii procps 2:3.3.17-5 ii python3 3.9.2-3 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: pn lxc pn lxd ii ovmf 2020.11-4 pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:5.2+dfsg-9 ii schroot 1.6.10-12 pn vmdb2 -- no debconf information
Processed: found 986637 in 2.0.2-1+deb10u1
Processing commands for cont...@bugs.debian.org: > # version in buster is also affected > found 986637 2.0.2-1+deb10u1 Bug #986637 [speedtest-cli] speedtest-cli: ValueError: invalid literal for int() with base 10 Marked as found in versions speedtest-cli/2.0.2-1+deb10u1. > thanks Stopping processing here. Please contact me if you need assistance. -- 986637: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986637 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986655: marked as done (Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable)
Your message dated Fri, 9 Apr 2021 10:22:40 +0200 with message-id and subject line Re: Bug#986655: Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable has caused the Debian Bug report #986655, regarding Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 986655: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986655 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lighttpd Version: 1.4.57-1 Severity: grave Justification: non serious data loss whe made force reload the log fiel are not more used.. this again happens only with the shitstemd case, cos sysvinit script are in the fly converted to, so the it display a "Warining" about log output is incomplete.. in some cases causes spurious socket break serveruno:/etc/lighttpd/conf-available# service lighttpd status ● lighttpd.service - Lighttpd Daemon Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2021-04-08 09:00:10 -04; 8h ago Process: 3997 ExecReload=/bin/kill -USR1 $MAINPID (code=exited, status=0/SUCCESS) Main PID: 8936 (lighttpd) Tasks: 1 (limit: 4915) CGroup: /system.slice/lighttpd.service └─8936 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf abr 08 17:24:22 serveruno systemd[1]: Reloading Lighttpd Daemon. abr 08 17:24:22 serveruno systemd[1]: Reloaded Lighttpd Daemon. abr 08 17:25:24 serveruno systemd[1]: Reloading Lighttpd Daemon. abr 08 17:25:24 serveruno systemd[1]: Reloaded Lighttpd Daemon. *Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable*. serveruno:/etc/lighttpd/conf-available# service lighttpd restart Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com --- End Message --- --- Begin Message --- On Thu, Apr 08, 2021 at 05:34:02PM -0400, PICCORO McKAY Lenz wrote: > whe made force reload the log fiel are not more used.. this again happens > only with the shitstemd case, cos sysvinit script are in the fly converted > to, so the it display a "Warining" about log output is incomplete.. in some > cases causes spurious socket break Your way of presenting the issue is not constructive and uses insults. Regardless of the technical matter, such contribution is not welcome in Debian. Please take your rants elsewhere. On a technical level, I see little to do here. Your log got rotated. That's to be expected. systemd is just telling you that it happened since starting lighttpd. I don't understand what "spurious socket break" is supposed to mean. If that is a real issue, please file a separate bug without violating our code of conduct. Helmut--- End Message ---
Bug#986268: marked as done (Should be in non-free, not main; no source code)
Your message dated Fri, 09 Apr 2021 08:10:08 + with message-id and subject line Bug#986268: fixed in firmware-ast 20140808-2 has caused the Debian Bug report #986268, regarding Should be in non-free, not main; no source code to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 986268: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986268 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: firmware-ast Version: 20140808-1 Severity: serious X-Debbugs-Cc: j...@joshtriplett.org firmware-ast is binary-only firmware. The "source code" appears to consist of a C header file containing a hex dump of a binary, and a makefile transforming the hex dump into binary. The previous package, xserver-xorg-video-ast, had a similar bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941077 . --- End Message --- --- Begin Message --- Source: firmware-ast Source-Version: 20140808-2 Done: Daniel Baumann We believe that the bug you reported is fixed in the latest version of firmware-ast, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 986...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Daniel Baumann (supplier of updated firmware-ast package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 06 Apr 2021 12:56:55 +0200 Source: firmware-ast Binary: firmware-ast Architecture: source all Version: 20140808-2 Distribution: sid Urgency: medium Maintainer: Daniel Baumann Changed-By: Daniel Baumann Description: firmware-ast - Binary firmware for ASpeed Technologies graphics chips Closes: 986268 Changes: firmware-ast (20140808-2) sid; urgency=medium . * Uploading to sid. * Moving package to non-free, the binary-blob has a free license but no source in the sense of 'prefered-form-of-modification', thanks Josh Triplett (Closes: #986268). Checksums-Sha1: 1102cd73e3140d624e93f9d72bed15612fa9215b 2014 firmware-ast_20140808-2.dsc f5ff470009181d5a058c7bab80f00edcc08d756d 11204 firmware-ast_20140808.orig.tar.xz 50ba18c07e05130a3f197a94fa7f35eec3d2cb5e 2180 firmware-ast_20140808-2.debian.tar.xz 38004a93cf4400bfb72999bbedbdcc6b583b23dd 8560 firmware-ast_20140808-2_all.deb 6b9ddf869455eb077c12cf7c47b32cc215ab9ef8 5788 firmware-ast_20140808-2_amd64.buildinfo Checksums-Sha256: b558a1bf83421964cb21ea5ebd24ce425bfce18fbd4b485fa84ec6a10dfd9377 2014 firmware-ast_20140808-2.dsc c9818a25becbf078fc9eb2c2205b25cddd65c4d200de8a61e731f7a3b193c967 11204 firmware-ast_20140808.orig.tar.xz 7f4a71a585c2f59f0db0712ecd3005592758459ed5eafeb4b0d9f6fa4317 2180 firmware-ast_20140808-2.debian.tar.xz 9012cdde457f73616b1af8d184e25f1cec9f26778b2622561be389355fc3b60b 8560 firmware-ast_20140808-2_all.deb c48cbcbb5ff1df650a26cda9624f430a3a1af795920af4ea9b5f709d86b33a7e 5788 firmware-ast_20140808-2_amd64.buildinfo Files: 59eaea8a9085d71e5568ce1def5a481e 2014 non-free/kernel optional firmware-ast_20140808-2.dsc 8237f677d34ebfd40bae5f621baeadc6 11204 non-free/kernel optional firmware-ast_20140808.orig.tar.xz 16c613fcc530121e73c396cdbe0544e2 2180 non-free/kernel optional firmware-ast_20140808-2.debian.tar.xz ec8018131e99c61282c8ba635071e2e7 8560 non-free/kernel optional firmware-ast_20140808-2_all.deb 12584dd3fe65fe680d433285e76ef098 5788 non-free/kernel optional firmware-ast_20140808-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmBsPq4ACgkQVc8b+Yar ucdwgxAAvjqJcoMNf2OVUymFpSndermgo7ozI5Ek0dBCdaDwJYwsTyoF+G0IcEpt dUET+RVOCu9yTs/hYMnZREvXRwoanzi4NWagOhc5eH9M1Y34D16fUHTrBE9UVaVQ KVaN/0w1HoH4rAcSnCV/JdeArUaRoSEAHN+vLfZYoPnQQqtSm/ZwX42KK53x4lpB JjshKRBLcwEHwvggPbPZ0ToYTBWHxZDeNhnwTjrCGG6/oSJ+bq0AVvyZWJ5WqmyV 5KnHnqlbnaAVbQKF6rIi995FFJBXpRQO4A9nI0+zV/EQBxtzSAaDNmy1yZcpEKk2 +/4Okrc3kdC/cBEZPN+tq6j5qfJEzi3p7s2vcjjyANCsFseSpcGE48lwA3fgqlMv nnCF5a2o4ZITnSmGDJ6lQIZIeknYZX44wE8XZ+sC5QVGKt9IHEpO8pzEwVVG3U0m lHlJETVEbvHYzWckoLrdLe8gWvalWCwK6IlHKJ+akbOay2saj77SiOy6BmTx0rMU PIyC4P3YyRYhM88q6RMhX1YMjeOaN4/WzvslfQO0xJIEWBLVq7WA2kslplK6Jens c9/zZwXMLew0AH6MeKiw2TNjnUJ2qsoaUOL03V/ETxUnDGXh64yUJRhHbtBwLnEW zYwWGtKvi2COcAAffSF+YZDQnh+LElLNg17Mb3MsR/wlYCPNtKY= =FUQ2 -END
Bug#986592: [Help] Re: Bug#986592: kleborate: flaky arm64 autopkgtest: Mutex is not owned by current thread
Hi Aaron, On Fri, Apr 09, 2021 at 12:01:21AM -0400, Aaron M. Ucko wrote: > Never mind, this appears to be a different issue, per a backtrace > obtained with EXCEPTION_STACK_TRACE_LEVEL=Error and a great deal of > patience: > > Error: tblastn encountered an error: > terminate called after throwing an instance of 'ncbi::CMutexException' > what(): NCBI C++ Exception: > T29 "c++/include/corelib/ncbidiag.hpp", line 417: Error: > (CMutexException::eOwner) > ncbi::ncbi_namespace_mutex_mt::SSystemMutex::ThrowNotOwned() - Mutex is not > owned by current thread > Stack trace: > /usr/lib/ncbi-blast+/libxncbi.so ???:0 > ncbi::CMutexException::CMutexException(ncbi::CDiagCompileInfo const&, > ncbi::CException const*, ncbi::CMutexException::EErrCode, > std::__cxx11::basic_string, std::allocator > > const&, ncbi::EDiagSev) offset=0x3C addr=0x83061d9c > /usr/lib/ncbi-blast+/libxncbi.so ???:0 > ncbi::ncbi_namespace_mutex_mt::SSystemMutex::ThrowNotOwned() offset=0x88 > addr=0x82f76534 > /usr/lib/ncbi-blast+/libxncbi.so ???:0 > ncbi::ncbi_namespace_mutex_mt::SSystemMutex::Unlock(ncbi::ncbi_namespace_mutex_mt::SSystemFastMutex::ELockSemantics) > offset=0x78 addr=0x83057938 > /usr/lib/ncbi-blast+/libseqdb.so ???:0 > ncbi::CSeqDBLockHold::~CSeqDBLockHold() offset=0x30 addr=0x84305fa0 > /usr/lib/ncbi-blast+/libseqdb.so ???:0 > ncbi::CSeqDBImpl::GetSeqLength(int) const offset=0x48 addr=0x8432ca1c > /usr/lib/ncbi-blast+/libblast.so ???:0 BLAST_SetupPartialFetching > offset=0x134 addr=0x84442904 > /usr/lib/ncbi-blast+/libblast.so ???:0 offset=0x27938 > addr=0x8441f938 > /usr/lib/aarch64-linux-gnu/libgomp.so.1 ???:0 offset=0x18CB0 > addr=0x81f19cb0 > /lib/aarch64-linux-gnu/libpthread.so.0 ???:0 offset=0x8628 > addr=0x82027628 > /lib/aarch64-linux-gnu/libc.so.6 ???:0 offset=0xD601C > addr=0x82c2001c Thanks a lot for your investigation. Unfortunately I have no idea how to proceed from here. Does anybody have an idea? I mean a better idea than just stating this package does not work on arm64 which would probably some last resort. Kind regards Andreas. -- http://fam-tille.de
