Bug#1021857: CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 (message):
Salut Sylvestre ! On Wed, Nov 30, 2022 at 9:21 PM Sylvestre Ledru wrote: > > btw, do you know what caused this in cmake? (seems that it is caused by > a new cmake version). > > (or not to make sure that all binaries aren't exported?) If you have a build-tree of llvm-14, here is what I would do: $ cd obj-* $ DESTDIR=/tmp/sylvestre make install $ find /tmp/sylvestre -name mlir-tblgen output1 $ grep mlir-tblgen /tmp/sylvestre/usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake output2 -> verify output1 & output2 matches > > Le 28/11/2022 à 12:07, Mathieu Malaterre a écrit : > > Control: found 1021857 1:14.0.6-2 > > > > -- Found LibXml2: /usr/lib/x86_64-linux-gnux32/libxml2.so (found > > version "2.9.14") > > CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 > > (message): > >The imported target "mlir-tblgen" references the file > > > > "/usr/lib/llvm-14/bin/mlir-tblgen" > > > >but this file does not exist. Possible reasons include: > > > >* The file was deleted, renamed, or moved to another location. > > > >* An install or uninstall procedure did not complete successfully. > > > >* The installation package was faulty and contained > > > > "/usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake" > > > >but not all the files it references. > > > > Call Stack (most recent call first): > >/usr/lib/llvm-14/cmake/LLVMConfig.cmake:323 (include) > >openvdb_ax/openvdb_ax/CMakeLists.txt:105 (find_package) > > > > > > > > * > > https://buildd.debian.org/status/fetch.php?pkg=openvdb=x32=10.0.0-7=1669627540=0 > > > > ___ > > Pkg-llvm-team mailing list > > pkg-llvm-t...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team
Bug#1025091: toot: Posting toots with media attachment fails
On Tue, 29 Nov 2022, at 19:27, gregor herrmann wrote: > As far as I can guess from the debug output, toot expects something > in text_url the but reply from the server contains "text_url":null The text_url field was deprecated and seems to be removed in Mastodon 4. This bug is fixed in toot 0.30.1. Regards, -- Ivan
Bug#1023738: orthanc-dicomweb FTBFS with node-axios 1.1
Hi Andreas, Sorry for not answering earlier, but I'm still in the process of finalizing the GNU Health / Orthanc conference, and I'm extremely busy with my academic activities. I admit I would have loved if you would have made some noise about this conference on the Debian Med list. I hope you had a successful conference. The conference was great success, and I advertised about it on the Debian Med mailing list back in August: https://lists.debian.org/debian-med/2022/08/msg00060.html Unfortunately, I got no feedback from our community. The openSUSE community was present, and I hope we'll get submissions from our community in the next edition of this joint conference. I'll have a look by Wednesday 30th November. Do you think you can work on this in the next couple of days? Yes, as soon as I finalize a research application that could gather funding for Orthanc and GNU Health... sorry for the delay, I got feedback yesterday that required a rework for this application. Cheers, Sébastien- -- Sébastien Jodogne Mail: s.jodo...@orthanc-labs.com Web: http://www.orthanc-labs.com/ Twitter: https://twitter.com/sjodogne
Bug#1025222: clblas: ftbfs due to Could NOT find PythonInterp
Source: clblas Version: 2.12-2 Severity: serious Tags: ftbfs Dear Maintainer, The package has ftbfs issue due to: ``` -- Found OPENCL: /usr/lib/x86_64-linux-gnu/libOpenCL.so (found version "2.0") -- FindOpenCL /usr/lib/x86_64-linux-gnu/libOpenCL.so, /usr/include -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.33.0") found components: program_options -- Boost_PROGRAM_OPTIONS_LIBRARY: Boost::program_options CMake Error at /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE) Call Stack (most recent call first): /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.25/Modules/FindPythonInterp.cmake:170 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) library/CMakeLists.txt:17 (find_package) ... ``` The full buildd log is here: https://buildd.debian.org/status/fetch.php?pkg=clblas=amd64=2.12-2=1669843177=0 It is easy to fix the issue and I will update it once verifing. -- Regards, -- Bo YU signature.asc Description: PGP signature
Bug#1023738: orthanc-dicomweb FTBFS with node-axios 1.1
Hi Sébastien, On Thu, 24 Nov 2022 17:37:36 you wrote > Sorry for not answering earlier, but I'm still in the process of > finalizing the GNU Health / Orthanc conference, and I'm extremely busy > with my academic activities. I admit I would have loved if you would have made some noise about this conference on the Debian Med list. I hope you had a successful conference. > I'll have a look by Wednesday 30th November. Do you think you can work on this in the next couple of days? Kind regards Andreas. -- http://fam-tille.de
Bug#1024155: Fixed in Git [Re: libngs-c++-dev: missing Breaks+Replaces: libncbi-vdb-dev (<< 3), libngs-sdk-dev (<< 3)]
Control: tags -1 pending Hi Aaron, I have fixed this issue in Git. I'm wondering about the status of the ncbi-vdb transition[1]. Isn't it time to upload the packages to unstable now? Just let me know if you need any help. Kind regards Andreas. PS: Do you have any information whether it is sensible to upgrade to sra-sdk version 3.0.1? [1] https://release.debian.org/transitions/html/auto-ncbi-vdb.html -- http://fam-tille.de
Bug#1017844: ITP: python-axisregistry -- Access data from the Google Fonts variable fonts axis registry
Initial work is available at https://salsa.debian.org/python-team/packages/axisregistry Work is paused while other gftools update blockers are not resolved.
Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x
Some additional digging findings; - Testing and Unstable packages are not affected as they are built from the upstream passenger 6.x branch, which already includes this fix. - Stable package is not affected when using the nodejs package from debian stable repo as this is still on the nodejs 12.x branch. - Stable package is affected when using newer stable release from upstream vendor repo (deb.nodesource.com). It would be superb if we could get the fix from passenger 6.x backported to the debian stable passenger package so we can deploy on modern nodejs versions.
Bug#1025221: abseil: please consider disabling tests on riscv64
Source: abseil Version: 20220623.1-1 Hello, looks like riscv64 is timeouting on some tests, due to non-fast-enough hardware. Can you please consider disabling the tests also on that architecture? Also powerpc might be disabled I think log on riscv64: 99% tests passed, 2 tests failed out of 182 Total Test time (real) = 152.50 sec The following tests FAILED: 165 - absl_mutex_test (Subprocess aborted) 167 - absl_per_thread_sem_test (Failed) Errors while running CTest log on powerpc: 99% tests passed, 2 tests failed out of 182 Total Test time (real) = 1500.51 sec The following tests FAILED: 49 - absl_symbolize_test (Subprocess aborted) 50 - absl_failure_signal_handler_test (Timeout) Errors while running CTest thanks, Gianfranco OpenPGP_signature Description: OpenPGP digital signature
Bug#1022822: apache2: improve apache2 OOM handling w/systemd
close 1022822 2.4.54-5 thanks this seems to have been fixed in the most recent upload (without mentioning in changelog), so closing the bug. Regards, Daniel
Bug#1022160: new upstream (3.12)
Hi Robert, any eta, would you like some help with this? Regards, Daniel
Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x
Package: passenger Version: 5.0.30-1.2 Severity: important Dear Maintainer, Passenger errors out when starting a nodejs application when using a nodejs version later than 14.x. It throws the following error: /usr/share/passenger/helper-scripts/node-loader.js:41 GLOBAL.PhusionPassenger = exports.PhusionPassenger = new EventEmitter(); ^ ReferenceError: GLOBAL is not defined at Object. (/usr/share/passenger/helper-scripts/node-loader.js:41:1) at Module._compile (node:internal/modules/cjs/loader:1159:14) at Module._extensions..js (node:internal/modules/cjs/loader:1213:10) at Module.load (node:internal/modules/cjs/loader:1037:32) at Module._load (node:internal/modules/cjs/loader:878:12) at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) at node:internal/main/run_main_module:23:47 (Nodejs version: v18.12.1) It seems that after 14.x the "GLOBAL" alias to the "global" object was removed. Replacing the usage of "GLOBAL" with its lowercase variant in the node-loader.js file seems to be the way to fix this. -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-17-amd64 (SMP w/24 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) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages passenger depends on: ii libc6 2.31-13+deb11u5 ii libcurl47.74.0-1.3+deb11u3 ii libgcc-s1 10.2.1-6 ii libruby2.7 2.7.4-1+deb11u1 ii libstdc++6 10.2.1-6 ii libuv1 1.40.0-2 ii ruby1:2.7+2 ii ruby-rack 2.1.4-3 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 passenger recommends no packages. Versions of packages passenger suggests: ii nodejs 18.12.1-deb-1nodesource1 pn passenger-doc ii python33.9.2-3 pn rails -- no debconf information
Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel
Hi, Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers: > Source: r-cran-glmmtmb > Version: 1.1.4+dfsg-3 > Severity: serious > Tags: ftbfs > Justification: ftbfs > > Dear maintainer(s), > > Your package failed to build from source on mipsel, where it built > successfully in the past. > > https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb=mipsel=1.1.5%2Bdfsg-1=1669057119=0 > ... > cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 > bytes Isn't this just a matter of the autobuilders hardware? If not I do not see any other clue but removing the package for mipsel. Kind regards Andreas. -- http://fam-tille.de
Bug#1025219: libass: new upstream version 0.17.0
Source: libass Version: 1:0.16.0-1 Severity: wishlist Hi! a new version was just released upstream and it would be great if it could make it into Bookworm. https://github.com/libass/libass/releases/0.17.0 I noticed the automatic uscan watch broke a couple days ago for many GitHub-hosted projects. Apparently, the asset list on the releases page is no longer part of the website but dynamically loaded in from e.g. https://github.com/libass/libass/releases/expanded_assets/0.17.0 without any "latest" redirect afaik. The best fix I can come up with atm is to use GitHub’s REST API and uscan’s searchmode=plain to account for JSON being served instead of HTML. This also required to make the regex a bit stricter, but using the following watchline appears to work fine: opts=pgpsigurlmangle=s/$/.asc/,pgpmode=auto,searchmode=plain \ https://api.github.com/repos/libass/libass/releases/latest \ https?://[^"]*/libass-(\d+[^"]*)+\.tar\.gz (Note: there’s a preexisting warning about pgpsigurlmangle being ignored because pgpmode=auto is also set. Just removing pgpsigurlmangle doesn’t seem to cause issues and it still checks the signature but I’m less sure about this change) If you want to match and search through all releases, rather than just the latest one, remove the trailing /latest from the api.github.com URL. Speaking about pgp, there’s another issue. As announced last release tarballs may now be signed by any one of multiple authorised keys. debian/upstream/signing-key.asc currently only contains Oleg’s public key, who signed 0.15.x and 0.16.0, but this release is signed by my key, so in order for uscan to not reject the signature, all authorised keys need to be added to debian/upstream/signing-key.asc. I described how to do this (+ provided a patch) and how to establish a chain of trust from Oleg’s key to the other authorised keys in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012524 Regarding the new optional dependency, a just barely sufficiently recent version of libunibreak is already packaged in Debian, so it can be linked to for making ASS_FEATURE_WRAP_UNICODE do something. (Otherwise the packaged release 1.1 from 2013 is rather outdated though.) If you have any more questions or if I can somehow help with getting the new release packaged, let me know. Cheers Oneric signature.asc Description: PGP signature
Bug#1012524: libass: PGP signature
Control: severity -1 important With the new upstream release, adding the additional keys is now required for uscan to accept the signature. signature.asc Description: PGP signature
Bug#985857: RFP: libjs-bootstrap5 -- HTML, CSS and JS framework
Hi On 11/30/22 21:31, Emmy D'Anello wrote: > Is there any update? yes, I'm ready to upload in the next few days. Regards, Daniel
Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote: > Hi Scott, > > On 01/12/2022 02:16, Scott Kitterman wrote: > > Package: lintian > > Version: 2.115.3 > > Severity: normal > > X-Debbugs-Cc: debian-pyt...@lists.debian.org > > > > The missing-prerequisite-for-pyproject-backend check appears to only > > look for the prerequisite packages in Build-Depends, but since they > > aren't needed for clean, they could be in Build-Depends-Indep, leading > > to false positives. > > > > Scott K > > I contemplated filing a similar the other day but in writing it up, I > realised that lintian was correct. Policy requires that the 'clean' > target be functional with only the Build-Depends (and Build-Conflicts) > satisfied, and pybuild + the build-backend dependencies are involved in > the cleaning step. Not always. At least with the package I ran into this on, clean works fine without them. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1023954: WX assertion failure within the raw importer
Package: hugin
Version: 2022.0~beta1+dfsg-1
Followup-For: Bug #1023954
This bug still exists with 2022.0~beta1+dfsg-1. (As does #1023279, BTW)
Complete console output:
(hugin:2312042): Gtk-CRITICAL **: 10:31:00.719:
gtk_widget_set_size_request: assertion 'height >= -1' failed
(hugin:2312042): Gtk-CRITICAL **: 10:31:00.806:
gtk_widget_set_size_request: assertion 'height >= -1' failed
(hugin:2312042): Gtk-CRITICAL **: 10:31:00.809:
gtk_widget_set_size_request: assertion 'height >= -1' failed
(hugin:2312042): Gtk-CRITICAL **: 10:31:00.809:
gtk_widget_set_size_request: assertion 'height >= -1' failed
(hugin:2312042): Gtk-CRITICAL **: 10:31:00.815:
gtk_widget_set_size_request: assertion 'height >= -1' failed
(hugin:2312042): Gtk-CRITICAL **: 10:31:00.818:
gtk_widget_set_size_request: assertion 'height >= -1' failed
(hugin:2312042): Gtk-CRITICAL **: 10:31:00.818:
gtk_widget_set_size_request: assertion 'height >= -1' failed
/usr/share/hugin/data/plugins/top_five.py
CAT:Control Points
NAM:keep 5 CPs per image pair
fails @api-max
/usr/share/hugin/data/plugins/woa.py
CAT:Control Points
NAM:Warped Overlap Analysis
fails @api-max
ERROR: 10:31:04.966707 (./src/hugin1/hugin/GLViewer.cpp:133)
SetUpContext(): Error initialising GLEW: Unknown error.
./src/common/sizer.cpp(2267): assert "CheckSizerFlags(!((flags) &
(wxALIGN_RIGHT)))" failed in DoInsert(): wxALIGN_RIGHT will be ignored in this
sizer: only vertical alignment flags can be used in horizontal sizers
DO NOT PANIC !!
If you're an end user running a program not developed by you, please ignore
this message, it is harmless, and please try reporting the problem to the
program developers.
You may also set WXSUPPRESS_SIZER_FLAGS_CHECK environment variable to
suppress all such checks when running this program.
If you're the developer, simply remove this flag from your code to avoid
getting this message. You can also call
wxSizerFlags::DisableConsistencyChecks() to globally disable all such checks,
but this is strongly not recommended.
Trace/breakpoint trap
And after installing some debug symbol packages and asking gdb for a
backtrace:
#0 wxBoxSizer::DoInsert (this=0x576f9170, index=1,
item=0x575bbec0) at ./src/common/sizer.cpp:2273
flags = 752
__FUNCTION__ = "DoInsert"
#1 0x5581d4eb in wxSizer::Insert (item=,
index=, this=0x576f9170) at
/usr/include/wx-3.2/wx/sizer.h:1181
No locals.
#2 wxSizer::Add (item=0x575bbec0, this=0x576f9170) at
/usr/include/wx-3.2/wx/sizer.h:1188
No locals.
#3 wxSizer::Add (userData=0x0, border=10, flag=752, proportion=0,
window=0x5709e010, this=0x576f9170) at
/usr/include/wx-3.2/wx/sizer.h:1194
No locals.
#4 RawImportProgress::RawImportProgress (this=0x7fffb410,
parent=, converter=..., rawImages=..., images=...,
refImg=) at ./src/hugin1/hugin/RawImport.cpp:487
topsizer = 0x569ffae0
bottomsizer = 0x576f9170
topsizer =
bottomsizer =
__PRETTY_FUNCTION__ =
topsizer =
bottomsizer =
#5 0x55819dbd in RawImportDialog::OnOk (this=0x7fffd220,
e=...) at ./src/hugin1/hugin/RawImport.cpp:824
rawConverter = std::shared_ptr (use count 2, weak count
0) = {get() = 0x57767f80}
rawConverterInt = 0
dlg = { = { =
{> = { =
{ = { = { =
{ = { = { = { =
{ = {_vptr.wxObject = 0x558d2b70 , static ms_classInfo = {m_className = 0x77724348
L"wxObject", m_objectSize = 16, m_objectConstructor = 0x0, m_baseInfo1 = 0x0,
[snip remainder of unreasonably large stack frame]
This suggests that WX is complaining about attempted right-alignment of the
Cancel button
of the import progress dialog?
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500,
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (480, 'testing-debug'),
(480, 'testing'), (470, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-18-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages hugin depends on:
ii enblend 4.2-9
ii enfuse 4.2-9
ii hugin-tools 2022.0~beta1+dfsg-1
ii libc6 2.36-5
ii libexiv2-27 0.27.5-4
ii libfftw3-double33.3.8-2
ii libgcc-s1 10.2.1-6
ii libglew2.2 2.2.0-4+b1
ii
Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
Hi Scott, On 01/12/2022 02:16, Scott Kitterman wrote: Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org The missing-prerequisite-for-pyproject-backend check appears to only look for the prerequisite packages in Build-Depends, but since they aren't needed for clean, they could be in Build-Depends-Indep, leading to false positives. Scott K I contemplated filing a similar the other day but in writing it up, I realised that lintian was correct. Policy requires that the 'clean' target be functional with only the Build-Depends (and Build-Conflicts) satisfied, and pybuild + the build-backend dependencies are involved in the cleaning step. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025214: dkms: --environment-overrides causes several module build failures
Control: severity -1 grave
Hi!
Guess who just spent two hours chasing this down in a big upgrade with
a half-bootable system in the mean-time :)
Retagging as grave ("unusable by most or all users, or causes data loss"
feels more appropriate than "severe violation of Debian policy").
I cannot tell you just how /tempting/ critical ‒ "makes unrelated
software on the system (or the whole system) break" is,
probably would be even more so if I weren't on battery :)
My system's on ZFS. Needs ZFS to boot, actually. It's very cool to see
" doesn't exist" in the log. Much cooler still to find that
I can run make myself in the build directory and it works! Very cool and
fun to spend multiple minutes per iteration with ZFS's long
configuration times!
The dkms bit from apt-listchanges is
-- >8 --
dkms (3.0.8-2) unstable; urgency=medium
* export-CC, exact-cc: Merge and improve the two patches. Ensure that
compiler is set and exported as early in the prepartion stage as
possible, is not subsequently unset (already unset at the start of the
dkms script), and also export MAKEFLAGS to ensure that environment CC
variable is used by kernel's Makefile. Fixes LP: #1997841
* Drop dangling unapplied patch from git.
-- Dimitri John Ledkov Thu, 24 Nov 2022
14:59:45 +
dkms (3.0.8-1) unstable; urgency=medium
[ Andreas Beckmann ]
* update watch file
* message consistency
[ Gianfranco Costamagna ]
* New upstream version 3.0.8
* Drop upstream patches:
- 2b76d4aa29e65ae4ed8e89685c4e729f1276c5fc
- 3ca52f8769bdf7ebdc83735355fff7c5c0664152
- 7f3c4b03c506e40f0a5ce9315a8ade88b108ce0f
- 8d60956f6dcda0679066954215eb8be4045413b4
- 985bfd584f0e87bc726865bfdc17887d4713c854
* Refresh patches
-- Gianfranco Costamagna Fri, 18 Nov 2022 22:34:50
+0100
-- >8 --
I downgraded to 3.0.8-1 from snapshot.d.o (which surprisingly didn't
explode despite how fucked my dpkg config state was). That worked.
Please consider verifying whether an "improvement" doesn't straight-up
break every user before uploading.
This graph shows that the nvidia driver /alone/ is /4%/ of all reporting
installations (unfiltered rdeps for dkms):
https://qa.debian.org/popcon-graph.php?packages=zfs-dkms+zfs-dkms+r8168-dkms+nvidia-legacy-390xx-kernel-dkms+nvidia-kernel-dkms+broadcom-sta-dkms+zfs-dkms+acpi-call-dkms+dahdi-dkms+r8168-dkms+nvidia-tesla-470-kernel-dkms+nvidia-tesla-460-kernel-dkms+nvidia-tesla-450-kernel-dkms+nvidia-tesla-418-kernel-dkms+nvidia-legacy-390xx-kernel-dkms+nvidia-kernel-dkms+broadcom-sta-dkms+xtrx-dkms+xtables-addons-dkms+wireguard-dkms+west-chamber-dkms+v4l2loopback-dkms+tp-smapi-dkms+openrazer-driver-dkms+openafs-modules-dkms+octavia-agent+nat-rtsp-dkms+lttng-modules-dkms+live-task-recommended+lime-forensics-dkms+vpoll-dkms+langford-dkms+jool-dkms+iptables-netflow-dkms+gost-crypto-dkms+evdi-dkms+dpdk-kmods-dkms+dm-writeboost-dkms+digimend-dkms+ddcci-dkms+acpi-call-dkms+bbswitch-dkms+adv-17v35x-dkms_installed=on_percent=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1
:)
At least it didn't migrate to testing.
наб
signature.asc
Description: PGP signature
Bug#1025218: python3-urllib3: please drop dependance on python3-six
Package: python3-urllib3 Version: 1.26.12-1 Severity: normal Hi, Please drop dependance on Python3-six. The embedded copy has been removed from the upcoming release. https://sources.debian.org/src/python-urllib3/1.26.12-1/src/urllib3/packages/six.py/ -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) 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) Versions of packages python3-urllib3 depends on: ii python3 3.10.6-1 ii python3-six 1.16.0-4 Versions of packages python3-urllib3 recommends: ii ca-certificates 20211016 Versions of packages python3-urllib3 suggests: ii python3-brotli1.0.9-2+b5 ii python3-cryptography 3.4.8-2 ii python3-idna 3.3-1 ii python3-openssl 21.0.0-1 pn python3-socks -- no debconf information
Bug#1025217: please update sage for pari 2.15.0 and gap 4.12.0
Package: python3-sage Version: 9.5-4+b3 Followup-For: Bug #1020576 Dear Maintainer, I'm running a testing/unstable mix here and the current version of python3-sage is with the current version od pari (2.15.1-1 here), but it requires libgap7 (4.11.1-3) which conflicts with the current gap-libs (4.12.1-2). Since libgap8 is already available I wonder if it could be the required GAP shared libraty for python3-sage. Best, Alexandre -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable-security') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-sage depends on: ii bc1.07.1-3+b1 ii binutils 2.39-8 ii bzip2 1.0.8-5+b1 ii ca-certificates 20211016 ii cliquer 1.21-3+b1 ii cmake 3.25.0-3 ii curl 7.86.0-2 ii cython3 0.29.32-2 ii ecl 21.2.1+ds-4 ii eclib-tools 20221012-1 ii fflas-ffpack 2.5.0-1 ii flintqs 1:1.0-4 ii gap-atlasrep 2.1.6-1 hi gap-dev 4.11.1-3 ii gap-online-help 4.12.1-2 ii gap-primgrp 3.4.2-1 hi gap-smallgrp 1.5-1 ii gap-table-of-marks1.2.9-2 ii gap-transgrp 3.6.3-1 ii gfan 0.6.2-6+b1 ii gfortran 4:12.2.0-1 ii glpk-utils5.0-1 ii gmp-ecm 7.0.5+ds-1 ii jmol 14.32.79+dfsg2-1 ii lcalc 2.0.5-1+b1 ii libatlas3-base [libblas.so.3] 3.10.3-12 ii libatomic-ops-dev 7.6.14-1 ii libblas3 [libblas.so.3] 3.10.1-2 ii libboost-dev 1.74.0.3 ii libbraiding-dev 1.1-1 ii libbraiding0 1.1-1 ii libbrial-dev 1.2.11-1 ii libbrial-groebner-dev 1.2.11-1 ii libbrial-groebner31.2.11-1 ii libbrial3 1.2.11-1 ii libbz2-dev1.0.8-5+b1 ii libc6 2.36-5 ii libcdd-dev094m-1 ii libcdd-tools 094m-1 ii libcliquer-dev1.21-3+b1 ii libcliquer1 1.21-3+b1 ii libcurl4-openssl-dev 7.86.0-2 ii libec-dev 20221012-1 ii libec10 20221012-1 ii libecl21.221.2.1+ds-4 ii libecm-dev7.0.5+ds-1 ii libecm1 7.0.5+ds-1 ii libffi-dev3.4.4-1 ii libflint-arb-dev 1:2.23.0-1+b1 ii libflint-arb2 1:2.23.0-1+b1 ii libflint-dev 2.9.0-5 ii libflint172.9.0-5 ii libfreetype-dev [libfreetype6-dev]2.12.1+dfsg-3 ii libfreetype6-dev 2.12.1+dfsg-3 hi libgap-dev4.11.1-3 ii libgap7 4.11.1-3 ii libgc-dev 1:8.2.2-3 ii libgcc-s1 12.2.0-9 ii libgd-dev 2.3.3-7 ii libgd32.3.3-7 ii libgf2x-dev 1.3.0-2 ii libgiac-dev 1.9.0.29+dfsg2-1 ii libgiac0 1.9.0.29+dfsg2-1 ii libgivaro-dev 4.2.0-2 ii libgivaro9
Bug#1024991: RFS: jamulus/3.9.1+dfsg-1 [QA] -- real-time collaborative music session client and server
Hi, On Thu, Dec 1, 2022 at 1:59 AM Adam Borowski wrote: > > On Mon, Nov 28, 2022 at 08:52:48PM +0800, Bo YU wrote: > > * Package name : jamulus > >Version : 3.9.1+dfsg-1 > >Upstream contact : https://sourceforge.net/p/llcon/discussion/ > > * URL : https://jamulus.io/ > > * License : GPL-2.0+ and MIT-STK, CC0, GPL-2.0+, BSD3-OPUS, > > famfamfam-flag-icons > > * Vcs : > > https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/jamulus.git;a=shortlog;h=refs/heads/master > >Section : sound > > > jamulus (3.9.1+dfsg-1) unstable; urgency=medium > > . > >* QA upload. > >* Set Debian QA as maintainer. See #1023670. > >* New upstream version 3.9.1. > >* Update d/copyright: > > - adjust Files-Excluded due to repack. > > - update file-pattern due to upstream change. > >* Add support for riscv64. (Closes: #1024984) > >* Rebase all patches. > >* Adjust d/source/lintian-overrides > >* Update execute_after_dh_auto_install > > Hi! > > .--[ debian/source/lintian-overrides ] > # old repo > jamulus source: orphaned-package-not-maintained-in-debian-infrastructure > ` > > This is not a false positive -- an orphaned package's packaging repo is > supposed to be moved to some place that's writeable by people other than > the previous maintainer. Yes. I think the *right* place is debian namespace on salsa. But I do not have writable permission about it, so I did not change vcs field. In fact I put it under my namespace on salsa when packaging. > > Of course, there's no need to fix everything, especially not in a QA upload > where the only expectation is for the new version to be better than the old > one -- but hiding issues is no good. Agree. I do not intend to hide the issue here just think the lintian error is a false positive in this case.:). Another factor is that from uploading myself packages experience, lintian error will not be accepted even lintian warning by my sponsor. So I have to try to erase it. The most challenge to updating it for me is repacking it to obey DFSG. The workflow for such packages is unclear to me. But I have mastered some points from the package. Thanks again for pointing it. I saw Boyuan[0] has helped to upload the package to Debian archive. So I think I can close the reportbug. BR, Bo [0]: https://tracker.debian.org/news/1392012/accepted-jamulus-391dfsg-1-source-into-unstable/ > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? > ⠈⠳⣄
Bug#1025176: libicu71 missing on SH4 port
On Wed, Nov 30, 2022 at 5:14 PM László Böszörményi (GCS) wrote: > ... > You may locally hack the build of boost1.74 not to require Python > (and drop its related binary packages). Of course, best would be to > port python-greenlet to sh4 or just fix its build - can you give a > helping hand to its upstream? > At least this is what I see without access to any sh4 machine. As we > know each other, I may check it for you if I can access that machine. > But I think you are much more skilled in these things. Yes, sure. Let me take a look at python-greenlet on SH4. I would have done that already, but I could not figure out which package was the problem. Sorry about that! One word of caution... python-greenlet is described as "greenlets are lightweight coroutines for in-process sequential concurrent programming." I know Git has a problem with threads on SH4.[1] So the problem may be a little deeper than a library port. It may be down in libc or the kernel. Put another way, it may be beyond my skill level. [1] https://lore.kernel.org/git/cah8yc8niurchnxprzseba7g1z5af3pqydf1x0rm03rdanec...@mail.gmail.com/ Jeff
Bug#1025161: new version available
Hello! Debian packaging of LXD tracks the upstream LTS releases that receive bug fixes and security updates for fives years [1,2], as opposed to tracking features releases (such as 5.8), which are only supported for one month. Especially once LXD is included in the upcoming bookworm release, it will be far easier to provide bug/security fixes to the LTS branch. Maybe at some point in the future newer feature releases of LXD might be packaged in experimental; the current 5.8 release has several new golang dependencies that I'm in the process of packaging/updating in unstable. Mathias [1] -- https://linuxcontainers.org/lxd/docs/master/security/#supported-versions [2] -- https://discuss.linuxcontainers.org/t/lxd-5-0-lts-has-been-released/13723 signature.asc Description: This is a digitally signed message part
Bug#1025216: python3-setuptools: Missing distutils-precedence.pth
Package: python3-setuptools Version: 65.5.0-1 Severity: normal setuptools 60 uses its own bundled version of distutils, by default. It injects this into sys.modules, at import time. So we need to make sure that it is imported, before anything else imports distutils, to ensure everything is using the same distutils version. I have filed a number of patches upstream to reorder packages setup.py imports, to avoid the problem. But today I discovered why we were the only ones hitting this problem: We don't ship distutils-precedence.pth which should hook this at interpreter startup time. We should ship it. There's an interpreter startup cost to pth files. But all setuptools users would expect us to have this. SR
Bug#1025215: transition: qtermwidget
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: LXQt Packaging Team , Tom
Jampen
This transition is for qtermwidget soversion changing from 0 to 1. The
following are reverse dependencies affected by this transition:
* qterminal: new version has been uploaded to experimental
* texstudio: binNMU
Ben file:
title = "qtermwidget";
is_affected = .depends ~ "libqtermwidget5-0" | .depends ~ "libqtermwidget5-1";
is_good = .depends ~ "libqtermwidget5-1";
is_bad = .depends ~ "libqtermwidget5-0";
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#1025214: dkms: --environment-overrides causes several module build failures
Package: dkms
Version: 3.0.8-2
Severity: serious
Hi,
export MAKEFLAGS="--environment-overrides" causes several modules to
fail to build since this seems to inject unwanted environment variable
values into various build processes.
E.g. the nvidia modules react fragile to the ARCH variable, therefore we
unset that variable first:
MAKE[0]="unset ARCH; env NV_VERBOSE=1 \
make ${parallel_jobs+-j$parallel_jobs} modules KERNEL_UNAME=${kernelver}"
but that does not work any longer. Verbose output shows that it tries to
build with ARCH=x86 (I have no clue where that value comes from)
instead of ARCH=x86_64 (which it even attempts to set).
I think you are mixing two things in the export-CC.patch:
1.) try to get the correct CC value from the kernel (.kernelvariables,
.config, ...) and export that for the benefit of the module build
system, overriding any CC value found in the environment (which is
likely to be wrong) (this does not need to be propagated back to
kbuild)
2.) support overriding the CC used by kbuild (and the module build
system) with some custom value
Andreas
PS: shouldn't you rather append to MAKEFLAGS and not override them?
Bug#972211: FTBFS with OCaml 4.11.1 (-unsafe-string is not available)
Package: mldonkey Followup-For: Bug #972211 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-19-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1025213: gnome-shell: Flickering and mangled screens on wayland if dri driver not available
Package: gnome-shell Version: 43.1-2 Severity: serious Justification: Policy 3.8 Dear Maintainer, Recently a general upgrade was executed with gnome-shell upgrading from version 43.0-2 to 43.1-2. After this upgrade the gnome-shell wayland screen is flickering and mangled at any action. Flickering stops after short time, but screen often is mangled. During flickering different old or background screens are shown. Also the logon-screen is flickering and mangled. Some user-friendly person has decided to stop support for the i915 dri driver. As a "service" the mesa-upgrade at Debian also automatically deletes this driver. If an old i915-dri driver is moved to the original location, the flickering problem is gone. Also if "Gnome on Xorg" is started there is no flickering problem. In that case swrast is used for software rendering. I do not know which method gnome with wayland is using, but it is not swrast. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 6.0.0-4-686-pae (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gir1.2-accountsservice-1.0 22.08.8-1+b1 ii gir1.2-adw-1 1.2.0-1 ii gir1.2-atk-1.0 2.46.0-4 ii gir1.2-atspi-2.0 2.46.0-4 ii gir1.2-freedesktop 1.74.0-2 ii gir1.2-gcr-3 3.41.1-1+b1 ii gir1.2-gdesktopenums-3.0 43.0-1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1 ii gir1.2-gdm-1.0 43.0-1 ii gir1.2-geoclue-2.0 2.6.0-2 ii gir1.2-glib-2.0 1.74.0-2 ii gir1.2-gnomebluetooth-3.0 42.4-1 ii gir1.2-gnomedesktop-3.0 43-2 ii gir1.2-graphene-1.0 1.10.8-1 ii gir1.2-gstreamer-1.0 1.20.4-1 ii gir1.2-gtk-3.0 3.24.35-1 ii gir1.2-gtk-4.0 4.8.2+ds-3 ii gir1.2-gweather-4.0 4.2.0-1 ii gir1.2-ibus-1.0 1.5.27-4 ii gir1.2-mutter-11 43.0-2 ii gir1.2-nm-1.0 1.40.4-1 ii gir1.2-nma-1.0 1.10.4-2 ii gir1.2-pango-1.0 1.50.10+ds-1 ii gir1.2-polkit-1.0 122-1 ii gir1.2-rsvg-2.0 2.54.5+dfsg-1 ii gir1.2-soup-3.0 3.2.1-2 ii gir1.2-upowerglib-1.0 0.99.20-1+b1 ii gir1.2-webkit2-4.1 2.38.2-1+b1 ii gnome-backgrounds 43-1 ii gnome-settings-daemon 43.0-3 ii gnome-shell-common 43.1-2 ii gsettings-desktop-schemas 43.0-1 ii gstreamer1.0-pipewire 0.3.61-1 ii libatk-bridge2.0-0 2.46.0-4 ii libatk1.0-0 2.46.0-4 ii libc6 2.36-5 ii libcairo2 1.16.0-6 ii libecal-2.0-2 3.46.1-1+b2 ii libedataserver-1.2-27 3.46.1-1+b2 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1 ii libgirepository-1.0-1 1.74.0-2 ii libgjs0g 1.74.1-1 ii libgles2 1.5.0-1 ii libglib2.0-0 2.74.1-2 ii libglib2.0-bin 2.74.1-2 ii libgnome-autoar-0-0 0.4.3-1 ii libgnome-desktop-3-20 43-2 ii libgraphene-1.0-0 1.10.8-1 ii libgtk-3-0 3.24.35-1 ii libgtk-4-1 4.8.2+ds-3 ii libical3 3.0.16-1+b1 ii libjson-glib-1.0-0 1.6.6-1 ii libmutter-11-0 43.0-2 ii libnm0 1.40.4-1 ii libpango-1.0-0 1.50.10+ds-1 ii libpangocairo-1.0-0 1.50.10+ds-1 ii libpolkit-agent-1-0 122-1 ii libpolkit-gobject-1-0 122-1 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii libpulse0 16.1+dfsg1-2+b1 ii libsecret-1-0
Bug#1024890: ntcard - build-dependencies unsatisfiable on 32-bit.
On 30/11/2022 07:29, Andreas Tille wrote: 3. Declare your package unsupported on 32-bit architectures and file a removal bug with the ftpmasters. For what architecture should we file a removal bug? armel armhf i386 mipsel s390x (390x is not 32-bit but is also affected, I missed that when initially filing the bug). The package was never released on 32 bit architectures ntcard was built on all release architectures and binaries for all architetures are currently in testing. After it was built, nthash was removed on 32-bit and big-endian architectures as documented in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023060 Could you please give any reason which backs up your choice "serious" for this bug report? The rc policy says Packages must autobuild without failure on all architectures on which they are supported. Packages must be supported on as many architectures as is reasonably possible. Packages are assumed to be supported on all architectures for which they have previously built successfully. Prior builds for unsupported architectures must be removed from the archive (contact -release or ftpmaster if this is the case). Ref: RT? Packages must be buildable within the same release. Ref: RT?
Bug#1025212: transition: libfm-qt
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
This transition is for libfm-qt soversion changing from 11 to 12. All
affected packages listed in [0] have been uploaded to experimental.
Except mips64el, mipsel, ppc64el, all other architectures can be built
successful.
[0] https://release.debian.org/transitions/html/auto-libfm-qt.html
Ben file:
title = "libfm-qt";
is_affected = .depends ~ "libfm-qt11" | .depends ~ "libfm-qt12";
is_good = .depends ~ "libfm-qt12";
is_bad = .depends ~ "libfm-qt11";
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#1025131: apt-cacher-cleanup does not work
Mark Hindley pisze:
Hi,
Control: tags -1 patch
Robert,
Many thanks for pointing this out.
Does the attached patch help?
No, due to perl's syntax error related to unmatched parenthesis. I'm
attaching a patch that actually works.
Regards,
Robert
From cc36b2f690d694ad0cfe1b1c0ca5df7ead3e57ca Mon Sep 17 00:00:00 2001
From: Mark Hindley
Date: Wed, 30 Nov 2022 11:30:21 +
Subject: [PATCH] Add encoded underscores to *_files_regexp. Test fix for
#1025131.
---
lib/apt-cacher.pl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/apt-cacher.pl b/lib/apt-cacher.pl
index 712d0bc..dad985a 100755
--- a/lib/apt-cacher.pl
+++ b/lib/apt-cacher.pl
@@ -132,7 +132,7 @@ sub read_config {
qw(vmlinuz
linux
initrd\.gz
- (?:%VALID_PACKAGE_NAME%_%VALID_VERSION%[_\.])?changelog
+ (?:%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%[_\.])?changelog
NEWS\.Debian
%VALID_UBUNTU_RELEASE_NAMES%\.tar\.gz(?:\.gpg)?
(?:by-hash/(?i:MD5SUM/[0-9a-f]{32}|SHA1/[0-9a-f]{40}|SHA256/[0-9a-f]{64}))
@@ -141,7 +141,7 @@ sub read_config {
)
) . ')$',
package_files_regexp => '(?:' . join('|',
- qw((?:^|/)%VALID_PACKAGE_NAME%_%VALID_VERSION%(?:_%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz)
+ qw((?:^|/)%VALID_PACKAGE_NAME%(?:_|%5f)%VALID_VERSION%(?:(?:_|%5f)%VALID_ARCHS%\.(?:u|d)?deb|\.dsc|\.tar\.(?:gz|bz2|xz|lzma)(?:\.asc)?|\.diff\.gz)
\.rpm
index\.db-.+\.gz
\.jigdo
--
2.35.1
Bug#1025211: /usr/bin/riscv64-unknown-elf-g++: Missing C++ headers for riscv64-unknown-elf-g++
Package: gcc-riscv64-unknown-elf Version: 12.1.0-7+11 Severity: important File: /usr/bin/riscv64-unknown-elf-g++ Hello Keith, I am using the riscv elf toolchain to build a C++ program. It tries to look for headers here: $ echo | riscv64-unknown-elf-g++ -E -Wp,-v - ignoring nonexistent directory "/usr/lib/gcc/riscv64-unknown-elf/12.1.0/../../../riscv64-unknown-elf/sys-include" ignoring nonexistent directory "/usr/lib/gcc/riscv64-unknown-elf/12.1.0/../../../riscv64-unknown-elf/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/riscv64-unknown-elf/12.1.0/include /usr/lib/gcc/riscv64-unknown-elf/12.1.0/include-fixed End of search list. There's no C++ headers in this location. How should users get C++ headers with the elf toolchain? Or is this unsupported, and we should instead use the linux toolchain for C++ programs? I'm not usually a C++ developer so please clarify if I've made some bad assumptions here. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 6.0.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-riscv64-unknown-elf depends on: ii binutils-riscv64-unknown-elf 2.39-8+4 ii libc6 2.36-5 ii libgcc-s1 12.2.0-9 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libisl23 0.25-1 ii libmpc3 1.2.1-2 ii libmpfr6 4.1.0-3 ii libstdc++612.2.0-9 ii zlib1g1:1.2.11.dfsg-4.1 gcc-riscv64-unknown-elf recommends no packages. gcc-riscv64-unknown-elf suggests no packages. -- no debconf information
Bug#1025210: ITP: rtlamr -- RTL-SDR receiver for smart utility meters
Hey John, Debian Developer, Amateur Radio nerd (K3XEC), and Go team member here. I use rtlamr. I'm not a very good sponsor right now, but I can step in if no one else has bandwidth; my time is a bit more limited than I'd like, and it'd be cool to have rtlamr in the repos. It'd certainly help save me time too! Give it a few days to see if anyone here has bandwidth, and if not, send me your dsc or git repo for review. On your other points: rtlamr talks to the rtlsdr via rtltcp (rtl_tcp(1)). It's a simple protocol I documented at https://hz.tools/rtl_tcp/ . I've also written a daemon for myself while learning about radio (not released yet; for a few reasons) that will serve a few radios over rtl_tcp; namely, my Ettus B210/B200mini, LimeSDR, RTL-SDR, HackRF, PlutoSDR, an airspyhf, or hilariously, another rtl_tcp endpoint (yo dawg). The hardest part of this exercise (and to be clear; it's straightforward), are two big things: - translating IQ formats; which I've done a bit of documentation on https://k3xec.com/packrat-processing-iq/ including some exemplar files to test with to build confidence in your code - accepting rtl_tcp commands (such as AGC enable, Set Gain) - which don't always translate 1:1. For instance ,some radios don't have automatic gain control, so the command isn't supported; but the client will expect it to be enabled. Other radios (like the HackRF, for instance) have multiple gain stages -- which you can kinda cobble together if you pretend to be a RTL-SDR E4k (https://hz.tools/e4k/) in the rtl_tcp header, and store the IF gain stages in memory, compute the net gain, and scale the gain from min to max -- proxying that into the real radio's gain from min to max. paultag On Wed, Nov 30, 2022 at 6:06 PM John Scott wrote: > Package: wnpp > Severity: wishlist > Owner: John Scott > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-h...@lists.debian.org, > debian...@lists.debian.org > > * Package name: rtlamr > Version : 0.9.1 > Upstream Author : Douglas Hall > * URL : https://github.com/bemasher/rtlamr > * License : AGPLv3 only > Programming Lang: Go > Description : RTL-SDR receiver for smart utility meters > > rtlamr is a program for using an RTL-SDR (and maybe other SDRs?) to > receive readings from smart utility meters. I use this software, an willing > to maintain it, and will make sure it stays in good shape. I have confirmed > that it works with commonly available meters. > > This is useful for a variety of creative purposes, such as analyzing one's > own energy usage, or even energy usage within a community, or to identify > water leaks. As far as I know, no other packages provide similar > functionality. The closest package is rtl_433, and it doesn't support these > devices. > > I'm neither DD nor DM and will need a sponsor. I will maintain this either > within the Go Team or the Ham Radio Team. I've CC'ed both of them to see if > it piques their interest or if they have a preference. > > I would really like it if a fellow ham would see about getting it to work > with an alternate SDR. > -- :wq
Bug#1025157: missing /usr/bin/lorem
Control: tag -1 + pending On Wed, 30 Nov 2022 15:20:29 +0200, David G wrote: > Version 0.3-2 and earlier included /usr/bin/lorem, which provided a > useful command-line interface to the library. > This is missing in version 0.34-1 and later. Thanks, a fixed package is on its way. (With the patch taken from https://github.com/adeolaawoyemi/Text-Lorem/pull/7 ) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#765906: ITP: coinor-bonmin -- mixed-integer nonlinear optimization solver
Control: retitle -1 ITP: coinor-bonmin -- mixed-integer nonlinear optimization solver Control: owner -1 ! Hi, I am willing to package bonmin as it is a (optional) dependency of openturns, which I maintain. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1025171: zfs-dkms FTBFS against 6.0.0-5-amd64
There isn't enough detail to be sure, but this might be the same issue I hit on sid yesterday, so adding it here. It might also count as a dkms bug for all I know. In my case, zfs-dkms fails to build against either of my currently installed kernels (5.19.0-1-amd64, 6.0.0-5-amd64), but only after updating the package dkms to version 3.0.8-2 (from 3.0.8-1). This appears to be the result of the changes to the export-CC.patch: https://sources.debian.org/patches/dkms/3.0.8-2/export-CC.patch/ The 3.0.8-2 version adds the following commands to the prepare_build() function: export CC=$CC export MAKEFLAGS="--environment-overrides" I've verified that zfs-dkms builds fine for me if I temporarily comment out the second line from /usr/sbin/dkms. A build log for a failed attempt (with the flag present) is at: https://0x0.st/o0fu.txt The log also includes a dump of the environment variables at the start of the build, from a command I added to the dkms script. Digging a little deeper, it appears that when `--environment-overrides` is set, a number of required command-line options (in particular, an -I option to add /var/lib/dkms/zfs/2.1.6/build/include in the include search path) fail to be set. I didn't manage to trace why exactly that is, but you can see both a failing and a working example (for one object file) at: https://0x0.st/o0EC.txt FWIW, it seems like the build environment dkms uses inherits whatever was present in the environment when apt was called. If this is the case, then it feels to me including the `--environment-overrides` flag has potential to make things brittle. The effect of the flag is to: "Give variables taken from the environment precedence over variables from makefiles." Any arbitrary environment variables the user may have set for their own purposes might be unexpectedly overriding important variables from the Makefile(s).
Bug#1025210: ITP: rtlamr -- RTL-SDR receiver for smart utility meters
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-de...@lists.debian.org, debian-h...@lists.debian.org, debian...@lists.debian.org * Package name : rtlamr Version : 0.9.1 Upstream Author : Douglas Hall * URL : https://github.com/bemasher/rtlamr * License : AGPLv3 only Programming Lang: Go Description : RTL-SDR receiver for smart utility meters rtlamr is a program for using an RTL-SDR (and maybe other SDRs?) to receive readings from smart utility meters. I use this software, an willing to maintain it, and will make sure it stays in good shape. I have confirmed that it works with commonly available meters. This is useful for a variety of creative purposes, such as analyzing one's own energy usage, or even energy usage within a community, or to identify water leaks. As far as I know, no other packages provide similar functionality. The closest package is rtl_433, and it doesn't support these devices. I'm neither DD nor DM and will need a sponsor. I will maintain this either within the Go Team or the Ham Radio Team. I've CC'ed both of them to see if it piques their interest or if they have a preference. I would really like it if a fellow ham would see about getting it to work with an alternate SDR. signature.asc Description: This is a digitally signed message part
Bug#1024744: grpc: fail to build on riscv64
Source: grpc Version: 1.30.2-4 Followup-For: Bug #1024744 User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: m...@debian.org, locutusofb...@debian.org, bba...@debian.org Control: tags -1 ftbfs patch Hi, > If you have time, please look into this. Sure, grpc 1.51.0 may still > need to link with atomic, but first we need to get abseil work on > riscv64. Yes, it will still need to link against -latomic. The package in its current version in unstable builds with the patch attached, I built the package locally on this architecture, so please include it in the next uploads -- as Gianfranco said, it's critical for LLVM. Regarding grpc 1.51.0 and abseil, we're looking at it in parallel and probably will submit a patch about it in the next days, so I hope that it will be ready by the time that you want to migrate to the newer version. Thanks and cheers. -- Manuel A. Fernandez Montecelo diff -Nru grpc-1.30.2/debian/changelog grpc-1.30.2/debian/changelog --- grpc-1.30.2/debian/changelog2022-09-25 18:03:42.0 + +++ grpc-1.30.2/debian/changelog2022-11-30 10:55:30.0 + @@ -1,3 +1,10 @@ +grpc (1.30.2-4+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: build without tests, try to link against -latomic + + -- Manuel A. Fernandez Montecelo Wed, 30 Nov 2022 10:55:30 + + grpc (1.30.2-4) unstable; urgency=medium * Import setuptools before distutils in setup.py (closes: #1020116). diff -Nru grpc-1.30.2/debian/rules grpc-1.30.2/debian/rules --- grpc-1.30.2/debian/rules2021-01-13 21:50:31.0 + +++ grpc-1.30.2/debian/rules2022-11-30 10:55:30.0 + @@ -25,7 +25,7 @@ # package maintainers to append LDFLAGS export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) +ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc riscv64)) export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -latomic -Wl,--as-needed endif diff -Nru grpc-1.30.2/debian/changelog grpc-1.30.2/debian/changelog --- grpc-1.30.2/debian/changelog2022-09-25 18:03:42.0 + +++ grpc-1.30.2/debian/changelog2022-11-30 10:55:30.0 + @@ -1,3 +1,10 @@ +grpc (1.30.2-4+0.riscv64.1) unreleased; urgency=medium + + * Non-maintainer upload. + * riscv64: build without tests, try to link against -latomic + + -- Manuel A. Fernandez Montecelo Wed, 30 Nov 2022 10:55:30 + + grpc (1.30.2-4) unstable; urgency=medium * Import setuptools before distutils in setup.py (closes: #1020116). diff -Nru grpc-1.30.2/debian/rules grpc-1.30.2/debian/rules --- grpc-1.30.2/debian/rules2021-01-13 21:50:31.0 + +++ grpc-1.30.2/debian/rules2022-11-30 10:55:30.0 + @@ -25,7 +25,7 @@ # package maintainers to append LDFLAGS export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) +ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc riscv64)) export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-as-needed -latomic -Wl,--as-needed endif
Bug#1024898: mozc: FTBFS on armel
In the hope that working around https://bugs.debian.org/1023525 would fix also this build failure on armel, I NMU'ed a workaround to experimental: https://salsa.debian.org/debian/mozc/-/commit/cc5301a0 It made no difference wrt the armel FTBFS, though. -- Gunnar Hjalmarsson
Bug#1025209: File .gz attached
Hi, Now the file attached is in .gz -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Site: http://phls.com.br GPG ID: 0443C450 pt_BR.po.gz Description: application/gzip OpenPGP_signature Description: OpenPGP digital signature
Bug#1025208: File is attached now
Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Site: http://phls.com.br GPG ID: 0443C450 pt_BR.po.gz Description: application/gzip OpenPGP_signature Description: OpenPGP digital signature
Bug#1025209: osk-sdl: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: osk-sdl Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Site: http://phls.com.br GPG ID: 0443C450 # Debconf translations for osk-sdl. # Copyright (C) 2022 THE osk-sdl'S COPYRIGHT HOLDER # This file is distributed under the same license as the osk-sdl package. # Paulo Henrique de Lima Santana (phls) , 2022. # msgid "" msgstr "" "Project-Id-Version: osk-sdl_0.67.1-1\n" "Report-Msgid-Bugs-To: osk-...@packages.debian.org\n" "POT-Creation-Date: 2022-08-08 09:21+\n" "PO-Revision-Date: 2022-11-30 19:36-0300\n" "Last-Translator: Paulo Henrique de Lima Santana (phls) \n" "Language-Team: Brazilian Portuguese \n" "Language: pt_BR\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n > 1)\n" "X-Generator: Gtranslator 42.0\n" #. Type: boolean #. Description #: ../templates:1001 msgid "Automatically clean crypttab?" msgstr "Remover crypttab automaticamente?" #. Type: boolean #. Description #: ../templates:1001 msgid "" "Selecting this will result in instances of 'osk-sdl-keyscript' being " "removed from /etc/crypttab on package removal." msgstr "" "Selecionar \"sim\" resultará na remoção de instâncias de \"osk-sdl-" "keyscript\" do arquivo /etc/crypttab na remoção do pacote." OpenPGP_signature Description: OpenPGP digital signature
Bug#1025138: Acknowledgement (mariadb-server-10.5: editing config files has no apparent effect on bind-address)
More diagnostics and a working work-around. One more item from the logs that went with my previous attempts: Nov 29 15:48:26 barley /etc/mysql/debian-start[109190]: /usr/bin/mysql_upgrade: unknown variable 'bind_address=192.168.1.10' In my input there were spaces around the `=`, and so I don't think the problem is that it mistook the whole line for a variable. It may indicate that `bind_address` can only be set on the command line. I create /etc/default/mariad and put MYSQLD_OPTS = --bind-address=192.168.1.10 in it. This changed the address the daemon listened on. It stopped listening on 127.0.0.1. It is unclear to me exactly how it worked. The file is sourced by the debian-start script, but systemd configuration doesn't seem to run it until after the main command that brings up the database.
Bug#1023495: transition: ruby3.1
On 2022-11-30 09:14:55 -0300, Antonio Terceiro wrote: > On Wed, Nov 23, 2022 at 05:35:18PM +0100, Sebastian Ramacher wrote: > > Hi Antonio > > > > On 2022-11-23 13:13:37 -0300, Antonio Terceiro wrote: > > > On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > > > > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > > > > Hi Lucas, > > > > > > > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > > > > After discussing with Antonio, since our deadline to finish the > > > > > > transition is approaching, we decided to already enable ruby3.1 as > > > > > > the > > > > > > default and remove ruby3.0 in a single step. > > > > > > > > > > I may be remembering wrong (it's a bit late), but isn't the change of > > > > > the > > > > > default a forward rebuild, while removal is a backward rebuild (I > > > > > mean in > > > > > the dependency tree)? If that's true, I think doing it in two steps is > > > > > easier to manage, as packages can then migrate on their own and don't > > > > > need a > > > > > lock step migration. > > > > > > > > That's correct. I'd prefer to handle this with two trackers. > > > > > > Fair enough. I will update ruby-defaults accordingly. Is it OK for us to > > > start the transition in unstable? > > > > I'd like protobuf to migrate first which is currently doing its own > > transition. Afer that, we can go ahead with the switch to 3.1 as > > default. > > protobuf migrate a few days ago, so I just uploaded ruby-defaults. > Please binNMU these packages: > > epic5 > graphviz > ignition-math > kamailio > klayout > kross-interpreters > libprelude > marisa > ngraph-gtk > notmuch > obexftp > redland-bindings > subtle > subversion > vim-command-t > weechat > xapian-bindings binNMUs scheduled Cheers -- Sebastian Ramacher
Bug#1025208: iperf3: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: iperf3 Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Site: http://phls.com.br GPG ID: 0443C450 OpenPGP_signature Description: OpenPGP digital signature
Bug#1025207: brltty: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Package: brltty Tags: l10n patch Severity: wishlist Hello, Please, Could you update the Brazilian Portuguese Translation? Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is tested with msgfmt and podebconf-display-po. Kind regards. -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Site: http://phls.com.br GPG ID: 0443C450 pt_BR.po.gz Description: application/gzip OpenPGP_signature Description: OpenPGP digital signature
Bug#1025049: asymptote: Error in shipout3
Am 30.11.2022 um 07:48 teilte picca mit: Hello, I imagine that the zzz1.asy file is my B_b3_y.asy, right ? Yes, correct. if so, something must be different between your environment and mine. I use the latest unstable with ghostscript 10 and you ? Some here. Pure Debian unstable, w/ gs 10 installed. hille@sid-amd64:~$ dpkg -l ghost* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===-=--> ii ghostscript 10.0.0~dfsg-7 amd64interpreter for the PostScri> ii ghostscript-x:amd64 10.0.0~dfsg-7 amd64interpreter for the PostScri> Is it possible to have a more informative debug message than this one ? Does [1] help you somehow? H. [1] https://tex.stackexchange.com/questions/592394/using-asymptote-for-3d-plots -- sigfault
Bug#1025176: libicu71 missing on SH4 port
Hi Jeffrey, On Wed, Nov 30, 2022 at 8:03 PM Jeffrey Walton wrote: > Package: libicu71 > Version: 71.1-1~ > Tags: sid > > I'm working on a Debian Chroot for SH4 machine. I am trying to install > GDB. The GDB installation fails: > > # apt install gdb [...] > The following packages have unmet dependencies: > libboost-regex1.74.0 : Depends: libicu71 (>= 71.1-1~) but it is not > installable > E: Unable to correct problems, you have held broken packages. Unfortunately this is correct. The sh4 architecture is only an unofficial port of Debian, a secondary architecture. It seems it can't keep up with package changes. Architectures transitioned to ICU 72.1 (version is 72.1-3 to be exact) and that's also built for sh4 [1]. Reason why boost1.74 can't pick that up seems to be numpy; build status [2] shows it needs build dependency on python3-numpy (>= 1:1.21.5-2) and libicu-dev (>= 72). The latter is OK, but stuck on the former [3]. To cut it short, digging down on the mentioned page through python3-matplotlib I see the culprit build dependency is python-greenlet [4] which fails to build on sh4. It seems it was never built there as the error is [5]: src/greenlet/greenlet.c:376:6: error: #error "greenlet needs to be ported to this platform, or taught how to detect your compiler properly." > The rub is, SH4 is not listed at > https://packages.debian.org/sid/libicu71 . The package page also shows > version 71.1-3, not 71.1-1. That's because ICU was transitioned to version 72.1 as noted above which also happened and available on sh4 [6]. > I'm not really sure how to proceed. You may locally hack the build of boost1.74 not to require Python (and drop its related binary packages). Of course, best would be to port python-greenlet to sh4 or just fix its build - can you give a helping hand to its upstream? At least this is what I see without access to any sh4 machine. As we know each other, I may check it for you if I can access that machine. But I think you are much more skilled in these things. Regards, Laszlo/GCS [1] https://buildd.debian.org/status/package.php?p=icu [2] https://buildd.debian.org/status/package.php?p=boost1.74 [3] https://buildd.debian.org/status/package.php?p=numpy [4] https://buildd.debian.org/status/package.php?p=python-greenlet [5] https://buildd.debian.org/status/fetch.php?pkg=python-greenlet=sh4=1.1.3-1=1668258039=0 [6] https://packages.debian.org/sid/libicu72
Bug#1025206: RFP: bespoke -- Software modular music synthesizer
Package: wnpp Severity: wishlist X-Debbugs-Cc: j...@joshtriplett.org * Package name: bespoke Version : 1.1.0 Upstream Author : Ryan Challinor * URL : https://www.bespokesynth.com/ https://github.com/BespokeSynth/BespokeSynth/ * License : GPLv3 Programming Lang: C++ Description : Software modular music synthesizer Bespoke is a graphical tool to synthesize music, by wiring together modular components.
Bug#1017573: python3-ulmo: autopkgtest fail with pandas 1.4
Control: reopen -1 On 13/11/2022 15:02, Rebecca N. Palmer wrote: It looks like this has been fixed somewhere other than the ulmo package (I don't know where), as the autopkgtest now passes with pandas 1.4/1.5. No it doesn't - it's being run with pandas 1.3 because pandas 1.5 declares a Breaks on this package (because of this bug).
Bug#1025141: powermgmt-base: Doesn't correctly detect we are on AC power
Hi! > It's possible that your machine can indeed be powered via USB C, new laptops > usually can. Which leads to fun like laptop that wants to be charged by a > phone -- and indeed negotiating it that way. If it was like that... do you think that USB-C would be a real USB or just for power delivery? I could atach a USB-C hub I have arround. I don't think a PD power supply will be able to supply enough power unless I unplug the two SATA HD I have plugged and the graphic card. I could try to unplug all this and try to get a PD power supply to test if you feel it would help us. > Could you perhaps provide: > cd /sys/class/power_supply && grep . */* 2>/dev/null|grep -v /uevent: ucsi-source-psy-USBC000:001/current_max:0 ucsi-source-psy-USBC000:001/current_now:0 ucsi-source-psy-USBC000:001/online:0 ucsi-source-psy-USBC000:001/type:USB ucsi-source-psy-USBC000:001/usb_type:[C] PD PD_PPS ucsi-source-psy-USBC000:001/voltage_max:0 ucsi-source-psy-USBC000:001/voltage_min:0 ucsi-source-psy-USBC000:001/voltage_now:0 Regards... -- Manty/BestiaTester -> http://manty.net
Bug#1025205: bullseye-pu: package mplayer/2:1.4+ds1-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
This updates fixes various minor crashes in mplayer, which
don't warrant a DSA by itself. I've run the PoCs against
the updated build where applicable and also tested various
random media files.
Note this isn't fixed in unstable, since mplayer FTBFSes
with ffmpeg 5.0 and won't be in bookworm (#1005899).
Cheers,
Moritz
diff -Nru mplayer-1.4+ds1/debian/changelog mplayer-1.4+ds1/debian/changelog
--- mplayer-1.4+ds1/debian/changelog2020-10-15 00:13:44.0 +0200
+++ mplayer-1.4+ds1/debian/changelog2022-11-28 21:31:43.0 +0100
@@ -1,3 +1,19 @@
+mplayer (2:1.4+ds1-1+deb11u1) bullseye; urgency=medium
+
+ * Backport the following commits:
+d19ea1ce173e95c31b0e8acbe471ea26c292be2b (CVE-2022-38850)
+58db9292a414ebf13a2cacdb3ffa967fb9036935 (CVE-2022-38851)
+2f6e69e59e2614acdde5505b049c48f80a3d0eb7 (CVE-2022-38855)
+92e0d0b1a04dfdd4ac741e0d07005e3ece2c92ca (CVE-2022-38858)
+62fe0c63cf4fba91efd29bbc85309280e1a99a47 (CVE-2022-38860)
+2622e7fbe3605a2f3b4f74900197fefeedc0d2e1 (CVE-2022-38861)
+b5e745b4bfab2835103a060094fae3c6cc1ba17d (CVE-2022-38863)
+36546389ef9fb6b0e0540c5c3f212534c34b0e94 (CVE-2022-38864)
+33d9295663c37a37216633d7e3f07e7155da6144 (CVE-2022-38865)
+373517da3bb5781726565eb3114a2697b13f00f2 (CVE-2022-38866)
+
+ -- Moritz Mühlenhoff Mon, 28 Nov 2022 21:31:43 +0100
+
mplayer (2:1.4+ds1-1) unstable; urgency=medium
* Team upload
diff -Nru
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
---
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
1970-01-01 01:00:00.0 +0100
+++
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
2022-11-28 21:31:07.0 +0100
@@ -0,0 +1,235 @@
+Backports of the following commits:
+
+d19ea1ce173e95c31b0e8acbe471ea26c292be2b (CVE-2022-38850)
+[PATCH] vd.c: sanity-check aspect adjustment
+
+58db9292a414ebf13a2cacdb3ffa967fb9036935 (CVE-2022-38851)
+PATCH] asfheader.c: Fix CHECKDEC macro.
+
+2f6e69e59e2614acdde5505b049c48f80a3d0eb7 (CVE-2022-38855)
+[PATCH] demux_mov.c: Add bounds checks to debug prints.
+
+92e0d0b1a04dfdd4ac741e0d07005e3ece2c92ca (CVE-2022-38858)
+[PATCH] demux_mov.c: robustness fixes.
+
+62fe0c63cf4fba91efd29bbc85309280e1a99a47 (CVE-2022-38860)
+[PATCH] demux_avi.c: check that sh->wf exists before using it.
+
+2622e7fbe3605a2f3b4f74900197fefeedc0d2e1 (CVE-2022-38861)
+[PATCH] mp_image.c: fix allocation size for formats with odd width.
+
+b5e745b4bfab2835103a060094fae3c6cc1ba17d (CVE-2022-38863)
+[PATCH] mpeg_hdr.c: Allocate 0xff initialized padding.
+
+36546389ef9fb6b0e0540c5c3f212534c34b0e94 (CVE-2022-38864)
+[PATCH] mpeg_hdr.c: Fix unescape code.
+
+33d9295663c37a37216633d7e3f07e7155da6144 (CVE-2022-38865)
+[PATCH] demux_avi.c: Fixup invalid audio block size.
+
+373517da3bb5781726565eb3114a2697b13f00f2 (CVE-2022-38866)
+[PATCH] aviheader.c: Fix allocation size for vprp
+
+
+--- mplayer-1.4+ds1.orig/libmpcodecs/mp_image.c
mplayer-1.4+ds1/libmpcodecs/mp_image.c
+@@ -51,8 +51,12 @@ void mp_image_alloc_planes(mp_image_t *m
+ }
+ mpi->planes[0]=av_malloc(mpi->bpp*mpi->width*(mpi->height+2)/8+
+ mpi->chroma_width*mpi->chroma_height);
+- } else
+-mpi->planes[0]=av_malloc(mpi->bpp*mpi->width*(mpi->height+2)/8);
++ } else {
++// for odd width round up to be on the safe side,
++// required in particular for planar formats
++int alloc_w = mpi->width + (mpi->width & 1);
++mpi->planes[0]=av_malloc(mpi->bpp*alloc_w*(mpi->height+2)/8);
++ }
+ if (mpi->flags_IMGFLAG_PLANAR) {
+ int bpp = IMGFMT_IS_YUVP16(mpi->imgfmt)? 2 : 1;
+ // YV12/I420/YVU9/IF09. feel free to add other planar formats here...
+--- mplayer-1.4+ds1.orig/libmpcodecs/vd.c
mplayer-1.4+ds1/libmpcodecs/vd.c
+@@ -332,7 +332,7 @@ int mpcodecs_config_vo(sh_video_t *sh, i
+ screen_size_y = screen_size_xy * sh->disp_h / sh->disp_w;
+ }
+ }
+-if (sh->aspect >= 0.01) {
++if (sh->aspect >= 0.01 && sh->aspect <= 100) {
+ int w;
+ mp_msg(MSGT_CPLAYER, MSGL_INFO, MSGTR_MovieAspectIsSet,
+sh->aspect);
+@@ -350,6 +350,8 @@ int mpcodecs_config_vo(sh_video_t *sh, i
+ } else {
+ mp_msg(MSGT_CPLAYER, MSGL_INFO, MSGTR_MovieAspectUndefined);
+
Bug#1024784: This is a bug in the Python 3.11 interpreter
FYI, this is what it goes down to: https://github.com/python/cpython/pull/99902 So this is a bug in the Python interpreter. There's a Swift patch to work around the issue: https://review.opendev.org/c/openstack/swift/+/866051 I'll probably apply it temporarily, until the Python 3.11 get the fix. Cheers, Thomas Goirand (zigo)
Bug#1025204: bullseye-pu: package speech-dispatcher/0.10.2-2+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hello, I'd like to have version 0.10.2-2+deb11u2 of speech-dispatcher uploaded to bullseye. [ Reason ] As reported on https://github.com/espeak-ng/espeak-ng/issues/1554 there is a longstanding buffer overflow issue in espeak-ng. It appears to users as artifacts in the speech that makes it sometimes less inteligible. But since they are due to a buffer overflow, the consequences could actually be way worse, notably since in the context of a screen reader using espeak-ng as speech synthesis, the data produced in the buffer comes from e.g. whatever webpage that the user is browsing, thus potential for security issues. This is not a regression from oldstable, since the bug has basically always been there. [ Impact ] If it is no included, users will still hear artifacts, and would also potentially be exposed to security issues due to the buffer overflows. [ Tests ] We made manual tests that confirmed that the change fixes the issue. We also confirmed the buffer overflow in espeak-ng's valgrind/asan CI. [ Risks ] The change is very trivial. It makes the speech synthesis processing a bit more expensive, but that will be very lightweight. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] The patch simply lowers the audio buffer size from 3s to 300ms. 3s was originally chosen so that large chunks of audio are processed at a time, but this is what is making espeak-ng overflow its synthesis buffers. The exact overflows should ideally be fixed in espeak-ng of course, but apparently this will be very involved, and it is way simpler to just make speech-dispatcher not request so large buffers. espeak-ng itself defaults to 60ms, and on Windows NVDA uses 300ms and does not suffer from buffer overflows. In practice, the overflows that we observed in https://github.com/espeak-ng/espeak-ng/issues/1554 happens with buffer around 900ms. 300ms seems a fairly safe value while being not too small so as to process not-so-small chunks of audio at a time. Samuel diff --git a/debian/changelog b/debian/changelog index 6fea892..b6120a2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +speech-dispatcher (0.10.2-2+deb11u2) bullseye; urgency=medium + + * patches/buffer_size: Reduce espeak buffer size to avoid synth artifacts. + + -- Samuel Thibault Wed, 30 Nov 2022 21:10:17 +0100 + speech-dispatcher (0.10.2-2+deb11u1) bullseye; urgency=medium * patches/generic-set-voice-name: Fix setting voice name for the generic diff --git a/debian/patches/buffer_size b/debian/patches/buffer_size new file mode 100644 index 000..2b13443 --- /dev/null +++ b/debian/patches/buffer_size @@ -0,0 +1,35 @@ +commit be4c3585ead45716b8f49300b50c30fdb6eee266 +Author: Alexander Epaneshnikov +Date: Thu Nov 24 01:41:40 2022 +0300 + +espeak: set buffer size to 300 + +this fixes #793 +ref for buffer size: https://github.com/nvaccess/nvda/blob/a6fb2392083b5fa1bae926102135ad452746ad3c/source/synthDrivers/_espeak.py#L338 + +diff --git a/config/modules/espeak-ng.conf b/config/modules/espeak-ng.conf +index d02704e9..9677bc99 100644 +--- a/config/modules/espeak-ng.conf b/config/modules/espeak-ng.conf +@@ -41,7 +41,7 @@ EspeakMaxRate 449 + # -- Internal parameters -- + + # Number of ms of audio returned by the espeak callback function. +-EspeakAudioChunkSize 3000 ++EspeakAudioChunkSize 300 + + # Maximum number of samples to buffer in playback queue. + EspeakAudioQueueMaxSize 441000 +diff --git a/config/modules/espeak.conf b/config/modules/espeak.conf +index 3abc422b..cbd453b7 100644 +--- a/config/modules/espeak.conf b/config/modules/espeak.conf +@@ -41,7 +41,7 @@ EspeakMaxRate 449 + # -- Internal parameters -- + + # Number of ms of audio returned by the espeak callback function. +-EspeakAudioChunkSize 3000 ++EspeakAudioChunkSize 300 + + # Maximum number of samples to buffer in playback queue. + EspeakAudioQueueMaxSize 441000 diff --git a/debian/patches/series b/debian/patches/series index 1f09fb7..5619c8a 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -2,3 +2,4 @@ doc-figures systemd-debian mbrola-paths generic-set-voice-name +buffer_size
Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel
Source: r-cran-glmmtmb Version: 1.1.4+dfsg-3 Severity: serious Tags: ftbfs Justification: ftbfs Dear maintainer(s), Your package failed to build from source on mipsel, where it built successfully in the past. Paul https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb=mipsel=1.1.5%2Bdfsg-1=1669057119=0 dh binary-arch --buildsystem R dh_update_autotools_config -a -O--buildsystem=R dh_autoreconf -a -O--buildsystem=R dh_auto_configure -a -O--buildsystem=R dh_auto_build -a -O--buildsystem=R dh_auto_test -a -O--buildsystem=R create-stamp debian/debhelper-build-stamp dh_testroot -a -O--buildsystem=R dh_prep -a -O--buildsystem=R dh_auto_install --destdir=debian/r-cran-glmmtmb/ -a -O--buildsystem=R I: R packages needed for DEP8: glmmtmb I: R Package: glmmTMB Version: 1.1.5 I: Building using R version 4.2.2.20221110-1 I: R API version: r-api-4.0 I: Using built-time from d/changelog: Fri, 18 Nov 2022 11:40:30 +0100 mkdir -p /<>/r-cran-glmmtmb-1.1.5\+dfsg/debian/r-cran-glmmtmb/usr/lib/R/site-library R CMD INSTALL -l /<>/r-cran-glmmtmb-1.1.5\+dfsg/debian/r-cran-glmmtmb/usr/lib/R/site-library --clean . "--built-timestamp='Fri, 18 Nov 2022 11:40:30 +0100'" * installing *source* package ‘glmmTMB’ ... files ‘inst/doc/covstruct.html’, ‘inst/doc/hacking.html’, ‘inst/doc/mcmc.html’, ‘inst/doc/miscEx.html’, ‘inst/doc/parallel.html’, ‘inst/doc/sim.html’, ‘inst/doc/troubleshooting.html’ are missing file ‘DESCRIPTION’ has the wrong MD5 checksum ** using staged installation ** libs make[1]: Entering directory '/<>/src' g++ -std=gnu++14 -I"/usr/share/R/include" -DNDEBUG -DTMBAD_FRAMEWORK -I'/usr/lib/R/site-library/TMB/include' -I'/usr/lib/R/site-library/RcppEigen/include' -fopenmp -fpic -g -O2 -ffile-prefix-map=/build/r-base-jMlmip/r-base-4.2.2.20221110=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c glmmTMB.cpp -o glmmTMB.o cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 bytes make[1]: *** [/usr/lib/R/etc/Makeconf:178: glmmTMB.o] Error 1 make[1]: Leaving directory '/<>/src' make[1]: Entering directory '/<>/src' make[1]: Leaving directory '/<>/src' ERROR: compilation failed for package ‘glmmTMB’ * removing ‘/<>/debian/r-cran-glmmtmb/usr/lib/R/site-library/glmmTMB’ dh_auto_install: error: R CMD INSTALL -l /<>/r-cran-glmmtmb-1.1.5\+dfsg/debian/r-cran-glmmtmb/usr/lib/R/site-library --clean . "--built-timestamp='Fri, 18 Nov 2022 11:40:30 +0100'" returned exit code 1 make: *** [debian/rules:4: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2
Bug#1025202: gscan2pdf: autopkgtest regression: Can't open scanners/Brother_DCP-7025
Source: gscan2pdf Version: 2.13.0-2 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of gscan2pdf the autopkgtest of gscan2pdf fails in testing when that autopkgtest is run with the binary packages of gscan2pdf from unstable. It passes when run with only packages from testing. In tabular form: passfail gscan2pdf from testing2.13.0-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gscan2pdf https://ci.debian.net/data/autopkgtest/testing/amd64/g/gscan2pdf/28805770/log.gz t/01_NetPBM.t . 1..14 ok 1 - use Gscan2pdf::NetPBM; ok 2 - get_size_from_PNM pbm 8x5 depth 8 ok 3 - get_size_from_PNM pbm 9x6 depth 8 ok 4 - get_size_from_PNM pbm 8x5 depth 16 ok 5 - get_size_from_PNM pbm 9x6 depth 16 ok 6 - get_size_from_PNM pgm 8x5 depth 8 ok 7 - get_size_from_PNM pgm 9x6 depth 8 ok 8 - get_size_from_PNM pgm 8x5 depth 16 ok 9 - get_size_from_PNM pgm 9x6 depth 16 ok 10 - get_size_from_PNM ppm 8x5 depth 8 ok 11 - get_size_from_PNM ppm 9x6 depth 8 ok 12 - get_size_from_PNM ppm 8x5 depth 16 ok 13 - get_size_from_PNM ppm 9x6 depth 16 ok 14 - 0-length PNM ok t/02_Scanner_Options_Brother_DCP-7025.t ... 1..3 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/Brother_DCP-7025: No such file or directory at t/02_Scanner_Options_Brother_DCP-7025.t line 10. Error: no options supplied at t/02_Scanner_Options_Brother_DCP-7025.t line 11. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests t/02_Scanner_Options_Brother_MFC_5100c.t .. 1..4 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/Brother_MFC_5100c: No such file or directory at t/02_Scanner_Options_Brother_MFC_5100c.t line 11. Error: no options supplied at t/02_Scanner_Options_Brother_MFC_5100c.t line 12. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 3/4 subtests t/02_Scanner_Options_Brother_MFC_8860DN.t . 1..4 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/Brother_MFC-8860DN: No such file or directory at t/02_Scanner_Options_Brother_MFC_8860DN.t line 11. Error: no options supplied at t/02_Scanner_Options_Brother_MFC_8860DN.t line 12. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 3/4 subtests t/02_Scanner_Options_brother.t 1..3 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/brother: No such file or directory at t/02_Scanner_Options_brother.t line 10. Error: no options supplied at t/02_Scanner_Options_brother.t line 11. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests t/02_Scanner_Options_canonLiDE25.t 1..3 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/canonLiDE25: No such file or directory at t/02_Scanner_Options_canonLiDE25.t line 10. Error: no options supplied at t/02_Scanner_Options_canonLiDE25.t line 11. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests t/02_Scanner_Options_canoscan_FB_630P.t ... 1..3 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/canoscan_FB_630P: No such file or directory at t/02_Scanner_Options_canoscan_FB_630P.t line 10. Error: no options supplied at t/02_Scanner_Options_canoscan_FB_630P.t line 11. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests t/02_Scanner_Options_epson1.t . 1..4 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/epson1: No such file or directory at t/02_Scanner_Options_epson1.t line 11. Error: no options supplied at t/02_Scanner_Options_epson1.t line 12. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 3/4 subtests t/02_Scanner_Options_epson_3490.t . 1..3 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/epson_3490: No such file or directory at t/02_Scanner_Options_epson_3490.t line 10. Error: no options supplied at t/02_Scanner_Options_epson_3490.t line 11. # Looks like your test exited with 2 just after 1. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/3 subtests t/02_Scanner_Options_epson_gt_2500.t .. 1..4 ok 1 - use Gscan2pdf::Scanner::Options; Can't open scanners/Epson_GT-2500: No such file or directory at t/02_Scanner_Options_epson_gt_2500.t line 11. Error: no options supplied at
Bug#1023177: sogo: CalDAV/CardDAV synchronization broken due to unexpected UTF-8 BOM in calendar and contact data
It seems that this bug was fixed in version 5.8.0 (upstream). See this commit: https://github.com/Alinto/sogo/commit/d5ad0ddf5d4a8a8b08cffc6f2a2629455c6a4362 Best regards, Timo
Bug#1025201: tkcalendar: (autopkgtest) needs update for two supported python versions: Xvfb failed to start
Source: tkcalendar Version: 1.6.1-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of tkcalendar fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 tkcalendar from testing1.6.1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/t/tkcalendar/28796449/log.gz === python3.11 === test_calendar_buttons_functions (tests.test_calendar.TestCalendar.test_calendar_buttons_functions) ... ok test_calendar_calevents (tests.test_calendar.TestCalendar.test_calendar_calevents) ... ok test_calendar_get_set (tests.test_calendar.TestCalendar.test_calendar_get_set) ... ok test_calendar_init (tests.test_calendar.TestCalendar.test_calendar_init) ... ok test_calendar_other_fcts (tests.test_calendar.TestCalendar.test_calendar_other_fcts) ... ok test_calendar_selection (tests.test_calendar.TestCalendar.test_calendar_selection) ... ok test_calendar_virtual_events (tests.test_calendar.TestCalendar.test_calendar_virtual_events) ... ok test_dateentry_drop_down (tests.test_dateentry.TestDateEntry.test_dateentry_drop_down) Check whether drop down opens on click. ... ok test_dateentry_functions (tests.test_dateentry.TestDateEntry.test_dateentry_functions) ... ok test_dateentry_get_set (tests.test_dateentry.TestDateEntry.test_dateentry_get_set) ... ok test_dateentry_init (tests.test_dateentry.TestDateEntry.test_dateentry_init) ... ok test_tooltip (tests.test_tooltip.TestTooltip.test_tooltip) ... ok test_tooltip_config (tests.test_tooltip.TestTooltipWrapper.test_tooltip_config) ... ok test_tooltipwrapper (tests.test_tooltip.TestTooltipWrapper.test_tooltipwrapper) ... ok test_tooltipwrapper_init (tests.test_tooltip.TestTooltipWrapper.test_tooltipwrapper_init) ... ok -- Ran 15 tests in 0.734s OK === python3.10 === xvfb-run: error: Xvfb failed to start autopkgtest [01:17:47]: test unittest OpenPGP_signature Description: OpenPGP digital signature
Bug#1025200: ruby-mime-types-data breaks ruby-mime-types autopkgtest: not found
Source: ruby-mime-types-data, ruby-mime-types Control: found -1 ruby-mime-types-data/3.2022.0105-1 Control: found -1 ruby-mime-types/3.4.1-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of ruby-mime-types-data the autopkgtest of ruby-mime-types fails in testing when that autopkgtest is run with the binary packages of ruby-mime-types-data from unstable. It passes when run with only packages from testing. In tabular form: passfail ruby-mime-types-data from testing3.2022.0105-1 ruby-mime-typesfrom testing3.4.1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of ruby-mime-types-data to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=ruby-mime-types-data https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-mime-types/28796478/log.gz /tmp/autopkgtest-lxc.l3u7sp3x/downtmp/wrapper.sh: 124: exec: /tmp/autopkgtest-lxc.l3u7sp3x/downtmp/build.oKA/src/debian/tests/smoke-test: not found autopkgtest [01:22:31]: test smoke-test OpenPGP_signature Description: OpenPGP digital signature
Bug#1025199: RM: kraken [armel armhf i386 s390x] -- ROM; dependency jellifish1 doesn't support 32-bit archs
Package: ftp.debian.org Severity: normal Control: tag 1016005 - moreinfo Hi ftpmaster, I noticed a couple of Debian Med packages stuck out of testing due to jellyfish1 lack of proper 32-bits support (and probably lack of big endian support too, given s390x presence in the list). To be honest, since plain jellyfish moved on with later versions, I wouldn't expect any change on the 32-bit front for the time being, for it or reverse dependencies. Please kindly remove kraken from the listed architectures. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/3, please excuse my verbosity `-on air: IQ - Until The End signature.asc Description: PGP signature
Bug#1024425: python-pysam ftbfs with python3.11 reduced severity
Nilesh Patra, on 2022-12-01: > On Tue, 29 Nov 2022 22:30:10 +0100 =?utf-8?Q?=C3=89tienne?= Mollier > wrote: > > Control: severity -1 important > > > > Hi, > > > > I just uploaded python-pysam 0.20 with python3-dev support only > > for the time being. This can be raised later on when python3.11 > > becomes the default, or a last time when python3.10 is to be > > dropped. > > Unfortunately this is a rabbit hole, and breaks other stuff, see Bug#1025116. Ouch, I haven't accounted for that. I'm suddenly somewhat concerned that packages marked "Depends" below can be potentially affected one way or another, even if not detected as such by autopkgtest or an archive rebuild (yet): $ apt rdepends python3-pysam python3-pysam Reverse Depends: Depends: python3-deeptools (>= 0.14.0) Depends: python3-seqcluster Depends: python3-bcbio Depends: yanosim Depends: umis Depends: tiddit Depends: svim Depends: sniffles Depends: sga Depends: python3-sqt Depends: python3-vcf Enhances: python-pysam-tests Depends: python3-pybedtools Depends: python3-pbcore Depends: python3-nanoget Depends: ariba (>= 0.9.1) Depends: python3-cooler Depends: pycoqc Depends: python3-pbsuite-utils Depends: pbhoney Depends: paleomix Depends: optimir Depends: nanosv Recommends: nanopolish Depends: python3-mirtop Depends: metaphlan Depends: mcaller Depends: mapdamage Depends: lumpy-sv Depends: iva Depends: insilicoseq Depends: python3-htseq Depends: gasic Depends: fitgcp Recommends: med-bio-dev Suggests: med-bio Depends: cutesv Depends: cnvkit Depends: circlator Depends: catfishq Depends: bamkit Depends: atropos > Ofcourse, there is a work around for that bug as well (i.e. just test with > default > pyvers) but, this would need fixing soonish* > > * T applied I don't expect being able to address the root issue, and I'm unsure right now how timely I would be able to bring reverse dependencies into shape to stick to python3.10 yet; possibly something to do in upcoming python sprint… Nevertheless, thanks for raising this, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/4, please excuse my verbosity. On air: Steve Unruh - challenging signature.asc Description: PGP signature
Bug#985857: RFP: libjs-bootstrap5 -- HTML, CSS and JS framework
Hi, Is there any update? Debian Bookworm will be soft-frozen in some weeks, and libjs-bootstrap5 does not exist yet. Do you plan to package the new version of Bootstrap, at least in unstable? Regards, -- Emmy D'Anello signature.asc Description: This is a digitally signed message part
Bug#1025198: RFS: memtest86+/6.00-1~bpo11+1 -- thorough real-mode memory tester
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "memtest86+": * Package name : memtest86+ Version : 6.00-1~bpo11+1 Upstream contact : Samuel Demeulemeester * URL : https://www.memtest.org/ * License : GPL-2 * Vcs : https://salsa.debian.org/debian/memtest86plus Section : misc The source builds the following binary packages: memtest86+ - thorough real-mode memory tester To access further information about this package, please visit the following URL: https://mentors.debian.net/package/memtest86+/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/memtest86+/memtest86+_6.00-1~bpo11+1.dsc Changes since the last upload: memtest86+ (6.00-1~bpo11+1) bullseye-backports; urgency=medium . * Rebuild for bullseye-backports. Regards, -- Fabio Fantoni OpenPGP_signature Description: OpenPGP digital signature
Bug#1025197: zope.exceptions: (autopkgtest) needs update for python3.11: 'DummyTB' object has no attribute 'tb_lasti'
Source: zope.exceptions
Version: 4.5-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
zope.exceptions fails in testing when that autopkgtest is run with the
binary packages of python3-defaults from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
zope.exceptionsfrom testing4.5-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/z/zope.exceptions/28796455/log.gz
=== FAILURES
===
TextExceptionFormatterTests.test_formatException_recursion_in_tb_stack
self =
testMethod=test_formatException_recursion_in_tb_stack>
def test_formatException_recursion_in_tb_stack(self):
import traceback
fmt = self._makeOne()
err = ValueError('testing')
tb_recurse = DummyTB()
tb_recurse.tb_lineno = 27
r_f = tb_recurse.tb_frame = DummyFrame()
r_f.f_lineno = 27
r_f.f_locals['__exception_formatter__'] = 1
tb = DummyTB()
tb.tb_frame = DummyFrame()
tb.tb_next = tb_recurse
lines = fmt.formatException(ValueError, err, tb)
/usr/lib/python3/dist-packages/zope/exceptions/tests/test_exceptionformatter.py:347:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/zope/exceptions/exceptionformatter.py:186:
in formatException
result.extend(traceback.format_tb(tb))
/usr/lib/python3.11/traceback.py:59: in format_tb
return extract_tb(tb, limit=limit).format()
/usr/lib/python3.11/traceback.py:74: in extract_tb
return StackSummary._extract_from_extended_frame_gen(
/usr/lib/python3.11/traceback.py:416: in _extract_from_extended_frame_gen
for f, (lineno, end_lineno, colno, end_colno) in frame_gen:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
tb = 0x7fea63c25110>
def _walk_tb_with_full_positions(tb):
# Internal version of walk_tb that yields full code positions
including
# end line and column information.
while tb is not None:
positions = _get_code_position(tb.tb_frame.f_code, tb.tb_lasti)
E AttributeError: 'DummyTB' object has no attribute 'tb_lasti'
/usr/lib/python3.11/traceback.py:353: AttributeError
=== warnings summary
===
../../../../usr/lib/python3/dist-packages/zope/exceptions/tests/test_exceptionformatter.py:869
/usr/lib/python3/dist-packages/zope/exceptions/tests/test_exceptionformatter.py:869:
PytestCollectionWarning: cannot collect test class
'TestingTracebackSupplement' because it has a __init__ constructor
(from: tests/test_exceptionformatter.py)
class TestingTracebackSupplement(object):
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info
FAILED
tests/test_exceptionformatter.py::TextExceptionFormatterTests::test_formatException_recursion_in_tb_stack
=== 1 failed, 79 passed, 1 warning in 0.18s
autopkgtest [01:18:35]: test upstream-unittest
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1025196: zfp: (autopkgtest) needs update for python3.11: No module named 'zfpy'
Source: zfp Version: 1.0.0-3 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of zfp fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 zfpfrom testing1.0.0-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/z/zfp/28796454/log.gz Testing with python3.11: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'zfpy' autopkgtest [01:18:36]: test autodep8-python3 OpenPGP_signature Description: OpenPGP digital signature
Bug#1025195: watcher-dashboard: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Source: watcher-dashboard
Version: 8.0.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
watcher-dashboard fails in testing when that autopkgtest is run with the
binary packages of python3-defaults from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
watcher-dashboard from testing8.0.0-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/w/watcher-dashboard/28796452/log.gz
Running migrations:
Applying contenttypes.0001_initial... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0001_initial... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying auth.0012_alter_user_first_name_max_length... OK
Applying sessions.0001_initial... OK
Destroying test database for alias 'default'
('file:memorydb_default?mode=memory=shared')...
Traceback (most recent call last):
File "/tmp/autopkgtest-lxc.2p5z09al/downtmp/build.k2W/src/manage.py",
line 23, in
execute_from_command_line(sys.argv)
File
"/usr/lib/python3/dist-packages/django/core/management/__init__.py",
line 419, in execute_from_command_line
utility.execute()
File
"/usr/lib/python3/dist-packages/django/core/management/__init__.py",
line 413, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"/usr/lib/python3/dist-packages/django/core/management/commands/test.py",
line 23, in run_from_argv
super().run_from_argv(argv)
File "/usr/lib/python3/dist-packages/django/core/management/base.py",
line 354, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib/python3/dist-packages/django/core/management/base.py",
line 398, in execute
output = self.handle(*args, **options)
^
File
"/usr/lib/python3/dist-packages/django/core/management/commands/test.py",
line 55, in handle
failures = test_runner.run_tests(test_labels)
^^
File "/usr/lib/python3/dist-packages/django/test/runner.py", line
728, in run_tests
self.run_checks(databases)
File "/usr/lib/python3/dist-packages/django/test/runner.py", line
665, in run_checks
call_command('check', verbosity=self.verbosity, databases=databases)
File
"/usr/lib/python3/dist-packages/django/core/management/__init__.py",
line 181, in call_command
return command.execute(*args, **defaults)
^^
File "/usr/lib/python3/dist-packages/django/core/management/base.py",
line 398, in execute
output = self.handle(*args, **options)
^
File
"/usr/lib/python3/dist-packages/django/core/management/commands/check.py",
line 63, in handle
self.check(
File "/usr/lib/python3/dist-packages/django/core/management/base.py",
line 419, in check
all_issues = checks.run_checks(
^^
File "/usr/lib/python3/dist-packages/django/core/checks/registry.py",
line 76, in run_checks
new_errors = check(app_configs=app_configs, databases=databases)
^^^
File "/usr/lib/python3/dist-packages/django/core/checks/urls.py",
line 13, in check_url_config
return check_resolver(resolver)
File "/usr/lib/python3/dist-packages/django/core/checks/urls.py",
line 23, in check_resolver
return check_method()
^^
File
Bug#1025194: tpot: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Source: tpot Version: 0.11.7+dfsg-4 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of tpot fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 tpot from testing0.11.7+dfsg-4 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/t/tpot/28796450/log.gz == ERROR: Assert that get_params returns the exact dictionary of parameters used by TPOT. -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/tmp/autopkgtest-lxc.aob2cy93/downtmp/autopkgtest_tmp/python3.11/tests/tpot_tests.py", line 480, in test_get_params initializer = inspect.getargspec(TPOTBase.__init__) ^^ AttributeError: module 'inspect' has no attribute 'getargspec' -- Ran 249 tests in 50.080s OpenPGP_signature Description: OpenPGP digital signature
Bug#1025193: tagpy: (autopkgtest) needs update for python3.11: initialization of _tagpy raised unreported exception
Source: tagpy Version: 2013.1-9 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of tagpy fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 tagpy from testing2013.1-9 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/t/tagpy/28796448/log.gz Testing with python3.11: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/tagpy/__init__.py", line 24, in import _tagpy SystemError: initialization of _tagpy raised unreported exception autopkgtest [01:17:35]: test autodep8-python3 OpenPGP_signature Description: OpenPGP digital signature
Bug#1025192: sublime-music: (autopkgtest) needs update for python3.11: mutable default for field current_album_search_query is not allowed
Source: sublime-music
Version: 0.11.16-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
sublime-music fails in testing when that autopkgtest is run with the
binary packages of python3-defaults from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
sublime-music from testing0.11.16-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/s/sublime-music/28796444/log.gz
=== python3.11 ===
= test session starts
==
platform linux -- Python 3.11.0+, pytest-7.1.2, pluggy-1.0.0+repack --
/usr/bin/python3.11
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.1ezw684c/downtmp/autopkgtest_tmp,
configfile: setup.cfg
collecting ... collected 0 items / 12 errors
ERRORS
ERROR collecting tests/config_test.py
_
tests/config_test.py:6: in
from sublime_music.adapters import ConfigurationStore
/usr/lib/python3/dist-packages/sublime_music/adapters/__init__.py:11: in
from .manager import AdapterManager, DownloadProgress, Result,
SearchResult
/usr/lib/python3/dist-packages/sublime_music/adapters/manager.py:33: in
from sublime_music.config import ProviderConfiguration
/usr/lib/python3/dist-packages/sublime_music/config.py:12: in
from .ui.state import UIState
/usr/lib/python3/dist-packages/sublime_music/ui/state.py:41: in
@dataclass
/usr/lib/python3.11/dataclasses.py:1220: in dataclass
return wrap(cls)
/usr/lib/python3.11/dataclasses.py:1210: in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash,
/usr/lib/python3.11/dataclasses.py:958: in _process_class
cls_fields.append(_get_field(cls, name, type, kw_only))
/usr/lib/python3.11/dataclasses.py:815: in _get_field
raise ValueError(f'mutable default {type(f.default)} for field '
E ValueError: mutable default 'sublime_music.adapters.adapter_base.AlbumSearchQuery'> for field
current_album_search_query is not allowed: use default_factory
ERROR collecting tests/config_test.py
_
tests/config_test.py:6: in
from sublime_music.adapters import ConfigurationStore
/usr/lib/python3/dist-packages/sublime_music/adapters/__init__.py:11: in
from .manager import AdapterManager, DownloadProgress, Result,
SearchResult
/usr/lib/python3/dist-packages/sublime_music/adapters/manager.py:33: in
from sublime_music.config import ProviderConfiguration
/usr/lib/python3/dist-packages/sublime_music/config.py:12: in
from .ui.state import UIState
/usr/lib/python3/dist-packages/sublime_music/ui/state.py:41: in
@dataclass
/usr/lib/python3.11/dataclasses.py:1220: in dataclass
return wrap(cls)
/usr/lib/python3.11/dataclasses.py:1210: in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash,
/usr/lib/python3.11/dataclasses.py:958: in _process_class
cls_fields.append(_get_field(cls, name, type, kw_only))
/usr/lib/python3.11/dataclasses.py:815: in _get_field
raise ValueError(f'mutable default {type(f.default)} for field '
E ValueError: mutable default 'sublime_music.adapters.adapter_base.AlbumSearchQuery'> for field
current_album_search_query is not allowed: use default_factory
ERROR collecting tests/adapter_tests/adapter_manager_tests.py
_
tests/adapter_tests/adapter_manager_tests.py:6: in
from sublime_music.adapters import (
/usr/lib/python3/dist-packages/sublime_music/adapters/__init__.py:11: in
from .manager import AdapterManager, DownloadProgress, Result,
SearchResult
/usr/lib/python3/dist-packages/sublime_music/adapters/manager.py:33: in
from sublime_music.config import ProviderConfiguration
/usr/lib/python3/dist-packages/sublime_music/config.py:12: in
from .ui.state import UIState
/usr/lib/python3/dist-packages/sublime_music/ui/state.py:41: in
@dataclass
/usr/lib/python3.11/dataclasses.py:1220: in dataclass
Bug#1021857: CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 (message):
btw, do you know what caused this in cmake? (seems that it is caused by a new cmake version). (or not to make sure that all binaries aren't exported?) thanks Sylvestre Le 28/11/2022 à 12:07, Mathieu Malaterre a écrit : Control: found 1021857 1:14.0.6-2 -- Found LibXml2: /usr/lib/x86_64-linux-gnux32/libxml2.so (found version "2.9.14") CMake Error at /usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake:1598 (message): The imported target "mlir-tblgen" references the file "/usr/lib/llvm-14/bin/mlir-tblgen" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/llvm-14/lib/cmake/llvm/LLVMExports.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/llvm-14/cmake/LLVMConfig.cmake:323 (include) openvdb_ax/openvdb_ax/CMakeLists.txt:105 (find_package) * https://buildd.debian.org/status/fetch.php?pkg=openvdb=x32=10.0.0-7=1669627540=0 ___ Pkg-llvm-team mailing list pkg-llvm-t...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team
Bug#1025191: RM: cyphesis-cpp/experimental -- ROM; unstable upstream, unsuitable for Debian
Package: ftp.debian.org Severity: normal Hello, This is a follow-up to [1], apologies for not mentioning experimental in that report. Thanks! -Olek [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024116
Bug#1025190: sqlitedict: (autopkgtest) needs update for python3.11: AssertionError
Source: sqlitedict
Version: 2.0.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
sqlitedict fails in testing when that autopkgtest is run with the binary
packages of python3-defaults from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
sqlitedict from testing2.0.0-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/s/sqlitedict/28796443/log.gz
=== FAILURES
===
TablenamesTest.test_tablenames
self =
def test_tablenames(self):
fname = norm_file('tests/db/tablenames-test-1.sqlite')
SqliteDict(fname)
self.assertEqual(SqliteDict.get_tablenames(fname), ['unnamed'])
fname = norm_file('tests/db/tablenames-test-2.sqlite')
with SqliteDict(fname, tablename='table1'):
self.assertEqual(SqliteDict.get_tablenames(fname), ['table1'])
E AssertionError: Lists differ: ['table1', 'table2'] != ['table1']
E E First list contains 1 additional elements.
E First extra element 1:
E 'table2'
E E - ['table1', 'table2']
E + ['table1']
tests/test_core.py:293: AssertionError
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1025189: spyder: (autopkgtest) needs update for python3.11: Signal sig_response(QString,PyQt_PyObject) not emitted after 30000 ms
Source: spyder
Version: 5.3.3+dfsg-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
spyder fails in testing when that autopkgtest is run with the binary
packages of python3-defaults from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
spyder from testing5.3.3+dfsg-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/s/spyder/28806955/log.gz
=== FAILURES
===
__ test_plugin_first_response_request
__
qtbot_module =
completion_receiver =
(0x7fb1231c7a30>,
object at 0x7fb11dcc7910>)
@pytest.mark.order(1)
def test_plugin_first_response_request(qtbot_module,
completion_receiver):
completion, receiver = completion_receiver
# Parameters to perform a textDocument/didOpen request
params = {
'file': 'test2.py',
'language': 'python',
'version': 2,
'text': "# This is some text with some classe\nimport os\n\n",
'response_instance': receiver,
'offset': 1,
'diff': '',
'selection_start': 0,
'selection_end': 0,
'codeeditor': receiver,
'requires_response': False
}
with qtbot_module.waitSignal(receiver.sig_response,
timeout=3) as blocker:
completion.send_request(
'python', CompletionRequestTypes.DOCUMENT_DID_OPEN, params)
params = {
'file': 'test2.py',
'line': 1,
'column': 8,
'offset': 43,
'diff': '',
'response_instance': receiver,
'codeeditor': receiver,
'requires_response': True
}
with qtbot_module.waitSignal(receiver.sig_response,
timeout=3) as blocker:
completion.send_request(
'python', CompletionRequestTypes.DOCUMENT_HOVER, params)
_, response = blocker.args
assert len(response['params']) > 0
E AssertionError: assert 0 > 0
E+ where 0 = len('')
spyder/plugins/completion/tests/test_plugin.py:253: AssertionError
___ test_get_signature[lsp_provider]
___
lsp_client_and_completion =
(object at 0x7fb11da1eb00>,
object at 0x7fb11da1ed40>)
qtbot =
@pytest.mark.order(3)
def test_get_signature(lsp_client_and_completion, qtbot):
client, completion = lsp_client_and_completion
# Parameters to perform a textDocument/didChange request
params = {
'file': 'test.py',
'language': 'python',
'version': 1,
'text': "import os\nos.walk(\n",
'codeeditor': completion,
'requires_response': False
}
# Perform the request
with qtbot.waitSignal(completion.sig_response, timeout=3):
E pytestqt.exceptions.TimeoutError: Signal
sig_response(QString,PyQt_PyObject) not emitted after 3 ms
spyder/plugins/completion/providers/languageserver/tests/test_client.py:76:
TimeoutError
__ test_get_completions[lsp_provider]
__
lsp_client_and_completion =
(object at 0x7fb11da1eb00>,
object at 0x7fb11da1ed40>)
qtbot =
@pytest.mark.order(3)
def test_get_completions(lsp_client_and_completion, qtbot):
client, completion = lsp_client_and_completion
# Parameters to perform a textDocument/didChange request
params = {
'file': 'test.py',
'language': 'python',
'version': 1,
'text': "import o",
'codeeditor': completion,
'requires_response': False
}
# Perform the request
with qtbot.waitSignal(completion.sig_response, timeout=3):
E pytestqt.exceptions.TimeoutError: Signal
sig_response(QString,PyQt_PyObject) not emitted after 3 ms
Bug#1025188: spyder-unittest: (autopkgtest) needs update for python3.11: AssertionError
Source: spyder-unittest
Version: 0.5.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
spyder-unittest fails in testing when that autopkgtest is run with the
binary packages of python3-defaults from unstable. It passes when run
with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
spyder-unittestfrom testing0.5.1-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/s/spyder-unittest/28796442/log.gz
=== FAILURES
===
__ test_run_tests_using_unittest_and_display_results
___
qtbot =
widget = 0x7fd5120a29e0>
tmpdir =
local('/tmp/pytest-of-debci/pytest-0/test_run_tests_using_unittest_0')
monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fd5120bba10>
def test_run_tests_using_unittest_and_display_results(
qtbot, widget, tmpdir, monkeypatch):
"""Basic check."""
os.chdir(tmpdir.strpath)
testfilename = tmpdir.join('test_foo.py').strpath
with open(testfilename, 'w') as f:
f.write("import unittest\n"
"class MyTest(unittest.TestCase):\n"
" def test_ok(self): self.assertEqual(1+1, 2)\n"
" def test_fail(self): self.assertEqual(1+1, 3)\n")
MockQMessageBox = Mock()
monkeypatch.setattr('spyder_unittest.widgets.unittestgui.QMessageBox',
MockQMessageBox)
config = Config(wdir=tmpdir.strpath, framework='unittest',
coverage=False)
with qtbot.waitSignal(widget.sig_finished, timeout=1,
raising=True):
widget.run_tests(config)
MockQMessageBox.assert_not_called()
model = widget.testdatamodel
assert model.rowCount() == 2
assert model.index(0, 0).data(Qt.DisplayRole) == 'FAIL'
assert model.index(0, 1).data(Qt.DisplayRole) == 't.M.test_fail'
E AssertionError: assert 't.M.test_f.test_fail' == 't.M.test_fail'
E - t.M.test_fail
E + t.M.test_f.test_fail
E ? +++
/tmp/autopkgtest-lxc.6hcp6lhp/downtmp/build.hJ9/src/spyder_unittest/widgets/tests/test_unittestgui.py:210:
AssertionError
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1025187: golang-github-crewjam-saml: CVE-2022-41912: Signature bypass via multiple Assertion elements
Source: golang-github-crewjam-saml Version: 0.4.6-3 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for golang-github-crewjam-saml. CVE-2022-41912[0]: | The crewjam/saml go library prior to version 0.4.9 is vulnerable to an | authentication bypass when processing SAML responses containing | multiple Assertion elements. This issue has been corrected in version | 0.4.9. There are no workarounds other than upgrading to a fixed | version. 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-2022-41912 https://www.cve.org/CVERecord?id=CVE-2022-41912 [1] https://github.com/crewjam/saml/security/advisories/GHSA-j2jp-wvqg-wc2g Regards, Salvatore
Bug#1025186: installation-reports: Successful Installation Report
Package: installation-reports Severity: wishlist X-Debbugs-Cc: spenserpulleyk...@yahoo.com (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: USB Image version: https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-11.5.0-i386-netinst.iso 11/30/2022 Date: Machine: Asus EeePc Eee-1005HA Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Please make sure that any installation logs that you think would be useful are attached to this report. Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u5" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux eee 5.10.0-18-686 #1 SMP Debian 5.10.140-1 (2022-09-02) i686 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GSE Express Memory Controller Hub [8086:27ac] (rev 03) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8340] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8340] lspci -knn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:8340] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition Audio Controller [8086:27d8] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:83ce] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: Kernel modules: snd_hda_intel lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 2 [8086:27d2] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 4 [8086:27d6] (rev 02) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:830f] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:830f] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:830f] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:830f] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:830f] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2) lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:830f] lspci -knn: Kernel modules: intel_rng lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 82801GBM/GHM (ICH7-M Family) SATA Controller [AHCI mode] [8086:27c5] (rev 02) lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:830f] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel
Bug#1025185: sphinx: (autopkgtest) needs update for python3.11: AssertionError
Source: sphinx Version: 4.5.0-4 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of sphinx fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 sphinx from testing4.5.0-4 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/s/sphinx/28796439/log.gz === FAILURES === _ test_restify _ def test_restify(): assert restify(int) == ":py:class:`int`" assert restify(int, "smart") == ":py:class:`int`" assert restify(str) == ":py:class:`str`" assert restify(str, "smart") == ":py:class:`str`" assert restify(None) == ":py:obj:`None`" assert restify(None, "smart") == ":py:obj:`None`" assert restify(Integral) == ":py:class:`numbers.Integral`" assert restify(Integral, "smart") == ":py:class:`~numbers.Integral`" assert restify(Struct) == ":py:class:`struct.Struct`" assert restify(Struct, "smart") == ":py:class:`~struct.Struct`" assert restify(TracebackType) == ":py:class:`types.TracebackType`" assert restify(TracebackType, "smart") == ":py:class:`~types.TracebackType`" > assert restify(Any) == ":py:obj:`~typing.Any`" E AssertionError: assert ':py:class:`~typing.Any`' == ':py:obj:`~typing.Any`' E - :py:obj:`~typing.Any` E ? ^^^ E + :py:class:`~typing.Any` E ? ^ tests/test_util_typing.py:55: AssertionError OpenPGP_signature Description: OpenPGP digital signature
Bug#1025184: sphinx-testing: (autopkgtest) needs update for python3.11: invalid mode: 'U'
Source: sphinx-testing Version: 1.0.1-0.1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of sphinx-testing fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 sphinx-testing from testing1.0.1-0.1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/s/sphinx-testing/28796440/log.gz /usr/lib/python3/dist-packages/babel/messages/catalog.py:13: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13 from cgi import parse_header test_abspath (test_path.TestPath.test_abspath) ... ok test_basename (test_path.TestPath.test_basename) ... ok test_copytree (test_path.TestPath.test_copytree) ... ok test_dirname (test_path.TestPath.test_dirname) ... ok test_exists (test_path.TestPath.test_exists) ... ok test_instantiate (test_path.TestPath.test_instantiate) ... ok test_isabs (test_path.TestPath.test_isabs) ... ok test_isdir (test_path.TestPath.test_isdir) ... ok test_isfile (test_path.TestPath.test_isfile) ... ok test_islink (test_path.TestPath.test_islink) ... ok test_ismount (test_path.TestPath.test_ismount) ... ok test_jonpath (test_path.TestPath.test_jonpath) ... ok test_listdir (test_path.TestPath.test_listdir) ... ok test_makedirs (test_path.TestPath.test_makedirs) ... ok test_move (test_path.TestPath.test_move) ... ok test_read_bytes (test_path.TestPath.test_read_bytes) ... ok test_read_text (test_path.TestPath.test_read_text) ... ERROR test_rmtree (test_path.TestPath.test_rmtree) ... ok test_suffix (test_path.TestPath.test_suffix) ... ok test_unlink (test_path.TestPath.test_unlink) ... ok test_utime (test_path.TestPath.test_utime) ... ok test_write_bytes (test_path.TestPath.test_write_bytes) ... /tmp/autopkgtest-lxc.yr0akpjp/downtmp/autopkgtest_tmp/tests/test_path.py:226: ResourceWarning: unclosed file <_io.BufferedReader name='/tmp/tmpkuvdvjne/test.file'> text = open(filename, 'rb').read() ResourceWarning: Enable tracemalloc to get the object allocation traceback ok test_write_text (test_path.TestPath.test_write_text) ... /tmp/autopkgtest-lxc.yr0akpjp/downtmp/autopkgtest_tmp/tests/test_path.py:210: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/tmp4l6oluer/test.file' mode='r' encoding='UTF-8'> text = open(filename).read() ResourceWarning: Enable tracemalloc to get the object allocation traceback ok test_mkdtemp (test_tmpdir.TestTmpdir.test_mkdtemp) ... ok test_with_tmpdir (test_tmpdir.TestTmpdir.test_with_tmpdir) ... ok test_TestApp (test_util.TestSphinxTesting.test_TestApp) ... /usr/lib/python3/dist-packages/sphinx/util/images.py:4: DeprecationWarning: 'imghdr' is deprecated and slated for removal in Python 3.13 import imghdr ok test_TestApp_cleanup (test_util.TestSphinxTesting.test_TestApp_cleanup) ... ok test_TestApp_cleanup_when_cleanup_on_errors (test_util.TestSphinxTesting.test_TestApp_cleanup_when_cleanup_on_errors) ... ok test_TestApp_when_copy_srcdir_to_tmpdir (test_util.TestSphinxTesting.test_TestApp_when_copy_srcdir_to_tmpdir) ... ERROR test_TestApp_when_create_new_srcdir (test_util.TestSphinxTesting.test_TestApp_when_create_new_srcdir) ... ERROR test_TestApp_when_srcdir_and_create_new_srcdir_conflict (test_util.TestSphinxTesting.test_TestApp_when_srcdir_and_create_new_srcdir_conflict) ... ok test_TestApp_when_srcdir_is_None (test_util.TestSphinxTesting.test_TestApp_when_srcdir_is_None) ... ok test_TestApp_when_srcdir_specified (test_util.TestSphinxTesting.test_TestApp_when_srcdir_specified) ... ERROR test_with_app (test_util.TestSphinxTesting.test_with_app) ... ok test_with_app_bad_args (test_util.TestSphinxTesting.test_with_app_bad_args) ... ok test_with_app_return_value (test_util.TestSphinxTesting.test_with_app_return_value) ... ok test_with_app_write_docstring (test_util.TestSphinxTesting.test_with_app_write_docstring) ... ERROR test_with_app_write_docstring_by_name
Bug#1025183: silx: (autopkgtest) needs update for python3.11: Segmentation fault
Source: silx Version: 1.1.0+dfsg-3 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of silx fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 silx from testing1.1.0+dfsg-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/s/silx/28796438/log.gz Testing with python3.11: = test session starts == platform linux -- Python 3.11.0+, pytest-7.1.2, pluggy-1.0.0+repack rootdir: /tmp/autopkgtest-lxc.btdfxoen/downtmp/autopkgtest_tmp plugins: xvfb-2.0.0 collected 1796 items app/test/test_convert.py [ 0%] app/view/test/test_launcher.py . [ 0%] app/view/test/test_view.py FF [ 2%] gui/data/test/test_arraywidget.py sFFF [ 3%] gui/data/test/test_dataviewer.py FFF [ 5%] FFF [ 5%] gui/data/test/test_numpyaxesselector.py F [ 6%] gui/data/test/test_textformatter.py [ 7%] gui/dialog/test/test_colormapdialog.py FEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFE [ 8%] FEFE [ 8%] gui/dialog/test/test_datafiledialog.py F [ 10%] FF [ 10%] gui/dialog/test/test_imagefiledialog.py Fatal Python error: Segmentation fault Current thread 0x7fb29d541040 (most recent call first): File "/usr/lib/python3/dist-packages/silx/gui/utils/testutils.py", line 334 in qWait File "/usr/lib/python3/dist-packages/silx/gui/utils/testutils.py", line 393 in qWaitForDestroy File "/usr/lib/python3/dist-packages/silx/gui/dialog/test/test_imagefiledialog.py", line 124 in _deleteDialog File "/usr/lib/python3/dist-packages/silx/gui/dialog/test/test_imagefiledialog.py", line 151 in tearDown File "/usr/lib/python3.11/unittest/case.py", line 584 in _callTearDown File "/usr/lib/python3.11/unittest/case.py", line 626 in run File "/usr/lib/python3.11/unittest/case.py", line 678 in __call__ File "/usr/lib/python3/dist-packages/_pytest/unittest.py", line 327 in runtest File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 166 in pytest_runtest_call File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 338 in from_call File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 258 in call_runtest_hook File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 219 in call_and_report File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 130 in runtestprotocol File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 111 in pytest_runtest_protocol File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/main.py", line 347 in pytest_runtestloop File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__ File "/usr/lib/python3/dist-packages/_pytest/main.py", line 322 in _main File "/usr/lib/python3/dist-packages/_pytest/main.py", line 268 in wrap_session File "/usr/lib/python3/dist-packages/_pytest/main.py", line 315 in pytest_cmdline_main File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in _multicall File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec File
Bug#1025180: qiskit-aer: (autopkgtest) needs update for python3.11: No module named 'qiskit.transpiler.passes.routing.cython.stochastic_swap.utils'
Source: qiskit-aer
Version: 0.4.1-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
qiskit-aer fails in testing when that autopkgtest is run with the binary
packages of python3-defaults from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
qiskit-aer from testing0.4.1-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/q/qiskit-aer/28796434/log.gz
Testing with python3.11:
/usr/lib/python3/dist-packages/qiskit/validation/fields/custom.py:76:
DeprecationWarning: `np.float` is a deprecated alias for the builtin
`float`. To silence this warning, use `float` by itself. Doing this will
not modify any behavior and is safe. If you specifically wanted the
numpy scalar type, use `np.float64` here.
Deprecated in NumPy 1.20; for more details and guidance:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
numpy.integer, numpy.float,
/usr/lib/python3/dist-packages/qiskit/__init__.py:53: RuntimeWarning:
Could not import the Aer provider from the qiskit-aer package. Install
qiskit-aer or check your installation.
warnings.warn('Could not import the Aer provider from the qiskit-aer '
/usr/lib/python3/dist-packages/qiskit/__init__.py:60: RuntimeWarning:
Could not import the IBMQ provider from the qiskit-ibmq-provider
package. Install qiskit-ibmq-provider or check your installation.
warnings.warn('Could not import the IBMQ provider from the '
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/qiskit/__init__.py", line 67, in
from qiskit.execute import execute
File "/usr/lib/python3/dist-packages/qiskit/execute.py", line 24, in
from qiskit.compiler import transpile, assemble
File "/usr/lib/python3/dist-packages/qiskit/compiler/__init__.py",
line 35, in
from .transpile import transpile
File "/usr/lib/python3/dist-packages/qiskit/compiler/transpile.py",
line 16, in
from qiskit.transpiler import Layout, CouplingMap
File "/usr/lib/python3/dist-packages/qiskit/transpiler/__init__.py",
line 76, in
from .transpile_circuit import transpile_circuit
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/transpile_circuit.py",
line 17, in
from qiskit.transpiler.preset_passmanagers import
(level_0_pass_manager,
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/preset_passmanagers/__init__.py",
line 31, in
from .level0 import level_0_pass_manager
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/preset_passmanagers/level0.py",
line 23, in
from qiskit.transpiler.passes import Unroller
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/passes/__init__.py",
line 116, in
from .routing import BasicSwap
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/passes/routing/__init__.py",
line 19, in
from .stochastic_swap import StochasticSwap
File
"/usr/lib/python3/dist-packages/qiskit/transpiler/passes/routing/stochastic_swap.py",
line 30, in
from .cython.stochastic_swap.utils import nlayout_from_layout
ModuleNotFoundError: No module named
'qiskit.transpiler.passes.routing.cython.stochastic_swap.utils'
autopkgtest [01:17:01]: test autodep8-python3
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1025182: rich: (autopkgtest) needs update for python3.11: AssertionError
Source: rich
Version: 12.4.4-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
rich fails in testing when that autopkgtest is run with the binary
packages of python3-defaults from unstable. It passes when run with only
packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
rich from testing12.4.4-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rich/28796437/log.gz
=== FAILURES
===
__ test_inspect_text
___
@skip_pypy3
def test_inspect_text():
expected = (
"╭ ─╮\n"
"│ str(object='') -> str │\n"
"│ str(bytes_or_buffer[, encoding[, errors]]) -> │\n"
"│ str│\n"
"││\n"
"│ 33 attribute(s) not shown. Run │\n"
"│ inspect(inspect) for options. │\n"
"╰╯\n"
)
print(repr(expected))
assert expected == render("Hello")
E AssertionError: assert '╭───...──╯\n' ==
'╭───...──╯\n'
E Skipping 248 identical leading characters in diff, use -v to show
E Skipping 140 identical trailing characters in diff, use -v to show
E│
E - │ 34 attribut
E ?^
E + │ 33 attribut
E ?^
tests/test_inspect.py:102: AssertionError
- Captured stdout call
-
"╭ ─╮\n│ str(object='') ->
str │\n│ str(bytes_or_buffer[, encoding[,
errors]]) -> │\n│ str│\n│
│\n│ 33 attribute(s) not
shown. Run │\n│ inspect(inspect) for options.
│\n╰╯\n"
test_inspect_builtin_function
_
@skip_pypy3
def test_inspect_builtin_function():
expected = (
"╭── ───╮\n"
"│ def print(...) │\n"
"││\n"
"│ print(value, ..., sep=' ', end='\\n', │\n"
"│ file=sys.stdout, flush=False) │\n"
"││\n"
"│ 29 attribute(s) not shown. Run │\n"
"│ inspect(inspect) for options. │\n"
"╰╯\n"
)
assert expected == render(print)
E AssertionError: assert '╭── ...──╯\n' ==
'╭── ...──╯\n'
E Skipping 53 identical leading characters in diff, use -v to show
E + def print(...) │
E - def print(*args, sep=' ', end='\n', file=None, │
E - │ flush=False): │
E ││
E - │ Prints the values to a stream, or to │
E - │ sys.stdout by default. │...
E E ...Full output truncated (10 lines hidden), use
'-vv' to show
tests/test_inspect.py:142: AssertionError
__ test_inspect_integer_with_methods
___
@skip_py36
@skip_py37
@skip_py38
@skip_py39
def test_inspect_integer_with_methods():
expected = (
"╭ ─╮\n"
"│ int([x]) -> integer│\n"
"│ int(x, base=10) -> integer │\n"
"│
Bug#1025181: qiskit-ibmq-provider: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'
Source: qiskit-ibmq-provider
Version: 0.4.6-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults
Dear maintainer(s),
We are in the transition of adding python3.11 as a supported Python
version [0]. With a recent upload of python3-defaults the autopkgtest of
qiskit-ibmq-provider fails in testing when that autopkgtest is run with
the binary packages of python3-defaults from unstable. It passes when
run with only packages from testing. In tabular form:
passfail
python3-defaults from testing3.10.6-3
qiskit-ibmq-provider from testing0.4.6-4
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of python3-defaults
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists
what's new in Python3.11, it may help to identify what needs to be updated.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults
https://ci.debian.net/data/autopkgtest/testing/amd64/q/qiskit-ibmq-provider/28796435/log.gz
Testing with python3.11:
/usr/lib/python3/dist-packages/qiskit/validation/fields/custom.py:76:
DeprecationWarning: `np.float` is a deprecated alias for the builtin
`float`. To silence this warning, use `float` by itself. Doing this will
not modify any behavior and is safe. If you specifically wanted the
numpy scalar type, use `np.float64` here.
Deprecated in NumPy 1.20; for more details and guidance:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
numpy.integer, numpy.float,
/usr/lib/python3/dist-packages/qiskit/__init__.py:53: RuntimeWarning:
Could not import the Aer provider from the qiskit-aer package. Install
qiskit-aer or check your installation.
warnings.warn('Could not import the Aer provider from the qiskit-aer '
/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/rest/validation.py:35:
RemovedInMarshmallow4Warning: The 'missing' argument to fields is
deprecated. Use 'load_default' instead.
_status = String(required=False, missing=None)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/qiskit/__init__.py", line 58, in
from qiskit.providers.ibmq import IBMQ
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/__init__.py", line
20, in
from .ibmqfactory import IBMQFactory
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/ibmqfactory.py",
line 21, in
from .accountprovider import AccountProvider
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/accountprovider.py",
line 26, in
from .api.clients import AccountClient
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/__init__.py",
line 18, in
from .account import AccountClient
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/account.py",
line 35, in
from .websocket import WebsocketClient
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/websocket.py",
line 113, in
class WebsocketClient(BaseClient):
File
"/usr/lib/python3/dist-packages/qiskit/providers/ibmq/api/clients/websocket.py",
line 126, in WebsocketClient
@asyncio.coroutine
^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you
mean: 'coroutines'?
autopkgtest [01:16:47]: test autodep8-python3
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1025179: pyvows: (autopkgtest) needs update for python3.11: No module named 'gevent._gevent_c_hub_local'
Source: pyvows Version: 3.0.0-3 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of pyvows fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 pyvows from testing3.0.0-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyvows/28796433/log.gz === python3.11 === Traceback (most recent call last): File "", line 198, in _run_module_as_main File "", line 88, in _run_code File "/usr/lib/python3/dist-packages/pyvows/__main__.py", line 12, in sys.exit(main()) ^^ File "/usr/lib/python3/dist-packages/pyvows/cli.py", line 184, in main result = run( File "/usr/lib/python3/dist-packages/pyvows/cli.py", line 136, in run from pyvows.core import Vows File "/usr/lib/python3/dist-packages/pyvows/core.py", line 20, in from pyvows.decorators import _batch, async_topic, capture_error, skip_if File "/usr/lib/python3/dist-packages/pyvows/decorators.py", line 15, in from pyvows.runner import SkipTest File "/usr/lib/python3/dist-packages/pyvows/runner/__init__.py", line 10, in from pyvows.runner.gevent import VowsParallelRunner as VowsRunner File "/usr/lib/python3/dist-packages/pyvows/runner/gevent.py", line 27, in from gevent.pool import Pool File "/usr/lib/python3/dist-packages/gevent/__init__.py", line 86, in from gevent._hub_local import get_hub File "/usr/lib/python3/dist-packages/gevent/_hub_local.py", line 101, in import_c_accel(globals(), 'gevent.__hub_local') File "/usr/lib/python3/dist-packages/gevent/_util.py", line 148, in import_c_accel mod = importlib.import_module(cname) ^^ File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) ModuleNotFoundError: No module named 'gevent._gevent_c_hub_local' autopkgtest [01:16:00]: test unittests OpenPGP_signature Description: OpenPGP digital signature
Bug#1025178: python-wadllib: (autopkgtest) needs update for python3.11: Deprecation warning on stderr
Source: python-wadllib Version: 1.3.6-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update User: debian-pyt...@lists.debian.org Usertags: python3.11 Control: affects -1 src:python3-defaults Dear maintainer(s), We are in the transition of adding python3.11 as a supported Python version [0]. With a recent upload of python3-defaults the autopkgtest of python-wadllib fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.10.6-3 python-wadllib from testing1.3.6-2 all others from testingfrom testing I copied some of the output at the bottom of this report. The test doesn't fail itself, but it prints output on stderr which by default (without allow-stderr restriction) is interpreted as failure. Currently this regression is blocking the migration of python3-defaults to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists what's new in Python3.11, it may help to identify what needs to be updated. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] https://bugs.debian.org/1021984 [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-wadllib/28796431/log.gz = python3.11 = Running tests at level 1 Running zope.testrunner.layer.UnitTests tests: Set up zope.testrunner.layer.UnitTests in 0.000 seconds. Running: /usr/lib/python3/dist-packages/wadllib/docs/NEWS.rst /usr/lib/python3/dist-packages/wadllib/docs/index.rstindex.rst[140]>:1: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13 import cgi Ran 2 tests with 0 failures, 0 errors and 0 skipped in 0.049 seconds. Tearing down left over layers: Tear down zope.testrunner.layer.UnitTests in 0.000 seconds. = python3.10 = Running tests at level 1 Running zope.testrunner.layer.UnitTests tests: Set up zope.testrunner.layer.UnitTests in 0.000 seconds. Running: /usr/lib/python3/dist-packages/wadllib/docs/NEWS.rst /usr/lib/python3/dist-packages/wadllib/docs/index.rst Ran 2 tests with 0 failures, 0 errors and 0 skipped in 0.055 seconds. Tearing down left over layers: Tear down zope.testrunner.layer.UnitTests in 0.000 seconds. autopkgtest [01:15:34]: test py3 OpenPGP_signature Description: OpenPGP digital signature
Bug#1025177: ITP: conda-package-streaming -- fetch conda metadata
Package: wnpp Severity: wishlist Subject: ITP: conda-package-streaming -- fetch conda metadata Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: conda-package-streaming Version : 0.7.0 Upstream Author : Anaconda, Inc. * URL : https://github.com/conda/conda-package-streaming * License : BSD-3-Clause Programming Lang: Python Description : fetch conda metadata Download conda metadata from packages without transferring entire file. Get metadata from local .tar.bz2 packages without reading entire files. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/conda-package-streaming
Bug#1024425: python-pysam ftbfs with python3.11 reduced severity
On Tue, 29 Nov 2022 22:30:10 +0100 =?utf-8?Q?=C3=89tienne?= Mollier wrote: > Control: severity -1 important > > Hi, > > I just uploaded python-pysam 0.20 with python3-dev support only > for the time being. This can be raised later on when python3.11 > becomes the default, or a last time when python3.10 is to be > dropped. Unfortunately this is a rabbit hole, and breaks other stuff, see Bug#1025116. Ofcourse, there is a work around for that bug as well (i.e. just test with default pyvers) but, this would need fixing soonish* * T applied -- Best, Nilesh signature.asc Description: PGP signature
Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible
Hi Gregor, On 29/11/2022 22:19, Gregor Riepl wrote: Hi Lee, can you still reproduce this bug? AFAICS this was fixed in the 2.13.3 upload. I couldn't find the original requirements.yml that produced the error, but I tested a similar file with Ansible 2.13.4, and it worked fine. That's great news! Additionally, I'll tighten the package dependencies so this issue will be more apparent in the future. Thanks, I appreciate it! Hopefully there will be a more stable resolvelib soon that doesn't cause these problems any more. By the way, what's the reason for the disparate versioning in Ansible and the ansible package? Why is Ansible 2.13.4 packaged as 6.4.0+dfsg-1? The upstream project has split into the "core" (the binaries basically, which was called "base" for one release cycle), and the community modules (now just called "ansible"). Also check /usr/share/doc/ansible/NEWS.Debian.gz for details. :) Regards, Gregor Regards, Lee
Bug#816393: Works now?
* Helge Kreutzmann : > for what is worth: > helge@samd:/tmp$ debget nghttp2 > Get:1 http://172.16.18.51:/ftp.de.debian.org/debian bullseye/main > amd64 nghttp2 all 1.43.0-1 [14.4 kB] > Fetched 14.4 kB in 0s (117 kB/s) For anyone reading along: this "success" is, because nghttp2 switched to tar.bz2 orig tarballs. Chris
Bug#1025176: libicu71 missing on SH4 port
Package: libicu71 Version: 71.1-1~ Tags: sid I'm working on a Debian Chroot for SH4 machine. I am trying to install GDB. The GDB installation fails: # apt install gdb Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libboost-regex1.74.0 : Depends: libicu71 (>= 71.1-1~) but it is not installable E: Unable to correct problems, you have held broken packages. The rub is, SH4 is not listed at https://packages.debian.org/sid/libicu71 . The package page also shows version 71.1-3, not 71.1-1. I'm not really sure how to proceed.
Bug#993996: RFS: guerillabackup/0.3.0-1 [ITP]: Updated package version for ITP, looking for sponsors
Dear mentors, A new version of the package is uploaded at mentors with the following changes compared with the previous version uploaded: * Include upstream support for backup policies checks both for quality (verify interval policy) but also regulatory/GDPR compliant retention policy. * Fixed Debian FHS violation pedantic lintian warning. Now I am looking for a sponsor for my package "guerillabackup": * Package name : guerillabackup Version : 0.3.0-1 Upstream contact : m...@halfdog.net * URL : https://github.com/halfdog/guerillabackup * License : LGPL-3.0+ * Vcs : https://salsa.debian.org/halfdog-guest/guerillabackup Section : misc The source builds the following binary packages: guerillabackup - resilient, distributed backup and archiving solution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/guerillabackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.3.0-1.dsc Changes for the initial release: guerillabackup (0.3.0-1) unstable; urgency=medium . * Initial packaging of guerillabackup (Closes: #849714) Regards, -- hd
Bug#942959: dh-python: Python2 removal in sid/bullseye
All of dh-python's reverse dependencies that use its Python 2 support have other unsatisfiable build dependencies now, so you should move forward with dropping Python 2 support.
Bug#1025175: asyncio_mqtt.Client("localhost") fails with a TypeError
Package: python3-asyncio-mqtt
Version: 0.13.0-1
Severity: grave
$ python3 -c 'import asyncio_mqtt; asyncio_mqtt.Client("localhost")'
Exception ignored in:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 660, in
__del__
self._reset_sockets()
File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 704, in
_reset_sockets
self._sock_close()
File "/usr/lib/python3/dist-packages/paho/mqtt/client.py", line 691, in
_sock_close
if not self._sock:
AttributeError: 'Client' object has no attribute '_sock'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/asyncio_mqtt/client.py", line 222, in
__init__
self._client: mqtt.Client = mqtt.Client(
TypeError: Client.__init__() got an unexpected keyword argument
'reconnect_on_failure'
$
The reconnect_on_failure keyword argument has been added to paho mqtt
quite recently and the Debian package hasn't been updated yet. So to fix
this bug you have two options:
a) Reupload 0.10.0 (with some really version).
b) Upload a new paho mqtt and upload python3-asyncio-mqtt with a suitable
version constraint.
In both cases, please do add an autopkgtest and a build-time test or
something. Such a fundamental failure shouldn't have entered unstable
much less migrated to testing. And I should have restarted my
application sooner. ;)
Helmut
Bug#1025146: RM: simbody [mips64el ppc64el] -- ROM; FTBFS on mips64el and ppc64el
On Wed, 30 Nov 2022 11:39:06 +0200 Andrius Merkys wrote: > Package: ftp.debian.org > Severity: normal > Control: block 1024989 by -1 > > Hello, > > Please remove simbody binaries for architectures mips64el and ppc64el as > the package no longer builds there. There are reverse depends that need to be addressed first (unless these are all arch: all, I didn't actually check). Please remove the moreinfo tag once these are resolved. Checking reverse dependencies... # Broken Depends: macromoleculebuilder: libmmblib3.5 [ppc64el] mmb [ppc64el] molmodel: libsimtkmolmodel3.0 # Broken Build-Depends: gazebo: libsimbody-dev macromoleculebuilder: libsimbody-dev molmodel: libsimbody-dev Dependency problem found. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1024961: Acknowledgement (nebula: Update package to v1.6.1 for migration to unstable)
Hi, I would go on with an team upload next week if there is no concerns with that :) That would include upgrading the package to the latest version and introducing golang-github-slackhq-nebula-dev for the source files kind regards, Peymaneh OpenPGP_signature Description: OpenPGP digital signature
Bug#1024959: Acknowledgement (golang-github-nbrownus-go-metrics-prometheus-dev: Upload to unstable)
Hi, I would go on with an team upload to unstable next week if there is no concerns with that :) kind regards, Peymaneh OpenPGP_signature Description: OpenPGP digital signature
Bug#1025061: RM: python-azure-devtools -- ROM; dead upstream, no more rdeps, broken with Python 3.11
On Wed, 30 Nov 2022 00:23:55 +1100 Stuart Prescott wrote: > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: stu...@debian.org > > The python-azure-devtools pacakge no longer has any reverse dependencies > and is 'archived' upstream. It doesn't support Python 3.11 and now is > the time to remove it from Debian. It does, however, have reverse build-depends, which will need to be addressed first. Please remove the moreinfo tag once that's done. Checking reverse dependencies... # Broken Build-Depends: azure-cli: python3-azure-devtools (>= 1.2.0-1~) azure-devops-cli-extension: python3-azure-devtools azure-functions-devops-build: python3-azure-devtools python-azure: python3-azure-devtools (>= 1.1.0) Dependency problem found. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1024827: RM: gatb-core [i386 armel armhf s390x] -- ROM; Not supported for some architectures
On Sat, 26 Nov 2022 07:34:27 +0100 Andreas Tille wrote: > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: 1023...@bugs.debian.org > > Hi, > > it turned out that we have to restrict the number of architectures for this package. > Thus please remove the other architectures from the archive. > > Thanks a lot for your work as ftpmaster > Andreas. There are rdepends that need to be addressed first. Please remove the moreinfo tag once this is complete. # Broken Depends: bcalm: bcalm [i386 s390x] discosnp: discosnp [i386 s390x] gatb-core: gatb-core-testdata mindthegap: mindthegap [i386 s390x] minia: minia [i386 s390x] simka: simka [i386 s390x] # Broken Build-Depends: bcalm: libgatbcore-dev discosnp: libgatbcore-dev mindthegap: libgatbcore-dev (>= 1.4.2+dfsg-7) minia: libgatbcore-dev (>= 1.4.2-7) simka: libgatbcore-dev Scott K signature.asc Description: This is a digitally signed message part.
Bug#1025174: release 43.0 breaks Xfce X2Go sessions
Package: libwnck-3-0 Version: 43.0-2 Severity: normal X-Debbugs-Cc: ever...@libero.it Dear Maintainer, Since I updated the package to version 43.0-2 I have been unable to open XFCE X2Go sessions. The problem has been reported several times recently. https://gitlab.gnome.org/GNOME/libwnck/-/issues/154 https://forum.manjaro.org/t/xfce4-panel-crashing/124194 It has also been reported for Debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024160 but the reporter hasn't included the package name so I decided to open it again indicating also the package. Downgrading to version 3.36.0-1 (from Stable) solves the problem. Thanks for your attention. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'stable'), (400, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libwnck-3-0 depends on: ii libatk1.0-0 2.46.0-4 ii libc6 2.36-5 ii libcairo2 1.16.0-6 ii libgdk-pixbuf2.0-02.40.2-2 ii libglib2.0-0 2.74.1-2 ii libgtk-3-03.24.35-1 ii libpango-1.0-01.50.10+ds-1 ii libstartup-notification0 0.12-6+b1 ii libwnck-3-common 43.0-2 ii libx11-6 2:1.8.1-2 ii libxrender1 1:0.9.10-1.1 ii libxres1 2:1.2.1-1 libwnck-3-0 recommends no packages. libwnck-3-0 suggests no packages. -- no debconf information
