Bug#990627: python3-torchaudio: torchaudio import aborts
Package: python3-torchaudio Version: 0.7.2-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: johnmoha...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** The line "import torchaudio" at the python interactive shell or in a python script or imported file results in the progra aborting with the following output: -- terminate called after throwing an instance of 'c10::Error' what(): Type c10::intrusive_ptr, c10::detail::intrusive_target_default_null_type > > could not be converted to any of the known types. Exception raised from call at ../aten/src/ATen/core/jit_type.h:1698 (most recent call first): frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string, std::allocator >) + 0x5c (0x7fb37a0b925c in /usr/lib/x86_64-linux-gnu/libc10.so.1.7) frame #1: + 0x11d0ac2 (0x7fb376ddfac2 in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #2: + 0xe7d991 (0x7fb376a8c991 in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #3: c10::detail::infer_schema::make_function_schema(std::__cxx11::basic_string, std::allocator >&&, std::__cxx11::basic_string, std::allocator >&&, c10::ArrayRef, c10::ArrayRef) + 0x6a (0x7fb376a8d70a in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #4: + 0x120457f (0x7fb376e1357f in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #5: + 0x11fe28f (0x7fb376e0d28f in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #6: + 0x11fe404 (0x7fb376e0d404 in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #7: + 0xdb5480 (0x7fb3769c4480 in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #8: + 0xcdd79c (0x7fb3768ec79c in /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.7) frame #9: + 0xffe2 (0x7fb3d5ec1fe2 in /lib64/ld- linux-x86-64.so.2) frame #10: + 0x100e9 (0x7fb3d5ec20e9 in /lib64/ld- linux-x86-64.so.2) frame #11: _dl_catch_exception + 0xdd (0x7fb3d5c302bd in /lib/x86_64-linux- gnu/libc.so.6) frame #12: + 0x14058 (0x7fb3d5ec6058 in /lib64/ld- linux-x86-64.so.2) frame #13: _dl_catch_exception + 0x80 (0x7fb3d5c30260 in /lib/x86_64-linux- gnu/libc.so.6) frame #14: + 0x138fa (0x7fb3d5ec58fa in /lib64/ld- linux-x86-64.so.2) frame #15: + 0x1258 (0x7fb3d5e55258 in /lib/x86_64-linux- gnu/libdl.so.2) frame #16: _dl_catch_exception + 0x80 (0x7fb3d5c30260 in /lib/x86_64-linux- gnu/libc.so.6) frame #17: _dl_catch_error + 0x2f (0x7fb3d5c3031f in /lib/x86_64-linux- gnu/libc.so.6) frame #18: + 0x1a65 (0x7fb3d5e55a65 in /lib/x86_64-linux- gnu/libdl.so.2) frame #19: dlopen + 0x44 (0x7fb3d5e552e4 in /lib/x86_64-linux-gnu/libdl.so.2) frame #20: + 0x14e8d (0x7fb3d5e9ce8d in /usr/lib/python3.9/lib-dynload/_ctypes.cpython-39-x86_64-linux-gnu.so) frame #21: /usr/bin/python3() [0x53f38a] frame #22: _PyObject_MakeTpCall + 0x39b (0x51d89b in /usr/bin/python3) frame #23: _PyEval_EvalFrameDefault + 0x5654 (0x5170e4 in /usr/bin/python3) frame #24: /usr/bin/python3() [0x510fe7] frame #25: _PyFunction_Vectorcall + 0x361 (0x528d21 in /usr/bin/python3) frame #26: /usr/bin/python3() [0x537b80] frame #27: _PyObject_MakeTpCall + 0x1f5 (0x51d6f5 in /usr/bin/python3) frame #28: _PyEval_EvalFrameDefault + 0x5b2a (0x5175ba in /usr/bin/python3) frame #29: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #30: /usr/bin/python3() [0x53bcfb] frame #31: _PyEval_EvalFrameDefault + 0x53e6 (0x516e76 in /usr/bin/python3) frame #32: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #33: /usr/bin/python3() [0x53bcfb] frame #34: _PyEval_EvalFrameDefault + 0x53e6 (0x516e76 in /usr/bin/python3) frame #35: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #36: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3) frame #37: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #38: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3) frame #39: /usr/bin/python3() [0x5106ed] frame #40: _PyEval_EvalCodeWithName + 0x47 (0x510497 in /usr/bin/python3) frame #41: PyEval_EvalCode + 0x23 (0x5f5be3 in /usr/bin/python3) frame #42: /usr/bin/python3() [0x5fa670] frame #43: /usr/bin/python3() [0x5298c4] frame #44: _PyEval_EvalFrameDefault + 0x610b (0x517b9b in /usr/bin/python3) frame #45: /usr/bin/python3() [0x5106ed] frame #46: _PyFunction_Vectorcall + 0x361 (0x528d21 in /usr/bin/python3) frame #47: _PyEval_EvalFrameDefault + 0x53e6 (0x516e76 in /usr/bin/python3) frame #48: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #49: _PyEval_EvalFrameDefault + 0x702 (0x512192 in /usr/bin/python3) frame #50: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #51: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3) frame #52: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #53: _PyEval_EvalFrameDefault + 0x525 (0x511fb5 in /usr/bin/python3) frame #54: _PyFunction_Vectorcall + 0x1a3 (0x528b63 in /usr/bin/python3) frame #55: /usr/bin/python3() [0x52842e] frame #56:
Processed: tagging 883194
Processing commands for cont...@bugs.debian.org:
> tags 883194 + bullseye sid
Bug #883194 {Done: Salvatore Bonaccorso } [nfs-utils] please
convert mountstats and nfsiostat scripts to Python3
Added tag(s) sid and bullseye.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
883194: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883194
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: found 990419 in 6.2.0-3
Processing commands for cont...@bugs.debian.org: > found 990419 6.2.0-3 Bug #990419 [puppetdb] CVE-2021-27021 Marked as found in versions puppetdb/6.2.0-3. > thanks Stopping processing here. Please contact me if you need assistance. -- 990419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990419 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed 990123 in 2.5.1-1
Processing commands for cont...@bugs.debian.org: > fixed 990123 2.5.1-1 Bug #990123 [iptables-netflow-dkms] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Marked as fixed in versions iptables-netflow/2.5.1-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 990123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990123 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990620: marked as done (python-duckpy: python-ducky -- Mising Depends on python3-h2 -- renders package unusable)
Your message dated Fri, 02 Jul 2021 20:18:26 + with message-id and subject line Bug#990620: fixed in python-duckpy 3.1.0-2 has caused the Debian Bug report #990620, regarding python-duckpy: python-ducky -- Mising Depends on python3-h2 -- renders package unusable 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.) -- 990620: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990620 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: python-duckpy Version: 3.1.0-1 Severity: serious X-Debbugs-Cc: nil...@debian.org Dear Maintainer, python-duckpy has a missing dependency on python3-h2 which is uncovered by a non-superficial autopkgtest committed to salsa[1] As can be seen in the corresponding pipeline, it fails with dependency error[2] "Using http2=True, but the 'h2' package is not installed" [1]: https://salsa.debian.org/med-team/python-duckpy/-/commit/687a66a3be451d5f3458caa956927af7bd9880c5 [2]: https://salsa.debian.org/med-team/python-duckpy/-/jobs/1736252 Nilesh -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- Source: python-duckpy Source-Version: 3.1.0-2 Done: Nilesh Patra We believe that the bug you reported is fixed in the latest version of python-duckpy, 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 990...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Nilesh Patra (supplier of updated python-duckpy 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: Sat, 03 Jul 2021 01:37:34 +0530 Source: python-duckpy Architecture: source Version: 3.1.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Nilesh Patra Closes: 990620 Changes: python-duckpy (3.1.0-2) unstable; urgency=medium . * Team Upload. * Add autopkgtests * d/examples: Add d/tests/test_duckpy_basic.py as example * d/control: Add Depends on python3-h2 (Closes: #990620) Checksums-Sha1: c8720c2530c5030e97463a570ca2de35674da44e 2195 python-duckpy_3.1.0-2.dsc 25a1e56597a6d43fc662e014575231239540c15d 2960 python-duckpy_3.1.0-2.debian.tar.xz 12cae2833a65b928c2e66b024fa34ce34770bba9 6687 python-duckpy_3.1.0-2_amd64.buildinfo Checksums-Sha256: c18951fb6c2bd1786173d2074f3eba4706c596bbd83ebf27ffc1e6f2088ce6c9 2195 python-duckpy_3.1.0-2.dsc c5b3e8b27d806cf86b092a4bc8d88a0bc36d1256f41d91c5a5fb6b702fdf4e9e 2960 python-duckpy_3.1.0-2.debian.tar.xz 82ce2b232f45a091b40271aaa3966e21e1fa1980747c54b8b5cef439601c271d 6687 python-duckpy_3.1.0-2_amd64.buildinfo Files: ee92b0ad7e3510544247bbd00a4635bb 2195 science optional python-duckpy_3.1.0-2.dsc 2c80860bfd9ec57f0c2f50911af38caf 2960 science optional python-duckpy_3.1.0-2.debian.tar.xz c50be25e1249962cdabfcda1bef205ad 6687 science optional python-duckpy_3.1.0-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCgAyFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmDfcoIUHG5wYXRyYTk3 NEBnbWFpbC5jb20ACgkQALrnSzQzafGRcRAAujpQeU26d2z3uIQX9c0tiMQPJM4M zu2yCVl7GGZJMrA6rHE3bob0kU4RGrs9X6Sx4dR9hYTKT5Dpl0m3gqffvn6RGNeb /HIhDQ1pMNsdRP1A6Zl3vkbvUBs8i1FWvo7eftqjFEqG4NonICZQJWWywcJdjnFf 7b2NGv7VtSy12sv1+I4aaO37ZJ7RDGguMNsCXXzjQ2hKJ9mi0YcLPpbAtNaBVgBJ A7nwgFoJ6hm85cSJFm1yKflqg+8fAG56knOT5rxE++wJbhBd02stykfV2PNsb15C 1Iq09/vjAr7nWdxHE+ihpIjGbBfepOdThnFrED1qOqtmESX+wcB93Fz1lzswtOcE o5jr6d9MiO7uyAziacaJDNZKvNl8JmnI8/lD3UrgLWfyuHGTNlb1qyzWN3gsCll+ HxySGFdZub1KPpJeNg9pc3RReQJfmp52Z8x51LC74ic212KHj2B45Izrh8CdpVlW ADGWTRaS7Jlwilcd0ytbOF67lWThja36Xf4sfCgEaF8IbTbJLEV/S7OaTxpxEiJs jMbBuHEt19QFDyLiy1wJwyabY8G2uBgU3qui92o3oC9OkUJrTuVs1I2/QIvqsudO Z9vu73Otk0ht4tkgX7LJItTY3V8iGwgMPY6KdI1Y0Mp24Oq36gP905fHlDpKSrVt wcFAl70OsdaHY9M= =I5tY -END PGP SIGNATURE End Message ---
Bug#990620: python-duckpy: python-ducky -- Mising Depends on python3-h2 -- renders package unusable
Source: python-duckpy Version: 3.1.0-1 Severity: serious X-Debbugs-Cc: nil...@debian.org Dear Maintainer, python-duckpy has a missing dependency on python3-h2 which is uncovered by a non-superficial autopkgtest committed to salsa[1] As can be seen in the corresponding pipeline, it fails with dependency error[2] "Using http2=True, but the 'h2' package is not installed" [1]: https://salsa.debian.org/med-team/python-duckpy/-/commit/687a66a3be451d5f3458caa956927af7bd9880c5 [2]: https://salsa.debian.org/med-team/python-duckpy/-/jobs/1736252 Nilesh -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#981928: (no subject)
Ubuntu builds are now hitting this same issue. The corresponding bug on launchpad: https://bugs.launchpad.net/debian/+source/gauche-gtk/+bug/1934534
Processed: Re: mark affected packages
Processing commands for cont...@bugs.debian.org:
> affects 990493 node-colormin node-css-loader
Bug #990493 {Done: Pirate Praveen }
[node-babel-plugin-add-module-exports] node-babel-plugin-add-module-exports
broken with babel-preset-env 7
Added indication that 990493 affects node-colormin and node-css-loader
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
990493: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990493
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#990573: marked as done (libpmem1: insufficient flushing on ARMv8.2+)
Your message dated Fri, 02 Jul 2021 16:03:32 +
with message-id
and subject line Bug#990573: fixed in pmdk 1.10-2
has caused the Debian Bug report #990573,
regarding libpmem1: insufficient flushing on ARMv8.2+
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.)
--
990573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libpmem1
Version: 1.10-1
Severity: grave
Justification: causes data loss
[a fix is coming, filing this bug so the Release Team knows why]
Hi!
Support for arm64 in PMDK is deeply experimental. As far as I know, it has
never been tested on real hardware nor had been reviewed by someone with
adequate knowledge about ARM. Yet, enabling arm64 in our packages has been
requested multiple times, and bullseye / buster-backports do include arm64
builds. This was done with porting in mind, yet it looks like pmem-capable
ARM hardware is coming soon, and will be used in production not long after.
This makes inadequate support for new ARM chips unfortunate to say the least.
In ARMv8.0 and ARMv8.1, the only flushes available were CVAI (to make icache
= dcache, irrelevant for pmem), and CVAC ("flush to coherency"). The latter
was the deepest flush available, and implementors simply had no other option
than to have this instruction request the memory controller to send its data
to actual memory chips.
This changed in ARMv8.2, where a new instruction CVAP ("flush to
persistency") has been added, and CVAC was defined to require coherency only
between "agents" (such as CPU cores, GPU, etc) but not memory.
Yet PMDK knew only about CVAC -- despite asking around, no one of us could
get hold of an ARMv8.2 machine to implement detection/etc. Such support is
obviously not a priority for Intel nor IBM.
Only recently, I managed to get access to such a box, and implemented
flushes via CVAP. Without them, an unexpected power loss may result in
recent writes being lost. This is even worse than with disks -- a typical
filesystem will flush every 5 seconds or so, while there's no time-based
mechanism to flush CPU caches. If a machine finished its task and became
quiescent, it's possible the kernel and daemons won't actively touch more
than 16-64MB of L3 cache for hours or days.
The new flushes have been merged upstream in 1.11, I'm about to cherry-pick
to 1.10 for Bullseye.
Meow!
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.13.0-00032-g2fc675a48a0e (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libpmem1 depends on:
ii libc6 2.31-12
ii libdaxctl1 71.1-1
ii libndctl6 71.1-1
libpmem1 recommends no packages.
libpmem1 suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: pmdk
Source-Version: 1.10-2
Done: Adam Borowski
We believe that the bug you reported is fixed in the latest version of
pmdk, 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 990...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Adam Borowski (supplier of updated pmdk 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, 02 Jul 2021 17:02:37 +0200
Source: pmdk
Architecture: source
Version: 1.10-2
Distribution: unstable
Urgency: high
Maintainer: Adam Borowski
Changed-By: Adam Borowski
Closes: 990573
Changes:
pmdk (1.10-2) unstable; urgency=high
.
* Fix insufficient flushing on ARMv8.2+ (closes: #990573).
Checksums-Sha1:
51b90651718942bb92cb7f7fd662851974428b7e 3841 pmdk_1.10-2.dsc
a9bfccf9711ee65bdfd6bfc871b28f851a2df6f4 17316 pmdk_1.10-2.debian.tar.xz
dbd0bec530bb1904adc7b7e7cd30c4a552d94abb 6741 pmdk_1.10-2_source.buildinfo
Checksums-Sha256:
ec245dad59c5b89993c8e6725fde9bd81e88f97f43632fb7afe048b69a1cc31f 3841
pmdk_1.10-2.dsc
Bug#989799: psmisc: Undeclared file conflict with manpages-de
Hello Hideki, On Fri, Jul 02, 2021 at 10:29:53AM +0900, Hideki Yamane wrote: > On Thu, 1 Jul 2021 21:07:03 +0200 > Helge Kreutzmann wrote: > > It now has. So this bug is closed, if users upgrade to the latestes > > backport version. > > Hmm, however, this bug is not closed automatically. Weird. > > https://tracker.debian.org/news/1243791/accepted-manpages-l10n-4100-1bpo101-source-into-buster-backports-backports-policy-buster-backports/ This is normal, somehow Closes in backported packages don't work. I asked this earlier and was told otherwiese, but it still applies. > We can close it via mail, but should investigate its reason, IMO. I already did that, however, I can do it again, if necessary. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#990573: marked as done (libpmem1: insufficient flushing on ARMv8.2+)
Your message dated Fri, 02 Jul 2021 14:49:51 +
with message-id
and subject line Bug#990573: fixed in pmdk 1.11.0-1
has caused the Debian Bug report #990573,
regarding libpmem1: insufficient flushing on ARMv8.2+
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.)
--
990573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990573
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libpmem1
Version: 1.10-1
Severity: grave
Justification: causes data loss
[a fix is coming, filing this bug so the Release Team knows why]
Hi!
Support for arm64 in PMDK is deeply experimental. As far as I know, it has
never been tested on real hardware nor had been reviewed by someone with
adequate knowledge about ARM. Yet, enabling arm64 in our packages has been
requested multiple times, and bullseye / buster-backports do include arm64
builds. This was done with porting in mind, yet it looks like pmem-capable
ARM hardware is coming soon, and will be used in production not long after.
This makes inadequate support for new ARM chips unfortunate to say the least.
In ARMv8.0 and ARMv8.1, the only flushes available were CVAI (to make icache
= dcache, irrelevant for pmem), and CVAC ("flush to coherency"). The latter
was the deepest flush available, and implementors simply had no other option
than to have this instruction request the memory controller to send its data
to actual memory chips.
This changed in ARMv8.2, where a new instruction CVAP ("flush to
persistency") has been added, and CVAC was defined to require coherency only
between "agents" (such as CPU cores, GPU, etc) but not memory.
Yet PMDK knew only about CVAC -- despite asking around, no one of us could
get hold of an ARMv8.2 machine to implement detection/etc. Such support is
obviously not a priority for Intel nor IBM.
Only recently, I managed to get access to such a box, and implemented
flushes via CVAP. Without them, an unexpected power loss may result in
recent writes being lost. This is even worse than with disks -- a typical
filesystem will flush every 5 seconds or so, while there's no time-based
mechanism to flush CPU caches. If a machine finished its task and became
quiescent, it's possible the kernel and daemons won't actively touch more
than 16-64MB of L3 cache for hours or days.
The new flushes have been merged upstream in 1.11, I'm about to cherry-pick
to 1.10 for Bullseye.
Meow!
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.13.0-00032-g2fc675a48a0e (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libpmem1 depends on:
ii libc6 2.31-12
ii libdaxctl1 71.1-1
ii libndctl6 71.1-1
libpmem1 recommends no packages.
libpmem1 suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: pmdk
Source-Version: 1.11.0-1
Done: Adam Borowski
We believe that the bug you reported is fixed in the latest version of
pmdk, 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 990...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Adam Borowski (supplier of updated pmdk 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, 02 Jul 2021 15:23:11 +0200
Source: pmdk
Architecture: source
Version: 1.11.0-1
Distribution: experimental
Urgency: medium
Maintainer: Adam Borowski
Changed-By: Adam Borowski
Closes: 990573
Changes:
pmdk (1.11.0-1) experimental; urgency=medium
.
* New upstream release.
+ Fixes insufficient flushing on ARMv8.2+ (closes: #990573).
Checksums-Sha1:
3039406ccbe8c325f7ac29e081d00c5ef5e41a2a 3861 pmdk_1.11.0-1.dsc
97fbd6d72725144eb05c60ac298710d910d62de1 2422502 pmdk_1.11.0.orig.tar.gz
43f09d46e7b64da0b5208e3cd07bac2698e95c23 833 pmdk_1.11.0.orig.tar.gz.asc
eb86486042012247ea5a94e5823c84611533a707 15404 pmdk_1.11.0-1.debian.tar.xz
Processed: Re: debian/copyright should mention BSD3 license, not PSF
Processing control commands: > severity -1 serious Bug #801951 [python3-dateutil] debian/copyright should mention BSD3 license, not PSF Severity set to 'serious' from 'important' > retitle -1 d/copyright must contain BSD3 and Apache 2, not PSF Bug #801951 [python3-dateutil] debian/copyright should mention BSD3 license, not PSF Changed Bug title to 'd/copyright must contain BSD3 and Apache 2, not PSF' from 'debian/copyright should mention BSD3 license, not PSF'. -- 801951: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801951 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990575: php8.0: CVE-2021-21704 CVE-2021-21705
Source: php8.0 Version: 8.0.7-1 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for php8.0, they are fixed in 8.0.8 upstream. CVE-2021-21704[0]: | PHP: firebird issues CVE-2021-21705[1]: | PHP: SSRF bypass in FILTER_VALIDATE_URL If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-21704 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21704 [1] https://security-tracker.debian.org/tracker/CVE-2021-21705 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21705 Regards, Salvatore
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Dear Ajith, I uploaded a fixed package to Debian, just before Jithin proposed an even better fix (more general for various hardware related to Phoenix project). We must let some time to developers of the release.debian.org to manage the current "unblock request". If they agree with the unblock request, expeyes will be part of the next Debian/stable distribution. I shall try to upload Jithin's better fix later: maybe some member of release.debian.org will be able to take it in consideration, as a second (and lighter) change to this package. Best regards, Georges. Ajith Kumar a écrit : > Dear Georges, > I think a message may be displayed during the installation of eyes17 > instructing to remove the modem manager in case of any trouble > communicating with eyes17. It is left to the user instead of a forced > removal. It is important to have it in the Distro. The users in Kerala is a > closed community and we can instruct them. Jithin may consider it. signature.asc Description: PGP signature
Processed: found 990566 in 1:2.3.13+dfsg1-1, tagging 990566
Processing commands for cont...@bugs.debian.org: > found 990566 1:2.3.13+dfsg1-1 Bug #990566 [src:dovecot] dovecot: CVE-2021-33515 CVE-2021-29157 CVE-2020-28200 Marked as found in versions dovecot/1:2.3.13+dfsg1-1. > tags 990566 + upstream Bug #990566 [src:dovecot] dovecot: CVE-2021-33515 CVE-2021-29157 CVE-2020-28200 Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 990566: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990566 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: found 990561 in 1.40.0-1, tagging 990561
Processing commands for cont...@bugs.debian.org: > found 990561 1.40.0-1 Bug #990561 [src:libuv1] libuv1: CVE-2021-22918 Marked as found in versions libuv1/1.40.0-1. > tags 990561 + upstream Bug #990561 [src:libuv1] libuv1: CVE-2021-22918 Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 990561: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990561 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990573: libpmem1: insufficient flushing on ARMv8.2+
Package: libpmem1
Version: 1.10-1
Severity: grave
Justification: causes data loss
[a fix is coming, filing this bug so the Release Team knows why]
Hi!
Support for arm64 in PMDK is deeply experimental. As far as I know, it has
never been tested on real hardware nor had been reviewed by someone with
adequate knowledge about ARM. Yet, enabling arm64 in our packages has been
requested multiple times, and bullseye / buster-backports do include arm64
builds. This was done with porting in mind, yet it looks like pmem-capable
ARM hardware is coming soon, and will be used in production not long after.
This makes inadequate support for new ARM chips unfortunate to say the least.
In ARMv8.0 and ARMv8.1, the only flushes available were CVAI (to make icache
= dcache, irrelevant for pmem), and CVAC ("flush to coherency"). The latter
was the deepest flush available, and implementors simply had no other option
than to have this instruction request the memory controller to send its data
to actual memory chips.
This changed in ARMv8.2, where a new instruction CVAP ("flush to
persistency") has been added, and CVAC was defined to require coherency only
between "agents" (such as CPU cores, GPU, etc) but not memory.
Yet PMDK knew only about CVAC -- despite asking around, no one of us could
get hold of an ARMv8.2 machine to implement detection/etc. Such support is
obviously not a priority for Intel nor IBM.
Only recently, I managed to get access to such a box, and implemented
flushes via CVAP. Without them, an unexpected power loss may result in
recent writes being lost. This is even worse than with disks -- a typical
filesystem will flush every 5 seconds or so, while there's no time-based
mechanism to flush CPU caches. If a machine finished its task and became
quiescent, it's possible the kernel and daemons won't actively touch more
than 16-64MB of L3 cache for hours or days.
The new flushes have been merged upstream in 1.11, I'm about to cherry-pick
to 1.10 for Bullseye.
Meow!
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.13.0-00032-g2fc675a48a0e (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libpmem1 depends on:
ii libc6 2.31-12
ii libdaxctl1 71.1-1
ii libndctl6 71.1-1
libpmem1 recommends no packages.
libpmem1 suggests no packages.
-- no debconf information
Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?
Dear Georges, I think a message may be displayed during the installation of eyes17 instructing to remove the modem manager in case of any trouble communicating with eyes17. It is left to the user instead of a forced removal. It is important to have it in the Distro. The users in Kerala is a closed community and we can instruct them. Jithin may consider it. Regards. On Wed, Jun 30, 2021 at 9:36 PM Georges Khaznadar wrote: > Dear Andreas, > > I added in Cc: the authors of Expeyes hardware and software. > > Hello Jithin, Ajith! the context about the bug report with serious > severity is below. > > > > I ignored that a statement like "Conflicts: modemmanager" would create > problems with buster->bullseye upgrades. Currently, binary packages > conflicting with modemmanager are: eyes17, python3-expeyes, > firm-phoenix-ware. The first one, eyes17, will be the most used. > > This statement was added because boxes of the Expeyes family do not > communicate correctly by their serial link when modemmanager is > installed. I did not investigate further, to know the precise reason of > the incompatibility. > > I got e-mails of some users of previous versions of expeyes packages, > who could not activate their boxes, and my reply was to uninstall > modemmanager or upgrade to the new version of eyes17 package. > > The number of Expeyes users is currently growing in Kerala (a southern > state of India), and they rely on *eyes17* package, some with a Debian > machine, most with an Ubuntu machine. This community is growing since > Eyes17 box has become an officially encouraged scientific device, to be > distributed to all high schools in the state, together with training. > > I cannot withdraw the confict statement without damaging this user > community in the future. > > Hence the next question: > > > How would it be possible to keep expeyes packages in the soon-to-come > Debian/Stable distribution? > > The package modemmanager is recommended by widely used packages, like > network-manager, while eyes17 is recommended by no package. > > I do not know how many users do really need modemmanager, or use modems. > > However I know better the profile of users who use eyes17: they are > students and teachers, wo interact inside a high school. Then, the link > with Internet is generally provided by some router or some wireless box, > and no modem is used. > > @Jitin, @Ajith: > can you give please an estimate of the user community for eyes17 now, > and in a near future? > > Best regards, Georges. > > Andreas Beckmann a écrit : > > Package: python3-expeyes > > Version: 4.8.7+repack-4 > > Severity: serious > > User: debian...@lists.debian.org > > Usertags: piuparts > > Control: affects -1 + eyes17 > > > > Hi Georges, > > > > while investigating incomplete buster->bullseye upgrades, I came across > > the Conflicts: modemmanager in python3-expeyes. Why was that added? > > It is not mentioned in the changelog and the git commit introducing it > > doesn't explain it either. > > Should this have been a versioned Breaks instead? > > > > The modemmanager package still exists in bullseye, so what should be the > > desired buster->bullseye upgrade outcome for buster systems with both > > modemmanager and python3-expeyes installed (that happens e.g. when > > installing eyes17/buster with --install-recommends)? > > > > > > Andreas > > -- > Georges KHAZNADAR et Jocelyne FOURNIER > 22 rue des mouettes, 59240 Dunkerque France. > Téléphone +33 (0)3 28 29 17 70 > > -- Dr. Ajith Kumar B.P. https://scischool.in/ Ph: +91 9643258320 , 9868150852
Bug#990569: libnode72: Missing dependency on libuv
Package: libnode72 Version: 12.21.0~dfsg-4 Severity: serious Justification: Policy 3.5 Hi, i just realized libnode72 doesn't depend on libuv, even being built with --shared-libuv. Something is broken, will investigate quickly. Jérémy -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnode72 depends on: ii libbrotli1 1.0.9-2+b2 ii libc-ares2 1.17.1-1 ii libc6 2.31-12 ii libgcc-s1 10.2.1-6 ii libicu67 67.1-7 ii libnghttp2-14 1.43.0-1 ii libssl1.1 1.1.1k-1 ii libstdc++6 10.2.1-6 ii zlib1g 1:1.2.11.dfsg-2 libnode72 recommends no packages. libnode72 suggests no packages. -- no debconf information
Bug#990566: dovecot: CVE-2021-33515 CVE-2021-29157 CVE-2020-28200
Source: dovecot X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for dovecot. CVE-2021-33515[0]: | The submission service in Dovecot before 2.3.15 allows STARTTLS | command injection in lib-smtp. Sensitive information can be redirected | to an attacker-controlled address. https://dovecot.org/pipermail/dovecot-news/2021-June/000462.html https://www.openwall.com/lists/oss-security/2021/06/28/2 CVE-2021-29157[1]: | Dovecot before 2.3.15 allows ../ Path Traversal. An attacker with | access to the local filesystem can trick OAuth2 authentication into | using an HS256 validation key from an attacker-controlled location. | This occurs during use of local JWT validation with the posix fs | driver. https://dovecot.org/pipermail/dovecot-news/2021-June/000461.html https://www.openwall.com/lists/oss-security/2021/06/28/1 CVE-2020-28200[2]: | The Sieve engine in Dovecot before 2.3.15 allows Uncontrolled Resource | Consumption, as demonstrated by a situation with a complex regular | expression for the regex extension. https://dovecot.org/pipermail/dovecot-news/2021-June/000460.html https://www.openwall.com/lists/oss-security/2021/06/28/3 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-33515 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33515 [1] https://security-tracker.debian.org/tracker/CVE-2021-29157 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29157 [2] https://security-tracker.debian.org/tracker/CVE-2020-28200 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28200 Please adjust the affected versions in the BTS as needed.
Bug#990561: libuv1: CVE-2021-22918
Source: libuv1 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, the latest nodejs security release included an issue in libuv: https://nodejs.org/en/blog/vulnerability/july-2021-security-releases/ The patch hasn't landed in libuv.git, but here's the patch as applied by nodejs: https://github.com/nodejs/node/commit/d33aead28bcec32a2a450f884907a6d971631829 For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-22918 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22918 Please adjust the affected versions in the BTS as needed.
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
On Fri, 2 Jul 2021 00:43:02 +0200 Sebastian Ramacher wrote: > Yes, but note that this needs to happen soon as it has to pass NEW. Thanks, I'll try it. -- Hideki Yamane
