Hi Tobias,
I've prepared an NMU for slic3r-prusa (versioned as 2.7.4+dfsg-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Thank you, but could you explain where this patch is coming from?
+ set(OCCT_LIBS
+-TKXDESTEP
+-TKSTEP
+-TKSTEP209
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
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
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
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
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
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 @@
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,
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
> 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
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
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
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
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.
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
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,
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
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
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
(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!
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
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
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
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
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
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
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:
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.
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:
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
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
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
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
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",
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
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
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
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
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),
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
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
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
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'
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
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
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
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
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:
>
-- 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:
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 ]
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
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
#
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
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
> 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
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
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
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
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
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
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:
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
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
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,
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
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
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
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
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
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
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:
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
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
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
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
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
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.
.
@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
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
Is anybody already working on this?
I will attempt to fix d/copyright and submit a patch or MR for review
otherwise.
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
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:
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
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
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
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:
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-
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
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 .
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
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
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
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,
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?
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
> 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
> /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
> 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
> 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
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:
1 - 100 of 394 matches
Mail list logo
