Bug#1061216: Please upgrade to llvm-toolchain-17
If a fix for this can't be released on time, I'm requesting an exception for llvm-15. Removing OpenVDB from Debian will affect Blender, which is is relatively high-profile and should not just be axed for the sake if a pruning operation. You still have time, we aren't going to release the trixie anytime soon :) but we won't probably block the removal in testing for openvdb (the popcon isn't high IMHO). Let's hope upstream notices the issue and fixes it. In the meantime, it may be possible to remove the immediate pressure by simply disabling the build of libopenvdb-ax. The rest of OpenVDB doesn't require LLVM 15, and I couldn't find any Debian package that depends on it (save for python3-openvdb, which will simply not have AX support). This should at least bring Blender back into trixie. I did a quick build test with the AX component disabled, and that seems to work fine. Blender also compiles. Didn't try to install and run the final result, though.
Bug#1061216: Please upgrade to llvm-toolchain-17
Which LLVM versions are you planning to remove?
15, 16 soon. 17 later.
Would it be possible to keep at least LLVM 15 until upstream has
upgraded their code base?
Sounds very unlikely for the next Debian release.
If a fix for this can't be released on time, I'm requesting an exception
for llvm-15. Removing OpenVDB from Debian will affect Blender, which is
is relatively high-profile and should not just be axed for the sake if a
pruning operation.
Is there any other reason why llvm-15 couldn't be kept, aside from the
reason mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050070 ("too many
llvm version") ?
Is there an upstream bug to follow the progress on their upgrade of LLVM?
There is now:
https://github.com/AcademySoftwareFoundation/openvdb/issues/1804
Bug#1061216: Please upgrade to llvm-toolchain-17
As part of the effort to limit the number of llvm packages in the archive, it would be great if you could upgrade to -17. This package depends on 14. Not possible at this time. Trying to build openvdb 10.0.1 against LLVM 17 results in the following error: CMake Error at openvdb_ax/openvdb_ax/CMakeLists.txt:118 (message): OpenVDB AX does not currently support LLVM versions >= 15 due to opaque pointer changes in LLVM. Found unsuitable LLVM version "17.0.6" The release notes for openvdb 11.1.0[1] mention compatibility with LLVM 15, but not later versions. There's nothing listed for 11.0.0, and a quick test shows that this hasn't changed: CMake Error at openvdb_ax/openvdb_ax/CMakeLists.txt:118 (message): OpenVDB AX does not currently support LLVM versions >= 16 due to opaque pointer changes in LLVM. Found unsuitable LLVM version "17.0.6" Which LLVM versions are you planning to remove? Would it be possible to keep at least LLVM 15 until upstream has upgraded their code base? [1] https://www.openvdb.org/documentation/doxygen/changes.html#v10_1_0_changes
Bug#1042466: Likely fixed
Hi Thomas, I tried, in Sid, doing "import sendtry_sdk" and it worked without any problem. So it's likely this was fixed in Eventlet 0.35.1. The upstream bug is still open, and no fix for the missing epoll was committed. It's also unlikely that this will ever happen, as the README in the eventlet project now states: Eventlet now follows a new maintenance policy. Only maintenance for stability and bug fixing will be provided. No new features will be accepted, except those related to the asyncio migration. Usages in new projects are discouraged. Our goal is to plan the retirement of eventlet and to give you ways to move away from eventlet. So, the "fix" was most likely in sentry-sdk and not eventlet. I can confirm that Cura no longer crashes on startup, so this bug can indeed be closed. However: The appropriate long-term action should be to request removal of eventlet from Debian, and then start updating/fixing all packages that currently reverse-depend on it. Regards, Gregor
Bug#1066754: sentry-python: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hi, I believe this issue can be addressed by my proposed fix for #1063986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063986#12 Regards, Gregor
Bug#1063986: sentry-python: autopkgtest regression with pytest 8
Hi, I think this issue can be fixed by pulling in the latest sentry-sdk version (1.43 at this point) and applying the following patch: diff --git a/debian/rules b/debian/rules index 206ab22..27d6911 100755 --- a/debian/rules +++ b/debian/rules @@ -43,6 +43,7 @@ PYBUILD_TEST_ARGS_PYTEST7_IGNORE=\ and not test_circular_references \ and not test_has_tracestate_enabled \ and not test_default_release \ + and not test_uwsgi_warnings \ export PYBUILD_NAME=sentry_sdk # Disable tests failing mostly because of internet access (httpbin.org) The test "test_uwsgi_warnings" is flaky and doesn't clean up properly after itself, which leads to an error further down the line. Please release a new version as soon as possible. Thank you very much. Regards, Gregor
Bug#1067144: [3dprinter-general] Bug#1067144: uranium: missing depend on python3-all for autopkgtest
Hi Timo, This is not about Build-Depends, nor about the binary package Depends. uranium has an explicit debian/tests/control file with "Depends: @", which only installs the built package(s) and their dependencies. Up until now, these dependencies included all supported Python interpreters, because python3-numpy depended on them explicitly. As this is no longer the case, you must either - add python3-all to the Depends line in debian/tests/control, or - stop using `pyversions -r` in the Test-Command Thank you very much for the explanation, I wasn't aware of this. I pushed a simple patch to add the dependency, would be nice if you could release it, @myon? Thanks in advance. https://salsa.debian.org/3dprinting-team/uranium/-/commit/d1ec9acf9b6dd30abc8b6259a100809d20e4c2d6 The other Cura Python modules already include the python3-all test dependency, so there's no change needed for them. Regards, Gregor
Bug#1067144: [3dprinter-general] Bug#1067144: uranium: missing depend on python3-all for autopkgtest
Hi Timo, your package has an autopkgtest regression due to changes in NumPy. The python3-numpy package no longer depends on all supported Python versions. You need to depend on python3-all if you want to run your tests against all supported Python releases. Can you elaborate why this dependency is needed in the first place? It's the first time I heard that a python3 module package needs such an explicit dependency outside the Build-Depends. I also don't think it makes sense to always install python3-all on every system that installs python3-uranium, just because autopkgtest needs it. Shouldn't autopkgtest figure out by itself that this package is needed to run tests against all python versions? (and if this is about Build-Depends - src:uranium has depended on python3-all since it existed) Regards, Gregor
Bug#1062014: closing 1062014
> The upstream bug has been closed because Prusa Slicer no longer has USB control > capabilities. Are you sure this is related? Your upstream bug[1] is still open last I checked. Also, prusa-slicer 2.7.1+dfsg-1 still depends on libbgcode[2], so it will still FTBFS on all big endian archs and block migration due to the missing s390x build. Incidentally, I tried to build it with the dependency on libbgcode-dev removed, and it resulted in this error: CMake Error at src/libslic3r/CMakeLists.txt:24 (find_package): By not providing "FindLibBGCode.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "LibBGCode", but CMake did not find one. Could not find a package configuration file provided by "LibBGCode" with any of the following names: LibBGCodeConfig.cmake libbgcode-config.cmake Add the installation prefix of "LibBGCode" to CMAKE_PREFIX_PATH or set "LibBGCode_DIR" to a directory containing one of the above files. If "LibBGCode" provides a separate development package or SDK, be sure it has been installed. Looks like slicer 2.7.1 very much still depends on libbgcode.
Bug#1066948: [3dprinter-general] Bug#1066948: prusa-slicer: No installable version on trixie
Hi XTL, Looks like my system offers an upgrade for prusa-slicer, which is being kept back. The current/old version doesn't seem to appear available at all and the only one offered is from sid. That isn't reasonably installable either as it seems to replace or remove half the system. So, it looks like prusa-slicer is not availble and that effectively means trixie can not do 3d printing. Which has worked so far and works as long as I keep the old package that I luckily have on one machine. This seems like a situation that should never happen IMO. Sorry about this situation, but these things *do* happen from time to time. There's a large number of transitions going on right now, and slicer depends on several of the affected packages. That delays migration. Unfortunately, we also had to deal with fallout from some of updated dependencies recently (catch2 and wxwidgets come to mind), which blocked automigration and caused autoremoval from trixie in December. If you look at the package tracker[1], you can (somewhat) see what's going on. There's also the issue that libbgcode (a dependency of slicer) is broken on all big-endian architectures, which still seems to unsolved. This blocks automigration, because s390x is a big-endian release architecture. Related bug: [2] There might still be something fishy going here. @hyperair Do you think the situation will resolve itself, or do we need to exclude s390x from the Architectures in slic3r-prusa/debian/control ? Regards, Gregor [1] https://tracker.debian.org/pkg/slic3r-prusa [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062014
Bug#1062014: closing 1062014
The upstream bug has been closed because Prusa Slicer no longer has USB control capabilities. Are you sure this is related? Your upstream bug[1] is still open last I checked. Also, prusa-slicer 2.7.1+dfsg-1 still depends on libbgcode[2], so it will still FTBFS on all big endian archs and block migration due to the missing s390x build. [1] https://github.com/prusa3d/libbgcode/issues/47 [2] https://salsa.debian.org/3dprinting-team/slic3r-prusa/-/blob/master/debian/control?ref_type=heads
Bug#1064598: yagv: crashes with "module 'pyglet.graphics' has no attribute 'vertex_list'"
Hi, AttributeError: module 'pyglet.graphics' has no attribute 'vertex_list' I suspect this may not be trivial to fix. yagv depends on pyglet 1.x, which relies on the OpenGL fixed function pipeline. Debian has switched to 2.x and no longer supports this. [1] Unfortunately, it appears that upstream project is dead. The last commit was in 2017, and any requests by @pere on their bug tracker fell on deaf ears: [2] It's regrettable, but I don't think yagv can be kept with the current situation. As you might right recall, I offered to help with a similar situation in printrun, but this got stuck due to the significant effort required and a lack of time on my side. It's unlikely that I would be able to help with yagv either at the moment. Sorry... [1] https://pyglet.readthedocs.io/en/latest/programming_guide/migration.html [2] https://github.com/jonathanwin/yagv/issues/20
Bug#1064512: python3-samba: Tests should not be packaged
Package: python3-samba Version: 2:4.19.5+dfsg-1 Severity: normal X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, It looks like the python3-samba package installs some unit tests into /usr/lib/python3/dist-packages/samba/tests If this is the case, please exclude them from the package build. There is no value in installing unit tests along with a runtime library (or, as in this case, a Python module). Thank you! -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.13-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-samba depends on: ii libbsd0 0.11.8-1 ii libc6 2.37-15 ii libgnutls30 3.8.3-1 ii libldb2 2:2.8.0+samba4.19.5+dfsg-1 ii libpython3.11 3.11.8-1 ii libtalloc22.4.2-1 ii libtevent00.16.1-1 ii python3 3.11.6-1 ii python3-ldb 2:2.8.0+samba4.19.5+dfsg-1 ii python3-talloc2.4.2-1 ii python3-tdb 1.4.10-1 ii samba-libs [libndr3] 2:4.19.5+dfsg-1 Versions of packages python3-samba recommends: ii python3-gpg 1.18.0-4+b2 python3-samba suggests no packages. -- no debconf information
Bug#1038016: adlibtracker2: Depends on SDL 1.2
Package: adlibtracker2 Version: 2.4.24-2 Followup-For: Bug #1038016 X-Debbugs-Cc: onit...@gmail.com I can confirm that the package builds and runs fine with libsdl1.2-compat-dev. However, it seems to be broken in general, because no GUI is shown and the adtrack2 process can only be ended with a SIGKILL. This behavior is the same with the current package in sid. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages adlibtracker2 depends on: ii libsdl1.2debian 1.2.68-2 adlibtracker2 recommends no packages. adlibtracker2 suggests no packages. -- no debconf information
Bug#1062700: smplayer: Cannot resume playback from pause with mpv 0.37.0
Hi, After upgrading mpv to 0.37.0, resuming the paused video by clicking the UI "play" button nor pressing the space key works -> nothing happens. With mpv <= 0.36.0, resuming works normally. The workaround is to move video forward/backward 10 seconds (left/right key) first. After that, resuming works again. This is most likely upstream bug https://github.com/smplayer-dev/smplayer/issues/837 It should be fixed in smplayer 23.6.0.10190, or by adding the patch https://github.com/smplayer-dev/smplayer/commit/74690b30a816aa4644be4f83ffca096441713645 Regards, oni
Bug#1062014: libbgcode: FTBFS on s390x and ppc64 due to endianness issues
Source: libbgcode
Version: 0.0~git20231219.7aaf717-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Usertags: s390x
X-Debbugs-Cc: onit...@gmail.com
Dear Maintainer,
buildd reports failing unit tests on s390x and ppc64: [1] [2]
Example error:
1: Filters: "File transversal"
1: Randomness seeded to: 936238706
1:
1: TEST: File transversal
1: File:/<>/tests/data/mini_cube_b.bgcode
1:
1:
~~~
1: core_tests is a Catch2 v3.4.0 host application.
1: Run with -? for options
1:
1:
---
1: File transversal
1:
---
1: ./tests/core/core_tests.cpp:85
1:
...
1:
1: ./tests/core/core_tests.cpp:97: FAILED:
1: REQUIRE( is_valid_binary_gcode(*file, true, checksum_verify_buffer,
sizeof(checksum_verify_buffer)) == EResult::Success )
1: with expansion:
1: 3 == 0
1:
1:
===
1: test cases: 1 | 1 failed
1: assertions: 2 | 1 passed | 1 failed
1:
1/4 Test #1: File transversal .***Failed0.00 sec
Some debugging reveals that this error happens due to mismatched endianness
when reading data files.
diff --git a/src/LibBGCode/core/core.cpp b/src/LibBGCode/core/core.cpp
@@ -126,8 +127,10 @@ EResult FileHeader::read(FILE& file, const uint32_t* const
max_version)
{
if (!read_from_file(file, , sizeof(magic)))
return EResult::ReadError;
+printf("data=0x%08x MAGIC=0x%08x\n", magic, MAGICi32);
if (magic != MAGICi32)
return EResult::InvalidMagicNumber;
->
File:/build/libbgcode/tests/data/mini_cube_b.bgcode
data=0x47434445 MAGIC=0x45444347
It's likely that there are many more similar problems lurking in the source
code.
If this issue can't be fixed, the package should probably be disabled on big
endian architectures.
Thanks!
[1]
https://buildd.debian.org/status/fetch.php?pkg=libbgcode=s390x=0.0%7Egit20231219.7aaf717-1%2Bb1=1704613965=0
[2]
https://buildd.debian.org/status/fetch.php?pkg=libbgcode=ppc64=0.0%7Egit20231219.7aaf717-1%2Bb1=1704984706=0
[3]
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: s390x
Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Bug#1060421: python3-botocore: botocore as a (useless) undeclared dependency on python3-six
Hi, python3-core is importing python3-six for absolutely no reason this package only work by luck for now because the library got pulled-in by something else (most likely python3-urllib2) $ grep ' six' /usr/lib/python3/dist-packages/botocore -r | grep import /usr/lib/python3/dist-packages/botocore/compat.py:import six How do you suggest this should be fixed? A Debian patch that removes the line from compat.py? Or should the Debian package depend on python3-six? Or is it a bug that must be fixed upstream? Regards, Gregor
Bug#1059648: sip4: autopkgtest failure with Python 3.12
Hi Graham, sip4's autopkgtests fail with Python 3.12 [1]. I've copied what I hope is the relevant part of the log below. [1] https://ci.debian.net/packages/s/sip4/testing/amd64/ 22s autopkgtest [20:09:51]: test autodep8-python3: [--- 22s Testing with python3.12: 22s 22s bash: line 1: 1865 Segmentation fault $py -c "import sip; print(sip)" 22s autopkgtest [20:09:51]: test autodep8-python3: ---] I can reproduce that, although I should mention that the segfault happens during teardown, not when the module is loaded: >>> import sip >>> print(sip) '/usr/lib/python3/dist-packages/sip.cpython-312-x86_64-linux-gnu.so'> >>> Program received signal SIGSEGV, Segmentation fault. 0x00513a8d in PyMem_Free () (gdb) bt #0 0x00513a8d in PyMem_Free () #1 0x7f73de6feaf9 in sip_api_free (mem=) at ./siplib/siplib.c:2241 #2 0x7f73de710c6d in sipOMFinalise (om=) at ./siplib/objmap.c:69 #3 0x7f73de6febaf in finalise () at ./siplib/siplib.c:2143 #4 0x004591ab in ?? () #5 0x00662d77 in Py_RunMain () #6 0x006232eb in Py_BytesMain () #7 0x7f73deba66ca in __libc_start_call_main (main=main@entry=0x623240, argc=argc@entry=1, argv=argv@entry=0x7ffd043a59b8) at ../sysdeps/nptl/libc_start_call_main.h:58 #8 0x7f73deba6785 in __libc_start_main_impl (main=0x623240, argc=1, argv=0x7ffd043a59b8, init=, fini=, rtld_fini=, stack_end=0x7ffd043a59a8) at ../csu/libc-start.c:360 #9 0x00623171 in _start () I'd also like to point out that SIP4 is no longer supported upstream. The current version is 6.8.1, which is already packaged for Debian. https://www.riverbankcomputing.com/software/sip/download > SIP v4 is no longer supported. This is the last release. > sip-4.19.25.tar.gz Cura was made fit for PyQt6 and SIP6 in April 2022, and I think 5.0 has all the needed changes. I will investigate if we can drop the dependency on python3-sip-dev. As far as I can see, there are no other users of SIP4 in Debian, so maybe it can be dropped completely after fixing Cura.
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
(sorry for the very late response, I only noticed your message just now) I did come to the conclusion that Werkzeug 2.3.x has some bigger changes that will break most of the existing packages in some way. The main differences to Werkzeug 3.x than isn't that big. Ok, that makes sense! Although, I'm not 100% convinced that updating to 2.3 in the short run to fix some currently broken packages, and then focusing on upgrading to 3.x isn't a better choice. 2.3 is also closer to 3.x, so that may make a transition smoother. Because a updated flask-login and other (updated) packages have also underlying changes that require than a updated package of Werkzeug. And some upstream projects did change their source in a way so they can deal different versions of Werkzeug. So a usual update is magical fixing build issues we did have in older versions against recent Flask/Werkzeug versions. Ok, now I get what mean. Thanks for the clarification and sorry for the confusion.
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hi Carsten, I can see that 3.0.1 is currently in experimental, but it would be enough to upgrade to the latest 2.x to fix this issue. this makes not really sense to me. Flask 3.0.0 and Werkzeug 3.0.0 was released on 09-30-2023, so almost three months before. Putting energy into Flask 2.3.5 and fix other related packages while 3.x is on the way is a waste of time in my eyes as we would need to work at least twice on some packages... Absolutely! My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit for release, it should be enough to upgrade to 2.3.5 to address these unit test failures. flask-login got recent updates which so far I've seen will fix these issues in the test suite. So if you want to push things further try to update/patch flask-login to a recent version targeting experimental. Just rebuilding flask-login against the version of python3-werkzeug in experimental will not fix the problems, so also not an intermediate update to 2.3.5, Python 3.12 is now very strict about deprecation warnings. That doesn't make any sense to me. These deprecations are obviously in werkzeug and not flask-login. Why would changes in flask-login fix them? Not saying flask-login shouldn't be updated, but that's not the right scope for this bug report. Regards, Gregor
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
I don't see any other errors in the log except for the ast.Str deprecation warnings, and they all come from python-werkezug and not this package. Reassiging the bug. Upstream has already fixed this in in 2.3.5, by the way: https://github.com/pallets/werkzeug/issues/2704 I can see that 3.0.1 is currently in experimental, but it would be enough to upgrade to the latest 2.x to fix this issue. Please push a new python-werkzeug release ASAP. Thank you!
Bug#1057361: Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded load_files is ambiguous
It looks like this issue was already fixed upstream, or at least partially. I reported a separate bug that also references the upstream patch and gives some more context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057630 While this is a relatively severe bug (uninitialized memory), it doesn't manifest itself on many architectures. The build failure that occurs on arm64 and many others is actually a mistake in my Catch2 v3 patch: I used catch2::WithinRel comparison everywhere, but this doesn't work well when comparing to zero. The only surprise here is that it *doesn't* fail on amd64. I will reopen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054697 and submit an updated patch that uses catch2::WithinAbs for comparison with zero instead.
Bug#1057630: slic3r-prusa: Uninitialized memory in GravityKernel.hpp causes FTBFS on multiple architectures
Source: slic3r-prusa
Version: 2.6.1+dfsg-4.1
Severity: normal
Tags: patch upstream ftbfs
X-Debbugs-Cc: onit...@gmail.com
The PrusaSlicer currently fails to build on multiple architectures due to an
uninitialized field in GravityKernel.hpp .
This bug causes a unit test failure, but this doesn't always show.
The bug is in src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp line 18:
Vec2d active_sink;
This struct field is not initialized because the default constructor of Vec2d
(which is a type alias to Eigen::Matrix) does nothing. This is
documented behavior, but was not respected in the PrusaSlicer source code:
https://eigen.tuxfamily.org/dox/group__TutorialMatrixClass.html
> A default constructor is always available, never performs any dynamic memory
allocation, and never initializes the matrix coefficients.
This issue was partially fixed in upstream commit
f2ae32780eb8ec9437e0134b08a5e1c752353527, but the default constructor was not
replaced. It's not clear if this is still an issue or not, but the following
patch should at least be backported to Debian to fix the FTBFS issue in
PrusaSlicer:
commit f2ae32780eb8ec9437e0134b08a5e1c752353527
Author: tamasmeszaros
Date: Mon Oct 2 12:07:14 2023 +0200
Fix failing arrange test on newest msvc
diff --git a/src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp
b/src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp
index c8a5488b3..3bb1cad0e 100644
--- a/src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp
+++ b/src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp
@@ -17,7 +17,9 @@ struct GravityKernel {
std::optional item_sink;
Vec2d active_sink;
-GravityKernel(Vec2crd gravity_center) : sink{gravity_center} {}
+GravityKernel(Vec2crd gravity_center) :
+sink{gravity_center}, active_sink{unscaled(gravity_center)} {}
+
GravityKernel() = default;
template
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable'), (300, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1056897: [3dprinter-general] Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files?=()=?UTF-8?Q?’ is ambiguous
Gah, looks like some arch-dependent glitch. Which explains why it didn't
happen to either of us (we probably both used amd64 machines, I
definitely did) and then the failure did happen upon publishing.
Thanks for your help, I'll try to help get the next fix in once it's ready.
Ok, so I have a preliminary status report.
I debugged the issue on i386 first, because that's the easiest to do
with standard PC hardware.
In contrast with the other architectures, the value reported by the
failed unit test is off by several orders of magnitude on i386, while it
seems to be "only" a sign issue on other architectures.
I've isolated the issue to make debugging easier, and that revealed
incomplete initialization of the Slic3r::arr2::GravityKernel object -
this object is allocated on the stack by the unit test, and while the
constructors of all fields are called, the field active_sink remains
uninitialized.
This is apparently by design, as stated in the Eigen documentation (the
LA library used by Slicer):
https://eigen.tuxfamily.org/dox/group__TutorialMatrixClass.html
> A default constructor is always available, never performs any dynamic
memory allocation, and **never initializes the matrix coefficients**.
So, this is most definitely a bug in PrusaSlicer, because it doesn't
explicitly assign an initial value to
Slic3r::arr2::GravityKernel.active_sink - but uses it later anyway.
I don't know why this only causes issues on i386, but it's certainly
dangerous on all architectures.
The fix quite easy, though.
Modify line 20 and 21 in
src/libslic3r/Arrange/Core/NFP/Kernels/GravityKernel.hpp as follows:
-GravityKernel(Vec2crd gravity_center) : sink{gravity_center} {}
-GravityKernel() = default;
+GravityKernel(Vec2crd gravity_center) : sink{gravity_center},
active_sink{0, 0} {}
+GravityKernel() : active_sink{0, 0} {};
I'll file separate bug report + corresponding upstream report later.
Now, I don't know if this will fix the issues on the other
architectures, but I'll try to reproduce them on an arm64 device at
least. It's very likely that the issue is the same everywhere.
Bug#1056897: [3dprinter-general] Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files?=()=?UTF-8?Q?’ is ambiguous
Hi Aaron, Simon is uploading the new packaging to the DELAYED/1 queue. It should arrive in the archive on November 30. If you are a maintainer of slic3r-prusa, you can review the new packaging in the mean time and reject or fast-track it as you see fit. Thanks a lot for this! The NMU is building right now. Unfortunately, it looks like a new issue cropped up that curiously didn't happen to me during testing: [1] ./tests/arrange/test_arrange.cpp:935: FAILED: REQUIRE_THAT( score, WithinRel(0., EPSILON) ) with expansion: -0.0 and 0 are within 0.01% of each other Sounds like the EPSILON value is not appropriate for this test, or WithinRel has problems with negative zero (or near-zero). I'll investigate this issue as soon as I can. Regards, Gregor [1] https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=arm64=2.6.1%2Bdfsg-4.1=1701382946=0
Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files()’ is ambiguous
Here's the promised patch.
Also, I just found that this change was done in wxWidgets 3.2.4.
Upstream PR: https://github.com/wxWidgets/wxWidgets/pull/23309
It seems the wxWidgets developers actually recommend to move away from
wxArrayString and the like:
https://github.com/wxWidgets/wxWidgets/commit/4d62df488b8e421cadfbd8648b813d7494a56153
Index: slic3r-prusa/src/slic3r/GUI/PhysicalPrinterDialog.cpp
===
--- slic3r-prusa.orig/src/slic3r/GUI/PhysicalPrinterDialog.cpp
+++ slic3r-prusa/src/slic3r/GUI/PhysicalPrinterDialog.cpp
@@ -462,7 +462,7 @@ void PhysicalPrinterDialog::build_printh
// Always fill in the "printhost_port" combo box from the config and select it.
{
Choice* choice = dynamic_cast(m_optgroup->get_field("printhost_port"));
-choice->set_values({ m_config->opt_string("printhost_port") });
+choice->set_values(std::vector({ m_config->opt_string("printhost_port") }));
choice->set_selection();
}
Index: slic3r-prusa/src/slic3r/GUI/Plater.cpp
===
--- slic3r-prusa.orig/src/slic3r/GUI/Plater.cpp
+++ slic3r-prusa/src/slic3r/GUI/Plater.cpp
@@ -5310,7 +5310,7 @@ void Plater::load_project(const wxString
p->reset();
-if (! load_files({ into_path(filename) }).empty()) {
+if (! load_files(std::vector({ into_path(filename) })).empty()) {
// At least one file was loaded.
p->set_project_filename(filename);
// Save the names of active presets and project specific config into ProjectDirtyStateManager.
Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files()’ is ambiguous
Source: slic3r-prusa
Version: 2.6.1+dfsg-4
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: onit...@gmail.com
Hi,
During a recent upload, PrusaSlicer failed to build due to incompatible chanes
in wxWidgets 3.2.
These changes include support for initializer lists, which clashes with some
overloads in the
PrusaSlicer source code. The errors are as follows:
src/slic3r/GUI/Plater.cpp: In member function ‘void
Slic3r::GUI::Plater::load_project(const wxString&)’:
src/slic3r/GUI/Plater.cpp:5313:21: error: call of overloaded
‘load_files()’ is ambiguous
5313 | if (! load_files({ into_path(filename) }).empty()) {
| ~~^
In file included from src/slic3r/GUI/Plater.cpp:20:
src/slic3r/GUI/Plater.hpp:193:25: note: candidate: ‘std::vector Slic3r::GUI::Plater::load_files(const
std::vector&, bool, bool, bool)’
193 | std::vector load_files(const
std::vector& input_files, bool load_model = true, bool
load_config = true, bool imperial_units = false);
| ^~
src/slic3r/GUI/Plater.hpp:197:10: note: candidate: ‘bool
Slic3r::GUI::Plater::load_files(const wxArrayString&, bool)’
197 | bool load_files(const wxArrayString& filenames, bool
delete_after_load = false);
| ^~
and
src/slic3r/GUI/PhysicalPrinterDialog.cpp: In member function 'void
Slic3r::GUI::PhysicalPrinterDialog::build_printhost_settings(Slic3r::GUI::ConfigOptionsGroup*)':
src/slic3r/GUI/PhysicalPrinterDialog.cpp:465:27: error: call of overloaded
'set_values()' is ambiguous
465 | choice->set_values({ m_config->opt_string("printhost_port") });
| ~~^~~~
In file included from src/slic3r/GUI/ConfigManipulation.hpp:16,
from src/slic3r/GUI/Tab.hpp:50,
from src/slic3r/GUI/PhysicalPrinterDialog.cpp:28:
src/slic3r/GUI/Field.hpp:381:33: note: candidate: 'void
Slic3r::GUI::Choice::set_values(const
std::vector >&)'
381 | voidset_values(const
std::vector );
| ^~
src/slic3r/GUI/Field.hpp:382:33: note: candidate: 'void
Slic3r::GUI::Choice::set_values(const wxArrayString&)'
382 | voidset_values(const wxArrayString );
| ^~
These issues can be worked around with an explicit instantiation of the
std::vector.
A better solution would be a change to wxWidgets, by making the initializer
list constructor explicit.
A patch will follow shortly.
Regards,
Gregor
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (300,
'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1055468: [3dprinter-general] Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"
Hi Dave, Since it's just a warning, I wouldn't touch it. Stable updates are possible, but need poking the stable release managers who have more interesting problems to fix. In that case, I recommend comparing the list of files and removing what's not needed: https://packages.debian.org/bookworm/all/python3-charon/filelist -> https://packages.debian.org/trixie/all/python3-charon/filelist You can basically delete /lib/systemd/system/charon.service and /usr/share/dbus-1/system.d/nl.ultimaker.charon.conf on your system to get rid of the warning. It's not a persistent change, but it's unlikely that there will be an update to the package in stable. Regards, Gregor
Bug#1055468: [3dprinter-general] Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"
Hi Dave, During boot, I get a warning about a missing username "ultimaker". As far as I can tell this stems from the dbus configuration file packaged with python3-charon (/usr/share/dbus-1/system.d/nl.ultimaker.charon.conf) (I don't think it's the systemd configuration file that mentions the same user (/lib/systemd/system/charon.service), as I'm running Devuan with OpenRC). I guess the easy fix for this would be to add the username - maybe that should be part of the package installation scripts though? Actually, this should no longer be an issue and is fixed in python3-charon 5.0.0-4. But we didn't backport it, so it still affects Cura in bookworm. We have confirmation from Ultimaker that the daemon/dbus/systemd stuff in libCharon is only used on Ultimaker devices and shouldn't even be installed with Cura: https://github.com/Ultimaker/libCharon/issues/45 @myon, could we release a backported fix to bookworm, or should we leave it as it is? I don't have much experience with stable packaging policies. Regards, Greg
Bug#1054697: slic3r-prusa: FTBFS: test_arrange.cpp:1:10: fatal error: catch2/catch.hpp: No such file or directory
Here's an updated version of the patch with hardcoded precision values
replaced with the epsilon constant used in other unit tests.
I also submitted the patch as a PR upstream:
https://github.com/prusa3d/PrusaSlicer/pull/11576From: Gregor Riepl
Date: Tue, 31 Oct 2023 19:37:00 +0100
Subject: Catch2 v3 updates
Bug-Debian: https://bugs.debian.org/1054697
---
tests/CMakeLists.txt | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -12,7 +12,7 @@
add_library(test_common INTERFACE)
target_compile_definitions(test_common INTERFACE TEST_DATA_DIR=R"\(${TEST_DATA_DIR}\)" CATCH_CONFIG_FAST_COMPILE)
-target_link_libraries(test_common INTERFACE Catch2::Catch2)
+target_link_libraries(test_common INTERFACE Catch2::Catch2WithMain)
target_include_directories(test_common INTERFACE ${CMAKE_CURRENT_LIST_DIR})
if (APPLE)
target_link_libraries(test_common INTERFACE "-liconv -framework IOKit" "-framework CoreFoundation" -lc++)
--- a/tests/arrange/test_arrange.cpp
+++ b/tests/arrange/test_arrange.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_utils.hpp"
#include
@@ -40,6 +40,8 @@
#include
+using Catch::Matchers::WithinRel;
+
template
static std::vector prusa_parts(double infl = 0.) {
using namespace Slic3r;
@@ -930,7 +932,7 @@
Slic3r::Vec2crd D = bed.center - item.shape.center();
REQUIRE(item.translation == D);
-REQUIRE(score == Approx(0.).margin(EPSILON));
+REQUIRE_THAT(score, WithinRel(0., EPSILON));
}
}
}
@@ -1063,7 +1065,7 @@
bool packed = pack(strategy, bed, itm);
REQUIRE(packed);
-REQUIRE(get_rotation(itm) == Approx(PI));
+REQUIRE_THAT(get_rotation(itm), WithinRel(PI));
}
//TEST_CASE("NFP optimizing test", "[arrange2]") {
--- a/tests/arrange/test_arrange_integration.cpp
+++ b/tests/arrange/test_arrange_integration.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_utils.hpp"
#include
@@ -12,6 +12,8 @@
#include "libslic3r/Format/3mf.hpp"
#include "libslic3r/ModelArrange.hpp"
+using Catch::Matchers::WithinRel;
+
static Slic3r::Model get_example_model_with_20mm_cube()
{
using namespace Slic3r;
@@ -560,10 +562,10 @@
auto ref_pos = tr * Vec3d::Zero();
auto displace = bed_index * (unscaled(vbh.stride_scaled()));
-REQUIRE(ref_pos.x() == Approx(-displace));
+REQUIRE_THAT(ref_pos.x(), WithinRel(-displace));
auto ref_pos_mi = mi_to_move.get_matrix() * Vec3d::Zero();
-REQUIRE(ref_pos_mi.x() == Approx(instance_displace.x() + (bed_index >= 0) * displace));
+REQUIRE_THAT(ref_pos_mi.x(), WithinRel(instance_displace.x() + (bed_index >= 0) * displace));
}
}
}
@@ -868,8 +870,8 @@
{
return v1.is_rotation_enabled() == v2.is_rotation_enabled() &&
v1.get_arrange_strategy() == v2.get_arrange_strategy() &&
- v1.get_distance_from_bed() == Approx(v2.get_distance_from_bed()) &&
- v1.get_distance_from_objects() == Approx(v2.get_distance_from_objects()) &&
+ WithinRel(v2.get_distance_from_bed()).match(v1.get_distance_from_bed()) &&
+ WithinRel(v2.get_distance_from_objects()).match(v1.get_distance_from_objects()) &&
v1.get_geometry_handling() == v2.get_geometry_handling() &&
v1.get_xl_alignment() == v2.get_xl_alignment();
;
--- a/tests/fff_print/test_avoid_crossing_perimeters.cpp
+++ b/tests/fff_print/test_avoid_crossing_perimeters.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_data.hpp"
--- a/tests/fff_print/test_bridges.cpp
+++ b/tests/fff_print/test_bridges.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
--- a/tests/fff_print/test_clipper.cpp
+++ b/tests/fff_print/test_clipper.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_data.hpp"
#include "libslic3r/ClipperZUtils.hpp"
--- a/tests/fff_print/test_cooling.cpp
+++ b/tests/fff_print/test_cooling.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
--- a/tests/fff_print/test_custom_gcode.cpp
+++ b/tests/fff_print/test_custom_gcode.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
--- a/tests/fff_print/test_data.cpp
+++ b/tests/fff_print/test_data.cpp
@@ -367,7 +367,7 @@
} } // namespace Slic3r::Test
-#include
+#include
SCENARIO("init_print functionality", "[test_data]") {
GIVEN("A default config") {
--- a/tests/fff_print/test_extrusion_entity.cpp
+++ b/tests/fff_print/test_extrusion_entity.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include
@@ -11,6 +11,7 @@
#include "test_data.hpp"
using namesp
Bug#1054697: [3dprinter-general] Bug#1054697: slic3r-prusa: FTBFS: test_arrange.cpp:1:10: fatal error: catch2/catch.hpp: No such file or directory
Hi,
If that's an intentional upstream change, reassigning to catch2 won't
help as it's not a bug in that package.
Got it.
In the meantime, I prepared a patch to fix compatibility with Catch2 v3
(attached). I haven't submitted it upstream yet, but I'd appreciate any
feedback.
The biggest changes were around floating point value comparisons.
I had to tweak some unit tests, because the previous approximations in
Catch2 are no longer available, and the replacement functionality uses a
different algorithm. In fact, there's three algorithms now, and I chose
the one that seems most appropriate to me for what slic3r does. I
believe there is no change in correctness, the results should be well
within acceptable limits.
Regards,
GregFrom: Gregor Riepl
Date: Tue, 31 Oct 2023 19:37:00 +0100
Subject: Catch2 v3 updates
Bug-Debian: https://bugs.debian.org/1054697
---
tests/CMakeLists.txt | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -12,7 +12,7 @@
add_library(test_common INTERFACE)
target_compile_definitions(test_common INTERFACE TEST_DATA_DIR=R"\(${TEST_DATA_DIR}\)" CATCH_CONFIG_FAST_COMPILE)
-target_link_libraries(test_common INTERFACE Catch2::Catch2)
+target_link_libraries(test_common INTERFACE Catch2::Catch2WithMain)
target_include_directories(test_common INTERFACE ${CMAKE_CURRENT_LIST_DIR})
if (APPLE)
target_link_libraries(test_common INTERFACE "-liconv -framework IOKit" "-framework CoreFoundation" -lc++)
--- a/tests/arrange/test_arrange.cpp
+++ b/tests/arrange/test_arrange.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_utils.hpp"
#include
@@ -40,6 +40,8 @@
#include
+using Catch::Matchers::WithinRel;
+
template
static std::vector prusa_parts(double infl = 0.) {
using namespace Slic3r;
@@ -930,7 +932,7 @@
Slic3r::Vec2crd D = bed.center - item.shape.center();
REQUIRE(item.translation == D);
-REQUIRE(score == Approx(0.).margin(EPSILON));
+REQUIRE_THAT(score, WithinRel(0., EPSILON));
}
}
}
@@ -1063,7 +1065,7 @@
bool packed = pack(strategy, bed, itm);
REQUIRE(packed);
-REQUIRE(get_rotation(itm) == Approx(PI));
+REQUIRE_THAT(get_rotation(itm), WithinRel(PI));
}
//TEST_CASE("NFP optimizing test", "[arrange2]") {
--- a/tests/arrange/test_arrange_integration.cpp
+++ b/tests/arrange/test_arrange_integration.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_utils.hpp"
#include
@@ -12,6 +12,8 @@
#include "libslic3r/Format/3mf.hpp"
#include "libslic3r/ModelArrange.hpp"
+using Catch::Matchers::WithinRel;
+
static Slic3r::Model get_example_model_with_20mm_cube()
{
using namespace Slic3r;
@@ -560,10 +562,10 @@
auto ref_pos = tr * Vec3d::Zero();
auto displace = bed_index * (unscaled(vbh.stride_scaled()));
-REQUIRE(ref_pos.x() == Approx(-displace));
+REQUIRE_THAT(ref_pos.x(), WithinRel(-displace));
auto ref_pos_mi = mi_to_move.get_matrix() * Vec3d::Zero();
-REQUIRE(ref_pos_mi.x() == Approx(instance_displace.x() + (bed_index >= 0) * displace));
+REQUIRE_THAT(ref_pos_mi.x(), WithinRel(instance_displace.x() + (bed_index >= 0) * displace));
}
}
}
@@ -868,8 +870,8 @@
{
return v1.is_rotation_enabled() == v2.is_rotation_enabled() &&
v1.get_arrange_strategy() == v2.get_arrange_strategy() &&
- v1.get_distance_from_bed() == Approx(v2.get_distance_from_bed()) &&
- v1.get_distance_from_objects() == Approx(v2.get_distance_from_objects()) &&
+ WithinRel(v2.get_distance_from_bed()).match(v1.get_distance_from_bed()) &&
+ WithinRel(v2.get_distance_from_objects()).match(v1.get_distance_from_objects()) &&
v1.get_geometry_handling() == v2.get_geometry_handling() &&
v1.get_xl_alignment() == v2.get_xl_alignment();
;
--- a/tests/fff_print/test_avoid_crossing_perimeters.cpp
+++ b/tests/fff_print/test_avoid_crossing_perimeters.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_data.hpp"
--- a/tests/fff_print/test_bridges.cpp
+++ b/tests/fff_print/test_bridges.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
--- a/tests/fff_print/test_clipper.cpp
+++ b/tests/fff_print/test_clipper.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include "test_data.hpp"
#include "libslic3r/ClipperZUtils.hpp"
--- a/tests/fff_print/test_cooling.cpp
+++ b/tests/fff_print/test_cooling.cpp
@@ -1,4 +1,4 @@
-#include
+#include
#include
#include
--- a/tests/fff_print/test_custom_gcode.cpp
+++ b/tests/fff_print/test_custom_gcode.cpp
@@ -1,4 +1,4 @@
-#include
Bug#1054697: [3dprinter-general] Bug#1054697: slic3r-prusa: FTBFS: test_arrange.cpp:1:10: fatal error: catch2/catch.hpp: No such file or directory
Hi, > fatal error: catch2/catch.hpp: No such file or directory This is caused by significant changes in catch2 3.4.0. Some other packages are affected by the same problem, which currently blocks migration: https://qa.debian.org/excuses.php?package=catch2 I think this bug should be: reassign -1 catch2 affects -1 slic3r-prusa Are there any objections if I do this? Upstream slic3r-prusa supplies a bundled copy of catch2, so they may be reluctant to upgrade compatibility with catch2 3.x. We could switch back to the bundled copy for the time being. As an alternative, we could try to fix the dependency for Debian only. It looks like some effort will be needed, though: https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md
Bug#1054026: packagekitd crashes with "assertion failed: (transaction->priv->emitted_finished)" (SIGABRT)
Package: packagekit Version: 1.2.7-1 Severity: important Tags: upstream Forwarded: https://github.com/PackageKit/PackageKit/issues/656 X-Debbugs-Cc: onit...@gmail.com The PackageKit daemon () crashes regularly with a SIGABRT due to a failed assertion: domain="PackageKit", file="../src/pk-transaction.c", line=5528, func="pk_transaction_dispose", message="assertion failed: (transaction->priv->emitted_finished)" This makes software that uses PackageKit (such as KDE Discover) partially unusable. The issue was fixed upstream, but hasn't been released yet. Please include patch 83cc46eae3ad9f95f6aae3b7bc3bb01207b06711 (see upstream issue) in the Debian release, or push a new version as soon as it's released. Thank you. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages packagekit depends on: ii init-system-helpers 1.65.2 ii libappstream4 0.16.3-1 ii libapt-pkg6.0 2.7.6 ii libc6 2.37-12 ii libgcc-s1 13.2.0-4 ii libglib2.0-02.78.0-2 ii libglib2.0-bin 2.78.0-2 ii libgstreamer1.0-0 1.22.6-1 ii libpackagekit-glib2-18 1.2.7-1 ii libpolkit-gobject-1-0 123-1 ii libsqlite3-03.43.1-1 ii libstdc++6 13.2.0-4 ii libsystemd0 254.5-1 ii polkitd 123-1 Versions of packages packagekit recommends: ii appstream 0.16.3-1 ii packagekit-tools 1.2.7-1 ii systemd 254.5-1 packagekit suggests no packages. -- Configuration Files: /etc/dbus-1/system.d/org.freedesktop.PackageKit.conf [Errno 2] No such file or directory: '/etc/dbus-1/system.d/org.freedesktop.PackageKit.conf' -- no debconf information
Bug#1053285: AttributeError: 'PlatformioCLI' object has no attribute 'resultcallback'
Package: platformio
Version: 4.3.4-3
Severity: grave
Justification: renders package unusable
Forwarded: https://github.com/platformio/platformio-core/issues/4075
X-Debbugs-Cc: onit...@gmail.com
Dear Maintainer,
The current version of PlatformIO in Debian no longer works with python3-click
due to the following incompatibility:
AttributeError: 'PlatformioCLI' object has no attribute 'resultcallback'. Did
you mean: 'result_callback'?
This issue has been fixed in PlatformIO 5.2.1.
Preferably, update to the latest upstream version (6.1.11 currently).
Thanks!
Full stack trace:
Traceback (most recent call last):
File "/usr/bin/platformio", line 33, in
sys.exit(load_entry_point('platformio==4.3.4', 'console_scripts',
'platformio')())
^^
File "/usr/bin/platformio", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1204, in _gcd_import
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/platformio/__main__.py", line 66, in
@cli.resultcallback()
^^
AttributeError: 'PlatformioCLI' object has no attribute 'resultcallback'. Did
you mean: 'result_callback'?
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages platformio depends on:
ii python3 3.11.4-5+b1
ii python3-bottle0.12.23-1.2
ii python3-click 8.1.6-1
ii python3-colorama 0.4.6-4
ii python3-marshmallow 3.18.0-1
ii python3-pyelftools0.30-1
ii python3-requests 2.31.0+dfsg-1
ii python3-semantic-version 2.9.0-2
ii python3-serial3.5-1.1
ii python3-tabulate 0.8.9-1
platformio recommends no packages.
Versions of packages platformio suggests:
pn platformio-doc
-- no debconf information
Bug#1050993: podman: Podman should use overlay storage driver by default instead of vfs
Hi Reinhard, I've now worked on packaging 4.6.2, and it is currently available in debian/experimental. Can you do me a favor? Please test it and let me know whether it fixes this issue. Thanks, it looks very promising! On a system without any storage.conf files, but with existing vfs container storage, podman kept using the vfs driver. Trying to force the overlay driver with --storage-driver overlay resulted in an error, as expected. After removing ~.local/share/containers it started using the overlay driver automatically. Trying to force vfs resulted in an error, also as expected. I think this is very sensible behavior and a news message may not even be required. On the other hand, existing vfs users would miss out on the advantages of overlay storage. Since migration is not trivial, it might be helpful to include migration instructions. I'm happy to add a note in NEWS.Debian, which is going to be presented on package upgrades. Can you please provide a wording for that text that you would have been useful to you? How about this? Podman 4.6 changes the default storage driver from vfs to overlay. The overlay driver has been available for some time, but it had to be enabled explicitly in the Debian version of podman. The overlay driver is generally much faster and uses less disk space than the vfs driver. . To take advantage of overlay, it's necessary to delete local container storage. Make sure to save or export any images, containers and volumes before doing so, or you will lose them! . Some helpful commands: . # save the filesystem of a container podman export -o important-container.tar important_container # save a volume podman volume export -o important-volume.tar important_volume # save all container images podman save -o images.tar # delete ~/.local/share/containers # check that podman is using the overlay driver podman info | grep graphDriverName # re-import all container images podman load -i images.tar # re-import a saved container filesystem as a container image podman import important-container.tar # re-import a volume podman volume import important_volume important-volume.tar Maybe some web links could be helpful. I haven't found anything complete though.
Bug#1050993: podman: Podman should use overlay storage driver by default instead of vfs
As mentioned in the upstream bug report[1], the fix is actually in containers/storage 1.48, included with podman 4.6 and not 4.5. So, the bug can (hopefully) be fixed for good when this version is packaged. It might also be helpful to include a what's new message, to make users aware they need to reset their storage after upgrading. There doesn't seem to be an easy way to convert vfs containers or images to overlay. [1] https://github.com/containers/podman/issues/19811#issuecomment-1716344802
Bug#1051807: openjdk-17-jre: system look defaults to non-native Metal theme, GTK theme isn't enabled by default
Package: openjdk-17-jre
Version: 17.0.9~4ea-1
Severity: normal
X-Debbugs-Cc: onit...@gmail.com
The OpenJDK version in Debian includes the GTK+ theme, but the
SystemLookAndFeelClassName is set to the default Swing Metal theme.
Manually loading the GTK+ theme works, but this is very unportable and
shouldn't be necessary.
Instead, the following code should use the native GTK+ theme:
import java.awt.*;
import javax.swing.*;
public class Test {
public static void main(String[] args) {
try {
System.out.println("System look class: " +
UIManager.getSystemLookAndFeelClassName());
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
// This shouldn't be necessary:
//
UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel");
} catch (Exception e) {
System.err.println("Can't find native look: " + e);
}
JFrame frame = new JFrame();
frame.getContentPane().setLayout(new FlowLayout());
frame.setSize(new Dimension(200, 200));
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.getContentPane().add(new JButton("Button 1"));
frame.getContentPane().add(new JButton("Button 2"));
frame.getContentPane().add(new JButton("Button 3"));
frame.setVisible(true);
}
}
Is this by design, or would it be possible to change the system theme to the
native one?
Metal doesn't really fit well with most modern desktops, and the GTK+ theme
would at least make Java applications match the system GTK theme.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable'), (300, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages openjdk-17-jre depends on:
ii libc62.37-7
ii libgif7 5.2.1-2.5
ii libgl1 1.6.0-1
ii libglib2.0-0 2.77.3-1
ii libgtk-3-0 3.24.38-4
ii libgtk2.0-0 2.24.33-2
ii libharfbuzz0b8.0.1-1
ii libjpeg62-turbo 1:2.1.5-2
ii libpng16-16 1.6.40-1
ii libx11-6 2:1.8.6-1
ii libxext6 2:1.3.4-1+b1
ii libxi6 2:1.8-1+b1
ii libxinerama1 2:1.1.4-3
ii libxrandr2 2:1.5.2-2+b1
ii libxrender1 1:0.9.10-1.1
ii libxtst6 2:1.2.3-1.1
ii openjdk-17-jre-headless 17.0.9~4ea-1
ii zlib1g 1:1.2.13.dfsg-3
Versions of packages openjdk-17-jre recommends:
ii fonts-dejavu-extra 2.37-8
ii libatk-wrapper-java-jni 0.40.0-3
openjdk-17-jre suggests no packages.
-- no debconf information
Bug#1050993: podman: Podman should use overlay storage driver by default instead of vfs
Package: podman
Version: 4.5.1+ds1-2
Followup-For: Bug #1050993
X-Debbugs-Cc: onit...@gmail.com
Control: found -1
Thanks for upgrading the package, but it looks like the issue isn't fixed in
4.5 after all.
After upgrading and removing /etc/containers/storage.conf (to revert to default
behavior), I'm now facing the following error:
ERRO[] User-selected graph driver "vfs" overwritten by graph driver
"overlay" from database - delete libpod local files
("/home/user/.local/share/containers/storage") to resolve. May prevent use of
images created by other tools
This indicates that the vfs driver was autoselected, despite overlay being
available.
In fact, if I explicitly run podman with the option "--storage-driver overlay",
it works fine.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.1.6+ds1-1
ii golang-github-containers-common 0.50.1+ds1-4
ii libc62.37-7
ii libdevmapper1.02.1 2:1.02.185-2
ii libgpgme11 1.18.0-3+b1
ii libseccomp2 2.5.4-1+b3
ii libsqlite3-0 3.43.0-1
ii libsubid41:4.13+dfsg1-1+b1
ii runc 1.1.5+ds1-1+b2
Versions of packages podman recommends:
ii buildah1.30.0+ds1-3
ii dbus-user-session 1.14.10-1
ii slirp4netns1.2.0-1
ii tini 0.19.0-1
ii uidmap 1:4.13+dfsg1-1+b1
Versions of packages podman suggests:
pn containers-storage
pn docker-compose
ii fuse-overlayfs 1.10-1
ii iptables1.8.9-2
-- Configuration Files:
/etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied:
'/etc/cni/net.d/87-podman-bridge.conflist'
-- no debconf information
Bug#1050993: podman: Podman should use overlay storage driver by default instead of vfs
Package: podman Version: 4.4.0+ds1-1 Severity: normal Forwarded: https://github.com/containers/podman/issues/19811 X-Debbugs-Cc: onit...@gmail.com The vfs storage driver in Podman has been the recommended upstream default up until 4.4, but there isn't really a good reason to use it any more. The overlay driver is faster and more conservative in most cases. Please upgrade Podman to 4.5+ (4.6.3 is current) in Debian, or add the configuration file /etc/containers/storage.conf with the following contents: [storage] driver = "overlay" For reference, I ran into a serious storage explosion with the vfs driver recently: https://github.com/containers/podman/issues/19811 This issue doesn't occur with the overlay driver. Thanks! -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.1.6+ds1-1 ii golang-github-containers-common 0.50.1+ds1-4 ii libc62.37-7 ii libdevmapper1.02.1 2:1.02.185-2 ii libgpgme11 1.18.0-3+b1 ii libseccomp2 2.5.4-1+b3 ii libsubid41:4.13+dfsg1-1+b1 ii runc 1.1.5+ds1-1+b2 Versions of packages podman recommends: ii buildah1.29.0+ds1-1 ii dbus-user-session 1.14.8-2 ii fuse-overlayfs 1.10-1 ii slirp4netns1.2.0-1 ii tini 0.19.0-1 ii uidmap 1:4.13+dfsg1-1+b1 Versions of packages podman suggests: pn containers-storage pn docker-compose ii iptables1.8.9-2 -- Configuration Files: /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied: '/etc/cni/net.d/87-podman-bridge.conflist' -- no debconf information
Bug#1042818: firmware-amd-graphics: Random display freezes on certain AMD GPUs
Package: firmware-amd-graphics Version: 20230515-3 Tags: fixed-upstream, upstream Followup-For: Bug #1042818 X-Debbugs-Cc: onit...@gmail.com linux-firmware 20230804 has been released and contains the mentioned reverts for amdgpu firmware. This is not a permanent fix of the underlying problem, but it will at least allow systems to function normally again. Please update as soon as possible. This should also fix #1040185, but for that issue, a backport to bookworm may be required. Thanks. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1043024: amdgpu: When updating I get a "Possible missing firmware /lib/firmware/amdgpu/modules" (Sapphire Nitro R9 390)
Package: firmware-amd-graphics Version: 20230515-3 Followup-For: Bug #1043024 X-Debbugs-Cc: onit...@gmail.com Can you post which firmware files are missing exactly? dmesg should give you all the needed information. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1042466: AttributeError: module 'eventlet.green.select' has no attribute 'epoll'
Here's a temporary workaround until the issue is fixed. Either set the environment variable EVENTLET_NO_GREENDNS to "yes" before launching applications that import eventlet, or put the following Python code before loading the module: import os os.environ['EVENTLET_NO_GREENDNS'] = 'yes' import eventlet ...
Bug#1042818: firmware-amd-graphics: Random display freezes on certain AMD GPUs due to "Error waiting for DMUB idle: status=3"
Package: firmware-amd-graphics Version: 20230515-3 Severity: important Tags: upstream Forwarded: https://gitlab.freedesktop.org/drm/amd/-/issues/1887 X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, The current AMDGPU firmware in Debian has compatibility issues with 6.3+ kernels. These errors manifest themselves with kernel messages like these: [ +0.226777] [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 [ +4.020959] [drm:dc_dmub_setup_subvp_dmub_command [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 Furthermore, they cause sudden display freezes and even GPU lock-ups that require power-cycling the system. It's not clear why these problems occur, but they might have to do with certain optimizations that AMD had to do to reduce power consumption at idle on RX 7000 series GPUs. See https://gitlab.freedesktop.org/drm/amd/-/issues/2315 for more information about this issue. As a temporary workaround, it's possible to avoid the power management optimizations by reducing the overall pixel clock rate or creating modelines with a longer blanking delay, as long as the display supports this. For example, reducing the refresh rate from 120Hz to 60Hz has helped in one case for me. Another workaround is to disable optimizations in the affected firmware with the kernel option drm.vblankoffdelay=0 . As stated in https://gitlab.freedesktop.org/drm/amd/-/issues/1887#note_1993615 , the problematic firmware changes were reverted in https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- firmware.git/commit/?id=d3f66064cf43bd7338a79174bd0ff60c4ecbdf6d , and there have been several amdgpu firmware commits since. Please update linux-firmware as soon a release containing the revert or a permanent fix is available. Thanks. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1039859: mixxx: Mixxx GUI is broken / elements not rendered
Package: mixxx Version: 2.3.5+dfsg-1+b1 Severity: important Followup-For: Bug #1039859 X-Debbugs-Cc: onit...@gmail.com This issue does not occur for me on X.org. While the rendering of album covers and the waveforms is suboptimal (lack of interpolation, movement jitter, transparency issues at the edges), it works without issue for me. There was no change in rendering in bookworm, or even trixie/sid. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mixxx depends on: ii libavcodec607:6.0-4 ii libavformat60 7:6.0-4 ii libavutil58 7:6.0-4 ii libc6 2.37-6 ii libchromaprint1 1.5.1-3 ii libebur128-11.2.6-1+b1 ii libflac12 1.4.3+ds-2 ii libgcc-s1 13.1.0-9 ii libglib2.0-02.76.4-4 ii libhidapi-libusb0 0.14.0-1 ii libid3tag0 0.15.1b-14 ii liblilv-0-0 0.24.14-1 ii libmad0 0.15.1b-10.1+b1 ii libmodplug1 1:0.8.9.0-3 ii libmp3lame0 3.100-6 ii libogg0 1.3.5-3 ii libopus01.4-1 ii libopusfile00.12-4 ii libportaudio2 19.6.0-1.2 ii libportmidi01:217-6.1 ii libprotobuf-lite32 3.21.12-6 ii libqt5core5a5.15.10+dfsg-2 ii libqt5dbus5 5.15.10+dfsg-2 ii libqt5gui5 5.15.10+dfsg-2 ii libqt5keychain1 0.14.1-1 ii libqt5network5 5.15.10+dfsg-2 ii libqt5opengl5 5.15.10+dfsg-2 ii libqt5script5 5.15.10+dfsg-2 ii libqt5scripttools5 5.15.10+dfsg-2 ii libqt5sql5 5.15.10+dfsg-2 ii libqt5sql5-sqlite 5.15.10+dfsg-2 ii libqt5svg5 5.15.10-2 ii libqt5widgets5 5.15.10+dfsg-2 ii libqt5x11extras55.15.10-2 ii libqt5xml5 5.15.10+dfsg-2 ii librubberband2 3.2.1+dfsg-6 ii libsndfile1 1.2.0-1 ii libsoundtouch1 2.3.2+ds1-1 ii libsqlite3-03.42.0-1 ii libssl3 3.0.9-1 ii libstdc++6 13.1.0-9 ii libswresample4 7:6.0-4 ii libtag1v5 1.13.1-1 ii libupower-glib3 0.99.20-2 ii libusb-1.0-02:1.0.26-1 ii libvorbis0a 1.3.7-1 ii libvorbisenc2 1.3.7-1 ii libvorbisfile3 1.3.7-1 ii libwavpack1 5.6.0-1 ii libx11-62:1.8.6-1 ii mixxx-data 2.3.5+dfsg-1 mixxx recommends no packages. Versions of packages mixxx suggests: ii okular [pdf-viewer] 4:22.12.3-1 -- no debconf information
Bug#1042466: AttributeError: module 'eventlet.green.select' has no attribute 'epoll'
Package: python3-eventlet
Version: 0.33.1-4
Severity: important
Tags: upstream
Forwarded: https://github.com/eventlet/eventlet/issues/805
X-Debbugs-Cc: onit...@gmail.com
Control: affects -1 cura
Dear Maintainer,
The eventlet module has a known incompatibility with dnspython 0.24, that
causes it to throw exceptions of the form: AttributeError: module
'eventlet.green.select' has no attribute 'epoll'
One example is cura 5.0.0, which won't start start any more due to this bug
(full report further below):
/usr/lib/python3/dist-packages/eventlet/support/greenlets.py:6:
DeprecationWarning: distutils Version classes are deprecated. Use
packaging.version instead.
preserves_excinfo = (distutils.version.LooseVersion(greenlet.__version__)
...
File "/usr/bin/cura", line 30, in
import sentry_sdk
...
File "/usr/lib/python3/dist-packages/trio/_core/_io_epoll.py", line 190, in
EpollIOManager
_epoll = attr.ib(factory=select.epoll)
AttributeError: module 'eventlet.green.select' has no attribute 'epoll'
Please provide a fix for this issue as soon as one is available from upstream,
or pin to dnspython to 0.23 until this is fixed (which would break on
sid/trixie, because dnspython 0.23 isn't available there).
Thanks.
Full output from cura:
/usr/lib/python3/dist-packages/UM/PluginRegistry.py:4: DeprecationWarning: the
imp module is deprecated in favour of importlib and slated for removal in
Python 3.12; see the module's documentation for alternative uses
import imp
/usr/lib/python3/dist-packages/eventlet/support/greenlets.py:6:
DeprecationWarning: distutils Version classes are deprecated. Use
packaging.version instead.
preserves_excinfo = (distutils.version.LooseVersion(greenlet.__version__)
Traceback (most recent call last):
File "/usr/bin/cura", line 30, in
import sentry_sdk
File "/usr/lib/python3/dist-packages/sentry_sdk/__init__.py", line 1, in
from sentry_sdk.hub import Hub, init
File "/usr/lib/python3/dist-packages/sentry_sdk/hub.py", line 8, in
from sentry_sdk.scope import Scope
File "/usr/lib/python3/dist-packages/sentry_sdk/scope.py", line 7, in
from sentry_sdk.utils import logger, capture_internal_exceptions
File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 925, in
HAS_REAL_CONTEXTVARS, ContextVar = _get_contextvars()
^^
File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 895, in
_get_contextvars
if not _is_contextvars_broken():
File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 856, in
_is_contextvars_broken
from eventlet.patcher import is_monkey_patched # type: ignore
^^
File "/usr/lib/python3/dist-packages/eventlet/__init__.py", line 17, in
from eventlet import convenience
File "/usr/lib/python3/dist-packages/eventlet/convenience.py", line 7, in
from eventlet.green import socket
File "/usr/lib/python3/dist-packages/eventlet/green/socket.py", line 21, in
from eventlet.support import greendns
File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 79,
in
setattr(dns, pkg, import_patched('dns.' + pkg))
File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 61,
in import_patched
return patcher.import_patched(module_name, **modules)
^^
File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 132, in
import_patched
return inject(
^^^
File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 109, in
inject
module = __import__(module_name, {}, {}, module_name.split('.')[:-1])
File "/usr/lib/python3/dist-packages/dns/asyncquery.py", line 38, in
from dns.query import (
File "/usr/lib/python3/dist-packages/dns/query.py", line 63, in
import httpcore
File "/usr/lib/python3/dist-packages/httpcore/__init__.py", line 1, in
from ._api import request, stream
File "/usr/lib/python3/dist-packages/httpcore/_api.py", line 5, in
from ._sync.connection_pool import ConnectionPool
File "/usr/lib/python3/dist-packages/httpcore/_sync/__init__.py", line 1, in
from .connection import HTTPConnection
File "/usr/lib/python3/dist-packages/httpcore/_sync/connection.py", line 12,
in
from .._synchronization import Lock
File "/usr/lib/python3/dist-packages/httpcore/_synchronization.py", line 13,
in
import trio
File "/usr/lib/python3/dist-packages/trio/__init__.py", line 19, in
from ._core import TASK_STATUS_IGNORED as TASK_STATUS_IGNORED # isort:
skip
^
File "/usr/lib/python3/dist-packages/trio/_core/__init__.py", line 21, in
from ._local import RunVar
Bug#1042157: [3dprinter-general] Bug#1042157: uranium: FTBFS: dh_install: error: missing files, aborting
purelib: directory for site-specific, non-platform-specific files
(https://docs.python.org/3/library/sysconfig.html)
"site-specific" doesn't sound like packages should install anything
there.
"site-specific" may be meant from the perspective of the Python
interpreter, not the whole system, so it does sound correct to me -
especially if you consider that Python modules are separated into the
standard library and dist-packages.
> Perhaps the bug is that Python_SITELIB is used and it should be
> something else?
I've tried Python_STDLIB (=sysconfig.get_path('stdlib')), but that's
definitely wrong: It points to /usr/lib/python3.11
Python packages are normally installed into
/usr/lib/python3/dist-packages/ (or /usr/lib/python3.11/dist-packages/
if they're interpreter-specific). Uranium used to be installed into
/usr/lib/python3/dist-packages/, because it's a pure Python library and
doesn't depend on the interpreter version.
Python_STDARCH and Python_SITEARCH have the same values as Python_STDLIB
and Python_SITELIB, and I don't see any other useful FindPython[1]
variables.
IMHO, Python_SITELIB is still the best choice, unless there's some other
way to install Python modules in cmake that doesn't involve these variables.
I'm going to ask the debian-python list for help, perhaps they know more
about the correct paths to use.
In the meantime, I do think this issue should block cmake 3.27 migration
until we've sorted it out, so the bug should be reassigned to cmake.
[1] https://cmake.org/cmake/help/latest/module/FindPython.html
Bug#1042157: uranium: FTBFS: dh_install: error: missing files, aborting
Source: uranium
Version: 5.0.0-2
Followup-For: Bug #1042157
X-Debbugs-Cc: onit...@gmail.com
This is caused by a change in cmake 3.27.
In 3.26.4-4, Python_SITELIB is /usr/lib/python3/dist-packages.
In 3.27.1-1, it's /usr/local/lib/python3.11/dist-packages
The documentation for 3.26 states:
> Information returned by
> distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False) or
> else sysconfig.get_path('purelib').
And for 3.27:
> Information returned by sysconfig.get_path('purelib').
I'm not sure if Debian overrides this in any way, but it's certainly a
regression.
Should I reassign this bug to the cmake package?
Bug#1042157: [3dprinter-general] Bug#1042157: uranium: FTBFS: dh_install: error: missing files, aborting
-- Installing: /<>/debian/tmp/usr/local/lib/python3.11/dist-packages/UM -- Installing: /<>/debian/tmp/usr/local/lib/python3.11/dist-packages/UM/ColorImage.py dh_install: warning: Cannot find (any matches for) "usr/lib/python3/dist-packages/UM" (tried in ., debian/tmp) dh_install: warning: python3-uranium missing files: usr/lib/python3/dist-packages/UM dh_install: error: missing files, aborting make: *** [debian/rules:7: binary] Error 25 Those are very strange results. No files should end up in /usr/local! And I haven't been able to reproduce this locally yet. Investigation ongoing...
Bug#1041808: cura-engine: Several unit test failures on i686
Here's an excerpt of the failing tests: test 21 Start 21: PolygonConnectorTest 21: Test command: cura-engine/obj-i686-linux-gnu/PolygonConnectorTest 21: Working Directory: cura-engine/tests/ 21: Test timeout computed to be: 1500 5: [ OK ] InfillTestcases/InfillTest.TestInfillSanity/InfillTestParameters_P6_Z0_C1_L600__2 (5 ms) 5: [ RUN ] InfillTestcases/InfillTest.TestInfillSanity/InfillTestParameters_P6_Z0_C0_L800__2 6: [ OK ] AllCombinations/AddTravelTest.NoRetractionIfDisabled/62 (4 ms) 6: [ RUN ] AllCombinations/AddTravelTest.NoRetractionIfDisabled/63 21: [==] Running 6 tests from 1 test suite. 21: [--] Global test environment set-up. 21: [--] 6 tests from PolygonConnectorTest 21: [ RUN ] PolygonConnectorTest.getBridgeNestedSquares 21: ./tests/utils/PolygonConnectorTest.cpp:71: Failure 21: Expected equality of these values: 21: LinearAlg2D::getDist2BetweenLineSegments(bridge->a.from_point, bridge->a.to_point, bridge->b.from_point, bridge->b.to_point) 21: Which is: 9801 21: 100 * 100 21: Which is: 1 21: The bridges should be spaced 1 line width (100 units) apart. 21: [ FAILED ] PolygonConnectorTest.getBridgeNestedSquares (0 ms) 21: [ RUN ] PolygonConnectorTest.getBridgeAdjacentSquares 21: ./tests/utils/PolygonConnectorTest.cpp:91: Failure 21: Expected equality of these values: 21: LinearAlg2D::getDist2BetweenLineSegments(bridge->a.from_point, bridge->a.to_point, bridge->b.from_point, bridge->b.to_point) 21: Which is: 9801 21: 100 * 100 21: Which is: 1 21: The bridges should be spaced 1 line width (100 units) apart. test 18 Start 18: IntPointTest 18: Test command: cura-engine/obj-i686-linux-gnu/IntPointTest 18: Working Directory: cura-engine/tests/ 18: Test timeout computed to be: 1500 18: [==] Running 1 test from 1 test suite. 18: [--] Global test environment set-up. 18: [--] 1 test from IntPointTest 18: [ RUN ] IntPointTest.TestRotationMatrix 18: ./tests/utils/IntPointTest.cpp:24: Failure 18: Expected equality of these values: 18: rotated_in_place 18: Which is: (11,20) 18: rotated_in_place_2 18: Which is: (10,20) 18: Matrix composition with translate and rotate failed. 18: [ FAILED ] IntPointTest.TestRotationMatrix (0 ms) 18: [--] 1 test from IntPointTest (0 ms total) 18: 18: [--] Global test environment tear-down 18: [==] 1 test from 1 test suite ran. (0 ms total) 18: [ PASSED ] 0 tests. 18: [ FAILED ] 1 test, listed below: 18: [ FAILED ] IntPointTest.TestRotationMatrix 18: 18: 1 FAILED TEST 15/26 Test #18: IntPointTest .***Failed0.00 sec [==] Running 1 test from 1 test suite. [--] Global test environment set-up. [--] 1 test from IntPointTest [ RUN ] IntPointTest.TestRotationMatrix ./tests/utils/IntPointTest.cpp:24: Failure Expected equality of these values: rotated_in_place Which is: (11,20) rotated_in_place_2 Which is: (10,20) Matrix composition with translate and rotate failed. [ FAILED ] IntPointTest.TestRotationMatrix (0 ms) [--] 1 test from IntPointTest (0 ms total) [--] Global test environment tear-down [==] 1 test from 1 test suite ran. (0 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] IntPointTest.TestRotationMatrix
Bug#1041808: cura-engine: Several unit test failures on i686
Source: cura-engine Version: 5.0.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Usertags: i686 Forwarded: https://github.com/Ultimaker/CuraEngine/issues/1192 X-Debbugs-Cc: onit...@gmail.com On i686, CuraEngine 5.x fails to build due to failing unit tests. This is a longstanding issue, going back to 4.4, where it was fixed by adding a larger tolerance to test values. However, the issue was not investigated thoroughly and returns in 5.0 with more failing unit tests. The root cause of these failures are rounding errors on i686, where the x87 FPU produces different results than floating point units in other processors. These differences are tiny, and usually not more than a few ULPs. CuraEngine uses integer math in most places, but resorts to double-precision floating-point calculations in certain cases. Afterwards, the results are truncated to 64-bit integers (C type long long), and subsequent calculation is done on the integer values. Truncation (aka round-toward-zero) is often ok and works fine on amd64 (SSE2 floating-point math) and other CPUs, but produces different results on the x87 FPU. When truncating, these produce off-by-one errors in many cases, and the these errors can accumulate and lead to huge differences in the unit tests. By strategically adding explicit rounding (round-to-nearest) in the right places, these errors can be eliminated. While this will produce subtly different results in some cases, it is arguably more correct than always truncating. And at least on amd64, there is no performance difference between truncation and rounding: The SSE2 CVTTSD2SI and CVTSD2SI instructions have the same performance. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1037593: binutils-avr: ftbfs with GCC-13
Upstream has fixed this via https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5b429b870767e2107bcc7d5d849e04d6901b5912 Thanks for uploading the fix. Unfortunately, it looks like the buildds are still choking on it: https://buildd.debian.org/status/package.php?p=binutils-avr # Convert hardlinks to softlinks cd debian/binutils-avr/usr/lib/avr/bin && for f in *; do \ rm ../../../bin/avr-$f; \ ln -s ../lib/avr/bin/$f ../../../bin/avr-$f; \ done /bin/sh: 1: cd: can't cd to debian/binutils-avr/usr/lib/avr/bin make: *** [debian/rules:88: install] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2 Could you take a look? Thanks!
Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"
I'm sorry Gregor, this is what happened, I mis-reported against 4.13. I hope it wasn't too much of a time waste. Fixing 5.0.0 should be sufficient. Thank you. All right - I went ahead and marked the correct version. It looks the next release is still on hold because of an old FPU rounding issue affecting i686. I hope I can get that fixed shortly.
Bug#1037614: [3dprinter-general] Bug#1037614: cura-engine: ftbfs with GCC-13
thanks for collecting all the patches and putting them together. There's still an issue on i386 left, and at least from looking at the CI tests, it might have been caused by this fix: https://salsa.debian.org/3dprinting-team/cura-engine/-/pipelines Any ideas? Very interesting! I couldn't reproduce it in a i686 chroot, but after upgrading all packages (including gcc 13), I'm getting it as well. So the missing include was just the tip of the iceberg and we're seeing some real errors on 32 bit now. I'll look into, the error looks vaguely familiar...
Bug#1028507: digikam: downloads binary blobs from the internet
> Could that please be disabled? It's coming in version 8. > a) It's a security risk. It's aboslutely unclear who controls these files >(at least not debian). I hear your concerns. These files are data that used to be shipped as part of digikam and were later unbundled, which led to the download prompt. You can read through the upstream bug for a full discussion. That fixes the immediate issue, but it still doesn't answer the question if it's legitimate that an application packaged for the Debian main archive would ask for additional downloads from a 3rd party server to enable full functionality. Would it be possible to create a separate Debian package with this data and add it as a Recommends: dependency? I believe there is enough precedent for large optional companion data packages in Debian. (0ad-data and kicad-packages3d come to mind) This would make it much clearer what the user is getting and from whom, and it would reduce the burden on the upstream CDN.
Bug#1037614: cura-engine: ftbfs with GCC-13
The package fails to build in a test rebuild on at least amd64 with gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The severity of this report will be raised before the trixie release. This issue was due to a missing #include , and it was already fixed upstream in an unrelated commit. I pushed a patch to Salsa together with two other bug fixes, but I'm waiting for a DD to upload it since I can't do that myself.
Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"
Hi Dan, I tested the upstream CuraEngine commit and then realized that refreshing it results in the same patch as yours, so I pushed your version instead. Now, I'm slightly confused about the version you reported this against. According to the report, it affects 4.13, but the changes requiring the patch weren't even present in that version? From what I can see, it only affects 5.0.0. Do we need to backport it against 4.13 in some way, or was this just a goof-up when you reported the bug? In any case, this should conclude the three important issues[1] still present in CuraEngine 5.0.0-3. I'd appreciate if someone from the 3-D printing team could push 5.0.0-4 to sid, so we can get the package promoted to trixie soon. Thanks a lot! [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040252 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037614 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040806
Bug#1034797: azure-cli: az keyvault show fails with No module named 'azure.keyvault.v7_0'
Package: azure-cli Version: 2.50.0-2 Severity: important Followup-For: Bug #1034797 X-Debbugs-Cc: onit...@gmail.com With azure-cli 2.50.0-2, the keyvault feature is still broken, but it fails with a different error now: $ az keyvault secret show --vault-name myvault --name mykey No module named 'azure.keyvault.key_vault_id' This is similar to https://github.com/Azure/azure-cli/issues/17981 Other keyvault commands, such as keyvault list, keyvault secret list, keyvault show, work fine. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages azure-cli depends on: ii python33.11.2-1+b1 ii python3-azure-cli 2.50.0-2 azure-cli recommends no packages. azure-cli suggests no packages. -- no debconf information
Bug#1040806: [3dprinter-general] Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"
Hi Dan, Visible in both Sid and Ubuntu Mantic is the following autopkgtest error: [ERROR] Trying to retrieve setting with no value given: 'adhesion_extruder_nr' See the attached patch, which is just a trivial backport of https://github.com/Ultimaker/CuraEngine/pull/1693 Thanks for that patch, it looks like it's still relevant for cura-engine 5.0.0: https://ci.debian.net/data/autopkgtest/testing/amd64/c/cura-engine/35613243/log.gz I'll test it and see if it helps. sid and trixie will get cura-engine 5.0.0 as soon as some remaining issues are fixed. We've had to hold back with the release before bookworm due to a lack of time, unfortunately. Since bookworm is stuck with 4.13, the patch might also be a candidate there. Regards, Gregor
Bug#1040252: [3dprinter-general] Bug#1040252: cura-engine FTBFS on some 32bit architectures
Hi myon, I've tested the patch both on amd64 and i686 (in a chroot) and pushed it to Salsa. Could you upload cura-engine 5.0.0-4 when you have time? Thank you very much! Regards, Gregor
Bug#1040252: cura-engine FTBFS on some 32bit architectures
This is actually a bug in the test and not CuraEngine.
In tests/InfillTest.cpp:104, they format a size_t as %lld instead of
%zu. %llu works as well, but it's not 100% correct with a 32-bit size_t.
Current upstream HEAD still has the bug, so I'm going to report it there
as well:
https://github.com/Ultimaker/CuraEngine/blob/main/tests/InfillTest.cpp#L103
Patch:
diff --git a/tests/InfillTest.cpp b/tests/InfillTest.cpp
index 23b083f5..6f39b708 100644
--- a/tests/InfillTest.cpp
+++ b/tests/InfillTest.cpp
@@ -100,7 +100,7 @@ namespace cura
result_lines(result_lines),
result_polygons(result_polygons)
{
-name =
makeName("InfillTestParameters_P%d_Z%d_C%d_L%lld__%lld",
(int)params.pattern, (int)params.zig_zagify,
(int)params.connect_polygons, params.line_distance, test_polygon_id);
+name =
makeName("InfillTestParameters_P%d_Z%d_C%d_L%lld__%zu",
(int)params.pattern, (int)params.zig_zagify,
(int)params.connect_polygons, params.line_distance, test_polygon_id);
}
friend std::ostream& operator<<(std::ostream& os, const
InfillTestParameters& params)
Bug#1040312: python3-charon: Drop metadata service only relevant for Ultimaker 3D printers
Package: python3-charon Version: 5.0.0-3 Severity: normal Forwarded: https://github.com/Ultimaker/libCharon/issues/45 X-Debbugs-Cc: onit...@gmail.com Upstream has reported that the metadata service is only relevant on Ultimaker 3D printers. The service file installed in /lib/systemd/system/charon.service can be dropped from the package, as well as the DBus configuration in /usr/share/dbus-1/system.d/nl.ultimaker.charon.conf -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-charon depends on: ii python33.11.2-1+b1 ii python3-dbus 1.3.2-4+b1 ii python3-gi 3.42.2-3+b1 ii python3-pyqt6 6.4.2-1 python3-charon recommends no packages. python3-charon suggests no packages. -- no debconf information
Bug#1040191: marked as pending in libnest2d
Hi myon,
Cmake files check for matching architecture width now, mark package as Arch: any
* Cmake files check for matching architecture width now, mark package as
Arch: any. (The header files themselves do not change. Closes: #1040191)
* Drop M-A: foreign.
Thanks for the quick fix, but I'm not super happy about this solution.
This package *really* installs only platform-independent header files,
and I think the error is wrong.
But I can see where it's coming from; one of the cmake scripts contains
boilerplate that depends on the installation architecture:
/usr/lib/cmake/Libnest2D/Libnest2DConfigVersion.cmake
# check that the installed version has the same 32/64bit-ness as the one which
is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
math(EXPR installedBits "8 * 8")
set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
I'll report this upstream, perhaps this was really unintentional
(copy).
And it looks like we're not the first with this sort of issue:
https://stackoverflow.com/questions/51659082/how-to-skip-32-64bit-ness-check-in-xxxconfigversion-cmake
Regards,
Gregor
Bug#1038883: dolfin: autopkgtest failure due to bytes as docstring
your package fails the autopkgtest with the new pytest 7.3 because python/test/unit/function/test_function_space.py uses a bytes object (b""" literal) as module docstring, and pytest crashes while looking for the "PYTEST_DONT_REWRITE" marker. This does sound like a serious bug in pytest, though. If it can't process the docstring, it should ignore it, not crash. But I don't quite get why it would choke on a byte string, if it's just looking for a token? As far as I understand, using a bytes() object as docstring violates PEP-257, which is why I am filing this as a dolfin bug and not a pytest regression. I have Cc'd the debian-python mailing list for a second opinion, but I believe this bug should be resolved by getting rid of the erroneous "b" prefix. PEP-257 says: If you violate these conventions, the worst you’ll get is some dirty looks. But some software (such as the Docutils docstring processing system PEP 256, PEP 258) will be aware of the conventions, so following them will get you the best results. FWIW, I think this should be fixed in both pytest and the affected package. Unless there is a specific reason for the byte string, it should be replaced with a regular string.
Bug#1035479: intel-mkl: debian/watch should point to upstream changelog, not third party repository
Source: intel-mkl Severity: important X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Please revert the change made to debian/watch in commit https://salsa.debian.org/science-team/intel- mkl/-/commit/9b5dfecfc43e3e06ce2308219c46957e383117af The reason given in the commit message no longer seems to be valid, as current versions can be found on https://pypi.org/project/mkl/#history The Debian package is now 3 years outdated, and PTS doesn't even show that there's a new version available. This is a likely indicator that the third party repo doesn't have current versions of intel-mkl. It should be enough to revert commit 9b5dfecf to fix this issue. Thank you very much! -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1035380: [3dprinter-general] Bug#1035380: prusa-slicer: segfaults at start if window is too small
I use a tiling window manager (sway). If I start prusa-slicer and the
resulting window is too small, the program segfaults:
$ prusa-slicer
[2023-05-02 15:49:42.874172] [0x7f8b39d49d80] [trace]
Initializing StaticPrintConfigs
15:49:45: Debug: window wxTreeCtrl@0x558be9c7d190 ("treeCtrl") lost
focus even though it didn't have it
15:49:45: Debug: window wxTreeCtrl@0x558be9c7d190 ("treeCtrl") lost
focus even though it didn't have it
Segmentation fault (core dumped)
Could you add a stack trace as well?
It will be easier to debug the issue or report it upstream that way.
coredumpctl will help, and possibly some debug symbol packages.
Also, can you explain what "too small" means exactly, to help reproduce
the problem?
Bug#969203: Merging *-avr with existing binutils & gcc packages
Is there any reason why https://tracker.debian.org/pkg/gcc-12-cross-ports and https://tracker.debian.org/pkg/binutils can't be used to produce gcc-avr avr-libc & binutils-avr packages? Of course we still need to add a few dependencies (e.g. core-avr). See the discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989 - a switch from the Atmel/Microchip toolchain to mainstream gcc was already up for discussion, but Ardö has mentioned that he lacks the time to do it. There is no mention of AVR on the GCC 11 and 12 changelog: https://gcc.gnu.org/gcc-11/changes.html https://gcc.gnu.org/gcc-12/changes.html So, I'm not sure if the announced deprecation of the AVR target has actually happened. As I understand, there's at least the Arduino community who has an active interest in keeping AVR support alive. If you're up for it, please take a shot at upgrading the packages to the mainstream versions. I can't contribute a lot of time either, but I'd be happy to support you with bug fixing and testing.
Bug#1034797: azure-cli: az keyvault show fails with No module named 'azure.keyvault.v7_0'
Package: azure-cli
Version: 2.45.0-1
Severity: normal
X-Debbugs-Cc: onit...@gmail.com
Dear Maintainer,
az keyvault secret show (options don't matter) currently fails on Debian with
the following error:
The command failed with an unexpected error. Here is the traceback:
No module named 'azure.keyvault.v7_0'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in invoke
cmd_result = self.invocation.execute(args)
^
File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
line 561, in execute
self.commands_loader.load_arguments(command)
File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 507,
in load_arguments
self.command_table[command].load_arguments() # this loads the arguments
via reflection
File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
line 318, in load_arguments
super(AzCliCommand, self).load_arguments()
File "/usr/lib/python3/dist-packages/knack/commands.py", line 104, in
load_arguments
cmd_args = self.arguments_loader()
^^^
File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/keyvault/_command_type.py", line 75, in
keyvault_arguments_loader
op = get_op_handler()
File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/keyvault/_command_type.py", line 72, in
get_op_handler
return
self.command_loader.get_op_handler(operations_tmpl.format(method_name))
^^^
File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 884,
in get_op_handler
op = import_module(mod_to_import)
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1128, in _find_and_load_unlocked
File "", line 241, in _call_with_frames_removed
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1142, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'azure.keyvault.v7_0'
az --version shows:
azure-cli 2.45.0 *
core 2.45.0 *
telemetry 1.0.8
Extensions:
azure-devops 0.26.0
Dependencies:
msal 1.21.0
azure-mgmt-resource 22.0.0
Python location '/usr/bin/python3'
Extensions directory '${HOME}/.azure/cliextensions'
Extensions system directory '/usr/lib/python3/dist-packages/azure-cli-
extensions'
Python (Linux) 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]
This also happens in a freshly created sid container, so it doesn't look like
it's related to any local configuration.
-- System Information:
Debian Release: 12.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-security'), (500, 'testing-debug'), (500, 'unstable'), (500,
'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages azure-cli depends on:
ii python33.11.2-1+b1
ii python3-azure-cli 2.45.0-1
azure-cli recommends no packages.
azure-cli suggests no packages.
-- no debconf information
Bug#1034210: python3-charon: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi,
As a result, could you please move these files to /lib/systemd/system instead
so they are properly detected by debhelper?
As soon as debhelper is supporting (not until bookworm+1 aka Trixie) you will
be able to move them back to the newer location.
I've committed a patch to Salsa.
It looks like it does what it's supposed to, but I don't know how to
test it because I don't understand the inner workings of debhelper very
well.
@myon: Could you push a new release when you have time, and also against
4.13.0-1? Thanks!
The patch also works with 4.13.0-1, with minor fuzz. Here's the
refreshed version:
$ cat debian/patches/0002-service-files-in-root.patch
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -35,7 +35,7 @@
install(DIRECTORY Charon DESTINATION ${CHARON_INSTALL_PATH} ${_excludes})
if(INSTALL_SERVICE)
-install(FILES service/charon.service DESTINATION lib/systemd/system)
+install(FILES service/charon.service DESTINATION /lib/systemd/system)
install(FILES service/nl.ultimaker.charon.conf DESTINATION
share/dbus-1/system.d)
endif()
Bug#1034526: azure-cli: Better collaboration with upstream
The only official Debian packages are what you find on debian.org and its mirrors, third party repositories are unofficial by definition and ... From upstream's perspective, this is not true, unless you apply the term Debian in the strict sense of "released by the Debian project" and not in the sense of "packaged using Debian's packaging system". Debian packages are not broken, they are working fine, to the extent permitted by extremely broken and messy upstream sources. Due to upstream bugs outside of our control at times some subfeature might not work, but there's nothing we can do about it, there's always something broken in the upstream code. From a user's perspective, this is also untrue: If azure-cli is currently installed from the Debian package repository, it fails on multiple subfeatures. In this context, it's irrelevant if this is "upstream's fault". By releasing the package in the Debian package repositories, one or multiple DDs or DMs have taken (limited) responsibility for the Debian version, and they should make sure the Debian version gets fixed. That is a bit rich, given upstream routinely ignores bug reports, pull requests and so on, to the extent that I have given up even trying. The "azure-sdk-for-python" upstream repository is an absolute disaster of a dumpster fire, with no attempt whatsoever at even a semblance of functional release engineering, which causes enough pain already to us. That may be the case, but this is not visible to users. They will experience a bug in the Debian version, report it upstream, be rebuffed because they had the gall (!!) to use the Debian version instead of the upstream version, and then get redirected to upstream's package repository. Most regular users would think at this point that the fault lies with the Debian project and simply install the upstream version instead. This is a terrible user experience and does absolutely nothing to get broken subfeatures fixed in the Debian packages. Absolutely not, the official Debian packages are following Debian policy and best practices as they should, while upstream is a gigantic mess and a security nightmare, so ask them instead. This may be the case, but taking this stance doesn't get the mess fixed. As is evident in https://github.com/Azure/azure-cli/issues/19640 , upstream doesn't care about what their mess causes downstream, and they will simply continue "fixing" it in their own way. Again: I'm trying to blame Debian Developers for broken packages, I'm trying to request a solution that does not result in a shitty user experience.
Bug#1034526: azure-cli: Better collaboration with upstream
Package: azure-cli Version: 2.45.0-1 Severity: important X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Upstream has had lots of bug reports due to discrepancies between the version packaged in Debian and Ubuntu and Microsoft's own "official" Debian packages: https://github.com/Azure/azure-cli/issues/19640 Virtually all of these bugs were reported upstream instead of the Debian project, causing fallout on their side, whilst the Debian packages remain broken. Please consider working closer together with upstream to reach the same release quality, or (possibly) fix the bug reporting channel, so bugs specific to the Debian version are reported where they belong (i.e. BTS and not upstream's Github). As an alternative, please consider renaming the Debian packages, so there is less ambiguity which version is installed. Examples of bugs that should have been reported in Debian instead of upstream: https://github.com/Azure/azure-cli/issues/25826 https://github.com/Azure/azure-cli/issues/25950 https://github.com/Azure/azure-cli/issues/25122 https://github.com/Azure/azure-cli/issues/24959 https://github.com/Azure/azure-cli/issues/24656 https://github.com/Azure/azure-cli/issues/24308 Thank you for your consideration. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages azure-cli depends on: ii python33.11.2-1+b1 ii python3-azure-cli 2.45.0-1 azure-cli recommends no packages. azure-cli suggests no packages. -- no debconf information
Bug#950920: (no subject)
I've committed a patch that will make the problems go away and shouldn't cause any issues when the dtype already matches the expectation, i.e. when the platform's int type is equal or greater than np.int64. There is a slight risk with the type conversion though: When the input is very large and uses indices > 2³¹-1. This will cause data loss on 32-bit architectures without any warning. I did some simple tests and found that this will cause failures in other places (memory allocation, for example), but that's not very reliable. Unfortunately, I couldn't find a way to do an efficient "unsafe" conversion with a warning in numpy - a lot of boilerplate and performance loss would be needed to do this manually. The Fedora developers already reported the issue upstream, by the way: https://github.com/mikedh/trimesh/issues/690
Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED
E TypeError: Cannot cast array data from dtype('int64') to
dtype('int32') according to the rule 'safe'
Tracked it down to incorrect usage of numpy.bincount: This function
requires the native index type, which is int32 on i686 (and probably all
other 32-bit architectures).
I submitted a documentation change request to numpy:
https://github.com/numpy/numpy/issues/23526
I'll try to fix the issue in trimesh and submit an upstream patch.
Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED
So, I pushed my current version to Salsa.
The CI job found another issue: Some of the tests fail on i386 due to
typing mismatches:
https://salsa.debian.org/3dprinting-team/trimesh/-/jobs/4103005
E TypeError: Cannot cast array data from dtype('int64') to
dtype('int32') according to the rule 'safe'
This is probably similar to
https://github.com/mwaskom/seaborn/issues/1950 - I'll try to fix it and
submit an upstream patch.
Bug#1033828: mono-xbuild: Mono packages should provide msbuild instead of xbuild
Package: mono-xbuild Version: 6.8.0.105+dfsg-3.3 Severity: important X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Please consider adding msbuild to the Mono SDK packages. The older xbuild tool is deprecated and shouldn't be used any more: $ xbuild xbuild tool is deprecated and will be removed in future updates, use msbuild instead The Mono project has provided the official msbuild tool since version 5.0: https://www.mono-project.com/docs/about-mono/releases/5.0.0/#msbuild Thanks! -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-6-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mono-xbuild depends on: ii libc6 2.36-8 ii libmono-corlib4.5-cil 6.8.0.105+dfsg-3.3 ii libmono-microsoft-build-engine4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-microsoft-build-framework4.0-cil6.8.0.105+dfsg-3.3 ii libmono-microsoft-build-tasks-v4.0-4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-microsoft-build-utilities-v4.0-4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-system-core4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-system-data4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-system-runtime-serialization4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-system-xml-linq4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-system-xml4.0-cil 6.8.0.105+dfsg-3.3 ii libmono-system4.0-cil 6.8.0.105+dfsg-3.3 ii mono-runtime6.8.0.105+dfsg-3.3 mono-xbuild recommends no packages. mono-xbuild suggests no packages. -- no debconf information
Bug#950920: [3dprinter-general] trimesh_3.5.25-1_amd64.changes REJECTED
I experimented with the package a bit and was successful in building it, including running all the tests. My current fix for the model path issue is not very good, though: I simply patched out the relative path so it would work with the local package build directory, but it's probably better if the build process copies the whole /models directory into the build dir before running the tests. Is there a "clean" way to do this? Any help would be appreciated. Aside from that, I found two issues: Lintian reports a source-is-missing error on load_base64.js. This is a hand-written JavaScript source file that contains a base64-encoded example. This example looks machine-generated and very trivial. I think it would be ok to simply apply a Lintian override here. The .js file isn't packaged anyway, and I don't think there's any copyright issue either. The other problem may be much more serious. The example file models/duck.dae contains metadata that says it's under the "SCEA" license, which is not an OSI-approved free software license. That means this file is most likely not DFSG-compliant. The file is only an example that isn't packaged, but I'm not sure if we can keep it in the source tree. The license explicitly permits redistribution though, so this may not be an issue.
Bug#925424: linux-image-amd64: Build the Silead touchscreen controller kernel driver
Hi Debian kernel team, It's been 4 years, and the Debian kernel is still lacking out-of-the-box support for Silead touchscreen controllers and corresponding DMI quirks. Can you please enable these options? CONFIG_TOUCHSCREEN_SILEAD=m CONFIG_TOUCHSCREEN_DMI=y Thank you very much.
Bug#979090: Legally problematic GPL-3+ readline dependency
Since merge requests are disabled on the Salsa repository, I'm attaching the patch here. Almost everything in the project is GPL-2+, with only a few outliers: install-sh is X11, and debian/avrdude.metainfo.xml is CC-BY-SA-3.0. I believe this is acceptable under the terms of libreadline8. @Milan please review the patch and push a new version soon, if you can.From acdcf1c29c6a3d3d20cac2d4cf046a5a0e7c90cf Mon Sep 17 00:00:00 2001 From: Gregor Riepl Date: Sun, 19 Feb 2023 00:31:37 +0100 Subject: [PATCH] Fix and updat d/copyright to include all copyrights and correct licenses --- debian/changelog | 9 + debian/copyright | 520 +-- 2 files changed, 512 insertions(+), 17 deletions(-) diff --git a/debian/changelog b/debian/changelog index 198010a..10d190a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +avrdude (6.3-20171130+svn1429-3) UNRELEASED; urgency=medium + + [Gregor Riepl] + * Fix debian/copyright +(add missing statements, correct license to GPL-2+) +Closes: #979090 + + -- Gregor Riepl Sun, 19 Feb 2023 00:31:45 +0100 + avrdude (6.3-20171130+svn1429-2) sid; urgency=medium * revert usbtiny tpi implementation (closes: #922558) diff --git a/debian/copyright b/debian/copyright index b9051f1..e42c6fa 100644 --- a/debian/copyright +++ b/debian/copyright @@ -1,24 +1,510 @@ -This package was debianized by Michael Biebl on -Mon, 6 Jun 2005 20:28:53 +0200. +Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ +Source: http://savannah.nongnu.org/projects/avrdude/ +Upstream-Name: avrdude +Upstream-Contact: Brian S. Dean -It was downloaded from http://savannah.nongnu.org/projects/avrdude/ +Files: * +Copyright: + 1990-200 Brian S. Dean + 2001-2016 Joerg Wunsch + 2009 Analog Devices Inc. + Michael Hennerich (henner...@blackfin.uclinux.org) + 2008 Klaus Leidinger + 2003, 2004, 2006 Eric B. Weddington + 2003-2005 Theodore A. Roth + 2011 Darell Tan + 2003, 2004 Martin J. Thomas + 2005-2007 Colin O'Flynn + 2005 Erik Walthinsen + 2005 Juliane Holzt + 2006 Christian Starkjohann + 2006 David Moore + 2006 Thomas Fischl + 2007 Dick Streefland + 2007 Limor Fried + 2009 Lars Immisch + 2009 Michal Ludvig + 2011-2012 Roger E. Wolff + 2011 Brett Hagman + 2011 Hannes Weisbach, Doug Springer + 2012 Kirill Levchenko + 2013 Radoslav Kolev + 2003-2004 Jan-Hinnerk Reichert + 2004 Alex Shepherd + 2009-2010 David Hoerl + 2011-2014 Rene Liebscher + Wolfgang Moser + Ville Voipio + Jim Paris + David Mosberger-Tang +License: GPL-2+ + +Files: + Makefile.in + doc/Makefile.in + windows/Makefile.in +Copyright: + 1994-2014 Free Software Foundation, Inc. + 2003 Theodore A. Roth +License: GPL-2+ + This Makefile.in is free software; the Free Software Foundation + gives unlimited permission to copy and/or distribute it, + with or without modifications, as long as this notice is preserved. + . + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY, to the extent permitted by law; without + even the implied warranty of MERCHANTABILITY or FITNESS FOR A + PARTICULAR PURPOSE. + . + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + . + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + . + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. -AVRDUDE was written by: - Brian S. Dean . +Files: + aclocal.m4 + m4/* + config.sub + doc/texinfo.tex + doc/mdate-sh + config.guess + compile + INSTALL + COPYING + configure + missing + ylwrap + ltmain.sh +Copyright: 1989-2015 Free Software Foundation, Inc. +License: GPL-2+ -Contributors: - Joerg Wunsch - Eric Weddington - Jan-Hinnerk Reichert - Alex Shepherd - Martin Thomas - Theodore A. Roth +Files: + install-sh +Copyright: 1994 X Consortium +License: X11+PublicDomain +Files: + debian/* Copyright: - 2000, 2001, 2002, 2003 Brian S. Dean + 2005-2015 Michael Biebl + 2015 Guido Günther + 2015-2019 Milan Kupcevic + 2023 Gregor Riepl +License: GPL-2+ + +Files: + debian/avrdude.metainfo.xml +Copyright: + 2018 Milan Kupcevic +License: CC-BY-SA-3.0 + +License: GPL-2+ + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + . + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied wa
Bug#1031534: firmware-linux-nonfree: Package removed from sid and bookworm
Package: firmware-linux-nonfree Version: 20221214-3 Severity: grave Justification: renders package unusable X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, With the recent upgrade to version 20230210 (or 20230117 on testing), the package has vanished from the apt cache of two of my bookworm/sid installations. apt policy reports that firmware-linux-nonfree is stuck at version 20221214-3 on my systems, with the only available version being the one that is locally installed. According to https://tracker.debian.org/pkg/firmware-nonfree everything seems to be fine, but I simply don't see any available upgrades. Opening https://packages.debian.org/source/unstable/firmware-nonfree reports: "Package not available in this suite." Were these packages renamed, or what exactly is going on here? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firmware-linux-nonfree depends on: ii firmware-amd-graphics 20221214-3 ii firmware-misc-nonfree 20221214-3 Versions of packages firmware-linux-nonfree recommends: ii amd64-microcode 3.20220411.1 ii intel-microcode 3.20221108.1 firmware-linux-nonfree suggests no packages. -- no debconf information
Bug#979090: Legally problematic GPL-3+ readline dependency
Is anybody already working on this? I will attempt to fix d/copyright and submit a patch or MR for review otherwise.
Bug#1028083: plasma-discover: Discover tray app crashes kded5, causing other system tray icons to vanish
Hello, this seems similar to the backtrace in bug #1026062. At least the "transactionListChanged" and the two lines above. It looks similar and may have the same root cause. I'd prefer to keep the bugs separate for now, though. It could be a different bug. FYI: My kded core dumps also contained something about a closed DBus connection in a different thread's stack trace. Perhaps this is related?
Bug#915370: Please drop anacron from task-desktop and task-laptop
Package: task-laptop Version: 3.71 Followup-For: Bug #915370 X-Debbugs-Cc: onit...@gmail.com The drop didn't happen in buster+1, but there may still be time for bookworm. FYI: The anacron service was silently disabled by default a while ago due to a bug, but this was only recently reported: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1028205 On the other hand, the systemd-cron package provides anacron, so it could be installed instead, if the cron dependency should be kept. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-proposed-updates-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages task-laptop depends on: ii anacron 2.3-36 ii tasksel 3.71 Versions of packages task-laptop recommends: ii avahi-autoipd 0.8-7 ii bluetooth 5.66-1 ii iw 5.19-1 ii powertop2.14-1+b2 ii wireless-tools 30~pre9-14 ii wpasupplicant 2:2.10-10 task-laptop suggests no packages. -- no debconf information
Bug#1028462: ITP: obs-vkcapture -- OBS plugin for Vulkan/OpenGL game capture
Package: wnpp Severity: wishlist Owner: Gregor Riepl X-Debbugs-Cc: debian-de...@lists.debian.org, onit...@gmail.com * Package name: obs-vkcapture Version : 1.2.2 Upstream Contact: David Rosca * URL : https://github.com/nowrep/obs-vkcapture * License : GPL-2+ Programming Lang: C Description : OBS plugin for Vulkan/OpenGL game capture This OBS plugin provides an efficient method to capture output from GPU-accelerated applications, such as games and other 3D applications. The built-in capture methods provided by OBS on Linux are very slow and not suitable for higher resolutions or faster frame rates. With the plugin, high resolution and high frame rate capture directly from a GPU framebuffer becomes possible. As the OBS packages are already maintained by the DebianMultimedia team, I think it makes sense to put the plugin under the unmbrella of DebianMultimedia. I'd be willing to co-maintain it together with the team. I will need a sponsor for the package because I'm not a DD. My packaging effort so far can be found here: https://salsa.debian.org/onitake-guest/obs-vkcapture
Bug#1028236: cura: Please package Cura 5.1+
Package: cura Version: 5.0.0-1 Severity: wishlist X-Debbugs-Cc: onit...@gmail.com Control: block -1 by 845463 This is a placeholder bug to track activity towards packaging Cura 5.1 and later versions. With Cura 5.1, upstream has switched to a new build and dependency management system that is based on Conan[1], which is not yet packaged for Debian. CMake is still used, and there are also some requirements on other build tools, such as Ninja[2]. Ninja is available in Debian as "ninja-build". The work done by the Alpine package maintainer may serve as a starting point: https://git.alpinelinux.org/aports/tree/community/libarcus https://git.alpinelinux.org/aports/tree/community/curaengine However, it would be better if we didn't have to maintain a large set of compatibility patches to make building Cura possible again. Be aware that upstream states there may still be changes to the build system coming[3]. [1] https://conan.io/ [2] https://ninja-build.org/ [3] https://github.com/Ultimaker/libArcus/tree/6b70728da6149232dd8c7b20d23a31103468b3ba#how- to-build -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cura depends on: ii cura-engine 1:5.0.0-1 ii fdm-materials5.0.0-1 ii fonts-open-sans 1.11-2 ii python3 3.10.6-3+b1 ii python3-certifi 2022.9.24-1 ii python3-charon 4.13.0-1 ii python3-cryptography 3.4.8-2 ii python3-keyring 23.9.3-2 ii python3-pynest2d 5.0.0-1 ii python3-pyqt66.4.0-1+b2 ii python3-requests 2.28.1+dfsg-1 ii python3-savitar 5.0.0-1 ii python3-sentry-sdk 1.9.10-2 ii python3-serial 3.5-1.1 ii python3-shapely 1.8.5-2 ii python3-uranium 5.0.0-1 ii qml6-module-qt-labs-folderlistmodel 6.4.2+dfsg~rc1-2 ii qml6-module-qtqml-workerscript 6.4.2+dfsg~rc1-2 ii qml6-module-qtquick-controls 6.4.2+dfsg~rc1-2 ii qml6-module-qtquick-dialogs 6.4.2+dfsg~rc1-2 ii qml6-module-qtquick-layouts 6.4.2+dfsg~rc1-2 ii qml6-module-qtquick-templates6.4.2+dfsg~rc1-2 ii qml6-module-qtquick-window 6.4.2+dfsg~rc1-2 ii qt6-qpa-plugins 6.4.2+dfsg~rc1-3 ii uranium-plugins 5.0.0-1 Versions of packages cura recommends: ii python3-zeroconf 0.47.1-1 cura suggests no packages. -- no debconf information
Bug#1028083: plasma-discover: Discover tray app crashes kded5, causing other system tray icons to vanish
Package: plasma-discover Version: 5.26.4-1+b1 Severity: normal X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, On systems running the KDE Plasma desktop together with plasma-discover, some system tray icons regularly vanish. This mostly happens right after desktop startup, but can also occur at any later point. Uninstalling plasma-discover and its dependencies causes the problem to disappear completely. After analyzing the systemd user session (systemctl --user --failed) and the crashed plasma-kded service, I looked at the coredump (coredumpctl gdb). The service's journal (journalctl --user -xu plasma-kded.service) did not provide any insights. An example backtrace of kded5 is attached below. The trace suggests that the actual problem may be with libpackagekitqt5, but I cannot say for sure. (gdb) thread 6 [Switching to thread 6 (Thread 0x7f9cbb230cc0 (LWP 5626))] warning: Section `.reg-xstate/5626' in core file too small. #0 0x7f9cbc71b0af in __GI___poll (fds=fds@entry=0x7ffd3cad4118, nfds=nfds@entry=1, timeout=timeout@entry=1000) at ../sysdeps/unix/sysv/linux/poll.c:29 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) bt #0 0x7f9cbc71b0af in __GI___poll (fds=fds@entry=0x7ffd3cad4118, nfds=nfds@entry=1, timeout=timeout@entry=1000) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f9cbdf0b160 in poll (__timeout=1000, __nfds=1, __fds=0x7ffd3cad4118) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39 #2 pollDrKonqiSocket (sockfd=3, pid=19571) at ./src/kcrash.cpp:865 #3 KCrash::startProcess (argc=argc@entry=16, argv=argv@entry=0x7ffd3cad4238, waitAndExit=waitAndExit@entry=true) at ./src/kcrash.cpp:727 #4 0x7f9cbdf0bb67 in KCrash::defaultCrashHandler (sig=11) at ./src/kcrash.cpp:623 #5 #6 std::__atomic_base::load (__m=std::memory_order_relaxed, this=0x330035002e0038) at /usr/include/c++/12/bits/atomic_base.h:818 #7 std::atomic::load (__m=std::memory_order_relaxed, this=0x330035002e0038) at /usr/include/c++/12/atomic:579 #8 QAtomicOps::loadRelaxed (_q_value=...) at ../../include/QtCore/../../src/corelib/thread/qatomic_cxx11.h:239 #9 QBasicAtomicPointer::loadRelaxed (this=0x330035002e0038) at ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:248 #10 QObjectPrivate::ConnectionData::resizeSignalVector (size=11, this=0x330035002e0030) at kernel/qobject_p.h:303 #11 QObjectPrivate::addConnection (this=, signal=signal@entry=10, c=c@entry=0x5600995c33a0) at kernel/qobject.cpp:327 #12 0x7f9cbcade63e in QObjectPrivate::connectImpl (sender=0x5600996bb250, signal_index=10, receiver=, slot=, slotObj=0x56009947fda0, type=, types=, senderMetaObject=) at ../../include/QtCore/../../src/corelib/kernel/qobject.h:132 #13 0x7f9cbcadeaa5 in QObject::connectImpl (sender=sender@entry=0x5600996bb250, signal=signal@entry=0x7ffd3cad55b0, receiver=receiver@entry=0x56009937fc50, slot=slot@entry=0x7ffd3cad55c0, slotObj=0x56009947fda0, type=Qt::AutoConnection, types=0x0, senderMetaObject=) at kernel/qobject.cpp:5034 #14 0x7f9c8c26f6ed in QObject::connect (type=Qt::AutoConnection, slot=(void (TransactionJob::*)(TransactionJob * const)) 0x7f9c8c26fcc0 , receiver=0x56009937fc50, signal=(void (PackageKit::Transaction::*)(PackageKit::Transaction * const)) 0x7f9c8c1bdb10 , sender=0x5600996bb250) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268 #15 TransactionJob::TransactionJob (this=0x56009937fc50, transaction=0x5600996bb250, parent=) at ./apperd/TransactionJob.cpp:47 #16 0x7f9c8c271648 in TransactionWatcher::transactionChanged (this=this@entry=0x7f9c94026f90, transaction=0x5600996bb250, interactive=80) at ./apperd/TransactionWatcher.cpp:211 #17 0x7f9c8c271ade in TransactionWatcher::watchTransaction (this=this@entry=0x7f9c94026f90, tid=..., interactive=interactive@entry=false) at ./apperd/TransactionWatcher.cpp:106 #18 0x7f9c8c271b99 in TransactionWatcher::transactionListChanged (this=0x7f9c94026f90, tids=...) at ./apperd/TransactionWatcher.cpp:85 #19 0x7f9cbcae8caf in QtPrivate::QSlotObjectBase::call (a=0x7ffd3cad57b0, r=0x7f9c94026f90, this=0x560099587360) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #20 doActivate (sender=0x5600993e8140, signal_index=8, argv=0x7ffd3cad57b0) at kernel/qobject.cpp:3919 #21 0x7f9cbcae1f4f in QMetaObject::activate (sender=, m=m@entry=0x7f9c8c1e97c0 , local_signal_index=local_signal_index@entry=5, argv=argv@entry=0x7ffd3cad57b0) at kernel/qobject.cpp:3979 #22 0x7f9c8c1b3095 in PackageKit::Daemon::transactionListChanged (this=, _t1=...) at ./obj-x86_64-linux- gnu/src/packagekitqt5_autogen/include/moc_daemon.cpp:419 #23 0x7f9cbcae8cdc in doActivate (sender=0x560099294690, signal_index=5, argv=0x7ffd3cad58d0) at kernel/qobject.cpp:3931 #24 0x7f9cbcae1f4f in QMetaObject::activate (sender=sender@entry=0x560099294690, m=m@entry=0x7f9c8c1e9b00 , local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x7ffd3cad58d0) at
Bug#1026856: [3dprinter-general] Bug#1026856: cura-engine: FTBFS: 14 tests segfault
cura-engine/experimental recently started to FTBFS: 46% tests passed, 14 tests failed out of 26 This is caused by the recent protobuf transition, see gdb log below. It will be fixed in libarcus 5.0.0-2, which is waiting for release: https://salsa.debian.org/3dprinting-team/libarcus/-/commit/c2dfe6eacb2213195619b50f1d1efc7cd519c8f8 @myon: Can you take care of pushing this version, please? Thank you! (gdb) run Starting program: /home/onitake/Code/cura/CuraEngine/obj-x86_64-linux-gnu/ArcusCommunicationPrivateTest [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x773b8c90 in google::protobuf::internal::AddDescriptors(google::protobuf::internal::DescriptorTable const*) () from /lib/x86_64-linux-gnu/libprotobuf.so.23 (gdb) bt #0 0x773b8c90 in google::protobuf::internal::AddDescriptors(google::protobuf::internal::DescriptorTable const*) () from /lib/x86_64-linux-gnu/libprotobuf.so.23 #1 0x773b8cf2 in google::protobuf::internal::AddDescriptors(google::protobuf::internal::DescriptorTable const*) () from /lib/x86_64-linux-gnu/libprotobuf.so.23 #2 0x77fcfabe in call_init (env=0x7fffdc88, argv=0x7fffdc78, argc=1, l=) at ./elf/dl-init.c:70 #3 call_init (l=, argc=1, argv=0x7fffdc78, env=0x7fffdc88) at ./elf/dl-init.c:26 #4 0x77fcfba4 in _dl_init (main_map=0x77ffe2e0, argc=1, argv=0x7fffdc78, env=0x7fffdc88) at ./elf/dl-init.c:117 #5 0x77fe59f0 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #6 0x0001 in ?? () #7 0x7fffe032 in ?? () #8 0x in ?? ()
Bug#1026860: libarcus: Lintian error custom-library-search-path due to rpath usage
Source: libarcus Version: 5.0.0-1 Severity: normal X-Debbugs-Cc: onit...@gmail.com This seems to a new occurrence, reported since the build was switched to DH13. E: python3-arcus: custom-library-search-path RUNPATH /usr/lib/python3.10/config-3.10-x86_64-linux-gnu [usr/lib/python3/dist- packages/pyArcus.cpython-310-x86_64-linux-gnu.so] Caused by (search for -rpath): [100%] Linking CXX shared library pyArcus.so /usr/bin/cmake -E cmake_link_script CMakeFiles/sip_pyArcus.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=<>/libArcus=. -fstack- protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -flto=auto -fno-fat-lto-objects -Wl,-z,relro -Wl,-z,now -shared -Wl,-soname,pyArcus.so -o pyArcus.so CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_array.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_core.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_descriptors.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_enum.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_int_convertors.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_object_map.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_threads.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_voidptr.c.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_bool.cpp.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart0.cpp.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart1.cpp.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart2.cpp.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart3.cpp.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart4.cpp.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart5.cpp.o CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart6.cpp.o CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o -Wl,-rpath,<>/libArcus/.pybuild/cpython3_3.10/build:/usr/lib/python3.10/config-3.10-x86_64-linux- gnu: libArcus.so.5.0.0 /usr/lib/x86_64-linux-gnu/libprotobuf.so /usr/lib/python3.10/config-3.10-x86_64-linux-gnu/libpython3.10.so It seems that the rpath option is generated by pybuild, but I'm not 100% sure. If this is the case, I think this issue should be reported against pybuild. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1025844: plasma-workspace: Non-KDE system tray icons vanish after upgrade to Plasma 5.26.4
Package: plasma-workspace Version: 4:5.26.4.1-1 Severity: normal X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, After an upgrade to Plasma Workspace 5.26.4, many system tray icons are gone after logging out/rebooting and logging back in. I encountered the issue with various applications, such as IBus Panel, KeepassXC, Teams, Slack and others. Native KDE applications don't seem to be affected. The applications also don't appear in the "Shown icons" configuration dialog of the system tray. I've encountered this issue on two separate systems so far. A manual fix is relatively easy: Simply remove the system tray widget from any task bars and add it back in. This solution hints to a cache or configuration incompatibility, but it's not clear why the upgraded system tray widget didn't perform an automatic migration or clean-up in that case. It's also not clear if this is an upstream issue or specific to Debian. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-workspace depends on: ii dbus-user-session [default-dbus-session-bus]1.14.4-1 ii dbus-x11 [dbus-session-bus] 1.14.4-1 ii drkonqi 5.26.4-1 ii frameworkintegration5.100.0-1 ii gdb 12.1-4 ii init-system-helpers 1.65.2 ii iso-codes 4.12.0-1 ii kactivitymanagerd 5.26.4-1 ii kded5 5.100.0-1 ii kinit 5.100.0-1 ii kio 5.100.0-2 ii kpackagetool5 5.100.0-1 ii kwin-common 4:5.26.4-1 ii libappstreamqt2 0.15.5-1 ii libc6 2.36-6 ii libcolorcorrect54:5.26.4.1-1 ii libcrypt1 1:4.4.33-1 ii libfontconfig1 2.13.1-4.5 ii libfreetype62.12.1+dfsg-3 ii libgcc-s1 12.2.0-9 ii libgps283.22-4.1+b1 ii libice6 2:1.0.10-1 ii libicu7272.1-3 ii libkf5activities5 5.100.0-1 ii libkf5activitiesstats1 5.100.0-1 ii libkf5archive5 5.100.0-2 ii libkf5authcore5 5.100.0-1 ii libkf5baloo55.100.0-1 ii libkf5bookmarks55.100.0-1 ii libkf5calendarevents5 5.100.0-1 ii libkf5completion5 5.100.0-1 ii libkf5config-bin5.100.1-1 ii libkf5configcore5 5.100.1-1 ii libkf5configgui55.100.1-1 ii libkf5configwidgets55.100.0-1 ii libkf5coreaddons5 5.100.0-1 ii libkf5crash55.100.0-1 ii libkf5dbusaddons5 5.100.0-1 ii libkf5declarative5 5.100.0-1 ii libkf5globalaccel-bin 5.100.0-1 ii libkf5globalaccel5 5.100.0-1 ii libkf5guiaddons55.100.0-3 ii libkf5holidays5 1:5.100.0-1 ii libkf5i18n5 5.100.0-1 ii libkf5iconthemes5 5.100.0-1 ii libkf5idletime5 5.100.0-1 ii libkf5jobwidgets5 5.100.0-1 ii libkf5kcmutils5 5.100.0-1 ii libkf5kexiv2-15.0.0 21.12.3-1 ii libkf5kiocore5 5.100.0-2 ii libkf5kiofilewidgets5 5.100.0-2 ii libkf5kiogui5 5.100.0-2 ii libkf5kiowidgets5
Bug#992010: pipewire: Cracking when playing sounds
Package: pipewire Version: 0.3.61-1 Severity: important Followup-For: Bug #992010 Forwarded: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2451 X-Debbugs-Cc: onit...@gmail.com This is almost certainly upstream issue https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2451 . According to the bug report, it was fixed in 0.3.58, but it's still present in Debian 0.3.63-1. Adding the allowed-rates option as described fixed it for me as well. Looks like the fix was either reverted, or the Debian package is still missing it? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pipewire depends on: ii adduser 3.129 ii init-system-helpers 1.65.2 ii libpipewire-0.3-modules 0.3.61-1 ii pipewire-bin 0.3.61-1 pipewire recommends no packages. pipewire suggests no packages. -- no debconf information
Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible
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. 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? Regards, Gregor
Bug#1023365: prusa-slicer: Wrong wxWidgets Version linked during debian Build resulting in instant SIGSEGV on launch (due to lacking wxWidgets 3.2 support)
The wrong wxWidgets Version is linked during the build. Normally debian/rules specifies WX_STABLE=1 which should result in the usage of wxWidgets 3.0 which is in stable. However, wx-config always returns wx3.2 which is then used by CMake even if CMakeLists.txt is changed to especially require wxWidgets 3.0 and wx-config options set to --version=3.0. Please note that there is currently a transition to wxWidgets 3.2 ongoing in Debian: https://release.debian.org/transitions/html/wxwidgets-3.2.html As such, it's expected that packages depending on wxWidgets upgrade to 3.2, but there seems to be considerable fallout due to breaking changes in from 3.0 to 3.2. In particular, slic3r is not ready due to the mentioned upstream issues. IMHO there is really no need to open another bug report on slic3r, since it's expected that all packages upgrade in due time, but you may want to add a block on the wxWidgets 3.2 transition to #1022234. slic3r currently shows as "green" in the transition table, because the build issues were fixed, but slic3r is not compatible, so it should block the transition.
Bug#1020702: [3dprinter-general] Bug#1020702: prusa-slicer: SEGV on start still happens [but different cause]
Prusa Slicer 2.5.0+dfsg-2 still SIGSEGV's during startup on Bookworm with some sid. A local rebuild does also runs into Segfault. However, it also reports that it is unable to init glew. I'm quite sure it is a different issue, but the result is quite the same. So i was unsure if I should open a new Bug. It *is* a different issue, but related. Upstream has stated that they're not supporting wxWidgets 3.2 yet: https://github.com/prusa3d/PrusaSlicer/issues/8299#issuecomment-1236874810 It's probably best to open a new issue covering other wx 3.2 crashes/issues, since a fix for the segfault was already released. That being said, the comments on the upstream bug report make it sound like fixes for wx 3.2 will take some time, so it may be best to classify the new bug report as serious, so it will block the transition of the broken 2.5.0 package to testing?
Bug#1020779: [3dprinter-general] Bug#1020779: slic3r-prusa: FTBFS on 32-bit arches
Do you have a bit more context for this? From the log, I can't see what the actual issue is. Is it an autoconf check that fails or an actual compilation issue? If it's a check, which one? If it's actually in the source, the error doesn't make any sense. Compilation is done without -Werror, and the deprecation message is only a warning.
Bug#1020702: [3dprinter-general] Bug#1020702: prusa-slicer: SEGV on start
That seems to be a dead giveaway: #2 0x7696e0c6 in wxTranslations::SetLanguage (this=0x0, lang=lang@entry=wxLANGUAGE_DEFAULT) at ./src/common/translation.cpp:1384 I'd expect it to crash when *this* is a null pointer. Have you reported the issue upstream?
Bug#1020556: python3-pip: man page documents removed --build option
Package: python3-pip Version: 22.2+dfsg-1 Severity: normal X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, According to https://pip.pypa.io/en/latest/news/#deprecations-and-removals the option --build-dir was removed in pip 21.3. The man page included in the Debian package still documents the option --build, which was an alias to this option and was removed likewise. Please fix the man page so it reflects current usage. Thanks! -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pip depends on: ii ca-certificates 20211016 ii python3 3.10.6-1 ii python3-distutils 3.10.6-1 ii python3-setuptools 59.6.0-1.2 ii python3-wheel 0.37.1-2 Versions of packages python3-pip recommends: ii build-essential 12.9 ii python3-dev 3.10.6-1 python3-pip suggests no packages. -- no debconf information
Bug#1011215: openvdb: FTBFS with onetbb/2021.5.0-8 in experimental
> Could NOT find TBB (missing: Tbb_INCLUDE_DIR) (Required is at least > version > "2018.0") > Call Stack (most recent call first): > /usr/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594 > (_FPHSA_FAILURE_MESSAGE) > cmake/FindTBB.cmake:319 (find_package_handle_standard_args) > openvdb/openvdb/CMakeLists.txt:123 (find_package) Maybe the same issue: https://github.com/AcademySoftwareFoundation/openvdb/issues/1366 The solution is to update OpenVDB to at least 8.2, which has compatibility with OneTBB 2021.5.
Bug#1011229: slic3r-prusa: FTBFS with onetbb/2021.5.0-8 in experimental
> /home/merkys/slic3r-prusa-2.4.2+dfsg/src/libslic3r/OpenVDBUtils.cpp:9: > /usr/include/openvdb/tools/MeshToVolume.h:36:10: fatal error: > tbb/task_scheduler_init.h: No such file or directory >36 | #include > | ^~~ > compilation terminated. Looks like this is actually in openvdb and not slic3r-prusa. Hopefully fixing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011215 will fix this issue too?
Bug#808940: pkg-group
> Something completely different: > The list of blocking RFP bugreports scares me. > I think not all are needed to get a working Terraform. That dependency list doesn't look so scary any more, but maybe it has changed significantly since the last update to the bug report. Is someone still working on this? While upstream provides their own Debian package servers[1], it would be better to have Terraform in Debian. [1] https://www.terraform.io/downloads
Bug#1012575: [3dprinter-general] Bug#1012575: libarcus: FTBFS with protobuf 3.20.1+
> I would like to start the Protobuf 3.20.1 transition in a few days. > Your package is currently FTBFS for a simple reason. The function > SetTotalBytesLimit doesn't have a second argument for long (protobuf > 3.6) and it was ignored previously. Now it's finally removed and hence > your package doesn't build anymore. > As it was ignored for a long time, the fix is easy, just remove that > argument when calling the mentioned function. Patch is attached, > please apply it soon. Unfortunately, upstream hasn't fixed this issue yet: https://github.com/Ultimaker/libArcus/issues/121 I suppose it would be best if we add your patch right away and drop it when upstream releases a fix. I took the liberty to branch from the last 4.13 release, so we can push a fixed version before 5.0 arrives: https://salsa.debian.org/3dprinting-team/libarcus/-/tree/testing And I added it to the master branch for the 5.0 release as well. @myon Please upload 4.13.0-3 when you have time. Thank you!
Bug#1009618: Firmware "beige-goby*", for Radeon RX6500XT, missing from package
Package: firmware-amd-graphics Version: 20210818-1 Severity: important Followup-For: Bug #1009618 X-Debbugs-Cc: onit...@gmail.com A couple of other firmware files have been missing for a while too: W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_gpu_info.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/vangogh_gpu_info.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_sos.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_toc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_asd.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_ta.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_sos.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_ce.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_ce.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_ce.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_rlc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_mec2.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_mec.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_me.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_pfp.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_ce.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_sdma.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_sdma1.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish2_sdma.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_sdma1.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/cyan_skillfish_sdma.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_sdma.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_sdma.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/sienna_cichlid_mes.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_vcn.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_vcn.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_vcn.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_smc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/aldebaran_smc.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/yellow_carp_dmcub.bin for module amdgpu W: Possible missing firmware /lib/firmware/amdgpu/beige_goby_dmcub.bin for module amdgpu Most of them can be found in https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible
Package: ansible Version: 5.5.0-1 Severity: important X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, Ansible has a strict dependency on resolvelib >=0.5.3 && <0.6.0, which is documented in the upstream requirements.txt: https://github.com/ansible/ansible/blob/devel/requirements.txt Debian bullseye/sid installs 0.8.1, which breaks some functionality in Ansible. In particular, downloading collections with ansible-galaxy is no longer possible: $ ansible-galaxy install -r requirements.yml -vvv ... Process install dependency map ERROR! Unexpected Exception, this is probably a bug: CollectionDependencyProvider.find_matches() got an unexpected keyword argument 'identifier' the full traceback was: Traceback (most recent call last): File "/usr/bin/ansible-galaxy", line 128, in exit_code = cli.run() File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 569, in run return context.CLIARGS['func']() File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 86, in method_wrapper return wrapped_method(*args, **kwargs) File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1203, in execute_install self._execute_install_collection( File "/usr/lib/python3/dist-packages/ansible/cli/galaxy.py", line 1230, in _execute_install_collection install_collections( File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py", line 548, in install_collections dependency_map = _resolve_depenency_map( File "/usr/lib/python3/dist-packages/ansible/galaxy/collection/__init__.py", line 1364, in _resolve_depenency_map return collection_dep_resolver.resolve( File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 481, in resolve state = resolution.resolve(requirements, max_rounds=max_rounds) File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 348, in resolve self._add_to_criteria(self.state.criteria, r, parent=None) File "/usr/lib/python3/dist-packages/resolvelib/resolvers.py", line 147, in _add_to_criteria matches = self._p.find_matches( TypeError: CollectionDependencyProvider.find_matches() got an unexpected keyword argument 'identifier' Related issue: https://bugs.gentoo.org/795933 I'm not aware of a proper patch for this issue. Gentoo has fixed it by pinning the resolvelib dependency to the requested version range. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ansible depends on: ii ansible-core 2.12.4-1 ii openssh-client 1:9.0p1-1 ii python33.10.4-1 ii python3-distutils 3.9.12-1 ii python3-dnspython 2.2.0-2 ii python3-httplib2 0.20.2-2 ii python3-jinja2 3.0.3-1 ii python3-netaddr0.8.0-2 ii python3-yaml 5.4.1-1+b1 Versions of packages ansible recommends: ii python3-argcomplete 1.12.3-0.1 ii python3-cryptography 3.4.8-1 ii python3-jmespath 1.0.0-1 ii python3-kerberos 1.1.14-3.1+b4 ii python3-libcloud 3.4.1-2 ii python3-selinux 3.3-1+b2 ii python3-winrm 0.3.0-2 ii python3-xmltodict 0.12.0-2 Versions of packages ansible suggests: pn cowsay ii sshpass 1.09-1+b1 -- no debconf information
